Begrijp de volgende hop-set in iBGP-advertenties op Nexus NX-OS vs Cisco IOS

Downloadopties

  • PDF     (418.4 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (349.4 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (205.5 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:12 juni 2018
Document-id:213402

Inclusief taalgebruik

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

Over deze vertaling

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


    Inleiding

    Dit document beschrijft het gedrag van de NEXT_HOP path-eigenschap wanneer deze is ingesteld voor iBGP-advertenties (Interior Border Gateway Protocol) op Nexus NX-OS vs Cisco IOS (dit omvat Cisco IOS-XE) gebaseerde platforms. Dit geldt voor advertenties op niet-lokale routes.

    Voorwaarden

    Vereisten

    Cisco raadt kennis van de volgende onderwerpen aan:

    • Border Gateway Protocol (BGP)
    • Herdistributie van routingprotocollen

    Gebruikte componenten

    Dit document is niet beperkt tot specifieke software- en hardwareversies:

    • Nexus 7000 met NX-OS versie 7.3(0)D1(1)
    • Cisco-router die Cisco IOS versie 15.6(2)T uitvoert

    De uitgangen in dit document zijn afkomstig van apparatuur in een specifieke labomgeving. Alle apparaten die in dit document worden gebruikt, zijn gestart met een gewalste (standaard) configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.


    Achtergrondinformatie

    • Op Nexus op NX-OS gebaseerde platforms, voor niet lokaal geïnitieerde routes, wijzigt iBGP-advertenties de NEXT_HOP-eigenschap en stelt deze in met zijn eigen lokale IP-adres.
    • Op Cisco IOS gebaseerde platforms, voor niet lokaal geïnitieerde routes, handhaaft iBGP-advertenties de NEXT_HOP eigenschap van de originele route zoals deze is.

    Het gedrag op Nexus NX-OS kan overeenkomen met het gedrag dat op Cisco IOS is gezien indien gewenst dankzij de codnieuwingen die door defect CSCud20941 zijn geïntroduceerd.

    Opmerking: dit geldt alleen voor iBGP-advertenties en niet voor eBGP.


    Opmerking: Toepasselijk voor niet lokaal geïnitieerde routes die als Static Routes zijn geconfigureerd of die via een Interior Gateway Protocol (IGP) zijn ontvangen zoals Enhanced Interior Gateway Routing Protocol (DHCP), Open Shortest Path First (OSPF) of Routing Information Protocol (RIP).


    iBGP-advertenties begrijpen

    Om de NEXT_HOP te begrijpen die in iBGP advertenties wordt geplaatst, neem als voorbeeld de diagrammen van de netwerktopologie die in de beelden worden getoond.

    Topologie voor Nexus NX-OS-case
    213402-understand-next-hop-set-in-ibgp-advertis-00.png


     Topologie voor Cisco IOS-case
    213402-understand-next-hop-set-in-ibgp-advertis-01.png


    Nexus NX-OS-case

    In Topologie voor Nexus NX-OS geval, ontvangt R2 (Nexus NX-OS) de 1.1.1.1/32 route via DHCP van router 1 en adverteert het met het gebruik van iBGP tot router 3 zoals in het beeld getoond wordt.

    213402-understand-next-hop-set-in-ibgp-advertis-02.png


    R2 (Nexus NX-OS) routingtabel toont de route 1.1.1.1/32 die via HTTP en met de originele next-hop IP van 10.1.2.1 is ontvangen

    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


    In het configuratiescherm van BGP kunt u de opdrachten op hun plaats zien om 1.1.1.1/32 via iBGP naar router 3 te adverteren.

    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


    Op router 3 wordt de 1.1.1.1/32 route ontvangen via iBGP terwijl de volgende hop nu is ingesteld op het IP-adres van R2 (Nexus NX-OS) dat 10.2.3.2 is

    - Router 3 BGP-tabelingang voor 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


    - Router 3 routingtabel voor 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 Topologie voor Cisco IOS geval, ontvangt R2 (Cisco IOS) de 1.1.1.1/32 route via RSP van Router 1 en adverteert het met het gebruik van iBGP aan router 3 zoals in het beeld getoond wordt.

    213402-understand-next-hop-set-in-ibgp-advertis-03.png

    R2 (Cisco IOS) Routing Tabel toont de route 1.1.1.1/32 die via DHCP ontvangen is en met de oorspronkelijke next-hop-IP van 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


    In het configuratiescherm van BGP ziet u de opdrachten op hun plaats om 1.1.1.1/32 via iBGP naar router 3 te adverteren

    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


    Op router 3, kunt u de 1.1.1.1/32 route zien die via iBGP wordt ontvangen met de originele next-hop die op IP op router 1 is die 10.1.2.1 is.

    - Router 3 BGP-tabelingang voor 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 dit specifieke scenario moet router 3 een pad naar 10.1.2.1 (de volgende-hop) hebben zodat BGP het pad als geldig kan beschouwen. Anders toont BGP het pad als (ontoegankelijk).


    Opmerking: Dit is een basiscontrole die in BGP het algoritme voor selectie van het beste pad wordt beschreven om routes van BGP in de Routing Tabel te aanvaarden.


    De opdracht debug ip bgp update toont de reden router 3 niet de route installeert is omdat er geen ingang in zijn Routing Tabel voor de volgende-hop is, in dit geval is de volgende-hop 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


    Eén benadering om de volgende hop toegankelijk te maken is:

    - Stap 1. Eén statische route in de routingtabel van router 3 is geconfigureerd om een ingang voor de volgende hop te maken.

    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


    - Stap 2. Dezelfde debug-opdracht toont aan dat de route nu is geaccepteerd.

    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#


    - Stap 3. De BGP-tabel heeft de (ontoegankelijke) status verwijderd.

    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


    - Stap 4. De routingtabel installeert nu de route naar 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


    Gebruik van de ingestelde ip de volgende-hop herst-onveranderd Opdracht

    Sinds versie 6.2(12), zijn de opdrachten geplaatst in ip next-hop-reset en set ipv6 next-hop-reset- onveranderd waren door defect CSCud20941 om Nexus NX-OS als kopie van Cisco IOS te maken.

    Opmerking: Deze opdrachten werken alleen wanneer deze als parameters worden gebruikt in een routekaart en worden in combinatie met de opdracht herdistributie gebruikt.


    In Topologie voor Nexus NX-OS geval, ontvangt R2 (Nexus NX-OS) de 1.1.1.1/32 route via DHCP van router 1 en adverteert het met iBGP tot router 3 zoals in het beeld getoond wordt:

    213402-understand-next-hop-set-in-ibgp-advertis-04.png


    R2 (Nexus NX-OS) routingtabel toont de route 1.1.1.1/32 die via HTTP en met de originele next-hop IP van 10.1.2.1 is ontvangen

    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


    De commando set ip next-hop zal onveranderd blijven is beschikbaar onder de 'route-map' configuratie modus.

    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


    De route-map REDIST-UNCHANGED wordt toegepast als parameter voor het opnieuw verdelen van configuratie statement 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


    Nu ontvangt router 3 de BGP UPDATE met de originele NEXT_HOP reeks gelijkend op 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 ?


    Dit document beschrijft het verschil tussen de manier waarop Nexus NX-OS en Cisco IOS iBGP-advertenties van niet lokaal gegenereerde routes verwerken.

    Het in dit document beschreven gedrag is voor de meeste scenario's en het is niet een dat de gebruikelijke routingoperaties van het netwerk beïnvloedt.

    De optionele opdrachten die ip ongewijzigd en ipv6 ongewijzigd zijn ingesteld, zijn beschikbaar om BGP-routing te onderhouden die compatibel is met RFC 4271 op Nexus NX-OS


    Configuratie van eerste apparaten

    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

    Bijgedragen door Cisco-engineers

    • Hector Gustavo Serrano Gutierrez
      Cisco TAC-ingenieur

    Was dit document nuttig?

    FeedbackFeedback

    Contact Cisco