Managed switch (Dell) + loop op aangesloten unmanaged switch

[basset]

Ik vroeg mij af, of iemand hier licht in het bos kan werpen:

Ik heb een Dell PC 3548 waar RSTP op is geconfigureerd en als we nu een loop op een unmanaged switch maken, had ik eigenlijk verwacht, dat RSTP de port dicht zou knallen waar de unmanaged switch op zit aangesloten. Helaas dus niet.

Weet iemand welke instellingen daar nu voor zijn op dit type switch?

Ik snap de manual niet helemaal en op het grote boze internet worden functies aangehaald, die ik niet of niet helemaal op de Dell switch kan vinden:

Moeten we gewoon storm control aanzetten en configureren, of moeten we juist op de niet trunk poorten spanning tree uitzetten en BPDU op flooding of filtering zetten.

Of ik lees niet goed, of ik ben te ongeduldig, ik kom er niet uit.

[Yariva]

Op Cisco meuk knalt bpduguard daar altijd voor in... Is zo'n optie beschikbaar?

[basset]

Ik zie op onze switches alleen een optie: BPDU Handling (filtering of flooding) staan bij global settings onder spanning tree, waarbij BPDU dus alleen gebruikt wordt als Spanning tree uit staat (aldus de omschrijving)

In het kort zou dat dan mogelijk betekenen, dat we op alle poorten die geen trunk zijn, dus STP uitgezet moet worden en BPDU FIltering op flooding of Filtering moet staan. En dat we dan voor verbindingen naar de core switches en de stacks STP apart aan moeten zetten.

[Ximon]

basset schreef op dinsdag 14 april 2015 @ 15:54:
In het kort zou dat dan mogelijk betekenen, dat we op alle poorten die geen trunk zijn, dus STP uitgezet moet worden en BPDU FIltering op flooding of Filtering moet staan. En dat we dan voor verbindingen naar de core switches en de stacks STP apart aan moeten zetten.

In het kort: ja

Ik gok dat STP tussen de managed en unmanaged switch niet werkt omdat de unmanaged switch geen BDPUs forward (deze worden naar multicast adres 01:80:C2:00:00:00 gestuurd volgens Wikipedia). De managed switch kan er dus niet via STP achter komen dat beide poorten waar de unmanaged switch op zit aangesloten eigenlijk een loop vormen.

Het lijkt me ook niet wenselijk dat BPDUs terecht komen op plekken waar deze geen functie hebben. In het slechtste geval kan een grapjas die die dingen op zijn werkstation ziet langskomen spoofed BDUs het netwerk in sturen, zichzelf voordoen als switch met designated port en zo een MITM aanval uitvoeren. Ook zie je irritante herrie als je een keer een trace moet maken met Wireshark.

[DiedX]

basset schreef op dinsdag 14 april 2015 @ 15:12:

Of ik lees niet goed, of ik ben te ongeduldig, ik kom er niet uit.

Afgezien van dat: RSTP gebruik je alléén voor einddevices. Die unmanaged switch != einddevice.

@Ximon, waarom zouden die multicasts niet doorgestuurd worden?

@ TS. Volgens mij moet je RSTP naar STP zetten, en nog eens proberen...

[Ximon]

DiedX schreef op dinsdag 14 april 2015 @ 20:17:
[...]

Afgezien van dat: RSTP gebruik je alléén voor einddevices. Die unmanaged switch != einddevice.

Wat bedoel je precies? RSTP gebruik je alléén voor einddevices (dus alleen in de accesslaag) of alléén voor einddevices (dus juist in de distributionlaag/core)?

@Ximon, waarom zouden die multicasts niet doorgestuurd worden?

Dat weet ik niet, maar klaarblijkelijk gebeurt het niet. Als je een twee poorten op dezelfde switch simpelweg met een UTP kabel op elkaar aansluit blijft 1 poort in blocking wanneer STP aan staat (in ieder geval op een Cisco, weet ik helaas uit ervaring). Op basis daarvan concludeer ik dat de managed switch 1 poort in blocking zou moeten houden als de BDPUs wel geforward zouden worden.

[DiedX]

RSTP gebruik je alleen voor de accesslaag. Dwz: alles wat /geen/ loop kan veroorzaken. Laptops, IP-telefonie, Desktops and such. /geen/ switches.

RSTP forward dus wél alles, en wacht tot hij een BPDU tegen komt. Non-Managed switches forwarden gewoon alles (ze zijn dom!), inclusief BPDU's.

Nogmaals: TS moet gewoon nog eens een test doen, maar dan met STP (dus de niet fast variant). Die luistert eerst een 30 seconden, en gooit daarna de poort in forwarding state.

[Ximon]

DiedX schreef op dinsdag 14 april 2015 @ 21:57:
RSTP gebruik je alleen voor de accesslaag. Dwz: alles wat /geen/ loop kan veroorzaken. Laptops, IP-telefonie, Desktops and such. /geen/ switches.

Bedoel je niet PortFast of een variant daarvan? Volgens mij is het niet handig om twee verschillende STP protocollen door elkaar te gebruiken in een netwerk.

RSTP forward dus wél alles, en wacht tot hij een BPDU tegen komt. Non-Managed switches forwarden gewoon alles (ze zijn dom!), inclusief BPDU's.

Non-managed switches zijn nog steeds soort van slim: ze hebben een CAM tabel en gebruiken die voor het "slim" forwarden frames. Een compleet dom apparaat is een hub, en ik hoop niet dat TS die gebruikt

[basset]

Ximon schreef op woensdag 15 april 2015 @ 08:47:
[...]


Bedoel je niet PortFast of een variant daarvan? Volgens mij is het niet handig om twee verschillende STP protocollen door elkaar te gebruiken in een netwerk.


[...]


Non-managed switches zijn nog steeds soort van slim: ze hebben een CAM tabel en gebruiken die voor het "slim" forwarden frames. Een compleet dom apparaat is een hub, en ik hoop niet dat TS die gebruikt

Nee, hubs doen we hier niet meer aan

Maar als ik het goed heb: We hebben een rits managed switches, waarom STP (RSTP) aan staat. STP genereerd BPDU paketjes (met informatie over het netwerk), die ervoor zorgen dat de "goedkoopste" route in een netwerk gevolgd wordt en als er tussen managed switches redundant links liggen, dan wordt de "duurste" link blocking/disabled gezet, totdat er bijvoorbeeld een switch of port uitvalt die goedkoper was. Gebeurt dit, dan wordt die "dure" link enabled en root.

Tot zover is het wel duidelijk. Nu op het moment dat iemand een huis-tuin en keukenswitch (geen hub) aansluit, dan is er niets aan de hand. Die switch die werkt en de computers die je er op aansluit ook. Dit willen we niet tegen gaan.

BPDU guard, die zorgt er volgens mij voor, dat dit soort switches geblokkeerd worden, dat willen we dus liever niet.

Onze switches zijn 3548 switches van Dell en die hebben zo te zien die functie ook niet.

Nu maakt iemand op die simpele switch een loop: Plof! Het lijkt er op dat deze switches geen opties hebben om dit tegen te gaan, behalve misschien Storm Control, maar dan loop je volgens mij weer de kans dat je false positives gaat krijgen en weer andere services uitschakelt.

Pfffff

Een alternatief zou zijn om in het hele pand, de switches uit te faseren, voor STP aware switches, maar willen we die investering doen.

Ik wil een simpel vinkje! (en kennis)

[Ximon]

(R)STP is bedoeld om redundante verbindingen tussen switches te kunnen maken, en voorkomt dat een switch gelijk van het netwerk af ligt als de uplink poort faalt. Dat je hiermee foutjes kan opvangen zoals per ongeluk een netwerkloop maken vind ik een soort van bijkomend voordeel dan echt een feature. Het zou namelijk niet voor mogen komen dat iemand per ongeluk een loop maakt via een (unmanaged) switch.

In praktijk komt dit natuurlijk helaas wel voor, dus je wil in eerste plaats een manier om dit te detecteren. Je zou bijvoorbeeld met een monitoringpakket als OMD(CheckMK) de switch kunnen laten uitlezen via Syslog, zodat dit soort problemen zichtbaar worden. 100% zeker voorkomen kan je het niet zolang er unmanaged switches in gebruik zijn in het netwerk.

Over BPDU handling (zoals het in Dell taal heet):

BPDU Handling — Determines how Bridge Protocol Data Unit (BPDU) packets are managed when STP is disabled on the port/ device. BPDUs are used to transmit spanning tree information.
The possible field values are:
– Filtering — Filters BPDU packets when spanning tree is disabled on an interface. This is the default value
– Flooding — Floods BPDU packets when spanning tree is disabled on an interface.

Ik zou zeggen: schakel STP uit op poorten die niet op een managed switch zitten aangesloten, want het doet verder toch niets op die poorten en levert securityrisico's op.

[basset]

Ximon schreef op woensdag 15 april 2015 @ 11:10:
(R)STP is bedoeld om redundante verbindingen tussen switches te kunnen maken, en voorkomt dat een switch gelijk van het netwerk af ligt als de uplink poort faalt. Dat je hiermee foutjes kan opvangen zoals per ongeluk een netwerkloop maken vind ik een soort van bijkomend voordeel dan echt een feature. Het zou namelijk niet voor mogen komen dat iemand per ongeluk een loop maakt via een (unmanaged) switch.

In praktijk komt dit natuurlijk helaas wel voor, dus je wil in eerste plaats een manier om dit te detecteren. Je zou bijvoorbeeld met een monitoringpakket als OMD(CheckMK) de switch kunnen laten uitlezen via Syslog, zodat dit soort problemen zichtbaar worden. 100% zeker voorkomen kan je het niet zolang er unmanaged switches in gebruik zijn in het netwerk.

Over BPDU handling (zoals het in Dell taal heet):

[...]


Ik zou zeggen: schakel STP uit op poorten die niet op een managed switch zitten aangesloten, want het doet verder toch niets op die poorten en levert securityrisico's op.

Dat uitschakelen heb ik aan gedacht, maar ik snap niet wat nu het nut, van Of Filtering Of Flooding is. Ik snap niet helemaal wat filtering doet tov flooding. Bij Filtering worden en schijnbaar geen BPDU paketjes doorgezet en bij flooding wel, maar wat betekent dat nu op die port op de managed 3548?

Anders moet ik mogelijk toch met Storm control gaan werken, maar die vind ik mogelijk nog enger

[Tijntje]

Check eerst even of je de laatste firmware van de PowerConnect 3548 hebt.
http://www.dell.com/suppo...powerconnect-3548/drivers

In de laatste releases van de Dell firmwares is erg veel gewijzigd en worden de PowerConnects steeds meer gelijk getrokken betreft fuctionaliteit met de Force10.
Uiteraard zijn op deze pagina ook de manuals te vinden.
http://www.dell.com/suppo...powerconnect-3548/manuals

De laatste versie is: Firmware v2.0.0.65,A11
http://www.dell.com/suppo...ersDetails?driverId=5PGT7

[Ximon]

basset schreef op woensdag 15 april 2015 @ 11:28:
[...]


Dat uitschakelen heb ik aan gedacht, maar ik snap niet wat nu het nut, van Of Filtering Of Flooding is. Ik snap niet helemaal wat filtering doet tov flooding. Bij Filtering worden en schijnbaar geen BPDU paketjes doorgezet en bij flooding wel, maar wat betekent dat nu op die port op de managed 3548?

Anders moet ik mogelijk toch met Storm control gaan werken, maar die vind ik mogelijk nog enger

Als op een poort STP ingeschakeld is en BPDU Control staat op Filtering, dan worden BDPUs doorgestuurd
Als op een poort STP ingeschakeld is en BPDU Control staat op Flooding, dan worden BDPUs doorgestuurd
Als op een poort STP uitgeschakeld is en BPDU Control staat op Filtering, dan worden BDPUs niet doorgestuurd (dit is de default volgens mij)
Als op een poort STP uitgeschakeld is en BPDU Control staat op Flooding, dan worden BDPUs doorgestuurd

Storm Control zou je kunnen instellen, met hele conservatieve waarden zodat er alleen ingegrepen als er daadwerkelijk een broadcast storm plaatsvindt.

[basset]

Wij hebben de voorlaatste versie van de firmware. Ik zag in de release notes niet iets over nieuwe functies. Ik ben bang dat storm control de enige optie is om ellende te voorkomen.

Al doende leert men. Ik ga maar een testopstelling in elkaar zetten...

[Ximon]

Succes!

[Wim-Bart]

1. Je zegt dat er een unmanaged switch achter hangt. Maar volgens mij wordt (R)STP uitgeschakeld omdat bij de inialisatie van de poort er eerst bepaald wordt of het een Edge Poortt is (auto-edge).

2. Wanneer de Switch "dom" is zal de managed switch gewoon 1 device zien zonder BDPU verkeer en na 4-15 seconden (tijd is afhankelijk of portfast is ingeschakeld) gewoon omgeschakeld worden naar Edge-Port.

3. En op een Edge port wordt Spanning Tree UIT gezet. Wanneer je dan een loop maakt via de unmanaged switch, gaat de poort niet down en zal deze Edge blijven staan en zal nooit participeren in Spanning tree dus ook niet uitgeschakeld worden.

4. De poort waarop de loop gemaakt wordt zal spanning tree wel aan hebben staan. echter zal hij geen BDPU's ontvangen van de andere poort omdat deze op Edge staat met als gevolg dat de loop gehandhaafd blijft.

Simulatie:
Zet de unmanaged switch UIT. Maak de loop. Zet hem aan. Dan zie je dat het opeens wel goed werkt. Reden is dat beide poorten BDPU's zenden zodra er link is, beide poorten zien elkaar door de unmanaged switch heen en 1 van de poorten zal in blocking gaan.

Doe nu het volgende:
Zet de unmanaged switch UIT. Verbind maar 1 poort met de managed switch. Zet de switch aan en je zal zien dat hij op Forwarding Edge komt te staan. Maak nu een loop en je ziet dat hij zo blijft staan en dat je network min of meer zal instorten.

Er zijn een aantal oplossingen:
Workaround 1: Forceer alle access poorten op Spanning Tree en zet auto Auto Edge UIT (auto edge is voor bijna alle switches default). Het nadeel is dat je een hick-up krijgt bij ieder device wat aan/uit gezet wordt (spanning tree gaat door je network heen). Dus een echte goede oplossing is het niet.

Work around 2: alleen de access poorten waar een unmanaged switch op aangesloten is geforceerd op Spannning tree te zetten. Het nadeel is dat alle devices aangesloten op deze switches ook weer je network verstoren met het veroorzaken van spanning-tree verkeer.

Oplossing: Dit is eigenlijk het beste. Gewoon Spanning tree port-fast aanzetten op al je edge poorten. Tevens BDPU-protect op alle edge-poorten aanzetten. EXPLICIET BDPU-filter uitzetten. Eventueel wanneer je switch het ondersteund ook nog Loop Protect AANZETTEN.
BDPU protect zorgt ervoor dat wanneer je een loop veroorzaakt (via een unmanaged switch of hub) altijd de poort wordt UITGEZET voor X-tijd (instelbaar).
Tevens voorkom je dat mensen Eigen managed switches plaatsen.
Loop protect zorgt er voor dat "unmanaged" domme switches welke zelf BDPU filteren loops kunnen veroorzaken, loop protect werkt op basis van MAC adressen.

[basset]

Wim-Bart schreef op woensdag 15 april 2015 @ 17:57:
1. Je zegt dat er een unmanaged switch achter hangt. Maar volgens mij wordt (R)STP uitgeschakeld omdat bij de inialisatie van de poort er eerst bepaald wordt of het een Edge Poortt is (auto-edge).

2. Wanneer de Switch "dom" is zal de managed switch gewoon 1 device zien zonder BDPU verkeer en na 4-15 seconden (tijd is afhankelijk of portfast is ingeschakeld) gewoon omgeschakeld worden naar Edge-Port.

3. En op een Edge port wordt Spanning Tree UIT gezet. Wanneer je dan een loop maakt via de unmanaged switch, gaat de poort niet down en zal deze Edge blijven staan en zal nooit participeren in Spanning tree dus ook niet uitgeschakeld worden.

4. De poort waarop de loop gemaakt wordt zal spanning tree wel aan hebben staan. echter zal hij geen BDPU's ontvangen van de andere poort omdat deze op Edge staat met als gevolg dat de loop gehandhaafd blijft.

Simulatie:
Zet de unmanaged switch UIT. Maak de loop. Zet hem aan. Dan zie je dat het opeens wel goed werkt. Reden is dat beide poorten BDPU's zenden zodra er link is, beide poorten zien elkaar door de unmanaged switch heen en 1 van de poorten zal in blocking gaan.

Doe nu het volgende:
Zet de unmanaged switch UIT. Verbind maar 1 poort met de managed switch. Zet de switch aan en je zal zien dat hij op Forwarding Edge komt te staan. Maak nu een loop en je ziet dat hij zo blijft staan en dat je network min of meer zal instorten.

Er zijn een aantal oplossingen:
Workaround 1: Forceer alle access poorten op Spanning Tree en zet auto Auto Edge UIT (auto edge is voor bijna alle switches default). Het nadeel is dat je een hick-up krijgt bij ieder device wat aan/uit gezet wordt (spanning tree gaat door je network heen). Dus een echte goede oplossing is het niet.

Work around 2: alleen de access poorten waar een unmanaged switch op aangesloten is geforceerd op Spannning tree te zetten. Het nadeel is dat alle devices aangesloten op deze switches ook weer je network verstoren met het veroorzaken van spanning-tree verkeer.

Oplossing: Dit is eigenlijk het beste. Gewoon Spanning tree port-fast aanzetten op al je edge poorten. Tevens BDPU-protect op alle edge-poorten aanzetten. EXPLICIET BDPU-filter uitzetten. Eventueel wanneer je switch het ondersteund ook nog Loop Protect AANZETTEN.
BDPU protect zorgt ervoor dat wanneer je een loop veroorzaakt (via een unmanaged switch of hub) altijd de poort wordt UITGEZET voor X-tijd (instelbaar).
Tevens voorkom je dat mensen Eigen managed switches plaatsen.
Loop protect zorgt er voor dat "unmanaged" domme switches welke zelf BDPU filteren loops kunnen veroorzaken, loop protect werkt op basis van MAC adressen.

Na de testopstelling, zagen we dat de managed switches beschikken over loop detect. Dit zit schijnbaar in het STP deel van Dell (of mogelijk maakt het onderdeel uit van STP). De console roept ook STP Loop-detect.

Wat nu interessant is, is dat als het heel druk is op de managed switch, doordat er veel broadcast verkeer is, dan ziet de switch niet altijd deze trigger voorbij komen. In onze testopstelling ging dit bij het generereren van veel broadcast verkeer op de managed switch 1 op de 3 keer fout.

We vermoeden, dat ook dit een broadcast of multicast signaal is. Storm control is dan ook geen oplossing, want storm control negeert gewoon al het broadcast en/of multicast verkeer boven een threshhold die je instelt.

Wat wel gebeurt, is dat de switch dan niet meer van slag raakt, maar dan blijft het probleem onbekend en als dat dan een paar keer optreed, zonder dat het opgelost wordt, dan ploft wellicht alsnog de boel.

Ik denk dat (voor ons) de beste oplossing is, om gewoon de stacks van elkaar te isoleren, door op de "uplinks" storm control aan te zetten, zodat het probleem ieder geval per verdieping geïsoleerd blijft.

RSTP zet overigens BPDU filtering standaard uit. En deze switches beschikken niet over BPDU protect helaas.

Portfast aan of uit heeft idd geen zin als er een unmanaged switch achter hangt. De port waar hij mee op de managed switch zit, is immers al up. Dus als je portfast uit hebt staan en je prikt er een computer op, dan is de port meteen actief. Eigenlijk kun je portfast dus "simuleren" op een switch die dit niet zou hebben, door er een unmanaged switch aan te hangen

[ Voor 7% gewijzigd door basset op 30-04-2015 08:31 . Reden: toevoeging ]

[Wim-Bart]

Strak verhaal. Ik heb ook eens in de CLI manual zitten kijken van deze switch en inderdaad er zitten een aantal features in welke standaard aan staan zoals loop protect. Maar ook features die ontberen. Ik denk dan ook dat deze switch (ondanks dat het een leuk product is) een te beperke STP functionaliteit heeft. Of dat de CPU te traag is en het bij flinke broadcasts niet meer kan bijbenen.