06-15-2017 11:47 AM - edited 03-05-2019 08:42 AM
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?
06-15-2017 01:11 PM
Hello,
hard to say without seeing the configurations, can you post those ?
Do you have a router id specified for each VRF ?
06-15-2017 01:58 PM
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?
10-03-2019 02:01 AM
Hi,
Can you share configuration, please?
10-09-2019 04:30 PM
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
10-03-2019 01:39 AM
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.
10-03-2019 01:56 AM
Hi @TheLaw
Check for bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCul52450/?rfs=iqvred
If everything configured properly.
10-09-2019 04:32 PM
The bug listed is reported fixed in 6.2(9). I am running 7.3(4).
We have completed reloads and no change.
10-09-2019 04:38 PM
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.
10-03-2019 07:10 AM - edited 10-03-2019 07:11 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide