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
