Cisco SG550x - VLANs, DHCP, usw
Nabend Zusammen,
ich hab hier diverse Cisco SG550X stehen. So weit so gut. Drei davon hab ich gestacked - läuft.
VLANs sind angelegt und jedes VLAN hat eine IP
VLAN1 192.168.178.0
VLAN10 172.16.10.0
VLAN20 172.16.20.0
usw
VLAN100 172.16.100.0
So weit so gut.
1. Problem: Offenbar kann man die Teile nicht generell auf Layer 3 stellen? Ich kann das nur Portabhängig machen.
2. Stelle ich auf Layer 3 um kann ich den VLAN Modus nicht mehr beeinflussen und er steht immer auf Access, was zur Folge hat, dass ich den Port nur noch im VLAN Modus: Excluded, Untagged und Multi TV VLAN betreiben kann, Aber nicht mehr tagged.
3. Problem: DHCP Relay - sprich einen DHCP Server (2008er) mit mehreren Scopes - Testweise nur ein Scope mit 172.16.10.0/24
Wie schon hier beschrieben: Cisco SG500-52 10 x Vlan mit einen DHCP Server
kann man über die CLI mit dem Befehl "ip helper-address 192.168.178.5" nichts reißen. Außer mit all dazwischen, aber das macht keinen Sinn.
Benutzt man es sind die DHCP Ports 67,68 nicht aufgelistet, sondern nur diverse andere UDP Ports.
Also hab ich den DHCP Server als DHCP Relay eingetragen - wieder nix
Ich steh auf der Stelle und find nichts brauchbares.
Jemand nen Tipp oder auch zwei?
Grüße
X
ich hab hier diverse Cisco SG550X stehen. So weit so gut. Drei davon hab ich gestacked - läuft.
VLANs sind angelegt und jedes VLAN hat eine IP
VLAN1 192.168.178.0
VLAN10 172.16.10.0
VLAN20 172.16.20.0
usw
VLAN100 172.16.100.0
So weit so gut.
1. Problem: Offenbar kann man die Teile nicht generell auf Layer 3 stellen? Ich kann das nur Portabhängig machen.
2. Stelle ich auf Layer 3 um kann ich den VLAN Modus nicht mehr beeinflussen und er steht immer auf Access, was zur Folge hat, dass ich den Port nur noch im VLAN Modus: Excluded, Untagged und Multi TV VLAN betreiben kann, Aber nicht mehr tagged.
3. Problem: DHCP Relay - sprich einen DHCP Server (2008er) mit mehreren Scopes - Testweise nur ein Scope mit 172.16.10.0/24
Wie schon hier beschrieben: Cisco SG500-52 10 x Vlan mit einen DHCP Server
kann man über die CLI mit dem Befehl "ip helper-address 192.168.178.5" nichts reißen. Außer mit all dazwischen, aber das macht keinen Sinn.
Benutzt man es sind die DHCP Ports 67,68 nicht aufgelistet, sondern nur diverse andere UDP Ports.
Also hab ich den DHCP Server als DHCP Relay eingetragen - wieder nix
switched8d1d#show running-config
config-file-header
switched8d1d
v2.3.5.63 / RLINUX_923_093
CLI v1.0
file SSD indicator encrypted
@
ssd-control-start
ssd config
ssd file passphrase control unrestricted
no ssd file integrity control
ssd-control-end cb0a3fdb1f3a1af4e4430033719968c0
!
!
unit-type-control-start
unit-type unit 1 network gi uplink te
unit-type unit 2 network gi uplink te
unit-type unit 3 network gi uplink te
unit-type unit 4 network gi uplink te
unit-type unit 5 network gi uplink te
unit-type unit 6 network gi uplink te
unit-type unit 7 network gi uplink te
unit-type unit 8 network gi uplink te
unit-type-control-end
!
vlan database
vlan 10,20,30,40,50,60,70,80,90,100
exit
voice vlan oui-table add 0001e3 Siemens_AG_phone________
voice vlan oui-table add 00036b Cisco_phone_____________
voice vlan oui-table add 00096e Avaya___________________
voice vlan oui-table add 000fe2 H3C_Aolynk______________
voice vlan oui-table add 0060b9 Philips_and_NEC_AG_phone
voice vlan oui-table add 00d01e Pingtel_phone___________
voice vlan oui-table add 00e075 Polycom/Veritel_phone___
voice vlan oui-table add 00e0bb 3Com_phone______________
ethtype dot1q
ip dhcp relay address 192.168.178.5
ip dhcp information option
bonjour interface range vlan 1
hostname switched8d1d
line console
exec-timeout 30
exit
line ssh
exec-timeout 30
exit
line telnet
exec-timeout 30
exit
ip ssh server
snmp-server location XXX
ip http timeout-policy 1800
clock timezone " " +2
sntp server 0.de.pool.ntp.org poll
no sntp server time-a.timefreq.bldrdoc.gov
no sntp server time-b.timefreq.bldrdoc.gov
no sntp server time-c.timefreq.bldrdoc.gov
ip domain name XXXX
ip name-server 192.168.178.7
ip telnet server
!
interface vlan 1
ip address 192.168.178.254 255.255.255.0
no ip address dhcp
!
interface vlan 10
name XXX
ip address 172.16.10.254 255.255.255.0
ip dhcp relay enable
!
interface vlan 20
name XXX
ip address 172.16.20.254 255.255.255.0
!
interface vlan 30
name XXX
ip address 172.16.30.254 255.255.255.0
!
USW
!
interface GigabitEthernet1/0/2
switchport mode general
switchport general allowed vlan add 10 untagged
switchport access vlan 10
!
interface GigabitEthernet1/0/3
spanning-tree link-type point-to-point
switchport mode trunk
macro description switch
!next command is internal.
macro auto smartport dynamic_type switch
!
interface GigabitEthernet1/0/24
spanning-tree link-type point-to-point
macro description switch
!next command is internal.
macro auto smartport dynamic_type switch
!
interface TengigabitEthernet1/0/2
spanning-tree link-type point-to-point
switchport mode general
switchport general allowed vlan add 10,20,30,40,50,60,70,80,90,100 tagged
switchport general allowed vlan add 1 untagged
macro description switch
!next command is internal.
macro auto smartport dynamic_type switch
!
exit
ip default-gateway 192.168.178.7Ich steh auf der Stelle und find nichts brauchbares.
Jemand nen Tipp oder auch zwei?
Grüße
X
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 372339
Url: https://administrator.de/forum/cisco-sg550x-vlans-dhcp-usw-372339.html
Ausgedruckt am: 28.04.2025 um 20:04 Uhr
26 Kommentare
Neuester Kommentar
Zu 1.)
Nein, das ist unmöglich, das supporten die Switches nicht. Das geht nur bei IOS Modellen.
Die IP Adresse gilt pro VLAN !
Zu 2.)
Nein, das stimmt de facto nicht !
Du definierst den zuerst Port als Trunk Port und setzt dann das er Tagged ist in dem VLAN bzw. VLANs.
Die IP Adresse wird NICHT auf dem Port definiert somndern nur global im VLAN, was ja auch logisch ist.
10G 1/0/2 ist z.B. richtig außer das der Modus auf fälschlicherweise General ist, den sollte man besser auf Trunk setzen.
Zu 3.)
Hier liegt der Fehler zwischen den Kopfhörern !!
Das Relay wird natürlich NICHT auf dem Layer 3 Interface (VLAN) gemacht wo der Server selber drin hängt !!! Sondern immer auf den VLAN Segmenten die KEINEN DHCP Server haben. Diese sollen ja die Requests "relayen" zum Server !!
Du hast es genau andersrum und damit komplett falsch gemacht.
Hier wird also Relay enabled und der relay Server auf die DHCP Server IP eingestellt.
Im DHCP Server VLAN wird KEIN Relay definiert.
Korrigiere das, dann kommt das sofort zum Fliegen !
Kosmetisches:
Nein, das ist unmöglich, das supporten die Switches nicht. Das geht nur bei IOS Modellen.
Die IP Adresse gilt pro VLAN !
Zu 2.)
Nein, das stimmt de facto nicht !
Du definierst den zuerst Port als Trunk Port und setzt dann das er Tagged ist in dem VLAN bzw. VLANs.
Die IP Adresse wird NICHT auf dem Port definiert somndern nur global im VLAN, was ja auch logisch ist.
10G 1/0/2 ist z.B. richtig außer das der Modus auf fälschlicherweise General ist, den sollte man besser auf Trunk setzen.
Zu 3.)
Hier liegt der Fehler zwischen den Kopfhörern !!
Das Relay wird natürlich NICHT auf dem Layer 3 Interface (VLAN) gemacht wo der Server selber drin hängt !!! Sondern immer auf den VLAN Segmenten die KEINEN DHCP Server haben. Diese sollen ja die Requests "relayen" zum Server !!
Du hast es genau andersrum und damit komplett falsch gemacht.
Hier wird also Relay enabled und der relay Server auf die DHCP Server IP eingestellt.
Im DHCP Server VLAN wird KEIN Relay definiert.
Korrigiere das, dann kommt das sofort zum Fliegen !
Kosmetisches:
- IP Default Gateway ist falsch !! Entfernen und eine Default Route setzen ip route 0.0.0.0 /0 192.168.178.7
- SNTP Server solltest du einen dedizierten aus D nehmen: https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html
1
Zu 1)
Aber die SG500x konnte man wohl in den Layer3 Modus setzen - gab es eine Option zu?! InterVLANRouting wäre schon wichtig, wenn ich nicht irre
Das ist klar ...
Zu 2)
Du sagst ja (PN) dass ich die Uplinks als Trunk setzen soll - nur für die ist überhaupt "Tagged" relevant oder?
Hab ich geändert - danke
Zu 3)
Nicht nur da ;)
Aber das hab ich auch nicht vor gehabt. Der DHCP liegt in VLAN1 und in VLAN10 hab ich den DHCP Relay aktiviert
Kosmetisches:
Grüße
Aber die SG500x konnte man wohl in den Layer3 Modus setzen - gab es eine Option zu?! InterVLANRouting wäre schon wichtig, wenn ich nicht irre
Das ist klar ...
Zu 2)
Du sagst ja (PN) dass ich die Uplinks als Trunk setzen soll - nur für die ist überhaupt "Tagged" relevant oder?
Hab ich geändert - danke
Zu 3)
Nicht nur da ;)
Aber das hab ich auch nicht vor gehabt. Der DHCP liegt in VLAN1 und in VLAN10 hab ich den DHCP Relay aktiviert
Kosmetisches:
- korrigiere ich edit: Das ist als statische Route eingetragen?!
- ist der de.pool Server kein Deutscher? Aber ändere ich auch gerne! Danke
Grüße
Du sagst Layer3 Interface - muss ich die Interfaces alle auf Layer3 setzen?
Zu 1.)
Alle SoHo Switches der SG Serie kann man ab dem Modell SG250 in den Layer 3 Modus setzen, bzw. der ist schon per Default an.
Zu 2.)
Richtig !
Es reicht einfach eine VLAN IP zu konfigurieren.
Damit macht das Teil dann Layer 3 in dem VLAN !
Alle SoHo Switches der SG Serie kann man ab dem Modell SG250 in den Layer 3 Modus setzen, bzw. der ist schon per Default an.
Zu 2.)
Richtig !
muss ich die Interfaces alle auf Layer3 setzen?
Neiiiin ! Niemals die Interfaces (Ports) direkt. Das geht auch bei den SGs gar nicht nur bei IOS.Es reicht einfach eine VLAN IP zu konfigurieren.
Damit macht das Teil dann Layer 3 in dem VLAN !
1
Zu 1)
Aber nicht generell!? Zumindest find ich dazu nix, außer wie du bei 2. schreibst ...
Zu 2)
Mh ich kann aber bei den Interfaces auswählen ob Layer 2 oder Layer 3
Hab ich getan...
DHCP Relay geht nicht, aber ich glaub ich muss am Server noch was einstellen ...
Aber nicht generell!? Zumindest find ich dazu nix, außer wie du bei 2. schreibst ...
Zu 2)
Mh ich kann aber bei den Interfaces auswählen ob Layer 2 oder Layer 3
Hab ich getan...
DHCP Relay geht nicht, aber ich glaub ich muss am Server noch was einstellen ...
Also ich habe es wie hier konfiguriert:
http://9to5it.com/cisco-sg300-configure-dhcp-relay-to-allow-dhcp-server ...
Nix! Bekomme keine IP vom DHCP!
Geb ich mir eine statische IP aus dem VLAN 10 (172.16.10.254) bekomme ich Antworten von der .254 und aus dem VLAN1 mit 192.168.178.x
http://9to5it.com/cisco-sg300-configure-dhcp-relay-to-allow-dhcp-server ...
Nix! Bekomme keine IP vom DHCP!
Geb ich mir eine statische IP aus dem VLAN 10 (172.16.10.254) bekomme ich Antworten von der .254 und aus dem VLAN1 mit 192.168.178.x
Aber nicht generell!?
Doch, generell ! Alles was SG250 und höher ist macht Layer 3 !DHCP Relay geht nicht, aber ich glaub ich muss am Server noch was einstellen ...
Ja, hier musst du aufpassen das dir die lokale Firewall am Server nicht die Relay Pakete vom Switch blockt !Die haben immer als Absender IPs die des lokalen VLAN Interfaces und normal blockt die Firewall ALLES was nicht vom lokalen Netz kommt. Das musst du anpassen !
Nix! Bekomme keine IP vom DHCP!
Sniffer mal mit dem Wireshark ob am DHCP Server die Requests überhaupt ankommen !Wenn nicht hast du noch einen Konfig Fehler !
Die VLAN IP Adressen kannst du ALLE vom DHCP Server und vice versa anpingen ?
1
Also ich hab die Firewall mal komplett abgedreht. Ändert aber nix.
Wireshark läuft auf dem Ding nicht. Habe jetzt Packetyzer benutzt und dort bekomme ich:
DHCP Discover von 172.16.10.254 an den DHCP Server 192.168.178.5
und nen DHCP Offer zurück ans VLAN Interface
Und das wars dann auch ....
Wireshark läuft auf dem Ding nicht. Habe jetzt Packetyzer benutzt und dort bekomme ich:
DHCP Discover von 172.16.10.254 an den DHCP Server 192.168.178.5
Packetyzer Trace:
Frame 1 (362 bytes on wire, 362 bytes captured)
Frame is marked: False
Arrival Time: Apr 27, 2018 14:23:20.186234000
Time delta from previous packet: -1.121711000 seconds
Time since reference or first frame: 42.725122000 seconds
Frame Number: 1
Packet Length: 362 bytes
Capture Length: 362 bytes
Protocols in frame: eth:ip:udp:bootp
Ethernet II, Src: 40:a6:e8:ed:8d:1d (40:a6:e8:ed:8d:1d), Dst: 00:50:56:a6:68:9c (00:50:56:a6:68:9c)
Destination: 00:50:56:a6:68:9c (00:50:56:a6:68:9c)
Address: 00:50:56:a6:68:9c (00:50:56:a6:68:9c)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address
Source: 40:a6:e8:ed:8d:1d (40:a6:e8:ed:8d:1d)
Address: 40:a6:e8:ed:8d:1d (40:a6:e8:ed:8d:1d)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address
Type: IP (0x0800)
Internet Protocol, Src: 172.16.10.254 (172.16.10.254), Dst: 192.168.178.5 (192.168.178.5)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xe0 (DSCP 0x38: Class Selector 7; ECN: 0x00)
1110 00.. = Differentiated Services Codepoint: Class Selector 7 (0x38)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 348
Identification: 0x536b (21355)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0xfb89 [correct]
Good: True
Bad : False
Source: 172.16.10.254 (172.16.10.254)
Source or Destination Address: 172.16.10.254 (172.16.10.254)
Source Host: 172.16.10.254
Source or Destination Host: 172.16.10.254
Destination: 192.168.178.5 (192.168.178.5)
Source or Destination Address: 192.168.178.5 (192.168.178.5)
Destination Host: 192.168.178.5
Source or Destination Host: 192.168.178.5
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootps (67)
Source port: bootps (67)
Destination port: bootps (67)
Source or Destination Port: 67
Source or Destination Port: 67
Length: 328
Checksum coverage: 328
Checksum: 0x0312 [correct]
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 1
Transaction ID: 0xa2b63342
Seconds elapsed: 6656
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 172.16.10.254 (172.16.10.254)
Client MAC address: 1c:39:47:bb:33:3c (1c:39:47:bb:33:3c)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Frame is DHCP: True
Option 53: DHCP Message Type = DHCP Discover
Option 61: Client identifier
Hardware type: Ethernet
Client MAC address: 1c:39:47:bb:33:3c (1c:39:47:bb:33:3c)
Option 12: Host Name = "NAME"
Option 60: Vendor class identifier = "MSFT 5.0"
Option 55: Parameter Request List
1 = Subnet Mask
15 = Domain Name
3 = Router
6 = Domain Name Server
44 = NetBIOS over TCP/IP Name Server
46 = NetBIOS over TCP/IP Node Type
47 = NetBIOS over TCP/IP Scope
31 = Perform Router Discover
33 = Static Route
121 = Classless Static Route
249 = Classless static routes
43 = Vendor-Specific Information
Option 82: Agent Information Option (18 bytes)
Agent Circuit ID: 0004000A0102
Agent Remote ID: 000640A6E8ED8D1D
End Option
Paddingund nen DHCP Offer zurück ans VLAN Interface
Packetyzer Trace:
Frame 1 (342 bytes on wire, 342 bytes captured)
Frame is marked: False
Arrival Time: Apr 27, 2018 14:23:20.186376000
Time delta from previous packet: -1.121569000 seconds
Time since reference or first frame: 42.725264000 seconds
Frame Number: 1
Packet Length: 342 bytes
Capture Length: 342 bytes
Protocols in frame: eth:ip:udp:bootp
Ethernet II, Src: 00:50:56:a6:68:9c (00:50:56:a6:68:9c), Dst: 00:ff:d9:5a:a9:2a (00:ff:d9:5a:a9:2a)
Destination: 00:ff:d9:5a:a9:2a (00:ff:d9:5a:a9:2a)
Address: 00:ff:d9:5a:a9:2a (00:ff:d9:5a:a9:2a)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address
Source: 00:50:56:a6:68:9c (00:50:56:a6:68:9c)
Address: 00:50:56:a6:68:9c (00:50:56:a6:68:9c)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address
Type: IP (0x0800)
Internet Protocol, Src: 192.168.178.5 (192.168.178.5), Dst: 172.16.10.254 (172.16.10.254)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 328
Identification: 0x3919 (14617)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0x0000 [incorrect, should be 0xd6cf]
Good: False
Bad : True
Source: 192.168.178.5 (192.168.178.5)
Source or Destination Address: 192.168.178.5 (192.168.178.5)
Source Host: 192.168.178.5
Source or Destination Host: 192.168.178.5
Destination: 172.16.10.254 (172.16.10.254)
Source or Destination Address: 172.16.10.254 (172.16.10.254)
Destination Host: 172.16.10.254
Source or Destination Host: 172.16.10.254
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootps (67)
Source port: bootps (67)
Destination port: bootps (67)
Source or Destination Port: 67
Source or Destination Port: 67
Length: 308
Checksum coverage: 308
Bad Checksum: True
Checksum: 0x2b02 [incorrect, should be 0x731e]
Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0xa2b63342
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 172.16.10.100 (172.16.10.100)
Next server IP address: 192.168.178.5 (192.168.178.5)
Relay agent IP address: 172.16.10.254 (172.16.10.254)
Client MAC address: 1c:39:47:bb:33:3c (1c:39:47:bb:33:3c)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Frame is DHCP: True
Option 53: DHCP Message Type = DHCP Offer
Option 1: Subnet Mask = 255.255.255.0
Option 58: Renewal Time Value = 1 day
Option 59: Rebinding Time Value = 1 day, 18 hours
Option 51: IP Address Lease Time = 2 days
Option 54: Server Identifier = 192.168.178.5
Option 15: Domain Name = "DOMAIN.local"
Option 3: Router = 172.16.10.254
Option 6: Domain Name Server = 192.168.178.5
End Option
PaddingUnd das wars dann auch ....
Es sieht so aus als wenn beim Client nichts ankommt. Der schickt immer wieder DHCP Discover Anforderungen raus, aber nix kommt zurück.
"Geb ich mir eine statische IP aus dem VLAN 10 (172.16.10.254) bekomme ich Antworten von der .254 und aus dem VLAN1 mit 192.168.178.x"
Vergiss das! WLAN war an. Kann nur die 172.16.10.254 pingen - nichts aus dem anderen Netz!
Vergiss das! WLAN war an. Kann nur die 172.16.10.254 pingen - nichts aus dem anderen Netz!
Habe jetzt noch eine Route auf dem DHCP Server gesetzt
route add -p 172.16.10.0 mask 255.255.255.0 192.168.178.254
dhcp Relay geht
Aber das wars. Sonst ist nichts erreichbar.
Zum Verständnis: Wenn ich jetzt nur möchte das die Clients aus 172.16.10.0/24 auf bestimmte Adressen in 192.168.178.0/24 zugreifen können mache ich das über die ACL am Switch?
edit: Ich muss jetzt doch nicht alles mit Routen versehen oder?
route add -p 172.16.10.0 mask 255.255.255.0 192.168.178.254
dhcp Relay geht
Aber das wars. Sonst ist nichts erreichbar.
Zum Verständnis: Wenn ich jetzt nur möchte das die Clients aus 172.16.10.0/24 auf bestimmte Adressen in 192.168.178.0/24 zugreifen können mache ich das über die ACL am Switch?
edit: Ich muss jetzt doch nicht alles mit Routen versehen oder?
und dort bekomme ich: DHCP Discover von 172.16.10.254 an den DHCP Server 192.168.178.5
Bingo !Also funktioniert dein DHCP Relay fehlerlos ! Da ist dann der Winblows Server der pöhse Buhmann !
und nen DHCP Offer zurück ans VLAN Interface
Noch besser !Vergiss das! WLAN war an.
Grrrr... !! 
Zum Testen immer aus damit !Kann nur die 172.16.10.254 pingen - nichts aus dem anderen Netz!
Dann stimmt dein Routing generell auf dem Switch nicht Du musst auch ALLE anderen VLAN Interface IPs pingen können !
Nur mal nebenbei: ICMP hast du im Test PC richtig customized ?
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Habe jetzt noch eine Route auf dem DHCP Server gesetzt
Ist doch totaler Schwachsinn !!Sorry für die harten Worte aber dein Switch soll routen und NICHT eine Frickelroute übers WLAN.
Vergiss den Blödsinn und lösche diesen Unsinn sofort wieder !
Der DHCP Server MUSS den Client in dem VLAN eine IP aus dem VLAN vergeben und als Gateway die Switch VLAN IP und als DNS Server den internen DNS oder den Internet Router.
Vergebe dir sonst erstmal im Test VLAN eine statische IP mit Gateway auf die L3 Switch VLAN IP.
Dann pingst du mal alle anderen L3 VLAN IP Adressen des Switches (WLAN aus !)
Das MUSS gehen !
Bevor das nicht klappt musst du gar nicht erst weitermachen !
Ich muss jetzt doch nicht alles mit Routen versehen oder?
Natürlich nicht !Es muss wie gesagt nur die VLAN Switch IP als Gateway eingetragen sein !
Der L3 Switch "kennt" ja alle diese IPs da sie ja direkt an ihm dran sind.
Er braucht lediglich eine Default Route zum Internet Router und der selber muss alle VLANs als statische Routen definiert haben.
Ein Ping auf die VLAN IPs des Switches geht immer ohne Routen. Wenn nicht stimmt an deiner L3 Konfig grundsätzlich was nicht.
Zum Verständnis: Wenn ich jetzt nur möchte das die Clients aus 172.16.10.0/24 auf bestimmte Adressen in 192.168.178.0/24 zugreifen können mache ich das über die ACL am Switch?
Ja !Aber bitte nicht jetzt !!. Bringe erstmal das Routing generell zum Laufen dann kannst du die Schotten dicht machen.
Du musst dir ja nicht noch mehr Fussfallen legen vorher !
1
Jaha
Du musst auch ALLE anderen VLAN Interface IPs pingen können !
Ich hab da wohl beim DHCP Server nicht das Gateway angepasst .... hab mich die ganze Zeit gewundert, warum ich ne Antwort bekomme von 172.16.10.20 bzw. die Antwort aufn Ping von 172.16.10.252(anderer Switch) heißt: Antwort von 172.16.10.20, Zielhost nicht erreichbar.
Hier wurde kürzlich noch ne Fritzbox 6490 ins Netz gehängt und dort lief der DHCP noch und wie auch immer ging das offenbar durch den Schulrouter durch. Jut, das hab ich dann auch mal abgedreht.
Sorry für die harten Worte aber dein Switch soll routen und NICHT eine Frickelroute übers WLAN.
Vergiss den Blödsinn und lösche diesen Unsinn sofort wieder !
Hab mich ja auch schon gewundert, weil das ja nicht der Sinn der Sache sein konnte, aber es ging naja "ging"
Das hatte ich schon gesetzt alles, aber eben auf dem DHCP Server nicht das Gateway geändert - dazu gleich noch ne Frage.
Das klappt nun - kann aus dem 172.16.10.0 Netz auch die anderen VLAN Interfaces pingen.
Aber bitte nicht jetzt !!. Bringe erstmal das Routing generell zum Laufen dann kannst du die Schotten dicht machen.
Du musst dir ja nicht noch mehr Fussfallen legen vorher !
Logisch War nur zum Verständnis
So und nun noch ne Frage bzgl. GW.
Ich habe ja hier mehrere Räume in denen die Switche verteilt werden
Nehmen wir mal an ich habe 4 Rechner - jeder Rechner hängt an einem anderen Switch
PC 1 - Switch 1 (172.16.10.254)
PC 2 - Switch 2 (172.16.10.252)
PC 3 - Switch 3 (172.16.10.251)
PC 4 - Switch 4 (172.16.10.250)
172.16.10.0 ist jeweils das VLAN 10 auf den Switchen
Am DHCP füge ich einen Scope hinzu für 172.16.10.0
Aber was ist nun der Router? .254? .252? .251? .250? Oder ist das wurscht?
Edit: offenbar wurscht wenn die Dinger verbunden sind.
Edit2: Aber weder DNS noch sonst irgendwas geht ... nur icmp
Grüße
Edit: Du darfst auch harte Worte benutzen
Kann nur die 172.16.10.254 pingen - nichts aus dem anderen Netz!
Dann stimmt dein Routing generell auf dem Switch nicht Du musst auch ALLE anderen VLAN Interface IPs pingen können !
Ich hab da wohl beim DHCP Server nicht das Gateway angepasst .... hab mich die ganze Zeit gewundert, warum ich ne Antwort bekomme von 172.16.10.20 bzw. die Antwort aufn Ping von 172.16.10.252(anderer Switch) heißt: Antwort von 172.16.10.20, Zielhost nicht erreichbar.
Hier wurde kürzlich noch ne Fritzbox 6490 ins Netz gehängt und dort lief der DHCP noch und wie auch immer ging das offenbar durch den Schulrouter durch. Jut, das hab ich dann auch mal abgedreht.
Nur mal nebenbei: ICMP hast du im Test PC richtig customized ?
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Jep, das war schonhttps://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Habe jetzt noch eine Route auf dem DHCP Server gesetzt
Ist doch totaler Schwachsinn !!Sorry für die harten Worte aber dein Switch soll routen und NICHT eine Frickelroute übers WLAN.
Vergiss den Blödsinn und lösche diesen Unsinn sofort wieder !
Hab mich ja auch schon gewundert, weil das ja nicht der Sinn der Sache sein konnte, aber es ging
naja "ging"Der DHCP Server MUSS den Client in dem VLAN eine IP aus dem VLAN vergeben und als Gateway die Switch VLAN IP und als DNS Server den internen DNS oder den Internet Router.
Das hatte ich schon gesetzt alles, aber eben auf dem DHCP Server nicht das Gateway geändert - dazu gleich noch ne Frage.
Vergebe dir sonst erstmal im Test VLAN eine statische IP mit Gateway auf die L3 Switch VLAN IP.
Dann pingst du mal alle anderen L3 VLAN IP Adressen des Switches (WLAN aus !)
Das MUSS gehen !
Bevor das nicht klappt musst du gar nicht erst weitermachen !
Dann pingst du mal alle anderen L3 VLAN IP Adressen des Switches (WLAN aus !)
Das MUSS gehen !
Bevor das nicht klappt musst du gar nicht erst weitermachen !
Das klappt nun - kann aus dem 172.16.10.0 Netz auch die anderen VLAN Interfaces pingen.
Zum Verständnis: Wenn ich jetzt nur möchte das die Clients aus 172.16.10.0/24 auf bestimmte Adressen in 192.168.178.0/24 zugreifen können mache ich das über die ACL am Switch?
Ja !Aber bitte nicht jetzt !!. Bringe erstmal das Routing generell zum Laufen dann kannst du die Schotten dicht machen.
Du musst dir ja nicht noch mehr Fussfallen legen vorher !
Logisch
War nur zum VerständnisSo und nun noch ne Frage bzgl. GW.
Ich habe ja hier mehrere Räume in denen die Switche verteilt werden
Nehmen wir mal an ich habe 4 Rechner - jeder Rechner hängt an einem anderen Switch
PC 1 - Switch 1 (172.16.10.254)
PC 2 - Switch 2 (172.16.10.252)
PC 3 - Switch 3 (172.16.10.251)
PC 4 - Switch 4 (172.16.10.250)
172.16.10.0 ist jeweils das VLAN 10 auf den Switchen
Am DHCP füge ich einen Scope hinzu für 172.16.10.0
Aber was ist nun der Router? .254? .252? .251? .250? Oder ist das wurscht?
Edit: offenbar wurscht wenn die Dinger verbunden sind.
Edit2: Aber weder DNS noch sonst irgendwas geht ... nur icmp
Grüße
Edit: Du darfst auch harte Worte benutzen
Ich hab da wohl beim DHCP Server nicht das Gateway angepasst ...
Hier wurde kürzlich noch ne Fritzbox
WLAN an, dann das..., wilde DHCP Server und Router im Netz...Hier wurde kürzlich noch ne Fritzbox
Mal ein bischen sorgfältiger arbeiten erspart dir weitere Threads und graue Haare !!!
Das klappt nun - kann aus dem 172.16.10.0 Netz auch die anderen VLAN Interfaces pingen.
Röchel...was eine schwere Geburt !mehrere Räume in denen die Switche verteilt werden
Wie ??Alle als Einzelswitches oder indem du die 4 Switches als Stack betreibst ?
Am DHCP füge ich einen Scope hinzu für 172.16.10.0
Yepp, richtig !Aber was ist nun der Router? .254? .252? .251? .250? Oder ist das wurscht?
Oha, die Frage lässt darauf schliessen das du hier einen Denk- bzw. Designfehler aufliegst !!!Die Etagenswitches sind NICHT im L3 Mode zu konfigurieren sondern rein im L2 Mode. Diese routen also NICHT.
Deshalb stellt sich die Frage also gar nicht, denn das Gateway ist immer das VLAN IP Interface des Core Stacks !
Dieser ist der zentrale Layer 3 Knoten.
Das Routing passiert also in deinem Design rein nur auf den Core Knoten und NICHT in den Access Switches. Die werden wie gesagt rein nur im L2 Mode betrieben !!
Du hast mit dem Core Routing 2 Optionen:
1.)
Du routest einzig und allein auf dem einen Core Stack im Hauptgebäude wo auch dein RZ mit den Servern ist, also der zentrale Knoten.
2.)
Du routest auf jedem der 3 Core Knoten und definierst die 3 Koppellinks zw. den Gebäuden als Punkt zu Punkt IP Netze.
Vorteil Option 1:
- Ein zentraler Routing Punkt und damit einfaches L3 Management.
- Campus übergreifende VLANs möglich
- Spanning Tree im Core erforderlich
- Bei hohem Anteil von any zu any Traffic zw. den Gebäuden höherer Traffic Anteil bei L3 Verkehr
Vorteil Option 2:
- Bessere Segmentierung, weniger Last auf den Koppelnetzen
- Verzicht auch Spanning Tree im Core Netz möglich, schnelles Failover mit dynam. Routing
- Keine Campus übergreifenden VLANs mehr möglich.
- Höherer L3 Management Aufwand
Für eine der Optionen musst du dich entscheiden !
offenbar wurscht wenn die Dinger verbunden sind.
Ja, denn Routing Punkt ist bei beiden obigen Versionen ja immer der Core Router !Aber weder DNS noch sonst irgendwas geht ... nur icmp
WO ist dein DNS Server ??WER macht DNS ? Ein dedizierter Server oder nur der Internet Router ?
- Hat der DNS Server ein richtiges Gateway ?
- Ist der DNS Server aus ALLEN Vlan Segmenten pingbar ??
- Dein DNS Server hat ein Routing Problem !
1
Ich glaube mein Fallstrick ist dieser komische Schulrouter
Am Switch hab ich die Statische Route drin auf das Ding - 192.168.178.7
Bin ich in diesem Netz funktioniert alles, aber ich kann das Ding nicht aus den anderen Netzen pingen - ja, anderes GW, aber das kann ich da auch gar nicht setzen.
Im Handbuch steht man soll Routen setzen - hab ich getan zum Testen
Zielnetz 172.16.10.0/24
GW: 192.168.178.254 - VLAN1 Interface IP
geht net :/
Am Switch hab ich die Statische Route drin auf das Ding - 192.168.178.7
Bin ich in diesem Netz funktioniert alles, aber ich kann das Ding nicht aus den anderen Netzen pingen - ja, anderes GW, aber das kann ich da auch gar nicht setzen.
Im Handbuch steht man soll Routen setzen - hab ich getan zum Testen
Zielnetz 172.16.10.0/24
GW: 192.168.178.254 - VLAN1 Interface IP
geht net :/
Zitat von @aqui:
Mal ein bischen sorgfältiger arbeiten erspart dir weitere Threads und graue Haare !!!
Ich hab da wohl beim DHCP Server nicht das Gateway angepasst ...
Hier wurde kürzlich noch ne Fritzbox
WLAN an, dann das..., wilde DHCP Server und Router im Netz...Hier wurde kürzlich noch ne Fritzbox
Mal ein bischen sorgfältiger arbeiten erspart dir weitere Threads und graue Haare !!!
Du weißt doch - viele Köche verderben den Brei und das Ding wurde hier rein gehangen als ich nicht da war.
Das klappt nun - kann aus dem 172.16.10.0 Netz auch die anderen VLAN Interfaces pingen.
Röchel...was eine schwere Geburt !mehrere Räume in denen die Switche verteilt werden
Wie ??Alle als Einzelswitches oder indem du die 4 Switches als Stack betreibst ?
Raum 1: 8F8T - Core single(hab hier noch nen zweiten rumfliegen, aber das wird nix wegen der spärlichen LWL Verkabelung), Stack: SG550x-48P, SG550X-48, SG550X-24
Raum 2: Stack: SG550X-24P, SG550X-48, SG550X-24
Raum 3: Stack: SG550X-24P, SG550X-48, SG550X-24
Raum 4: Stack: SG550X-24P, SG550X-48, SG550X-24
Am DHCP füge ich einen Scope hinzu für 172.16.10.0
Yepp, richtig !Aber was ist nun der Router? .254? .252? .251? .250? Oder ist das wurscht?
Oha, die Frage lässt darauf schliessen das du hier einen Denk- bzw. Designfehler aufliegst !!!Die Etagenswitches sind NICHT im L3 Mode zu konfigurieren sondern rein im L2 Mode. Diese routen also NICHT.
Deshalb stellt sich die Frage also gar nicht, denn das Gateway ist immer das VLAN IP Interface des Core Stacks !
Dieser ist der zentrale Layer 3 Knoten.
Das Routing passiert also in deinem Design rein nur auf den Core Knoten und NICHT in den Access Switches. Die werden wie gesagt rein nur im L2 Mode betrieben !!
Angekommen
Du hast mit dem Core Routing 2 Optionen:
1.)
Du routest einzig und allein auf dem einen Core Stack im Hauptgebäude wo auch dein RZ mit den Servern ist, also der zentrale Knoten.
2.)
Du routest auf jedem der 3 Core Knoten und definierst die 3 Koppellinks zw. den Gebäuden als Punkt zu Punkt IP Netze.
Vorteil Option 1:
- Ein zentraler Routing Punkt und damit einfaches L3 Management.
- Campus übergreifende VLANs möglich
- Spanning Tree im Core erforderlich
- Bei hohem Anteil von any zu any Traffic zw. den Gebäuden höherer Traffic Anteil bei L3 Verkehr
Vorteil Option 2:
- Bessere Segmentierung, weniger Last auf den Koppelnetzen
- Verzicht auch Spanning Tree im Core Netz möglich, schnelles Failover mit dynam. Routing
- Keine Campus übergreifenden VLANs mehr möglich.
- Höherer L3 Management Aufwand
Für eine der Optionen musst du dich entscheiden !
Da kommt nur Option 1 in Betracht, weil ich Campusübergreifendes VLAN brauche.
offenbar wurscht wenn die Dinger verbunden sind.
Ja, denn Routing Punkt ist bei beiden obigen Versionen ja immer der Core Router !Aber weder DNS noch sonst irgendwas geht ... nur icmp
WO ist dein DNS Server ??WER macht DNS ? Ein dedizierter Server oder nur der Internet Router ?
- Hat der DNS Server ein richtiges Gateway ?
- Ist der DNS Server aus ALLEN Vlan Segmenten pingbar ??
- Dein DNS Server hat ein Routing Problem !
Der DNS Server ist auf dem Server 2008(192.168.178.5), der auch DHCP macht, dort gibt es ne Weiterleitung an den Schulrouter(192.168.178.7) - bisher war der Schulrouter als GW gesetzt überall und der Server 2008 als DNS und noch ein zweiter als alternativer DNS mit 192.168.178.6.
Das läuft ja auch alles...
Da der auch DHCP macht hat er das VLAN1 Interface als GW: 192.168.178.254
Ich hab aktuell nur ein VLAN zum Testen, aber von diesem aus geht es.
Das könnte möglich sein
Hach ja ...
Am Switch hab ich die Statische Route drin auf das Ding - 192.168.178.7
Das ist richtig !!Hast du auch an die Rückroute gedacht und dem Router deine VLAN Adressen in einer statischen Route beigebracht ?!
aber ich kann das Ding nicht aus den anderen Netzen pingen
Zeigt ganz klar das du die statischen Routen in deine VLANs vergessen hast auf diesem Router zu setzen !!! ja, anderes GW, aber das kann ich da auch gar nicht setzen.
Bahnhof ??Der Router 192.168.178.7 ist ja vermutlich eine FritzBox, nach der IP Adresse zu urteilen.
Der ist ja in einem VLAN Segment mit dem routenden Switch verbunden. Sagen wir mal im VLAN 99.
Der routende Switch hat im VLAN 99 die IP 192.168.178.254 /24
Im VLAN 10 am routenden Switch ist ein Test Laptop mit der IP 172.16.10.100 /24 der den Router pingen will.
Folgende Voraussetzungen müssen zwingend erfüllt sein:
- Der routende Switch braucht eine Default Route auf den Router. Also sowas wie ip route 0.0.0.0 0.0.0.0 192.168.178.7 ! Kein Default Gateway, es muss eine Default Route sein !
- Die FritzBox braucht eine statische Route aller VLAN IP Segmente auf den routenden Switch. Befinden sich ALLE deiner VLAN Segmente im Bereich 172.16.x.y dann reicht eine Summary Route mit einem 16 Bit Prefix in der FB um alle VLAN IP Netze zu routen also so:
Maske 255.255.0.0
Gateway: 192.168.178.254 (VLAN IP Switch)
Diese Route mit der 16er Maske routet dann ALLE 172.16.x.y IP Netze auf den routenden Switch. Und der "kennt" natürlich alle Netze.... Richtig ! Weil sie alle direkt an ihm dran sind.
Alles was er nicht kennt schaufelt er dann an die FB 192.168.178.7. Die routet dann alles was NICHT 172.16.0.0 /16 in der Ziel IP ist Richtung Internet Provider.
Alles was 172.16.0.0 /16 in der Ziel IP hat geht wie es sich gehört an den routenden VLAN Switch.
Jetzt machst du folgenden Test vom Latop:
- Ping lokale Switch VLAN 10 IP --> Sollte klappen
- Ping VLAN 99 Switch IP (Koppelnetz zum Router) --> Sollte klappen
- Ping Router IP 192.168.178.7 --> Sollte nun auch klappen
Traceroute zeigt dir alle Router Hops einzeln an. tracert 192.168.178.7 zeigt dir also den gesamten Routing Weg zum Internet Router. Da wo es nicht mehr weitergeht ist dein Fehler !
Da kommt nur Option 1 in Betracht, weil ich Campusübergreifendes VLAN brauche.
OK, dann ist das also geklärt.Dann machst du einzig NUR auf dem Core 2er Stack im RZ Layer 3 (Routing) !! Alle anderen Switches werden nur im Layer 2 konfiguriert. IP Forwarding (Routing) also AUS und max. nur eine IP Adresse im Management VLAN !!
Damit ist dann auch deine o.a. Gateway Frage umfassend geklärt.
1Zitat von @aqui:
Hast du auch an die Rückroute gedacht und dem Router deine VLAN Adressen in einer statischen Route beigebracht ?!
Genau das ist offenbar das Problem...Am Switch hab ich die Statische Route drin auf das Ding - 192.168.178.7
Das ist richtig !!Hast du auch an die Rückroute gedacht und dem Router deine VLAN Adressen in einer statischen Route beigebracht ?!
aber ich kann das Ding nicht aus den anderen Netzen pingen
Zeigt ganz klar das du die statischen Routen in deine VLANs vergessen hast auf diesem Router zu setzen !!! ja, anderes GW, aber das kann ich da auch gar nicht setzen.
Bahnhof ??Der Router 192.168.178.7 ist ja vermutlich eine FritzBox, nach der IP Adresse zu urteilen.
Eben nicht, sondern ein Schulrouter (http://www.time-for-kids.de/produkte/schulrouter/schulrouter-plus.html)
Der ist ja in einem VLAN Segment mit dem routenden Switch verbunden. Sagen wir mal im VLAN 99.
Der routende Switch hat im VLAN 99 die IP 192.168.178.254 /24
Im VLAN 10 am routenden Switch ist ein Test Laptop mit der IP 172.16.10.100 /24 der den Router pingen will.
Folgende Voraussetzungen müssen zwingend erfüllt sein:
Gateway: 192.168.178.254 (VLAN IP Switch)
Diese Route mit der 16er Maske routet dann ALLE 172.16.x.y IP Netze auf den routenden Switch. Und der "kennt" natürlich alle Netze.... Richtig ! Weil sie alle direkt an ihm dran sind.
Alles was er nicht kennt schaufelt er dann an die FB 192.168.178.7. Die routet dann alles was NICHT 172.16.0.0 /16 in der Ziel IP ist Richtung Internet Provider.
Alles was 172.16.0.0 /16 in der Ziel IP hat geht wie es sich gehört an den routenden VLAN Switch.
Der routende Switch hat im VLAN 99 die IP 192.168.178.254 /24
Im VLAN 10 am routenden Switch ist ein Test Laptop mit der IP 172.16.10.100 /24 der den Router pingen will.
Folgende Voraussetzungen müssen zwingend erfüllt sein:
- Der routende Switch braucht eine Default Route auf den Router. Also sowas wie ip route 0.0.0.0 0.0.0.0 192.168.178.7 ! Kein Default Gateway, es muss eine Default Route sein !
- Die FritzBox braucht eine statische Route aller VLAN IP Segmente auf den routenden Switch. Befinden sich ALLE deiner VLAN Segmente im Bereich 172.16.x.y dann reicht eine Summary Route mit einem 16 Bit Prefix in der FB um alle VLAN IP Netze zu routen also so: Zielnetz: 172.16.0.0
Gateway: 192.168.178.254 (VLAN IP Switch)
Diese Route mit der 16er Maske routet dann ALLE 172.16.x.y IP Netze auf den routenden Switch. Und der "kennt" natürlich alle Netze.... Richtig ! Weil sie alle direkt an ihm dran sind.
Alles was er nicht kennt schaufelt er dann an die FB 192.168.178.7. Die routet dann alles was NICHT 172.16.0.0 /16 in der Ziel IP ist Richtung Internet Provider.
Alles was 172.16.0.0 /16 in der Ziel IP hat geht wie es sich gehört an den routenden VLAN Switch.
Das ist alles klar so weit - habe ich auch versucht zu setzen:
Jetzt machst du folgenden Test vom Latop:
Klappt- Ping lokale Switch VLAN 10 IP --> Sollte klappen
* Ping VLAN 99 Switch IP (Koppelnetz zum Router) --> Sollte klappen
Was meinst du mit Koppelnetz zum Router? Das Ding hängt in VLAN1 wie alles andere derzeit auch noch.* Ping Router IP 192.168.178.7 --> Sollte nun auch klappen
Klappt nicht.Wenn wider Erwarten nicht, dann Traceroute verwenden. (tracert unter Winblows)
Traceroute zeigt dir alle Router Hops einzeln an. tracert 192.168.178.7 zeigt dir also den gesamten Routing Weg zum Internet Router. Da wo es nicht mehr weitergeht ist dein Fehler !
Ende ist bei der VLAN10 Interface-IP 172.16.10.254 - der DHCP-Server oder andere Rechner mit geändertem GW gehen problemlosTraceroute zeigt dir alle Router Hops einzeln an. tracert 192.168.178.7 zeigt dir also den gesamten Routing Weg zum Internet Router. Da wo es nicht mehr weitergeht ist dein Fehler !
Da kommt nur Option 1 in Betracht, weil ich Campusübergreifendes VLAN brauche.
OK, dann ist das also geklärt.Dann machst du einzig NUR auf dem Core 2er Stack im RZ Layer 3 (Routing) !! Alle anderen Switches werden nur im Layer 2 konfiguriert. IP Forwarding (Routing) also AUS und max. nur eine IP Adresse im Management VLAN !!
Damit ist dann auch deine o.a. Gateway Frage umfassend geklärt.
Was meinst du mit "max nur eine IP Adresse im Management VLAN"?
1000Dank nochmal!
Das ist alles klar so weit - habe ich auch versucht zu setzen:
Quell Netz darfst du vermutlich NICHT leer lassen !Dort müsste eine Wildcard rein also "Any". Meist ist das 0.0.0.0/0.
Wenn du das leer lässt trägt er vermutlich KEINE statische Route ein.
Kann man irgendwo die Routing Tabelle dieses Routers einsehen ?!
Vermutlich ist diese Route gar nicht aktiv oder gar keine Route angelegt. Deshalb mal die Routing Tabelle ansehen.
Laut Info werkelt da auch ne Firewall auf dem Router ! Achte darauf das lokal gerouteter Traffic dort von der Firewall ausgenommen ist, sonst schlägt die auch zu und filtert dir deinen 172.16er Traffic !!
Das ist alles klar so weit - habe ich auch versucht zu setzen:
Das der Router nur rein Layer 2 macht. Er braucht dann nur eine einzige IP Adresse um mit dem Management zugreifen zu können.Verantwortungsvolle Netzwerker packen die Management IP Adressen IMMER in ein separates VLAN und niemals im Produktiv Netze. Der Grund liegt auf der Hand = Sicherheit.
Das Management VLAN blockt man nachher mit ACLs so das nur die Admins Zugriff darauf haben. In dieses VLAN kommen dann auch alle ILO Boards von Servern und alle Out of Band Interfaces anderer Endgeräte die sicher gemanagt werden müssen.
Das sind aber simple und banale Basics im netzwerk Design !
1
Also ich raffs nicht.
Ich habe hier zwei Leitungen - genau genommen 3 ...
1) 1&1 VDSL mit einer Fritzbox 7390
2) Vodafone Cable mit einer Fritzbox 6490
Beide sind an dem Schulrouter dran und verbunden und via Load Balancing wird die Last aufgeteilt - so weit so gut.
Jetzt habe ich mal die Kabelleitung deaktiviert und plötzlich bekomme ich von meinem Testnotebook im 172.16.10.0er Netz eine Antwort von dem Ding(192.168.178.7)
Dass mir das gerade nicht in den Kopf will leuchtet ein oder?
Ja gut, aus dem VLAN1 fliegt nach und nach dann im Grunde eh alles raus. Alles andere kommt nach und nach.
Ach und ich komme nicht an die Shell ran - keine Zugangsdaten. Die wollen nicht das man da dran rumfrickelt. Mal sehen.
Ich habe hier zwei Leitungen - genau genommen 3 ...
1) 1&1 VDSL mit einer Fritzbox 7390
2) Vodafone Cable mit einer Fritzbox 6490
Beide sind an dem Schulrouter dran und verbunden und via Load Balancing wird die Last aufgeteilt - so weit so gut.
Jetzt habe ich mal die Kabelleitung deaktiviert und plötzlich bekomme ich von meinem Testnotebook im 172.16.10.0er Netz eine Antwort von dem Ding(192.168.178.7)
Dass mir das gerade nicht in den Kopf will leuchtet ein oder?
Ja gut, aus dem VLAN1 fliegt nach und nach dann im Grunde eh alles raus. Alles andere kommt nach und nach.
Ach und ich komme nicht an die Shell ran - keine Zugangsdaten. Die wollen nicht das man da dran rumfrickelt. Mal sehen.
Jetzt hab ich rausbekommen an welchem Haken es liegt:
In den WAN Einstellungen gibt es den Punkt "Diese WAN Verbindung ist verwaltet"
Laut Handbuch:
Wenn ich den Haken setze geht kein Ping mehr. Entferne ich den Haken geht der Ping durch.
Sinn?
In den WAN Einstellungen gibt es den Punkt "Diese WAN Verbindung ist verwaltet"
Laut Handbuch:
Jede WAN-Verbindung kann entweder im Modus „Verwaltet“ oder manuell laufen. Im Modus
„Verwaltet“ überwacht der Schulrouter Plus die Verbindung und stellt gegebenenfalls die Verbindung
automatisch wieder her. Wird der Modus „Verwaltet“ deaktiviert, kann die Verbindung manuell
hergestellt oder getrennt werden. Es wird kein automatischer Wiederaufbau der Verbindung
eingeleitet, wenn die Verbindung getrennt wird. Wenn ich den Haken setze geht kein Ping mehr. Entferne ich den Haken geht der Ping durch.
Sinn?
Also ich habe jetzt zwei VLANs getestet:
172.16.10.0
172.16.20.0
DHCP Scopes für beide sind angelegt.
VLAN Interface IP auf dem Coreswitch ist gesetzt mit .254 am Ende.
DHCP Relay Adresse ist gesetzt auf 192.168.178.5 (DHCP Server)
Statische Route auf dem Switch ebenfalls mit 0.0.0.0/0 - 192.168.178.7 (Schulrouter)
Route auf dem Schulrouter ist ebenfalls gesetzt mit Zielnetz: 172.16.0.0/16
Ich würde sagen: Bis zu diesem Punkt - es läuft.
Danke, Aqui!
172.16.10.0
172.16.20.0
DHCP Scopes für beide sind angelegt.
VLAN Interface IP auf dem Coreswitch ist gesetzt mit .254 am Ende.
DHCP Relay Adresse ist gesetzt auf 192.168.178.5 (DHCP Server)
Statische Route auf dem Switch ebenfalls mit 0.0.0.0/0 - 192.168.178.7 (Schulrouter)
Route auf dem Schulrouter ist ebenfalls gesetzt mit Zielnetz: 172.16.0.0/16
Ich würde sagen: Bis zu diesem Punkt - es läuft.
Danke, Aqui!
Beide sind an dem Schulrouter dran und verbunden und via Load Balancing wird die Last aufgeteilt
Das Balancing macht aber der Schulrouter, oder ? Sprich der ist das zentrale Gateway für alles im LAN.Die FritzGurken sind dann seine WAN1 und WAN2 Ports über die er balanced, richtig ?
Sprich die FBs sind dann erstmal irrelevant fürs Routing da hinter dem Schulrouter.
und plötzlich bekomme ich von meinem Testnotebook im 172.16.10.0er Netz
Mmmhhhh....Könnte natürlich sein das die beiden WAN 1+2 Koppelnetze dahinter 172.16.x.y Netze sind !!!
Dann hast du natürlich Pech und mit Zitronen gehandelt mit deinen VLANs bzw. deiner VLAN Adressierung
VLANs dann mal auf 10er oder 172.20..x.y umstellen oder sowas.
Bring mal in Erfahrung welche Koppelnetze da verwendet werden !
und ich komme nicht an die Shell ran - keine Zugangsdaten.
An den Schulrouter oder was ??Die wollen nicht das man da dran rumfrickelt.
Verständlich aber wenn du die Routing Tabelle anpasst ist das ja auch "rumfummeln" Die Einstellung ist aber Blödsinn. Musst du ja machen wenn sie ein neues netzdesign in Auftrag geben. Wasch mich aber mach mich nicht naß wäre ja Schwachsinn mit Verlaub gesagt....
Du brauchst zwingend eine detailierte Information WIE der Router eingerichtet ist, das ist doch klar. Ohne das kannst du doch das Projekt gar nicht umsetzen... Irgendeiner wird den ja eingerichtet haben der das weiß. Zumindest wird der wohl hoffentlich eine anständige Doku gemacht haben bei der Übergabe ?!!
"Diese WAN Verbindung ist verwaltet"
Kann damit eigentlich nichts zu tun haben. Damit kappt irgendwo einer den Internet Zugang.Mmmhhh.... OK wenn der damit dann natürlich das 192.168.178.7er Interface kappt dann kann das natürlich der Fall sein.
Aber dann würde sich der Kappende ja selber den Ast absägen worauf er sitzt. Ausnahme natürlich es gibt noch einen anderen Management Zugang unabhängig davon auf dem Router.
Wenn die .7 weg ist geht nix mehr, das ist dann klar. Oder sie wird nur geblockt für alles ausser dem Steuerrechner. All das muss man natürlich wissen.
Bring das in Erfahrung. Ohne diese Infos stocherst du weiter im Trüben und musst frickeln was Mist ist...wie immer.
1Zitat von @aqui:
Die FritzGurken sind dann seine WAN1 und WAN2 Ports über die er balanced, richtig ?
Sprich die FBs sind dann erstmal irrelevant fürs Routing da hinter dem Schulrouter.
Korrekt - Balancing macht der RouterBeide sind an dem Schulrouter dran und verbunden und via Load Balancing wird die Last aufgeteilt
Das Balancing macht aber der Schulrouter, oder ? Sprich der ist das zentrale Gateway für alles im LAN.Die FritzGurken sind dann seine WAN1 und WAN2 Ports über die er balanced, richtig ?
Sprich die FBs sind dann erstmal irrelevant fürs Routing da hinter dem Schulrouter.
und plötzlich bekomme ich von meinem Testnotebook im 172.16.10.0er Netz
Mmmhhhh....Könnte natürlich sein das die beiden WAN 1+2 Koppelnetze dahinter 172.16.x.y Netze sind !!!
Dann hast du natürlich Pech und mit Zitronen gehandelt mit deinen VLANs bzw. deiner VLAN Adressierung
VLANs dann mal auf 10er oder 172.20..x.y umstellen oder sowas.
Bring mal in Erfahrung welche Koppelnetze da verwendet werden !
und ich komme nicht an die Shell ran - keine Zugangsdaten.
An den Schulrouter oder was ??Die wollen nicht das man da dran rumfrickelt.
Verständlich aber wenn du die Routing Tabelle anpasst ist das ja auch "rumfummeln" Die Einstellung ist aber Blödsinn. Musst du ja machen wenn sie ein neues netzdesign in Auftrag geben. Wasch mich aber mach mich nicht naß wäre ja Schwachsinn mit Verlaub gesagt....
Du brauchst zwingend eine detailierte Information WIE der Router eingerichtet ist, das ist doch klar. Ohne das kannst du doch das Projekt gar nicht umsetzen... Irgendeiner wird den ja eingerichtet haben der das weiß. Zumindest wird der wohl hoffentlich eine anständige Doku gemacht haben bei der Übergabe ?!!
Den Router habe ich im Grunde schon eingerichtet, aber die Shell scheint separat gesichert mit einem Passwort was die Leute von Time for Kids haben offenbar. Ich habe alle Passwortkombinationen probiert - ich komme nicht ran an die Shell.
"Diese WAN Verbindung ist verwaltet"
Kann damit eigentlich nichts zu tun haben. Damit kappt irgendwo einer den Internet Zugang.Mmmhhh.... OK wenn der damit dann natürlich das 192.168.178.7er Interface kappt dann kann das natürlich der Fall sein.
Aber dann würde sich der Kappende ja selber den Ast absägen worauf er sitzt. Ausnahme natürlich es gibt noch einen anderen Management Zugang unabhängig davon auf dem Router.
Wenn die .7 weg ist geht nix mehr, das ist dann klar. Oder sie wird nur geblockt für alles ausser dem Steuerrechner. All das muss man natürlich wissen.
Bring das in Erfahrung. Ohne diese Infos stocherst du weiter im Trüben und musst frickeln was Mist ist...wie immer.
Ich verstehe auch nicht wieso es funktioniert wenn ich diese Option abschalte. Ich werde die eine Fritte mal in ein anderes Netz packen und dann nochmal testen.
Grds. funktioniert jetzt eigentlich erstmal alles. Jetzt muss ich noch die übrigen 9 Switche stacken zu 3x3 - bei denen kann ich ja die VLAN Interface IPs weg lassen, richtig? Weil das GW ist ja wieder die .254. Den Uplink jeweils auf tagged setzen für alle VLANs und gut is.
Muss ich da auch den DHCP Relay einrichten? Dem Grunde nach ja eigentlich nicht, oder? Weil es ja alles über den Coreswitch geht.
Sollte ich den Coreswitch dennoch stacken, sprich ich hab ja zwei davon, aber wie du ja weißt nur jeweils ein LWL Kabel aus den anderen Räumen. D.h. im Grunde wäre einer leer. Macht ja dann auch keinen Sinn oder? Dann lieber die Konfig sichern und im Fall der Fälle den anderen ran hängen oder?
Morgen werde ich mal die Verkabelung testen zwischen zwei Räumen - du weißt schon wegen der LC SC Kabel usw
mal sehen...Grüße
x
die WAN Schnittstelle am Router die 172.16.10.2 - kann ich aber problemlos ändern.
Tödlich ! Doppelte IP Adressen im Netz ! Das geht natürlich nicht. Solltest du also dringenst anpassen. IP Adressen müssen bekanntermaßen einzigartig sein im Netz !Weil das GW ist ja wieder die .254. Den Uplink jeweils auf tagged setzen für alle VLANs und gut is.
So ist es richtig !Muss ich da auch den DHCP Relay einrichten?
Natürlich nicht. Nackdenken.... DHCP Relay ginbts nur auf Layer 3 und da du da ja gar kein Layer 3 machst im Access gibts da logischerweise auch KEIN DHCP Relay Gibts nur auf den Routing Interfaces. Und nur an den Segmenten wo der DHCP Server NICHT ist. Am DHCP Server VLAN Interface natürlich KEIN Relay, klar !
aber wie du ja weißt nur jeweils ein LWL Kabel aus den anderen Räumen.
OK, dann kannst du ja auch keine Redundanz konfigurieren mit einem LAG der jeweils auf einem Stack Member endet.Mit nur einem einzigen Kabel geht das nicht und wenn du die Ports nicht brauchst dann nützt dir auch kein Stack. Die Redundanz bekommst du ja dann durch deine Dreiecks Struktur und die RSTP Priority Konfig.
1Zitat von @aqui:
Das ist ja klar. Doppelt ist hier nix. Nur die Cable Fritte hängt ebenfalls im 172.16.10.0er Netz mit der 172.16.10.1 - die gibt es nur einmal, aber ich werde die mal ändern.die WAN Schnittstelle am Router die 172.16.10.2 - kann ich aber problemlos ändern.
Tödlich ! Doppelte IP Adressen im Netz ! Das geht natürlich nicht. Solltest du also dringenst anpassen. IP Adressen müssen bekanntermaßen einzigartig sein im Netz !Weil das GW ist ja wieder die .254. Den Uplink jeweils auf tagged setzen für alle VLANs und gut is.
So ist es richtig !Muss ich da auch den DHCP Relay einrichten?
Natürlich nicht. Nackdenken.... DHCP Relay ginbts nur auf Layer 3 und da du da ja gar kein Layer 3 machst im Access gibts da logischerweise auch KEIN DHCP Relay Gibts nur auf den Routing Interfaces. Und nur an den Segmenten wo der DHCP Server NICHT ist. Am DHCP Server VLAN Interface natürlich KEIN Relay, klar !
Dankeaber wie du ja weißt nur jeweils ein LWL Kabel aus den anderen Räumen.
OK, dann kannst du ja auch keine Redundanz konfigurieren mit einem LAG der jeweils auf einem Stack Member endet.Mit nur einem einzigen Kabel geht das nicht und wenn du die Ports nicht brauchst dann nützt dir auch kein Stack. Die Redundanz bekommst du ja dann durch deine Dreiecks Struktur und die RSTP Priority Konfig.
Richtig ... also doch wie ich sagte, wenn der mal die Gretsche macht oder doch mal was neu verkabelt wird.
Ansonsten siehe PN - es geht!
Grüße
