pour toute question (ou erreur) sur un article.VPLS LDP vs BGP
Lors d'une discussion avec un collègue au sujet du VPLS, a ressurgi la question fondamentale du MAC learning. Il m'affirmait qu'un VPLS en mode BGP, contrairement au mode LDP, échange les adresses MAC apprises 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, surtout avec l'habitude du MPLS L3VPN où BGP échange effectivement les routes VPN-IPv4.
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, faisons 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, à un « plan de contrôle »
Un projet m'a par ailleurs amené à revisiter les fondamentaux du VPLS. Et je dois dire, outre le MAC learning, que c'est plus tarabiscoté qu'il n'y paraît. Bien que simplement nommé « VPLS LDP vs BGP », cet article, après quelques rappels, répond aux questions pièges suivantes :
En particulier, cet article met en avant un certain illogisme : la possibilité d'implémenter la topologie hub-and-spoke en VPLS, et ce, en tirant parti de la règle split horizon adoptée en raison de la nature full-mesh admise des VPLS.
Rappels
Notion de PW (Pseudowire)
Notamment décrit dans la RFC 4447, le pseudowire permet 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 pseudowire—un vieil adage dirait « ne pas réinventer la roue ».
Plans de contrôle du VPLS
Différents plans de contrôle accompagnent le VPLS afin de pouvoir établir plus ou moins simplement les PW qui le composent. Nous distinguons :
| 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 (il mélange les deux modes précédents) | RFC 6074 |
Les extraits de conf ne concerneront que full-LDP et BGP-AD qui constituent les modes les plus répandus à ma connaissance.
Un VPLS BGP échange-t-il les adresses MAC en BGP ?
Le début d'article a déjà répondu à cette question.
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.
De nouveau tirés des RFC 4761 et RFC 4762, ces extraits nous apprennent que, par définition, le VPLS suit une topologie full-mesh sur le plan de données.
Prenons l'exemple d'une instance de VPLS avec quatre PE participant :
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. Vous me voyez sans doute venir : cela engendre une boucle,
en l'occurrence : PE3 → PE1 → PE4 → PE3 → PE1 → etc.
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. L'extrait cité raisonne ainsi : 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.
Cela évite ainsi la boucle.
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, elle servira à implémenter de façon astucieuse une autre topologie intéressante—et ça n'était peut-être pas l'intention de départ des standards cités.
Le VPLS LDP est-il synonyme de statique (manuel) ?
Non.
Des articles et équipementiers disent 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 :
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éfinie 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.
Étonnament, d'après mes recherches, seul le draft-ietf-l2vpn-signaling-00 semble vraiment le dire explicitement :
We do not specify an auto-discovery procedure in this draft, but we
do specify the information which needs to be obtained via auto-
discovery in order for the signaling procedures to begin. The way in
which the LDP-based signaling mechanisms can be integrated with BGP-
based auto-discovery is covered in some detail. Later revisions of
this draft will provide equivalent detail for other discovery
mechanisms.
Il a donné lieu à la RFC 6074 que Cisco cite d'ailleurs à ce sujet :
Prior to the VPLS BGP Signaling feature, BGP was used for
autodiscovery and Label Distribution Protocol (LDP) for
signaling in accordance with RFC 6074.
Nokia en parle également ici : LDP VPLS Using BGP Auto-Discovery.
Exemple
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).
Que faut-il retenir de ces extraits de conf ?
Le mode full-LDP se veut 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. Pour quatre PE, ça passe encore. Mais pour trente PE, le travail s'avère bien plus laborieux. À chaque ajout-suppression de PE dans le VPLS, tous les PE impliqués doivent être modifiés. Et plus il y a d'actions manuelles, plus les erreurs humaines sont probables (inévitables).
Le mode BGP-AD possède cet avantage que l'ajout (ou la suppression) d'un membre du VPLS n'a pas d'impact sur les autres membres en matière de configuration. Il suffit d'ajouter (ou de supprimer) la configuration suivante sur le PE en question :
vsi MY-VSI
bgp-ad
vpls-id 100:1
vpn-target 100:1 import-extcommunity
vpn-target 100:1 export-extcommunity
Et les RT, tels des connecteurs, se chargent de l'établissement (ou de la destruction) des PW.
Cela assure un gain de temps et diminue la marge d'erreurs. Les OPEX (Operating Expense), les coûts d'exploitation, s'en retrouvent 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 courbe d'apprentissage est, certes, un peu plus élevée en raison du mécanisme RD-RT mais vite rentabilisée.
Par curiosité, quelles informations véhiculent les RT ?
Notons déjà et pour réinsister : le VPLS se voulant full-mesh par définition,
la RFC 4761
préconise l'usage d'un unique RT pouvant aussi être RD ou identifier—d'où
la répétition de 100:1 dans l'exemple de configuration BGP-AD précédent.
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.
De plus, 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). Que véhiculent-ils alors ? Regardons 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. 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.
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 la topologie 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 de mise à jour, …), cette astuce peut sauver les meubles.
Exemple
La topologie hub-and-spoke devient 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. En VPLS BGP-AD, un jeu de RT rend possible la topologie :
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 sous le soleil. 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é) |
|---|---|
|
|
Ces deux configurations produisent le même résultat, c'est-à-dire la topologie hub-and-spoke prise en exemple. Cependant, la solution BGP-AD se veut plus évolutive dans le temps pour des raisons de maintenabilité déjà évoquées.
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 constitue 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.
Prenons 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 :
- établir un maillage complet de PW uniquement entre les PE de cœur, appelés H(ub)-PE
- établir ensuite au besoin un seul PW avec chaque PE d'accès concerné, appelés S(poke)-PE
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.
Le problème de la réplication
Le fait que VPLS LDP soit « configuration-intensif » ne constitue pas forcément le vrai problème pour les opérateurs qui, bien souvent, automatisent l'injection des configurations.
(…) 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 point négatif reste la réplication des trames sur chaque PW qui augmente la charge de trafic sur le backbone. Comme indiqué dans l'extrait ci-dessus de la RFC 4762, la force de H-VPLS réside dans la réduction du nombre PW et, par conséquent, du nombre de trames à répliquer.
H-VPLS BGP versus H-VPLS LDP
Comme indiqué dans l'extrait ci-dessous de la RFC 4761, le H-VPLS BGP diffère du H-VPLS LDP que nous venons de décrire.
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].
La solution RR évoquée permet d'éviter le maillage iBGP entre tous les PE, maillage 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 la problématique de réplication, même pas évoquée dans le document, 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.
Aujourd'hui, la technologie EVPN remplace de plus en plus le VPLS.