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@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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
