In diesem Dokument wird beschrieben, wie das Internal Border Gateway Protocol (iBGP) zwischen Provider Edge (PE) und Customer Edge (CE) in Cisco IOS® implementiert wird.
Bis zur neuen iBGP-PE-CE-Funktion wurde iBGP zwischen PE und CE (also auf einer VRF-Schnittstelle (Virtual Routing and Forwarding) am PE-Router) nicht offiziell unterstützt. Eine Ausnahme bildet iBGP auf VRF-Schnittstellen in einer Multi-VRF-CE-Konfiguration (VRF-Lite). Die Motivation für die Bereitstellung dieser Funktion ist:
Mit dieser Funktion können die Standorte der VRF-Instanz dasselbe ASN wie der SP-Core aufweisen. Wenn sich das ASN der VRF-Standorte jedoch von dem ASN des SP-Core unterscheidet, kann es mit der Funktion Local-Autonomous System (AS) identisch dargestellt werden.
Im Folgenden werden die beiden Hauptaspekte beschrieben, damit diese Funktion funktioniert:
Das neue ATTR_SET-Attribut ermöglicht es dem SP, alle BGP-Attribute des Kunden transparent zu übertragen und stört nicht die SP-Attribute und BGP-Richtlinien. Solche Attribute sind die Cluster-Liste, lokale Präferenzen, Communitys usw.
ATTR_SET ist das neue BGP-Attribut, mit dem die VPN-BGP-Attribute des SP-Kunden übertragen werden. Es ist ein optionales transitives Attribut. In diesem Attribut können alle BGP-Attribute des Kunden aus der BGP Update-Nachricht mit Ausnahme der Attribute MP_REACH und MP_UNREACH übertragen werden.
Das ATTR_SET-Attribut hat folgendes Format:
+------------------------------+
| Attr Flags (O|T) Code = 128 |
+------------------------------+
| Attr. Length (1 or 2 octets) |
+------------------------------+
| Origin AS (4 octets) |
+------------------------------+
| Path Attributes (variable) |
+------------------------------+
Die Attributflags sind die regulären BGP-Attributflags (siehe RFC 4271). Die Attributlänge gibt an, ob die Attributlänge ein oder zwei Oktette ist. Der Zweck des Origin AS-Felds besteht darin, das Leck einer Route, die von einem AS ausgeht, an ein anderes AS zu übertragen, ohne dass die AS_PATH ordnungsgemäß geändert wird. Das Feld Path Attributes variabler Länge enthält die VPN-BGP-Attribute, die über den SP-Core übertragen werden müssen.
Auf dem Egress-PE-Router werden die VPN-BGP-Attribute in dieses Attribut übertragen. Auf dem Eingangs-PE-Router werden diese Attribute aus dem Attribut entfernt, bevor das BGP-Präfix an den CE-Router gesendet wird. Dieses Attribut ermöglicht die Isolierung von BGP-Attributen zwischen dem SP-Netzwerk und dem Kunden-VPN und umgekehrt. Beispielsweise wird das Cluster-Listenattribut für die SP-Route-Reflektion nicht im VPN-Netzwerk angezeigt und berücksichtigt. Das Attribut der VPN-Route-Reflection-Cluster-Liste wird jedoch nicht im SP-Netzwerk angezeigt und berücksichtigt.
In Abbildung 1 sehen Sie die Verbreitung eines Kunden-BGP-Präfixes im SP-Netzwerk.
Abbildung 1
CE1 und CE2 sind mit dem SP-Netzwerk identisch: 65000 Für PE1 wurde iBGP für CE1 konfiguriert. PE1 gibt den Pfad für das Präfix 10.100.1.1/32 zum RR im SP-Netzwerk an. Der RR gibt wie gewohnt den iBGP-Pfad zu den PE-Routern wieder. PE2 spiegelt den Pfad zu CE2 wider.
Damit dies ordnungsgemäß funktioniert, müssen Sie:
Siehe Abbildung 1.
Die erforderliche Konfiguration für PE1 und PE2 ist wie folgt:
PE1
vrf definition customer1
rd 65000:1
route-target export 1:1
route-target import 1:1
!
address-family ipv4
exit-address-family
router bgp 65000
bgp log-neighbor-changes
neighbor 192.168.100.3 remote-as 65000
neighbor 192.168.100.3 update-source Loopback0
!
address-family vpnv4
neighbor 192.168.100.3 activate
neighbor 192.168.100.3 send-community extended
exit-address-family
!
address-family ipv4 vrf customer1
neighbor 10.1.1.4 remote-as 65000
neighbor 10.1.1.4 activate
neighbor 10.1.1.4 internal-vpn-client
neighbor 10.1.1.4 route-reflector-client
neighbor 10.1.1.4 next-hop-self
exit-address-family
PE2
vrf definition customer1
rd 65000:2
route-target export 1:1
route-target import 1:1
!
address-family ipv4
exit-address-family
router bgp 65000
bgp log-neighbor-changes
neighbor 192.168.100.3 remote-as 65000
neighbor 192.168.100.3 update-source Loopback0
!
address-family vpnv4
neighbor 192.168.100.3 activate
neighbor 192.168.100.3 send-community extended
exit-address-family
!
address-family ipv4 vrf customer1
neighbor 10.1.2.5 remote-as 65000
neighbor 10.1.2.5 activate
neighbor 10.1.2.5 internal-vpn-client
neighbor 10.1.2.5 route-reflector-client
neighbor 10.1.2.5 next-hop-self
exit-address-family
Der neue Befehl neighbor <internal-CE> internal-vpn-client soll diese Funktion ermöglichen. Sie muss auf dem PE-Router nur für die iBGP-Sitzung mit den CE-Routern konfiguriert werden.
Siehe Abbildung 1.
Dies ist das von CE1 angegebene Präfix:
CE1#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
4
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (10.100.1.1)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
rx pathid: 0, tx pathid: 0x0
Wenn PE1 das BGP-Präfix 10.100.1.1/32 von CE1 empfängt, wird es zweimal gespeichert:
PE1#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 21
Paths: (2 available, best #1, table customer1)
Advertised to update-groups:
5
Refresh Epoch 1
Local, (Received from ibgp-pece RR-client)
10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
Origin IGP, metric 0, localpref 200, valid, internal, best
mpls labels in/out 18/nolabel
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
Local, (Received from ibgp-pece RR-client), (ibgp sourced)
10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
Origin IGP, localpref 100, valid, internal
Extended Community: RT:1:1
mpls labels in/out 18/nolabel
rx pathid: 0, tx pathid: 0
Der erste Pfad ist der tatsächliche Pfad auf PE1, da er von CE1 empfangen wird.
Der zweite Pfad ist der Pfad, der den RRs/PE-Routern angekündigt wird. Er ist mit ibgp-sourcing markiert. Sie enthält das ATTR_SET-Attribut. Beachten Sie, dass diesem Pfad mindestens ein Route Targets (RTs) zugeordnet ist.
PE1 gibt das Präfix wie folgt an:
PE1#show bgp vpnv4 unicast all neighbors 192.168.100.3 advertised-routes
BGP table version is 7, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65000:1 (default for vrf customer1)
*>i 10.100.1.1/32 10.1.1.4 0 200 0 i
Total number of prefixes 1
So sieht der RR den Pfad:
RR#show bgp vpnv4 un all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 10
Paths: (1 available, best #1, no table)
Advertised to update-groups:
3
Refresh Epoch 1
Local, (Received from a RR-client)
192.168.100.1 (metric 11) (via default) from 192.168.100.1 (192.168.100.1)
Origin IGP, localpref 100, valid, internal, best
Extended Community: RT:1:1
Originator: 10.100.1.1, Cluster list: 192.168.100.1
ATTR_SET Attribute:
Originator AS 65000
Origin IGP
Aspath
Med 0
LocalPref 200
Cluster list
192.168.100.1,
Originator 10.100.1.1
mpls labels in/out nolabel/18
rx pathid: 0, tx pathid: 0x0
Beachten Sie, dass die lokale Präferenz dieses VPNv4-Unicast-Präfix im Core 100 beträgt. Im ATTR_SET wird die ursprüngliche lokale Voreinstellung von 200 gespeichert. Dies ist jedoch für den RR im SP-Core transparent.
Auf PE2 wird das Präfix wie folgt angezeigt:
PE2#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 5
Paths: (1 available, best #1, no table)
Not advertised to any peer
Refresh Epoch 2
Local
192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
Origin IGP, localpref 100, valid, internal, best
Extended Community: RT:1:1
Originator: 10.100.1.1, Cluster list: 192.168.100.3, 192.168.100.1
ATTR_SET Attribute:
Originator AS 65000
Origin IGP
Aspath
Med 0
LocalPref 200
Cluster list
192.168.100.1,
Originator 10.100.1.1
mpls labels in/out nolabel/18
rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 65000:2:10.100.1.1/32, version 6
Paths: (1 available, best #1, table customer1)
Advertised to update-groups:
1
Refresh Epoch 2
Local, imported path from 65000:1:10.100.1.1/32 (global)
192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
Origin IGP, metric 0, localpref 200, valid, internal, best
Originator AS(ibgp-pece): 65000
Originator: 10.100.1.1, Cluster list: 192.168.100.1
mpls labels in/out nolabel/18
rx pathid:0, tx pathid: 0x0
Der erste Pfad ist der, der vom RR mit ATTR_SET empfangen wurde. Beachten Sie, dass der RD 65000:1, der Ursprungs-RD, ist. Der zweite Pfad ist der importierte Pfad aus der VRF-Tabelle mit RD 65000:1. ATTR_SET wurde entfernt.
Dies ist der Pfad, der auf CE2 angezeigt wird:
CE2#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32, version 10
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
Local
10.1.2.2 from 10.1.2.2 (192.168.100.2)
Origin IGP, metric 0, localpref 200, valid, internal, best
Originator: 10.100.1.1, Cluster list: 192.168.100.2, 192.168.100.1
rx pathid: 0, tx pathid: 0x0
Beachten Sie, dass der Next-Hop 10.1.2.2 ist, d. h. PE2. Die Cluster-Liste enthält Router PE1 und PE2. Dies sind die RRs, die innerhalb des VPNs wichtig sind. Der SP-RR (10.100.1.3) ist nicht in der Cluster-Liste enthalten.
Die lokale Präferenz von 200 wurde innerhalb des VPN im gesamten SP-Netzwerk beibehalten.
Der Befehl debug bgp vpnv4 unicast updates zeigt die im SP-Netzwerk weitergeleitete Aktualisierung an:
PE1#
BGP(4): Revise route installing 1 of 1 routes for 10.100.1.1/32 -> 10.1.1.4
(customer1) to customer1 IP table
BGP(4): 192.168.100.3 NEXT_HOP changed SELF for ibgp rr-client pe-ce net
65000:1:10.100.1.1/32,
BGP(4): 192.168.100.3 Net 65000:1:10.100.1.1/32 from ibgp-pece 10.1.1.4 format
ATTR_SET
BGP(4): (base) 192.168.100.3 send UPDATE (format) 65000:1:10.100.1.1/32, next
192.168.100.1, label 16, metric 0, path Local, extended community RT:1:1
BGP: 192.168.100.3 Next hop is our own address 192.168.100.1
BGP: 192.168.100.3 Route Reflector cluster loop; Received cluster-id 192.168.100.1
BGP: 192.168.100.3 RR in same cluster. Reflected update dropped
RR#
BGP(4): 192.168.100.1 rcvd UPDATE w/ attr: nexthop 192.168.100.1, origin i, localpref
100, originator 10.100.1.1, clusterlist 192.168.100.1, extended community RT:1:1,
[ATTR_SET attribute: originator AS 65000, origin IGP, aspath , med 0, localpref 200,
cluster list 192.168.100.1 , originator 10.100.1.1]
BGP(4): 192.168.100.1 rcvd 65000:1:10.100.1.1/32, label 16
RT address family is not configured. Can't create RTC route
BGP(4): (base) 192.168.100.1 send UPDATE (format) 65000:1:10.100.1.1/32, next
192.168.100.1, label 16, metric 0, path Local, extended community RT:1:1
PE2#
BGP(4): 192.168.100.3 rcvd UPDATE w/ attr: nexthop 192.168.100.1, origin i, localpref
100, originator 10.100.1.1, clusterlist 192.168.100.3 192.168.100.1, extended community
RT:1:1, [ATTR_SET attribute: originator AS 65000, origin IGP, aspath , med 0, localpref
200, cluster list 192.168.100.1 , originator 10.100.1.1]
BGP(4): 192.168.100.3 rcvd 65000:1:10.100.1.1/32, label 16
RT address family is not configured. Can't create RTC route
BGP(4): Revise route installing 1 of 1 routes for 10.100.1.1/32 -> 192.168.100.1
(customer1) to customer1 IP table
BGP(4): 10.1.2.5 NEXT_HOP is set to self for net 65000:2:10.100.1.1/32,
PE2# debug bgp vpnv4 unicast updates detail
BGP updates debugging is on with detail for address family: VPNv4 Unicast
PE2#
BGP(4): 192.168.100.3 rcvd UPDATE w/ attr: nexthop 192.168.100.1, origin i,
localpref 100, originator 10.100.1.1, clusterlist 192.168.100.3 192.168.100.1,
extended community RT:1:1, [ATTR_SET attribute: originator AS 65000, origin IGP,
aspath , med 0, localpref 200, cluster list 192.168.100.1 , originator 10.100.1.1]
BGP(4): 192.168.100.3 rcvd 65000:1:10.100.1.1/32, label 17
RT address family is not configured. Can't create RTC route
BGP: 192.168.100.3 rcv update length 125
BGP: 192.168.100.3 rcv update dump: FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
0090 0200 00
PE2#00 7980 0E21 0001 800C 0000 0000 0000 0000 C0A8 6401 0078 0001 1100 00FD E800
0000 010A 6401 0140 0101 0040 0200 4005 0400 0000 64C0 1008 0002 0001 0000 0001 800A
08C0 A864 03C0 A864 0180 0904 0A64 0101 C080 2700 00FD E840 0101 0040 0200 8004 0400
0000 0040 0504 0000 00C8 800A 04C0 A864 0180 0904 0A64 0101
BGP(4): Revise route installing 1 of 1 routes for 10.100.1.1/32 -> 192.168.100.1
(customer1) to customer1 IP table
BGP(4): 10.1.2.5 NEXT_HOP is set to self for net 65000:2:10.100.1.1/32,
Für diese Funktion muss Next-Hop-Self auf den PE-Routern konfiguriert werden. Der Grund dafür ist, dass der Next-Hop normalerweise unverändert mit iBGP transportiert wird. Es gibt jedoch zwei separate Netzwerke: VPN-Netzwerk und SP-Netzwerk, die separate Interior Gateway Protocols (IGPs) ausführen. Daher kann die IGP-Metrik nicht einfach verglichen und für die Berechnung des besten Pfads zwischen den beiden Netzwerken verwendet werden. Der RFC 6368 hat sich für eine Next-Hop-Selbstverpflichtung für die iBGP-Sitzung zum CE entschieden, wodurch das zuvor beschriebene Problem zusammen vermieden wird. Ein Vorteil ist, dass an den VRF-Standorten verschiedene IGPs mit diesem Ansatz ausgeführt werden können.
Laut RFC 6368 sollten verschiedene VRF-Standorte desselben VPN unterschiedliche (eindeutige) RDs verwenden. In Cisco IOS ist dies für diese Funktion obligatorisch.
Siehe Abbildung 2. Der VPN-Kunde1 hat ASN 65001.
Abbildung 2
CE1 ist in AS 65001. Um dieses interne BGP vom Standpunkt von PE1 aus zu erstellen, ist die lokale iBGP-Funktion erforderlich.
CE1
router bgp 65001
bgp log-neighbor-changes
network 10.100.1.1 mask 255.255.255.255
neighbor 10.1.1.1 remote-as 65001
PE1
router bgp 65000
bgp log-neighbor-changes
neighbor 192.168.100.3 remote-as 65000
neighbor 192.168.100.3 update-source Loopback0
!
address-family vpnv4
neighbor 192.168.100.3 activate
neighbor 192.168.100.3 send-community extended
exit-address-family
!
address-family ipv4 vrf customer1
neighbor 10.1.1.4 remote-as 65001
neighbor 10.1.1.4 local-as 65001
neighbor 10.1.1.4 activate
neighbor 10.1.1.4 internal-vpn-client
neighbor 10.1.1.4 route-reflector-client
neighbor 10.1.1.4 next-hop-self
exit-address-family
PE2 und CE2 werden ähnlich konfiguriert.
PE1 sieht das BGP-Präfix wie folgt:
PE1#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 41
Paths: (2 available, best #1, table customer1)
Advertised to update-groups:
5
Refresh Epoch 1
Local, (Received from ibgp-pece RR-client)
10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
Origin IGP, metric 0, localpref 200, valid, internal, best
mpls labels in/out 18/nolabel
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
Local, (Received from ibgp-pece RR-client), (ibgp sourced)
10.1.1.4 (via vrf customer1) from 10.1.1.4 (10.100.1.1)
Origin IGP, localpref 100, valid, internal
Extended Community: RT:1:1
mpls labels in/out 18/nolabel
rx pathid: 0, tx pathid: 0
Das Präfix ist ein internes BGP.
PE2 sieht Folgendes:
PE2#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 33
Paths: (1 available, best #1, no table)
Not advertised to any peer
Refresh Epoch 5
Local
192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
Origin IGP, localpref 100, valid, internal, best
Extended Community: RT:1:1
Originator: 10.100.1.1, Cluster list: 192.168.100.3, 192.168.100.1
ATTR_SET Attribute:
Originator AS 65001
Origin IGP
Aspath
Med 0
LocalPref 200
Cluster list
192.168.100.1,
Originator 10.100.1.1
mpls labels in/out nolabel/18
rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 65000:2:10.100.1.1/32, version 34
Paths: (1 available, best #1, table customer1)
Advertised to update-groups:
5
Refresh Epoch 2
Local, imported path from 65000:1:10.100.1.1/32 (global)
192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
Origin IGP, metric 0, localpref 200, valid, internal, best
Originator AS(ibgp-pece): 65001
Originator: 10.100.1.1, Cluster list: 192.168.100.1
mpls labels in/out nolabel/18
rx pathid: 0, tx pathid: 0x0
Der Originator AS ist 65001. Dies ist das AS, das beim Versenden des Präfixes vom PE2 an CE2 verwendet wird. Das AS wird also beibehalten, und die lokale Präferenz in diesem Beispiel.
CE2#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32, version 3
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
Local
10.1.2.2 from 10.1.2.2 (192.168.100.2)
Origin IGP, metric 0, localpref 200, valid, internal, best
Originator: 10.100.1.1, Cluster list: 192.168.100.2, 192.168.100.1
rx pathid: 0, tx pathid: 0x0
Sie sehen Lokal anstelle eines AS-Pfads. Dies bedeutet, dass es sich um eine interne BGP-Route handelt, die vom AS 65001 ausgeht und ebenfalls das konfigurierte ASN des Router-CE2 ist. Alle BGP-Attribute wurden aus dem ATTR_SET-Attribut übernommen. Dies entspricht den Regeln für Fall 1 im nächsten Abschnitt.
Der ATTR_SET enthält das Originator-AS der ursprünglichen VRF-Instanz. Dieses Ursprungs-AS wird vom Remote-PE überprüft, wenn es den ATTR_SET entfernt, bevor es das Präfix an den CE-Router sendet.
Fall 1: Wenn das ursprüngliche AS mit dem für den CE-Router konfigurierten AS übereinstimmt, werden die BGP-Attribute aus dem ATTR_SET-Attribut übernommen, wenn der PE den Pfad in die Ziel-VRF importiert.
Fall 2: Wenn das ursprüngliche AS nicht mit dem für den CE-Router konfigurierten AS übereinstimmt, werden die Attribute für den konstruierten Pfad wie folgt verwendet:
PE2 sieht die Route wie folgt:
PE2#show bgp vpnv4 unicast all 10.100.1.1/32
BGP routing table entry for 65000:1:10.100.1.1/32, version 43
Paths: (1 available, best #1, no table)
Not advertised to any peer
Refresh Epoch 6
Local
192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
Origin IGP, localpref 100, valid, internal, best
Extended Community: RT:1:1
Originator: 10.100.1.1, Cluster list: 192.168.100.3, 192.168.100.1
ATTR_SET Attribute:
Originator AS 65000
Origin IGP
Aspath
Med 0
LocalPref 200
Cluster list
192.168.100.1,
Originator 10.100.1.1
mpls labels in/out nolabel/17
rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 65000:2:10.100.1.1/32, version 44
Paths: (1 available, best #1, table customer1)
Advertised to update-groups:
6
Refresh Epoch 6
Local, imported path from 65000:1:10.100.1.1/32 (global)
192.168.100.1 (metric 21) (via default) from 192.168.100.3 (192.168.100.3)
Origin IGP, metric 0, localpref 200, valid, internal, best
Originator AS(ibgp-pece): 65000
Originator: 10.100.1.1, Cluster list: 192.168.100.1
mpls labels in/out nolabel/17
rx pathid: 0, tx pathid: 0x0
Dies ist das Präfix, das auf CE2 angezeigt wird:
CE2#show bgp ipv4 unicast 10.100.1.1/32
BGP routing table entry for 10.100.1.1/32, version 5
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65000
10.1.2.2 from 10.1.2.2 (192.168.100.2)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Dies ist Fall 2. Die im ATTR_SET-Attribut enthaltene Origin AS-Nummer wird dem AS_PATH von PE2 vorangestellt und befolgt die Regeln, die für ein eBGP-Peering zwischen dem Quell- und dem Ziel-AS gelten. Die iBGP-spezifischen Attribute werden von PE2 ignoriert, wenn die Route erstellt wird, die CE2 mitgeteilt werden soll. Die lokale Voreinstellung ist also 100 und nicht 200 (wie im ATTR_SET-Attribut dargestellt).
Siehe Abbildung 4.
Abbildung 4
Abbildung 4 zeigt einen zusätzlichen CE-Router, CE3, der mit PE1 verbunden ist. CE1 und CE3 sind beide mit PE1 auf derselben VRF-Instanz verbunden: Kunde1. Dies bedeutet, dass CE1 und CE3 Multi-VRF-CE-Router (auch bekannt als VRF-Lite) von PE1 sind. PE1 stellt sich selbst als Next-Hop dar, wenn es Präfixe von CE1 an CE3 meldet. Falls dieses Verhalten nicht erwünscht ist, können Sie Next-Hop-unveränderten Nachbar 10.1.3.6 auf PE1 konfigurieren. Um dies zu konfigurieren, müssen Sie Next-Hop-Self (Next-Hop-Self) aus dem Nachbarn 10.1.3.6 auf PE1 entfernen. Anschließend wird von CE3 erkannt, dass die Routen von CE1 mit CE1 der nächste Hop für diese BGP-Präfixe sind. Damit dies funktioniert, müssen die Routen für diese BGP Next-Hops in der Routing-Tabelle von CE3 angegeben werden. Sie benötigen ein dynamisches Routing-Protokoll (IGP) oder statische Routen auf CE1, PE1 und CE3, um sicherzustellen, dass die Router über eine Route für die anderen Next-Hop-IP-Adressen verfügen. Es besteht jedoch ein Problem mit dieser Konfiguration.
Konfiguration für PE1:
router bgp 65000
!
address-family ipv4 vrf customer1
neighbor 10.1.1.4 remote-as 65000
neighbor 10.1.1.4 activate
neighbor 10.1.1.4 internal-vpn-client
neighbor 10.1.1.4 route-reflector-client
neighbor 10.1.1.4 next-hop-self
neighbor 10.1.3.6 remote-as 65000
neighbor 10.1.3.6 activate
neighbor 10.1.3.6 internal-vpn-client
neighbor 10.1.3.6 route-reflector-client
neighbor 10.1.3.6 next-hop-unchanged
exit-address-family
Das Präfix von CE1 wird auf CE3 einwandfrei angezeigt:
CE3#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 9
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
Local
10.1.1.4 from 10.1.3.1 (192.168.100.1)
Origin IGP, metric 0, localpref 200, valid, internal, best
Originator: 10.100.1.1, Cluster list: 192.168.100.1
rx pathid: 0, tx pathid: 0x0
Das Präfix von CE2 wird jedoch auf CE3 angezeigt, wie hier gezeigt:
CE3#show bgp ipv4 unicast 10.100.1.2
BGP routing table entry for 10.100.1.2/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
Local
192.168.100.2 (inaccessible) from 10.1.3.1 (192.168.100.1)
Origin IGP, metric 0, localpref 100, valid, internal
Originator: 10.100.1.2, Cluster list: 192.168.100.1, 192.168.100.2
rx pathid: 0, tx pathid: 0
Der BGP Next-Hop ist 192.168.100.2, die Loopback-IP-Adresse von PE2. PE1 hat den BGP Next-Hop nicht selbst umgeschrieben, als es CE3 das Präfix 10.100.1.2/32 bekannt gab. Dadurch ist dieses Präfix auf CE3 unbrauchbar.
Bei einer Kombination der iBGP-PE-CE-Funktion mit MPLS-VPN und iBGP-VRF-Lite müssen Sie also sicherstellen, dass die PE-Router stets über Next-Hop-Self verfügen.
Der Next-Hop kann nicht beibehalten werden, wenn es sich bei einem PE-Router um einen RR handelt, der iBGP-Routen von einem CE zu einem anderen CE über lokale VRF-Schnittstellen auf dem PE widerspiegelt. Wenn Sie iBGP PE-CE in einem MPLS-VPN-Netzwerk ausführen, müssen Sie den internen VPN-Client für die iBGP-Sitzungen zu den CE-Routern verwenden. Wenn sich in einem VRF auf einem PE-Router mehr als ein lokaler CE befindet, müssen Sie Next-Hop-Self für diese BGP-Peers beibehalten.
Sie können Routing-Maps anzeigen, um den Next-Hop für Präfixe festzulegen, die von anderen PE-Routern empfangen wurden, jedoch nicht für reflektierte Präfixe anderer lokal verbundener CE-Router. Es wird jedoch derzeit nicht unterstützt, den Next-Hop in einer ausgehenden route-map auf sich selbst festzulegen. Diese Konfiguration wird hier angezeigt:
router bgp 65000
address-family ipv4 vrf customer1
neighbor 10.1.1.4 remote-as 65000
neighbor 10.1.1.4 activate
neighbor 10.1.1.4 internal-vpn-client
neighbor 10.1.1.4 route-reflector-client
neighbor 10.1.1.4 next-hop-self
neighbor 10.1.3.6 remote-as 65000
neighbor 10.1.3.6 activate
neighbor 10.1.3.6 internal-vpn-client
neighbor 10.1.3.6 route-reflector-client
neighbor 10.1.3.6 route-map NH-setting out
exit-address-family
ip prefix-list PE-loopbacks seq 10 permit 192.168.100.0/24 ge 32
!
route-map NH-setting permit 10
description set next-hop to self for prefixes from other PE routers
match ip route-source prefix-list PE-loopbacks
set ip next-hop self
!
route-map NH-setting permit 20
description advertise prefixes with next-hop other than the prefix-list in
route-map entry 10 above
!
Dies wird jedoch nicht unterstützt:
PE1(config)#route-map NH-setting permit 10
PE1(config-route-map)# set ip next-hop self
% "NH-setting" used as BGP outbound route-map, set use own IP/IPv6 address for the nexthop not supported
Wenn PE1 ältere Cisco IOS-Software ausführt, die nicht über die Funktion iBGP PE-CE verfügt, legt sich PE1 nie als Next-Hop für die reflektierten iBGP-Präfixe fest. Das bedeutet, dass das reflektierte BGP-Präfix (10.100.1.1/32) von CE1 (10.100.1.1) zu CE2 (über PE1) CE1 (10.1.1.4) als Next-Hop fungieren würde.
CE3#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 32
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
Local
10.1.1.4 from 10.1.3.1 (192.168.100.1)
Origin IGP, metric 0, localpref 200, valid, internal, best
Originator: 10.100.1.1, Cluster list: 192.168.100.1
rx pathid: 0, tx pathid: 0x0
Das Präfix von CE2 (10.100.1.2/32) wird mit PE2 als Next-Hop betrachtet, da PE1 für dieses Präfix auch kein Next-Hop-Self ausführt:
CE3#show bgp ipv4 unicast 10.100.1.2
BGP routing table entry for 10.100.1.2/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
Local
192.168.100.2 (inaccessible) from 10.1.3.1 (192.168.100.1)
Origin IGP, localpref 100, valid, internal
Originator: 10.100.1.2, Cluster list: 192.168.100.1, 192.168.100.3, 192.168.100.2
ATTR_SET Attribute:
Originator AS 65000
Origin IGP
Aspath
Med 0
LocalPref 100
Cluster list
192.168.100.2,
Originator 10.100.1.2
rx pathid: 0, tx pathid: 0
Damit die iBGP-PE-CE-Funktion ordnungsgemäß funktioniert, müssen bei allen PE-Routern für das VPN, für das die Funktion aktiviert ist, der Code zur Unterstützung der Funktion vorhanden sein und die Funktion aktiviert sein.
Siehe Abbildung 5.
Abbildung 5
Abbildung 5 zeigt eine VRF-Lite-Konfiguration. Die Sitzung von PE1 zu CE4 ist eBGP. Die Sitzung von PE1 zu CE3 ist immer noch iBGP.
Für eBGP-Präfixe wird der Next-Hop immer auf sich selbst festgelegt, wenn er die Präfixe einem iBGP-Nachbarn auf VRF meldet. Dies gilt unabhängig davon, ob die Sitzung zum iBGP-Nachbarn über VRF den Next-Hop-Self-Set aufweist oder nicht.
In Abbildung 5 sieht CE3 die Präfixe von CE4 mit PE1 als Next-Hop.
CE3#show bgp ipv4 unicast 10.100.1.4
BGP routing table entry for 10.100.1.4/32, version 103
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65004
10.1.3.1 from 10.1.3.1 (192.168.100.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Dies geschieht bei Next-Hop-Self auf PE1 zu CE3 oder ohne.
Wenn sich die Schnittstellen auf PE1 zu CE3 und CE4 nicht in einer VRF-Instanz befinden, aber im globalen Kontext, macht das Next-Hop-Self-To-CE3 einen Unterschied.
Ohne Next-Hop-Self auf PE1 zu CE3 sehen Sie:
PE1#show bgp vrf customer1 vpnv4 unicast neighbors 10.1.3.6
BGP neighbor is 10.1.3.6, vrf customer1, remote AS 65000, internal link
...
For address family: VPNv4 Unicast
Translates address family IPv4 Unicast for VRF customer1
Session: 10.1.3.6
BGP table version 1, neighbor version 1/0
Output queue size : 0
Index 12, Advertise bit 0
Route-Reflector Client
12 update-group member
Slow-peer detection is disabled
Slow-peer split-update-group dynamic is disabled
Interface associated: (none)
Obwohl Next-Hop-Self implizit aktiviert ist, gibt die Ausgabe dies nicht an.
Bei Next-Hop-Self auf PE1 zu CE3 sehen Sie:
PE1#show bgp vrf customer1 vpnv4 unicast neighbors 10.1.3.6
BGP neighbor is 10.1.3.6, vrf customer1, remote AS 65000, internal link
..
For address family: VPNv4 Unicast
...
NEXT_HOP is always this router for eBGP paths
Wenn sich die Schnittstellen zu CE3 und CE4 in einem globalen Kontext befinden, ist der nächste Hop für Präfixe von CE4 selbst CE4, wenn Next-Hop-Self nicht konfiguriert ist:
CE3#show bgp ipv4 unicast 10.100.1.4
BGP routing table entry for 10.100.1.4/32, version 124
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65004
10.1.4.7 from 10.1.3.1 (192.168.100.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Für Next-Hop-Self auf PE1 zu CE3:
CE3#show bgp ipv4 unicast 10.100.1.4
BGP routing table entry for 10.100.1.4/32, version 125
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65004
10.1.3.1 from 10.1.3.1 (192.168.100.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Dies wurde auf Basis von RFC 4364 durchgeführt.
Wenn Sie das Next-Hop-Self für eBGP-Präfixe für eine iBGP-Sitzung über eine VRF-Schnittstelle nicht festlegen möchten, müssen Sie Next-Hop-unveränderlich konfigurieren. Die Unterstützung dafür fand nur mit der Cisco Bug-ID CSCuj11720 statt.
router bgp 65000
...
address-family ipv4 vrf customer1
neighbor 10.1.1.4 remote-as 65000
neighbor 10.1.1.4 activate
neighbor 10.1.1.4 route-reflector-client
neighbor 10.1.3.6 remote-as 65000
neighbor 10.1.3.6 activate
neighbor 10.1.3.6 route-reflector-client
neighbor 10.1.3.6 next-hop-unchanged
neighbor 10.1.4.7 remote-as 65004
neighbor 10.1.4.7 activate
exit-address-family
Nun sieht CE3 CE4 als Next-Hop für die von CE4 angekündigten Präfixe:
CE3#show bgp ipv4 unicast 10.100.1.4
BGP routing table entry for 10.100.1.4/32, version 130
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 3
65004
10.1.4.7 from 10.1.3.1 (192.168.100.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Wenn Sie versuchen, das Next-Hop-unveränderte Schlüsselwort für die iBGP-Sitzung zu CE3 im Cisco IOS-Code vor der Cisco Bug-ID CSCuj11720 zu konfigurieren, wird folgender Fehler angezeigt:
PE1(config-router-af)# neighbor 10.1.3.6 next-hop-unchanged
%BGP: Can propagate the nexthop only to multi-hop EBGP neighbor
Nach der Cisco Bug-ID CSCuj11720 ist das Next-Hop-unveränderte Schlüsselwort für Multi-Hop eBGP-Nachbarn und iBGP VRF-Lite-Nachbarn gültig.