[c-nsp] Route Leaking and next-hop recursion

[Julio Arruda]

Ahmed Maged (amaged) wrote:
> Hi Sami, Peter,
> 
>  
> 
> I'll try to explain this for you in simple but long words, let me know
> if that doesn't make any sense to you.
> 
>  
> 
> The packet will come in through your interface that is attached to a VRF
> and so it will lookup the VRF routing table to find a route but your
> destination is not inside the VRF, it's in the Global table so you will
> need to leak this route out.
> 
>  
> 
> Now that was for the outgoing direction, how about the incoming, it will
> come from the interface that is in global and lookup the RIB for a
> next-hop and it wont find any, why, because its in the VRF.
> 
>  
> 
> So, you will need another route to tell the router that in order to go
> to your source, you need to go into this VRF interface, and to achieve
> that you need to create a static route that point to the VRF.
> 
>  
> 
> Now if you create this static route with the next-hop being an IP
> address, the router/CEF will try to do recursion in order to find the
> outgoing interface but it wont, why, because it's attached to a VRF so
> its invisible to our global table.
> 
>  
> 
> And that's why you created a next-hop that consists of an IP and an
> interface. This way, you are bypassing the route recursion process by
> telling the router all the info it needs to find its destination and
> create the CEF adjacency (next-hop IP + interface).
> 
>  
> 
> You can see this if you do (but be careful): debug ip cef events and
> debug ip cef interface


Dumb question, if I've another route, where the next-hop is reached via 
this 'leaked+nailed-with-interface' route, would it work with a dynamic 
routing protocol ?
Example, if a BGP route announced to this VRF, had the next-hop 'field' 
== to the remote end in a p2p interface in the global table, could I add 
a static route to reach the next-hop 'via' 'static-route on global + 
interface', and this would make all routes with that next-hop received 
via BGP work ?


> 
>  
> 
> http://www.cisco.com/en/US/tech/tk827/tk831/technologies_white_paper0918
> 6a00800a62d9.shtml
> 
>  
> 
> Regards,
> 
> Ahmed
> 
>  
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Sami Joseph
> Sent: Friday, August 08, 2008 2:26 PM
> To: Peter Rathlev
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Route Leaking and next-hop recursion
> 
>  
> 
> That made it work but i need to understand the reason?
> 
>  
> 
> Sam
> 
>  
> 
> On Fri, Aug 8, 2008 at 3:05 AM, Peter Rathlev <peter at rathlev.dk> wrote:
> 
>  
> 
>> On Fri, 2008-08-08 at 00:59 +0300, Sami Joseph wrote:
> 
>> <cut>
> 
>>> *interface Vlan20*
> 
>>> *ip address 10.5.5.73 255.255.255.248*
> 
> 
>> <cut>
> 
>>> *int vlan40*
> 
>>> *ip vrf forwarding 3G*
> 
>>> *ip address 10.0.0.1 255.255.255.252*
> 
> 
>>> Then I want the routes inside this VRF to access the IP addresses
> behind
> 
>>> VLAN20 as depicted in the diagram : (1.1.1.10 and 1.1.1.11)
> 
> 
>>> So I need to do leaking from global to vrf and the path back from
> vrf to
> 
>>> global:
> 
> 
>>> *ip route vrf 3G 1.1.1.10 255.255.255.255 10.5.5.74 global*
> 
> 
>>> And: (assuming the networks on the yellow cloud are 8.8.8.0)
> 
> 
>>> *ip route 8.8.8.0 255.255.255.0 vlan40*
> 
> 
>>> This way, I guaranteed that packets destined from the VRF to global
> will
> 
>> go
> 
>>> to their next-hop which is directly connected to the switch
> (10.5.5.74)
> 
>> and
> 
>>> I suppose route recursion should be able to find where the next-hop
> is.
> 
> 
>>> When we opened a ticket for this, we were told that with this setup,
> CEF
> 
>> is
> 
>>> not going to be able to create a valid adjacency and so an arp
> request
> 
>> will
> 
>>> be sent for each packet destined to 10.5.5.74 without a reply.
> 
> 
>>> Why cant CEF install an entry for 10.5.5.74, why cant route
> recursion
> 
>> work?
> 
> 
>> Just a shot in the dark, but would it help to add an interface to the
> 
>> vrf route statement? Like this:
> 
> 
>> ip route vrf 3G 1.1.1.10 255.255.255.255 Vlan20 10.5.5.74 global
>