flush mac adres ?

[Viktor Novotný]

jinak sh span det :


Port 11 (FastEthernet0/11) of VLAN0001 is designated forwarding
Port path cost 19, Port priority 128, Port Identifier 128.11.
Designated root has priority 32769, address 001c.0fae.ea80
Designated bridge has priority 32769, address 001c.0fae.ea80
Designated port id is 128.11, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 7
Link type is point-to-point by default
Bpdu filter is enabled
BPDU: sent 38102, received 34

[Viktor Novotný]

jste ta 24ka ...


Port 24 (FastEthernet0/24) of VLAN0001 is designated forwarding
Port path cost 19, Port priority 128, Port Identifier 128.24.
Designated root has priority 32769, address 001c.0fae.ea80
Designated bridge has priority 32769, address 001c.0fae.ea80
Designated port id is 128.24, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
The port is in the portfast mode
Link type is point-to-point by default
Bpdu filter is enabled
BPDU: sent 0, received 0

cele je to myslene tak, ze vzdy ten sam switch ma byt jen svuj spaning root .. proste to nemelo vubec jit nahoru ... ten spaning tam mam jen kvuli nechtenym smyckam a porucham radii ... ale jinak nema delat vubec strom

[Viktor Novotný]

jeste konf portu :


interface FastEthernet0/11
switchport mode access
switchport nonegotiate
switchport protected
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard disable
!

interface FastEthernet0/24
switchport mode access
switchport nonegotiate
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard disable
!

[Viktor Novotný]

jeste doplnim, vzhledem k tomu, ze to nemaze ty macy jen na switchich se spaningem, ale i na switchich kde je span uplne vypnuty ... tak to nebude asi nejak uplne otazka spaningu, spis nejakeho poslaneho bordelu ... jenze co muze takovy uzivatel poslat za shit ?

[Dalibor Toman]

1) ze je filtering BPDUcek zapnuty je videt IMHO az v 'sh span vlan xy detail'
2) nemas na tom uplinku jeste 'spanning tree portfast'? (pokud je to access port)

[Majklik]

Na tom portu 11 jsi tne bpdufilter enable dával až dodatečně? Protože pak uniká, proč je tam BPDU: sent 38102. A je vidět, že z toho portu nějaké BPDU přišly 34 a bylo změn stavu do forwardu 7x, takže při tom mohlo dojít k fast agingu MAC tabulky. Nicméně, pokud to mezi switchi blokuješ vzájemně, tak by to mělo vyčistit od tohoto jen ten jeden switch.
Nemáš volbu "spanning-tree bpdufilter enable" uvedenou jako globální? Globálně povolený bpdufilter dělá něco trochu jiného, než uvedený vysloveně na portu (bpduguard globální zakáže odesílání BPDU na portfast portech, ale když se bpdu na takovém portu přijme, tak přejde normálně do klasickéo stp režimu, proti tomu bpdiuguard uvedený na portu blokuje příjem/odesílání bpdu portem).

[Dalibor Toman]

jeste doplnim, vzhledem k tomu, ze to nemaze ty macy jen na switchich se spaningem, ale i na switchich kde je span uplne vypnuty ... tak to nebude asi nejak uplne otazka spaningu, spis nejakeho poslaneho bordelu ... jenze co muze takovy uzivatel poslat za shit ?

pokud pominu nejakou chybku ve switchi (a pokud nejsou switche stejne pak se pravdepobnost neceho takoveho blizi nule) pak muze 'uzivatel' ovlivnit MAC tabulku jen neprimo. Tj pokusi se ji zaplnit vygenerovanymi MACkami. Ale to by asi bylo videt na grafu poctu packetu. A zalezi na tom odkud by ten tok sel. Pokud neucpe konektivitu k normalnim legalnim MACkam, tak jim nezabrani aby se ozivovaly v MAC tabulce. Zaplneni MAC tabulky by switch urcite logoval.

Kdyby se to stalo me tak bych udelal tohle:
1) kontrola zda nedoslo k packetove bource = zkouknout grafy vsech non-unicast packetu na switchi pripadne na okolnich switchihc/zarizenich. Jakmile uvidim odchozi non-unicasty ve zvysene mire je to jasne. Pokud se najde port kde graf ukazuje prichozi non-unicasty jdu po nem dal. Po identifikovani problemu nasleduje kontrola 'storm-control' konfigu nas switchich/portech. Pokud je to v okruhu vyplati se nastavit UDLD do aggresive modu na prislusnych portech
2) kontrola logu switche. Pokud uvidim nejaky hlasky z RSTP snazim se zjistit co to bylo a co bylo pricinou.

Zapni ten debug na spanning-tree a az to nastane priste budes mit alespon jistotu, ze to tim STP nebylo. V tom debug logu jsou fakt veci, ktery jinak neuvidis. Muze byt, ze zdroj problemu je uplne jinde nez myslis - treba switche ztraci konektivitu na root bridge atd

[Majklik]

Zapni ten debug na spanning-tree a az to nastane priste budes mit alespon jistotu, ze to tim STP nebylo. V tom debug logu jsou fakt veci, ktery jinak neuvidis. Muze byt, ze zdroj problemu je uplne jinde nez myslis - treba switche ztraci konektivitu na root bridge atd

Já si tkaé myslím, že vysvětlením může být, že mu padá port mezi switchi. Když padne port mezi switchi, flushnou se mac adresy naučené na tom portu, pokud padne uplink port přes který vidím většinu sítě, tak mac tabulka se pročistí důkladně.

[Viktor Novotný]

1) ze je filtering BPDUcek zapnuty je videt IMHO az v 'sh span vlan xy detail'
2) nemas na tom uplinku jeste 'spanning tree portfast'? (pokud je to access port)

mam " spanning-tree portfast "

[Viktor Novotný]

Na tom portu 11 jsi tne bpdufilter enable dával až dodatečně? Protože pak uniká, proč je tam BPDU: sent 38102. A je vidět, že z toho portu nějaké BPDU přišly 34 a bylo změn stavu do forwardu 7x, takže při tom mohlo dojít k fast agingu MAC tabulky. Nicméně, pokud to mezi switchi blokuješ vzájemně, tak by to mělo vyčistit od tohoto jen ten jeden switch.
Nemáš volbu "spanning-tree bpdufilter enable" uvedenou jako globální? Globálně povolený bpdufilter dělá něco trochu jiného, než uvedený vysloveně na portu (bpduguard globální zakáže odesílání BPDU na portfast portech, ale když se bpdu na takovém portu přijme, tak přejde normálně do klasickéo stp režimu, proti tomu bpdiuguard uvedený na portu blokuje příjem/odesílání bpdu portem).

ano dodatecne, na uplinku 24ce byl od nasazeni ten filtering ...
globalne to nemam, mam jen na portech - vicemene vzdy uplink a jen na tom 11tem to mam protoze to delalo prave problem, ale asi to neresi co bych chtel

[Viktor Novotný]

Zapni ten debug na spanning-tree a az to nastane priste budes mit alespon jistotu, ze to tim STP nebylo. V tom debug logu jsou fakt veci, ktery jinak neuvidis. Muze byt, ze zdroj problemu je uplne jinde nez myslis - treba switche ztraci konektivitu na root bridge atd

Já si tkaé myslím, že vysvětlením může být, že mu padá port mezi switchi. Když padne port mezi switchi, flushnou se mac adresy naučené na tom portu, pokud padne uplink port přes který vidím většinu sítě, tak mac tabulka se pročistí důkladně.

kdyby to tak bylo, procisti se od vrchu tedy na vsech vetvich ... ne od spoda .. jen z jedne vetve a na spolecnych switchich ... spis to bude nejaky problem s tim spaningem ... jak psal o par prispevku vyse " spanning-tree portfast " ten mam na uplinku ... on prebije filter ?

[Majklik]

Pokud máš všechny switche od sebe na úrovni xSTP izolovány, tak pád linky vyvola flushnutí jen MAC tabulek v těch dvou switchích, které ta padlá linka propojuje.
U tebe možná půjde i o to, zda ty další switche jsou opravdu od sebe odizolované na úrovni xSTP nebo ne. A pak jestli chápu, tka máš stále mix STP a RSTP switchů, pak se některé věci mění.

Dle toho výpisu je na tom uplinku 24 BPDU zastaveno. A teď půjde i o to, jak je ten port definován v nadřazeném switchi. Pokud ze strany toho downlinku směrem dolů je ten port definován jako edge, tak jeho zacvičení down/up se nepropaguje jako změna topologie dál. Pokud ten downlink port není edge, tak jeho up event vyvolá poslání TC dál u RSTP s příslušným okamžitým flushnutím mac tabulek (pokud by switch nebyl v RSTP, ale starším STP, tak se TC posílá při down i up eventu a vvolává to zkrácení vyhnívání mac tabulek na 15 sec).

Takže pokud mám 3 switche za sebou, 1. a 2. se spolu baví pomocí xSTP a 2. s 3. nikoliv, tak pokud padne linka mezi 2. a 3. switchem a tato linka nebude v 2. switchi jako edge, tak dojde k flushnutí MAC ve všech třech switchích. Pokud jako edge bude, flush se má udělat jen částečně na switchích 2 a 3.

Pozapínej ten debug na těch switchích a uvidí se pak jasně, zda ti to šíří xSTP nebo ne.

[Viktor Novotný]

Pokud máš všechny switche od sebe na úrovni xSTP izolovány, tak pád linky vyvola flushnutí jen MAC tabulek v těch dvou switchích, které ta padlá linka propojuje.
U tebe možná půjde i o to, zda ty další switche jsou opravdu od sebe odizolované na úrovni xSTP nebo ne. A pak jestli chápu, tka máš stále mix STP a RSTP switchů, pak se některé věci mění.

Dle toho výpisu je na tom uplinku 24 BPDU zastaveno. A teď půjde i o to, jak je ten port definován v nadřazeném switchi. Pokud ze strany toho downlinku směrem dolů je ten port definován jako edge, tak jeho zacvičení down/up se nepropaguje jako změna topologie dál. Pokud ten downlink port není edge, tak jeho up event vyvolá poslání TC dál u RSTP s příslušným okamžitým flushnutím mac tabulek (pokud by switch nebyl v RSTP, ale starším STP, tak se TC posílá při down i up eventu a vvolává to zkrácení vyhnívání mac tabulek na 15 sec).

Takže pokud mám 3 switche za sebou, 1. a 2. se spolu baví pomocí xSTP a 2. s 3. nikoliv, tak pokud padne linka mezi 2. a 3. switchem a tato linka nebude v 2. switchi jako edge, tak dojde k flushnutí MAC ve všech třech switchích. Pokud jako edge bude, flush se má udělat jen částečně na switchích 2 a 3.

Pozapínej ten debug na těch switchích a uvidí se pak jasně, zda ti to šíří xSTP nebo ne.

ty dva switche co to na centralnim miste taky flushuje nemaji stp vubec ! proste vypnute ...

cele to nevyvolava TC ... to je prave to divny, kdyz se podivam tak topology change je nekde davno ...

defakto cela struktura je od spodu :

c2960 ma spanning-tree mode rapid-pvst, na 24 a 11 spanning-tree bpdufilter enable, 24 je uplink, ma protected porty
c2960 ma spanning-tree mode rapid-pvst, na 24 spanning-tree bpdufilter enable, 24 je uplink, ma protected porty
c3560E ma spanning-tree mode pvst, zadny filter nema, ma protected porty
c3560E nema zadny spanning je jen switch a nema ani protected porty
c3560G nema zadny spanning je jen switch a nema ani protected porty

pri dane udalosti se flushnou macy VSEM ! z meho pohledu je zaskodnik nekde na 11 portu v tech kabelazich

[Dalibor Toman]

kdyby to tak bylo, procisti se od vrchu tedy na vsech vetvich ... ne od spoda .. jen z jedne vetve a na spolecnych switchich ... spis to bude nejaky problem s tim spaningem ... jak psal o par prispevku vyse " spanning-tree portfast " ten mam na uplinku ... on prebije filter ?

nevim ale v Cisco DOC jsem nasel zminku:
You can also use the spanning-tree bpdufilter enable interface configuration command to enable BPDU filtering on any interface without also enabling the Port Fast feature. This command prevents the interface from sending or receiving BPDUs.

Ale pokud v tom sh span vlan xy detail je napsano, ze filtering je enabled tak to je asi irelevantni.

Mas tam nejake rozumne verze IOSu? Neco co se blizi poslednim 12.2 verzim na dane platforme?
12.2.58-SE2 (nebo 12.2.55-SE10) ?

[Viktor Novotný]

ano, vetsinou jak pises " 12.2-25.SEE2.bin" , "12.2-35.SE5.bin"

ale jak rikam, mam za to ze nejaky klient v tech kabelazich ma nejakou sracku, tipuju na router aušus ... a nejlepsi bude asi do baraku narvat cisca najit konkretniho kretena a podivat se co si to tam sam dal ... pak ho s tim ubiju k smrti