Já tem uma conta?

  •   Conteúdo personalizado
  •   Produtos e suporte

Ainda não tem uma conta?

Criar conta

Compreenda o lúpulo seguinte ajustado em propagandas do iBGP nos nexos NX-OS contra o Cisco IOS

Opções de download

  • PDF     (419.1 KB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (343.8 KB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (209.7 KB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:12 de Junho de 2018
ID do documento:213402
Sobre a tradução

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.


    Introdução

    Este original descreve o comportamento do atributo de trajeto do Próximo salto quando o grupo para propagandas interiores do protocolo Protocolo de la puerta de enlace marginal (BGP) (iBGP) nos nexos NX-OS contra o Cisco IOS (este inclui o Cisco IOS XE) baseou Plataformas. Isto é para propagandas de rotas não localmente originadas.

    Pré-requisitos

    Requisitos

    A Cisco recomenda que você tenha conhecimento destes tópicos:

    • Border Gateway Protocol (BGP)
    • Redistribução dos protocolos de roteamento

    Componentes Utilizados

    Este original não é restringido à versão de software e hardware específica:

    • Nexo 7000 que executa a versão 7.3(0)D1(1) NX-OS
    • Roteador de Cisco que executa a versão do Cisco IOS 15.6(2)T

    As saídas neste original foram tomadas dos dispositivos em um ambiente de laboratório específico. Todos os dispositivos usados neste original começaram com uma configuração cancelada (do padrão). Se sua rede está viva, assegure-se de que você compreenda o impacto potencial do comando any.


    Informações de fundo

    • No nexo NX-OS baseado as Plataformas, porque as rotas não localmente originadas, propagandas do iBGP alteram o atributo do Próximo salto e ajustam-no com seu próprio IP address da interface local.
    • No Cisco IOS baseado as Plataformas, porque as rotas não localmente originadas, propagandas do iBGP mantêm o atributo do Próximo salto da rota original enquanto é.

    O comportamento no nexo NX-OS pode combinar esse considerado no Cisco IOS se agradecimentos desejados às mudanças do código introduzidas pelo defeito CSCud20941.

    Note: Isto é somente aplicável para propagandas e não eBGP do iBGP.


    Note: Aplicável para as rotas não localmente originadas configuradas como rotas estáticas ou recebidas através de algum Interior Gateway Protocol (IGP) como o Enhanced Interior Gateway Routing Protocol (EIGRP), o Open Shortest Path First (OSPF) ou o Routing Information Protocol (RIP).


    Compreenda propagandas do iBGP

    A fim compreender o Próximo salto ajustado em propagandas do iBGP, tome como um exemplo os diagramas de topologia de rede mostrados nas imagens.

    Topologia para o caso do nexo NX-OS


     Topologia para o caso do Cisco IOS


    Caso do nexo NX-OS

    Na topologia para o caso do nexo NX-OS, R2 (nexo NX-OS) recebe a rota 1.1.1.1/32 através do EIGRP do roteador 1 e anuncia-a com o uso do iBGP ao roteador 3 segundo as indicações da imagem.


    (Nexo NX-OS) a tabela de roteamento R2 mostra a rota 1.1.1.1/32 recebida através do EIGRP e com o IP original do seguinte-lúpulo de 10.1.2.1

    R2 (nexo NX-OS) 
    R2# show ip route 1.1.1.1/32
    IP Route Table for VRF "default"
    '*' denotes best ucast next-hop
    '**' denotes best mcast next-hop
    '[x/y]' denotes [preference/metric]
    '%<string>' in via output denotes VRF <string>

    1.1.1.1/32, ubest/mbest: 1/0
        *via 10.1.2.1, Eth2/1, [90/130816], 00:02:28, eigrp-1, internal


    Na seção de configuração de BGP você pode ver os comandos anunciar no lugar 1.1.1.1/32 através do iBGP ao roteador 3.

    R2 (nexo NX-OS) 
    R2# show running-config bgp

!Command: show running-config bgp
!Time: -

version -
feature bgp

router bgp 2
  address-family ipv4 unicast
    network 1.1.1.1/32
  neighbor 10.2.3.3 remote-as 2
    address-family ipv4 unicast


    No roteador 3, a rota 1.1.1.1/32 é recebida através do iBGP com o seguinte-lúpulo ajustado agora ao IP address de R2 (nexo NX-OS) que é 10.2.3.2

    - Entrada de tabela do roteador 3 BGP para 1.1.1.1/32

    R3 
    R3# show bgp ipv4 unicast 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 8
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.2.3.2 from 10.2.3.2 (2.2.2.2)
      Origin IGP, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0


    - Entrada de tabela de roteamento do roteador 3 para 1.1.1.1/32

    R3 
    R3# show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
B        1.1.1.1 [200/0] via 10.2.3.2, 00:07:17


    Caso do Cisco IOS

    Na topologia para o caso do Cisco IOS, R2 (Cisco IOS) recebe a rota 1.1.1.1/32 através do EIGRP do roteador 1 e anuncia-a com o uso do iBGP ao roteador 3 segundo as indicações da imagem.

    (Cisco IOS) a tabela de roteamento R2 mostra a rota 1.1.1.1/32 recebida através do EIGRP e com o IP original do seguinte-lúpulo de 10.1.2.1

    R2 (Cisco IOS) 
    R2# show ip route 1.1.1.1 255.255.255.255 longer-prefixes
    Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
           D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
           N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
           E1 - OSPF external type 1, E2 - OSPF external type 2
           i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
           ia - IS-IS inter area, * - candidate default, U - per-user static route
           o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
           a - application route
           + - replicated route, % - next hop override, p - overrides from PfR

    Gateway of last resort is not set

          1.0.0.0/32 is subnetted, 1 subnets
    D        1.1.1.1 [90/130816] via 10.1.2.1, 00:00:06, GigabitEthernet0/1


    Na seção de configuração de BGP você pode ver os comandos anunciar no lugar 1.1.1.1/32 através do iBGP ao roteador 3

    R2 (Cisco IOS) 
    R2# show running-config partition router bgp 2
    Building configuration...

    Current configuration : 210 bytes
    !
    ! Last configuration change at -
    !
    !
    !
    !
    router bgp 2
     bgp router-id 2.2.2.2
     bgp log-neighbor-changes
    network 1.1.1.1 mask 255.255.255.255
     neighbor 10.2.3.3 remote-as 2
    !
    !
    end


    No roteador 3, você pode ver a rota 1.1.1.1/32 recebida através do iBGP com o seguinte-lúpulo original ajustado ao IP no roteador 1 que é 10.1.2.1.

    - Entrada de tabela do roteador 3 BGP para 1.1.1.1/32

    R3 
    R3# show bgp ipv4 unicast 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.1.2.1 (inaccessible) from 10.2.3.2 (2.2.2.2)
      Origin IGP, metric 130816, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0


    Nesta encenação específica, o roteador 3 deve ter um trajeto a 10.1.2.1 (o Seguinte-lúpulo) assim que o BGP pode considerar o trajeto como válido. Se não, o BGP mostra o trajeto como (inacessível).


    Note: Esta é uma verificação básica descrita no algoritmo de seleção de caminho do melhors BGP a fim aceitar rotas do BGP na tabela de roteamento.


    O comando debug ip bgp update mostra que o roteador 3 da razão não instala a rota é porque não há nenhuma entrada em sua tabela de roteamento para o seguinte-lúpulo, neste caso o seguinte-lúpulo é 10.1.2.1

    R3 
    R3# debug ip bgp update
*-: BGP(0): 10.2.3.2 rcvd UPDATE w/ attr: nexthop 10.1.2.1, origin i, localpref 100, metric 130816
*-: BGP(0): 10.2.3.2 rcvd 1.1.1.1/32
*-: BGP(0): no valid path for 1.1.1.1/32


    Uma aproximação para fazer o seguinte-lúpulo acessível é:

    - Etapa 1. Uma rota estática na tabela de roteamento do roteador 3 é configurada a fim criar uma entrada para o seguinte-lúpulo.

    R3 
    R3# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)# ip route 10.1.2.1 255.255.255.255 10.2.3.2


    - Etapa 2. O mesmo comando debug mostra que a rota está aceitada agora.

    R3 
    R3# debug ip bgp update
R3#
*Mar 29 16:08:42.888: BGP(0): 10.2.3.2 rcvd UPDATE w/ attr: nexthop 10.1.2.1, origin i, localpref 100, metric 130816
*Mar 29 16:08:42.890: BGP(0): 10.2.3.2 rcvd 1.1.1.1/32
*Mar 29 16:08:42.892: BGP(0): Revise route installing 1 of 1 routes for 1.1.1.1/32 -> 10.1.2.1(global) to main IP table
R3#


    - Etapa 3. A tabela de BGP removeu o estado (inacessível).

    R3 
    R3# show bgp ipv4 unicast 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 6
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  Local
    10.1.2.1 from 10.2.3.2 (2.2.2.2)
      Origin IGP, metric 130816, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0


    - A tabela de roteamento de etapa 4. instala agora a rota a 1.1.1.1/32

    R3 
    R3# show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

      1.0.0.0/32 is subnetted, 1 subnets
B        1.1.1.1 [200/130816] via 10.1.2.1, 00:11:37


    Uso de comando redist-inalterado do seguinte-lúpulo IP do grupo

    Desde a versão 6.2(12), os comandos set ip next-hop redist-inalterados e o seguinte-lúpulo ajustado do IPv6 redist-inalterado foram introduzidos pelo defeito CSCud20941 a fim fazer a espelho do nexo NX-OS o comportamento do Cisco IOS.

    Note: Estes comandos trabalham quando usados como parâmetros em um mapa de rotas e são usados somente em combinação com o comando redistribution.


    Na topologia para o caso do nexo NX-OS, R2 (nexo NX-OS) recebe a rota 1.1.1.1/32 através do EIGRP do roteador 1 e anuncia-a com iBGP ao roteador 3 segundo as indicações da imagem:


    (Nexo NX-OS) a tabela de roteamento R2 mostra a rota 1.1.1.1/32 recebida através do EIGRP e com o IP original do seguinte-lúpulo de 10.1.2.1

    R2 (nexo NX-OS) 
    R2# show ip route 1.1.1.1/32
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

1.1.1.1/32, ubest/mbest: 1/0
    *via 10.1.2.1, Eth2/1, [90/130816], 04:38:21, eigrp-1, internal


    O comando set ip next-hop redist-inalterado está disponível sob o modo de configuração do “mapa de rotas”.

    R2 (nexo NX-OS) 
    R2(config)# route-map REDIST-UNCHANGED
    R2(config-route-map)# set ip next-hop ?
      A.B.C.D              IP address of next hop
      load-share           Enables load sharing
      peer-address         Use peer address (for BGP only)
      redist-unchanged     Use unchanged address during redistribution (for BGP
                           session only) 
      unchanged            Use unchanged address (for eBGP session only)
      verify-availability  Verify the reachability of the tracked object

    R2(config-route-map)# set ip next-hop redist-unchanged


    O mapa de rotas REDIST-UNCHANGED é aplicado como um parâmetro para a instrução de configuração da redistribuição no BGP.

    R2 (nexo NX-OS) 
    R2#

!
    route-map REDIST-UNCHANGED permit 10
  set ip next-hop redist-unchanged
!    

R2# show running-config bgp

!Command: show running-config bgp
!Time: -

version -
feature bgp

router bgp 2
  address-family ipv4 unicast
    redistribute eigrp 1 route-map REDIST-UNCHANGED
  neighbor 10.2.3.3 remote-as 2
    address-family ipv4 unicast


    Agora o roteador 3 recebe a ATUALIZAÇÃO BGP com o similar ajustado do Próximo salto original ao Cisco IOS.

    R3 
    R3# show ip bgp 
BGP table version is 15, local router ID is 10.2.3.3
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
 * i 1.1.1.1/32       10.1.2.1            130816    100      0 ?


    Este original descreve a diferença de como o nexo NX-OS e o Cisco IOS seguram propagandas do iBGP de rotas não localmente geradas.

    O comportamento descrito neste original é para a maioria de cenários de caso e não é operações usuais de um esse roteamento de rede dos impactos.

    Os comandos opcionais ajustam o seguinte-lúpulo IP redist-inalterado e o seguinte-lúpulo ajustado do IPv6 redist-inalterado está disponível para manter a distribuição BGP complacente com o RFC 4271 no nexo NX-OS


    Configuração de dispositivos inicial

    R1 
    hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip ospf 1 area 0
!
interface GigabitEthernet0/1
 ip address 10.1.2.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
!
router ospf 1
    !


    R2 (nexo NX-OS) 
    hostname R2
!
feature ospf
feature bgp
!
interface Ethernet2/1
  no switchport
  ip address 10.1.2.2/24
  ip ospf network point-to-point
  ip router ospf 1 area 0.0.0.0
  no shutdown
!
interface Ethernet2/2
  no switchport
  ip address 10.2.3.2/24
  no shutdown
!
router ospf 1
!
router bgp 2
  address-family ipv4 unicast
    network 1.1.1.1/32
  neighbor 10.2.3.3 remote-as 2
    address-family ipv4 unicast
!


    R2 (Cisco IOS) 
    hostname R2
!
interface GigabitEthernet0/1
 ip address 10.1.2.2 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
!
interface GigabitEthernet0/2
 ip address 10.2.3.2 255.255.255.0
!
router ospf 1
!
router bgp 2
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 neighbor 10.2.3.3 remote-as 2
!


    R3 
    hostname R3
!
interface GigabitEthernet0/1
 ip address 10.2.3.3 255.255.255.0
!
router bgp 2
 bgp log-neighbor-changes
 neighbor 10.2.3.2 remote-as 2
!


    TAC Authored

    Colaborado por engenheiros da Cisco

    • Hector Gustavo Serrano Gutierrez
      Engenheiro de TAC da Cisco

    Este documento lhe foi útil?

    FeedbackFeedback

    Contate a Cisco

    Discussões relacionadas com comunidade da Cisco

    Sobre a Cisco
    Fale Conosco
    Trabalhe Conosco