Vi känner alla till den stora fördelen med att konfigurera Portfast, en port som är konfigurerad med Portfast kommer omedelbart att börja överföra data i ”forwarding”-tillståndet och kringgå de andra spanning-tree-tillstånden. Detta är verkligen en bra funktion att ha konfigurerad på dina nedströms-portar som ansluter till slutanvändarens arbetsstation eller dina servrar. Det finns också en annan bra anledning att konfigurera Portfast på dina klientportar, som inte är så allmänt känd.
När en switchport går upp eller ner genererar switchen ett TCN-paket (Topology Change Notification) och skickar detta TCN-paket till rotbryggan, rotbryggan svarar sedan tillbaka med ett TCA-paket (Topology Change Acknowledge), helt enkelt för att bekräfta TCN-paketet. Rotbryggan sänder sedan en annan BPDU med TC-biten (Topology Change) inställd till alla växlar inom Spanning-Tree-domänen. När de andra växlarna tar emot detta TC-märkta paket återställs åldringstiden för varje post i CAM-tabellen (även känd som MAC-adresstabellen) till 15 sekunder, vilket kan leda till att växeln måste bygga om sin CAM-tabell om posterna börjar åldras. Beroende på storleken på ditt lager 2-nätverk kan detta slösa mycket resurser på dina växlar. För att inte tala om att det orsakar en hel del onödig trafiköverskott, eftersom vi har en uppsättning BPDU:er som sänds med TCN-, TCA- och TC-flaggorna individuellt inställda. Tänk också på att om CAM-tabellposter börjar löpa ut kan detta orsaka onödig ARP-trafik för ytterligare information som växeln redan hade.
Nu ska vi granska en del av detta:
Här är en portkonfiguration, utan portfast:
När vi kopplar bort och återansluter fa1/0/5 får vi följande loggutgång:
I den tidigare skärmdumpen märker du att det första som händer är att spanning-tree sänder ut den där TCN BPDU:n och att gränssnittet är markerat som nere. Jag ansluter sedan kabeln till fa1/0/5 igen och du ser hur porten går igenom spanning-tree-stegen, från att lyssna till att lära sig och slutligen till att vidarebefordra. (Extra poäng: vilken version av Spanning är det jag kör?) Något som också är värt att notera är det faktum att ett annat TCN BPDU-paket sänds när porten återgår till forwarding-tillståndet.
Nu konfigurerar vi Portfast på den här switchporten:
Nu igen kopplar vi bort och återkopplar den här porten igen:
Det händer mycket mindre här jämfört med vår tidigare erfarenhet, det viktiga här är att märka att det inte skickas några TCN, varken när porten markeras som nere eller när porten markeras som uppe (eller vidarebefordrande). De enda STP-händelser som registreras är det faktum att port fa1/0/5 går direkt till forwarding-tillståndet från blockeringstillståndet och förbigår lyssningstillståndet och inlärningstillståndet, vilket gör det möjligt för klienten att börja använda nätverket ännu snabbare.
Nu ska vi luta oss tillbaka i stolen en stund och tänka på det här en stund. En TCN skickas ut när switchporten går ner och igen när switchporten går in i forwarding state. Så när en slutanvändare bestämmer sig för att starta om sin dator, när han eller hon tar bort sin bärbara dator för att gå till ett möte och åter kopplar in sig vid sitt skrivbord igen, eller när han eller hon bestämmer sig för att organisera om sitt skrivbord och koppla bort sin dator, kommer en TCN att sändas, vilket gör att växlarna sänker åldringstimern för posterna i MAC-adresstabellen. Det kan bli mycket onödigt resursutnyttjande.
P.S. Kom ihåg att aktivera BPDU Guard när du aktiverar portfast! Portfast är ett utmärkt verktyg, men eftersom det hoppar över lyssnings- och inlärningstillstånden finns det en risk för att skapa skikt 2-switching-slingor om du korsansluter flera switchar eller om dina användare börjar ansluta enkla switchar/hubbar vid sina skrivbord. BPDU Guard placerar en port i en Err-Disabled-status om den tar emot en BPDU på den porten.