Route Leaking and Next-Hop

[jmeggers]

I have two issues with BGP route leaking on NX-OS running 7.x code. This is the first time I've tried to do any serious route leaking. I'm leaking routes between VRFs on R1, and on R1 I see the subnet in the BGP table for the destination VRF.  However I see it still has a next-hop of the origin of the route, which is in the source VRF, advertised to R1. Right now my import and export route-maps only permit or deny the subnets. Do I need to apply a set parameter to change the IP next-hop to an address in the destination VRF? Otherwise, it seems like other routers receiving that route will see a next-hop they know nothing about and cannot reach. I made a quick attempt at doing that and it didn't seem to solve the problem, so I'm not sure if that's a rat hole that won't help.

Which brings me to the second issue. Right now, I see the route in the BGP table on R1, but on R1's peer (R2) I do not see the leaked route in the BGP table in the destination VRF. I looked at advertised routes for that VRF on R1, and he's not advertising it to R2. I originally thought it might be an issue with sync but it turns out sync is disabled by default in NX-OS, so there must be something else at work. Any thoughts on what I need to do differently to get that route to propagate? Is it possible it's because of the next-hop issue above, and if I fix that, it will fix propagation?

Thanks for any suggestions. I have a deadline coming up so this is somewhat time critical. 

John

[Georg Pauwen]

John,

post the config of the router, that is the best way to get the fastest answer...

[paul driver]

Hello John

I see it still has a next-hop of the origin of the route

I dont understand or visulize your topology at present however regards bgp, if route is being advertised from an ebgp peer which also has an ibgp peer, This same route will be advertised to that ibgp peer with the original next-hop of the ebgp router and the ibgp peer will not know how to reach that external next-hop.

So to negate this the ebgp/ibgp  router can be set to advertise itself as the next hop, thus the igbp peer will be able to reach it.

res
Paul

[shamax_1983]

Hi John,

Not sure you ever found managed to get this one sorted. If you didn't, following explanation may be of help.

I have done something similar to that and went through the same experience/thought-process as you did. Eventually, I managed to figure out why this is happenning.

With regards to the Next-Hop, what you see is the correct behaviour,

In case if the source prefix is a connected prefix or a redistributed prefix in the Source VRF, It will have its own IP (most likely a loopback address) as the Next-Hop. If you are sitting on the same Source PE (say PE1) and Source VRF, you will see within the BGP table the Next-Hop as 0.0.0.0 (indicating it is originated within the same PE). If you check for the same prefix (being leaked) in the Destination VRF (and if you are still in PE1) you would see exact same Next-Hop (0.0.0.0). So no issues.

I guess the confusion comes from the false belief that, the prefix being leaked into the Destination VRF (inside the PE1) will be advertised by the Destination VRF (in PE1) to all other PEs within MPLS network. In other words, you would think that, if you did the route leaking on PE1, the same route will suddenly show up on all other PEs within the MPLS network (without having to configure route-leaking on those PEs).

But what really happens is that the Destination VRF will NOT advertise the leaked prefix to the rest of the MPLS network. It will be solely used by the local PE only. If you want it to appear on any other PE (within the Destination VRF), you HAVE TO configure route-leaking on that PE as well. The actual source (say the connected SVI) may be still in the PE1 only. But if you have to make it appear on the PE2 Destination VRF, you need to configure route-leaking on PE2.

The idea is that in the global BGP table(in your MPLS network), the original source VPNV4 address (generated by PE1 within the Source VRF) will be available for anyone to import ( Regardless of which PE you are in or which VRF you want it to appear). So if you want that prefix in any other VRF (other than the source VRF - as you would normally import the specif RT attached to that VPNV4 address on to all PEs inside the Source VRF anyway) you need to import it locally into other VRFs on all required PEs.

Now, say you did the route-leaking into the Destination VRF on PE2, and the Original Source is in PE1 in the Source VRF. In this case, the next-hop for that leaked route in PE2 will (and should if you have configured the MPLS correctly) show up as the loopback address of the PE1 (which should not be part of any VRF). This is the Loop-back Address your P/PE routers are forwarding to, and probably using an IGP in the global routing table to forward traffic to, within your core MPLS infrastructure ( Basically corresponds to the outer Lable on the forwarding frame). [This happens because when you setup your PEs for the core MPLS network, you would have setup the "update-source loopback X" towards the P routers or PE routers]

And there would be a second inner-label associated with (and advertised by PE1) for that prefix so, once the frame gets there, PE1 will look at it and forward it to the Source VRF (in our example, to the corrected subnet). If you do "show ip bgp vrf <DestVRF> <prefix>", you would see this second label showing up on the output.

One more thing to take a note is that, although these leaked eBGP prefixes are not advertised to any other PE within the MPLS core (inside the Destination VRF), If you have another eBGP peering session in the same PE router, attached to the destination VRF, that leaked prefix will be advertised to that eBGP peer.

In the case where the original prefix (in PE1) was learned by an eBGP peer and that prefix is leaked into the Dest. VRF, inside both Source and Destination VRFs, the next-hop for that prefix would show up as the eBGP neigbor IP (if you check it on the PE1). In this case, if you try to resolve that next-hop from within the Destination VRF, it will fail. But if you try to forward traffic to the leaked destination it will actually work fine.

In case if you leaked the same prefix (eBGP learned prefix) on some other PE (say PE2), if you check the next-hop of that leaked route, it would show up as the loopback address of PE1.

Hope this answers all your questions.

Thanks

Shamal

[peter2727]

Hello - Thanks for a great explanation. I am wondering something along the same lines as was being originally asked...

Is it possible in the ‘destination’ VRF to modify the next-hop so that it no longer points to the PE in the ‘source’ VRF? Essentially, I would like to import prefixes from a ‘source’ VRF to a ‘destination’ VRF, but then have those prefixes point to a next-hop within that ‘destination’ VRF.

Thanks, Peter

[shamax_1983]

Hi Peter,

I believe you can do this by using "export map" inside the destination VRF.

"import map" is essentially a "route-map" applied on the imported MPLS/BGP routes. So, as you know, with a routed map, you can tweak many BGP attributes (including the next-hop). I haven't tested this myself but I am very positive that you can do this. Let me know how you go.

Thanks

Shamal