[prev in list] [next in list] [prev in thread] [next in thread] 

List:       juniper-nsp
Subject:    [j-nsp] RFC3107 to LDP stitching
From:       Adam Vitkovsky <Adam.Vitkovsky () gamma ! co ! uk>
Date:       2015-03-31 22:48:46
Message-ID: 627266B72B856946BCD625D4B34B1916A4340D () INF-EXCH-MB-01 ! gammatelecom ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]