Scaleway Approach to VXLAN EVPN Fabric
•Download as PPTX, PDF•
1 like•1,243 views
- Scaleway uses VXLAN with BGP EVPN to build an overlay fabric on their network infrastructure. This provides multi-tenancy, encapsulation of Ethernet frames over UDP, and support for both bridging and routing. - The underlay fabric uses Clos topology with IPv4 and eBGP for high bandwidth and resilience. Edge devices run as VTEPs to connect virtual networks over the overlay. - A virtual route reflector provides the control plane for the overlay fabric, decoupling it from the underlying hardware. This allows routing between subnets and multi-homing of hosts between VTEPs.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Scaleway Approach to VXLAN EVPN Fabric
Similar to Scaleway Approach to VXLAN EVPN Fabric (20)
More from Scaleway
More from Scaleway (20)
Recently uploaded
Recently uploaded (20)
Scaleway Approach to VXLAN EVPN Fabric
- 1. Delbecq Adrien SeniorNetworkSRE@Scaleway Scaleway’s approach to VXLAN + BGP EVPN Fabric
- 2. Summary • Reminder VXLAN + BGP EVPN • Fabric Underlay • Fabric Overlay • What’snext ? Scaleway’s approachto VXLAN– EVPN 2
- 3. VXLAN Terminology • VXLAN: Virtual eXtensibleLAN • VTEP : VXLAN TunnelEndpoint • VNI : VXLAN NetworkIdentifier • NVE: Network Virtual Interface VXLAN– BGPEVPN 3
- 4. VXLAN Concept • rfc 7348 • Data-planetechnology • EncapsulateEtherneton top of UDP • Support Bridging &Routing • Multi– tenant(up to 16M VNI) • Hardware support VXLAN– BGPEVPN 4
- 6. BGPEVPN Concept • rfc 8365 • Controlplane technology • Another BGP Address-family • from MPLSEVPN (rfc7432) • Support multipleencapsulation VXLAN– BGPEVPN 6
- 7. BGPEVPN –route types • Type 1 : Ethernet autodiscovery • Type 2 : Host (mac + mac-ip) routes • Type 3 : Inclusive Multicast Ethernet tag route • Type 4 : Ethernet Segment Route • Type 5 : Ip Prefix Route • … VXLAN– BGPEVPN 7
- 8. VXLAN/BGPEVPN – type2 ,bridging VXLAN– BGPEVPN 8
- 9. VXLAN/BGPEVPN – routing,type5 / type2symmodel VXLAN– BGPEVPN 9
- 10. BGPEVPN –type 2,routing,asymmodel VXLAN– BGPEVPN 10
- 11. Layer1 :Remember Clos Fabric Underlay 11
- 12. Closscale: moreingress/egress ? Fabric Underlay 12
- 16. DataPlane:IPv4 Fabric Underlay • No extendedbroadcast domain • IPv6 underlay was not available/ready • L3 sub-interfaceeverywhere • Efficientloop prevention • ECMP: 100%bandwith used 16
- 17. Control Plane:eBGP Fabric Underlay • No link-state protocol • No OSPF • No IS-IS • iBGP isn’t really good as IGP • eBGP just fits • RFC7938 – draft Lapukhov • No BFD 17
- 19. Addressing plan Fabric Underlay • Internet-likeaddressing plan • Use nextavailableprefix • No waste • Topology–driven addressing • IP address = function ( topology ) • Human-friendly 19
- 21. Managementthroughunderlay Fabric Underlay • KISS • Resilient(hello BGP) • It just works 21
- 22. Everything isnow running on overlay Fabric Overlay • Adm, bmc (ipmi) • Publictraffic • VPC (coming soon) • … • Underlay only persists for shelves management 22
- 23. Agnosticspine &superspine Fabric Overlay • Spineand superspine are not VXLAN aware : • KISS • Less FIB usage • Less features • Cheaper 23
- 24. Virtualized Route-reflector Fabric Overlay • Connected on edgeleaves • Independant from shelves • Easyto replace withanother control plane • Cisco xrv, Juniper vRR, Arista vEOS… • Bird, FRR… • HV could handle other services • Route-injector 24
- 25. Routing onlythroughtype 5 Fabric Overlay • Type 5 routingonly • Type 2 bridging only : no mix 25
- 26. Host multihoming Fabric Overlay • L3 on HV could work • But, how to do itwith Baremetalservices ? • How to scalebgp sessions number (per vrf) ? • ESI + MC-LAG light= standard • But isn’treally plebiscitedby vendors • Anycast VTEP + MC-LAG • Non standard • It justworks 26
- 27. Host multihoming– Anycast VTEP+ MC-LAG Fabric Overlay 27
- 28. SoftwareVTEP Fabric Future • Compatiblewith hw vtep • Bring your own Control-Plane • No hardware limits(tcam,fib) … • Limitedperformance (cpu vsasic/fpga) 28
- 29. Scaling–hub&spoke- sharding Fabric Future • scalelimitrelatedto FIB – More and more prefixes • Does allleafneed allroutes ? 29
- 30. Scaling–hub&spoke Fabric Future 30 Scaling – hub&spoke Fabric Future 31
- 32. Multi-vendor interoperabilty Fabric Future • Cisco– Juniper Interoperabilty? – Bridging OK – Routing type 5 OK – Routing type 2 KO * Cisco use SYM IRB routing with t2 * Juniper useASYM IRB routing with t2 32
- 33. whitebox Fabric Future • Bring your own Control-Plane • Standard Linux OS : – same automation than onsoft VTEP • SameASICs (helloBroadcom Trident) • Cheaper 33
- 34. Thank you Follow meonLinkedin andtwitter @Adelbecq 34
Editor's Notes
- Bonjour [Breath] Je m’appelle Adrien DELBECQ, Je suis ingénieur réseau chez Scaleway, Et je suis spécialisé en réseau DC. [Breath] On va s’intéresser ojd à l’IP Fabric et voir comment on peut designer un réseau Scalable et multi-service en centre de données.
- Udp 4789 par défaut Hardware support : Bridging depuis un moment Single pass sur routing depuis moins longtemps Hyperloop interne ou externe
- Vxlan : 8bytes Udp : 8bytes Ipv4 :20 bytes -> 40 en v6 Ethernet: 14bytes + 4 si dot1q
- Vxlan nous décrit comment transporter les paquets, à traver un tunnel entre 2 VTEP Il faut également adresser la problématique du signaling : Vers quelles VTEP je dois envoyer mon traffic pour joindre tel mac, ip, prefix ? On pourrait imaginer faire du signaling static et user/abuser des configurations statiques ou utiliser un vrai outil …
- Type1 : accelere la convergence dans les cas de multihoming via ESI Type2: comment joindre un host distant ? Mac learning Ip/mac learning (arp like) Type3: requis pour le BUM Vers quel VTEP est-ce que je dois flood mon BUM ? Type 4 : Ethernet Segment Route Pour élire le segment vers lequel fwd le traff en cas de multihoming (ESI) Type 5 : prefix advertisement
- Un lookup sur le VTEP EGRESS Un lookup sur le VTEP INGRESS
- asymetric Pas de routage en INGRESS : uniquement en EGRESS Le choix de Juniper, plus historique Transition -> quels sont nos choix ?
- CLOS 3 : 3 sauts pour aller d’un node à un autre node Résistant aux outage Facile à rendre non bloquant Comment scale ? Si je veux plus d’uplinks sur un leaf : je rajoute un spine Limite du nombre de leaf = fonction du nombre de ports sur le spine Si je veux plus de port clients : je rajoute un leaf Limite de la capacité d’un leaf = fonction du nombre d’uplink du leaf Quand le spine est plein ? Scale vertical du spine Passage à Clos 5
- CLOS 3 : 3 sauts pour aller d’un node à un autre node Résistant aux outage Facile à rendre non bloquant Comment scale ? Si je veux plus d’uplinks sur un leaf : je rajoute un spine Limite du nombre de leaf = fonction du nombre de ports sur le spine Si je veux plus de port clients : je rajoute un leaf Limite de la capacité d’un leaf = fonction du nombre d’uplink du leaf Quand le spine est plein ? Scale vertical du spine Passage à Clos 5
- CLOS 3 : 3 sauts pour aller d’un node à un autre node Résistant aux outage Facile à rendre non bloquant Comment scale ? Si je veux plus d’uplinks sur un leaf : je rajoute un spine Limite du nombre de leaf = fonction du nombre de ports sur le spine Si je veux plus de port clients : je rajoute un leaf Limite de la capacité d’un leaf = fonction du nombre d’uplink du leaf Quand le spine est plein ? Scale vertical du spine Passage à Clos 5
- CLOS 5 : 5 sauts max pour aller d’un node à un autre node Scale horizontal vs scale vertical Plutôt que d’agrandir mon spine, et donc d’en prendre un plus cher : j’en rajoute d’autres D’autres facons de faire du multi-stage clos, notament en introduisant la notion de Vspine : mieux !
- Pas sur les spine, contrairement à ce qu’on pourrait penser : On respecte le modele clos : edge connectivity == une connectivité comme une autre Easy to scale Border Leaf / Edge Leaf
- On a suffisament parlé des problématiques liées au L2 : On limite les domaines de broadcast et on passe au L3. MPLS est la technologie d’underlay des SP mais malheuresement, pas réellement prête pour être présente jusqu’au Top Of Rack : Coût d’accès à la techno trop important Probablement pas envie de faire se chevaucher les gammes SP et les gammes DC IPv6 : une bonne alternative possible, malheuresement n’était pas compatible avec la solution qu’on a choisit atm IPV4, : On peut utiliser 100% de nos liens : Sans boucle Avec du load balancing Technologie éprouvée, maîtrisée
- Ospf – isis : link state : limited scale : flooding or area Limited traffic engineering Limited traffic tagging Multi-vendor BGP : Scale Traffic engineering Traffic tagging Filtering enhanced iBGP require full mesh OR route-reflection : Standard Route-reflection : only best path Can be bypassed by BGP ( coucou addpath feature )
- Attention au allowasin
- Internet-Like Addressing●Pros:–In theory, up to 100% numbering space utilization–Works well for flexible/undefined topologies–What most IP people are used to●Cons:–Requires strong integration with IPAM/registry–Not human-friendly (no encoded semantics), error prone–Practically address space is never really 100% utilized
- Concretement, qu’est ce que ca donne !?
- ultimate flexibility -> unlimited tcam, unlimited routes, ... - limited performance (software) -> don't overuse it. e.g. bad idea for block sto - standard and well supported -> interoperable with hw vtep (e.g. vm <-> bmaas) - very high control plane performance -> can handle anything
- Pour certaines vrf, certains type de traffic (le traffic vers l’externe par exemple) : On n’a pas besoin d’optimiser le traffic est-west Je représente ici les domaines de chacun de nos satellite : Notre leaf5 annonce tout à notre edgeleaf Le edgeleaf lui envoie une default Edgeleaf à besoin de tout connaitre, pas les autre leaf
- Si on étend le modele précédent, on n’est pas obligés d’isoler nos leaf 1 par 1, on peut plutôt diviser / sharder nos domaines par bulles Grâce à ce genre de mécanisme on peut : Optimiser le traffic est-west à l’intérieur de la bulle Tout en limitant la taille des différentes tables sur nos leaf : on limite le scale des shelf et donc leur cout
- ultimate flexibility -> unlimited tcam, unlimited routes, ... - limited performance (software) -> don't overuse it. e.g. bad idea for block sto - standard and well supported -> interoperable with hw vtep (e.g. vm <-> bmaas) - very high control plane performance -> can handle anytIRB routing with t2 hing
- todo