[j-nsp] move routes from VRF to inet.0

[Bastien Pilat]

Hello,
I may have a workable solution.
As pointed by Adam, you cannot copy via rib-groups routes in VRF learned 
from mpBGP since they are already a copy of routes inside bgp.l3vpn table.
I guess you cannot copy either routes from bgp.l3vpn table into inet.0 
via rib-groups since that would copy inet-vpn family routes into a inet 
family table. Actually I didn't try, that may do the trick if JunOS is 
super-smart :) That would require putting some rib-group configuration 
on your main mpBGP session on family inet-vpn that I wouldn't dare put 
on live routers :)

The dirty trick I used is to have loopback interfaces inside the VRF on 
both PEs, and make a iBGP session inside the VRF between both PEs, and 
exchanging routes from PE2 to PE1 on this session.
This way, routes learned from PE2 on PE1 VRF are of family inet and 
considered CE routes (ie their primary table is VRF.inet.0), on top of 
it JunOS puts the correct labels (VRF-label at PE-label) on the push list 
of the routes.
You can then use your C1-internet rib-group applied on protocol BGP 
inside the VRF on PE1, this will copy BGP routes as-is into inet.0, with 
the correct label push list, so packets will end inside VRF on PE2.
You may have to prevent PE2 from advertising its routes in the normal 
way (ie in mpBGP) to prevent duplicates ans only have the iBGP ipv4 
routes on PE1.

I had this setup lab tested, seemed to work, we're gonna have it in 
production in the coming days.
This dirty BGP session from PE to PE may not be suitable for everyone, 
ofc, not the cleanest of setups :)

AFAIK, both Juniper and Redback allow these PE-to-PE BGP sessions, Cisco 
prohibits it (IOS consider CE routes must have CE-PE interfaces as 
next-hop interface)

Regards,
Bastien


Le 04/02/2014 09:47, Tobias Heister a écrit :
> Hi,
>
> Am 04.02.2014 04:25, schrieb Bikram Singh:
>>> There might be a couple of alternate solutions coming to mind:
>>> 1. move all internet Routes to the CE1 table and use static routes to point back at the VRF with next-table from inet.0 which will not really scale beyond a single l3vpn.
>>> 2. use a separate VRF for the internet routes and use auto-export, rib-groups, vrf-import/export policy to move routes around. This would need a rework of our network and is not really
>> feasible right now.
>>
>> If point 2. is not feasible then you can do below
>>
>> Since you have already put a static route from VRF pointing to inet.0 for the traffic going to internet now you need to work for reverse traffic from internetto CE1 or CE2 .
>>
>> As you have mentioned that they use Public IP in that case you can put all VPN routes (from CE1 and CE2 )  or aggregate routes into inet.0 using rib-goups to attract reverse traffic from
>> internet .
> That is actually what i am trying right now. But i am not able to put all the VPN Routes into inet.0
> I have trouble to move the ones learned from the remote PE, as i have no clue how and where to match them with a rib-groub as they are from protocol BGP and are placed there by the l3vpn
> itself. If you happen to have an example how to move the BGP routes received from the remote PE to inet.0 i would be happy if you would share it.
>
> I already have a manual aggregate route covering CE1 and CE2 prefixes in inet.0 which i am exporting into the iBGP to get the internet incoming Traffic to the PE1. What i am missing are
> routes for the remote CE/PE on PE1 inet.0 in order to direct the traffic to the remote PE (PE2/CE2).
>
> regards
> Tobias
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp