[j-nsp] RFC3107 to LDP stitching
Krasimir Avramski
krasi at smartcom.bg
Fri Apr 3 10:40:31 EDT 2015
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
> ------------------------------
>
More information about the juniper-nsp
mailing list