Loop voorkomen op enkele switch zonder poort uitschakelen

[dion_b]

Altijd leuk als je networking ambities je kennisniveau overstijgen...

Ik wil iets, maar loop tegen een vrij fundamenteel probleem aan en vraag me af of daar omheen te werken is.

Situatie is als volgt:
Ik heb een testopstelling waar ik (TCP) throughput wil meten van devices/verbindingen. Dat gebeurt op zich vrij simpel: ik heb een server (iPerf en/of ixChariot) en een client/endpoint. Hang de testopstelling tussen client en server en (ervan uitgaande dat de bottleneck in de testopstelling is) je weet de performance.

Tot vorig jaar was dat prima. Nu zijn er twee veranderingen waardoor ik moet klussen:
- 1GbE begint te bottlenecken. Server en endpoint hebben 10GbE interfaces, maar in de testopstelling moet ik werken met link aggregation om boven de 1Gbps uit te komen. Dus iets moet van 1x 10GbE gaan naar 1/2/3/n keer 1GbE koppelen.
- De testopstelling wordt complexer. In plaats van 1-op-1 heb ik 4 mogelijke apparaten. In eerste instantie nog steeds altijd 1-op-1, maar dus niet altijd zelfde paar.

Gezien deze eisen willen we er een switch tussen hangen met 1GbE en mogelijkheid tot LAPC met 1GbE aansluitingen. Dat is niet zo'n punt. Scheiding tussen de verschillende apparaten kan met VLANs. Door VLAN config aan te passen zou het mogelijk moeten zijn om zonder fysiek met kabels te kloten ieder willekeurige combinatie van die 4 mogelijke apparaten aan de server danwel client te knopen. Op layer 3 fantastisch - en dat laatste is gelijk de reden waarom ik graag met één switch zou willen werken en niet met twee losse, want dan zou ik vroeg of laat ompluggen vereisen.

Maar...

Wat ik dan gecreeerd heb is op Layer 2 een loop. Twee opties:
- geen STP of vergelijkbaar: broadcast storm die de hele switch lam legt.
- wel STP of vergelijkbaar: een van de poorten waar de loop over gaat wordt dichtgegooid. Geen loop meer, maar ook geen connectivty over m'n testopstelling

Schematisch weergegeven is dit het probleem:


Nu, high-end enterprise switches (Cisco, Juniper etc.) hebben de mogelijkheid een switch in twee aparte virtuele te scheiden. Mooi, maar zeker gezien eis van 10Gbps op meerdere poorten wordt dat een ERG dure grap (en hoogstwaarschijnlijk takkenherrie), en qua config wordt het ws meer moeite dan ompluggen van kabels als ik poorten tussen de een en de ander wil verschuiven. Ik zit meer te kijken richting een TP-Link JetStream T1700X-16TS.

Is er een manier om hierop (of met iets anders in de prijscategorie EUR <1500) de loop (gele cirkel) te voorkomen en het verkeer zoals gewenst (rode lijn) te laten gaan. of moet ik accepteren dat ik twee losse switches nodig ga hebben?

[CyBeR]

Betreft je "testopstelling" een bridge? Want dan idd, loop. De simpelste oplossing is dan gewoon je 10GbE switch twee VLANs te geven en de testopstelling in beide te prikken.

[Kabouterplop01]

Het ligt een klein beetje aan je testopstelling, maar volgens mij kun je die loop voorkomen door je server en je client in een apart L3 vlan te hangen en PVST (cisco term ervoor) te configgen.

edit: @CyBeR is veel sneller! Die methode is ook eenvoudiger!

[ Voor 15% gewijzigd door Kabouterplop01 op 07-02-2018 16:36 ]

[dion_b]

CyBeR schreef op woensdag 7 februari 2018 @ 16:30:
Betreft je "testopstelling" een bridge? Want dan idd, loop. De simpelste oplossing is dan gewoon je 10GbE switch twee VLANs te geven en de testopstelling in beide te prikken.

De testopstelling kun je benaderen als een WiFi AP en bijbehorende client. Allemaal L2 dus, geen routering.

Voor L3 broadcasts is VLAN prima, maar helpt dat ook op L2 met L2 broadcasts? Ook al werk je met aparte VLANs zal het MAC-adres van de switch op poort 1 hetzelfde zijn als het adres van de switch op poort 2, ongeacht VLAN, waardoor het toch een loop zal detecteren?

Kabouterplop01 schreef op woensdag 7 februari 2018 @ 16:31:
Het ligt een klein beetje aan je testopstelling, maar volgens mij kun je die loop voorkomen door je server en je client in een apart L3 vlan te hangen en PVST (cisco term ervoor) te configgen.

edit: @CyBeR is veel sneller! Die methode is ook eenvoudiger!

Hmm, PVST is natuurlijk Cisco-proprietary, maar ik lees dat MSTP (IEEE802.1s) vergelijkbaar zou moeten zijn - en ondersteund is door de switch die ik voor ogen heb. Ik ga daar eens in snuffelen...

[Kabouterplop01]

Voor L3 broadcasts is VLAN prima, maar helpt dat ook op L2 met L2 broadcasts? Ook al werk je met aparte VLANs zal het MAC-adres van de switch op poort 1 hetzelfde zijn als het adres van de switch op poort 2, ongeacht VLAN, waardoor het toch een loop zal detecteren?

Nee, spanning tree treedt in werking voordat mac-flooding ter sprake komt.

[CyBeR]

dion_b schreef op woensdag 7 februari 2018 @ 16:59:
[...]
Voor L3 broadcasts is VLAN prima, maar helpt dat ook op L2 met L2 broadcasts? Ook al werk je met aparte VLANs zal het MAC-adres van de switch op poort 1 hetzelfde zijn als het adres van de switch op poort 2, ongeacht VLAN, waardoor het toch een loop zal detecteren?

Alleen als je een heel brakke switch hebt die niet het VLAN bij een MAC<->port mapping bijhoudt. Dat zijn voor namelijk heel oude switches -- tegenwoordig is 't vrij normaal dat een MAC op meer dan een VLAN voor komt.

[ Voor 11% gewijzigd door CyBeR op 07-02-2018 22:06 ]

[Verwijderd]

Voor L3 broadcasts is VLAN prima, maar helpt dat ook op L2 met L2 broadcasts?

VLAN is een L2-beest, dus op frame level gaat het prima... totdat er STP BPDUs voorbijkomen.

STP kijkt namelijk niet naar VLANs, zodat als je bijvoorbeeld twee lijntjes met elk verschillende VLANs tussen twee switches trekt, dan zien ze dat toch als loop. Dan moet je dat dus apart aan de switches communiceren via een (extra) spanning tree domein, danwel selectief STP op poortjes uitzetten. Dat gaat overigens niet op poort-MAC maar op bridge-ID.

Maar ik volg eigenlijk niet wat die testopstelling nou precies tot loop-gevoelig maakt. Als je maar een kabeltje per tussenhangend testapparaat naar die switch trekt is het een doodnormaal LANnetje, waarbij dus server, client, en de rest allemaal in hetzelfde broadcast domain hangen. Je zegt dat het APs zijn, maar bridgen die ook elkaars verkeer?

[dion_b]

Verwijderd schreef op woensdag 7 februari 2018 @ 17:50:
[...]

Maar ik volg eigenlijk niet wat die testopstelling nou precies tot loop-gevoelig maakt. Als je maar een kabeltje per tussenhangend testapparaat naar die switch trekt is het een doodnormaal LANnetje, waarbij dus server, client, en de rest allemaal in hetzelfde broadcast domain hangen. Je zegt dat het APs zijn, maar bridgen die ook elkaars verkeer?

Ja. Zie plaatje. Ethernet gaat uit switch, in AP. AP verbindt met client, van client gaat er weer een kabeltje in de switch. Allemaal op L2. Een AP is uiteindelijk niets meer dan een heterogeneous bridge met aan ene kant Ethernet en aan andere kant WiFi.

[Verwijderd]

dion_b schreef op woensdag 7 februari 2018 @ 19:53:
Ethernet gaat uit switch, in AP. AP verbindt met client, van client gaat er weer een kabeltje in de switch. Allemaal op L2.

Dat haalde ik niet uit het plaatje. In dit scenario, zolang client geen bridge is, heb je nog geen loop.

Een AP is uiteindelijk niets meer dan een heterogeneous bridge met aan ene kant Ethernet en aan andere kant WiFi.

Ook maar voorzover het 802.3 in 802.11 weet te proppen, maar ik weet bijvoorbeeld niet of en wat dan APs met STP BPDUs doen. Als ze die netjes doorgeven en ze komen er aan de andere kant weer uit dan merk je snel genoeg dat STP poorten dicht begint te zetten. Maar als client niet voor bridge speelt, en wel L3 data terugpompt, nouja, dan heb je een hoop data op je switch.