Fehlerbehebung, warum externe EIGRP-Route gegenüber BGP bevorzugt wird

Download-Optionen

PDF (1.0 MB)
Mit Adobe Reader auf verschiedenen Geräten anzeigen
ePub (890.0 KB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Mobi (Kindle) (282.1 KB)
Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen

Aktualisiert:23. Juni 2024

Dokument-ID:222088

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Inhalt

Einleitung

Voraussetzungen

Einrichtung und Topologie

Problemaussage

Problemübersicht

Fehlerbehebung und Verifizierung

Warum wird die EIGRP-Route der eBGP-Route vorgezogen?

Lösung

Einleitung

In diesem Dokument wird das Routing-Verhalten im ACI-Leaf-Switch beschrieben, wenn dieser dieselbe Route über EIGRP und eBGP empfängt.

Voraussetzungen

Der Leser muss mit den ACI-Komponenten, -Terminologien und -Abläufen sowie den Routing-Protokollen (EIGRP und BGP) vertraut sein.

Einrichtung und Topologie

Topologie

Diese Einrichtung erfolgte mithilfe von 2 verschiedenen ACI-Fabrics, die wie folgt verbunden sind:

Direkte Verbindung zwischen den beiden DC Border Leaf Switches (BGP).
Erweiterung über WAN-Netzwerk (EIGRP). SW1 und SW2 sind WAN-Switches.

2. 192.168.10.0/24 ist ein internes ACI-Subnetz, das an Fabric-1 angeschlossen und Fabric-2 über eBGP und EIGRP angekündigt ist.

Problemaussage

Der Fabric-2-Border-Leaf-Switch empfängt dieselbe Route über EIGRP und eBGP, wobei die eBGP-Route erwartungsgemäß in der Routing-Tabelle des Switches installiert wird. Wenn die eBGP-Sitzung ausfällt, werden EIGRP-Routen in der Routing-Tabelle des Switches installiert. Der Switch behält die EIGRP-Route bei, selbst wenn das eBGP aktiviert ist. Es wird erwartet, dass die eBGP-Route in der Routing-Tabelle installiert wird, sobald die eBGP-Sitzung gestartet wird, da eBGP einen geringeren AD-Wert [ 20 ] als EIGRP [ 90 ] aufweist.

Problemübersicht

Fabric-1- und Fabric-2-Rechenzentren sind über ein WAN-Netzwerk (EIGRP) und eine direkte Verbindung zwischen den beiden eBGP-Switches an den Standorten BL verbunden.
Der Fabric-1 Border Leaf-Switch kündigt das Subnetz 192.168.10.0/24 via eBGP und EIGRP an Fabric-2 an.
Beide L3Out verwenden dieselbe VRF-Instanz.
Die BGP-Route wird in der Routing-Tabelle des Fabric-2 Border Leaf-Switches basierend auf dem AD-Wert installiert.
Wenn die eBGP-Sitzung zwischen Fabric-1 und Fabric-2 ausfällt, wird die EIGRP-Route in der Routingtabelle des Fabric-2_BL-Switches installiert, was erwartet wird.
Beim eBGP wird davon ausgegangen, dass die eBGP-Route neu installiert und die EIGRP-Route aus der Routing-Tabelle entfernt wird, was nicht der Fall ist.
Beim Fabric-2 Border Leaf-Switch verbleibt die EIGRP-Route stattdessen in der Routing-Tabelle.

Fehlerbehebung und Verifizierung

Überprüfen der eBGP-Nachbarschaft zwischen den Fabric-1- und Fabric-2 Border Leaf-Switches

Fabric-2_BL# show bgp sessions vrf snTn:snTn_VRF
Total peers 3, established peers 3
ASN 100
VRF snTn:snTn_VRF, local ASN 100
peers 1, established peers 1, local router-id 172.16.2.100
State: I-Idle, A-Active, O-Open, E-Established, C-Closing, S-Shutdown

Neighbor        ASN    Flaps LastUpDn|LastRead|LastWrit St Port(L/R)  Notif(S/R)

10.10.10.3     65001     2   1d23h   |never   |never    E  179/26051    45/6

Verifizieren der EIGRP-Nachbarschaft in Fabric-2

Fabric-2_BL# show ip eigrp neighbors vrf snTn:snTn_VRF
EIGRP neighbors for process 500 VRF snTn:snTn_VRF
H   Address                 Interface       Hold  Uptime  SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   10.10.20.3              vlan7           13   2d00h     1    50    0   8

SW-2# show ip eigrp neighbors VRF default
IP-EIGRP neighbors for process 500 VRF default
H   Address                 Interface       Hold  Uptime  SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num

0   10.10.20.2              Vlan776          14   2d00h    6    50    0   9

Anfangs wird die BGP-Route in der Routing-Tabelle installiert, und dieselbe Route ist in der EIGRP-Topologietabelle des Fabric-2 Border Leaf-Switches vorhanden.

Fabric-2_BL# show ip route 192.168.10.0/24 vrf snTn:snTn_VRF
IP Route Table for VRF "snTn:snTn_VRF"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.168.10.0/24, ubest/mbest: 1/0

    *via 10.10.10.3%snTn:snTn_VRF, [20/0], 00:00:17, bgp-100, external, tag 65005

         recursive next hop: 10.10.10.3/32%snTn:snTn_VRF

Fabric-2_BL# show ip eigrp topology 192.168.10.0/24 vrf snTn:snTn_VRF

EIGRP (AS 500): VRF: snTn:snTn_VRF , Topology entry for 192.168.10.0/24
  State is Passive, Query origin: Local origin, 0 Successor(s),  FD is Infinity
  Routing Descriptor Blocks:

   10.10.20.3(vlan7), from 10.10.20.3
    Urib State: in-rib,up-to-date
      Composite metric is (128576/128320), Route is Internal
      Vector metric:
        Minimum bandwidth is 8000000 Kbit
        Total delay is 5010 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Internal tag is 0

Die EIGRP-Route wird in der Routing-Tabelle des Fabric-2 Border Leaf-Switches installiert, wenn die eBGP-Sitzung zwischen den Fabric-1- und Fabric-2 Border Leaf-Switches ausfällt, und behält die EIGRP-Route bei, selbst wenn das eBGP aktiviert wird.

Fabric-2_BL# show ip route 192.168.10.0/24 vrf snTn:snTn_VRF
IP Route Table for VRF "snTn:snTn_VRF
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.168.10.0/24, ubest/mbest: 1/0
    *via 10.10.20.3, vlan7, [90/128576], 2d00h, eigrp-default, internal

Es wird hierbei davon ausgegangen, dass die eBGP-Route in der Routing-Tabelle neu installiert werden muss, sobald die eBGP-Sitzung beginnt. Der Fabric-2_BL-Switch behält jedoch nur die EIGRP-Route bei.

Warum wird die EIGRP-Route der eBGP-Route vorgezogen?

Wenn die eBGP-Sitzung ausfällt, installiert der Fabric-2_BL-Switch die EIGRP-Route in der Routing-Tabelle, und diese wird in das MP-BGP umverteilt, um sie an andere Service-Leaf-Switches im Fabric-2 weiterzuleiten.
Da der Fabric-2_BL-Switch ihn neu verteilt, wird er zu einem Ausgangspunkt für diese Route mit dem Standardgewichtungswert 32768. Die vom eBGP kommende Route hingegen hat das Gewicht 0.
Da eine höhere Gewichtung bevorzugt wird, betrachtet der Fabric-2_BL-Switch die neu verteilte Route als beste Route und installiert keine eBGP-Route.
Die unten gezeigte Ausgabe zeigt an, wann die eBGP-Sitzung wieder aufgenommen wurde.

Fabric-2_BL# show ip bgp 192.168.10.0/24 vrf snTn:snTn_VRF
BGP routing table information for VRF snTn:snTn_VRF, address family IPv4 Unicast
BGP routing table entry for 192.168.10.0/24, version 28 dest ptr 0xa0fe0328
Paths: (2 available, best #1)
Flags: (0x80c0002 00000000) on xmit-list, is not in urib, exported
  vpn: version 371, (0x100002) on xmit-list
Multipath: eBGP iBGP

  Advertised path-id 1, VPN AF advertised path-id 1
  Path type (0xa961d880): redist 0x408 0x1 ref 0 adv path ref 2, path is valid, is best path
  AS-Path: NONE, path locally originated
  Tx Domain path attribute Flag 0xc0,Code 36, Length 8, segment length 1
  domain path: { <1:5345:128>}

    0.0.0.0 (metric 0) from 0.0.0.0 (172.16.0.10)
      Origin incomplete, MED 128576, localpref 100, weight 32768 tag 0, propagate 0
      Extcommunity:
          RT:100:2129921
          VNID:2129921
          COST:pre-bestpath:128:128576
          COST:pre-bestpath:162:90
          0x8800:32768:0 (Flags = 32768, Tag = 0)
          0x8801:500:128256 (ASN = 500, Delay = 128256)
          0x8802:65281:320 (Reliability = 255, Hop = 1, Bandwidth = 320)
          0x8803:1:1500 (Reserve = 0, Load = 1, MTU = 1500)
          0x8804:0:0 (Remote ASN = 0, Remote ID = 0)
          0x8805:0:0 (Remote Prot = 0, Remote Metric = 0)

  VPN AF advertised path-id 2
  Path type (0xa961e0bc): external 0x28 0x0 ref 0 adv path ref 1, path is valid, not best reason: Weight
  AS-Path: 65001 , path sourced external to AS
  Source Domain: <1:16:128>
  Tx Domain path attribute Flag 0xc0,Code 36, Length 15, segment length 2
  domain path: { <1:5345:128>,<1:16:128>}

    10.10.10.3 (metric 0) from 10.10.10.3 (172.16.1.100)
      Origin IGP, MED not set, localpref 100, weight 0 tag 0, propagate 0
      Extcommunity:
          RT:100:2129921
          VNID:2129921

  VRF advertise information:
  Path-id 1 not advertised to any peer
  VPN AF advertise information:
  Path-id 1 advertised to peers:
    10.0.152.65        10.0.152.66   
  Path-id 2 not advertised to any peer

Lösung

Es gibt zwei Möglichkeiten, dieses Problem zu beheben:

LPM ist eine der folgenden Lösungen:
1. Geben Sie dasselbe Subnetz mit der /23-Maske unter der EIGRP- und der /24-Maske über eBGP bekannt, sodass beide Routen in der Routing-Tabelle des Fabric-2_BL-Switches vorhanden sind.

SW-2# show run interface vlan 776

!Command: show running-config interface Vlan776
!Time: Sun Jun 23 06:30:43 2024

version 7.0(3)I7(5) Bios:version 07.66 

interface Vlan776
  no shutdown
  ip address 10.10.20.3/24
  ip router eigrp 500
  ip summary-address eigrp 500 192.168.10.0/23   >>>>>> Advertised /23 via EIGRP

Fabric-2_BL# show ip route vrf snTn:snTn_VRF

IP Route Table for VRF "snTn:snTn_VRF"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.168.10.0/23, ubest/mbest: 1/0
    *via 10.10.20.3, vlan20, [90/128576], 00:24:11, eigrp-default, internal    >>>>>>>>> EIGRP Route

192.168.10.0/24, ubest/mbest: 1/0
    *via 10.10.10.3%snTn:snTn_VRF, [20/0], 00:04:12, bgp-100, external, tag 65005   >>>>>>>> BGP Route

b. Wenn die eBGP-Sitzung ausfällt, ist aus Redundanzgründen weiterhin eine EIGRP-Route in der Routing-Tabelle vorhanden.

c. Sobald die BGP-Sitzung beginnt, wird die BGP-Route in der Routing-Tabelle neu installiert und für die Weiterleitung von Datenverkehr bevorzugt.

Gewicht auf eBGP-Route anwenden:
1. Wenn Sie das Subnetz mit derselben Subnetzmaske sowohl über EIGRP als auch über BGP ankündigen müssen, kann auf die eBGP-Route eine höhere Gewichtung (als 32768) angewendet werden, um immer die bevorzugte Route zu sein.
2. Wie wird die ACI gewichtet:
  1. Erstellen Sie eine Route-Map-Richtlinie.

Tenant ----> Richtlinien ----> Routenzuordnungen für die Routensteuerung (Klicken Sie mit der rechten Maustaste, und erstellen Sie eine neue Richtlinie, füllen Sie alle erforderlichen Details aus)----> Richtlinie "Regel festlegen" erstellen —> Richtlinie für das Attribut "Gewicht" auswählen und Wert eingeben

Konfiguration 1

ii. Anwenden der Routenübersicht auf L3Out:

Tenant —> Networking —> L3Out ----> Logical Node Profiles —> Node Profile ----> Logical Interface Profile —> Interface Profile —> Peer Profile —> Click on "+" under "Route Control Profile" and select created new Route Map

Konfiguration 2

Fabric-2_BL# show ip bgp 192.168.10.0/24 vrf snTn:snTn_VRF

BGP routing table information for VRF snTn:snTn_VRF, address family IPv4 Unicast
BGP routing table entry for 192.168.10.0/24, version 61 dest ptr 0xa0fa3f70
Paths: (1 available, best #1)
Flags: (0x80c001a 00000000) on xmit-list, is in urib, is best urib route, is in HW, exported
  vpn: version 79, (0x100002) on xmit-list
Multipath: eBGP iBGP

  Advertised path-id 1, VPN AF advertised path-id 1
  Path type (0xa95a2d5c): external 0x28 0x0 ref 0 adv path ref 2, path is valid, is best path
  AS-Path: 65005 65001 , path sourced external to AS
  Source Domain: <1:16:128>
  Tx Domain path attribute Flag 0xc0,Code 36, Length 15, segment length 2
  domain path: { <1:5345:128>,<1:16:128>}
    10.10.10.3 (metric 0) from 10.10.10.3 (172.16.0.10)
      Origin IGP, MED not set, localpref 100, weight 32769 tag 0, propagate 0
      Extcommunity: 
          RT:100:2129921
          VNID:2129921

  VRF advertise information:
  Path-id 1 not advertised to any peer

  VPN AF advertise information:
  Path-id 1 advertised to peers:
    10.0.152.65        10.0.152.66

c. Der Haken hierbei ist, dass eine neu verteilte EIGRP-Route in der BGP-Tabelle nicht angezeigt wird, wenn die BGP-Sitzung aktiv ist. Der Grund dafür ist, dass FD für die externe EIGRP-Route auf "Infinity" gesetzt ist.

Fabric-2_BL# show ip eigrp topology vrf snTn:snTn_VRF

EIGRP Topology Table for AS(500)/ID(172.16.2.100) VRF snTn:snTn_VRF
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

    P 192.168.10.0/24, 0 Successors, FD is Infinity 
      via 10.10.20.3(128576/128320), vlan20

d. Die Meldung "FD is Infinity" (FD ist unendlich) ist tatsächlich ein Indikator innerhalb des EIGRP, dass die RIB die Route abgelehnt hat, da bereits eine Route mit geringerer Admin-Distanz vorhanden ist.

e. Die EIGRP-Route wird nur beim Ausfall der BGP-Sitzung im MP-BGP neu verteilt und in der Routing-Tabelle des Fabric-2_BL-Switches installiert.

Fabric-2_BL# show ip bgp summary vrf snTn:snTn_VRF

BGP summary information for VRF snTn:snTn_VRF, address family IPv4 Unicast
BGP router identifier 172.16.2.100, local AS number 100
BGP table version is 65, IPv4 Unicast config peers 1, capable peers 0
6 network entries and 6 paths using 1248 bytes of memory
BGP attribute entries [4/704], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [2/8]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

10.10.10.3      4 65001   18530   18554        0    0    0 00:04:25   Idle

Fabric-2_BL# show ip eigrp topology vrf snTn:snTn_VRF

IP-EIGRP Topology Table for AS(500)/ID(172.16.2.100) VRF snTn:snTn_VRF
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status 

P 192.168.10.0/24, 1 successors, FD is 128576
        via 10.10.20.3 (128576/128320), Vlan20

Fabric-2_BL# show ip route vrf snTn:snTn_VRF

IP Route Table for VRF "snTn:snTn_VRF"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.168.10.0/24, ubest/mbest: 1/0
    *via 10.10.20.3, Vlan20, [90/128576], 02:31:52, eigrp-default, internal  >>>>>>> EIGRP Route

Fabric-2_BL# show ip bgp 192.168.10.0/24 vrf snTn:snTn_VRF

BGP routing table information for VRF snTn:snTn_VRF, address family IPv4 Unicast
BGP routing table entry for 192.168.10.0/24, version 65 dest ptr 0xa0fa3f70
Paths: (1 available, best #1)
Flags: (0x80c0002 00000000) on xmit-list, is not in urib, exported
  vpn: version 83, (0x100002) on xmit-list
Multipath: eBGP iBGP

  Advertised path-id 1, VPN AF advertised path-id 1
  Path type (0xa95a2c64): redist 0x408 0x1 ref 0 adv path ref 2, path is valid, is best path
  AS-Path: NONE, path locally originated
  Tx Domain path attribute Flag 0xc0,Code 36, Length 8, segment length 1
  domain path: { <1:5345:128>}
    0.0.0.0 (metric 0) from 0.0.0.0 (172.16.0.10)
      Origin incomplete, MED 128576, localpref 100, weight 32768 tag 0, propagate 0
      Extcommunity: 
          RT:100:2129921
          VNID:2129921
          COST:pre-bestpath:128:128576
          COST:pre-bestpath:162:90
          0x8800:32768:0 (Flags = 32768, Tag = 0)
          0x8801:500:128256 (ASN = 500, Delay = 128256)
          0x8802:65281:320 (Reliability = 255, Hop = 1, Bandwidth = 320)
          0x8803:1:1500 (Reserve = 0, Load = 1, MTU = 1500)
          0x8804:0:0 (Remote ASN = 0, Remote ID = 0)
          0x8805:0:0 (Remote Prot = 0, Remote Metric = 0)

  VRF advertise information:
  Path-id 1 not advertised to any peer

  VPN AF advertise information:
  Path-id 1 advertised to peers:
    10.0.152.65        10.0.152.66

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
1.0	01-Jul-2024	Erstveröffentlichung

Beiträge von Cisco Ingenieuren

Shekhar Nehete
TAC

Fehlerbehebung, warum externe EIGRP-Route gegenüber BGP bevorzugt wird

Download-Optionen

Inklusive Sprache

Informationen zu dieser Übersetzung

Inhalt

Einleitung

Voraussetzungen

Einrichtung und Topologie

Problemaussage

Problemübersicht

Fehlerbehebung und Verifizierung

Warum wird die EIGRP-Route der eBGP-Route vorgezogen?

Lösung

Revisionsverlauf

Beiträge von Cisco Ingenieuren

War dieses Dokument hilfreich?

Cisco kontaktieren

Dieses Dokument gilt für folgende Produkte.