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 <bra...@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@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
