[j-nsp] RFC3107 to LDP stitching

[Adam Vitkovsky]

Hi Krasimir,

Thank you for the response

Well I was applying the config in steps and when the cmd:  "set protocols bgp group nni-opt-c family inet labeled-unicast per-prefix-label"
- is enabled it appears that it already creates a working LSP on its own, i.e ASBR in local AS allocates unique label for loopback IP address of a PE in local AS and advertises it to ASBR in remote AS via BGP-LU.
- the ASBR also creates a swap operation for the BGP-LU label to LDP label for the loopback IP address of a PE in local AS.
However the VPN ping from PE in local AS to PE in remote AS was not working. 
Only when "set protocols mpls traffic-engineering bgp-igp-both-ribs" is added VPN ping starts working. 
Hence my question what did the command "bgp-igp-both-ribs" do if the LSP was there already. 
ASBR also allocates label 3 for its own loopback and advertises it to remote AS ASBR. 

Regarding  the " labeled-unicast rib inet.3":
set routing-options rib-groups export-inet0 import-rib inet.3  <--primary table where routes are to be installed
set routing-options rib-groups export-inet0 import-rib inet.0  <--secondary tabel where routes are to be installed
set protocols bgp group nni-opt-c family inet labeled-unicast rib-group export-inet0 <-- to get routes from inet.3 into inet.0 so that ISIS and LDP can disseminate them in local AS
set protocols bgp group nni-opt-c family inet labeled-unicast rib inet.3 <-- to install the labeled prefixes received from remote ASBR in remote AS into inet.3 and to stitch them to LDP labels
- so manually copying routes from inet.3 to inet.0
- it also does the LSP stitching so remote AS NHs or received routes have their rfc3107 assigned label stitched to LDP label - where the LDP label was assigned to the prefixes once leaked into inet.0
- problem is that only routes in inet.3 are advertised from local AS ASBR to ASBR in remote AS because inet.3  is the primary table for the SAFI 3 -so RR loopbacks are missing i.e. those are not part of inet.3 thus not advertised to remote AS.
- don't know how to fix this



adam
From: Krasimir Avramski [mailto:krasi at smartcom.bg] 
Sent: 01 April 2015 10:42
To: Adam Vitkovsky
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] RFC3107 to LDP stitching

Hi Adam,

Yes, bgp-igp-both-ribs is needed for transport LSP stitching on ASBRs. BGP-LU works as follow:
If the route has label then select new label and perform swap. 
If there is no label then select new label and perform pop - note for the direct routes(such as loopback) implicit label 3 is used.

So, ISIS local AS PE routes are advertised and label operation POP is programmed  - this exposes traffic with vpn labels (requested by local AS PEs different from asbr ) to the ASBR itself and since such ip-vpn routes are not advertised, upon label lookup they are dropped.
When  bgp-igp-both-ribs is configured the LDP, RSVP routes are already in inet.0 so when redistributed, label operation SWAP is programmed (actual LSP transport stitch).

Personally I prefer "rib inet.3" way - this should work in case you establish both "inet" and "labeled-unicast" bgp families (actually rib inet.3 is only way to do that). This will relax the need of bgp-igp-both-ribs(when it is not desired since the change is global for the router) and resolve-vpn and through the policies you can granularly control what is advertised for data path stitching and what for control plane purposes.(plane IP).

As per local PE functionality on ASBR are you sure you properly redistributed local loopbacks through the bgp-lu - while I'm not 100% sure it should work without explicit-null .... Do you have vrf-table-label in VRF?

Regards,
Krasi

On 1 April 2015 at 01:48, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk> wrote:
Hi Folks,

So for the RFC3107 to LDP stitching if ASBR is also a PE the working config for ASBR is as follows but I'm not sure why/how it actually works.

set protocols mpls traffic-engineering bgp-igp-both-ribs
set protocols bgp group nni-opt-c family inet labeled-unicast per-prefix-label (probably optional)
set protocols bgp group nni-opt-c family inet labeled-unicast explicit-null connected-only
set protocols bgp group nni-opt-c family inet labeled-unicast resolve-vpn

Why do I need to use "bgp-igp-both-ribs" or possibly "mpls-forwarding" option (haven't tested that yet) to copy routes from inet.3 to inet.0 if I'm already using "resolve-vpn" and with "resolve-vpn" the primary table for RFC3107 routes is inet.0 and inet.0 already has the local AS PEs and RRs loopbacks in it, so those are advertised to the remote AS.
It seems like the "bgp-igp-both-ribs" is necessary for the inet.0 or I should say mpls.0 <-> RFC3107 LSP stitching but I have no idea how/why.

And also why the ASBR acting as PE won't accept packet with just the VPN label and there's this explicit-null label stack required.

The "resolve-vpn" vs "rib inet.3".
Ok so "resolve-vpn" option uses inet.0 as primary routing table and will just copy the RFC3107 labeled routes to inet.3 table.
The RFC3107 labeled routes have be placed in the inet.3 routing table so that VRF routes from remote AS have NH in inet.3 for proper NH resolution (In case the ASBR is also a PE for a vrf spanning across the ASNs).
Since inet.0 is still the primary table the remote-AS PE loopbacks can be advertised via ISIS to local AS RRs -i.e pure IP connectivity is in place so MP-eBGP can be formed.
However with "rib inet.3" the inet.3 will become the primary routing table for RFC3107 routes.
So then you need to manually leak routes from inet.3 to inet.0 using rib-groups the remote-AS prefixes (PE loopbacks) can be advertised via ISIS to RRs.
However since inet.3 is the primary table only for RFC3107 session only routes in inet.3 are advertised from local AS to the remote AS and RR loopbacks are not in inet.3 which is a show stopper unless it's somehow possible to leak routes from inet.0 to inet.3.

I'd appreciate any thoughts, ideas on how this actually works.

adam
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------


_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------