[j-nsp] RFC3107 to LDP stitching
Adam Vitkovsky
Adam.Vitkovsky at gamma.co.uk
Tue Apr 7 02:49:14 EDT 2015
Hello Krasimir,
I was also labbing :) and you are right indeed.
Since LSPs are unidirectional I need to be looking at both LSPs i.e from remote AS to local AS and vice versa.
And cmd: “set protocols bgp group nni-opt-c family inet labeled-unicast per-prefix-label”
-only creates label mapping for BGP-LU label that remote AS ASBR advertised for remote AS PE loopback with LDP label that local AS ASBR allocated for this prefix.
And cmd: “set protocols mpls traffic-engineering bgp-igp-both-ribs” or cmd: “set protocols mpls traffic-engineering mpls-forwarding”
-actually creates the stitching on ASBR between the locally generated BGP-LU label and LDP label allocated by P router for loopback of PE in local AS.
-without this cmd the locally generated BGP-LU label points to POP operation (instead of SWAP for next-hop label advertised by P router)
Interesting is that for loopback of local AS PE there is also a locally generated LDP label mapped to an LDP label allocated by P router
So it's interesting that for one FEC there can be two label mappings or operations programmed in FIB
Wondering if routers usually allocate one label for the same prefix and advertise same label to all neighbours as opposed to allocating several different labels for the same prefix/FEC depending on how many LDP neighbours there are and if it would be of any value or just a waste of FIB.
So now the only mystery is the need for explicit null label advertised by local AS ASBR (acting as PE) for its own loopback to remote AS ASBR
Without this the VPN ping doesn’t work
But it might something to do with the vrf table-label
Regarding the rib inet.3
Ok I tried the same think during the first lab session and these are my notes:
2)
set protocols bgp group nni-opt-c family inet unicast
set protocols bgp group nni-opt-c family inet labeled-unicast rib inet.3
---------------------------
able to comit
but no routes received as inet.3 => no remote AS routes in inet.3 table
all routes received as inet
ASBR LDP allocates label 3 for remote AS NHs (same label 3 as for it's own loopback)
<-- maybe try copying routes from inet.0 into inet.3 manualy similary as you copy inet.3 to inet.0 in (3)
(3) is the “labeled-unicast rib inet.3” without “unicast” and using “rib-group” to install routes from primary table inet.0 t inet.3
-have to try again but seems there where several issues with the option 2)
Thank you very much
adam
From: Krasimir Avramski [mailto:krasi at smartcom.bg]
Sent: 03 April 2015 15:41
To: Adam Vitkovsky
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] RFC3107 to LDP stitching
Hello Adam,
I don't know what sw version/platform you are using, but here is quick setup in my lab:
krasi# show protocols bgp group lu
family inet {
labeled-unicast {
per-prefix-label; <---- per-prefix enabled as per your claim this triggers stitching
}
}
export bgp-lu;
neighbor 172.16.0.2 {
peer-as 65001;
}
krasi# show protocols mpls
inactive: traffic-engineering bgp-igp-both-ribs; TE disabled
So for a PE2 router(lo0 2.2.2.2) directly connected to ASBR with AS12591:
krasi# run show route 2.2.2.2 table inet.0
2.2.2.2/32 *[OSPF/10] 00:04:28, metric 1
> to 172.16.0.9 via ge-1/0/2.300
krasi# run show route 2.2.2.2 table inet.3
2.2.2.2/32 *[LDP/9] 00:05:58, metric 1
> to 172.16.0.9 via ge-1/0/2.300, Push 0 <--- PE2 is configured with explicit-null otherwise it will request label pop(implicit label 3) since it is directly connected to ASBR
krasi# run show ldp database session 2.2.2.2
Input label database, 192.168.1.1:0--2.2.2.2:0
Label Prefix
0 2.2.2.2/32
299792 192.168.1.1/32
Now let see bgp-lu:
krasi# run show route advertising-protocol bgp 172.16.0.2 2.2.2.2 detail
* 2.2.2.2/32 (1 entry, 1 announced)
BGP group lu type External
Route Label: 299904 <---- BGP LU label advertised to neighbor ASBR
Nexthop: Self
Flags: Nexthop Change
MED: 1
AS path: [12591] I
krasi# run show route table mpls.0 label 299904
299904 *[VPN/170] 00:10:20
> to 172.16.0.9 via ge-1/0/2.300, Pop <-------- LABEL POP for label stack with S=1
299904(S=0) *[VPN/170] 00:10:20
> to 172.16.0.9 via ge-1/0/2.300, Pop <---------- LABEL POP for label stack with S=0 ( i.e. VPN transit traffic)
So, at the and of the day there is NO stitching with this configuration!!!!
Now I enable bgp-igp-both-ribs:
krasi# run show route 2.2.2.2 table inet.0
2.2.2.2/32 *[LDP/9] 00:07:47, metric 1
> to 172.16.0.9 via ge-1/0/2.300, Push 0
[OSPF/10] 00:07:47, metric 1
> to 172.16.0.9 via ge-1/0/2.300
krasi# run show route advertising-protocol bgp 172.16.0.2 2.2.2.2 detail
* 2.2.2.2/32 (2 entries, 2 announced)
BGP group lu type External
Route Label: 299920 New Label allocated and advertised
Nexthop: Self
Flags: Nexthop Change
MED: 1
AS path: [12591] I
krasi# run show route table mpls label 299920
299920 *[VPN/170] 00:02:00
> to 172.16.0.9 via ge-1/0/2.300, Swap 0 <------- LABEL SWAP and actual LDP stitching !!!
Regarding "rib inet.3" what I mean is not to use rib-group under bgp-lu, but to use both bgp families i.e.
krasi# show protocols bgp group lu
family inet {
unicast; <-------- FAMILY "inet unicast" which is regular e-bgp session AFI=1 SAFI=1
labeled-unicast { <-------- FAMILY LU AFI=1 SAFI=4
inactive: per-prefix-label; <------- NOT NEEDED
rib {
inet.3;
}
}
}
export bgp-lu;
neighbor 172.16.0.2 {
peer-as 65001;
}
krasi# show protocols mpls
inactive: traffic-engineering bgp-igp-both-ribs; TE disabled and not needed
We advertise route from the both tables inet.0 and inet.3 and that can be controlled through the bgp policy:
krasi# run show route advertising-protocol bgp 172.16.0.2 2.2.2.2 detail
inet.0: 27 destinations, 28 routes (27 active, 0 holddown, 0 hidden)
* 2.2.2.2/32 (1 entry, 1 announced)
BGP group lu type External
Nexthop: Self
MED: 1
AS path: [12591] I
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
* 2.2.2.2/32 (1 entry, 1 announced)
BGP group lu type External
Route Label: 299952
Nexthop: Self
Flags: Nexthop Change
MED: 1
AS path: [12591] I
krasi# run show route table mpls.0 label 299952
299952 *[VPN/170] 00:07:22
> to 172.16.0.9 via ge-1/0/2.300, Swap 0 <------- LSP stitching with LABEL SWAP
Best Regards,
Krasi
On 3 April 2015 at 01:26, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk> wrote:
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
________________________________________
---------------------------------------------------------------------------------------
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------
More information about the juniper-nsp
mailing list