[j-nsp] MPLS L3VPNs, Route-Reflection, and SPRING with IS-IS on QFX5100
Olivier Benghozi
olivier.benghozi at wifirst.fr
Mon Jul 3 17:10:35 EDT 2017
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 <https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/mpls-configuring-the-prefixes-advertised-into-ldp-from-the-routing-table.html>
> Le 3 juil. 2017 à 20:19, Brant Ian Stevens <branto at argentiumsolutions.com> a écrit :
>
> 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.
>
More information about the juniper-nsp
mailing list