Dell PowerConnect Gateway per Vlan/Subnet

[Verwijderd]

Ik heb een lastig probleem op een PowerConnect 6024 welke ik echt niet opgelost krijg.

Op een 6024 heb ik een aantal Vlan geconfigureerd voor een eigen subnet. Iedere Vlan heeft IP zodat de clients in deze vlan een GW hebben die altijd bereikbaar is zolang de switch het maar doet.

Om verkeer naar buiten te krijgen heb ik een route aangemaakt naar mijn router welke ook aan deze switch hangt, internet verkeer gaat dus goed. De route hiervoor bedraagt de meest simpele:

0.0.0.0 0.0.0.0 172.16.1.253

En dit is mijn output op de switch:

code:

sh ip route 
Maximum Parallel Paths: 4 (4 after reset)

Codes: C - connected, S - static, R - RIP, O - OSPF, E - OSPF external

S  0.0.0.0/0          [1/1] via  172.16.1.253  21:33:27            vlan 1    
C  172.16.1.0/24      is directly connected                        vlan 1    
C  172.16.2.0/24      is directly connected                        vlan 2    
C  172.16.4.0/24      is directly connected                        vlan 4

Dat werkt, maar ik wil graag bepaalde subnetten, bijvoorbeeld 172.16.4.0 over een andere gateway naar buiten sturen, dus ik maar een route:

ip route 172.16.4.0 /24 172.16.1.250

Hierna krijg ik (ook wanneer ik de default route verwijder) dit als output op mijn switch:

code:

# sh ip route 
Maximum Parallel Paths: 4 (4 after reset)

Codes: C - connected, S - static, R - RIP, O - OSPF, E - OSPF external

C  172.16.1.0/24      is directly connected                        vlan 1    
C  172.16.2.0/24      is directly connected                        vlan 2    
C  172.16.4.0/24      is directly connected                        vlan 4    
S  172.16.4.0/24     [1/1] via 172.16.1.250 Backup Not Active

En hier dus geen traffic mogelijk.

Ik ben echt al tijden bezig dit te uit te zoekenen heb dit nog nooit meegemaakt op een dergelijke routing switch, zelfs grotere routers werkt dit prima.

Wat doe ik hier verkeerd ?

[Verwijderd]

Het lijkt erop dat je wanneer je een Vlan een IP address uit je subnet geeft je het subnet niet meer kunt routeren in de switch omdat de switch dit subnet al als "directly connected" ziet.

Een 0.0.0.0 /0 xxx.xxx.xxx.xxx is wat je dan alleen kunt gebruiken.

Iemand een idee over een workaround ?

[Paul]

172.16.1.250 lijkt me niet de router die verkeer voor Vlan4 af moet handelen?

Een router doet (vrijwel) niks moet source adresses maar kijkt alleen maar naar de destination: Naar welk netwerk moet het toe, en welk IP-adres is daarvoor mijn eerstvolgende hop.

Je wilt nu policy based routen, daarvoor heb je een wat geavanceerder router nodig ben ik bang

[Verwijderd]

Paul schreef op woensdag 27 maart 2013 @ 20:34:
172.16.1.250 lijkt me niet de router die verkeer voor Vlan4 af moet handelen?

Een router doet (vrijwel) niks moet source adresses maar kijkt alleen maar naar de destination: Naar welk netwerk moet het toe, en welk IP-adres is daarvoor mijn eerstvolgende hop.

Je wilt nu policy based routen, daarvoor heb je een wat geavanceerder router nodig ben ik bang

Het lijkt op policy based routing inderdaad maar wat meer het probleem lijkt te zijn is dat de IP range al bekend is op de switch, dus directly attached.

De .250 is een IP dat ook een router is in datzelfde .1 subnet. Dit is heb ik bewust gedaan om te lijken waar het probleem kan zitten bij exact dezelfde instellingen op de switch.

De .1 is overigens geconnect op een andere switch die weer via een trunk met elkaar in verbinding staan.

[Paul]

Verwijderd schreef op donderdag 28 maart 2013 @ 08:57:
...maar wat meer het probleem lijkt te zijn is dat de IP range al bekend is op de switch...

Dan nog werkt een standaard router enkel met destination based routing: "Waar moet dit naar toe, en hoe kom ik daar?" is het enige waar een router zich mee bezig houdt.

Als dat IP niet bekend zou zijn op de switch dan gaat alle verkeer NAAR Vlan4 naar Router253. Deze zal het vervolgens vrolijk het internet op sturen (als deze niet is ingesteld RFC1918 adressen te droppen) aangezien die router verder ook niet zal weten waar het naartoe moet... Je wilt juist alle verkeer VANAF Vlan4 naar de andere router sturen als ik het goed zie.

Een oplossing is om op alle devices in Vlan4 een aantal static routes te zetten. Andere oplossing is een deftiger Router253 (die bijvoorbeeld meer 'Wan'-interfaces aan kan).

Wat is überhaupt de reden dat verkeer vanaf Vlan4 een ander pad naar het internet moeten krijgen?

Als ik het goed heb is de situatie nu als volgt?


Met de volgende situatie heb je er ook, ik weet alleen niet of Router253 dat kan en of die daarvoor ingezet kan worden (mogelijk doet het ding al [veel] meer...):

Je stelt dan in Router253 (die dan dus niet meer in Vlan1 zit en ook geen 172.16.1.253 meer heeft...) in dat verkeer voor 172.16.0.0/12 naar het IP van de switch in het koppel-Vlan moet. Aangezien 172.16.4.0/24 een langere prefix length heeft zal de router als het goed is (maar check dat in de manual / bij de vendor) verkeer voor Vlan4 toch op Vlan4 afleveren. Werkt dit niet dan moet je meerdere routes maken:

172.16.0.0/22
172.16.5.0/24
172.16.6.0/23
172.16.8.0/21
172.16.16.0/20
172.16.32.0/19
172.16.64.0/18
172.16.128.0/17
127.17.0.0/16
172.18.0.0/15
172.20.0.0/14
172.24.0.0/13

Zoals je ziet wordt dat deel (als router253 het anders niet snapt) een stuk simpeler wanneer je Vlan4 uit 172.16.0.0/12 haalt

[ Voor 37% gewijzigd door Paul op 28-03-2013 16:18 ]

[Verwijderd]

Dank je Paul voor je uitleg, dit schept wat duidelijkheid in het topic.

Het probleem dat ik heb is dat ik niet wil dat al het traffic over de router heen gaat, dat zou betekenen dat een 1GB lijntje voor storage, VMs, en clients gebruikt zou worden. Dit komt omdat de Router/GW een PFsense box is welke als VM draait en aangesloten is op één 1GB poort aan de Lan kant.

De clients zijn aangesloten op een andere switch via een trunk, de storage en VM nodes echter op dezelfde switch als de FW.

Voor optimaal traffic en uptime van de router voor het storage/VM netwerk is het dus prettig om de Vlan's van een IP te voorzien en dit aan te wijzen als GW. Switch plat betekent netwerk plat dus dan maakt dat toch weinig uit. Mocht de Router-VM een probleem hebben en GW voor alles zijn dan is het een wat minder prettige situatie.

Omdat de switch opzich een arp table heeft, een Dell 6024, ben ik niet 100% zeker of hij zal onthouden op welke poort wel IP zit en de Router/GW eventueel zal "ontwijken" zodat lokaal traffic ook lokaal op de switch blijft als ik de VM als GW inzet.

Dan hebben we ook nog de refreshtijd van de ARP-table welke wellicht roet in het eten kan gooien.

[Paul]

Zou je een tekening kunnen maken van de fysieke opstelling? Hoeveel vSphere / HyperV / KVM / XenServer / whatever hosts heb je? Welk merk/type hardware? Storage is iSCSI zo te zien?

Want momenteel kom ik er niet zo veel wijs uit Maak ik hieruit op dat je hosts maar 1 touwtje naar de switch hebben en dat daar alles overheen moet? Ik zou sowieso minimaal 3 touwtjes per server trekken: 1x storage (FC of iSCSI), 1x vMotion en 1x LAN-verkeer, en dan heb je nog geen redundancy. Maar goed, ik weet dus niet hoe groot de omgeving is

[CyBeR]

Verwijderd schreef op donderdag 28 maart 2013 @ 08:57:
[...]


Het lijkt op policy based routing inderdaad maar wat meer het probleem lijkt te zijn is dat de IP range al bekend is op de switch, dus directly attached.

Het lijkt niet op policy based routing, dat is precies wat je wilt: aan de hand van policy's routeren (f ik begrijp verkeerd wat je precies wilt doen.) De policy zijnde dat verkeer vanaf een bepaalde source via een bepaalde verbinding gaat.

Dat de ip's al directly connected zijn maakt niet uit. Met het 'ip route' commando stel je routes in voor destinations dus wat jij ermee wilde doen gaat nooit werken.

De meeste switches kunnen geen PBR aan.

Verwijderd schreef op dinsdag 02 april 2013 @ 09:21:
Omdat de switch opzich een arp table heeft, een Dell 6024, ben ik niet 100% zeker of hij zal onthouden op welke poort wel IP zit en de Router/GW eventueel zal "ontwijken" zodat lokaal traffic ook lokaal op de switch blijft als ik de VM als GW inzet.

Dan hebben we ook nog de refreshtijd van de ARP-table welke wellicht roet in het eten kan gooien.

ARP tabel is níet boeiend bij routing-beslissingen. De ARP-tabel dient alleen om bij een gegeven IP-adres, een MAC-adres in de ethernet frame te stoppen. Dat gebeurt ná de routing-beslissing.

En ja een routing switch die een packet tegen komt met een destination adres wat 'ie directly connected in z'n route tabel heeft staan zal die niet alsnog via een router sturen.

[ Voor 39% gewijzigd door CyBeR op 02-04-2013 11:25 ]

[Verwijderd]

CyBeR schreef op dinsdag 02 april 2013 @ 11:20:
[...]


Het lijkt niet op policy based routing, dat is precies wat je wilt: aan de hand van policy's routeren (f ik begrijp verkeerd wat je precies wilt doen.) De policy zijnde dat verkeer vanaf een bepaalde source via een bepaalde verbinding gaat.

Dat de ip's al directly connected zijn maakt niet uit. Met het 'ip route' commando stel je routes in voor destinations dus wat jij ermee wilde doen gaat nooit werken.

De meeste switches kunnen geen PBR aan.

Wat jij zegt klopt niet helemaal. Dell zegt zelf ook dat omdat de IP's op de Switch aanwezig zijn kan je dus niet meer policy based routeren. Dat is de issue.

Je hebt gelijk omtrent het verhaal dat niet alle switches PBR aankunnen maar dat is dus in dit geval niet direct het probleem.

[...]


ARP tabel is níet boeiend bij routing-beslissingen. De ARP-tabel dient alleen om bij een gegeven IP-adres, een MAC-adres in de ethernet frame te stoppen. Dat gebeurt ná de routing-beslissing.

En ja een routing switch die een packet tegen komt met een destination adres wat 'ie directly connected in z'n route tabel heeft staan zal die niet alsnog via een router sturen.

Hier spreek je jezelf nogal tegen, opzich niet erg.

De ARP table is dus ZEKER boeiend bij routering als je weet dat je traffic kan beperken over de GW op deze manier. Dat valt zeker onder het kopje design.

[CyBeR]

Verwijderd schreef op dinsdag 02 april 2013 @ 12:05:
[...]


Wat jij zegt klopt niet helemaal. Dell zegt zelf ook dat omdat de IP's op de Switch aanwezig zijn kan je dus niet meer policy based routeren. Dat is de issue.

Je hebt gelijk omtrent het verhaal dat niet alle switches PBR aankunnen maar dat is dus in dit geval niet direct het probleem.

Volgens mij omdat je wel de indruk geeft PBR te willen door de manier waarop je terminologie gebruikt maar dat eigenlijk niet wilt. (Dat Paul en ik in de 1e instantie hetzelfde dachten is daar testament aan.)

Hier spreek je jezelf nogal tegen, opzich niet erg.

Ik spreek mezelf zelden tegen Ik weet heel precies waar ik 't over heb hier.

De ARP table is dus ZEKER boeiend bij routering als je weet dat je traffic kan beperken over de GW op deze manier. Dat valt zeker onder het kopje design.

Nee, dat doe je met een routing tabel. De ARP-tabel is daarbij een means to an end. Als je ARP tabel leeg is en er moet een packet naar een IP wordt de tabel gevuld. Die tabel is feitelijk slechts een cache, en wordt alleen gebruikt om L2-addressering bij L3-addressering te maken. Een niet-directly connected subnet komt ook niet in je ARP cache*.

Ik denk dat ik inmiddels begrijp wat je wilt: je wilt verkeer vóór een bepaald subnet over een bepaalde router leiden, omdat je denkt dat je anders een performance bottleneck hebt. Dat is helemaal niet nodig dus je zit het jezelf hier nogal moeilijk te maken om niks. Sterker nog, je introduceert juist een bottleneck zo. Die switch kan zo'n 48Gbps routen, maar jij wilt 't over een enkel GbE touwtje proppen.


*) Designtechnisch; sommige implementaties doen dat wel om performanceredenen.

[ Voor 8% gewijzigd door CyBeR op 02-04-2013 12:13 ]

[Verwijderd]

CyBeR schreef op dinsdag 02 april 2013 @ 12:09:
[...]
Die switch kan zo'n 48Gbps routen, maar jij wilt 't over een enkel GbE touwtje proppen.

Wat je hier stelt zegt dus voldoende... ik wil juist de opposite...

Valt me op dat je vaker leest wat jij beter vindt in plaats van te lezen wat er staat en mee te denken naar een oplossing.

Judgement in testament vorm zegt hierin al voldoende.

Ik heb je al vaker verzocht niet te reageren in mijn topics als je alleen maar wilt oordelen. Je insteek zal allicht goed zijn, het komt er alleen iedere keer zo bagger uit.

Als ik mijn Vlans een IP geef en deze als GW voor mijn hosts, of wat dan ook gebruik, gaat er niets over de 1GB lijn en blijft het lekker binnen de switch.

Ik ben in dat geval alleen in staat om een "ip route 0.0.0.0 /0 172.16.1.xxx" voor verkeer naar buiten te doen omdat de switch het anders gewoon niet slikt per subnet.

[CyBeR]

Verwijderd schreef op dinsdag 02 april 2013 @ 12:24:
[...]


Wat je hier stelt zegt dus voldoende... ik wil juist de opposite...

Valt me op dat je vaker leest wat jij beter vindt in plaats van te lezen wat er staat en mee te denken naar een oplossing.

Ja hallo. Jij komt met een brak idee en ik vertel je waarom dat brak is. Dat gebeurt vaker ja maar de oorzaak ligt aan het eerste in die zin hoor.

Verder kwam je in je TS met een uitleg waardoor de twee professionele netwerkbeheerders in dit topic beide dachten dat je PBR wilde doen. Dat ligt niet aan mij hoor.

Ik heb je al vaker verzocht niet te reageren in mijn topics als je alleen maar wilt oordelen. Je insteek zal allicht goed zijn, het komt er alleen iedere keer zo bagger uit.

Kom om hulp, reject hulp, ???, profit.

Maar goed ik wil je voortaan best negeren hoor. Ik probeer alleen de moeilijkdoenerij waar jij nogal een hand van hebt te voorkomen om jouw leven makkelijker te maken.

Vervolgens heb je de neiging om, als ik je technisch correcte informatie geef, die af te doen als zijnde incorrect (zie ARP cache, zie vlan tags in eerder topic). Dat is hoogst hinderlijk: jij komt om hulp omdat je iets niet weet en dan ga je degenen die je proberen te helpen vertellen dat zij niet weten waar ze 't over hebben.

Als ik mijn Vlans een IP geef en deze als GW voor mijn hosts, of wat dan ook gebruik, gaat er niets over de 1GB lijn en blijft het lekker binnen de switch.

Correct. Dus waarom ben je nou moeilijk aan het doen? Want met je moeilijkdoenerij bewerkstellig je nou juist wél dat alles over één 1GbE gaat, link aggregation niet beschouwd.

Ik ben in dat geval alleen in staat om een "ip route 0.0.0.0 /0 172.16.1.xxx" voor verkeer naar buiten te doen omdat de switch het anders gewoon niet slikt per subnet.

Ook correct, en het enige wat nodig is om bovenstaande reden.

[ Voor 14% gewijzigd door CyBeR op 02-04-2013 12:34 ]

[Verwijderd]

CyBeR schreef op dinsdag 02 april 2013 @ 12:28:
[...]

Correct. Dus waarom ben je nou moeilijk aan het doen? Want met je moeilijkdoenerij bewerkstellig je nou juist wél dat alles over één 1GbE gaat, link aggregation niet beschouwd.

Wellich wil je clients over een andere GW naar buiten gooien dan je servers ? En wil je tevens dat je servers NIET afhankelijk zijn van een "externe" router aan je switch ?

Dat laatste is dus de issue, want:

- Je verkeer is afhankelijk van die externe GW
- Je propt dus alles over die 1GB terwijl dat niet nodig is.
- Een IP aan je Vlan toekennen en verder alles voor dat subnet naar buiten routeren kan dus niet.

[...]


Ook correct, en het enige wat nodig is om bovenstaande reden.

Whaoh niet helemaal eens. Je routeert alles over 1 GW wat niet wenselijk hoeft te zijn, zeker niet als je vlanned wil werken en ook Firewalling tussen je subnets wil doen. Komt alles over die 1GB proppen weer aan omdat je toch verkeer gaat managent op je GW/RTR/FW voor naar binnen.

[CyBeR]

Verwijderd schreef op dinsdag 02 april 2013 @ 12:40:
[...]


Wellich wil je clients over een andere GW naar buiten gooien dan je servers ?

Juist. Dit is dus Policy Routing: routing (naar buiten) op basis van afkomst (servers vs clients). Dat kan je 6024 helaas niet.

En wil je tevens dat je servers NIET afhankelijk zijn van een "externe" router aan je switch ?

Dat laatste is dus de issue, want:

- Je verkeer is afhankelijk van die externe GW
- Je propt dus alles over die 1GB terwijl dat niet nodig is.

Je servers zijn daar voor hun interne verkeer ook helemaal niet afhankelijk van. Alleen voor verkeer naar "buiten". Het verkeer wat binnen de netwerken gekoppeld aan je switch blijft, wordt gewoon door je switch gerouteerd zonder externe hulp.

(De grap is trouwens, dat model bestond vroeger ook wel, maar wordt tegenwoordig nooit meer gebruikt.)

- Een IP aan je Vlan toekennen en verder alles voor dat subnet naar buiten routeren kan dus niet.

Inderdaad. Zo zitten subnets in elkaar en daar gaan wij met z'n tweeën niks aan veranderen.

Whaoh niet helemaal eens. Je routeert alles over 1 GW wat niet wenselijk hoeft te zijn, zeker niet als je vlanned wil werken en ook Firewalling tussen je subnets wil doen. Komt alles over die 1GB proppen weer aan omdat je toch verkeer gaat managent op je GW/RTR/FW voor naar binnen.

Ah. Hier komen een paar extra zaken tevoorschijn.

Als je op een centrale plek wilt firewallen moet je dat óf doen op je switch (ACL's) óf in een ander apparaat wat zich met security bezig houdt. In dat eerste geval gebeurt het line-rate (in de hardware van de switch), in dat tweede geval moet je het naar dat andere apparaat vervoeren en ja, dan komt daar een bottleneck bij kijken. Of je dat ok vindt is de afweging die je moet maken.

Wat in ieder geval níet kan is een subnet zowel directly connected hebben als er een route naartoe hebben via een andere router. De "directly connected" route heeft namelijk altijd de voorkeur.

(In netwerken is alles vloeibaar overigens, zeker met SDN erbij, dus je zult vast een stuk hardware vinden wat iets anders doet maar in de basis geldt het bovenstaande.)

[ Voor 8% gewijzigd door CyBeR op 02-04-2013 12:58 ]

[Paul]

Heb je nou al een tekening? Want vooralsnog heb ik het probleem niet helder.

Ah, je wilt gaan firewallen. Tja, wat CyBeR al zegt, dat kan inderdaad een bottleneck opleveren. Om hoeveel VLANs en hoeveel verkeer hebben we het?

Die 6024, is dat je core? Is dat de distributielaag in je datacentrum? Is het de enige switch die je hebt? Zonder inzicht in je omgeving komen we niet verder dan "een 6024 doet geen PBR" en gaan we hooguit uitkomen bij het 2e plaatje in mijn eerdere post verwacht ik...

[Verwijderd]

Ik wilde nog even reageren op dit topic gezien ik dit inmiddels opgelost heb.

Door het toepassen van verschillende GW's werkt dit prima. Verkeer dat alleen op de switch moet blijven. Storage en VM Management gebruikt een IP op de switch als GW en alles wat naar buiten moet kunnen een t.o.v. de switch een externe GW.