IP : Border Gateway Protocol (BGP)

Aplicação IO da característica do iBGP PE-CE

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como o internal border gateway protocol (iBGP) entre a ponta de provedor (PE) e a característica do edge de cliente (CE) é executada no ® do Cisco IOS.

Contribuído por Luc De Ghein, engenheiro de TAC da Cisco.

Informações de Apoio

Até a característica nova do iBGP PE-CE, o iBGP entre o PE e o CE (daqui em uma relação do roteamento virtual e da transmissão (VRF) no roteador de PE) não foram apoiados oficialmente. Uma exceção é iBGP em relações VRF em um Multi-VRF CE (VRF-Lite) setup. A motivação para distribuir esta característica é:

  • O cliente quer ter um único número de sistema autônomo (ASN) nas sites múltiplo do VRF, sem o desenvolvimento do Protocolo de Gateway Limite externo (eBGP) (eBGP) com como-ultrapassagem.

  • O cliente quer fornecer a reflexão da rota interna para os CE Router, atuando como se o núcleo do provedor de serviços (SP) é um refletor de rota transparente (RR).

Com esta característica, os locais do VRF podem ter o mesmo ASN que o núcleo SP. Contudo, caso que o ASN dos locais VRF é diferente do que o ASN do núcleo SP, pode ser feito para aparecer o mesmos com o uso do sistema local-autônomo da característica (COMO).

IBGP PE-CE do implementar

Estão aqui os dois maiores parte a fim fazer esta característica trabalhar:

  • Um atributo novo ATTR_SET foi adicionado ao protocolo BGP a fim levar os atributos de BGP VPN através do núcleo SP em uma maneira transparente.
  • Faça ao roteador de PE um RR para as sessões do iBGP para os CE Router no VRF e como um RR para os vizinhos do VPNv4 (outros roteadores de PE ou RR).


O atributo novo ATTR_SET permite que o SP leve todos os atributos de BGP do cliente em uma maneira transparente e não interfere com os atributos e as políticas do BGP SP. Tais atributos são a lista do conjunto, preferência local, as comunidades, e assim por diante.

Atributo da rota do cliente BGP

ATTR_SET é os atributos de BGP novos usados a fim levar os atributos de BGP VPN do cliente SP. É um atributo de transição opcional. Neste atributo, todos os atributos de BGP do cliente da mensagem da atualização BGP, à exceção dos atributos MP_REACH e MP_UNREACH, podem ser levados.

O atributo ATTR_SET tem este formato:

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

As bandeiras do atributo são as bandeiras regulares dos atributos de BGP (refira o RFC 4271). O comprimento de atributo indica se o comprimento de atributo é um ou dois octetos. A finalidade da origem COMO o campo é impedir o escape de uma rota originada em uma a respeito de seja escapada a outra COMO sem a manipulação apropriada do AS_PATH. O campo dos atributos de trajeto do comprimento variável leva os atributos de BGP VPN que devem ser levados através do núcleo SP.

No roteador de PE da saída, os atributos de BGP VPN são introduzidos neste atributo. No roteador de PE do ingresso, estes atributos estão estalados do atributo, antes que o prefixo BGP esteja enviado ao CE Router. Este atributo fornece o isolamento dos atributos de BGP entre a rede SP e o cliente VPN e vice-versa. Por exemplo, o atributo de lista do conjunto da reflexão de rota SP não é considerado e é considerado dentro da rede VPN. Mas também, o atributo de lista do conjunto da reflexão de rota VPN não é considerado e é considerado dentro da rede SP.

Olhe figura 1 a fim ver a propagação de um prefixo do cliente BGP através da rede SP.

                                                                                                            Figura 1

O CE1 e o CE2 estão no mesmos QUE como a rede SP: 65000. O PE1 tem o iBGP configurado para o CE1. O PE1 reflete o trajeto para o prefixo 10.100.1.1/32 para o RR na rede SP. O RR reflete o trajeto do iBGP para os roteadores de PE como de costume. O PE2 reflete o trajeto para o CE2.

Para que isto trabalhe corretamente, você deve:

  • Tenha o código no PE1 e no PE2 que tem o suporte de recurso do iBGP PE-CE

  • Configurar o PE1 e o PE2 a fim executar a reflexão de rota em sua sessão de BGP para seus CE Router respectivos

  • Tenha o seguinte-salto-auto nos roteadores de PE para a sessão de BGP para seus CE Router

  • Certifique-se de que cada local VPN usa os distinguidores de rota diferentes (RD)

Configurar

Consulte para figurar 1.

Está aqui a configuração necessário para o PE1 e o 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: Se o PE não tem o comando vizinho do interno-VPN-cliente do <internal-CE> para o vizinho CE, não propaga os prefixos do CE para o Roteadores SP RRs/PE.

Nota: Se o PE não é o RR no VRF, não propaga os prefixos do Roteadores RRs/PE para o CE Router.

Comando new

Há um comando new, interno-VPN-cliente vizinho do <internal-CE>, fazer este trabalho do feaure. Deve ser configurado no roteador de PE somente para a sessão do iBGP para os CE Router.

Nota: A característica do iBGP PE-CE MULTI-VRF CE (VRF-Lite) é apoiada ainda sem o comando vizinho do interno-VPN-cliente do <internal-CE>.

Nota: Quando o comando vizinho do interno-VPN-cliente do <internal-CE> é configurado, os comandos next-hop-self vizinhos do <internal-CE> do rota-refletor-cliente e do vizinho do <internal-CE> estão postos automaticamente na configuração também. Quando qualquer um do rota-refletor-cliente e do vizinho vizinhos do <internal-CE> comandos next-hop-self do <internal-CE> que (ou ambos) está removido e um reload é executado, a seguir estão postos automaticamente para trás na configuração.

Olhar detalhado em ATTR_SET

Consulte para figurar 1.

Este é o prefixo anunciado pelo 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

Quando o PE1 recebe o prefixo 10.100.1.1/32 BGP do CE1, armazena-o duas vezes:

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

O primeiro trajeto é o trajeto real no PE1, porque é recebido do CE1.

O segundo trajeto é o trajeto que é anunciado para o Roteadores RRs/PE. É identificado por meio do iBGP originado. Contém o atributo ATTR_SET. Observe que este trajeto tem uns ou vários alvos da rota (RT) anexados a ele.

O PE1 anuncia o prefixo como mostrado aqui:

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

Isto é como o RR vê o trajeto:

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

Observe que a preferência local deste prefixo do unicast do VPNv4 no núcleo é 100. No ATTR_SET, a preferência local original de 200 é armazenada. Contudo, isto é transparente ao RR no núcleo SP.

No PE2, você vê o prefixo como mostrado aqui:

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

O primeiro trajeto é esse recebido do RR, com o ATTR_SET. Note que o RD é 65000:1, a origem RD. O segundo trajeto é o trajeto importado da tabela VRF com RD 65000:1. O ATTR_SET foi removido.

Este é o trajeto como visto no 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

Observe que o salto seguinte é 10.1.2.2, que é PE2. A lista do conjunto contém o Roteadores PE1 e PE2. Estes são os RR que importam dentro do VPN. O SP RR (10.100.1.3) não está na lista do conjunto.

A preferência local de 200 foi preservada dentro do VPN através da rede SP.

O unicast do VPNv4 BGP debugar atualiza o comando mostra a atualização propagada na rede 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: O PE1 recebeu sua própria atualização do RR e deixou-a cair então. Isto é porque o PE1 e o PE2 estão no mesmo grupo da atualização no RR.

Nota: Se você quer despejar o mensagem de atualização completo no hexadecimal, use a palavra-chave do detalhe para o comando das atualizações BGP debugar.

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,

Manipulação do salto seguinte

o Seguinte-salto-auto deve ser configurado nos roteadores de PE para esta característica. A razão para esta é que o salto seguinte está transportado normalmente inalterado com iBGP. Contudo, aqui há duas redes separadas: a rede VPN e a rede SP, que executam os protocolos Interior Gateway Protocols separados (IGP). Daqui, a métrica IGP não pode facilmente ser comparada e usado para o cálculo do melhor caminho entre as duas redes. A aproximação escolhida pelo RFC 6368 é ter o seguinte-salto-auto imperativo para a sessão do iBGP para o CE, que evita toda a edição junto previamente descrita. Uma vantagem é que os locais VRF podem executar IGP diferentes com esta aproximação.

RD

O RFC 6368 menciona que se recomenda que os locais diferentes VRF do mesmo VPN usam RD (originais) diferentes. No Cisco IOS, isto é imperativo para esta característica.

característica do iBGP PE-CE com Local-COMO

Consulte para figurar 2. O cliente1 VPN tem ASN 65001.

                                                                                                           Figura 2

O CE1 está dentro COMO 65001. A fim fazer este Internal BGP do ponto de vista do PE1, precisa os recursos locais do 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

O PE2 e o CE2 são configurados similarmente.

O PE1 vê o prefixo BGP como mostrado aqui:

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

O prefixo é um Internal BGP.

O PE2 vê este:

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

O autor COMO é 65001, que é COMO usado quando o prefixo for enviado do PE2 ao CE2. Assim, COMO é preservada, e assim que é a preferência local neste exemplo.

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

Você vê o Local em vez do COMO o trajeto. Isto significa que é uma rota do Internal BGP originada dentro COMO 65001, que seja igualmente o ASN configurado do roteador CE2. Todos os atributos de BGP foram tomados do atributo ATTR_SET. Isto adere às regras para o caso 1 na próxima seção.

Regras para o intercâmbio de rota entre locais diferentes VRF

O ATTR_SET contém o autor até à data do VRF de origem. Isto que origina COMO é verificado pelo PE remoto, quando remover o ATTR_SET antes que enviar o prefixo ao CE Router.

Caso 1: Se a origem COMO combina configurado QUANTO para ao CE Router, a seguir os atributos de BGP estão tomados do atributo ATTR_SET quando o PE importa o trajeto no destino VRF.

Caso 2: Se a origem COMO não combina configurado QUANTO para ao CE Router, a seguir ao grupo de atributos para o trajeto construído é tomada como mostrado aqui:

  1. Os atributos de trajeto são ajustados aos atributos contidos no atributo ATTR_SET.

  2. Os atributos iBGP-específicos são rejeitados (LOCAL_PREF, AUTOR, e CLUSTER_LIST).

  3. A origem COMO o número contido no atributo ATTR_SET prepended ao AS_PATH e segue as regras que se aplicam a um BGP externo que espreita entre a fonte e o destino AS.

  4. Se o sistema autônomo associado com o VRF é o mesmo que o sistema autônomo do fornecedor VPN e o atributo AS_path da rota VPN não estão vazios, prepended ao atributo AS_path da rota VRF.

    Consulte para figurar que 3. CE1 e PE1 têm COMO 65000 e estão configurados com a característica do iBGP PE-CE. O CE2 tem ASN 65001. Isto significa que há um eBGP entre o PE2 e o CE2.

    117567-technote-ibgp-03.jpg

                                                                                                           Figura 3

O PE2 vê a rota como segue:

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

Este é o prefixo como visto no 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

Este é o caso 2. A origem COMO o número contido no atributo ATTR_SET prepended ao AS_PATH pelo PE2 e segue as regras que se aplicam a um peering eBGP entre a fonte e o destino COMO. Os atributos iBGP-específicos estão ignorados pelo PE2 quando cria a rota a ser anunciada ao CE2. Assim, a preferência local é 100 e não 200 (como visto no atributo ATTR_SET).

Reflexão CE-à-CE VRF-Lite

Consulte para figurar 4.

117567-technote-ibgp-04.jpg

                                                                                                         Figura 4

Figura 4 mostra um CE Router adicional, CE3, conectado ao PE1. O CE1 e o CE3 ambos são conectados ao PE1 no mesmo exemplo VRF: cliente1. Isto significa que o CE1 e o CE3 são os CE Router Multi-VRF (igualmente conhecidos como VRF-Lite) do PE1. O PE1 põe-se como o salto seguinte quando anuncia os prefixos do CE1 ao CE3. No caso em que este comportamento não fosse querido, você poderia configurar o vizinho 10.1.3.6 seguinte-salto-inalterado no PE1. A fim configurar isto, você deve remover o seguinte-salto-auto de 10.1.3.6 do vizinho no PE1. Então o CE3 vê as rotas do CE1 com CE1 para ser o salto seguinte para aqueles prefixos BGP. A fim fazer este trabalho, você precisa as rotas para aqueles saltos seguintes BGP na tabela de roteamento do CE3. Você precisa um protocolo de roteamento dinâmico (IGP) ou rotas estáticas no CE1, no PE1, e no CE3 a fim certificar-se do Roteadores ter uma rota para cada outro endereços IP do próximo salto. Contudo, há um problema com esta configuração.

A configuração no 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

O prefixo do CE1 é considerado muito bem no 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

Contudo, o prefixo do CE2 é considerado no CE3 como mostrado aqui:

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

O salto seguinte BGP é 192.168.100.2, o endereço IP de loopback do PE2. O PE1 senão reescreveu o salto seguinte BGP quando anunciou o prefixo 10.100.1.2/32 ao CE3. Isto faz este prefixo inusável no CE3.

Assim, no caso de uma mistura da característica do iBGP PE-CE através de MPLS-VPN e de iBGP VRF-Lite, você deve certificar-se de que você tem sempre o seguinte-salto-auto nos roteadores de PE.

Você não pode preservar o salto seguinte quando um roteador de PE é um RR que reflita rotas iBGP de um CE a um outro CE através das relações VRF localmente no PE. Quando você executa o iBGP PE-CE através de uma rede do MPLS VPN, você deve usar o interno-VPN-cliente para as sessões do iBGP para os CE Router. Quando você tem mais de um CE local em um VRF em um roteador de PE, a seguir você deve manter o seguinte-salto-auto para aqueles bgp peer.

Você poderia olhar mapas de rotas a fim ajustar o salto seguinte ao auto para os prefixos recebidos de outros roteadores de PE, mas não para prefixos refletido de outros CE Router local-conectados. Contudo, não é apoiado atualmente para ajustar o salto seguinte ao auto em um mapa de rotas de partida. Essa configuração é mostrada aqui:

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
!

Contudo, isto não é apoiado:

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

Cisco IOS mais velho no roteador de PE

Se o PE1 executa um Cisco IOS Software mais velho que falte o iBGP PE-CE da característica, a seguir o PE1 nunca ajusta-se como o salto seguinte para os prefixos refletidos do iBGP. Isto significa que o prefixo refletido BGP (10.100.1.1/32) de CE1 (10.100.1.1) ao CE2 - através de PE1- teria CE1 (10.1.1.4) como o salto seguinte.

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

O prefixo de CE2 (10.100.1.2/32) é considerado com o PE2 como o salto seguinte, porque o PE1 não faz o seguinte-salto-auto para este prefixo qualquer um:

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 a característica do iBGP PE-CE trabalhe corretamente, todos os roteadores de PE para o VPN onde a característica é permitida devem ter o código para apoiar a característica e para ter a característica permitida.

Seguinte-salto-auto para o eBGP no VRF

Consulte para figurar o 5.

                                                                                                  Figura 5

Figure que 5 mostra uma instalação de VRF-Lite. A sessão do PE1 para CE4 é eBGP. A sessão do PE1 para o CE3 é ainda iBGP.

Para prefixos do eBGP, o salto seguinte está ajustado sempre ao auto quando anuncia os prefixos para um vizinho iBGP no VRF. Isto é apesar do fato se a sessão para o vizinho iBGP através do VRF tem o seguinte-salto-auto ajustado ou não.

Na figura 5, o CE3 vê os prefixos de CE4 com o PE1 como o salto seguinte.

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

Isto ocorre com seguinte-salto-auto no PE1 para o CE3 ou sem.

Se as relações no PE1 para o CE3 e o CE4 estão não em um VRF, mas no contexto global, o seguinte-salto-auto para o CE3 faz faz a diferença.

Sem seguinte-salto-auto no PE1 para o CE3, você vê:

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)

Embora o seguinte-salto-auto seja permitido implicitamente, a saída não indica esta. 

Com seguinte-salto-auto no PE1 para o CE3, você vê:

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, se as relações para o CE3 e o CE4 estão em um contexto global, o salto seguinte para prefixos de CE4 é CE4 próprio quando o seguinte-salto-auto não for configurado:

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 o seguinte-salto-auto no PE1 para o 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

Isto foi feito com base no RFC 4364.

Se você quer não ajustar o seguinte-salto-auto para prefixos do eBGP para uma sessão do iBGP através de uma relação VRF, você deve configurar seguinte-salto-inalterado. O apoio para este ocorreu somente com identificação 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

Agora, o CE3 vê CE4 como o salto seguinte para os prefixos anunciados 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

Se você tenta configurar a palavra-chave seguinte-salto-inalterada para a sessão do iBGP para o CE3 no código do IOS Cisco antes da identificação de bug Cisco CSCuj11720, você encontra este erro:

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

Após a identificação de bug Cisco CSCuj11720, a palavra-chave seguinte-salto-inalterada é válida para vizinhos de ebgp do multi-salto e vizinhos de VRF-Lite do iBGP.



Document ID: 117567