IP : Protocolo de puerta de enlace fronteriza (BGP)

Aplicación IOS de la característica del iBGP PE-CE

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe cómo el Internal Border Gateway Protocol (iBGP) entre el borde del proveedor (PE) y la característica de la frontera del cliente (CE) se implementa en el ® del Cisco IOS.

Contribuido por Lucas De Ghein, ingeniero de Cisco TAC.

Antecedentes

Hasta la nueva característica del iBGP PE-CE, el iBGP entre el PE y el CE (por lo tanto en una interfaz del ruteo virtual y de la expedición (VRF) en el router PE) no fueron soportados oficialmente. Una excepción es iBGP en las interfaces VRF en un Multi-VRF CE (VRF-Lite) puesto. La motivación para desplegar esta característica es:

  • El cliente quiere tener un solo número del sistema autónomo (ASN) en los sitios múltiples del VRF, sin el despliegue del Border Gateway Protocol externo (eBGP) con la como-invalidación.

  • El cliente quiere proporcionar la reflexión de la ruta interno hacia el Routers CE, actuando como si la base del proveedor de servicio (SP) sea un reflector de ruta transparente (RR).

Con esta característica, los sitios del VRF pueden tener el mismo ASN que la base SP. Sin embargo, en caso de que el ASN de los sitios VRF sea diferente que el ASN de la base SP, puede ser hecha para aparecer lo mismo con el uso del sistema local-autónomo de la característica (COMO).

Implemente el iBGP PE-CE

Aquí están los dos mayores parte para hacer que esta característica trabaja:

  • Un nuevo atributo ATTR_SET fue agregado al protocolo BGP para llevar los atributos BGP VPN a través de la base SP de una manera transparente.
  • Haga el router PE un RR para las sesiones del iBGP hacia el Routers CE en el VRF y como RR hacia los vecinos del VPNv4 (otro Routers PE o RR).


El nuevo atributo ATTR_SET permite que el SP lleve todos los atributos BGP del cliente de una manera transparente y no interfiere con los atributos y las políticas de BGP SP. Tales atributos son la lista del cluster, preferencia local, las comunidades, y así sucesivamente.

Atributo de la ruta del cliente BGP

ATTR_SET es el nuevo atributo BGP usado para llevar los atributos BGP VPN del cliente SP. Es un atributo transitivo opcional. En este atributo, todos los atributos BGP del cliente del mensaje de la actualización de BGP, a excepción de los atributos MP_REACH y MP_UNREACH, pueden ser llevados.

El atributo ATTR_SET tiene este formato:

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

Los indicadores del atributo son los indicadores regulares del atributo BGP (refiera al RFC 4271). La longitud de atributo indica si la longitud de atributo es uno o dos octetos. El propósito del origen COMO campo es prevenir el escape de una ruta originada en una en cuanto a se escape a otra COMO sin la manipulación apropiada del AS_PATH. El campo de los atributos path de la Longitud variable lleva los atributos BGP VPN que se deben llevar a través de la base SP.

En el router de la salida PE, los atributos BGP VPN se avanzan en este atributo. En el router del ingreso PE, estos atributos se hacen estallar del atributo, antes de que el prefijo BGP se envíe al router CE. Este atributo proporciona el aislamiento de los atributos BGP entre la red y el cliente VPN SP y vice versa. Por ejemplo, el List Attribute del cluster del Route Reflection SP no se considera y se considera dentro de la red VPN. Pero también, el List Attribute del cluster del Route Reflection VPN no se considera y se considera dentro de la red SP.

Mire el cuadro 1 para ver la propagación de un prefijo del cliente BGP a través de la red SP.

                                                                                                            Figura 1

El CE1 y el CE2 están en lo mismo QUE como la red SP: 65000. El PE1 tiene iBGP configurado hacia el CE1. El PE1 refleja la trayectoria para el prefijo 10.100.1.1/32 hacia el RR en la red SP. El RR refleja la trayectoria del iBGP hacia el Routers PE como de costumbre. El PE2 refleja la trayectoria hacia el CE2.

Para que esto trabaje correctamente, usted debe:

  • Tenga código en el PE1 y el PE2 que tiene el soporte de característica del iBGP PE-CE

  • Configure el PE1 y el PE2 para realizar el Route Reflection en su sesión de BGP hacia su Routers respectivo CE

  • Tenga el siguiente-salto-uno mismo en el Routers PE para la sesión de BGP hacia su Routers CE

  • Aseegurese que cada sitio VPN utiliza diversos Route Distinguisher (RD)

Configurar

Refiera al cuadro 1.

Aquí está la configuración necesaria para el PE1 y el 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

Nota: Si el PE no tiene el comando vecino del interno-VPN-cliente del <internal-CE> para el vecino CE, no propaga los prefijos del CE hacia el Routers SP RRs/PE.

Nota: Si el PE no es el RR en el VRF, no propaga los prefijos del Routers RRs/PE hacia el router CE.

Nuevo Comando

Hay comando new, interno-VPN-cliente vecino del <internal-CE>, de hacer este trabajo del feaure. Debe ser configurado en el router PE solamente para la sesión del iBGP hacia el Routers CE.

Nota: La característica del iBGP PE-CE MULTI-VRF CE (VRF-Lite) todavía se soporta sin el comando vecino del interno-VPN-cliente del <internal-CE>.

Nota: Cuando se configura el comando vecino del interno-VPN-cliente del <internal-CE>, ponen a los comandos next-hop-self vecinos del <internal-CE> del ruta-reflector-cliente y del vecino del <internal-CE> automáticamente en la configuración también. Cuando realizan cualquiera del ruta-reflector-cliente y del vecino vecinos del <internal-CE> que los comandos next-hop-self se quita del <internal-CE> (o ambos) y una recarga, después detrás los ponen automáticamente en la configuración.

Mirada detallada en ATTR_SET

Refiera al cuadro 1.

Éste es el prefijo de divulgación por el CE1:

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

Cuando el PE1 recibe el prefijo 10.100.1.1/32 BGP del CE1, lo salva dos veces:

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

La primera trayectoria es la ruta de acceso real en el PE1, porque se recibe del CE1.

La segunda trayectoria es la trayectoria que se hace publicidad hacia el Routers RRs/PE. Se marca con el ibgp originado. Contiene el atributo ATTR_SET. Note que esta trayectoria tiene una o más blancos de la ruta (RT) asociadas a ella.

El PE1 hace publicidad del prefijo como se muestra aquí:

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

Éste es cómo el RR ve la trayectoria:

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

Note que la preferencia local de este prefijo del unicast del VPNv4 en la base es 100. En el ATTR_SET, la preferencia local original de 200 se salva. Sin embargo, esto es transparente al RR en la base SP.

En el PE2, usted ve el prefijo como se muestra aquí:

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

La primera trayectoria es la que está recibida del RR, con el ATTR_SET. Observe que el RD es 65000:1, el origen RD. La segunda trayectoria es la trayectoria importada de la tabla VRF con RD 65000:1. Se ha quitado El ATTR_SET.

Ésta es la trayectoria según lo visto en el 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

Note que el Next-Hop es 10.1.2.2, que es PE2. La lista del cluster contiene al Routers PE1 y PE2. Éstos son los RR que importan dentro del VPN. El SP RR (10.100.1.3) no está en la lista del cluster.

La preferencia local de 200 se ha preservado dentro del VPN a través de la red SP.

El unicast BGP vpnv4 del debug pone al día el comando muestra la actualización propagada en la red SP:

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,

Nota: El PE1 recibió su propia actualización del RR y después la cayó. Esto es porque el PE1 y el PE2 están en el mismo grupo de la actualización en el RR.

Nota: Si usted quiere vaciar el mensaje de actualización completo en el hexadecimal, utilice la palabra clave del detalle para el comando de las actualizaciones de BGP del debug.

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,

Dirección del salto siguiente

el Siguiente-salto-uno mismo debe ser configurado en el Routers PE para esta característica. La razón de esto es que el Next-Hop está transportado normalmente sin cambiar con el iBGP. Sin embargo, aquí hay dos redes separadas: la red VPN y la red SP, que funcionan con los protocolos Interior Gateway Protocols separados (IGP). Por lo tanto, el IGP métrico no se puede comparar y utilizar fácilmente para el cálculo del mejor trayecto entre las dos redes. El acercamiento elegido por el RFC 6368 es tener el siguiente-salto-uno mismo obligatorio para la sesión del iBGP hacia el CE, que evita previamente el problema descrito todo junto. Una ventaja es que los sitios VRF pueden ejecutar diversos IGP con este acercamiento.

RD

El RFC 6368 menciona que está recomendado que diversos sitios VRF del mismo VPN utilizan diversos RD (únicos). En el Cisco IOS, esto es obligatorio para esta característica.

característica del iBGP PE-CE con Local-COMO

Refiera al cuadro 2. El customer1 VPN tiene ASN 65001.

                                                                                                           Figura 2

El CE1 está adentro COMO 65001. Para hacer este Internal BGP del punto de vista del PE1, necesita la función local-AS del iBGP.

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

El PE2 y el CE2 se configuran semejantemente.

El PE1 ve el prefijo BGP como se muestra aquí:

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

El prefijo es un Internal BGP.

El PE2 ve esto:

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

El terminal original AL IGUAL QUE 65001, que es SEGÚN LO utilizado cuando el prefijo se envía del PE2 al CE2. Así pues, AL IGUAL QUE se preserva, y así que es la preferencia local en este ejemplo.

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

Usted ve el Local en vez del COMO trayectoria. Esto significa que es una ruta del Internal BGP originada adentro COMO 65001, que es también el ASN configurado del router CE2. Todos los atributos BGP se han tomado del atributo ATTR_SET. Esto se adhiere a las reglas para el caso 1 en la siguiente sección.

Reglas para el intercambio de ruta entre diversos sitios VRF

El ATTR_SET contiene al terminal original a partir del VRF que origina. Esto que origina COMO es marcado por el telecontrol PE, cuando quita el ATTR_SET antes de que envíe el prefijo al router CE.

Caso 1: Si el originar COMO hace juego a configurado EN CUANTO el router CE, después a los atributos BGP se toma del atributo ATTR_SET cuando el PE importa la trayectoria en el destino VRF.

Caso 2: Si el originar AL IGUAL QUE no hace juego configurado EN CUANTO al router CE, después al conjunto de los atributos para la trayectoria construida se toma como se muestra aquí:

  1. Los atributos path se fijan a los atributos contenidos en el atributo ATTR_SET.

  2. Se desechan los atributos iBGP-específicos (LOCAL_PREF, TERMINAL ORIGINAL, y CLUSTER_LIST).

  3. El origen COMO número contenido en el atributo ATTR_SET prepended al AS_PATH y sigue las reglas que se aplican a un peering del BGP externo entre la fuente y el destino AS.

  4. Si el sistema autónomo asociado al VRF es lo mismo que el sistema autónomo del proveedor VPN y el atributo AS_PATH de la ruta VPN no está vacíos, prepended al atributo AS_PATH de la ruta VRF.

    Refiera al cuadro 3. CE1 y PE1 tienen COMO 65000 y se configuran con la característica del iBGP PE-CE. El CE2 tiene ASN 65001. Esto significa que hay eBGP entre el PE2 y el CE2.

    117567-technote-ibgp-03.jpg

                                                                                                           Figura 3

El PE2 ve la ruta como sigue:

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

Éste es el prefijo según lo visto en el 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

Éste es el caso 2. El origen COMO número contenido en el atributo ATTR_SET prepended al AS_PATH por el PE2 y sigue las reglas que se aplican a un eBGP que mira entre la fuente y el destino COMO. Los atributos iBGP-específicos son ignorados por el PE2 cuando crea la ruta que se hará publicidad al CE2. Así pues, la preferencia local es 100 y no 200 (como se ve en el atributo ATTR_SET).

Reflexión CE-a-CE VRF-Lite

Refiera al cuadro 4.

117567-technote-ibgp-04.jpg

                                                                                                         ‘Figura 4’

El cuadro 4 muestra un router CE adicional, CE3, conectado con el PE1. El CE1 y el CE3 ambos están conectados con el PE1 en el mismo caso VRF: customer1. Esto significa que el CE1 y el CE3 son Routers Multi-VRF CE (también conocido como VRF-Lite) del PE1. El PE1 se pone como Next-Hop cuando hace publicidad de los prefijos del CE1 al CE3. En caso de que este comportamiento no se quiera, usted podría configurar al vecino 10.1.3.6 siguiente-salto-sin cambios en el PE1. Para configurar esto, usted debe quitar al siguiente-salto-uno mismo de 10.1.3.6 del vecino en el PE1. Entonces el CE3 ve las rutas del CE1 con el CE1 para ser el Next-Hop para esos prefijos BGP. Para hacer este trabajo, usted necesita las rutas para esos saltos siguientes BGP en la tabla de ruteo de CE3. Usted necesita un Dynamic Routing Protocol (IGP) o las Static rutas en el CE1, el PE1, y el CE3 para aseegurarse al Routers tener una ruta para cada otras los IP Address de Next Hop. Sin embargo, hay un problema con esta configuración.

La configuración en el PE1 es:

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

El prefijo del CE1 se considera muy bien en el 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

Sin embargo, el prefijo del CE2 se considera en el CE3 como se muestra aquí:

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

El Next-Hop BGP es 192.168.100.2, el Loopback IP Address del PE2. El PE1 no reescribió el Next-Hop BGP a sí mismo cuando hizo publicidad del prefijo 10.100.1.2/32 al CE3. Esto hace este prefijo inutilizable en el CE3.

Así pues, en el caso de una mezcla de la característica del iBGP PE-CE a través de MPLS-VPN y del iBGP VRF-Lite, usted debe aseegurarse que usted tiene siempre el siguiente-salto-uno mismo en el Routers PE.

Usted no puede preservar el Next-Hop cuando un router PE es un RR que refleja las rutas del iBGP a partir de un CE a otro CE a través de las interfaces VRF localmente en el PE. Cuando usted ejecuta el iBGP PE-CE a través de una red del MPLS VPN, usted debe utilizar al interno-VPN-cliente para las sesiones del iBGP hacia el Routers CE. Cuando usted tiene más de un CE local en un VRF en un router PE, después usted debe guardar al siguiente-salto-uno mismo para esos peeres BGP.

Usted podría mirar las ruta-correspondencias para fijar el Next-Hop al uno mismo para los prefijos recibidos del otro Routers PE, pero no para los prefijos reflejados del otro Routers local-conectado CE. Sin embargo, no se soporta actualmente para fijar el Next-Hop al uno mismo en un mapa de ruta de salida. Esa configuración se muestra aquí:

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
!

Sin embargo, esto no se soporta:

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

Un Cisco IOS más viejo en el router PE

Si el PE1 funciona con un más viejo Cisco IOS Software que falte el iBGP PE-CE de la característica, después el PE1 nunca se fija como el Next-Hop para los prefijos reflejados del iBGP. Esto significa que el prefijo reflejado BGP (10.100.1.1/32) de CE1 (10.100.1.1) al CE2 - vía PE1- tendría CE1 (10.1.1.4) como el Next-Hop.

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

El prefijo de CE2 (10.100.1.2/32) se considera con el PE2 como el Next-Hop, porque el PE1 no hace al siguiente-salto-uno mismo para este prefijo cualquiera:

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

Para que la característica del iBGP PE-CE trabaje correctamente, todo el Routers PE para el VPN donde se habilita la característica debe tener el código para soportar la característica y para hacer la característica habilitar.

Siguiente-salto-uno mismo para el eBGP en el VRF

Refiera al cuadro 5.

                                                                                                  Figura 5

El cuadro 5 muestra una configuración de VRF-Lite. La sesión del PE1 hacia CE4 es eBGP. La sesión del PE1 hacia el CE3 sigue siendo iBGP.

Para los prefijos del eBGP, el Next-Hop se fija siempre al uno mismo cuando hace publicidad de los prefijos hacia un vecino iBGP en el VRF. Éste es sin importar el hecho si la sesión hacia el vecino iBGP a través del VRF tiene el siguiente-salto-uno mismo fijado o no.

En el cuadro 5, el CE3 ve los prefijos de CE4 con el PE1 como el 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

Esto ocurre con el siguiente-salto-uno mismo en el PE1 hacia el CE3 o fuera.

Si las interfaces en el PE1 hacia el CE3 y CE4 están no en un VRF, sino en el contexto global, el siguiente-salto-uno mismo hacia el CE3 hace diferencia.

Sin el siguiente-salto-uno mismo en el PE1 hacia el CE3, usted ve:

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)

Aunque habiliten al siguiente-salto-uno mismo implícito, la salida no indica esto. 

Con el siguiente-salto-uno mismo en el PE1 hacia el CE3, usted ve:

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

Considerando que, si las interfaces hacia el CE3 y CE4 están en un contexto global, el Next-Hop para los prefijos de CE4 es CE4 sí mismo cuando no configuran al siguiente-salto-uno mismo:

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

Para el siguiente-salto-uno mismo en el PE1 hacia el 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

Esto fue hecha sobre la base del RFC 4364.

Si usted quiere no fijar al siguiente-salto-uno mismo para los prefijos del eBGP hacia una sesión del iBGP a través de una interfaz VRF, usted debe configurar siguiente-salto-sin cambios. El soporte para esto ocurrió solamente con el Id. de bug Cisco CSCuj11720.

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

Ahora, el CE3 ve CE4 como el Next-Hop para los prefijos des divulgación por CE4:

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

Si usted intenta configurar la palabra clave siguiente-salto-sin cambios para la sesión del iBGP hacia el CE3 en el código del Cisco IOS antes del Id. de bug Cisco CSCuj11720, usted encuentra este error:

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

Después del Id. de bug Cisco CSCuj11720, la palabra clave siguiente-salto-sin cambios es válida para los vecinos eBGP del multi-salto y los vecinos de VRF-Lite del iBGP.



Document ID: 117567