IOS-implementatie van de iBGP PE-CE functie

Downloadopties

  • PDF     (409.8 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (177.4 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (178.0 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:4 april 2014
Document-id:117567

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inleiding

Dit document beschrijft hoe het Interne Border Gateway Protocol (iBGP) tussen Provider Edge (PE) en Customer Edge (CE) optie in Cisco IOS® wordt geïmplementeerd.

Achtergrondinformatie

Tot de nieuwe iBGP PE-CE optie werd iBGP tussen PE en CE (dus op een Virtual Routing and Forwarding (VRF) interface op de PE-router) niet officieel ondersteund. Eén uitzondering is iBGP op VRF-interfaces in een multi-VRF CE (VRF-Lite) instelling. De motivatie om deze functie in te zetten is:

  • De klant wil één enkel Autonoom Systeem Nummer (ASN) hebben op de meerdere plaatsen van VRF, zonder de plaatsing van het Protocol van de Externe Grensgateway (eBGP) met als-Override.

  • De klant wil interne routereflectie naar de CE routers verstrekken, handelend alsof de kern van de serviceproviders (SP) één transparante routereflector (RR) is.

Met deze optie kunnen de sites van VRF dezelfde ASN hebben als de SP-kern. Indien de ASN van de VRF-locaties echter anders is dan de ASN van de SP-kern, kan deze echter hetzelfde worden weergegeven met het gebruik van de functie local-Autonomous System (AS).

iBGP PE-CE implementeren

Dit zijn de twee belangrijkste onderdelen om deze functie te laten werken:

  • Een nieuwe eigenschap ATTR_SET werd aan het BGP-protocol toegevoegd om de VPN BGP-eigenschappen op een transparante manier over de SP-kern te dragen.
  • Maak de PE router een RR voor de iBGP sessies naar de CE routers in VRF en als RR naar de VPNv4 buren (andere PE routers of RRs).


De nieuwe eigenschap ATTR_SET stelt de SP in staat alle BGP-eigenschappen van de klant op een transparante manier te dragen en beïnvloedt niet de SP-eigenschappen en het BGP-beleid. Zulke eigenschappen zijn de clusterlijst, lokale voorkeur, gemeenschappen, etc.

BGP-routekenmerk

ATTR_SET is de nieuwe BGP eigenschap die wordt gebruikt om de VPN BGP eigenschappen van de SP klant over te dragen. Het is een optionele transitieve eigenschap. In deze eigenschap kunnen alle Customer BGP eigenschappen van het BGP Update bericht, behalve de MP_REACH en de MP_UNREACH eigenschappen, worden meegevoerd.

De eigenschap ATTR_SET heeft dit formaat:

 
                      +------------------------------+
                      | Attr Flags (O|T) Code = 128  |
                      +------------------------------+
                      | Attr. Length (1 or 2 octets) |
                      +------------------------------+
                      | Origin AS (4 octets)         |
                      +------------------------------+
                      | Path Attributes (variable)   |
                      +------------------------------+

De kenmerkende vlaggen zijn de gewone vlaggen van de BGP-eigenschap (zie RFC 4271). De eigenschap lengte geeft aan of de eigenschap lengte één of twee octetten is. Het veld Afkomst AS heeft tot doel te voorkomen dat het lekken van een route afkomstig van een AS naar een andere AS wordt gelekt zonder de juiste manipulatie van de AS_PATH. Het veld Eigenschappen van de variabele lengte pad heeft de VPN BGP-eigenschappen die over de SP-kern moeten worden meegesleept.

Op de GRE-router worden de VPN-BGP-eigenschappen naar deze eigenschap geduwd. Op de INGress PE-router worden deze eigenschappen van het kenmerk overgenomen voordat het BGP-prefix naar de CE-router wordt verzonden. Deze eigenschap verschaft de isolatie van BGP eigenschappen tussen het SP netwerk en de klant VPN en vice versa. Bijvoorbeeld, de eigenschap van de SP route reflectiescluster niet wordt gezien en overwogen binnen het VPN netwerk. Maar ook, de eigenschap van de de de groepering van de VPN route reflectie wordt niet gezien en overwogen binnen het SP netwerk.

Kijk naar afbeelding 1 om de doorgifte van een Customer BGP prefix over het SP netwerk te zien.

                                                                                                            Figuur 1

CE1 en CE2 bevinden zich in hetzelfde AS als het SP-netwerk: 65000. PE1 heeft iBGP ingesteld op CE1. PE1 weerspiegelt het pad voor het voorvoegsel 10.100.1.1/32 naar het RR in het SP-netwerk. RR weerspiegelt het iBGP-pad naar de PE-routers zoals gewoonlijk. PE2 weerspiegelt de weg naar CE2.

Om dit goed te laten werken, moet u:

  • Zorg voor code op PE1 en PE2 met iBGP PE-CE functieondersteuning

  • Configureer PE1 en PE2 zodat routereflectie op hun BGP-sessie naar hun respectievelijke CE routers wordt uitgevoerd

  • Heb next-hop-zelfover-de PE routers voor de BGP-sessie naar hun CE routers

  • Zorg ervoor dat elke VPN-site verschillende routeswitches (RD) gebruikt

Configureren

Raadpleeg afbeelding 1.

Hier is de configuratie nodig voor PE1 en PE2:

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

Opmerking: Als PE niet het buurbevel <interne-CE> interne-VPN-client voor de CE-buurman heeft, verspreidt het de prefixes van CE niet naar de SP RRs/PE routers.

Opmerking: Als PE niet RR in VRF is, verspreidt het de prefixes van de routers RRs/PE niet naar de router van CE.

Nieuwe opdracht

Er is een nieuwe opdracht, buurman <interne-CE> interne-VPN-client, om deze opdracht te laten werken. Het moet alleen op de PE-router worden geconfigureerd voor de iBGP-sessie naar de CE-routers.

Opmerking: De iBGP PE-CE Multi-VRF CE (VRF-Lite) optie wordt nog steeds ondersteund zonder de buuropdracht <interne-CE> interne-VPN-client.

Opmerking: Wanneer de opdracht voor een buurgebruiker <interne-CE> interne-VPN-client is ingesteld, worden de buuropdrachten <interne-CE> routereflector-client en buurgebruiker <interne-CE> next-hop-self-opdrachten ook automatisch in de configuratie geplaatst. Wanneer een van de buuropdrachten <interne-CE> routereflector-client en buurtwinkel <interne-CE> next-hop-zelfopdrachten (of beide) worden verwijderd en een herlading wordt uitgevoerd, worden ze automatisch teruggezet in de configuratie.

Gedetailleerd kijken naar ATTR_SET

Raadpleeg afbeelding 1.

Dit is het door CE1 geadverteerde prefix:

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

Als PE1 het voorvoegsel BGP 10.100.1.1/32 van CE1 ontvangt, slaat het het tweemaal op:

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

Het eerste pad is het echte pad op PE1, omdat het ontvangen is van CE1.

Het tweede pad is het pad dat naar de RRs/PE-routers wordt geadverteerd. Het is gemarkeerd met ibgp bron. Het bevat de eigenschap ATTR_SET. Merk op dat dit pad een of meer routedoelen (RTs) heeft aangesloten.

PE1 adverteert het voorvoegsel zoals hier wordt getoond:

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

Zo ziet RR het pad:

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

Merk op dat de lokale voorkeur van dit VPNv4 unicast prefix in de kern 100 is. In de ATTR_SET wordt de oorspronkelijke lokale voorkeur van 200 opgeslagen. Dit is echter transparant voor de RR in de SP - kern.

Op PE2, ziet u het voorvoegsel zoals hier wordt getoond:

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

Het eerste pad is dat ontvangen is van de RR, met de ATTR_SET. De RD is 65000:1, de oorsprong RD. Het tweede pad is het geïmporteerde pad uit de VRF-tabel met RD 65000:1. ATTR_SET is verwijderd.

Dit is het pad zoals gezien op CE2:

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

Merk op dat de volgende-hop 10.1.2.2 is, wat PE2 is. De clusterlijst bevat routers PE1 en PE2. Dit zijn de RR's die ertoe doen binnen VPN. De SP RR (10.100.1.3) staat niet in de clusterlijst.

De lokale voorkeur van 200 is binnen VPN over het SP netwerk bewaard gebleven.

De opdracht debug bgp vpnv4 unicast updates toont de update die in het SP netwerk wordt gekweekt:

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,

Opmerking: PE1 kreeg zijn eigen update van RR en liet die dan vallen. Dit komt doordat PE1 en PE2 in dezelfde update groep op RR zitten.

Opmerking: Als u het volledige bericht van de Update in hexadecimaal wilt dumpen, gebruik het detail sleutelwoord voor de debug BGP updates opdracht.

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,

Volgende hop

Next-hop-zelf moet op de PE routers voor deze functie worden geconfigureerd. De reden hiervoor is dat de volgende hop normaal ongewijzigd met iBGP wordt vervoerd. Er zijn echter twee afzonderlijke netwerken: het VPN-netwerk en het SP-netwerk, die afzonderlijke Interior Gateway Protocols (IGP’s) uitvoeren. Vandaar dat IGP metriek niet makkelijk vergeleken en gebruikt kan worden voor best path berekening tussen de twee netwerken. De benadering die door RFC 6368 is gekozen, is om voor de iBGP-sessie de volgende-hopzelfverplichting te hebben tegenover de CE, die de eerder beschreven kwestie bij elkaar vermijdt. Een voordeel is dat de sites VRF verschillende IGP's kunnen uitvoeren met deze benadering.

RD

RFC 6368 meldt dat het aanbevolen wordt om verschillende VRF-sites van hetzelfde VPN andere (unieke) RDs te gebruiken. In Cisco IOS is dit voor deze optie verplicht.

iBGP PE-CE optie met lokaal gesprek

Raadpleeg afbeelding 2. De VPN-klant1 heeft ASN 6501.

                                                                                                           Figuur 2

CE1 bevindt zich in AS 65001. Om deze interne BGP uit het oogpunt van PE1 te maken, heeft zij de iBGP locaal-as functie nodig.

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 en CE2 worden op dezelfde manier gevormd.

PE1 ziet het voorvoegsel BGP zoals hier wordt getoond:

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

Het voorvoegsel is een interne BGP.

PE2 ziet dit:

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

De Originator AS is 65001, het AS dat wordt gebruikt wanneer het voorvoegsel van PE2 naar CE2 wordt verzonden. Het AS wordt dus behouden, evenals de lokale voorkeur in dit voorbeeld.

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

U ziet Lokaal in plaats van AS pad. Dit betekent dat het een interne BGP-route is die is ontstaan in AS 65001, wat ook de geconfigureerde ASN van router CE2 is. Alle BGP-eigenschappen zijn overgenomen uit de ATTR_SET-eigenschap. Dit houdt zich aan de regels voor zaak 1 in het volgende deel.

Regels voor routeuitwisseling tussen verschillende VRF-locaties

ATTR_SET bevat de Originator AS van de oorsprong VRF. Dit Originator AS wordt gecontroleerd door de afgelegen PE, wanneer het de ATTR_SET verwijdert voordat het voorvoegsel naar de CE router stuurt.

Zaak 1: Als de Originator AS de geconfigureerde AS voor de CE-router overeenkomt, worden de BGP-eigenschappen afgeleid van de ATTR_SET-eigenschap wanneer de PE het pad naar de bestemming VRF importeert.

Zaak 2: Als de Originator AS niet overeenkomt met de geconfigureerde AS voor de CE-router, wordt de reeks eigenschappen voor het geconstrueerde pad zoals hieronder weergegeven:

  1. De eigenschappen van het pad worden ingesteld op de eigenschappen in de eigenschap ATTR_SET.

  2. De iBGP-specifieke eigenschappen worden weggegooid (LOCAL_PREF, ORIGINATOR en CLUSTER_LIST).

  3. Het Origin AS-nummer in de ATTR_SET-eigenschap wordt toegevoegd aan de AS_PATH en volgt de regels die van toepassing zijn op een extern BGP-signaal tussen de bron en de bestemming ASs.

  4. Als het autonome systeem dat met de VRF is geassocieerd, hetzelfde is als het VPN-provider autonome systeem en de AS_PATH-eigenschap van de VPN-route niet leeg is, DIENT dit te worden toegevoegd aan de AS_PATH-eigenschap van de VRF-route.

    Raadpleeg afbeelding 3. CE1 en PE1 hebben de AS 65000 en zijn geconfigureerd met de iBGP PE-CE functie. CE2 heeft ASN 65001. Dit betekent dat er eBGP is tussen PE2 en CE2.

    117567-technote-ibgp-03.jpg

                                                                                                           Figuur 3

PE2 ziet de route als volgt:

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

Dit is het prefix zoals gezien op CE2:

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

Dit is Case 2. Het Origin AS-nummer in de ATTR_SET-eigenschap wordt aan de AS_PATH toegevoegd door PE2 en volgt de regels die van toepassing zijn op een eBGP-bewerking tussen de bron en bestemming AS. De iBGP-specifieke eigenschappen worden door PE2 genegeerd wanneer het de route creëert die naar CE2 moet worden geadverteerd. De lokale voorkeur is dus 100 en niet 200 (zoals gezien in de ATTR_SET-eigenschap).

CE-to-CE VRF-Lite-reflectie

Raadpleeg afbeelding 4.

117567-technote-ibgp-04.jpg

                                                                                                         Figuur 4

Afbeelding 4 toont een extra CE-router, CE3, die op PE1 is aangesloten. CE1 en CE3 zijn beide verbonden met PE1 op dezelfde VRF-instantie: klant1. Dit betekent dat CE1 en CE3 multi-VRF CE routers (ook bekend als VRF-Lite) van PE1 zijn. PE1 zet zichzelf als volgende-hop wanneer het de prefixes van CE1 tot CE3 adverteert. In het geval dat dit gedrag niet gewild is, kunt u buurman 10.1.3.6 ongewijzigd op PE1 configureren. buurman 10.1.3.6 nahopzelf op PE1 verwijderen. Dan ziet CE3 de routes van CE1 met CE1 de volgende-hop voor die BGP prefixes. Om dit werk te maken, hebt u de routes voor die BGP volgende-hops in de routeringslijst van CE3 nodig. U hebt een dynamisch Routing Protocol (IGP) of statische routes op CE1, PE1, en CE3 nodig om te verzekeren de routers een route voor elk ander volgende-hop IP adressen hebben. Maar er is een probleem met deze configuratie.

De configuratie op PE1 is:

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

Het voorvoegsel van CE1 wordt fijn gezien op CE3:

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

Het prefix van CE2 wordt echter op CE3 weergegeven zoals hieronder wordt weergegeven:

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

Het BGP next-hop is 192.168.100.2, het loopback IP-adres van PE2. PE1 heeft de BGP next-hop niet herschreven toen het het voorvoegsel 10.100.1.2/32 aan CE3 bekendmaakte. Dit maakt dit voorvoegsel op CE3 onbruikbaar.

Dus in het geval van een mix van de iBGP PE-CE optie over MPLS-VPN en iBGP VRF-Lite, moet u ervoor zorgen dat u altijd next-hop-self op de PE routers hebt.

U kunt de volgende-hop niet bewaren wanneer een PE-router een RR is die iBGP-routes van één CE naar een andere CE door VRF-interfaces lokaal op de PE reflecteert. Wanneer u iBGP PE-CE over een MPLS VPN-netwerk draait, moet u interne VPN-client gebruiken voor de iBGP-sessies naar de CE-routers. Wanneer u meer dan één lokale CE in een VRF op een PE router hebt, dan moet u next-hop-self voor die BGP-peers houden.

U kunt naar routekaarten kijken om de volgende hop aan zichzelf voor prefixes te plaatsen die van andere PE routers worden ontvangen, maar niet voor gereflecteerde prefixes van andere lokaal aangesloten CE routers. Echter, het wordt momenteel niet ondersteund om de volgende-hop in een uitgaande route-kaart in zichzelf te zetten. Deze configuratie wordt hier getoond:

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
!

Dit wordt echter niet ondersteund:

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

Oudere Cisco IOS op PoE router

Als PE1 oudere Cisco IOS software draait die de optie iBGP PE-CE ontbeert, dan stelt PE1 zichzelf nooit in als de volgende-hop voor de gereflecteerde iBGP prefixes. Dit betekent dat het gereflecteerde BGP-voorvoegsel (10.100.1.1/32) van CE1 (10.100.1.1) tot CE2 -via PE1- CE1 (10.1.1.4) als volgende hop zou hebben.

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

Het voorvoegsel van CE2 (10.100.1.2/32) wordt met PE2 gezien als de volgende hop, omdat PE1 de volgende-hop zelf voor dit voorvoegsel ook niet doet:

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

Om de iBGP PE-CE optie goed te laten werken, moeten alle PE routers voor VPN waar de functie geactiveerd is, de code hebben om de functie te ondersteunen en deze optie ingeschakeld hebben.

Next-hop-zelf voor eBGP op VRF

Raadpleeg afbeelding 5.

                                                                                                  Afbeelding 5

Afbeelding 5 toont een VRF-Lite-installatie. De zitting van PE1 naar CE4 is eBGP. De zitting van PE1 naar CE3 is nog steeds iBGP.

Voor eBGP prefixes, wordt de volgende-hop altijd op zichzelf ingesteld wanneer de prefixes bij een iBGP buurman op VRF wordt geadverteerd. Dit maakt niet uit of de sessie naar de iBGP buurman bij VRF de volgende-hopzelfinstelling heeft of niet.

In figuur 5 ziet CE3 de prefixes van CE4 met PE1 als de volgende 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

Dit gebeurt met de volgende-hop-zelve op PE1 naar CE3 of zonder.

Als de interfaces op PE1 naar CE3 en CE4 niet in een VRF zijn opgenomen, maar in de mondiale context, maakt het volgende-hopzelf naar CE3 een verschil.

Zonder zichzelf op PE1 naar CE3, zie je:

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)

Alhoewel het volgende-hop-zelf impliciet wordt geactiveerd, wijst de output dit niet aan. 

Met next-hop-self-on PE1 naar CE3, zie je:

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

Terwijl, als de interfaces naar CE3 en CE4 in een mondiale context zijn, de volgende hop voor prefixes van CE4 zelf CE4 is wanneer next-hop-self niet is geconfigureerd:

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

Voor zichzelf in de richting van 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

Dit werd gedaan op basis van RFC 4364.

Als u de volgende-hop-zelf niet wilt instellen voor eBGP-prefixes bij een iBGP-sessie via een VRF-interface, moet u de volgende-hop-onveranderd configureren. De ondersteuning hiervoor is alleen beschikbaar bij Cisco bug-ID CSCuj1720.

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

CE3 ziet CE4 als de volgende hop voor de door CE4 geadverteerde prefixes:

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

Als u probeert het volgende-hop-onveranderde sleutelwoord voor de iBGP sessie naar CE3 op Cisco IOS code vóór Cisco bug-id CSCuj1720 te configureren, krijgt u deze fout te zien:

PE1(config-router-af)# neighbor 10.1.3.6 next-hop-unchanged 
%BGP: Can propagate the nexthop only to multi-hop EBGP neighbor

Na Cisco bug ID CSCuj1720, is het volgende-hop-onveranderde sleutelwoord geldig voor multi-hop eBGP buren en iBGP VRF-Lite buren.

TAC Authored

Bijgedragen door Cisco-engineers

  • Luc De Ghein
    Cisco TAC Engineer.

Was dit document nuttig?

FeedbackFeedback

Contact Cisco