Routing Fritzbox SG350-10 VLANs
Hallo an alle Administratoren hier
Seit einiger Zeit beschäftige ich mich nun mit der Strukturierung meines LAN und versuche momentan einen SG350-10 von Cisco einzurichten.
Zugegebenermaßen ist dies alles etwas Neuland für mich. Bisher war ein Netzwerk für mich ein WLAN/Router + evtl. noch ein Switch und dann alle Clients in einem Subnet zusammengepfercht. Nun im neuen Haus mit erweiterten Anforderungen bin ich dann über die Möglichkeiten von VLANS und sogar getrennte WLAN netze usw. gestolpert... Lange Rede Kurzer Sinn. Seit tagen liegt hier der SG350 Und lacht mich aus.
-Das Vlanrouting unter den einzelnen VLANs Funktioniert.
-Aus allen angelegten VLANs komme ich bis zum Router. (Bsp. Traceroute 8.8.8.8 endet bei 192.168.1.1)
-Aus dem default VLAN 1 komme ich Sogar ins Internet und zurück. (Bsp. Traceroute 8.8.8.8 endet wie gewollt bei Google)
jetzt könnte man meinen das die Rückroute in der Fritzbox fehlt und daher nicht in die VLANs geroutet wird.
Aber die Routen sind eingetragen. Habe es als einzelne Einträge und als zusammengefasste Route versucht.
Wo kann ich weiter nach dem Fehler suchen?
Hab ich den Fehler selbst eingebaut?
Im Anhang noch ein paar Screenshots der Konfig.
Danke und VG Robert
Seit einiger Zeit beschäftige ich mich nun mit der Strukturierung meines LAN und versuche momentan einen SG350-10 von Cisco einzurichten.
Zugegebenermaßen ist dies alles etwas Neuland für mich. Bisher war ein Netzwerk für mich ein WLAN/Router + evtl. noch ein Switch und dann alle Clients in einem Subnet zusammengepfercht. Nun im neuen Haus mit erweiterten Anforderungen bin ich dann über die Möglichkeiten von VLANS und sogar getrennte WLAN netze usw. gestolpert... Lange Rede Kurzer Sinn. Seit tagen liegt hier der SG350 Und lacht mich aus.
-Das Vlanrouting unter den einzelnen VLANs Funktioniert.
-Aus allen angelegten VLANs komme ich bis zum Router. (Bsp. Traceroute 8.8.8.8 endet bei 192.168.1.1)
-Aus dem default VLAN 1 komme ich Sogar ins Internet und zurück. (Bsp. Traceroute 8.8.8.8 endet wie gewollt bei Google)
jetzt könnte man meinen das die Rückroute in der Fritzbox fehlt und daher nicht in die VLANs geroutet wird.
Aber die Routen sind eingetragen. Habe es als einzelne Einträge und als zusammengefasste Route versucht.
Wo kann ich weiter nach dem Fehler suchen?
Hab ich den Fehler selbst eingebaut?
Im Anhang noch ein paar Screenshots der Konfig.
Danke und VG Robert
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 544585
Url: https://administrator.de/contentid/544585
Ausgedruckt am: 26.11.2024 um 07:11 Uhr
20 Kommentare
Neuester Kommentar
Moin,
ein Default Gateway muss immer im gleichen Subnetz liegen wie die Clients. Für 192.168.1.0/24 ist 192.168.1.1 als GW korrekt (und das Routing funktioniert hier auch).
In den anderen Netzen musst du jeweils die IP des Switches (falls der routen kann) als GW eintragen. Und an den Clients dann die Switch IP aus dem entsprechenden Subnetz.
Hier im Forum gibts auch eine tolle Anleitung zum Thema Routing und VLANs - schau da mal rein.
lg,
Slainte
ein Default Gateway muss immer im gleichen Subnetz liegen wie die Clients. Für 192.168.1.0/24 ist 192.168.1.1 als GW korrekt (und das Routing funktioniert hier auch).
In den anderen Netzen musst du jeweils die IP des Switches (falls der routen kann) als GW eintragen. Und an den Clients dann die Switch IP aus dem entsprechenden Subnetz.
Hier im Forum gibts auch eine tolle Anleitung zum Thema Routing und VLANs - schau da mal rein.
lg,
Slainte
Das gesamte Design und wie man es richtig umsetzt mit der FB ist in diesem Thread inkl. Zeichnung und Screenshots erklärt:
Verständnissproblem Routing mit SG300-28
Das ist der IP Adress Pool der DHCP Server den man auf dem Switch einrichten kann, sprich also die Gateway IP die der Switch DHCP an Clients gibt wenn man denn den DHCP Server auf dem Switch nutzt in den VLANs, was du vermutlich auch tust. Hier muss als Gateway immer die VLAN IP Adresse des Switches rein. In jedem VLAN also einen andere.
Für das globale Routing im Switch selber ist der Eintrag unter IPv4 Static Routes zuständig und da hast du vermutlich schlicht und einfach vergessen die Default Route einzutragen !!
Siehe Tutorial oben dort wird nochmal explizit darauf hingewiesen ! Wer lesen kann....
Fazit:
Der Switch selber muss eine Default Route auf die IP der FritzBox haben.
Verständnissproblem Routing mit SG300-28
ist unter Netzwerkpool.
Da hast du dann wohl nicht richtig hingesehen !!!Das ist der IP Adress Pool der DHCP Server den man auf dem Switch einrichten kann, sprich also die Gateway IP die der Switch DHCP an Clients gibt wenn man denn den DHCP Server auf dem Switch nutzt in den VLANs, was du vermutlich auch tust. Hier muss als Gateway immer die VLAN IP Adresse des Switches rein. In jedem VLAN also einen andere.
Für das globale Routing im Switch selber ist der Eintrag unter IPv4 Static Routes zuständig und da hast du vermutlich schlicht und einfach vergessen die Default Route einzutragen !!
Siehe Tutorial oben dort wird nochmal explizit darauf hingewiesen ! Wer lesen kann....
Fazit:
Der Switch selber muss eine Default Route auf die IP der FritzBox haben.
In der Tat ist das alles richtig nach den Screenshots. Der letzte mit "Pocketethernet" was ist das ?
In welchem VLAN Segment befindet sich dieser (vermutliche) WLAN Client ?
Du solltest einmal strategisch vorgehen zum Troubleshooting.
Konfig ist so erstmal OK. Stelle erstmal rein nur die Kopplung her mit der FritzBox her im Default VLAN 1. Dann machst du mal folgende Ping und IP Checks mit einem kabelgebundenen Endgerät am Switch:
In welchem VLAN Segment befindet sich dieser (vermutliche) WLAN Client ?
Du solltest einmal strategisch vorgehen zum Troubleshooting.
Konfig ist so erstmal OK. Stelle erstmal rein nur die Kopplung her mit der FritzBox her im Default VLAN 1. Dann machst du mal folgende Ping und IP Checks mit einem kabelgebundenen Endgerät am Switch:
- 1.) Test PC in einen untagged Port an VLAN 1. Check mit ipconfig ob eine korrekte IP (.1.x), Gateway (.1.1) und DNS (.1.1) vom FritzBox DHCP Server kommt.
- 2.) Ping Check von VLAN 1 Test PV auf .1.1, .1.254 und auf 8.8.8.8. Das sollte alles fehlerfrei klappen. (Achtung: die VLAN IPs auf dem Switch kannst du nicht pingen wenn kein aktives Endgerät in diesen VLANs. Das ist normal)
- 3.) Jetzt steckst du den Test PC in einen untagged Port im VLAN 10 und checkst wieder mit ipconfig ob eine korrekte IP (.10.x), Gateway (.10.1) und DNS (.1.1) diesmal vom Cisco DHCP Server kommt.
- 4.) Ist das der Fall dann wieder die gleichen Ping Checks auf VLAN 1 Cisco IP (.1.254), FritzBox (.1.1) und 8.8.8.8
- 5.) Das wiederholst du jetzt für die restlichen VLANs 11 und 12
Ich denke ich ahne wo der Fehler liegt !!!
Sieh dir mal deinen FritzBox Screenshot ganz genau an !!
Irgendwas kann da mit dem lokalen Netzwerk nicht stimmen !!
Dort ist ein 16 Bit Prefix eingestellt obwohl du aber ein 24 Bit Prefix in allen anderen Subnetzen hast und diesen auch selber oben in deinen Topologie Zeichnung so vorgibst.
Dadurch "denkt" die FritzBox natürlich das alle deine VLAN Subnetze in einem einzigen IP Netz liegen. Logisch, denn das lokale LAN Netzwerk wird nur durch die ersten 2 Bytes in der Adresse dargestellt, der Rest sind alles Host- sprich Endgeräte Adressen für die FB.
Die FB kann also durch die falsche Subnetzmaske deine VLAN Netze gar nicht "erkennen" bzw. routen, denn das sind alles lokale LAN Endgeräte Adressen für sie. Folglich ist ein sauberes Routing im 192.168er Segment damit vollkommen unmöglich, weil es hier einen Subnetz Mismatch gibt ! Erste Klasse IP Routing Grundschule...
Hier hast du vermutlich einen Kardinalsfehler bei der FritzBox Adressierung begangen und das auch noch übersehen ?!
Kann das sein ??
Sieh dir mal deinen FritzBox Screenshot ganz genau an !!
Irgendwas kann da mit dem lokalen Netzwerk nicht stimmen !!
Dort ist ein 16 Bit Prefix eingestellt obwohl du aber ein 24 Bit Prefix in allen anderen Subnetzen hast und diesen auch selber oben in deinen Topologie Zeichnung so vorgibst.
Dadurch "denkt" die FritzBox natürlich das alle deine VLAN Subnetze in einem einzigen IP Netz liegen. Logisch, denn das lokale LAN Netzwerk wird nur durch die ersten 2 Bytes in der Adresse dargestellt, der Rest sind alles Host- sprich Endgeräte Adressen für die FB.
Die FB kann also durch die falsche Subnetzmaske deine VLAN Netze gar nicht "erkennen" bzw. routen, denn das sind alles lokale LAN Endgeräte Adressen für sie. Folglich ist ein sauberes Routing im 192.168er Segment damit vollkommen unmöglich, weil es hier einen Subnetz Mismatch gibt ! Erste Klasse IP Routing Grundschule...
Hier hast du vermutlich einen Kardinalsfehler bei der FritzBox Adressierung begangen und das auch noch übersehen ?!
Kann das sein ??
Wie schon geschrieben... Das kann so niemals klappen.
Die FritzBox weiss natürlich nichts von einer weiteren Segmentierung. Sie geht davon aus das ihr lokales LAN eine 16 Bit Maske hat und somit Endgeräte Adressen von 192.168.0.0 bis .255.254. Das inkludiert natürlich alle deine VLANs.
Nichts passiert wäre hier wenn du die VLAN IP Adressen z.B. aus den anderen privaten Bereichen 172.16.0.0 /12 oder 10.0.0.0 /8 gewählt hättest ! Dann wäre alles wieder eindeutig gewesen was die IP Wegefindung anbetrifft !
Durch dieses falsche Subnetzmaske sind die .10.0, .11.0 und die .12.0 keine Netze sondern Endgeräte.
Sprich um eine Verbindung zu diesen Netzen aufzumachen müsste die FB erstmal erkennen das diese Endadressen in anderen IP Netzen liegen wenn sie Pakete für diese IP Netze hat.
Das kann sie aber nicht wegen der falschen Subnetzmaske !
Z.B. ein ICMP Echo Paket (Ping) aus dem 10er VLAN Netz was sie beantworten müsste wähnt sie wegen der falschen Subnetzmaske immer als lokalen Host an ihrem LAN Port. Hier zählt primär ihre LAN Port Maske und NICHT der Routing Eintrag !
Deshalb schickt sie ein ARP Paket als Broadcast (192.168.255.255) ins lokale LAN und fragt nach der Mac Adresse der IP .10.x. Diese Endgeräte IP gibt es nicht im lokalen LAN Segment und keiner antwortet dort. Deshalb verwirft sie nach einem Timeout das Paket und du siehst als Ergebnis einen nicht funktionierenden Ping.
Wäre die Maske richtig erkennt sie sofort das die Ziel IP in einem anderen Netzwerk liegt und ARPt dann direkt nach der Mac Adresse des Router der dann natürlich sofort antwortet und sie schickt dann das Paket dahin.
Das es mit lokalen Subnetze am lokalen Port dennoch klappt liegt daran das es auch von dort initiiert wurde. Im ARP Cache der FB liegt dann also als Absneder die Mac Adresse des VLAN 1 IP Interfaces des Cisco. Da die Kommunikation ja nur Mac Adress basierend ist schickt die FB es auch an die Mac Adresse zurück von der es gekommen ist ohne die IP zu beachten oder neu zu ARPen nach der Ziel IP. Deshalb kommt es für Laien zu dem komischen Verhalten das es lokal geht aber nicht wenn externe IPs im Spiel sind.
Also alles normales Verhalten im IP Routing.
Das hättest du übrigens auch alles mit deinem Ethernet Tool selber sehen können wenn das eine Paket Capture Funktion hat wie z.B. der kostenlose Wireshark.
Kleine Ursache große Wirkung also wenn man sich bei den richtigen Subnetzmasken vertut...
Nach den Ändern der Masken solltest du übrigens immer Router und Switch rebooten um den ARP Cache sicher zu löschen und nicht noch irgendwelche Side Effects zu triggern.
Case closed !
Die FritzBox weiss natürlich nichts von einer weiteren Segmentierung. Sie geht davon aus das ihr lokales LAN eine 16 Bit Maske hat und somit Endgeräte Adressen von 192.168.0.0 bis .255.254. Das inkludiert natürlich alle deine VLANs.
Nichts passiert wäre hier wenn du die VLAN IP Adressen z.B. aus den anderen privaten Bereichen 172.16.0.0 /12 oder 10.0.0.0 /8 gewählt hättest ! Dann wäre alles wieder eindeutig gewesen was die IP Wegefindung anbetrifft !
Durch dieses falsche Subnetzmaske sind die .10.0, .11.0 und die .12.0 keine Netze sondern Endgeräte.
Sprich um eine Verbindung zu diesen Netzen aufzumachen müsste die FB erstmal erkennen das diese Endadressen in anderen IP Netzen liegen wenn sie Pakete für diese IP Netze hat.
Das kann sie aber nicht wegen der falschen Subnetzmaske !
Z.B. ein ICMP Echo Paket (Ping) aus dem 10er VLAN Netz was sie beantworten müsste wähnt sie wegen der falschen Subnetzmaske immer als lokalen Host an ihrem LAN Port. Hier zählt primär ihre LAN Port Maske und NICHT der Routing Eintrag !
Deshalb schickt sie ein ARP Paket als Broadcast (192.168.255.255) ins lokale LAN und fragt nach der Mac Adresse der IP .10.x. Diese Endgeräte IP gibt es nicht im lokalen LAN Segment und keiner antwortet dort. Deshalb verwirft sie nach einem Timeout das Paket und du siehst als Ergebnis einen nicht funktionierenden Ping.
Wäre die Maske richtig erkennt sie sofort das die Ziel IP in einem anderen Netzwerk liegt und ARPt dann direkt nach der Mac Adresse des Router der dann natürlich sofort antwortet und sie schickt dann das Paket dahin.
Das es mit lokalen Subnetze am lokalen Port dennoch klappt liegt daran das es auch von dort initiiert wurde. Im ARP Cache der FB liegt dann also als Absneder die Mac Adresse des VLAN 1 IP Interfaces des Cisco. Da die Kommunikation ja nur Mac Adress basierend ist schickt die FB es auch an die Mac Adresse zurück von der es gekommen ist ohne die IP zu beachten oder neu zu ARPen nach der Ziel IP. Deshalb kommt es für Laien zu dem komischen Verhalten das es lokal geht aber nicht wenn externe IPs im Spiel sind.
Also alles normales Verhalten im IP Routing.
Das hättest du übrigens auch alles mit deinem Ethernet Tool selber sehen können wenn das eine Paket Capture Funktion hat wie z.B. der kostenlose Wireshark.
Kleine Ursache große Wirkung also wenn man sich bei den richtigen Subnetzmasken vertut...
Nach den Ändern der Masken solltest du übrigens immer Router und Switch rebooten um den ARP Cache sicher zu löschen und nicht noch irgendwelche Side Effects zu triggern.
Case closed !
Da diese Route aber nicht aktiv war. Dürfte sie auch keinen Einfluss haben.
Ich kenne die FB nicht so genau aber (bessere) Router zeigen in der Regel immer ihre Connected Interfaces, sprich also ihre lokalen Interfaces in der Routing Tabelle automatisch an. Hier mal ein Cisco Beispiel wo du es explizit siehst: Cisco#sh ip rou
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 10.99.1.254 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 10.99.1.254
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.99.1.0/24 is directly connected, Vlan99
L 10.99.1.222/32 is directly connected, Vlan99
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.7.0/24 is directly connected, Vlan1
L 172.16.7.1/32 is directly connected, Vlan1
Ich hatte ja die einzelnen VLANs geroutet und dort war korrekt 255.255.255.0 eingetragen. Siehe 2. screenshot
Das ist auch absolut korrekt, nur hier dann vollkommen irrelevant, weil das Gateway (Cisco) im Transfer Netz durch die völlig falsche Subnetzmaske technisch unereichbar für die FB ist. Da helfen dann auch noch so richtige Routen nicht. Der falsche 16er Prefix bringt dich dann in die Falle.Ein schnelles Testsetup hier mit einer ollen FritzBox 6240 funktioniert mit exakt deinen VLAN Settings, wie zu erwarten, natürlich absolut fehlerfrei.
Irgendwo ist da also noch ein PEBKAC Problem.
In der Tat mal alles neu machen, sprich Werks Reset auf dem Cisco, dann erstmal nur ein VLAN (10) einrichten, Ports zuweisen und erstmal nur mit der Minimal Konfig testen.
Dazu gehört natürlich auch das du sowohl Cisco als auch FB auf das aktuellste Firmware Image flashen solltest. Besonders den Cisco:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/ci ...
Auch solltest du die "nach Hause Telefonier" Funktion des Ciscos immer deaktivieren:
Das es bei dir generell funktioniert hast du ja an den 5 Minuten gesehen wo es klappte. Irgendwo hast du da also noch einen Konfig Fehler.
Btw. das Pocket Ethernet Teil ist ein neckisches Tool !