L3 tot de access laag, waar te filteren?

[Yariva]

Ik zit met het volgende dilemma voor een DC design. Er wordt steeds meer gepushed richting een L3 design tot aan de access switches. Maar dit betekend ook (neem ik aan) dat inkomend verkeer op de access switch al kan worden gerouteerd op connected subnets. Ter reference heb ik snel een plaatje gepakt vanaf Cisco:


De vraag: waar zou ik het verkeer het beste kunnen filteren? Wanneer ik dit op de L3 access switches ga doen lijkt mij dit erg onoverzichtelijk wat betreft beheersbaarheid. Mij lijkt het beste om het verkeer centraal op een FW cluster ergens in de core te filteren. Wat is jullie ervaring hiermee, hebben sommige tips of blijven jullie L2 en spanning tree op de access laag draaien?

tldr: Hoe zorg ik ervoor dat 2 subnets op 1 access switch niet met elkaar communiceren.

Thanks!

[Barreljan]

Is je design puur native vlan, dus 'gewoon' laag 2? Of ga je laag2 naar 3 zetten via vxlan of iets dergelijks?
Wat wil je bereiken met je design? Wat zijn de voorwaarden en doelstellingen? Wat wil je er op draaien aan services (dus aan je access-laag)? Is het platte servers of iets met Vmware of....

De vraag ansich is access-lists, maar dat doe je niet op een access-switch. Daar ga je niet direct je L3 doen, tenzij het platform anders opgezet is dan je nu schets. Is het een kale L2 switch met L3 functies of een complete fully-featured L3 switch?

Ik zelf zou zeggen op basis van nul informatie en de waarschijnlijkheid dat het een soort KISS oplossing moet zijn;

access > access houden (puur L2 vlan)
core > core met integratie van distributie (dus een L3 router/chassis switchblades)

op je core dus je routing domains en dus interfaces om te filteren met access-lists, of het routeren via een hardware firewall (wat overigens ook in een blade als service kaart kan in je core chassis)

Maar goed, dit is simpel. Tenzij je inderdaad leuk wilt gaan doen met virtualisaties als VXLAN of EVPN (is L2 in L3 bijv. met een bgp routing structuur erachter om mac-adressen uit te wisselen, maar dat is een hele hele erge nutshell uitleg)

[knutsel smurf]

Waarom een L3 design? Ben je niet beter af om te kijken naar een fabric op L2 scheelt je heel veel configuratie.
VXlan is een overlay netwerk wordt je ook niet heel vrolijk van, blijf je namelijk een routing configuratie beheren.

Kijk naar spb ofwel 802.1aq dat zorgt ervoor dat je alleen op je vm omgeving of op de access laag Vlans hoeft te programmeren. En op het zelfde moment heb je ook je L2 subnets overal beschikbaar.

[Bigs]

Zet L2 buiten spel en trek L3 door tot op je hosts: Routing on the Host (hoeft uiteraard niet per se met Cumulus).

[Equator]

Afhankelijk van je doel, kijk naar "micro segmentation". Een dergelijke volledig gerouteerd netwerk is prima en ideaal in een grotere virtualisatie-omgeving. Met (bijvoorbeeld) VMware NSX kan je filteren op VM-naam, -functie, -IP etc. Het maakt dan niet meer uit of een VM met DMZ functie in subnet x, y of z staat. Je creëert een groep op basis van handmatige selectie of een dynamische op basis van kenmerken (alle VM's startende met dmz- bijvoorbeeld). En op deze groep plaats je de firewall rules

Als je nu weer wilt gaan filteren op subnet-basis, dan moet je of alles gaan filteren op de L3 switches of je gaat alle verkeer tot op de core brengen en daar door een firewall laten verlopen. Niet beheersbaar vs. niet efficient.

[knutsel smurf]

Bij Avaya doen we Hyper-Segmentation op L2, hierbij kan je een L2 of een L3 VSN (Virtual Service Network) creeren welke overal in je netwerk beschikbaar is.

Hierdoor hoef je dus geen overlay meer over je netwerk te gooien met bijvoorbeeld NSX. Een ander voordeel is dat je veel goedkopere hardware kan implementeren op de access. NSX werkt tot op de dichts bijzijnde VTEP, ofwel VXLAN gateway. En dit betekend in jouw scenrario je een VTEP nodig hebt op de access, of je bent weer L3 Routing aan het beheren tot de access. En het is natuurlijk zo dat een switch welke VXLAN gateway ondersteund een stukje duurder is.

Een ander veel groter voordeel van de Fabric en SPB architectuur is dat je in de core niks meer hoeft te configureren, en je alleen op de edge van je netwerk de VLAN's aan een VSN koppelt. Omdat de core en alle verbindingen gebruik maken van SPB 802.1aq heb je volledige redundantie en zal het verkeer altijd te kortste route kiezen om naar de juiste plek te gaan. Op de Edge/access heb je dan een relatief simpele access switch die de VSN weer aan het juist VLAN koppelt en thats it.

Natuurlijk is een van de problemen die je hierbij tegen komt dat je constant de default gateway moet aanpassen voor je applicaties of gebruikers die van locatie wisselen. Veelal veroorzaakt door de redundantie of disaster recovery datacenters en natuurlijk Vmotion die een VM verplaatst, hiervoor hebben we bij Avaya Distributed Virtual Routing (DVR) geimplementeerd op de switches. En dit zorgt ervoor dat netzoals bij NSX en Logical Virtual Routing (LVR) je verkeer niet meer tromboned en je altijd de mogelijkheid hebt om IP shortcuts te doen.

Onthoud goed dat NSX nog steeds een overlay protocol is en als je dit wilt door trekken naar de access laag je flink je buidel mag open trekken om VXLAN support te hebben.

[Equator]

knutsel smurf schreef op maandag 20 februari 2017 @ 11:34:
...
Onthoud goed dat NSX nog steeds een overlay protocol is en als je dit wilt door trekken naar de access laag je flink je buidel mag open trekken om VXLAN support te hebben.

Nee, NSX is geen overlay protocol. VxLAN is het overlay protocol. NSX is de tool waarmee je - met VxLAN - overlay netwerken kunt maken in VMware. (Voorheen was dat vCloud Networking & Security)

met NSX kan je virtuele firewalls/routers maken en beheren, distributed firewalls (dat is de functionaliteit waarmee je kunt micro segmenteren) en distributed logical routers aanmaken en beheren. Allemaal zonder dat je een overlay protocol hebt ingeschakeld.

Overigens zijn hardware VTEP's (L2/L3) alleen noodzakelijk om fysieke hardware aan te sluiten op een VxLAN netwerk. Voor elke andere use-case heb je geen hardware VTEP nodig. Je switches hoeven het dus ook niet te ondersteunen. De enige fysieke eis aan je underlay netwerk is dat het een MTU grootte van 1600 ondersteund. Je moet wel de meest uitgebreide versie van NSX draaien om HW VTEP's te ondersteunen

[ Voor 4% gewijzigd door Equator op 20-02-2017 15:43 ]

[Barreljan]

Equator schreef op maandag 20 februari 2017 @ 15:41:
[...]

Nee, NSX is geen overlay protocol. VxLAN is het overlay protocol. NSX is de tool waarmee je - met VxLAN - overlay netwerken kunt maken in VMware. (Voorheen was dat vCloud Networking & Security)

met NSX kan je virtuele firewalls/routers maken en beheren, distributed firewalls (dat is de functionaliteit waarmee je kunt micro segmenteren) en distributed logical routers aanmaken en beheren. Allemaal zonder dat je een overlay protocol hebt ingeschakeld.

Overigens zijn hardware VTEP's (L2/L3) alleen noodzakelijk om fysieke hardware aan te sluiten op een VxLAN netwerk. Voor elke andere use-case heb je geen hardware VTEP nodig. Je switches hoeven het dus ook niet te ondersteunen. De enige fysieke eis aan je underlay netwerk is dat het een MTU grootte van 1600 ondersteund. Je moet wel de meest uitgebreide versie van NSX draaien om HW VTEP's te ondersteunen

Kijk, een netwerker anno 2017

Jammer dat de TS niet zo actief is ..