Scaleway Approach to VXLAN EVPN Fabric
•Transferir como PPTX, PDF•
1 gostou•1,238 visualizações
Discover how we build our fabrics using vxlan + bgp evpn.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Scaleway Approach to VXLAN EVPN Fabric
Semelhante a Scaleway Approach to VXLAN EVPN Fabric (20)
Mais de Scaleway
Mais de Scaleway (20)
Último
Último (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
Notas do Editor
- 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