We kennen allemaal het grote voordeel van het configureren van Portfast, een poort geconfigureerd met Portfast zal onmiddellijk beginnen met het verzenden van gegevens in de ‘forwarding’ status waarbij de andere spanning-tree toestanden worden omzeild. Dit is zeker een geweldige eigenschap om geconfigureerd te hebben op uw downstream poorten die verbinden met uw eindgebruikers werkstation of uw servers. Er is ook een andere goede reden om Portfast te configureren op uw client edge poorten, die niet zo wijd en zijd bekend is.
Wanneer een switchport omhoog of omlaag gaat genereert de switch een TCN (Topology Change Notification) pakket en zendt dit TCN pakket naar de root bridge, de root bridge antwoordt dan terug met een TCA (Topology Change Acknowledge) pakket, simpelweg om het TCN pakket te bevestigen. De root bridge zendt dan een andere BPDU met het TC (Topology Change) bit gezet naar elke switch binnen het Spanning-Tree domein. Wanneer de andere schakelaars dit TC gemarkeerde pakket ontvangen, wordt de verouderingstijd van elke entry in de CAM tabel (ook bekend als de MAC adres tabel) teruggezet naar 15 seconden, wat ertoe kan leiden dat de schakelaar zijn CAM tabel opnieuw moet opbouwen als de entries beginnen te verouderen. Afhankelijk van de grootte van je layer 2 netwerk kan dit veel bronnen op je switches verspillen. En dan hebben we het nog niet eens over de onnodige overhead, want er worden BPDU’s verstuurd met de TCN, TCA, en TC vlaggen apart ingesteld. Hou er ook rekening mee dat als CAM-tabel entries beginnen te verlopen, dit onnodig ARP verkeer kan veroorzaken voor extra informatie die de switch al had.
Nu zullen we hier eens wat van bekijken:
Hier is een poort configuratie, zonder portfast:
Wanneer we fa1/0/5 loskoppelen en weer aansluiten, krijgen we de volgende log output:
In dat vorige screenshot, zul je zien dat het eerste wat er gebeurt is dat spanning-tree die TCN BPDU verstuurt, en de interface wordt gemarkeerd als down. Ik sluit dan de kabel opnieuw aan op fa1/0/5 en je ziet de poort door de spanning-tree stadia gaan, van luisteren naar leren en tenslotte naar doorsturen. (Extra credit, welke versie van spanning heb ik draaien?) Iets om ook op te merken is het feit dat een ander TCN BPDU pakket wordt verzonden als de poort terug in de doorstuur status wordt gezet.
Nu configureren we Portfast op deze switchport:
Nu weer deze poort loskoppelen en weer aansluiten:
Er is hier veel minder aan de hand vergeleken met onze vorige ervaring, het belangrijkste hier is om op te merken dat er geen TCN wordt verzonden, niet wanneer de poort is gemarkeerd als down, noch wanneer de poort is gemarkeerd als up (of forwarding). De enige STP events die worden geregistreerd is het feit dat port fa1/0/5 direct naar de forwarding state gaat vanuit de blocking state, waarbij de listening state en de learning state worden omzeild, zodat de client nog sneller het netwerk kan gaan gebruiken.
Nou, laten we even achterover leunen in onze stoel en hier een minuutje over nadenken. Een TCN wordt verzonden wanneer de switchport down gaat en opnieuw wanneer de switchport in de forwarding status komt. Dus wanneer een eindgebruiker besluit zijn PC opnieuw op te starten, wanneer hij zijn laptop loskoppelt om naar een vergadering te gaan, weer aan zijn bureau vastkoppelt, of wanneer hij besluit zijn bureau opnieuw in te richten en zijn PC loskoppelt, wordt er een TCN verzonden waardoor de switches de verouderingstimers van entries in de MAC adres tabel verlagen. Dat kan een hoop onnodig resource gebruik zijn.
P.S. Vergeet niet om BPDU Guard in te schakelen als je portfast inschakelt! Portfast is een geweldig hulpmiddel, maar omdat het de luister- en leerstaten overslaat, loop je de kans dat er laag 2 switching loops ontstaan als je meerdere switches met elkaar verbindt of als je gebruikers eenvoudige switches/hubs op hun bureau aansluiten. BPDU Guard zal een poort in een Err-Disabled status plaatsen als het een BPDU ontvangt op die poort.