# 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](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](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

Une solution retenu pour gérer le traffic BUM est le Multicast Underlay et le Ingress 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](https://pe.t8.noe-charlier.fr/uploads/images/gallery/2026-06/g043188.gif)](https://pe.t8.noe-charlier.fr/uploads/images/gallery/2026-06/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](https://pe.t8.noe-charlier.fr/uploads/images/gallery/2026-06/scaled-1680-/g043189.png)](https://pe.t8.noe-charlier.fr/uploads/images/gallery/2026-06/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

```text
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 :

```text
BGP neighbor = Loopback IP
```

Ex :

```text
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 :

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

---

#### Étape 4 — VXLAN utilise ces infos

Quand Leaf1 reçoit un paquet :

```text
Host A → Host B (MAC inconnue ou connue)
```

Leaf1 regarde EVPN table :

```text
MAC B → VTEP Leaf2
```

---

#### Étape 5 — VXLAN encapsule

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

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

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

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