Table des matières

Introduction

Problème

Conditions

Configuration

Analyse

Solution

Introduction

Ce document décrit la solution aux failles du protocole BGP (Border Gateway Protocol) entre Cisco Ultra Packet Core (UPC) et le commutateur Nexus 9000 configuré avec une connexion BGP redondante.

Problème

Les défaillances BGP sont déclenchées lorsque l'une des interfaces redondantes entre le coeur de réseau Cisco Ultra Packet Core et le commutateur Nexus est défaillante.

Conditions

Le noeud UPC (Ultra Packet Core) est connecté à Nexus Leaf A et Leaf B sur des ports distincts. Les homologues IPv6 BGP sont établis et les routes par défaut sont installées sur le noeud UPC. La Figure 1 présente le schéma de réseau de haut niveau avec un chemin redondant vers les commutateurs Leaf.

Figure 1 : Schéma de réseau

Configuration

Configuration des ports UPC avec liaison VLAN et interface :

port ethernet 1/10

no shutdown

vlan 140

no shutdown

bind interface saegw_vlan140_1/10 saegw

#exit

#exit

port ethernet 1/11

no shutdown

vlan 141

no shutdown

bind interface saegw_vlan141_1/11 saegw

#exit

#exit

end

Configuration d'interface UPC avec adresses IP :

interface saegw_vlan140_1/10

ip address 10.11.11..8 255.255.255.0

ipv6 address fd00:10:11:11::8/64 secondary

bfd interval 300 min_rx 300 multiplier 3

#exit

interface saegw_vlan141_1/11

ip address 10.11.12.8 255.255.255.0

ipv6 address fd00:10:11:12::8/64 secondary

bfd interval 300 min_rx 300 multiplier 3

#exit

Configuration BGP UPC :

router bgp 25949

router-id 172.19.20.30

maximum-paths ebgp 4

neighbor 10.11.11..1 remote-as 25949

neighbor 10.11.11..1 fall-over bfd

neighbor 10.11.12.1 remote-as 25949

neighbor 10.11.12.1 fall-over bfd

neighbor fd00:10:11:11::1 remote-as 25949

neighbor fd00:10:11:12::1 remote-as 25949

address-family ipv4

neighbor 10.11.11..1 route-map accept_default in

neighbor 10.11.11..1 route-map gw-1-OUT out

neighbor 10.11.12.1 route-map accept_default in

neighbor 10.11.12.1 route-map gw-1-OUT out

redistribute connected

#exit

address-family ipv6

neighbor fd00:10:11:11::1 activate

neighbor fd00:10:11:11::1 route-map accept_v6_default in

neighbor fd00:10:11:11::1 route-map allow_service_ips_v6 out

neighbor fd00:10:11:12::1 activate

neighbor fd00:10:11:12::1 route-map accept_v6_default in

neighbor fd00:10:11:12::1 route-map allow_service_ips_v6 out

redistribute connected

#exit

ipv6 prefix-list name accept_v6_default_routes seq 10 permit ::/0

route-map accept_v6_default permit 10

match ipv6 address prefix-list accept_v6_default_routes

#exit

Configuration du commutateur Nexus 9000 :

Interface vlan140

ipv6 address fd00:10:11:11::1/64

no ipv6 redirects

interface vlan141

ipv6 address fd00:10:11:12::1/64

no ipv6 redirects

vrf upc

address-family ipv4 unicast

advertise l2vpn evpn

maximum-paths ibgp 2

address-family ipv6 unicast

advertise l2vpn evpn

maximum-paths ibgp 2

neighbor fd00:10:11:12::5

remote-as 25949

address-family ipv6 unicast

neighbor fd00:10:11:12::6

remote-as 25949

address-family ipv6 unicast

neighbor fd00:10:11:12::8

remote-as 25949

address-family ipv6 unicast

Analyse

Initialement, une communication BGP normale entre l'une des interfaces UPC (fd00:10:11:12::8) et le commutateur Nexus (fd00:10:11:12::1 appartient à vlan141) est observée qui inclut des messages TCP ACK :

2023-01-01 01:01:59.000000 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=8664 Win=31744 Len=0 TSV=2412344062 TSER=531234647

2023-01-01 01:01:59.000087 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=11520 Win=37376 Len=0 TSV=2412344062 TSER=531234647

2023-01-01 01:01:59.000162 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=14376 Win=43008 Len=0 TSV=241234062 TSER=531234647

2023-01-01 01:01:59.000281 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=17232 Win=49152 Len=0 TSV=2412344062 TSER=531234647

2023-01-01 01:01:59.000936 fd00:10:11:12::8 -> fd00:10:11:12::1 TCP 35813 > bgp [ACK] Seq=250 Ack=20663 Win=48640 Len=0 TSV=2412344063 TSER=531234647

En cas de défaillance de l'interface Leaf-B vers UPC, un comportement incorrect est observé dans les journaux où une nouvelle tentative de connexion BGP est initiée par l'UPC ( source: fd00:10:11:12::8) vers le Leaf-A sur l'interface fd00:10:11:11::1, qui appartient à un VLAN différent, vlan140.

2023-01-01 22:36:12.370117 fd00:10:11:12::8 -> fd00:10:11:11::1 TCP 41987 > bgp [SYN] Seq=0 Win=14400 Len=0 MSS=1440 TSV=2412347369 TSER=0 WS=9

Un tel message SYN BGP non valide envoyé sur une interface incorrecte entraîne l'arrêt du BGP. Lorsque le Nexus annonce sa propre route connectée et que l'UPC obtient une route pour l'interface qui était en panne sur BGP, alors l'UPC tente une connexion via une autre interface avec une adresse IP sortante différente/incorrecte.

Solution

En raison de la configuration mentionnée dans la section Condition de cet article, puisque UPC reçoit les informations de route connectée des deux Leaf des deux interfaces, quand l'une des interfaces est désactivée, UPC tente de communiquer avec ce Leaf par l'intermédiaire de l'autre interface.

Pour éviter qu'UPC n'envoie les messages d'établissement de connexion BGP à partir d'une interface incorrecte, voici les modifications de configuration à prendre en compte :

1. Dans la configuration UPC, ajoutez update-source pour le voisin. Cette configuration empêche la connexion BGP à partir d'une autre interface, si l'interface principale est désactivée. Par exemple, lorsque saegw_vlan140_1/10 (fd00:10:11:11::1/64) est en panne, le noeud ne peut pas utiliser l'interface sortante saegw_vlan141_1/11 pour l'homologue BGP fd00:10:11:11::8.

Voici un exemple de configuration :

neighbor fd00:10:11:11::1 update-source fd00:10:11:11::8

neighbor fd00:10:11:12::1 update-source fd00:10:11:12::8

2. Dans la configuration Nexus, bloquez les préfixes des mauvaises interfaces.

Par exemple, nous refusons les routes pour le leaf redondant sur le voisin fd00:10:11:11::1

neighbor fd00:10:11:11::1

update prefix list to deny fd00:10:11:12::8/64

3. Dans le commutateur Nexus, l'appairage EBGP du VTEP à un noeud externe sur VXLAN doit se trouver dans un VRF de locataire et doit utiliser le update-source d'un loopback (appairage sur VXLAN) comme recommandé dans le Guide de configuration Cisco Nexus 9000