Un brin de réseau


Tel un cahier de notes, ce blog propose des articles sur les technologies réseaux et leur utilisation pratique, le tout illustré avec des maquettes et des captures.

#about #contact

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 4762sont 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.

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.

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 ».

mpls-l2vpn-pw
Illustration d'un PW entre (nécessairement) deux PE. L'idée est d'établir un câble virtuel ou « pseudo-câble ».

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 :

Si je parle de « VPLS BGP » sans plus de précision, cela concerne alors à la fois full-BGP et BGP-AD qui sont de toute façon très proches—le dernier ayant été inspiré du premier.
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 :

mpls-l2vpn-pw-vpls
Dans un VPLS full-mesh, on établit des PW entre tous les PE. Ceci vaut pour chaque instance de VPLS.

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 : PE3PE1PE4PE3PE1 → …). 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).

Ce ne sont que les extraits de conf pertinents pour la comparaison. Les peerings LDP et BGP sont notamment absents. Des exemples complets sont disponibles dans la doc Huawei.
VPLS full-LDP (établissement PW manuel) VPLS LDP-BGP aka BGP-AD (établissement PW automatisé)

  PE1#
  vsi MY-VSI
   pwsignal ldp
    vsi-id 1
    peer 2.2.2.2
    peer 3.3.3.3
    peer 4.4.4.4

  PE2#
  vsi MY-VSI
   pwsignal ldp
    vsi-id 1
    peer 1.1.1.1
    peer 3.3.3.3
    peer 4.4.4.4

  PE3#
  vsi MY-VSI
   pwsignal ldp
    vsi-id 1
    peer 1.1.1.1
    peer 2.2.2.2
    peer 4.4.4.4

  PE4#
  vsi MY-VSI
   pwsignal ldp
    vsi-id 1
    peer 1.1.1.1
    peer 2.2.2.2
    peer 3.3.3.3
              

    PE1#
    vsi MY-VSI
     bgp-ad
      vpls-id 100:1 # RD
      vpn-target 100:1 import-extcommunity # RT
      vpn-target 100:1 export-extcommunity # RT


    PE2#
    vsi MY-VSI
     bgp-ad
      vpls-id 100:1
      vpn-target 100:1 import-extcommunity
      vpn-target 100:1 export-extcommunity


    PE3#
    vsi MY-VSI
     bgp-ad
      vpls-id 100:1
      vpn-target 100:1 import-extcommunity
      vpn-target 100:1 export-extcommunity


    PE4#
    vsi MY-VSI
     bgp-ad
      vpls-id 100:1
      vpn-target 100:1 import-extcommunity
      vpn-target 100:1 export-extcommunity

              

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) :

vpls-bgp-ad-update
Capture du BGP 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 :

vpls-full-mesh-hub-and-spoke

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 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.

Ce ne sont que les extraits de conf pertinents pour la comparaison. Les peerings LDP et BGP sont notamment absents. Des exemples complets sont disponibles dans la doc Huawei.
VPLS full-LDP (établissement PW manuel) VPLS LDP-BGP aka BGP-AD (établissement PW automatisé)

  PE1(Hub)#
  vsi MY-VSI
   pwsignal ldp
    vsi-id 1
    peer 2.2.2.2 # PW to spoke
    peer 3.3.3.3 # PW to spoke
    peer 4.4.4.4 # PW to spoke

  PE2(Spoke)#
  vsi MY-VSI
   pwsignal ldp
    vsi-id 1
    peer 1.1.1.1 # PW to hub



  PE3(Spoke)#
  vsi MY-VSI
   pwsignal ldp
    vsi-id 1
    peer 1.1.1.1 # PW to hub



  PE4(Spoke)#
  vsi MY-VSI
   pwsignal ldp
    vsi-id 1
    peer 1.1.1.1 # PW to hub

              

    PE1(Hub)#
    vsi MY-VSI
     bgp-ad
      vpls-id 100:1 # RD
      vpn-target 100:2 import-extcommunity # RT spoke2hub
      vpn-target 100:3 export-extcommunity # RT hub2spoke


    PE2(Spoke)#
    vsi MY-VSI
     bgp-ad
      vpls-id 100:1
      vpn-target 100:3 import-extcommunity # we import hub
      vpn-target 100:2 export-extcommunity # we export as spoke


    PE3(Spoke)#
    vsi MY-VSI
     bgp-ad
      vpls-id 100:1
      vpn-target 100:3 import-extcommunity # we import hub
      vpn-target 100:2 export-extcommunity # we export as spoke


    PE4(Spoke)#
    vsi MY-VSI
     bgp-ad
      vpls-id 100:1
      vpn-target 100:3 import-extcommunity # we import hub
      vpn-target 100:2 export-extcommunity # we export as spoke
              

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 :

vpls-vs-hvpls

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 :

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).