Skip to main content

Lab 2 - BGP EVPN VXLAN Fabric

Fabric VXLAN EVPN

Configuration complète: https://git.uttnetgroup.fr/PE-Redondance/VXLAN-C9300L/src/branch/main/vxlan-lab2

Nous allons mettre en place une fabric VXLAN avec les switchs de la D206.

On se base sur la doc cisco: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/vxlan/b_1715_bgp_evpn_vxlan_9300_cg/configuring_spine_switches_in_a_bgp_evpn_vxlan_fabric.html

Structure

          Spine1 (RR + RP)
         /               \
        /                 \
Leaf1                       Leaf2
        \                 /
         \               /
          Spine2 (RR + RP)

Dans cette structure nous avons les spines jouant le rôle intermediaire entre les leaf (qui seront les VTEP VXLAN).

Pour mettre à bien cette fabric nous allons utiliser différentes technologies:

  • VXLAN qui agira comme data plane
  • EVPN (avec MP-BGP) comme control plane
  • OSPF pour l'underlay IP.
  • Du multicast pour la gestion du traffic BUM (Broadcast; Unknown Unicast; Multicast)
            ┌──────────────────────────────┐
            │        EVPN (BGP)            │  ← contrôle overlay (MAC/IP/VTEP)
            └────────────┬─────────────────┘
                         │
            ┌────────────▼─────────────────┐
            │       VXLAN (data plane)     │  ← encapsulation Ethernet over UDP
            └────────────┬─────────────────┘
                         │
            ┌────────────▼─────────────────┐
            │   Underlay IP (OSPF)        │  ← transport IP pur
            └──────────────────────────────┘

Gestion du traffic BUM - Multicast Underlay

LaUne solution retenu pour gérer le traffic BUM est le Multicast Underlay (auet lieu dule Ingress Replication).Replication.

Leaf1 envoie un seul paquet vers un groupe multicast.

Exemple :

239.1.1.100

Le réseau PIM se charge de la duplication.

PIM (Le BUM Data Plane)

PIM est Protocol Independent Multicast.

PIM permet de construire les arbres multicast.

Multicast RP

Chaque Spine est un Anycast RP (Rendezvous Point) (Sparse Mode).

Exemple:

Quand Leaf2 veut recevoir :

239.1.1.100

il envoie :

PIM Join

vers le RP.

Quand Leaf1 émet :

239.1.1.100

il envoie aussi vers le RP.

MSDP

MSDP pour Multicast Source Discovery Protocol.

Permet à Spine1 de savoir ce que Spine2 sait.

Sinon:

Source connue par Spine1
Récepteur connecté à Spine2

Mais personne ne communique entre les deux.

Exemple:

VNI 10010

Leaf1
Leaf2
Leaf3

associés à :

239.1.1.10

Leaf2 et Leaf3 rejoignent :

239.1.1.10

via PIM.

Leaf1 reçoit un ARP Broadcast.

Il encapsule :

VXLAN
VNI 10010
Destination multicast :
239.1.1.10

L'underlay multicast :

Leaf1
  |
Spine
 / \
L2 L3

réplique automatiquement.

Leaf2 reçoit :

ARP Request

Leaf3 reçoit :

ARP Request

sans que Leaf1 ait dû envoyer deux copies.

Gestion du traffic BUM - Ingress Replication

Une autre méthode plus simple c'est de faire du Ingress Replication qui est de plus en plus utilisé (car plus simple, mais plus gourmand en ressources.)

Leaf1 crée lui-même N copies.

Exemple :

      Leaf1
        |
   +----+----+
   |    |    |
Leaf2 Leaf3 Leaf4

Pour un broadcast :

Copy 1 -> Leaf2
Copy 2 -> Leaf3
Copy 3 -> Leaf4

Le leaf source fait tout le travail.

C'est ce qu'on appelle :

  • HER (Head End Replication)
  • Ingress Replication

Les routes EVPN Type 3 servent notamment à annoncer les VTEP participants afin que le leaf sache à qui envoyer ces copies.

g043188.gif

(source: https://www.juniper.net/documentation/fr/fr/software/junos/evpn/topics/concept/vxlan-evpn-integration-overview.html)

Gestion du traffic Unicast

g043189.png

(source: https://www.juniper.net/documentation/fr/fr/software/junos/evpn/topics/concept/vxlan-evpn-integration-overview.html)

Chemin classique

Étape 1 — OSPF construit le transport

Leaf1 → OSPF → Leaf2 reachable via IP

donc Leaf1 peut envoyer des paquets IP à Leaf2 loopback

Étape 2 — BGP EVPN monte dessus

BGP utilise OSPF pour établir ses sessions :

BGP neighbor = Loopback IP

Ex :

neighbor 22.22.22.22 remote-as 65001
update-source loopback0

donc :

  • OSPF = reachability
  • BGP = overlay control plane

Étape 3 — EVPN distribue les infos VXLAN

BGP EVPN annonce :

MAC A → Leaf2
VNI 10010 members → Leaf1/2/3

Étape 4 — VXLAN utilise ces infos

Quand Leaf1 reçoit un paquet :

Host A → Host B (MAC inconnue ou connue)

Leaf1 regarde EVPN table :

MAC B → VTEP Leaf2

Étape 5 — VXLAN encapsule

Ethernet frame
↓
VXLAN tunnel
↓
IP via OSPF underlay

Configuration de base

La configuration ci-dessous correspond à la mise en place VXLAN/EVPN du lab2, qui sert ensuite de socle au lab3. On garde ici le modèle simple sans multi-homing : une fabric avec deux spines, deux leafs VTEP, un underlay OSPF et un overlay BGP EVPN.

L’idée est d’appliquer exactement les briques décrites plus haut :

  • OSPF pour la reachability underlay,
  • BGP EVPN pour distribuer les informations de contrôle,
  • VXLAN pour encapsuler les VLANs du campus,
  • multicast,
  • des loopbacks stables pour le routage et le NVE.

Configuration commune des leafs

Les leafs sont les VTEP VXLAN (via les interfaces NVE qui s'occupe de désencapsuler les trames). Elles portent les VLANs du domaine utilisateur, construisent les tunnels VXLAN et annoncent leurs informations via EVPN.

vrf definition green
 rd 1:1
 !
 address-family ipv4
  route-target export 1:1
  route-target import 1:1
  route-target export 1:1 stitching
  route-target import 1:1 stitching
 exit-address-family
 !
 address-family ipv6
  route-target export 1:1
  route-target import 1:1
  route-target export 1:1 stitching
  route-target import 1:1 stitching
 exit-address-family

ip routing
ip multicast-routing

l2vpn evpn
 replication-type static
 router-id Loopback1
 default-gateway advertise

l2vpn evpn instance 101 vlan-based
 encapsulation vxlan
 replication-type static

l2vpn evpn instance 102 vlan-based
 encapsulation vxlan
 replication-type ingress

vlan configuration 101
 member evpn-instance 101 vni 10101
vlan configuration 102
 member evpn-instance 102 vni 10102
vlan configuration 901
 member vni 50901

interface Loopback0
 ip address 172.16.255.3 255.255.255.255
 ip ospf 1 area 0

interface Loopback1
 ip address 172.16.254.3 255.255.255.255
 ip pim sparse-mode
 ip ospf 1 area 0

interface nve1
 no ip address
 source-interface Loopback1
 host-reachability protocol bgp
 member vni 10101 mcast-group 225.0.0.101
 member vni 10102 ingress-replication
 member vni 50901 vrf green

router ospf 1
 router-id 172.16.255.3

router bgp 65001
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 172.16.255.1 remote-as 65001
 neighbor 172.16.255.1 update-source Loopback0
 neighbor 172.16.255.2 remote-as 65001
 neighbor 172.16.255.2 update-source Loopback0
 !
 address-family l2vpn evpn
  neighbor 172.16.255.1 activate
  neighbor 172.16.255.1 send-community both
  neighbor 172.16.255.2 activate
  neighbor 172.16.255.2 send-community both
 exit-address-family
 !
 address-family ipv4 vrf green
  advertise l2vpn evpn
  redistribute static
  redistribute connected
 exit-address-family

Dans cette configuration, Loopback0 sert d’adresse de voisinage BGP et Loopback1 sert de source VXLAN. Le router-id OSPF et le router-id EVPN sont choisis sur des loopbacks stables pour éviter qu’un changement d’interface physique ne casse le plan de contrôle.

Le VNI 10101 utilise le multicast underlay pour la diffusion BUM, ce qui colle au principe décrit plus haut. Le VNI 10102 est configuré en ingress replication, ce qui montre qu’on peut mélanger les mécanismes de réplication selon les besoins du service.

Configuration commune des spines

Les spines servent de transport underlay et de route reflectors BGP. Ils ne portent pas de VNIs, mais ils doivent rendre les loopbacks des leafs joignables et relayer les sessions EVPN.

ip routing
ip multicast-routing

interface Loopback0
 ip address 172.16.255.1 255.255.255.255
 ip ospf 1 area 0

interface Loopback1
 ip address 172.16.254.1 255.255.255.255
 ip ospf 1 area 0

interface Loopback2
 ip address 172.16.255.255 255.255.255.255
 ip pim sparse-mode
 ip ospf 1 area 0

interface GigabitEthernet2/0/1
 no switchport
 ip address 172.16.13.1 255.255.255.0
 ip pim sparse-mode
 ip ospf network point-to-point
 ip ospf 1 area 0

interface GigabitEthernet2/0/2
 no switchport
 ip address 172.16.14.1 255.255.255.0
 ip pim sparse-mode
 ip ospf network point-to-point
 ip ospf 1 area 0

interface GigabitEthernet2/0/3
 no switchport
 ip address 172.16.15.1 255.255.255.0
 ip pim sparse-mode
 ip ospf network point-to-point
 ip ospf 1 area 0

router ospf 1
 router-id 172.16.255.1

router bgp 65001
 template peer-policy RR-PP
  route-reflector-client
  send-community both
 exit-peer-policy
 !
 template peer-session RR-PS
  remote-as 65001
  update-source Loopback0

Les mêmes principes s’appliquent sur Spine-02, avec les adresses adaptées. L’idée est de garder un underlay simple : les leafs s’envoient leurs loopbacks via OSPF, puis BGP EVPN s’appuie dessus pour diffuser les routes MAC/IP et les informations VXLAN.

Configuration des ports d’accès

Le lab2 utilise ensuite des ports d’accès classiques sur les leafs pour rattacher les VLANs aux VTEP. C’est cette partie qui rend la fabric exploitable pour des machines ou des services locaux.

interface GigabitEthernet1/0/12
 switchport access vlan 101
 switchport mode access

interface GigabitEthernet1/0/24
 switchport access vlan 101
 switchport mode access

Avec cette configuration, le lab2 fournit le socle de base : un domaine L2 distribué par VXLAN EVPN, sans redondance d’accès avancée. Le lab3 reprendra ce socle en ajoutant seulement la couche multi-homing, sans devoir refaire l’underlay ni le mapping VXLAN.

Back to top