Hi, I’ve been doing some more testing with the following results:
The following configurations work: 1. family mpls is deactivated on em1 with routing-options rib inet.3 static route 0.0.0.0/0 discard configured 2. family mpls is enabled on em1 with routing-options rib inet.3 static route 0.0.0.0/0 discard and routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0 configured simultaneously 3. family mpls is enabled on em1 with routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0 configured The following configurations do not work: 4. If family mpls is enabled on em1 with routing-options rib inet.3 static route 0.0.0.0/0 discard configured 5. If family mpls is deactivated on em1 with routing-options rib inet.3 static route 0.0.0.0/0 discard and routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0 configured simultaneously 6. If family mpls is deactivated on em1 with routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0 configured So it seems based on Masik’s statement that case 5 work in 17.4, then there may be a behaviour change between 17.4 and 18.2 It seems logical to me that if case 2 works, case 5 should work as well. All that being said, I can’t seem to find any documentation on what exactly enabling family mpls on the interface does. It seems to me that it would configure the interface to accept labelled packets, but since there are no labelled packets here, family mpls does something else? > On Sep 13, 2018, at 5:57 AM, Ivan Ivanov <[email protected]> wrote: > > Hi, > > There are a few different ways to resolve the MP-BGP routes on out of band > Juniper RR. Depends on how flexible you want to be, one can use static > route in inet.3, change of the resolution or rib-groups copying the routes > form inet.0 to inet.3. > > Using the static route will work even without family mpls enabled on the > interfaces. However the other two ways require that family to be enabled on > the RR interfaces. > > Ivan, > > On Thu, Sep 13, 2018 at 10:28 AM Misak Khachatryan <[email protected]> > wrote: > >> Well i think that also a problem of copy/pasting :) >> >> Previously we had RR on a PE router and it seems i did simple copy/paste >> of relevant config. >> Can't remember any other reason to do that. >> >> But Jason has a problem having only >> >> set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0 >> >> on his VRR >> >> Best regards, >> Misak Khachatryan, >> >> On Thu, Sep 13, 2018 at 1:41 AM [email protected]<mailto: >> [email protected]> <[email protected]<mailto: >> [email protected]>> wrote: >> Hmm, these things are nasty you set them once and forget how they work :) >> >> Why to define the inet.3 table at all? I mean if you can have bgp.l3vpn.0 >> resolve directly from inet.0 (which I seem to remember it would do without >> any help anyways): >> set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0 >> >> You can then do the same for v6, just need to leak all v4 routes to >> inet6.0 (well if you're not running v6 in IGP. >> >> Oh and don't forget the FIB filter. >> >> adam >> >> netconsultings.com<http://netconsultings.com> >> ::carrier-class solutions for the telecommunications industry:: >> >>> -----Original Message----- >>> From: juniper-nsp [mailto:[email protected]<mailto: >> [email protected]>] On Behalf >>> Of Misak Khachatryan >>> Sent: Wednesday, September 12, 2018 1:02 PM >>> To: [email protected]<mailto:[email protected]> >>> Cc: [email protected]<mailto:[email protected]> >>> Subject: Re: [j-nsp] vRR/L3VPN/Unusable >>> >>> Hi, >>> >>> I run two out of band vRR with all vpn flavors and families, and don't >> need to >>> have family mpls enabled on interfaces. It's version 17.4 but i don't >> think that >>> matters. >>> >>> This should be enough: >>> >>> routing-options { >>> rib inet.3 { >>> static { >>> route 0.0.0.0/0<http://0.0.0.0/0><http://0.0.0.0/0> discard; >>> } >>> } >>> rib inet6.3 { >>> static { >>> route ::/0 discard; >>> } >>> } >>> resolution { >>> rib bgp.l3vpn.0 { >>> resolution-ribs [ inet.3 inet.0 ]; >>> } >>> } >>> } >>> >>> >>> Best regards, >>> Misak Khachatryan, >>> >>> On Wed, Sep 12, 2018 at 3:51 PM Jason Lixfeld <jason- >>> [email protected]<mailto:[email protected]><mailto:[email protected] >> <mailto:[email protected]>>> wrote: >>> Hi Ivan, >>> >>> I did not, and that did indeed fix it. I don’t understand why it’s >> necessary so >>> that’ll be my next read. >>> >>> Thanks! >>> >>>> On Sep 12, 2018, at 7:22 AM, Ivan Ivanov >>> <[email protected]<mailto:[email protected]><mailto: >> [email protected]<mailto:[email protected]>>> wrote: >>>> >>>> Hi Jason. >>>> >>>> Do you have 'family mpls' configured for the vRR interfaces? Although >> the >>> RR is out of band you need that family configured on the RR interface. >>>> >>>> Ivan, >>>> >>>> On Wed, Sep 12, 2018 at 12:10 PM Jason Lixfeld <jason- >>> [email protected]<mailto:[email protected]><mailto:[email protected] >> <mailto:[email protected]>> <mailto:jason-<mailto:jason-> >>> [email protected]<mailto:[email protected]><mailto:[email protected] >> <mailto:[email protected]>>>> wrote: >>>> Hi all, >>>> >>>> Trying to learn more about JunOS, I’m playing around with a vRR >> instance >>> (18.2R1-S1.5), and I haven’t been able to get something sorted. >>>> >>>> This vRR instance is running as an out-of-band RR for a few LDP enabled >>> PEs. vRR is not running LDP so inet.3 is empty, but as far as I >> understand, any >>> one of the two routing-options knobs configured below should be enough to >>> provide for the prefixes in bgp.l3vpn.0 to be able to resolve their >> respective >>> next-hops and bring the routes in the table out of hidden to active. >> However >>> that’s not happening. >>>> >>>> jlixfeld@rr01# show routing-options | display set | match rib set >>>> routing-options rib inet.3 static route 0.0.0.0/0<http://0.0.0.0/0>< >> http://0.0.0.0/0> >>>> <http://0.0.0.0/0> discard set routing-options resolution rib >>>> bgp.l3vpn.0 resolution-ribs inet.0 >>>> >>>> [edit] >>>> jlixfeld@rr01# run show route table bgp.l3vpn.0 >>>> 9.9.9.9/32<http://9.9.9.9/32><http://9.9.9.9/32> <http://9.9.9.9/32> >> detail hidden >>>> >>>> bgp.l3vpn.0: 29 destinations, 49 routes (0 active, 0 holddown, 49 >>>> hidden) 12345:4:9.9.9.9/32<http://9.9.9.9/32><http://9.9.9.9/32> < >> http://9.9.9.9/32> (1 entry, >>> 0 announced) >>>> BGP Preference: 170/-391 >>>> Route Distinguisher: 12345:4 >>>> Next hop type: Unusable, Next hop index: 0 >>>> Address: 0x27b17bc >>>> Next-hop reference count: 53 >>>> State: <Hidden Int Ext ProtectionPath ProtectionCand> >>>> Local AS: 12345 Peer AS: 12345 >>>> Age: 1:52:31 Metric: 0 >>>> Validation State: unverified >>>> Task: BGP_12345.10.15.48.11+179 >>>> AS path: 11670 ? >>>> Communities: 12345:2000 12345:2010 target:12345:4 >>>> Accepted >>>> VPN Label: 217 >>>> Localpref: 390 >>>> Router ID: 10.15.48.11 >>>> >>>> [edit] >>>> jlixfeld@rr01# run show route table inet.0 10.15.48.11 >>>> >>>> inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) >>>> + = Active Route, - = Last Active, * = Both >>>> >>>> 10.15.48.11/32<http://10.15.48.11/32><http://10.15.48.11/32> < >> http://10.15.48.11/32> *[IS- >>> IS/18] 01:51:14, metric 30 >>>>> to 10.15.49.67 via em1.0 >>>> >>>> [edit] >>>> jlixfeld@rr01# >>>> >>>> Is there something less obvious that needs to happen before one of >> those >>> two knobs above will work? >>>> >>>> FWIW, I haven’t played around with enabling LDP here, or configuring >> RIB >>> groups because I’m not really interested in exploring those as solutions >> if I >>> can help it; they seem a little too heavy handed when the aforementioned >>> two knobs should probably work fine? >>>> >>>> Thanks in advance! >>>> _______________________________________________ >>>> juniper-nsp mailing list >>>> [email protected]<mailto:[email protected] >>> <mailto:[email protected]<mailto:[email protected]>> >>>> <mailto:[email protected]<mailto:[email protected] >>> <mailto:juniper-<mailto:juniper-> >>> [email protected]<mailto:[email protected]> >>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>>> <https://puck.nether.net/mailman/listinfo/juniper-nsp> >>>> >>>> >>>> -- >>>> Best Regards! >>>> >>>> Ivan Ivanov >>> >>> _______________________________________________ >>> juniper-nsp mailing list [email protected]<mailto: >> [email protected]><mailto:juniper-<mailto:juniper-> >>> [email protected]<mailto:[email protected]>> >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> _______________________________________________ >>> juniper-nsp mailing list [email protected]<mailto: >> [email protected]> >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> _______________________________________________ >> juniper-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > > -- > Best Regards! > > Ivan Ivanov > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
