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

MPLS VPN (Partie 2)

Dans la première partie de l'article, nous avons préparé le backbone IP/MPLS afin qu'il puisse porter un service MPLS L3VPN que nous avons commencé à configurer.

Étape 4 : un peering BGP VPN-IPv4 (plan de contrôle)

Rentrons un peu plus dans le vif du sujet avec le plan de contrôle des MPLS L3VPN qui s'appuie sur MP-BGP (RFC 4760) pour échanger les routes VPN-IPv4 :


      The BGP Multiprotocol Extensions [3] allow BGP to carry routes from
      multiple "address families".  We introduce the notion of the "VPN-
      IPv4 address family".  A VPN-IPv4 address is a 12-byte quantity,
      beginning with an 8-byte "Route Distinguisher (RD)" and ending with a
      4-byte IPv4 address.  If two VPNs use the same IPv4 address prefix,
      the PEs translate these into unique VPN-IPv4 address prefixes.  This
      ensures that if the same address is used in two different VPNs, it is
      possible to install two completely different routes to that address,
      one for each VPN.
    

Pour résumer ceci, une route VPN-IPv4 est une route classique mais préfixée du RD de sa VRF. C'est précisément ce qui permet à deux VRF différentes d'utiliser les mêmes réseaux sans se recouvrir—si, évidemment, elles ne forment pas un VPN commun en exportant-important leurs RT (comme vu à l'étape 3). Par exemple, la route 172.16.0.0/30 de la VRF VPN-A1 devient 100:0:172.16.0.0/30. Une autre VRF VPN-B1 (d'un autre VPN donc) ayant pour RD 100:53 pourrait utiliser la même route qui deviendrait 100:53:172.16.0.0/30. Ainsi, ces deux dernières routes ne sont pas les mêmes, car le RD diffère de l'une à l'autre. Nous retrouverons cette notation RD:prefix plus loin dans les sorties Cisco.

L'établissement du peering

Pour permettre l'échange de routes VPN-IPv4 entre les PE, ces derniers doivent établir un peering BGP entre eux avec la « capacité » VPN-IPv4. Par raccourci, nous parlons de peering MP-BGP ou MP-iBGP (i pour internal car on se situe dans le même AS) :

PE1 PE2

    PE1#show running-config

    router bgp 100
     bgp router-id 1.0.0.10

     ! The neighbor (same AS)
     neighbor 1.0.0.13 remote-as 100
     neighbor 1.0.0.13 update-source Loopback0

     ! Enable VPN-IPv4 capability
     address-family vpnv4 unicast
      neighbor 1.0.0.13 activate
      neighbor 1.0.0.13 send-community extended

     ! Disable IPv4 capability
     ! (enabled by default but NOT needed here)
     address-family ipv4 unicast
      no neighbor 1.0.0.13 activate

    ! Show the BGP neighbors
    PE1#show bgp all neighbors
    For address family: IPv4 Unicast

    For address family: IPv6 Unicast

    For address family: VPNv4 Unicast
    BGP neighbor is 1.0.0.13,  remote AS 100, internal link
    BGP version 4, remote router ID 1.0.0.13
    BGP state = Established, up for 00:03:29
    (…)

    For address family: IPv4 Multicast

    For address family: IPv6 Multicast

    For address family: NSAP Unicast
              

    PE2#show running-config

    router bgp 100
     bgp router-id 1.0.0.13

     ! The neighbor (same AS)
     neighbor 1.0.0.10 remote-as 100
     neighbor 1.0.0.10 update-source Loopback0

     ! Enable VPN-IPv4 capability
     address-family vpnv4 unicast
      neighbor 1.0.0.10 activate
      neighbor 1.0.0.10 send-community extended

     ! Disable IPv4 capability
     ! (enabled by default but NOT needed here)
     address-family ipv4 unicast
      no neighbor 1.0.0.10 activate

    ! Show the BGP neighbors
    PE2#show bgp all neighbors
    For address family: IPv4 Unicast

    For address family: IPv6 Unicast

    For address family: VPNv4 Unicast
    BGP neighbor is 1.0.0.10,  remote AS 100, internal link
     BGP version 4, remote router ID 1.0.0.10
     BGP state = Established, up for 00:03:51
     (…)

    For address family: IPv4 Multicast

    For address family: IPv6 Multicast

    For address family: NSAP Unicast
              

La commande neighbor send-community extended, automatiquement ajoutée par Cisco lors de l'activation de la capacité VPN-IPv4, permet l'envoi des communautés BGP dites étendues. C'est ce qui permet l'envoi des RT (comme nous le verrons plus bas lors de l'échange d'une route VPN-IPv4) :


      The function performed by the Route Target attribute is similar to
      that performed by the BGP Communities attribute.  However, the format
      of the latter is inadequate for present purposes, since it allows
      only a 2-byte numbering space.  It is desirable to structure the
      format, similar to what we have described for RDs (see Section 4.2),
      so that a type field defines the length of an administrator field,
      and the remainder of the attribute is a number from the specified
      administrator's numbering space.  This can be done using BGP Extended
      Communities.  The Route Targets discussed herein are encoded as BGP
      Extended Community Route Targets [BGP-EXTCOMM].  They are structured
      similarly to the RDs.
    

Voici la capture correspondant à l'établissement du peering MP-BGP entre PE1 et PE2 :

cap-mpls-l3vpn-bgp-open
Capture sur le lien P1 — P2. Le message BGP OPEN envoyé de PE1 à PE2 et transporté dans le label MPLS 21 (conformément à la LFIB de P1—voir l'étape 2).

Nous noterons surtout la négociation MP-BGP qui va permettre l'échange de routes VPN-IPv4 (l'AFI 1 combiné au SAFI 128) :


      The BGP Multiprotocol Extensions [BGP-MP] are used to encode the
      NLRI.  If the Address Family Identifier (AFI) field is set to 1, and
      the Subsequent Address Family Identifier (SAFI) field is set to 128,
      the NLRI is an MPLS-labeled VPN-IPv4 address.  AFI 1 is used since
      the network layer protocol associated with the NLRI is still IP.
      Note that this VPN architecture does not require the capability to
      distribute unlabeled VPN-IPv4 addresses.
    

Pour terminer, cet extrait rappelle qu'il n'est pas nécessaire d'établir un peering IPv4 simple (« unlabeled VPN-IPv4 addresses ») pour qu'un peering VPN-IPv4 soit fonctionnel. Aussi, nous l'avons explicitement désactivé dans les configurations ci-dessus afin de bien comprendre ceci (et car Cisco l'active par défaut).

L'échange de routes VPN-IPv4

Par défaut, aucune route n'est échangée ou « redistribuée ». Pour l'exemple, activons la redistribution des attachment circuits (qui sont des routes directement connectées) :

PE1 PE2

    PE1#show running-config

    router bgp 100
     address-family ipv4 unicast vrf VPN-A1
      redistribute connected
              

    PE2#show running-config

    router bgp 100
     address-family ipv4 unicast vrf VPN-A2
      redistribute connected
              

Et analysons la capture associée :

cap-mpls-l3vpn-bgp-update
Capture sur le lien P1 — P2. Le message BGP UPDATE envoyé de PE2 à PE1 et transporté dans le label MPLS 27 (conformément à la LFIB de P2—voir l'étape 2).

La route VPN-IPv4 est présente dans l'attribut MP_REACH_NLRI. Il y a le préfixe 172.16.0.4 et le label 43 que PE1 devra adjoindre—voir le plan de données à l'étape 5. Mais où est le masque /30 ? Il est en fait contenu dans le champ Prefix Length qui (je préviens, c'est moche) comprend à la fois la longueur du label (24 bits) et la longueur du RD (64 bits), soit : 118-24-64 = 30. Comme attendu, le RT 100:3 est contenu dans l'attribut EXTENDED_COMMUNITIES. Ce RT est exporté par la VRF VPN-A2 et importé par la VRF VPN-A1 pour former le VPN. Naturellement, ces informations sont visibles depuis PE1 et PE2 :

PE1 PE2

    ! Show the VRF IP Routing Information Base (RIB)
    PE1#show ip route vrf VPN-A1

    Routing Table: VPN-A1
    Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP (…)
         172.16.0.0/30 is subnetted, 2 subnets
    B       172.16.0.4 [200/0] via 1.0.0.13, 00:11:56
    C       172.16.0.0 is directly connected, FastEthernet0/1

    ! Show the received VPN-IPv4 route (from PE2)
    PE1#show bgp vpnv4 unicast vrf VPN-A1 172.16.0.4 255.255.255.252
    BGP routing table entry for 100:0:172.16.0.4/30, version 9
    Paths: (1 available, best #1, table VPN-A1)
      Not advertised to any peer
      Local, imported path from 100:1:172.16.0.4/30
       1.0.0.13 (metric 31) from 1.0.0.13 (1.0.0.13)
        Origin incomplete, metric 0, localpref 100, valid, internal, best
        Extended Community: RT:100:3
        mpls labels in/out nolabel/43

    ! Show the Label Forwarding Information Base (LFIB)
    PE1#show mpls forwarding-table
    Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
    tag    tag or VC   or Tunnel Id      switched   interface
    16     Pop tag     1.0.0.2/31        0          Fa0/0      1.0.0.1
    17     26          1.0.0.4/31        0          Fa0/0      1.0.0.1
    18     Pop tag     1.0.0.11/32       0          Fa0/0      1.0.0.1
    19     28          1.0.0.12/32       0          Fa0/0      1.0.0.1
    20     29          1.0.0.13/32       0          Fa0/0      1.0.0.1
    21     Aggregate   172.16.0.0/30[V]  0
              

    ! Show the VRF IP Routing Information Base (RIB)
    PE2#show ip route vrf VPN-A2

    Routing Table: VPN-A2
    Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP (…)
         172.16.0.0/30 is subnetted, 2 subnets
    C       172.16.0.4 is directly connected, FastEthernet0/1
    B       172.16.0.0 [200/0] via 1.0.0.10, 00:13:17

    ! Show the received VPN-IPv4 route (from PE1)
    PE2#show bgp vpnv4 unicast vrf VPN-A2 172.16.0.0 255.255.255.252
    BGP routing table entry for 100:1:172.16.0.0/30, version 9
    Paths: (1 available, best #1, table VPN-A2)
      Not advertised to any peer
      Local, imported path from 100:0:172.16.0.0/30
       1.0.0.10 (metric 31) from 1.0.0.10 (1.0.0.10)
        Origin incomplete, metric 0, localpref 100, valid, internal, best
        Extended Community: RT:100:2
        mpls labels in/out nolabel/21

    ! Show the Label Forwarding Information Base (LFIB)
    PE2#show mpls forwarding-table
    Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
    tag    tag or VC   or Tunnel Id      switched   interface
    38     18          1.0.0.0/31        0          Fa0/0      1.0.0.4
    39     Pop tag     1.0.0.2/31        0          Fa0/0      1.0.0.4
    40     19          1.0.0.10/32       0          Fa0/0      1.0.0.4
    41     20          1.0.0.11/32       0          Fa0/0      1.0.0.4
    42     Pop tag     1.0.0.12/32       0          Fa0/0      1.0.0.4
    43     Aggregate   172.16.0.4/30[V]  0
              

Nous retrouvons ci-dessus les routes VPN-IPV4, les RT exportés et les labels MPLS à adjoindre pour le plan de données, qui est l'objet de l'étape suivante.

Étape 5 : visualiser le label stacking (plan de données)

Comme introduit dans l'article L2VPN vs L3VPN, le plan de données consiste en une pile (stack) de labels MPLS de deux niveaux :

Comprenez bien : les P ne voient pas le label VPN et ne traitent que le label LSP. Ainsi, nous percevons bien l'intérêt du LSP : c'est un véritable tunnel dans lequel il est possible d'acheminer plusieurs types de trafic (IP, L2VPN, L3VPN, …, et ce, en fonction de la valeur du label).


      Before a customer data packet travels across the Service Provider's
      backbone, it is encapsulated with the MPLS label that corresponds, in
      the customer's VPN, to the route that is the best match to the
      packet's destination address.  This MPLS packet is further
      encapsulated (e.g., with another MPLS label or with an IP or Generic
      Routing Encapsulation (GRE) tunnel header [MPLS-in-IP-GRE]) so that
      it gets tunneled across the backbone to the proper PE router.  Thus,
      the backbone core routers do not need to know the VPN routes.
    

Cet extrait mentionne bien l'encapsulation de MPLS dans MPLS (stack) et l'aspect agnostique des P (core routers). La possibilité de transporter le label VPN directement dans IP ou GRE (RFC 4023) est par ailleurs évoquée, typiquement dans le cas d'un réseau non-MPLS à traverser (non abordé ici—le nombre de cas en architecture réseau est faramineux, tout voir d'un coup n'est pas possible). Pour résumer, nous avons, dans l'ordre des choses :

  1. Le PE source effectue du label stacking/pushing (empiler le label VPN et label LSP).
  2. Les P effectuent du label switching (changer le label LSP).
  3. Le PE destinataire effectue du label unstacking/popping (dépiler le label VPN et le label LSP).

Réalisons un ping dans la VRF VPN-A1 depuis PE1 et analysons les captures associées :


      PE1#ping vrf VPN-A1 172.16.0.5 repeat 1

      Type escape sequence to abort.
      Sending 1, 100-byte ICMP Echos to 172.16.0.5, timeout is 2 seconds:
      !
      Success rate is 100 percent (1/1), round-trip min/avg/max = 104/104/104 ms
    
cap-mpls-l3vpn-ping-pe1-p1
Capture sur le lien PE1 — P1. On retrouve le paquet IP encapsulé dans la label stack MPLS avec les labels 43 (VPN) et 29 (LSP).
cap-mpls-l3vpn-ping-p1-p2
Capture sur le lien P1 — P2. On retrouve le paquet IP encapsulé dans la label stack MPLS avec les labels 43 (VPN) et 21 (LSP)—seul le label LSP a changé.
cap-mpls-l3vpn-ping-p2-pe2
Capture sur le lien P2 — PE2. On retrouve le paquet IP encapsulé dans le label 43 (VPN)—seul le label VPN demeure (mécanisme PHP).

Et voici donc une illustration du plan de données d'un MPLS L3VPN. Le paquet IP du client est encapsulé dans une stack de labels. Le label VPN demeure de bout-en-bout. Le label LSP change de proche-en-proche. Cette stack de labels est bien visible depuis un traceroute :


      PE1#traceroute vrf VPN-A1 172.16.0.5 probe 1

      Type escape sequence to abort.
      Tracing the route to 172.16.0.5

        1 1.0.0.1 [MPLS: Labels 29/43 Exp 0] 72 msec
        2 1.0.0.3 [MPLS: Labels 21/43 Exp 0] 72 msec
        3 172.16.0.5 [MPLS: Label 43 Exp 0] 76 msec
    

Petit exercice…

À ce stade, vous devriez être capable de déterminer à partir des LFIB MPLS présentées (étape 2 de la première partie et étape 4 de cette seconde partie) la stack de labels dans le sens PE2 → PE1.


          PE2#traceroute vrf VPN-A2 172.16.0.1 probe 1

          Type escape sequence to abort.
          Tracing the route to 172.16.0.1

            1 1.0.0.4 [MPLS: Labels 19/21 Exp 0] 68 msec
            2 1.0.0.2 [MPLS: Labels 27/21 Exp 0] 96 msec
            3 172.16.0.1 [MPLS: Label 21 Exp 0] 88 msec
        

Étape 6 : le routage CE-PE

Pour cette dernière étape, commençons par résumer rapidement ce qui a été fait auparavant. Nous avons configuré un MPLS L3VPN ainsi que les attachment circuits côté PE. Nous avons visualisé—aux étapes 4 et 5—comment se comportaient le plan de contrôle pour l'échange des préfixes associés (172.16.0.0/30 et 172.16.0.4/30) et le plan de données lors d'un ping entre ces préfixes. Pour terminer, abordons la partie CE car (enfin !) il s'agit de router les LAN client de bout-en-bout du VPN. Ceci a été introduit à la fin de la première partie de l'article avec la question « comment sont routés les LAN client ? ».

mpls-l3vpn-ac
Rappel du schéma de la première partie de l'article. Les attachment circuits (172.16.0.0/30 et 172.16.0.4/30) et les LAN client (192.168.1.0/24 et 192.168.2.0/24) sont représentés.

Pour être plus précis, la question est plutôt : comment le CE et le PE s'échangent-ils les LAN client entre eux ? Et pour être encore plus précis, il y a deux sous-questions : comment le PE apprend les routes du CE ? comment le CE apprend les routes du PE ? En fait, la RFC 4364 résume bien les possibilités :


      7.  How PEs Learn Routes from CEs

        The PE routers that attach to a particular VPN need to know, for each
        attachment circuit leading to that VPN, which of the VPN's addresses
        should be reached over that attachment circuit.

        The possible PE/CE distribution techniques are:

           1. Static routing (…)
           2. PE and CE routers may be RIP peers (…)
           3. The PE and CE routers may be OSPF peers (…)
           4. The PE and CE routers may be BGP peers (…)

      8.  How CEs Learn Routes from PEs

        If the PE places a particular route in the VRF it uses to route
        packets received from a particular CE, then in general, the PE may
        distribute that route to the CE.

        In most cases, however, it will be sufficient for the PE to simply
        distribute the default route to the CE.  (In some cases, it may even
        be sufficient for the CE to be configured with a default route
        pointing to the PE.)
    

Dans la suite, spoiler alert, BGP sera utilisé. Mais avant cela, je commente rapidement les possibilités évoquées ci-dessus, en m'appuyant sur les cas que j'ai rencontrés au travail.

How PEs Learn Routes from CEs? Pour les routes statiques, c'est assez immédiat à comprendre (et formateur). La configuration ressemblerait à :

PE1 PE2

    PE1#show running-config

    ! Static route in VRF
    ip route vrf VPN-A1 192.168.1.0 255.255.255.0 172.16.0.2

    ! Redistribute static routes to other PE
    router bgp 100
     address-family ipv4 unicast vrf VPN-A1
      redistribute static
              

    PE2#show running-config

    ! Static route in VRF
    ip route vrf VPN-A2 192.168.2.0 255.255.255.0 172.16.0.6

    ! Redistribute static routes to other PE
    router bgp 100
     address-family ipv4 unicast vrf VPN-A2
      redistribute static
              

Cela fonctionnerait. Mais les routes statiques sont à éviter—sauf si elles sont descendues dynamiquement en RADIUS à la montée des CE en PPP-DHCP sur le PE (alors appelé BAS). Pourquoi cela ? Car, dans mon expérience, les routes statiques sont peu adaptées aux processus de (dé)provisioning de l'opérateur. Souvent, elles sont configurées puis oubliées—errare humanum est. Il en résulte des routes qui « traînent », qui n'aident pas au diagnostic et, surtout, qui peuvent avoir des effets de bord.

Concernant RIP, j'ai dû l'employer dans un cas où le CE n'appartenait pas à l'opérateur (déconseillé). Soit le client ne savait que configurer RIP, soit son équipement ne supportait que RIP. Sinon, l'hésitation porte généralement entre OSPF et BGP, ce dernier étant plutôt vainqueur. À juste titre à mon sens. C'est dans sa nature même d'échanger des routes entre AS différents. Le réseau du client peut tout à fait être vu comme un petit AS.

How CEs Learn Routes from PEs? Il est vrai que, point de vue CE, une route par défaut (envoyée dynamiquement en BGP par le PE ou configurée statiquement sur le CE) est suffisante, et ce, car le PE représente sa porte de sortie quelle que soit la destination. Cependant, certains cas nécessitent quand même l'envoi explicite des LAN client. Par exemple, si le CE est double-attaché à plusieurs PE (multi-homing), il est possible, en jouant avec les annonces BGP, de faire en sorte qu'une partie des LAN passent par le premier lien et que l'autre partie passent par le deuxième.

Configuration du peering BGP

Dans la suite, nous allons donc annoncer explicitement les LAN client en BGP, ce qui permettra par la même d'aborder certaines particularités de BGP. L'idée, finalement, est plutôt intuitive : chaque CE annonce son LAN à son PE de rattachement, lequel annonce le LAN du CE opposé. Schématiquement :


    +-----+                      +-----+                      +-----+                      +-----+
    |     |  192.168.1.0/24 >>>  |     |  192.168.1.0/24 >>>  |     |  192.168.1.0/24 >>>  |     |
    | CE1 |-------- eBGP --------| PE1 |------- MP-iBGP ------| PE2 |-------- eBGP --------| CE2 |
    |     |  <<< 192.168.2.0/24  |     |  <<< 192.168.2.0/24  |     |  <<< 192.168.2.0/24  |     |
    +-----+                      +-----+                      +-----+                      +-----+
    AS64512                       AS100                        AS100                       AS64512
    

Vous remarquerez alors que le BGP de CE à PE n'est pas le même que celui de PE à PE. Effectivement, de CE à PE, il s'agit d'un simple peering IPv4 et non VPN-IPv4. Les configurations associées :

CE1 PE1

  CE1#show running-config

  ! CE-PE attachment circuit
  interface FastEthernet0/0
   ip address 172.16.0.2 255.255.255.252

  ! LAN gateway
  interface FastEthernet0/1
   ip address 192.168.1.254 255.255.255.0

  ! CE-PE peering
  router bgp 64512
   neighbor 172.16.0.1 remote-as 100
   address-family ipv4 unicast
    neighbor 172.16.0.1 activate
    neighbor 172.16.0.1 allowas-in 1 ! needed
    neighbor 172.16.0.1 prefix-list PREFIXES-IN in
    neighbor 172.16.0.1 prefix-list PREFIXES-OUT out
    network 192.168.1.0 mask 255.255.255.0

  ! Prefix list
  ip prefix-list PREFIXES-IN seq 5 permit 192.168.2.0/24
  ip prefix-list PREFIXES-OUT seq 5 permit 192.168.1.0/24
              

  PE1#show running-config

  ! CE-PE attachment circuit
  interface FastEthernet0/1
   ip vrf forwarding VPN-A1
   ip address 172.16.0.1 255.255.255.252




  ! CE-PE peering
  router bgp 100
   address-family ipv4 unicast vrf VPN-A1
    neighbor 172.16.0.2 remote-as 64512
    neighbor 172.16.0.2 activate
    neighbor 172.16.0.2 next-hop-self ! implicit
    neighbor 172.16.0.2 prefix-list VPN-A1-PREFIXES-IN in
    neighbor 172.16.0.2 prefix-list VPN-A1-PREFIXES-OUT out


  ! Prefix list
  ip prefix-list VPN-A1-PREFIXES-IN seq 5 permit 192.168.1.0/24
  ip prefix-list VPN-A1-PREFIXES-OUT seq 5 permit 192.168.2.0/24
              
CE2 PE2

  CE2#show running-config

  ! CE-PE attachment circuit
  interface FastEthernet0/0
   ip address 172.16.0.6 255.255.255.252

  ! LAN gateway
  interface FastEthernet0/1
   ip address 192.168.2.254 255.255.255.0

  ! CE-PE peering
  router bgp 64512
   neighbor 172.16.0.5 remote-as 100
   address-family ipv4 unicast
    neighbor 172.16.0.5 activate
    neighbor 172.16.0.5 allowas-in 1 ! needed
    neighbor 172.16.0.5 prefix-list PREFIXES-IN in
    neighbor 172.16.0.5 prefix-list PREFIXES-OUT out
    network 192.168.2.0 mask 255.255.255.0

  ! Prefix list
  ip prefix-list PREFIXES-IN seq 5 permit 192.168.1.0/24
  ip prefix-list PREFIXES-OUT seq 5 permit 192.168.2.0/24
              

  PE2#show running-config

  ! CE-PE attachment circuit
  interface FastEthernet0/1
   ip vrf forwarding VPN-A2
   ip address 172.16.0.5 255.255.255.252




  ! CE-PE peering
  router bgp 100
   address-family ipv4 unicast vrf VPN-A2
    neighbor 172.16.0.6 remote-as 64512
    neighbor 172.16.0.6 activate
    neighbor 172.16.0.6 next-hop-self ! implicit
    neighbor 172.16.0.6 prefix-list VPN-A2-PREFIXES-IN in
    neighbor 172.16.0.6 prefix-list VPN-A2-PREFIXES-OUT out


  ! Prefix list
  ip prefix-list VPN-A2-PREFIXES-IN seq 5 permit 192.168.2.0/24
  ip prefix-list VPN-A2-PREFIXES-OUT seq 5 permit 192.168.1.0/24
              

Il y a (encore) à dire… Tout d'abord, nous retrouvons la configuration des attachment circuits et des gateways des LAN client. S'ensuit la configuration des peerings BGP entre les CE et les PE.

Les CE dans un AS privé ? La première chose à remarquer est l'utilisation de l'AS64512 pour chaque CE. Ce numéro appartient à la plage 64512-65534 qui est « Reserved for Private Use » par l'IANA. C'est une plage que les opérateurs peuvent employer pour des besoins internes. Notre cas est un bon exemple d'utilisation des AS privés. Il est possible d'avoir un AS différent pour chaque CE, comme il est possible d'avoir le même pour tous les CE (quel que soit leur VPN)—comme ici. La dernière option a pour avantage une gestion simplifiée (qui favorise l'automatisation). Cependant, elle requiert l'option allowas-in sur les CE. Pourquoi cela ? Parce que CE1 va recevoir la route 192.168.2.0/24 ayant dans AS_PATH (un attribut BGP bien connu) l'AS64512 de CE2. Or, cela correspond à son propre AS et ceci équivaut à une boucle comme l'explique la RFC 4271 :


      If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
      route should be excluded from the Phase 2 decision function.  AS loop
      detection is done by scanning the full AS path (as specified in the
      AS_PATH attribute), and checking that the autonomous system number of
      the local system does not appear in the AS path.  Operations of a BGP
      speaker that is configured to accept routes with its own autonomous
      system number in the AS path are outside the scope of this document.
    

Par conséquent, la route sera ignorée. Le même raisonnement s'applique à CE2 pour la route 192.168.1.0/24 de CE1. Dans notre cas—et c'est répandu—il convient d'autoriser une telle particularité avec allowas-in 1 (le 1 indiquant que AS_PATH peut contenir une seule fois AS64512).

Pourquoi le next-hop-self sur les PE ? Lorsqu'un routeur A envoie une route en BGP à un routeur B, il remplit l'attribut NEXT_HOP. Cet attribut prend une valeur qui ne correspond pas toujours à l'adresse IP du routeur A sur l'interco avec le routeur B—les différents cas sont indiqués en §5.1.3. Parfois, il est nécessaire de forcer la valeur à cette adresse IP d'interco. Dans notre cas, c'est fait implicitement car il s'agit d'un peering eBGP (et non iBGP) mais cet attribut est suffisamment important pour le rappeler.

Pourquoi des prefix-list sur les PE et les CE ? Une bonne habitude à prendre en BGP est de filtrer systématiquement les annonces-réceptions afin de n'autoriser que ce qui est strictement nécessaire—les LAN client ici. D'ailleurs, les versions récentes de Cisco l'imposent. Cela permet de se prémunir contre les route leaks, des routes annoncées par mégarde (c'est souvent dû à une erreur humaine).

Analyse du peering BGP

Après tout ce blabla, voyons maintenant l'état des sessions BGP et les routes annoncées-reçues de part et d'autre :

CE1 PE1

  ! Show the BGP neighbors
  CE1#show bgp ipv4 unicast neighbors
  BGP neighbor is 172.16.0.1,  remote AS 100, external link
    BGP version 4, remote router ID 1.0.0.10
    BGP state = Established, up for 00:02:02
    (…)

  ! Show advertised routes to PE
  CE1#show bgp ipv4 unicast neighbors 172.16.0.1 advertised-routes
  Status codes: * valid, > best, i - internal, (…)
  Origin codes: i - IGP, e - EGP, ? - incomplete


     Network          Next Hop     Metric LocPrf Weight Path
  *> 192.168.1.0      0.0.0.0           0         32768 i

  Total number of prefixes 1

  ! Show received routes from PE
  CE1#show bgp ipv4 unicast neighbors 172.16.0.1 routes
  BGP table version is 3, local router ID is 192.168.1.254
  Status codes: * valid, > best, i - internal, (…)
  Origin codes: i - IGP, e - EGP, ? - incomplete


     Network          Next Hop     Metric LocPrf Weight Path
  *> 192.168.2.0      172.16.0.1                      0 100 64512 i

  Total number of prefixes 1
              

  ! Show the BGP neighbors (in VRF)
  PE1#show bgp vpnv4 unicast vrf VPN-A1 neighbors
  BGP neighbor is 172.16.0.2,  vrf VPN-A1,  remote AS 64512, external link
    BGP version 4, remote router ID 192.168.1.254
    BGP state = Established, up for 00:02:23
    (…)

  ! Show received routes from CE
  PE1#show bgp vpnv4 unicast vrf VPN-A1 neighbors 172.16.0.2 routes
  Status codes: * valid, > best, i - internal, (…)
  Origin codes: i - IGP, e - EGP, ? - incomplete

     Network          Next Hop            Metric LocPrf Weight Path
  Route Distinguisher: 100:0 (default for vrf VPN-A1)
  *> 192.168.1.0      172.16.0.2               0             0 64512 i

  Total number of prefixes 1

  ! Show advertised routes to CE
  PE1#show bgp vpnv4 unicast vrf VPN-A1 neighbors 172.16.0.2 advertised-routes
  BGP table version is 16, local router ID is 1.0.0.10
  Status codes: * valid, > best, i - internal, (…)
  Origin codes: i - IGP, e - EGP, ? - incomplete

     Network          Next Hop            Metric LocPrf Weight Path
  Route Distinguisher: 100:0 (default for vrf VPN-A1)
  *>i192.168.2.0      1.0.0.13                 0    100      0 64512 i

  Total number of prefixes 1
              
CE2 PE2

  ! Show the BGP neighbors
  CE2#show bgp ipv4 unicast neighbors
  BGP neighbor is 172.16.0.5,  remote AS 100, external link
    BGP version 4, remote router ID 1.0.0.13
    BGP state = Established, up for 00:47:44
    (…)

  ! Show advertised routes to PE
  CE2#show bgp ipv4 unicast neighbors 172.16.0.5 advertised-routes
  Status codes: * valid, > best, i - internal, (…)
  Origin codes: i - IGP, e - EGP, ? - incomplete


     Network          Next Hop     Metric LocPrf Weight Path
  *> 192.168.2.0      0.0.0.0           0         32768 i

  Total number of prefixes 1

  ! Show received routes from PE
  CE2#show bgp ipv4 unicast neighbors 172.16.0.5 routes
  Status codes: * valid, > best, i - internal, (…)
  Origin codes: i - IGP, e - EGP, ? - incomplete


     Network          Next Hop     Metric LocPrf Weight Path
  *> 192.168.1.0      172.16.0.5                      0 100 64512 i

  Total number of prefixes 1
              

  ! Show the BGP neighbors (in VRF)
  PE2#show bgp vpnv4 unicast vrf VPN-A2 neighbors
  BGP neighbor is 172.16.0.6,  vrf VPN-A2,  remote AS 64512, external link
    BGP version 4, remote router ID 192.168.2.254
    BGP state = Established, up for 00:49:0
    (…)

  ! Show received routes from CE
  PE2#show bgp vpnv4 unicast vrf VPN-A2 neighbors 172.16.0.6 routes
  Status codes: * valid, > best, i - internal, (…)
  Origin codes: i - IGP, e - EGP, ? - incomplete

     Network          Next Hop            Metric LocPrf Weight Path
  Route Distinguisher: 100:1 (default for vrf VPN-A2)
  *> 192.168.2.0      172.16.0.6               0             0 64512 i

  Total number of prefixes 1

  ! Show advertised routes to CE
  PE2#show bgp vpnv4 unicast vrf VPN-A2 neighbors 172.16.0.6 advertised-routes
  Status codes: * valid, > best, i - internal, (…)
  Origin codes: i - IGP, e - EGP, ? - incomplete

     Network          Next Hop            Metric LocPrf Weight Path
  Route Distinguisher: 100:1 (default for vrf VPN-A2)
  *>i192.168.1.0      1.0.0.10                 0    100      0 64512 i

  Total number of prefixes 1
              

Bon… Cela devient verbeux mais ce qu'il faut retenir, ce sont les concepts. À commencer par le parallèle entre les commandes BGP côté CE et côté PE :

C'est car le peering BGP est établi en VRF côté PE et en GRT (Global Routing Table) côté CE—c'est-à-dire, dans la table de routage par défaut. De plus, nous voyons bien AS64512 apparaître dans AS_PATH sur les CE, particularité rendue possible grâce à l'option allowas-in abordée plus haut.

Le mode d'allocation des labels sur les PE

Maintenant qu'il y a deux routes dans chaque VRF, nous pouvons remarquer quelque chose. Pour cela, et comme pour les attachment circuits à l'étape 4, affichons les tables de routage en VRF, les routes VPN-IPv4 reçues et les LFIB sur les PE :

PE1 PE2

  ! Show the VRF IP Routing Information Base (RIB)
  PE1#show ip route vrf VPN-A1

  Routing Table: VPN-A1
  Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP (…)
       172.16.0.0/30 is subnetted, 2 subnets
  B       172.16.0.4 [200/0] via 1.0.0.13, 01:03:52
  C       172.16.0.0 is directly connected, FastEthernet0/1
  B    192.168.1.0/24 [20/0] via 172.16.0.2, 00:01:07
  B    192.168.2.0/24 [200/0] via 1.0.0.13, 00:00:52

  ! Show the received VPN-IPv4 route (from PE2)
  PE1#show bgp vpnv4 unicast vrf VPN-A1 192.168.2.0 255.255.255.0
  BGP routing table entry for 100:0:192.168.2.0/24, version 12
  Paths: (1 available, best #1, table VPN-A1)
    Advertised to update-groups:
       1
    64512, imported path from 100:1:192.168.2.0/24
      1.0.0.13 (metric 31) from 1.0.0.13 (1.0.0.13)
        Origin IGP, metric 0, localpref 100, valid, internal, best
        Extended Community: RT:100:3
        mpls labels in/out nolabel/44

  ! Show the Label Forwarding Information Base (LFIB)
  PE1#show mpls forwarding-table
  Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
  tag    tag or VC   or Tunnel Id      switched   interface
  16     Pop tag     1.0.0.2/31        0          Fa0/0      1.0.0.1
  17     26          1.0.0.4/31        0          Fa0/0      1.0.0.1
  18     Pop tag     1.0.0.11/32       0          Fa0/0      1.0.0.1
  19     28          1.0.0.12/32       0          Fa0/0      1.0.0.1
  20     29          1.0.0.13/32       0          Fa0/0      1.0.0.1
  21     Aggregate   172.16.0.0/30[V]  0
  22     Untagged    192.168.1.0/24[V] 0          Fa0/1      172.16.0.2


              

  ! Show the VRF IP Routing Information Base (RIB)
  PE2#show ip route vrf VPN-A2

  Routing Table: VPN-A2
  Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP (…)
       172.16.0.0/30 is subnetted, 2 subnets
  C       172.16.0.4 is directly connected, FastEthernet0/1
  B       172.16.0.0 [200/0] via 1.0.0.10, 01:05:03
  B    192.168.1.0/24 [200/0] via 1.0.0.10, 00:02:01
  B    192.168.2.0/24 [20/0] via 172.16.0.6, 00:02:14

  ! Show the received VPN-IPv4 route (from PE1)
  PE2#show bgp vpnv4 unicast vrf VPN-A2 192.168.1.0 255.255.255.0
  BGP routing table entry for 100:1:192.168.1.0/24, version 16
  Paths: (1 available, best #1, table VPN-A2)
    Advertised to update-groups:
       1
    64512, imported path from 100:0:192.168.1.0/24
      1.0.0.10 (metric 31) from 1.0.0.10 (1.0.0.10)
        Origin IGP, metric 0, localpref 100, valid, internal, best
        Extended Community: RT:100:2
        mpls labels in/out nolabel/22

  ! Show the Label Forwarding Information Base (LFIB)
  PE2#show mpls forwarding-table
  Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
  tag    tag or VC   or Tunnel Id      switched   interface
  38     18          1.0.0.0/31        0          Fa0/0      1.0.0.4
  39     Pop tag     1.0.0.2/31        0          Fa0/0      1.0.0.4
  40     19          1.0.0.10/32       0          Fa0/0      1.0.0.4
  41     20          1.0.0.11/32       0          Fa0/0      1.0.0.4
  42     Pop tag     1.0.0.12/32       0          Fa0/0      1.0.0.4
  43     Aggregate   172.16.0.4/30[V]  0
  44     Untagged    192.168.2.0/24[V] 0          Fa0/1      172.16.0.6
              

Les deux dernières lignes sont à noter. Un label différent a été alloué pour chaque route VPN-IPv4. Sur PE1, il s'agit des labels 21 et 22. Sur PE2, il s'agit des labels 43 et 44. En quoi est-ce notable ? Sur un vrai réseau opérateur, il peut y avoir des milliers de VRF dans lesquelles peuvent se trouver des centaines de routes. Par conséquent, les labels alloués peuvent poser un problème de mémoire au PE. En fait, trois modes d'allocation avaient été proposés :


      Whether or not each route has a distinct label is an implementation
      matter.  There are a number of possible algorithms one could use to
      determine whether two routes get assigned the same label:

        - One may choose to have a single label for an entire VRF (…)
        - One may choose to have a single label for each attachment circuit (…)
        - One may choose to have a distinct label for each route (…)

      There may be other possible algorithms as well.  The choice of
      algorithm is entirely at the discretion of the egress PE, and is
      otherwise transparent.
    

Chez Cisco, ces modes sont respectivement nommés per-vrf, per-ce et per-prefix. Le dernier mode est celui par défaut (et donc le nôtre dans la maquette). Dans la réalité, les deux premiers modes sont davantage employés, le per-vrf étant le plus naturel à mon sens. Ici, cela impliquerait, par exemple, que le label 21 sur PE1 soit alloué pour les deux routes distinctes (de même pour le label 43 sur PE2). Noter qu'il y aurait quand même deux annonces MP-iBGP pour ces routes, cela ne change en rien le protocole d'échange—ainsi, comme le dit l'extrait, l'implémentation est à la discrétion du PE.

Le test final… Enfin !

Voyons si les LAN des CE peuvent se joindre de bout-en-bout :


      CE1#ping 192.168.2.254 source 192.168.1.254 repeat 1

      Type escape sequence to abort.
      Sending 1, 100-byte ICMP Echos to 192.168.2.254, timeout is 2 seconds:
      Packet sent with a source address of 192.168.1.254
      !
      Success rate is 100 percent (1/1), round-trip min/avg/max = 140/140/140 ms
    
cap-mpls-l3vpn-ping-ce1-ce2
Capture sur le lien P1 — P2. Ping de CE1 à CE2. On retrouve le paquet IP encapsulé dans la label stack MPLS avec les labels 44 (VPN) et 21 (LSP). Noter que le label LSP est le même celui du ping des attachment circuits (étape 5).

Victoire ! Achevons ceci avec un traceroute :


      CE1#traceroute 192.168.2.254 source 192.168.1.254 probe 1

      Type escape sequence to abort.
      Tracing the route to 192.168.2.254

        1 172.16.0.1 20 msec
        2 1.0.0.1 [MPLS: Labels 29/44 Exp 0] 124 msec
        3 1.0.0.3 [MPLS: Labels 21/44 Exp 0] 144 msec
        4 172.16.0.5 [MPLS: Label 44 Exp 0] 120 msec
        5 172.16.0.6 112 msec
    

Petit exercice…

À ce stade, comme précédemment, vous devriez être capable de déterminer à partir des LFIB MPLS présentées (étape 2 de la première partie et étape 6 de cette seconde partie) la stack de labels dans le sens CE2 → CE1.


          CE2#traceroute 192.168.1.254 source 192.168.2.254 probe 1

          Type escape sequence to abort.
          Tracing the route to 192.168.1.254

            1 172.16.0.5 8 msec
            2 1.0.0.4 [MPLS: Labels 19/22 Exp 0] 116 msec
            3 1.0.0.2 [MPLS: Labels 27/22 Exp 0] 156 msec
            4 172.16.0.1 [MPLS: Label 22 Exp 0] 112 msec
            5 172.16.0.2 124 msec
        

Le mot de la fin

Si vous êtes arrivé jusqu'ici, félicitation !

Cet article, et la deuxième partie en particulier, a été dense en notions : backbone, IGP, LDP, VRF, plan de contrôle (BGP, MP-BGP), plan de données (MPLS), etc. Plutôt que de simplement lister les commandes à exécuter pour parvenir à ce réseau opérateur miniature puis dire « regardez, ça marche », j'ai souhaité aborder des questions souvent posées dans le milieu opérateur (quel mode d'adressage ? pourquoi ce mode ? quel routage CE-PE ? pourquoi BGP ? etc.).

L'idée du métier d'ingénieur n'est pas de maîtriser une implémentation particulière, mais de saisir les concepts l'ayant engendré. Ainsi, le parallèle répété avec les RFC est important pour montrer que Cisco n'est qu'une implémentation de ceci et qu'il en existe d'autres (Huawei, Nokia, Juniper, etc.). Si vous travaillez chez un opérateur qui a un backbone IP/MPLS, vous retrouverez sans doute dans celui-ci nombre de concepts évoqués ici.