[j-nsp] MPLS L3VPNs, Route-Reflection, and SPRING with IS-IS on QFX5100

Tue Jul 4 14:02:42 EDT 2017

What are other people who are testing SPRING with multiple peering 
loopback addresses doing?

So it looks like I may be SoL right now...

from 
https://www.juniper.net/documentation/en_US/junos/topics/concept/understanding-support-for-spring-anycast-and-prefix-segments.html

Currently, Junos OS allows you to configure SPRING node SID for IPv4 and 
IPv6 address family per routing instance. This node SID is attached to 
IPv4 and IPv6 router ID if the router ID is configured on the loopback 
interface. Otherwise, the lowest IP address assigned to the loopback 
interface is chosen as the node SID. You can now configure provide 
prefix segment identifier (SID) and node SID to prefixes that are 
advertised in ISIS through policy configuration. Prefix segment index is 
the index assigned to a specific prefix. This is used by all other 
remote routers in the network to index the prefix into respective SRGB 
to derive the segment identifier and to forward the traffic destined for 
this prefix. The prefix SID supports both IPv4 and IPv6 prefixes. 
Configuring node SID through policy allows you to choose the loopback 
address that gets the node SID.

Instead of LDP, I added some RSVP configuration, and boom...  l3vpn 
connectivity works.  I'll keep an eye out for updates to the code.

-- 
Regards,
--
Brant I. Stevens, Principal & Consulting Architect
branto at argentiumsolutions.com
d:212.931.8566, x101. m:917.673.6536. f:917.525.4759.
http://argentiumsolutions.com

> Olivier Benghozi <mailto:olivier.benghozi at wifirst.fr>
> July 3, 2017 at 5:10 PM
> By default JunOS will create a label for the primary loopback address 
> (as told in "MPLS in the SDN Era", page 172). So, here, by default, 
> the first one.
> If you wan a label for the "242" IP only: invert both loopback IPs in 
> the conf, or declare the second one as primary.
>
> But if you need a label for both IPs, attach an "egress-policy" to 
> protocol ldp matching those 2 IPs (maybe using route-filter, or a 
> prefix-list, of whatever):
>
> https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/mpls-configuring-the-prefixes-advertised-into-ldp-from-the-routing-table.html
>
>
> Brant Ian Stevens <mailto:branto at argentiumsolutions.com>
> July 3, 2017 at 2:19 PM
>
> I posted to the Juniper Forums, but figured I should try here as well:
>
> Hello All,
>
> I am attempting to build a network with the captioned technologies, 
> and am most of the way there, but am running into an issue.
>
> We want to use a separate loopback address for our MP-BGP peering 
> sessions in support of the MPLS VPNs address family, but the 
> "secondary" address on the loopback interface does not get a label 
> assigned to it in the IS-IS database.  The addresses in the 
> 10.242.0.0/24 range are the inet-vpn loopback sources, while the 
> addresses in the 100.64.0.0/24 range are the loopback ranges that are 
> used for inet-labeledunicast.
>
>
> branto at peer-rtr-01# show interfaces lo0
> unit 0 {
> family inet {
> address 100.64.0.7/32; This address is assigned a label.
> address 10.242.0.7/32; This address does NOT get assigned a label.
> }
> family iso {
> address 49.0000.0100.0064.0007.00;
> }
> family mpls;
> }
> unit 4000 {
> family inet {
> address 10.240.0.7/32;
> }
> }
>
> branto at peer-rtr-01# run show route 10.242.0.0/24
>
> inet.0: 38 destinations, 41 routes (38 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 10.242.0.1/32 *[IS-IS/18] 22:15:08, metric 25
> > to 100.64.1.6 via et-0/0/48.0
> 10.242.0.3/32 *[IS-IS/18] 22:15:08, metric 50
> > to 100.64.1.6 via et-0/0/48.0
> *10.242.0.5/32 *[IS-IS/18] 22:15:08, metric 50*
> *> to 100.64.1.6 via et-0/0/48.0*
> 10.242.0.7/32 *[Direct/0] 22:46:30
> > via lo0.0
>
> branto at peer-rtr-01# run show route 100.64.0.0/24
>
> inet.0: 38 destinations, 41 routes (38 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 100.64.0.1/32 *[L-ISIS/14] 22:15:30, metric 25
> > to 100.64.1.6 via et-0/0/48.0
> [IS-IS/18] 22:15:30, metric 25
> > to 100.64.1.6 via et-0/0/48.0
> 100.64.0.3/32 *[L-ISIS/14] 22:15:30, metric 50
> > to 100.64.1.6 via et-0/0/48.0, Push 19
> [IS-IS/18] 22:15:30, metric 50
> > to 100.64.1.6 via et-0/0/48.0
> *100.64.0.5/32 *[L-ISIS/14] 22:15:30, metric 50*
> *> to 100.64.1.6 via et-0/0/48.0, Push 21*
> *[IS-IS/18] 22:15:30, metric 50*
> *> to 100.64.1.6 via et-0/0/48.0*
> 100.64.0.7/32 *[Direct/0] 22:46:52
> > via lo0.0
>
> inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
>
> 100.64.0.1/32 *[L-ISIS/14] 22:15:30, metric 25
> > to 100.64.1.6 via et-0/0/48.0
> 100.64.0.3/32 *[L-ISIS/14] 22:15:30, metric 50
> > to 100.64.1.6 via et-0/0/48.0, Push 19
> *100.64.0.5/32 *[L-ISIS/14] 22:15:30, metric 50*
> *> to 100.64.1.6 via et-0/0/48.0, Push 21*
>
> {master:0}[edit]
> branto at peer-rtr-01#
>
> The VPN routes are reflected across the network properly and received, 
> but the next-hop is unusable.
>
> branto at peer-rtr-01# run show route protocol bgp hidden table 
> bgp.l3vpn.0 extensive
>
> bgp.l3vpn.0: 2 destinations, 2 routes (0 active, 0 holddown, 2 hidden)
> 10.242.0.5:1:10.240.0.5/32 (1 entry, 0 announced)
> BGP Preference: 170/-101
> Route Distinguisher: 10.242.0.5:1
> Next hop type: Unusable, Next hop index: 0
> Address: 0xa2f1744
> Next-hop reference count: 4
> State: <Hidden Int Ext ProtectionPath ProtectionCand>
> Local AS: 29749 Peer AS: 29749
> Age: 22:27:35
> Validation State: unverified
> Task: BGP_29749.10.242.0.1
> AS path: I (Originator)
> Cluster list: 10.242.0.1
> Originator ID: 100.64.0.5
> Communities: target:29749:5
> Import Accepted
> VPN Label: 4114
> Localpref: 100
> Router ID: 100.64.0.1
> Secondary Tables: sinewave-mgmt.inet.0
> Indirect next hops: 1
> Protocol next hop: 10.242.0.5
> Label operation: Push 4114
> Label TTL action: prop-ttl
> Load balance label: Label 4114: None;
> Indirect next hop: 0x0 - INH Session ID: 0x0
>
>
>  Here's my IS-IS config from the routers in question:
>
> PE Router 1:
> branto at peer-rtr-01# show protocols isis
> reference-bandwidth 1000g;
> traffic-engineering {
> family inet {
> shortcuts;
> }
> family inet6 {
> shortcuts;
> }
> family inet-mpls {
> shortcuts;
> }
> }
> source-packet-routing {
> node-segment {
> ipv4-index 7;
> ipv6-index 607;
> }
> }
> level 1 disable;
> level 2 wide-metrics-only;
> interface et-0/0/48.0 {
> point-to-point;
> }
> interface lo0.0 {
> point-to-point;
> passive;
> }
>
> {master:0}[edit]
> branto at peer-rtr-01#
>
>
> PE Router 2:
> branto at bb-rtr-01# show protocols isis
> reference-bandwidth 1000g;
> traffic-engineering {
> family inet {
> shortcuts;
> }
> family inet6 {
> shortcuts;
> }
> family inet-mpls {
> shortcuts;
> }
> family inet6-mpls {
> shortcuts;
> }
> }
> source-packet-routing {
> node-segment {
> ipv4-index 5;
> ipv6-index 605;
> }
> }
> level 1 disable;
> level 2 wide-metrics-only;
> interface et-0/0/48.0 {
> point-to-point;
> }
> interface lo0.0 {
> point-to-point;
> passive;
> }
>
> {master:0}[edit]
> branto at bb-rtr-01#
>
> I am totally open to suggestions on how to work around this, with 
> using only one peering address being the total last resort.
>