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
bra...@argentiumsolutions.com
d:212.931.8566, x101. m:917.673.6536. f:917.525.4759.
http://argentiumsolutions.com
Olivier Benghozi <mailto:olivier.bengh...@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:bra...@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@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@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@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@peer-rtr-01#
The VPN routes are reflected across the network properly and received,
but the next-hop is unusable.
branto@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@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@peer-rtr-01#
PE Router 2:
branto@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@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.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
