May be a silly question, but I am wondering what is the explicit difference between having a bgp session within a VRF and having one within the global inet.0?
if you have two routers A and B , A is connected to B in a VRF .
IF you want to run BGP between A and B , you need to configure BGP inside VRF of B ( typical CE -PE usecase in l3vpn scenerio) and for A we need to configure BGP normal as there is no VRF in A .
Not all BGP address families are supported inside VRF.
You can check the difference Yourself on the JUNOS box with
set routing-instances BLAH protocols bgp group blah family ?set protocols bgp group blah family ?
So in a L3VPN scenario where there is a CE1 -> PE1 -> P -> PE2 -> CE2.
Assume the following:
1. I have a complete IBGP mesh in the core network (with RR's)
2. I have RSVP signalling with LSPs build across the network between sites
I would use EBGP between CE1 -> PE1 (within a VRF, called vpn) - this would share CE routes to the vpn.inet.0 table?
My IBGP full mesh between my PE routers would mean that my BGP next hop to route to PE2 would be resolved via inet.3?
Because i would of added an RD and an RT within my VRF on PE1, i would then import those onto PE2?
Final question, would there ever be a scenario where you would have an IBGP peering configured within the VRF between PE's?
To answer your questions:
1) That is correct, the inet-vpn routes can only be resolved in inet.3. 2) Yes, the receiving side knows which routing table (which VRF or VRFs) the route needs to be installed in based on the route target attached to the route. The receiving side will have either vrf-target, vrf-target import, or vrf-import to define the matching criteria. 3) You would not have a BGP session within the VRF between the PE routers.
Configuration wise, other than the fact the one for the VRF is configured under the routing instance, there is no difference.
However, as someone already mentioned, the BGP session under the VRF can only be configured with families such inet unicast, or inet6 unicast, not family inet-vpn for instance. Also the routes installed in inet.0 vs the ones installed in a VRF are advertised differently to other routers.
Consider the topology in the diagram (assume default BGP policies are used)
R2 advertises a route for 10.1/16 to RA. Because the BGP session btween R2 and RA is configured outside any routing instance, the route is installed in inet.0 and can be advertised to other neighbors also with sessions outside the routing instance. Thus the route is sent to R1 and RB, and then RB advertises it to R5. This route is a family inet route (plain IPv4 route) and it advertised as so all the way across.
Now, between RA and RB the BGP session also carries family inet-vpn, to advertise routes from the VRFs. Notice that in the example there are two VRFs configured with their own route target and route-distinguisher (mandatory when you create a routing instance type vrf).
When R3 advertises a route for 16.1/16 to RA, the route is installed in VRF1.inet.0, since the BGP session is configured within that VRF. The route is then advertised to RB (and no other router connected to RA). The route is advertised to B, as a family inet-vpn route, and includes the RD and RT for VRF1. RB uses the route-target to figure out which VRF routing table to place the route on. Once the route is placed on RB's VRF1.inet.0, it can be advertised to R6.In the same way, when R4 advertises 16.1/16 to RA, the route is installed in VRF2.inet.0 advertised to RB as family inet-vpn, and then advertised from RB to R7.
In your example here: When R3 advertises a route for 16.1/16 to RA, the route is installed in VRF1.inet.0
Is this because R3 has an EBGP session to VRF1?
This was so useful and a great way to put it, thank you so much!
Yes. Because the BGP session with R3 is configured within the routing instance VRF1, any route received from R3 is placed in VRF1.inet.0. Just like any route coming from R4 goes to VRF2.inet.0 and any route from R1 and R2 goes to inet.0. The config will be something like:
user@RA# set protocol bgp group EBGP neighbor <R1>
set protocol bgp group EBGP0 neighbor <R1> ...
[edit routing-intance VRF1]
user@RA# set protocol bgp group EBGP1 neighbor <R3> ...
[edit routing-intance VRF2]
user@RA# set protocol bgp group EBGP2 neighbor <R4> ...
Glad I could help you!