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.vitkov...@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:kr...@smartcom.bg] > Sent: 01 April 2015 10:42 > To: Adam Vitkovsky > Cc: juniper-nsp@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.vitkov...@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@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 > ------------------------------ > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp