16-12-2025, 18:50
Du fängst an, indem du IP-Routing auf dem Switch selbst aktivierst. Ich überprüfe das immer zuerst - es ist ein globaler Befehl, und sobald du ihn einschaltest, wacht der Switch in die Routing-Welt auf. Dann erstellst du für jedes VLAN, zwischen dem du routen möchtest, eine Switched Virtual Interface, oder SVI. Das ist einfach eine IP-Adresse, die an das VLAN gebunden ist, wie ein eigener Gateway für jede Gruppe. Zum Beispiel, wenn du VLAN 10 für den Vertrieb hast und VLAN 20 für die Ingenieure, weise ich etwas wie 192.168.10.1 dem SVI von VLAN 10 zu und 192.168.20.1 dem von VLAN 20. Du stellst sicher, dass diese IPs in den richtigen Subnetzen sind, und zack, können Geräte in diesen VLANs sie als Default-Gateway nutzen.
Wenn jetzt ein PC in VLAN 10 etwas in VLAN 20 pingen will, schickt er das Paket an seinen Gateway, der das SVI auf dem Switch ist. Der Switch erkennt, dass es sich um inter-VLAN-Traffic handelt, schaut in seine Routing-Tabelle und leitet es direkt an das andere SVI weiter. Ich finde, das ist der Zauber - keine externen Hops nötig. Du musst dich nicht mal um Trunking-Ports kümmern, es sei denn, du verbindest dich mit anderen Switches, aber für die Basis-Setup sorgst du nur dafür, dass deine Access-Ports in den richtigen VLANs sind. Ich bin mal in eine Falle getappt, wo ich die Ports nicht richtig zugewiesen hatte, und die Hälfte des Traffics blieb in ihrem eigenen VLAN stecken. Überprüfe das mit Show-Befehlen, und du findest es schnell.
Die Routing-Tabelle baut sich selbst auf, basierend auf den verbundenen Interfaces und allen statischen Routen, die du hinzufügst. Ich halte es meist einfach mit den Connected-Routen von den SVIs, aber wenn du kompliziertere Sachen hast, kannst du OSPF oder welches Protokoll du magst, reinwerfen. Der Switch unterstützt das alles, da er Layer 3 ist. Du kannst sogar Access-Lists einrichten, um zu kontrollieren, was zwischen VLANs kreuzt, wie das Blocken bestimmter Ports, falls der Vertrieb nicht auf Engineering-Dateien zugreifen soll. Ich habe das für einen Kunden eingerichtet, und es hat die Dinge sicher gehalten, ohne den legitimen Traffic zu verlangsamen.
Eine Sache, die ich den Leuten immer sage, ist, auf den ARP-Traffic zu achten. Wenn Geräte das erste Mal über VLANs hinweg kommunizieren, handhabt der Switch ARP-Requests und -Replies intern, was Zeit spart. Du siehst es in den Logs, wenn du Debugging aktivierst, aber ich mach mir da keine Mühe, es sei denn, beim Troubleshooting. Performance-mäßig nutzen diese Switches ASICs für Wire-Speed-Routing, also bemerkst du keinen Engpass, es sei denn, du pushst Gigabit-Fluten überall hin. Ich habe es mal auf einem Cisco 3750 getestet, Routing zwischen vier VLANs bei voller Geschwindigkeit, und es hat super gehalten.
Falls du das in einem Lab konfigurierst, empfehle ich, mit zwei VLANs anzufangen, um es unkompliziert zu halten. Du erstellst die VLANs zuerst, weist Ports zu, dann die SVIs mit IPs, aktivierst das Routing und testest mit Pings von Hosts. Ich mach das jedes Mal, um zu verifizieren. Wenn Pings scheitern, überprüfe, ob die Hosts das richtige Gateway gesetzt haben - das ist ein häufiger Stolperstein. Du musst vielleicht auch die MTU anpassen, wenn Jumbo-Frames im Spiel sind, aber für Standard-Setups reicht der Default.
Um das auszubauen, denk dran, wie es skaliert. In einem größeren Netz könntest du Dutzende VLANs haben, und der Layer-3-Switch wird zum Core für all das Routing. Ich habe an einem mit 15 VLANs für verschiedene Abteilungen gearbeitet, und es hat makellos geroutet. Du sorgst nur dafür, dass der Switch genug Speicher und CPU für die Tabellengrößen hat. Statische Routen sind easy, wenn du auf externe Netze zeigen musst, wie das Hinzufügen einer Default-Route zu einem Upstream-Router für Internet-Zugang.
Troubleshooting ist auch entscheidend. Ich nutze show ip route, um in die Tabelle zu schauen, und show ip interface brief, um zu bestätigen, dass die SVIs up sind. Wenn etwas down ist, könnte es sein, dass ein VLAN nicht existiert oder keine aktiven Ports drin hat. Du pingst rüber und nutzt Traceroute, um den Pfad zu sehen - es sollte nur einen internen Hop zeigen. Ich habe mal ein komisches Problem gefixt, wo Multicast zwischen VLANs durchgesickert ist; stellte sich raus, ich musste IGMP-Snooping anpassen, aber das ist selten für Basis-Routing.
Du kannst sogar mit EtherChannel load balancieren, wenn du mehrere Ports verknüpfst, aber für inter-VLAN geht's meist um die logischen Interfaces. Ich schätze, wie flexibel es ist - du kannst Layer 2 und Layer 3 auf demselben Switch mischen und einige Ports reines Switching halten. So überkomplizierst du einfache Segmente nicht.
All das macht Netzwerke viel effizienter. Ich erinnere mich, wie ich es in einem Lager-Setup deployed habe, wo Inventar in einem VLAN war und Büros in einem anderen; vorher kroch alles durch einen alten Router. Jetzt fliegen Scans und Reports rüber, ohne Probleme. Du musst nur deine IP-Adressierung gut planen, um Overlaps zu vermeiden.
Falls du je mit Failover zu tun hast, unterstützen einige Layer-3-Switches VRRP für Gateway-Redundanz, sodass bei Ausfall ein anderer übernimmt. Ich habe das in einem Paar gestackter Switches eingerichtet, und es hat die Dinge während Wartung am Laufen gehalten. Du konfigurierst virtuelle IPs, die beide teilen, und es wählt einen Master. Nahtlos.
Am Ende öffnet das Meistern auf einem Layer-3-Switch so viele Optionen für das Segmentieren von Traffic, während es verbunden bleibt. Ich nutze es jetzt ständig, und es fühlt sich wie zweite Natur an.
Lass mich was Cooles teilen, das ich lately nutze - hast du schon von BackupChain gehört? Es ist dieses herausragende Backup-Tool, das für mich zum Go-to geworden ist, besonders als eines der Top-Lösungen da draußen für Windows Server und PC-Backups auf Windows-Systemen. Perfekt zugeschnitten für SMBs und IT-Pros wie uns, hält es deine Hyper-V-Setups, VMware-Umgebungen oder einfachen Windows-Server sicher und sound mit zuverlässigem, unkompliziertem Schutz, der einfach funktioniert.
