Informazioni sull'hop successivo impostato negli annunci iBGP su Nexus NX-OS e Cisco IOS

Opzioni per il download

  • PDF     (385.7 KB)
    Visualizza con Adobe Reader su diversi dispositivi
  • ePub     (350.4 KB)
    Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (207.2 KB)
    Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi
Aggiornato:12 giugno 2018
ID documento:213402

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).


    Introduzione

    In questo documento viene descritto il comportamento dell'attributo path NEXT_HOP quando impostato per gli annunci iBGP (Interior Border Gateway Protocol) su piattaforme basate su Nexus NX-OS e Cisco IOS (incluso Cisco IOS-XE). Questa opzione è destinata agli annunci di route non originate localmente.

    Prerequisiti

    Requisiti

    Cisco raccomanda la conoscenza dei seguenti argomenti:

    • Border Gateway Protocol (BGP)
    • Ridistribuzione dei protocolli di routing

    Componenti usati

    Il documento può essere consultato per tutte le versioni software o hardware:

    • Nexus 7000 con NX-OS versione 7.3(0)D1(1)
    • Router Cisco con Cisco IOS versione 15.6(2)T

    Gli output di questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.


    Premesse

    • Nelle piattaforme Nexus basate su NX-OS, per le route non originate localmente, gli annunci iBGP modificano l'attributo NEXT_HOP e lo impostano con il proprio indirizzo IP dell'interfaccia locale.
    • Sulle piattaforme Cisco IOS, per le route non originate localmente, gli annunci iBGP mantengono l'attributo NEXT_HOP della route originale invariato.

    Il comportamento di Nexus NX-OS può corrispondere a quello di Cisco IOS, se lo si desidera, grazie alle modifiche del codice introdotte dal difetto CSCud20941.

    Nota: applicabile solo per gli annunci iBGP e non per eBGP.


    Nota: Applicabile per route non originate localmente configurate come route statiche o ricevute tramite un protocollo IGP (Interior Gateway Protocol), ad esempio EIGRP (Enhanced Interior Gateway Routing Protocol), OSPF (Open Shortest Path First) o RIP (Routing Information Protocol).


    Informazioni sulle pubblicità iBGP

    Per comprendere il set NEXT_HOP negli annunci iBGP, prendere come esempio i diagrammi della topologia di rete mostrati nelle immagini.

    Topologia per il caso Nexus NX-OS


     Topologia per il caso Cisco IOS


    Caso Nexus NX-OS

    In Topologia per il caso Nexus NX-OS, R2 (Nexus NX-OS) riceve il percorso 1.1.1.1/32 tramite EIGRP dal router 1 e lo pubblicizza con l'uso di iBGP al router 3, come mostrato nell'immagine.


    La tabella di routing di R2 (Nexus NX-OS) mostra il percorso 1.1.1.1/32 ricevuto tramite EIGRP e con l'IP originale dell'hop successivo della versione 10.1.2.1

    R2 (Nexus 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


    Nella sezione di configurazione BGP è possibile visualizzare i comandi in uso per annunciare il sito 1.1.1.1/32 tramite iBGP al router 3.

    R2 (Nexus 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


    Sul router 3, la route 1.1.1.1/32 viene ricevuta tramite iBGP con l'hop successivo impostato sull'indirizzo IP di R2 (Nexus NX-OS), ossia 10.2.3.2

    - Voce della tabella BGP del router 3 per 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


    - Voce della tabella di routing del router 3 per 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


    Cisco IOS Case

    In Topologia per il caso Cisco IOS, R2 (Cisco IOS) riceve il percorso 1.1.1.1/32 tramite EIGRP dal router 1 e lo annuncia con l'uso di iBGP al router 3, come mostrato nell'immagine.

    La tabella di routing di R2 (Cisco IOS) mostra il percorso 1.1.1.1/32 ricevuto tramite EIGRP e con l'IP dell'hop successivo originale di 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


    Nella sezione di configurazione BGP è possibile visualizzare i comandi in uso per annunciare il file 1.1.1.1/32 tramite iBGP al router 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


    Sul router 3, è possibile vedere la route 1.1.1.1/32 ricevuta tramite iBGP con l'hop successivo originale impostato sull'IP sul router 1, ossia 10.1.2.1.

    - Voce della tabella BGP del router 3 per 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


    In questo scenario specifico, il percorso del router 3 deve essere 10.1.2.1 (l'hop successivo) in modo che BGP possa considerarlo valido. In caso contrario, BGP visualizza il percorso come (inaccessibile).


    Nota: Questo è un controllo di base descritto nell'algoritmo di selezione del miglior percorso BGP per accettare le route da BGP alla tabella di routing.


    Il comando debug ip bgp update mostra il motivo per cui il router 3 non installa la route: non è presente alcuna voce nella tabella di routing per l'hop successivo, in questo caso l'hop successivo è 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


    Un approccio per rendere accessibile l'hop successivo è:

    - Passaggio 1. Un percorso statico nella tabella di routing del router 3 viene configurato per creare una voce per l'hop successivo.

    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


    - Passaggio 2. Lo stesso comando debug indica che la route è ora accettata.

    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#


    - Passaggio 3. La tabella BGP ha rimosso lo stato (inaccessibile).

    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


    - Passaggio 4. La tabella di routing installa il percorso su 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 del comando set ip next-hop redist-unchanged

    A partire dalla versione 6.2(12), i comandi set ip next-hop redist-unchanged e set ipv6 next-hop redist-unchanged sono stati introdotti da CSCud20941 per fare in modo che Nexus NX-OS rispecchi il comportamento di Cisco IOS.

    Nota: Questi comandi funzionano solo quando vengono utilizzati come parametri in una route-map e vengono utilizzati in combinazione con il comando redistribution.


    In Topologia per il caso Nexus NX-OS, R2 (Nexus NX-OS) riceve il percorso 1.1.1.1/32 tramite EIGRP dal router 1 e lo pubblicizza con iBGP al router 3, come mostrato nell'immagine:


    La tabella di routing di R2 (Nexus NX-OS) mostra il percorso 1.1.1.1/32 ricevuto tramite EIGRP e con l'IP originale dell'hop successivo della versione 10.1.2.1

    R2 (Nexus 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


    il comando set ip next-hop redist-unchanged è disponibile nella modalità di configurazione 'route-map'.

    R2 (Nexus 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


    La route-map REDIST-UNCHANGED viene applicata come parametro per l'istruzione redistribute configuration in BGP.

    R2 (Nexus 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


    A questo punto, il router 3 riceve il messaggio BGP UPDATE con il comando NEXT_HOP originale impostato su 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 ?


    Questo documento descrive la differenza di modalità con cui Nexus NX-OS e Cisco IOS gestiscono gli annunci iBGP di route non generate localmente.

    Il comportamento descritto in questo documento si riferisce alla maggior parte degli scenari possibili e non ha alcun impatto sulle normali operazioni di routing della rete.

    I comandi opzionali set ip next-hop redist-unchanged e set ipv6 next-hop redist-unchanged sono disponibili per mantenere il routing BGP conforme alla RFC 4271 su Nexus NX-OS


    Configurazione iniziale dispositivi

    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 (Nexus 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

    Contributo dei tecnici Cisco

    • Hector Gustavo Serrano Gutierrez
      Cisco TAC Engineer

    Questo documento ti è stato utile?

    FeedbackFeedback

    Contattaci