VPLS LDP vs BGP
Lors d'une discussion avec un collègue à propos du VPLS, la question fondamentale du MAC learning a ressurgi. Il m'affirmait que dans un VPLS en mode BGP—par opposition au mode LDP—les adresses MAC étaient échangées en BGP. De mon côté, j'émettais un doute, et la relecture des standards ne lui a pas donné raison. Pour sa défense, c'est un piège dans lequel il est tentant de tomber, en particulier quand on a l'habitude du MPLS L3VPN où les routes VPN-IPv4 sont effectivement échangées en BGP.
It is worth mentioning an aspect of the control plane that is often a
source of confusion. No MAC addresses are exchanged via BGP. All
MAC address learning and aging is done in the data plane individually
by each PE.
Unlike BGP VPNs [RFC4364], reachability information is not advertised
and distributed via a control plane. Reachability is obtained by
standard learning bridge functions in the data plane.
Les extraits ci-dessus—tirés respectivement des RFC 4761 et RFC 4762—sont clairs et ont mis fin au désaccord : dans un VPLS BGP, les adresses MAC sont apprises de la même façon que dans un VPLS LDP, c'est-à-dire via le plan de données et non le plan de contrôle.
Si les concepts de plans de données et de contrôle paraissent flous, nous pouvons faire le parallèle avec les switchs Ethernet d'un LAN :
- Chaque switch construit sa table MAC au fur et à mesure des trames reçues des utilisateurs raccordés—elles appartiennent au « plan de données »
- Il n'y a pas d'échange d'adresses MAC entre les switchs via des trames spécifiques—qui appartiendraient, si elles existaient, au « plan de contrôle »
Plan de l'article
Un projet m'a par ailleurs amené à revisiter les fondamentaux du VPLS. Et je dois bien avouer, outre le MAC learning, que c'est plus tarabiscoté qu'il n'y paraît. Bien que simplement nommé « VPLS LDP vs BGP », vous vous doutez que cet article—si vous avez déjà lu ce blog—contiendra des digressions conceptuelles ornées de schémas et autres snippets de conf colorés.
- Un VPLS BGP échange-t-il les adresses MAC en BGP ?
- Un VPLS est-il par définition full-mesh ?
- Le VPLS LDP est-il synonyme de statique (manuel) ?
- Un VPLS peut-il être hub-and-spoke ?
- Le H-VPLS permet-il le hub-and-spoke ?
La comparaison sera menée au travers des questions-pièges ci-dessus. Car si je vous disais que dans un cas, le plan de contrôle est LDP et que la configuration est plus ou moins manuelle ; que dans l'autre cas, le plan de contrôle est BGP et que les procédures sont plus ou moins automatisées ; alors l'article s'arrêterait ici, avec le sentiment de n'avoir rien appris vraiment. La réponse à la première question a déjà été donnée.
- Non, le MAC learning est effectué sur le plan de données (contrairement à l'EVPN).
- Oui, un VPLS est par définition full-mesh (RFC).
- Non, l'établissement des PW en LDP peut être déclenché manuellement, certes, mais aussi automatiquement en BGP-AD.
- Oui, un VPLS peut être hub-and-spoke en tirant parti de la règle split horizon admise en raison du postulat full-mesh (hum…).
- Non, le H-VPLS est un modèle hub-and-spoke, certes, mais voué à réduire le nombre de PW. Il ne permet pas la topologie du point de vue usager.
Rappel sur les PW
Au commencement, il n'y avait rien. Puis apparurent les PW (Pseudowire). Définis dans la RFC 4447, ils permettent l'implémentation de L2VPN point-à-point sur MPLS, aussi appelé VPWS (Virtual Private Wire Service). Le L2VPN multipoint sur MPLS, aussi appelé VPLS (Virtual Private LAN Service), réutilise ce mécanisme de PW—un vieil adage dirait « ne pas réinventer la roue ».
Mais encore…
Le VPLS est pourvu de différents plans de contrôle dont l'objectif est l'établissement plus ou moins simplifié des PW qui le composent. On distingue :
| Plan de contrôle | Standard |
|---|---|
| VPLS LDP que j'appelle aussi full-LDP | RFC 4762 |
| VPLS BGP que j'appelle aussi full-BGP | RFC 4761 |
| VPLS BGP-AD que j'appelle aussi LDP-BGP—car mélange des deux modes précédents | RFC 6074 |
Enfin, les extraits de conf ne concerneront que full-LDP et BGP-AD car ce sont les modes les plus répandus à ma connaissance. Commençons.
Un VPLS est-il par définition full-mesh ?
Oui :
All the PEs participating in a VPLS are assumed to be fully meshed in
the data plane, i.e., there is a bidirectional pseudowire between
every pair of PEs participating in that VPLS
For the sake of simplicity, we define that the topology of a VPLS
is a full mesh of PWs.
Ces extraits—de nouveau tirés des RFC 4761 et RFC 4762—nous apprennent que by design la topologie d'un VPLS est full-mesh, faisant bien mention du plan de données (la vue usager). Si nous prenons l'exemple d'une instance de VPLS avec quatre PE participant, le schéma précédent devient :
Comme avec un switch Ethernet classique,
le trafic broadcast ou unknown unicast reçu sur un PE
est diffusé sur tous les autres « ports » appartenant au VPLS, c'est-à-dire sur les AC et les PW.
Par exemple, si PE1 reçoit du broadcast de PE3,
il le diffusera sur l'AC vers CE1 ainsi que sur les PW vers PE2 et PE4,
qui appliqueront la même règle. Ainsi, vous me voyez venir : des boucles sont engendrées
(exemple : PE3 → PE1 → PE4 → PE3 → PE1 → …).
C'est alors que :
(…) a full mesh of PWs is established between PEs. Since every
PE is now directly connected to every other PE in the VPLS via a PW,
there is no longer any need to relay packets, and we can instantiate
a simpler loop-breaking rule: the "split horizon" rule, whereby a PE
MUST NOT forward traffic from one PW to another in the same VPLS
mesh.
Le postulat du full-mesh résout le problème.
Le raisonnement de l'extrait est le suivant : puisque les PE d'un VPLS ont tous des PW entre eux,
nul besoin de diffuser le trafic reçu d'un PW sur les autres PW.
Par exemple : si PE3 envoie du broadcast à PE1,
il l'envoie forcément aussi à PE4 ; aussi, nul besoin pour PE1 de le diffuser à PE4.
Les boucles sont ainsi évitées.
Cette règle native du « split horizon »
est bien une conséquence de la topologie full-mesh :
This notion has been termed "split horizon" forwarding and is a
consequence of the PEs being logically fully meshed for VPLS.
Retenez bien cette notion car, comme nous le verrons plus bas, elle permettra d'implémenter astucieusement une autre topologie intéressante—et fort à parier que ça n'était pas l'intention de départ des standards cités.
Le VPLS LDP est-il synonyme de statique (manuel) ?
Non. Des articles et équipementiers diront pourtant : le VPLS LDP est statique car les PW doivent être configurés manuellement. Ce n'est pas tout à fait vrai. La RFC 4762 définit du point de vue protocolaire l'établissement des PW via LDP mais n'impose pas le déclencheur de cet établissement :
The capability to manually configure the addresses of the remote PEs
is REQUIRED. However, the use of manual configuration is not
necessary if an auto-discovery procedure is used. A number of auto-
discovery procedures are compatible with this document
([RADIUS-DISC], [BGP-DISC]).
Le déclencheur peut ainsi être manuel ou automatisé ! et ce, via une procédure d'AD (Auto-Discovery) à définir dans un document séparé. Le protocole, lui, reste compatible. Si RADIUS a été évoqué pour cette tâche, c'est BGP qui l'a emporté—en empruntant les mécanismes de RD (Route Distinguisher) et RT (Route Target) du MPLS L3VPN. En résulte un mélange de VPLS LDP-BGP aussi appelé BGP-AD : les PE s'auto-découvrent en BGP et cela déclenche l'établissement des PW en LDP automatiquement. Ceci a été standardisé dans la RFC 6074, même si les équipementiers n'ont pas attendu la version finale et ont implémenté ceci dès le statut de draft, car beaucoup de ressemblances avec le mode full-BGP défini plus tôt dans le temps.
Du concret !
Pour illustrer le propos, voyons des extraits de configuration implémentant le VPLS full-mesh schématisé plus haut.
Dans l'exemple, PE1 a l'adresse IP 1.1.1.1, PE2 a l'adresse IP 2.2.2.2, etc.
Il s'agit d'une syntaxe Huawei que je préfère à Cisco pour les VPLS
(comme je préfère Cisco à Huawei dans d'autres cas).
| VPLS full-LDP (établissement PW manuel) | VPLS LDP-BGP aka BGP-AD (établissement PW automatisé) |
|---|---|
|
|
Remarquez le parallèle :
- Un MPLS L2VPN est constitué d'un ensemble de VSI (Virtual Switching Instance), une VSI étant une instance de table de commutation virtuelle.
- Un MPLS L3VPN est constitué d'un ensemble de VRF (VPN Routing and Forwarding), une VRF étant une instance de table de routage virtuelle.
Dans la terminologie Cisco, le terme VSI est remplacé par VFI (Virtual Forwarding Instance).
Soit… Que faut-il retenir de ces extraits ? Le mode full-LDP est davantage « configuration-intensif » que le mode BGP-AD. En effet, il requiert de configurer à la main les adresses IP de chaque PE participant au VPLS donné—sachant que cela se répète pour tout autre VPLS. Pour quatre PE, ça passe, me direz-vous. Mais pour trente PE, le travail est autrement plus laborieux. À chaque ajout-suppression de PE dans le VPLS, la trentaine de PE impliqués doit être modifiée. Et plus les actions manuelles sont nombreuses, plus les erreurs humaines sont probables (comprendre inévitables).
Le mode BGP-AD a cet avantage que l'ajout-suppression d'un PE dans un VPLS n'a pas d'impact sur les autres membres en matière de configuration. Il suffit d'ajouter-supprimer le snippet de conf sur le PE en question et les RT—tels des connecteurs—exécutent le travail à notre place (établissement-destruction des PW). Le gain de temps est assuré et la marge d'erreurs est diminuée. On dit aussi que les OPEX (Operating Expense)—les coûts d'exploitation—sont réduits ; argument non négligeable quand ces derniers sont quotidiens et que les erreurs humaines peuvent engendrer des coupures dont les clients impactés sont en droit de réclamer des pénalités. La learning curve est, certes, plus élevée (en raison du mécanisme RD-RT) mais vite rentabilisée.
Bonus Mais quelles informations véhiculent donc les RT ?
Notons déjà et pour réinsister : le VPLS est tellement full-mesh par définition
que la RFC 4761 même
préconise l'usage d'un unique RT pouvant aussi être RD (identifier), d'où l'apparition de 100:1 partout dans notre extrait de conf BGP-AD :
As it has been assumed that VPLSs are fully meshed, a single Route
Target RT suffices for a given VPLS V, and in effect that RT is the
identifier for VPLS V.
Ensuite, comme introduit en début d'article, les RT d'un VPLS BGP ne véhiculent pas d'adresses MAC—contrairement aux RT d'un MPLS L3VPN qui véhiculent des routes. Le mieux reste alors de se plonger dans une capture de l'étape BGP-AD (en amont de l'établissement des PW) :
UPDATE envoyé par PE1 (peu importe à quel PE) lors de l'étape BGP-AD.
Nous ne détaillerons pas chaque paramètre, le but étant de visualiser le non-échange d'adresses MAC et remarquer la structure du point de vue protocolaire. Aussi, tel que précisé dans la RFC 6074, nous retrouvons bien notamment RD et RT :
In summary, the BGP advertisement for a particular VSI at a given PE will contain:
o an NLRI of AFI = L2VPN, SAFI = VPLS, encoded as RD:PE_addr
o a BGP next hop equal to the loopback address of the PE
o an Extended Community Attribute containing the VPLS-id
o an Extended Community Attribute containing one or more RTs.
L'extrait mentionne par ailleurs la notion de VPLS-ID visible sur la capture sous le terme de L2VPN Identifier.
Quelle différence avec le RD ? Aucune. Il semblerait que le VPLS-ID soit utilisé par LDP pour former l'AGI (Attachment Group Identifier), un ID devant être porté par tous les PW d'un même VPLS.
Chez certains équipementiers, le RD est généré depuis le VPLS-ID (ou vice-versa)—les paramètres sont alors égaux, comme illustré sur la capture.
Un VPLS peut-il être hub-and-spoke ?
Oui, nativement, si l'on comprend bien ce que l'on fait. Voici une comparaison schématisée des deux topologies :
Dans la topologie full-mesh, on établit des PW entre tous les PE (comme vu précédemment).
Dans la topologie hub-and-spoke, on établit les PW uniquement entre la racine et les feuilles.
Fonctionnellement, ces topologies répondent à des besoins différents. La première permet, par exemple, de raccorder tous les sites d'une entreprise en L2, de sorte à fournir un grand switch Ethernet virtuel. La deuxième permet la fameuse architecture client-serveur, par exemple DHCP ou PPPoE (voir PPP vs DHCP). Le CE racine est le serveur ; les CE feuilles sont les clients. Les feuilles ne doivent pas se voir entre elles. Autrement, l'une pourrait se prétendre serveur aux yeux des autres—attaque dite de MAC spoofing. La sécurité des réseaux commence dès les couches basses.
C'est le moment wtf.
Pour rappel, conformément au split horizon, si la feuille PE3 envoie du broadcast à la racine PE1,
ce dernier ne le diffuse pas sur les autres PW (et donc ne le diffuse pas aux autres feuilles).
Parfait ! c'est en effet le comportement souhaité pour du hub-and-spoke.
Permettons-nous donc une conclusion :
La topologie hub-and-spoke est implémentable nativement en profitant de la règle split horizon admise en raison du postulat full-mesh.
Héhé. Si les RFC 4761 et RFC 4762 ne font (étonnamment) pas mention du hub-and-spoke, la RFC 6074, elle, et comme on va le voir ci-dessous, le fait. C'est rassurant en un sens, mais elle ne daigne pas évoquer le tour de passe-passe du split horizon.
C'est illogique, certes, mais valide nativement. J'entends par là que le hub-and-spoke devient possible sans sortir l'artillerie lourde à base de RFC 7387 ou d'EVPN. Sur des réseaux n'offrant que VPLS (limitation technique, budget restreint, pas de réel besoin d'upgrade, etc.), cette astuce peut sauver les meubles. L'alternative à base de filtrage sur le plan de données pour empêcher le flooding—ou PBR (Policy-Based Routing) de niveau 2—ça, ce serait moche.
Du concret v2
La topologie hub-and-spoke est donc implémentable nativement. En VPLS LDP, c'est assez intuitif : il suffit d'établir les PW comme si nous branchions des câbles physiques en étoile. Simple ! basique ! mais manuel. En VPLS BGP-AD, cela est réalisable en jouant sur les RT exportés-importés :
As a simple example, consider the task of building a hub-and-spoke
topology with a single hub. One pool, the "hub" pool, is configured
with an export RT of RT_hub and an import RT of RT_spoke. All other
pools (the spokes) are configured with an export RT of RT_spoke and
an import RT of RT_hub. Thus, the hub pool will connect to the
spokes, and vice-versa, but the spoke pools will not connect to each
other.
Rien de nouveau. Cette façon d'exploiter les RT est largement utilisée dans le MPLS L3VPN pour un besoin identique.
| VPLS full-LDP (établissement PW manuel) | VPLS LDP-BGP aka BGP-AD (établissement PW automatisé) |
|---|---|
|
|
Une fois encore, ces deux configurations produiront le même résultat, c'est-à-dire le schéma hub-and-spoke pris en exemple plus haut. Cependant, la solution BGP-AD sera davantage maintenable et évolutive dans le temps.
Le H-VPLS permet-il le hub-and-spoke ?
Non. Mais lisons un extrait volontairement court de la RFC 4762 à son sujet :
The VPLS core PWs (hub) are augmented with access PWs (spoke)
to form a two-tier hierarchical VPLS (H-VPLS).
Cela peut vite porter à confusion. Les termes de hub et spoke sont en effet inhérents à la solution H-VPLS, incitant à croire qu'elle permet une telle topologie. Et elle vous sera probablement proposée si vous recherchez ces mots-clés avec VPLS. Le H-VPLS, c'est bien un modèle hub-and-spoke, mais voué à réduire le nombre de PW (dans un souci de passage à l'échelle). Il ne permet pas la topologie du point de vue usager. Voyons un exemple :
Sans H-VPLS, on établit N*(N-1)/2 PW où N est le nombre de PE participant (soit 28 PW ici).
Avec H-VPLS, ce nombre est réduit de moitié dans l'exemple (avec un réseau de cœur à 4 PE).
Le H-VPLS part du principe que les architectures opérateur sont souvent (mais pas toujours) hiérarchisées, et tire profit de ce découpage accès-cœur :
In many cases, service providers place smaller edge devices in
multi-tenant buildings and aggregate them into a PE in a large
Central Office (CO) facility.
La règle devient alors, pour chaque instance de VPLS :
- On établit un maillage complet de PW uniquement entre les PE de cœur—appelés H(ub)-PE dans le schéma
- On établit ensuite au besoin un seul PW avec chaque PE d'accès concerné—appelés S(poke)-PE dans le schéma
Afin que les S-PE puissent communiquer entre eux, une variante de la règle split horizon s'applique :
elle est valable au cœur qui est maillé mais pas à l'accès.
Par exemple, si S-PE1 envoie du broadcast (ou unknown unicast), H-PE1 le diffuse sur tous ses PW,
vers S-PE2, H-PE2, H-PE3 et H-PE4.
Ces mêmes H-PE ne le diffusent pas sur les Core PW mais le diffusent sur les Spoke PW vers les S-PE ;
ainsi, du point de vue usager, la topologie reste bien full-mesh !
Si vous avez implémenté H-VPLS sur votre réseau pensant isoler des sites feuilles,
je parie que le broadcast de l'un est reçu par les autres. À vos captures.
(…) the real detriment
to large scale deployment is the packet replication requirements for
each provisioned PWs on a PE router. Hierarchical connectivity,
described in this document, reduces signaling and replication
overhead to allow large-scale deployment.
Le fait que VPLS LDP soit « configuration-intensif » n'est en réalité pas le vrai problème—car des moulinettes d'automatisation peuvent être développées. Le point négatif est la réplication des trames sur chaque PW, ayant pour effet d'augmenter la charge de trafic sur le backbone de l'opérateur. Comme mis en avant dans l'extrait ci-dessus, la force de H-VPLS réside dans la réduction du nombre PW et, par conséquent, du nombre de trames à répliquer.
It is important to note that RRs, as used for VPLS and VPNs, are
purely a control plane technique. The use of RRs introduces no data
plane state and no data plane forwarding requirements on the RRs, and
does not in any way change the forwarding path of VPLS traffic. This
is in contrast to the technique of Hierarchical VPLS defined in [10].
Enfin, comme indiqué dans l'extrait ci-dessus de la RFC 4761, le H-VPLS BGP diffère du H-VPLS LDP que nous venons de voir. La solution RR évoquée permet d'éviter le maillage iBGP entre PE nécessaire au plan de contrôle pour l'auto-discovery—la même problématique existant pour le MPLS L3VPN. Elle ne traite pas de la problématique de réplication qui semble (donc) acceptée, et ne modifie pas les PW à établir contrairement au H-VPLS LDP.
Le mot de la fin
Je ne cache pas que cet article avait une double finalité : répondre aux questions-pièges tout en faisant le point sur les plans de contrôle existants du VPLS. C'est une technologie plutôt intuitive d'un point de vue conceptuel et facile à déployer, tant elle est maîtrisée et répandue chez les équipementiers. Je lui prédis encore de belles années. L'illogisme du hub-and-spoke reste étonnant (et amusant).