Data Center Interconnect

[Azhrarn]

Wij hebben hier 2 geografische gescheiden computerzalen (elk een twaalftal racks, de naam datacenter niet echt waardig) Deze zijn momenteel verbonden met een L2 Trunk (2 *10 Gbps CWDM) tussen de L2 Cores (Elke L2 core : is 2*Nexus 5600 in vpc verband) tevens hebben we ook een L3-verbinding (opnieuw 2*10Gbps CWDM) die als campus layer ook dienst doet aan beide kanten (Elke L3-core : is 2*Cisco 6800 in VSS verband). Dit werkt redelijk goed, maar tegenwoordig is veel te veel nood aan VMWare VMotion om redundancy redenen. Het probleem is dat we momenteel asynchrone traffic flows krijgen (ontdekt door rare effecten met dhcp snooping) en traffic die teveel ping-pongt.
Ik ben nu op zoek naar een betere, deftige oplossing rekening houdend met deze bestaande cores.
Momenteel lijkt Cisco Fabric Path me het beste waarbij er ook nog wat ACL's komen om een HSRP active active te hebben. VXLAN lijkt me voor ons zware overkill. (Extra Licentie kosten Nexus (N5648Q-EL2P-SSK9) + VMWare Enterprise Plus voor VDS noodzaak anders geen VTEP dit voor minimum 40 servers met elk 2 cpu's... duur zaakje dan). Daarentegen zie ik soms ook referentie naar gewoon vPC te gebruiken tussen de 2 geografische L2 cores en HSRP ACL's.
- Eerste vraag is in dit geval, is Fabric Path zelfs niet een beetje Overkill. Of mis ik iets belangrijk om het te nemen. Ik wil vooral een robuuste oplossing om deze zaaltjes moeten 24/7 ALTIJD draaien. Downtime vermijden is het belangrijkste.
- Tweede vraag, we willen zeer waarschijnlijk in afzienbare toekomst TrustSec implementeren (SGT/SGACL/ISE/...) om Segmentation te kunnen doen. Gaat dit lukken in combinatie met Fabric Path?Fabric Path is encapsulation en TrustSec ook, vandaar de vraag.

Vriendelijke groeten.

[Barreljan]

Wellicht een situatie schets wel op zijn plaatst? Dat helpt ook andere lezer met een beeld te krijgen van de situatie en netwerk topologie nu

[ Voor 7% gewijzigd door Barreljan op 10-03-2017 15:06 ]

[Azhrarn]

Bij deze.

[Barreljan]

Maar oke, best flink gevulde plaat. Ik heb even wat uit elkaar gezet in een eigen tekeningetje. Het design an-sich versimpeld getekend is een prima design en zou geen direct probleem moeten hebben, tenzij je laag3 en laag2 verkeer of paden stomweg verkeerd gebruikt.




Waar zit nu je probleem? Je pingpong dan wel asynchrone verkeer dus. Je fiber-channel netwerk en de 3850's heb ik even uit het plaatje weggelaten want ik denk dat dit niet interesant is aan de kwestie. Mij overigens ook niet geheel duidelijk waar nu je vmware hosts zich bevinden. Zijn dat de SRV's ?

[Azhrarn]

De srv zijn inderdaad de esx hosts. En het probleem is inderdaad asynchrone verkeer en tevens vrees ik spanning tree die beide dc's zou plat krijgen. Wat mijn nightmare scenario is.

[Azhrarn]

3850 zijn verdiepingsswitches. De 3750x zijn de internet switches. In dit verhaal niet belangrijk.

[Teutlepel]

vMotion traffic een eigen L2 pad geven? Voor vMotion is het prima acceptabel om af en toe een STP hikje te krijgen.

[Azhrarn]

VMotion is niet echt een probleem maar zorgt wel voor HET probleem: ip adres van de verhuisde server moet blijven werken, vandaar de l2 trunk. 10 jaar geleden was er geen l2 trunk, enkel l3 zoals het hoort tussen de twee. Nu moeten alles kunnen blijven werken onafhankelijk van d e originele locatie. Enter fabric path voor de asynchrone routeringspaden (dhcp snooping miserie or worse firewalls die niet correct kunnen werken omdat ze de traffic niet zien of langs verkeerde paden bvb) en schrik voor spanning-tree: vrees dat een l2 trunk mijn stp probleem naar het andere dc ook zou kunnen overbrengen.

[ik222]

Je zou de benodigde L2 VLAN's in theorie natuurlijk prima via een MPLS / VPLS setup op twee locaties beschikbaar kunnen maken waarbij de link tussen de twee locaties puur L3 kan zijn. Dan zijn de spanning tree domeinen en eventuele hickups in elk geval beperkt tot 1 locatie.

Andere opmerking van mij zou zijn om zo weinig mogelijk direct aan het L2 / DC netwerk te koppelen.

Maar al met al heb je zeker geen slecht design. En als je het netwerk onder controle hebt is spanning tree ook niet eng als het goed geconfigureerd is.

[ Voor 10% gewijzigd door ik222 op 11-03-2017 09:22 ]

[Paul]

Azhrarn schreef op vrijdag 10 maart 2017 @ 14:14:
een L2 Trunk (2 *10 Gbps CWDM) tussen de L2 Cores [..] L3-verbinding (opnieuw 2*10Gbps CWDM)

Zijn dat dark fibers (de CWDM in de ene Nexus praat rechtstreeks met de CWDM SFP in de andere Nexus) of huurlijnen (die Nexus hangt aan iets van je fiber-boer, die het intern doorzet naar een andere switch waar je andere Nexus aan hangt) waar je een bepaald VLAN op hebt?

Het lijkt op dark fiber, en dan is dit ongeveer exact wat wij ook hebben: Nexussen (aan de ene kant, andere kant is Avaya) die alleen L2 doen en wat 6500's die routeren. Wij hebben een aantal stretched VLAN's die dus op beide locaties leven, dat zijn de server-VLAN's en de vMotion VLAN's.

In ons geval is de core aan één kant de router van een bepaald subnet (bijvoorbeeld de rechter set 6800's en dus proberen we de VM's die in dat subnet zitten zo veel mogelijk op de VMware hosts aan de rechterkant te hosten; alleen in geval van nood steken die over. Waar dat niet kan (clusters bijvoorbeeld, in allerlei vormen en maten, als het maar met de andere nodes in hetzelfde subnet wil zitten) dan zorgen we dat de actieve node(s) aan die kant huizen.

We staan op het punt de hele boel te vervangen door een stapel Avaya's met Shortest Path Bridging waardoor (bijna) iedere switch in het geheel voor een bepaald pakketje ineens de router kan zijn, waardoor we geen (of veel minder) rekening meer hoeven te houden aan welke kant de router van een subnet staat, maar ik kan me indenken dat dit (even alles vervangen) geen optie is voor je

Voor asynchrone traffic flows zou ik de boel goed uittekenen, kijken welke paden een pakketje af kan leggen en dan kijken of er path costs oid zijn ingesteld die je kunt tweaken.

[Azhrarn]

Ik222: ik denk dat nexus 5600 geen mpls/vpls ondersteund...

Paul: Jou setup is inderdaad vergelijkbaar met onze en ja het is dark fiber met 2 # fysische paden en providers. Waarom kies je avaya spb en niet gewoon extra fabric path licenties zoals ik denk te doen? Je kan met fhrp acl's toch een active/active router krijgen aan beide en path problemen oplossen of niet?

[ik222]

Azhrarn schreef op zaterdag 11 maart 2017 @ 11:55:
Ik222: ik denk dat nexus 5600 geen mpls/vpls ondersteund...

Dat klopt, de hele interconnect zou dan via je L3 core gaan. De Nexus switches zijn dan enkel per datacenter het L2 platform waar de servers aan hangen.

Maar in het algemeen zie je inderdaad tegenwoordig in nieuwe setups voor dit soort omgevingen veel meer SPB en aanverwanten technieken waar je op L2 kunt blijven zonder de klassieke nadelen van een groot L2 netwerk.

Wat betreft fabric path vs SPB, fabric path is natuurlijk puur een Cisco ding waar SPB een open standaard is. Overigens voor wat het waard is want je ziet op dit moment zoveel vendor specifieke "standaarden" of afgeleide van een standaard omhoog schieten dat interoperabiliteit tussen vendors sowieso een lastig punt is. SPB wordt ook niet door alle vendors ondersteund, Cisco bijvoorbeeld ondersteunt het voor zover ik weet op geen enkel model.

[JackBol]

Azhrarn schreef op zaterdag 11 maart 2017 @ 08:58:
VMotion is niet echt een probleem maar zorgt wel voor HET probleem: ip adres van de verhuisde server moet blijven werken, vandaar de l2 trunk.

Het probleem zit hier. Vraag jezelf even af waarom je dit nodig hebt.
Waarom vMotion je VMs tussen datacenters?

[Verwijderd]

JackBol schreef op zaterdag 11 maart 2017 @ 12:57:
[...]


Het probleem zit hier. Vraag jezelf even af waarom je dit nodig hebt.
Waarom vMotion je VMs tussen datacenters?

Waarom niet? Het is een prima manier om datacenter redundantie te realiseren. De huidige apparatuur kan hier echter geen optimale netwerk backbone voor maken.
Het is echter wel een feit dat te markt beweegt naar redundantie in software/services.

Je zult moeten werken met een overlay netwerk waarbij de beste oplossing MPLS/EVPN zou zijn van Juniper.
Hierbij kan je gerouteerd laag 2 verkeer tussen de datacentra voor elkaar krijgen. Nu is dat niet zo spannend en zou misschien ook wel kunnen met de Cisco apparatuur, erg efficiënt is het niet.
De echte oplossing zit in het feit dat je met EVPN de gateway van het subnet op meerdere locaties/routers, tegelijkertijd onder het zelfde MAC adres kan laten leven. Verder wordt er niet alleen meer op subnet gerouteerd maar elke host krijgt een /32 routing entry in de route tabellen. Hierdoor zal je altijd efficient routeren en nooit last hebben van trombone effecten.
Er bestaan (nog) geen firewalls die dit ondersteunen dus moet je die op een slimme manier buiten je EVPN omgeving plaatsen. De beste locatie hiervoor hangt van het design af.

Als afsluiter: Spanning tree is evil en moet dood. Anno 2017 is het echt niet meer acceptabel om spanning-tree nodig te hebben in je netwerk. Dat kan gelukkig slimmer en sneller.

[ Voor 10% gewijzigd door Verwijderd op 11-03-2017 17:32 ]

[Equator]

STP moet inderdaad dood, hoe eerder hoe beter.

Maar ik snap iets niet. Of ik heb het niet goed gelezen.

Je hebt alle tools ter beschikking om een datacenter fabric te maken met Cisco FabricPath maar dat lijk je niet te gebruiken. Tussen je DC's wil je eigenlijk alleen maar L3 links. Met FabricPath kan je daaroverheen een L2 Netwerken maken voor de toepassing die jij wilt. Dus de voordelen van L3 en toch een stretched VLAN.

Overkill, nee totaal niet.

Nog een vraagje: waarom heb je de L3 links gebundeld? Daar zou ik 2 of 4 losse point to points van maken met een /31. Dus ECMP. OSPF regelt de rest wel. Of heb je de bandbreedte nodig?

NSX even verwijderd omdat je al aangeeft dat niet te kunnen of willen betalen..

[ Voor 39% gewijzigd door Equator op 11-03-2017 19:30 ]

[knutsel smurf]

Paul schreef op zaterdag 11 maart 2017 @ 09:51:
[...]
Zijn dat dark fibers (de CWDM in de ene Nexus praat rechtstreeks met de CWDM SFP in de andere Nexus) of huurlijnen (die Nexus hangt aan iets van je fiber-boer, die het intern doorzet naar een andere switch waar je andere Nexus aan hangt) waar je een bepaald VLAN op hebt?

Het lijkt op dark fiber, en dan is dit ongeveer exact wat wij ook hebben: Nexussen (aan de ene kant, andere kant is Avaya) die alleen L2 doen en wat 6500's die routeren. Wij hebben een aantal stretched VLAN's die dus op beide locaties leven, dat zijn de server-VLAN's en de vMotion VLAN's.

In ons geval is de core aan één kant de router van een bepaald subnet (bijvoorbeeld de rechter set 6800's en dus proberen we de VM's die in dat subnet zitten zo veel mogelijk op de VMware hosts aan de rechterkant te hosten; alleen in geval van nood steken die over. Waar dat niet kan (clusters bijvoorbeeld, in allerlei vormen en maten, als het maar met de andere nodes in hetzelfde subnet wil zitten) dan zorgen we dat de actieve node(s) aan die kant huizen.

We staan op het punt de hele boel te vervangen door een stapel Avaya's met Shortest Path Bridging waardoor (bijna) iedere switch in het geheel voor een bepaald pakketje ineens de router kan zijn, waardoor we geen (of veel minder) rekening meer hoeven te houden aan welke kant de router van een subnet staat, maar ik kan me indenken dat dit (even alles vervangen) geen optie is voor je

Voor asynchrone traffic flows zou ik de boel goed uittekenen, kijken welke paden een pakketje af kan leggen en dan kijken of er path costs oid zijn ingesteld die je kunt tweaken.

De oplossing in mijn visie is inderdaad zoals Paul hier zegt. Nu werk ik bij Avaya. En kan je zeggen je hoeft niet alles te vervangen.

Je kan de fabric ook als overlay gebruiken. Kijk even naar deze video. YouTube: Deploying SDN Fx Fabric Connect into existing networks

Als je bijvoorbeeld ervoor kiest om te beginnen bij de TOR switches denk ik dat 90% van je problemen al de wereld uit zijn.

[The Eagle]

Verwijderd schreef op zaterdag 11 maart 2017 @ 17:29:
[...]


Waarom niet? Het is een prima manier om datacenter redundantie te realiseren. De huidige apparatuur kan hier echter geen optimale netwerk backbone voor maken.
Het is echter wel een feit dat te markt beweegt naar redundantie in software/services.

Omdat nu redundancy en high availability door elkaar gehaald worden. HA moet je binnen je DC oplossen, DR over datacenters. Wat er nu gebeurt is, zoals ik het lees, een failover van een actieve VM naar het tweede DC. Dan is de vraag: waarom? En vraag twee: hoezo kun je dat niet gewoon in je eerste DC oplossen? Lijkt me een kwestie van een extra ESXi host en gaan
Een tweede DC gebruik je idd als datacenter failovr, of als tweede primaire locatie. Niet om zomaar naar toe te failoveren. Dat het kan wil nog niet zeggen dat je het zo moet doen

Je zult moeten werken met een overlay netwerk waarbij de beste oplossing MPLS/EVPN zou zijn van Juniper.
Hierbij kan je gerouteerd laag 2 verkeer tussen de datacentra voor elkaar krijgen. Nu is dat niet zo spannend en zou misschien ook wel kunnen met de Cisco apparatuur, erg efficiënt is het niet.
De echte oplossing zit in het feit dat je met EVPN de gateway van het subnet op meerdere locaties/routers, tegelijkertijd onder het zelfde MAC adres kan laten leven. Verder wordt er niet alleen meer op subnet gerouteerd maar elke host krijgt een /32 routing entry in de route tabellen. Hierdoor zal je altijd efficient routeren en nooit last hebben van trombone effecten.
Er bestaan (nog) geen firewalls die dit ondersteunen dus moet je die op een slimme manier buiten je EVPN omgeving plaatsen. De beste locatie hiervoor hangt van het design af.

Als afsluiter: Spanning tree is evil en moet dood. Anno 2017 is het echt niet meer acceptabel om spanning-tree nodig te hebben in je netwerk. Dat kan gelukkig slimmer en sneller.

[Bigs]

Even out of the box gedacht: Voor vMotion heb je sinds vSphere 6 geen gedeeld L2 segment meer nodig. Het IP behouden in de tweede locatie kun je doen door dat IP (dus een /32 of /128 netwerk) vanaf de host aan te kondigen aan de lokale router via OSPF of (unnumbered) BGP. Als ik het goed begrijp heb je daar de routers al voor en als je Linux of BSD draait is de aankondiging met Quagga eenvoudig in te richten.

[ Voor 3% gewijzigd door Bigs op 12-03-2017 10:10 ]

[Paul]

The Eagle schreef op zondag 12 maart 2017 @ 09:50:
Wat er nu gebeurt is, zoals ik het lees, een failover van een actieve VM naar het tweede DC. Dan is de vraag: waarom?

Omdat lang niet alle applicaties meerdere servers ondersteunen, en als we er dan toch de infra voor hebben kan het goed zijn dat de business besluit dat dit goed genoeg is en een aantal zaken die het wel zouden kunnen ineens niet meer redundant hoeven.[/]En vraag twee: hoezo kun je dat niet gewoon in je eerste DC oplossen?[/]Omdat dat één fysieke locatie is, en dus stuk kan. Als de boel tot de grond toe afbrand dan gaat die extra ESXi host gewoon mee down...

Onze beide datacentra zijn beide primair. Echter, van een heleboel applicatieservers kan men of wil men geen redundante setup maken maar vindt men VMware HA goed genoeg. Waarom dan moeilijk gaan doen als dit ook gewoon werkt?

[JackBol]

Paul schreef op zondag 12 maart 2017 @ 10:20:
[...]
Omdat lang niet alle applicaties meerdere servers ondersteunen, en als we er dan toch de infra voor hebben kan het goed zijn dat de business besluit dat dit goed genoeg is en een aantal zaken die het wel zouden kunnen ineens niet meer redundant hoeven.[/]En vraag twee: hoezo kun je dat niet gewoon in je eerste DC oplossen?[/]Omdat dat één fysieke locatie is, en dus stuk kan. Als de boel tot de grond toe afbrand dan gaat die extra ESXi host gewoon mee down...

Onze beide datacentra zijn beide primair. Echter, van een heleboel applicatieservers kan men of wil men geen redundante setup maken maar vindt men VMware HA goed genoeg. Waarom dan moeilijk gaan doen als dit ook gewoon werkt?

Als je L3 core of je L2 switches down gaan kan je al niet meer vMotionen naar de andere kant. Als je storage het begeeft ben je ook klaar.

vMotion als Disaster Recovery lijkt een makkelijke oplossing, maar als de shit echt de fan fan hit, lost het niets voor je op.

[Equator]

Of het nu vMotion, SRM of Zerto is.. Als de VM naar het andere DC moet zonder IP herconfig, dan is een L2 netwerk noodzakelijk.
Dat dit voor nieuwe applicatie servers niet meer nodig is, omdat deze enige hoog beschikbaarheid kennen op applicatie niveau, houdt niet in dat het voor legio legacy applicatie servers nog nodig is.

Zullen we de discussie over hoe hoge beschikbaarheid voor VM's te krijgen elders vieren? Desnoods in een eigen topic.

[JackBol]

Equator schreef op zondag 12 maart 2017 @ 12:16:
Of het nu vMotion, SRM of Zerto is.. Als de VM naar het andere DC moet zonder IP herconfig, dan is een L2 netwerk noodzakelijk.

Er zijn genoeg overlay solutions waarbij dat niet meer nodig is.

[The Eagle]

Paul schreef op zondag 12 maart 2017 @ 10:20:
[...]
Omdat lang niet alle applicaties meerdere servers ondersteunen, en als we er dan toch de infra voor hebben kan het goed zijn dat de business besluit dat dit goed genoeg is en een aantal zaken die het wel zouden kunnen ineens niet meer redundant hoeven.[/]En vraag twee: hoezo kun je dat niet gewoon in je eerste DC oplossen?[/]Omdat dat één fysieke locatie is, en dus stuk kan. Als de boel tot de grond toe afbrand dan gaat die extra ESXi host gewoon mee down...

En dus zorg je dat de storage onder je VM's wel gemirrord is
Als de boel op DC 1 plat gaat breng je ze in DC 2 weer op. Uiteraard wel zorgen dat je daar je schaduw VLAN's geconfigureerd (maar slapend) hebt, anders start de boel alsnog niet

Onze beide datacentra zijn beide primair. Echter, van een heleboel applicatieservers kan men of wil men geen redundante setup maken maar vindt men VMware HA goed genoeg. Waarom dan moeilijk gaan doen als dit ook gewoon werkt?

Applicatieservers is idd een vak apart. Staat me bij dat we die discussie al eens eerder gehad hebben. Staat me ook bij dat je dan een loadbalancer moet hebben en een dubbele applicatiestack (die naar de zelfde DB connect) om het goed te kunnen draaien. Kost dus euro's

[Equator]

JackBol schreef op zondag 12 maart 2017 @ 12:24:
[...]


Er zijn genoeg overlay solutions waarbij dat niet meer nodig is.

En als je naar mijn volledige antwoord had gekeken, of de post van mij eerder, dan had je geweten dat ik dat ook weet. Of het nu TRILL of Cisco variant FabricPath, VxLAN, SPB of iets anders is, het blijft een laag 2 netwerk. Daar ging het om, niet of het al dan niet noodzakelijk is om een VM wel of niet naar een ander DC te migreren.

[ Voor 3% gewijzigd door Equator op 12-03-2017 16:20 ]

[tomtom901]

ik222 schreef op zaterdag 11 maart 2017 @ 09:21:
Je zou de benodigde L2 VLAN's in theorie natuurlijk prima via een MPLS / VPLS setup op twee locaties beschikbaar kunnen maken waarbij de link tussen de twee locaties puur L3 kan zijn. Dan zijn de spanning tree domeinen en eventuele hickups in elk geval beperkt tot 1 locatie.

Andere opmerking van mij zou zijn om zo weinig mogelijk direct aan het L2 / DC netwerk te koppelen.

Maar al met al heb je zeker geen slecht design. En als je het netwerk onder controle hebt is spanning tree ook niet eng als het goed geconfigureerd is.

Wel oppassen dat je BPDU's niet over het VPLS gaan anders heb je nog steeds gewoon 1 STP toplogoy. Het meest toekomstgericht zou zijn om te kijken naar een overlay oplossing zoals al genoemd is VXLAN met EVPN als control plane om het trombone effect ook te mitigeren en op een goede manier een DCI te bouwen.

[knutsel smurf]

Is er überhaupt budget om iets te doen aan de situatie?
We kunnen wel mooie oplossingen bedenken. En er zijn goede oplossingen mogelijk, VxLAN of een gedeelte SPBm.

Je kan natuurlijk wel naar je refresh cycli kijken en zien of je iets naar voren kan trekken.

Ik ben zelf geen fan van een overlay omdat je dan eigenlijk het echte probleem niet aan pakt. Maar als dat het geen is wat binnen je budget past dan doen.

[JackBol]

knutsel smurf schreef op zondag 12 maart 2017 @ 22:16:
Is er überhaupt budget om iets te doen aan de situatie?
We kunnen wel mooie oplossingen bedenken. En er zijn goede oplossingen mogelijk, VxLAN of een gedeelte SPBm.

Je kan natuurlijk wel naar je refresh cycli kijken en zien of je iets naar voren kan trekken.

Ik ben zelf geen fan van een overlay omdat je dan eigenlijk het echte probleem niet aan pakt. Maar als dat het geen is wat binnen je budget past dan doen.

Je kan traffic tromboning nooit in de underlay aanpakken. Zelfs "underlay" oplossingen zoals Cisco's ACI gebruiken tunnelling technologie. Anycast gateway komt in de buurt voor egress verkeer, maar dan zal je voor ingress verkeer alsnog een prefix moeten originaten vanuit meerdere plekken, waardoor je ingress niet optimaal is.

[knutsel smurf]

Jawel dat kan wel! Bij Avaya hebben we DVR wat dit voorkomt. Alleen de topic starten heeft geen Avaya netwerk.

Je zal naar een fundamenteel andere architectuur moeten maar traffic tromboning kan met Distributed Virtual Routing worden voorkomen.

[ Voor 38% gewijzigd door knutsel smurf op 12-03-2017 22:23 ]

[JackBol]

knutsel smurf schreef op zondag 12 maart 2017 @ 22:21:
Jawel dat kan wel! Bij Avaya hebben we DVR wat dit voorkomt. Alleen de topic starten heeft geen Avaya netwerk.

Je zal naar een fundamenteel andere architectuur moeten maar traffic tromboning kan met Distributed Virtual Routing worden voorkomen.

Dit werkt alleen voor oost-west verkeer (bijv. als je je front proxy en app server in een verschillend subnet hebt). Wanneer verkeer je datacenter in/uit gaat (zoals bijv. een client die de applicatie wil gebruiken) dan zit je wederom weer met het probleem waar je je prefix moet originaten.

Edit: overigens is DVR geen unieke capability van Avaya. Alle datacenter boeren (Cisco, Arista) hebben iets vergelijkbaars.

[ Voor 8% gewijzigd door JackBol op 12-03-2017 22:27 ]

[knutsel smurf]

Ook dat kunnen we tegenwoordig oplossen met shortcuts.
Voor de applicaties kunnen we een L3 VSN met shortcuts en DVR altijd een en het zelfde gateway adres geven zodat we ook dat kunnen oplossen.

Edit:
AVAYA heeft het patent op DVR binnen SPBm
En idd met NSX is er een vergelijkbare functie.

Ook moet je vermelden dat arista en cisco geen L2 oplossing heeft dat als underlay het zelfde kan als SPBm. Zelfde geld voor de andere vendors die je noemt. De enige die in de buurt komen zijn Huawei en Alcatel-lucent.

[ Voor 44% gewijzigd door knutsel smurf op 12-03-2017 22:38 ]

[JackBol]

knutsel smurf schreef op zondag 12 maart 2017 @ 22:29:
Ook dat kunnen we tegenwoordig oplossen met shortcuts.
Voor de applicaties kunnen we een L3 VSN met shortcuts en DVR altijd een en het zelfde gateway adres geven zodat we ook dat kunnen oplossen.

Edit:
AVAYA heeft het patent op DVR binnen SPBm
En idd met NSX is er een vergelijkbare functie.

Ook moet je vermelden dat arista en cisco geen L2 oplossing heeft dat als underlay het zelfde kan als SPBm. Zelfde geld voor de andere vendors die je noemt. De enige die in de buurt komen zijn Huawei en Alcatel-lucent.

Backbone bridging is iets wat Avaya ge-erft heeft uit de Nortel inboedel, en daar was 't al geen succes.
Wie kan er tegenwoordig nog mac-in-mac troubleshooten?

Ik zie verder de hele wereld naar VXLAN met EVPN control-plane bewegen. Alles IP. Lekker makkelijk.

[knutsel smurf]

Weet je dat SPB maar 1 enkel protocol betekent en dat dit dus veel makkelijker te troubleshooten is dan andere oplossingen.

De hele wereld doet wat cisco marketing je verteld. Wordt het niet eens tijd dat mensen verder kijken dan cisco?

[tomtom901]

knutsel smurf schreef op zondag 12 maart 2017 @ 23:06:
Weet je dat SPB maar 1 enkel protocol betekent en dat dit dus veel makkelijker te troubleshooten is dan andere oplossingen.

De hele wereld doet wat cisco marketing je verteld. Wordt het niet eens tijd dat mensen verder kijken dan cisco?

Wij van WC eend.. ook Juniper zet er onder andere hard op in, zelfs Cumulus Linux doet gewoon VXLAN/EVPN dus een beetje een rare opmerking is het wel. Ik ken de details van SPB op Arista niet, dus daar kan ik niets over zeggen.

[JackBol]

tomtom901 schreef op maandag 13 maart 2017 @ 12:53:
[...]


Wij van WC eend.. ook Juniper zet er onder andere hard op in, zelfs Cumulus Linux doet gewoon VXLAN/EVPN dus een beetje een rare opmerking is het wel. Ik ken de details van SPB op Arista niet, dus daar kan ik niets over zeggen.

Arista doet ook VXLAN/EVPN.

[Azhrarn]

Hmmm heb er hier even met mijn integrator over gesproken en die denkt dat voor ons doen en laten, de huidige L2 Trunk met vPC relationship voldoende zou moeten zijn. (Tenslotte toch maar 2 verschillende DC's) Niettegenstaande enkele wijzigingen als SVI (L3 Vlan) grotendeels van de 6800 verplaatsen naar de Nexussen indien deze volledig de L2 al deden hiervoor. Tevens de HSRP ACL's waarschijnlijk. Eventueel GLBP herzien. (Support op 5600 is onduidelijk: Volgens de cli en de featurenavigator zou het er moeten zijn, maar wel geen release notes, want origineel was het er niet... vreemd...) Tevens wist hij mij te vertellen dat mijn plannen voor segmentatie met TrustSec/SGT/SGACL weleens problemen zouden kunnen krijgen met Fabric Path. Schijnbaar geeft die combo al eens problemen ondanks dat dit volgens doc zou moeten werken. Soit voor mij komt het er op neer dat ik enkel consultancy moet betalen voor een optimalisatie die toch nodig was. Indien achteraf blijkt dat het niet de perfecte oplossing is, dan is er toch al veel opgekuist en veel opgeklaard van wat er nu echt moet komen.
Basically : Het KISS moto is misschien hier wel van toepassing: Fabric Path is leuk, maar do we REALLY need it? Wat denken jullie?

Equator : Jouw opmerking voor ECMP begrijp ik niet zo goed. Wat is er zoveel beter an ECMP vergeleken met een L3 portchannel? Beide werken ze anders, maar LACP werkt wel sneller en meer opties voor bandwidth sharing om maar te zwijgen over troubleshooting...

[JackBol]

Azhrarn schreef op maandag 13 maart 2017 @ 15:36:
Eventueel GLBP herzien.

GLBP geeft round-robin verschillende MAC adressen aan clients. Je trombone en troubleshoot problemen worden hiermee alleen maar groter.

Basically : Het KISS moto is misschien hier wel van toepassing: Fabric Path is leuk, maar do we REALLY need it? Wat denken jullie?

Je lost dit probleem fundamenteel alleen op met een overlay tunneling solution. Of dat nu VXLAN (IP-in-IP) of SBP (Mac-in-Mac) is, dat maakt niet zoveel uit. Het fundamentele probleem is dat je de VM-locatie en de VM-identiteit los van elkaar moet gaan zien. En dat kan niet zonder een abstractielaag.

Equator : Jouw opmerking voor ECMP begrijp ik niet zo goed. Wat is er zoveel beter an ECMP vergeleken met een L3 portchannel? Beide werken ze anders, maar LACP werkt wel sneller en meer opties voor bandwidth sharing om maar te zwijgen over troubleshooting...

In de meeste hardware implementaties (ASICs) gebruiken LACP en ECMP dezelfde hashing logic. Dus qua bandwidth gebruik zou het niet uit moeten maken.

[knutsel smurf]

tomtom901 schreef op maandag 13 maart 2017 @ 12:53:
[...]


Wij van WC eend.. ook Juniper zet er onder andere hard op in, zelfs Cumulus Linux doet gewoon VXLAN/EVPN dus een beetje een rare opmerking is het wel. Ik ken de details van SPB op Arista niet, dus daar kan ik niets over zeggen.

Wil je toch eens aanraden om het volgende artikel te lezen. http://nojitter.com/post/...rking-impacts-it-security

[JackBol]

knutsel smurf schreef op dinsdag 14 maart 2017 @ 23:27:
[...]


Wil je toch eens aanraden om het volgende artikel te lezen. http://nojitter.com/post/...rking-impacts-it-security

Jeejtje, SPB is het gouden ei! En niemand ziet het! Het is denk ik een samenzwering van de grote networkvendors. Zonder grote hacks kunnen ze natuurlijk geen security products meer verkopen....

/s


On topic: segmentation, ephimiral subnets, overlays, het blijft moeilijk zolang je het niet goed automatiseerd. Wij netwerkmensen moeten gaan leren om tools als Ansible te gaan gebruiken en met onze dikke vingers van de CLI te blijven. Door automated scripts, via controllers gedeployde overlays, dat is de toekomst.


En nogmaals, SPB is gewoon Mac-in-mac encapsulation, net zoals VxLan een ip-in-ip encapsulatie is, maar dan 1 osi laagje dieper.
Als je op basis van dat artikel gelooft dat een encap technologie je security problemen oplost heb je echt teveel van je eigen koolaid gedronken.

[Predator]

Azhrarn schreef op maandag 13 maart 2017 @ 15:36:
Hmmm heb er hier even met mijn integrator over gesproken en die denkt dat voor ons doen en laten, de huidige L2 Trunk met vPC relationship voldoende zou moeten zijn. (Tenslotte toch maar 2 verschillende DC's) Niettegenstaande enkele wijzigingen als SVI (L3 Vlan) grotendeels van de 6800 verplaatsen naar de Nexussen indien deze volledig de L2 al deden hiervoor.

Wij hebben een redelijk gelijkaardige setup als jullie, alleen iets kleiner Alleen heb ik de layer 2 DCI op de cores (CAT 4500X VSS), daar zit ook de layer 3. Ik heb maar 2 DCI links, en met Nexus waren er toen nog issues voor L3 (SVI) &L2 over dezelfde links. Tussen de DC cores en de campus zitten er L3 links met ECMP. Ik wilde absoluut geen L2 meer tussen beide cores. De DC L2 is Nexus Vpc based.

Basically : Het KISS moto is misschien hier wel van toepassing: Fabric Path is leuk, maar do we REALLY need it? Wat denken jullie?

In niet al te grote omgevingen met maar 2 DC's zie je toch nog vaak dat er gewoon L2 interconnectie draait.
FabricPath/VxLAN/OTV zijn zeker prima DC technologieën maar personeel wordt duurder en duurder, en niet iedereen kan elke 3 jaar heel de boel vernieuwen ...

Equator : Jouw opmerking voor ECMP begrijp ik niet zo goed. Wat is er zoveel beter an ECMP vergeleken met een L3 portchannel? Beide werken ze anders, maar LACP werkt wel sneller en meer opties voor bandwidth sharing om maar te zwijgen over troubleshooting...

ECMP convengeert nog iets sneller dan LACP op veel platformen. ECMP heeft ook redelijk wat opties voor loadsharing. Als je ook nog eens OSPF met BFD gebruikt, dan wint ECMP het van LACP. In de praktijk maakt het niet zoveel uit imho.

PS: Ik doe wel enkele zaken anders dan jou denk ik. Als ik het goed begrijp heb je spanning-tree ook actief op de DCI links ? Ik heb dat bewust niet. Ik filter de BPDU's op de L2 DCI links. Hier vertrouw ik op o.a. LACP om de link in suspend te zetten bij assym link.

Doe je nu niet aan FHRP isolatie ? Dat doe ik iig wel. FHRP groepen zijn active/active aan beide kanten.

PPS: Ik heb 1 maal gehad dat de hele DC meuk tegen de grond ging. Maar dat was eigenlijk niet de fout van spanning-tree, maar van de VSS
Toen had ik Fast Hello & ePAGP dual active detection actief. Na een ISSU upgrade stonden de PAGP links op de standby "notconnect", er ging echter wel traffic door, maar spanning-tree draaide er niet. Poort stond namelijk nog "notconnect" Not my best weekend
Cisco TAC heeft me eigenlijk vlakaf gezegd: If you can have a maintenance windows, don't use ISSU with VSS, do a full reload.

Ik heb uiteindelijk de ePAGP meuk gewoon verwijderd, en de Fast Hello gehouden .

[Azhrarn]

Na interne discussie hier is besloten om de kat nog even uit de boom te kijken. We gaan eerst optimaliseren : Traffic flows uittekenen, en kijken wat we aan de STP setup kunnen verbeteren. Dit is tenslotte ons enige echte probleem. En ivm de Disaster Recovery : Spanning Tree zal wel niet zo een groot probleem geven bij ons aangezien we alles over 1 grote PortChannel trunken en we gaan HSRP ACL's toepassen. Geen logische loops tussen de twee mogelijk. Gezien de noodzaak van TrustSec in de nabije toekomst (segmentering netwerk dit jaar), is dit waarschijnlijk de beste oplossing (Fabric Path+TrustSec=Weird Problems blijkbaar). Deze netwerk virtualisatie technieken veranderen nog regelmatig. Ik durf er om te wedden dat over 2 à 3 jaar er een nieuwe nog betere techniek is... Soit, het zou misschien beter zijn, maar ik krijg stilaan het gevoel dat dit een mug dood doen is met een kanon.
Bedankt voor jullie inzichten.