20
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 544585
Url: https://administrator.de/contentid/544585
Printed on: April 23, 2024 at 15:04 o'clock
20 Comments
Latest comment
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
Der Switch ist ein Multilayerswitch und der kann Routen, er Router ja schon innerhalb der VLANs.
Der einzige Ort an dem ich eine RouterIP als GW im Switsch eintragen kann (hab zumindest nix weiter gefunden) ist unter Netzwerkpool. Da habe ich die VlanIP 192.168.10.1 als RouterIP eingetragen und als DNS-Server die Fritzbox. Jedoch ohne Erfolg.
Siehe Bilder
VG Robert
Der einzige Ort an dem ich eine RouterIP als GW im Switsch eintragen kann (hab zumindest nix weiter gefunden) ist unter Netzwerkpool. Da habe ich die VlanIP 192.168.10.1 als RouterIP eingetragen und als DNS-Server die Fritzbox. Jedoch ohne Erfolg.
Siehe Bilder
VG Robert
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.
Also anhand der Screenshots. Direkt unter dem Bild der Routen auf der Fritzbox, da sieht man doch das ich die Route zum Router eingetragen habe. Oder ist da etwas falsch? Aber irgendwie schaut mir das genau so aus wie auf deinem Bild, bis auf die angepasste IP natürlich
Diese ganzen Anleitungen habe ich mir mehrfach angeschaut. Ich komm aber echt nicht weiter
Und wenn ich das was du schreibst richtig lese, dann habe ich es ja garnicht so falsch gemacht. Denn ich habe ja wie oben geschrieben die IP des VLans eingetragen und nicht etwa die des routers. Also genau so wie du es geschrieben hast habe ich es vorher beschrieben und durchgeführt. Auch, weil ich mir eben diverse forenbeiträge durchgelesen habe.
Nichts desto trotz muss mir irgendetwas entgangen sein...
Diese ganzen Anleitungen habe ich mir mehrfach angeschaut. Ich komm aber echt nicht weiter
Und wenn ich das was du schreibst richtig lese, dann habe ich es ja garnicht so falsch gemacht. Denn ich habe ja wie oben geschrieben die IP des VLans eingetragen und nicht etwa die des routers. Also genau so wie du es geschrieben hast habe ich es vorher beschrieben und durchgeführt. Auch, weil ich mir eben diverse forenbeiträge durchgelesen habe.
Nichts desto trotz muss mir irgendetwas entgangen sein...
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
Danke erstmal für die Bestätigung das ich mich doch nicht zu doof angestellt habe. Der pockethernet ist ein netzwerktester. Der ist per Ethernet am Port angeschlossen und wird vom Tablett über Bluetooth bedient. Somit kann ich vorm Kind beschützt ohne lange Kabelbrücken testen 😂.
Der pockethernet hatte eine 192.168.10.100 bezogen. Also sollte er an Port 2 im VLAN 10 gehangen haben.
Ping auf 11.1 ist ein VLan Port an dem ein Client hing. (Hier hatte ich schon mitbekommen das man Ports nur anpingen kann wenn sie aktiv sind 😉)
Die systematische fehlersuche werde ich dann durchexerzieren und dokumentieren wenn der Zwerg wieder im Bett ist. Wollt mich nur kurz mit Dank und Antwort auf deine Frage zurück melden.
VG und ein schönes Wochenende
Robert
Der pockethernet hatte eine 192.168.10.100 bezogen. Also sollte er an Port 2 im VLAN 10 gehangen haben.
Ping auf 11.1 ist ein VLan Port an dem ein Client hing. (Hier hatte ich schon mitbekommen das man Ports nur anpingen kann wenn sie aktiv sind 😉)
Die systematische fehlersuche werde ich dann durchexerzieren und dokumentieren wenn der Zwerg wieder im Bett ist. Wollt mich nur kurz mit Dank und Antwort auf deine Frage zurück melden.
VG und ein schönes Wochenende
Robert
So, habe jetzt nochmal alle Ports/VLANs durchgepingt.
VLAN 11 und 12 erhalten keine DNS Server mitgeteilt, aber das liegt daran das dies noch nicht eingetragen ist. (Wollte den Unterschied erkennen)
Alle weiteren Konfigurationen sind wie in den screenshots siehe oben.
VLAN 11 und 12 erhalten keine DNS Server mitgeteilt, aber das liegt daran das dies noch nicht eingetragen ist. (Wollte den Unterschied erkennen)
Alle weiteren Konfigurationen sind wie in den screenshots siehe oben.
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 ??
Mit der Falschen Subnetmaske hast du natürlich Recht. Ich habe diese angepasst und den Eintrag aktiviert. Der war ja inaktiv. Jetzt kommt der Ping von 8.8.8.8 wieder zurück. Das freut mich natürlich. Trotzdem schwebt ein großes Fragezeichen über mir!
Die unteren Routen die ja das Subnet explizit nennen, hatte ich ja korrekt eingetragen. Warum hat die Fritzbox nicht mit denen geroutet? Denn das waren die 3 einzig aktiven Routen
Die unteren Routen die ja das Subnet explizit nennen, hatte ich ja korrekt eingetragen. Warum hat die Fritzbox nicht mit denen geroutet? Denn das waren die 3 einzig aktiven Routen
Ich muss meinen letzten Post revidieren. Ich hatte exakt eine Ping Antwort.
Und jetzt nicht mehr.
Wieder wie vorhin.
Alles im LAN geht.
Nur nach aussen nicht.
Auch vom Switch selbst nicht. Hab grad die PING Funktion im Switch gefunden ;) .
Und jetzt nicht mehr.
Wieder wie vorhin.
Alles im LAN geht.
Nur nach aussen nicht.
Auch vom Switch selbst nicht. Hab grad die PING Funktion im Switch gefunden ;) .
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 !
Ja das mit der Maske hatte ich übersehen und das ich bei 255.255.0.0 einen größeren Hostanteil habe ist mir bekannt. Das ist mir schlicht weg durch die Finger gerutscht. Da diese Route aber nicht aktiv war. Dürfte sie auch keinen Einfluss haben. Ich hatte ja die einzelnen VLANs geroutet und dort war korrekt 255.255.255.0 eingetragen. Siehe 2. screenshot 1. Post.
Und auch jetzt klappt es nicht. Wenn ich nur die erste (korrigierte) Route aktiviere geht es nicht und alle vier Routen gehen auch nicht. Und nur die unteren 3 Routen funktionieren nach wie vor nicht
Ich blicke echt langsam nicht mehr durch und werde wohl heute Abend wenn keiner im Netz ist mal komplett bei null beginnen.
Packet capture ist mit dem pockethernet im geringen Umfang möglich. Nützt mir nur (noch) wenig da ich gerade am Anfang stehe. Ich hatte schon überlegt ob und wo ich sinnvoll den Laptop mit Wireshark platziere. Aber wenn ich dann nicht weis nach was ich da suchen muss wäre das nur Spielerei die Sau technisch aussieht aber nicht zielführend ist 😉
Und auch jetzt klappt es nicht. Wenn ich nur die erste (korrigierte) Route aktiviere geht es nicht und alle vier Routen gehen auch nicht. Und nur die unteren 3 Routen funktionieren nach wie vor nicht
Ich blicke echt langsam nicht mehr durch und werde wohl heute Abend wenn keiner im Netz ist mal komplett bei null beginnen.
Packet capture ist mit dem pockethernet im geringen Umfang möglich. Nützt mir nur (noch) wenig da ich gerade am Anfang stehe. Ich hatte schon überlegt ob und wo ich sinnvoll den Laptop mit Wireshark platziere. Aber wenn ich dann nicht weis nach was ich da suchen muss wäre das nur Spielerei die Sau technisch aussieht aber nicht zielführend ist 😉
Trotzdem danke für deine Erklärung. Das klingt schon mal nachvollziehbar
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:
Btw. das Pocket Ethernet Teil ist ein neckisches Tool !
Ich danke dir vielmals für deine Geduld und Hilfe. Ich werde mir heut Abend nochmal die Zeit nehmen von vorn aufzubauen. Und dann hoffentlich diesen Thread hier abschließend mit einer Erfolgsmeldung beenden können 😉.
Ja der Pockethernet ist für daheim recht praktisch. Oder auch für kleinere Umgebungen. Etwas sperrig in der Bedienung aber dafür recht günstig im Vergleich zu linksprinter und co
Ich habe die App hier auf dem Tablet. Und am Tablet zusätzlich noch einen Ethernetadapter per usb OTG. Somit habe ich zwei „Clients“ die ich gegeneinander testen kann.
Auch während der Verkablung im Haus war der kleine blaue Kasten immer mit dabei.
Wiremap
Tongenerator zum Kabel finden
Usw.
Bin mir nur bei der Beurteilung der Kabel über TDR im unklaren was ich davon halten soll. Da hierzu kaum Dokumentation besteht und ich daher kaum nutzen daraus ziehen kann, außer die ungefähre Kabellänge. Die kommt in etwa hin.
VG
Robert
Ja der Pockethernet ist für daheim recht praktisch. Oder auch für kleinere Umgebungen. Etwas sperrig in der Bedienung aber dafür recht günstig im Vergleich zu linksprinter und co
Ich habe die App hier auf dem Tablet. Und am Tablet zusätzlich noch einen Ethernetadapter per usb OTG. Somit habe ich zwei „Clients“ die ich gegeneinander testen kann.
Auch während der Verkablung im Haus war der kleine blaue Kasten immer mit dabei.
Wiremap
Tongenerator zum Kabel finden
Usw.
Bin mir nur bei der Beurteilung der Kabel über TDR im unklaren was ich davon halten soll. Da hierzu kaum Dokumentation besteht und ich daher kaum nutzen daraus ziehen kann, außer die ungefähre Kabellänge. Die kommt in etwa hin.
VG
Robert
Gibt es den außer direkt über deren Webseite noch von anderen Quellen ?
Ich habe den auch nur auf der Webseite gesehen und von dort problemlos bestellt
Ich bin am Verzweifeln, ich habe es jetzt nochmal von vorn versucht. Auf der Fritzbox das Gäste LAN ausgeschaltet (um hier Routing Fehler auszuschließen) und mich für den Switch im 172.20.x.x Netz bedient. Dementsprechend auch die rückroute auf der Fritzbox für 172.20.10.0/24 auf 192.168.1.254 gesetzt. Im Switch nur 1 VLAN erstellt. Und die defaultroute 0.0.0.0 0.0.0.0 zu 192.168.1.1 gesetzt. Ebenso einen Port. Zu VLAN 10 U zugewiesen.
Gleiches Verhalten wie gestern...
Kann es sein das sich der SG350 doch ein wenig anders verhält bzw anders zu Konfigurieren ist wie der SG300 ? Beim 300er muss man ja den L3 Betrieb aktivieren beim 350er ist von Haus aus L3 aktiv. Zumindest hab ich das jetzt immer so gelesen. Allerdings habe ich jetzt noch bei den VLAN Interface Settings gesehen das die Ports dort auf L2 Stehen. Wenn ich meinen Port dort auf L3 stelle, wird der VLAN Interface State unter VLAN Setting aber disabled obwohl ein Client dran hängt. Was hat das zu bedeuten?
Gleiches Verhalten wie gestern...
Kann es sein das sich der SG350 doch ein wenig anders verhält bzw anders zu Konfigurieren ist wie der SG300 ? Beim 300er muss man ja den L3 Betrieb aktivieren beim 350er ist von Haus aus L3 aktiv. Zumindest hab ich das jetzt immer so gelesen. Allerdings habe ich jetzt noch bei den VLAN Interface Settings gesehen das die Ports dort auf L2 Stehen. Wenn ich meinen Port dort auf L3 stelle, wird der VLAN Interface State unter VLAN Setting aber disabled obwohl ein Client dran hängt. Was hat das zu bedeuten?
Die Verfluchte Fritzbox wars!!!!
Die hat das Routing scheinbar ignoriert.
ich habe sie Komplett Resettet und ohne einspielen eines Backups wieder aufs nötigste hoch gezogen und siehe da!
jetzt klappt das alles ohne Probleme.
Da bin ich froh das der Fehler nicht direkt auf Layer 8 lag ;)
Danke aqui
Die hat das Routing scheinbar ignoriert.
ich habe sie Komplett Resettet und ohne einspielen eines Backups wieder aufs nötigste hoch gezogen und siehe da!
jetzt klappt das alles ohne Probleme.
Da bin ich froh das der Fehler nicht direkt auf Layer 8 lag ;)
Danke aqui
Immer gerne !
