cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1796
Views
0
Helpful
9
Replies

BGP not installing routes into routing table on MPLS over GRE network

CRAIG NORBORG
Level 1
Level 1

I have a lab set up to test a new network design where we want to be able to keep virtual networks separate across WAN links.   So, I've set up a MGRE tunnel encrypted with IPSEC for securing the traffic, there is only one remote site at this time.   Over these MGRE tunnels I'm running MPLS, which is also running in our core.  So we're essentially trying to extend the VRF's in our core out to the remote sites.

Between the Hub router and the remote I'm running eBGP and everything seems to be working correctly.   I have multiple VRF's on either side and loopbacks configured up in the VRF's and I can ping remote loopbacks if I originate the ping in the correct VRF and such.

The problem is that I'm trying to connect the hub to a Nexus 7K via iBGP, which has the same VRF's and get everything working from it.   This is where it fails.   I can see the routes in the BGP table, but they're flagged as invalid and won't install into the routing tables on the Nexus.

I'm trying to figure out why this is and remedy it, but its not working.   The topology is quite simple.  Nexus is connected to Hub router (ISR4451 via iBGP) and Hub is connected to Remote (ISR4451 via eBGP).   

192.168.10.100 is the loopback on the Hub router, which I can ping from the Nexus.  192.168.20./24 is a network simulated by a loopback on the Remote router.

sh ip bgp vrf vrf-1 192.168.20./24
BGP routing table information for VRF vrf-1, address family IPv4 Unicast
BGP routing table entry for 192.168.20./24, version 171
Paths: (1 available, best #0)
Flags: (0x080002) on xmit-list, is not in urib, is not in HW,
vpn: version 534, (0x100002) on xmit-list
Multipath: iBGP

Path type: internal, path is invalid(rnh unreachable), imported same remote RD, no labeled nexthop
AS-Path: 65100 , path sourced external to AS
192.168.10.100 (metric 0) from 192.168.10.100 (192.168.10.100)
Origin IGP, MED 0, localpref 100, weight 0
Received label 62
Extcommunity:
RT:65000:1

VRF advertise information:

VPN AF advertise information:

Cisco seems stumped, any ideas or suggestions what to look for?

9 Replies 9

Hello,

hard to say without seeing the configurations, can you post those ?

Do you have a router id specified for each VRF ?

I'll have to sanitize them.  Even though this is a testbed, its mimicking the configs of a gov't production system.

No, I don't have a router ID specified for each VRF.  I didn't think I'd need to since there isn't really any routing happening on each VRF?   I thought it was basically one main BGP routing table for all the MPLS collectively.     Should I be doing that and what would I use for the router ID for each VRF, would they all be the same?

Hi,

Can you share configuration, please?

Regards,
Deepak Kumar,
Don't forget to vote and accept the solution if this comment will help you!

Sorry for the delay

 

We have two Nexus 7000 switches in a HA pair – each connected to a WAN router.  BGP is between the two Nexus 7000 switches (iBGP) and the two WAN routers (eBGP).

 

Please note that this configuration works perfectly under version 7.2(0) (and previous versions such as 6.2(16))

 

Configuration on the Nexus 7000 switches is :-

 

router bgp xxASxx

  template peer ebgp-template

    bfd

    remote-as xR-ASx

    timers 10 30

    address-family ipv4 unicast

      prefix-list pl-bgp-xxx-vrf in

  template peer ibgp-template

    bfd

    remote-as xxASxx

    timers 10 30

    address-family ipv4 unicast

  vrf xxx-vrf

    router-id xx.xx.1.6                                                   <<<< xx.xx.1.10 on other Nexus 7000 switch

    timers bgp 10 30

    log-neighbor-changes

    address-family ipv4 unicast

      redistribute ospf 1 route-map rm ospf-into-bgp

      aggregate-address xx.xx.0.0/16 summary-only

      max-paths 2

    neighbor xx.xx.0.4                                                      <<<<< xx.xx.0.3 on other Nexus 7000 switch

      inherit peer ibgp-template

      password xxxxxxx

      update-source Loopback0                                       <<< xx.xx.0.3/32 on this switch – xx.xx.0.4 on other switch

    neighbour xx.xx.1.5                                                     <<<< xx.xx.1.9 on other Nexus 7000 switch

      inherit peer ebgp-tempate

      password xxxxxxx

      address-family ipv4 unicast

        no prefix-list pl-bgp-xxx-vrf-in

 

 

 

Switch1#show ip bgp vrf xxx-vrf 0.0.0.0

BGP routing table information for VRF xxx-vrf, address family IPv4 Unicast

BGP routing table entry for 0.0.0.0/0, version 72

Paths: (2 available, best #2)

Flags: (0x8800001a) on xmit-list, is in urib, is best urib route, is in HW,             <<<< is in HW is new in version 7.3

Multipath: eBGP

 

  Path type: internal, path is invalid(rnh unreachable), no labeled nexthop

  AS-Path: xR-ASx , path sourced external to AS

    xx.xx.1.9 (metric 0) from xx.xx.0.4 (xx.xx.1.10)

      Origin IGP, MED not set, localpref 100, weight 0

 

  Advertised path-id 1

  Path type: external, path is valid, is best path

  AS-Path: xR-ASx , path sourced external to AS

    xx.xx.1.5 (metric 0) from xx.xx.1.5 (xx.yy.yy.yy)

      Origin IGP, MED not set, localpref 100, weight 0

 

  Path-id #1 advertised to peers:

    xx.xx.0.4

 

 

Switch2#show ip bgp vrf xxx-vrf 0.0.0.0

BGP routing table information for VRF xxx-vrf, address family IPv4 Unicast

BGP routing table entry for 0.0.0.0/0, version 66

Paths: (2 available, best #2)

Flags: (0x8800001a) on xmit-list, is in urib, is best urib route, is in HW,             <<<< is in HW is new in version 7.3

Multipath: eBGP

 

  Path type: internal, path is valid, not best reason: Internal path

  AS-Path: xR-ASx , path sourced external to AS

    xx.xx.1.5 (metric 1) from xx.xx.0.3 (xx.xx.1.6)

      Origin IGP, MED not set, localpref 100, weight 0

 

  Advertised path-id 1

  Path type: external, path is valid, is best path

  AS-Path: xR-ASx , path sourced external to AS

    xx.xx.1.9 (metric 0) from xx.xx.1.9 (xx.yy.yy.yy)

      Origin IGP, MED not set, localpref 100, weight 0

 

   Path-id #1 advertised to peers:

    xx.xx.0.3

 

 

Neither default route is being redistributed into OSPF

TheLaw
Level 1
Level 1

I have the same error - path invalid(rnh unreachable).

I had a working BGP configuration in 7.2.  I upgraded to 7.3 (ISSU - exactly the same configuration) and the error occurs.

Hi @TheLaw 

Check for bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCul52450/?rfs=iqvred

If everything configured properly. 

Regards,
Deepak Kumar,
Don't forget to vote and accept the solution if this comment will help you!

The bug listed is reported fixed in 6.2(9).  I am running 7.3(4).

We have completed reloads and no change.

I have taken another look and found that under 6.2(16) and 7.2(0) there was always one of the two switches in the HA pair that had an invalid route - and it is only in 7.3(4) that it reports that invalid route as rnh unreachable.  So this error may not be indicitive of the issue I am experiencing - which is the BGP default route is not being propogated into OSPF in 7.3(4) but is when running previous versions.

Hello

as this nexus is a ibgp peer then that received prefix could be seeing the next-hop in the route as the advertised  ebgp rtr and not it’s ibgp peer and as it doesn’t have reachability to the next hop it’s unreachable thus doesn’t get enters in it own rib

 

On the evgp/ibgp rtr - do you have next-hop-self applied towards the nxos ibgp peer


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco