Re: [j-nsp] igmp snooping layer 2 querier breaks ospf in other devices
I thought this was asked, but don’t recall an answer, what’s the point of turning on a querier if the switch is already a PIM router? You don’t need an IGMP snooping querier if it’s a multicast router. On Fri, Feb 2, 2024 at 8:21 AM Aaron Gould via juniper-nsp < juniper-nsp@puck.nether.net> wrote: > I tried to recreate the scenario in my lab with no success > > 21.2R3-S4.8 - in lab - problem not seen > 20.2R3-S7.3 - in lab - problem not seen > 19.2R3-S6.1 - in lab - problem not seen > 18.3R3-S6.1 - in lab - problem not seen > 17.4R2-S11 - in lab - problem not seen > > 17.4R2-S11 - in field - problem seen > > > again, the problem is, when i enabled this command... > > set protocols igmp-snooping vlan vlan100 l2-querier source-address > 10.100.4.1 > > ...a customer riding an l2circuit on ge-0/0/2 report to me that their > multicast stops working... ospf goes down and stays in INIT... > > when i remove all pim and igmp, then there OSPF neighbors up and stabilizes > > i just don't know how running igmp inside vlan 100 with ports ge-0/0/4, > 5 and 6 would have anything to do with an l2circuit on ge-0/0/2 > > > -Aaron > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX304 - Edge Router
I think the key here is that the OP had evaluation licenses. Those are timed and things stop working when they expire. Purchased license are permanent and do not expire. On Wed, Oct 25, 2023 at 6:18 AM Mark Tinka via juniper-nsp < juniper-nsp@puck.nether.net> wrote: > > > On 10/25/23 14:42, Saku Ytti via juniper-nsp wrote: > > > But we can reject licenses that expire in operation and cause an > > outage. That I think is a very reasonable ask. I know that IOS XE for > > example will do this, you run out of license and your box breaks. I > > swapped out from CRS1k to ASR1k because I knew the organisation would > > eventually fail to fix the license ahead of expiry. > > We had this happen to us in 2014 when we recovered a failed server > running CSR1000v. The "installation evaluation" license expired after 60 > days, and since everyone forgot about it, the box went down. > > So as part of our deployment/recovery procedure, we always procure > CSR1000v licenses for each installation. > > Of course, with things changing to Cat8000v, this could get juicy. > > > > I'm happy if the device calls homes via https proxy, and reports my > > license use, and the sales droid tells me I'm not compliant with > > terms. Making it a commercial problem is fine, making it an acute > > technical problem is not. > > > > > > In your specific case, the ports never worked, you had to procure a > > license, and the license never dies. So from my POV, this is fine. And > > being absolutist here will not help, as then you can't even achieve > > reasonable compromise. > > I tend to agree. > > Mark. > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...
I find it kind of telling that customers are just getting around to
complaining about it two years after it was released. Not at all
surprising, but illustrates how slow network operators update cycles can be
compared to the pace of development.
To the Junos developers, this is ancient news, long forgotten in the dozens
of sprints and multiple releases since.
On Wed, Jul 12, 2023 at 2:13 PM Andrey Kostin via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hi Mark,
> 100% agree if it could help.
> Very annoying. If UX designer touched it, he or she probably never
> actually worked with Junos.
>
> Kind regards,
> Andrey
>
> Mark Tinka via juniper-nsp писал(а) 2023-07-12 04:49:
> > So, this is going to be a very priviledged post, and I have been
> > spending the last several months mulling over even complaining about
> > it either on here, or with my SE.
> >
> > But a community friend sent me the exact same annoyance he is having
> > with Junos 21 or later, which has given me a final reason to just go
> > ahead and moan about it:
> >
> > tinka@router> show rout
> > ^
> > 'rout' is ambiguous.
> > Possible completions:
> > routeShow routing table information
> > routing Show routing information
> > {master}
> > tinka@router>
> >
> > I'm going to send this to my Juniper SE and AM. Not sure what they'll
> > make of it, as it is a rather priviledged complaint - but in truth, it
> > does make working with Junos on a fairly historically commonly used
> > command rather cumbersome, and annoying.
> >
> > The smile that comes to my face when I touch a box running Junos 20 or
> > earlier and run this specific command, is unconscionably satisfying
> > :-).
> >
> > Mark.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Advertising inactive routes to iBGP neighbors
I don't quite understand. Why don't you just export the static into your routing protocol? How is the static route a "fallback" if it is really the active route? On Sun, Apr 17, 2022 at 8:57 AM James via juniper-nsp < juniper-nsp@puck.nether.net> wrote: > > > > -- Forwarded message -- > From: James > To: juniper-nsp@puck.nether.net > Cc: > Bcc: > Date: Sun, 17 Apr 2022 10:49:44 -0500 > Subject: Advertising inactive routes to iBGP neighbors > Hi all, > > I have two routes in inet.0, neither of which come from BGP: > > 10.200.7.2/32 *[Static/5] 00:14:40 > > to 10.200.7.2 via irb.102 > [EVPN/7] 00:08:25 > > via irb.102 > > I want to advertise the 'EVPN/7' route, either alongside or completely in > place > of the 'Static/5' route. The particular use case here is EVPN-VXLAN virtual > machine traffic optimization, where I want to advertise the EVPN route > with a > higher localpref to steer traffic towards one or more particular leaf > switches > while still advertising the static route as a fallback in case the EVPN > route > is not there. Normally this works because the attached prefixes are longer > than > a /32, but I just can't seem to figure out how to make this work with /32 > statically routed prefixes. > > I've already tried several methods including rib-groups to bring the route > into > another table (no support for rib-groups with EVPN routes), bgp add-path > (doesn't advertise the second path), and playing with route preferences > (static route needs to be the active route for forwarding purposes), but > none > of those have been successful. > > Any other suggestions on how I could achieve this? > > Thanks, > James > > > > -- Forwarded message -- > From: James via juniper-nsp > To: juniper-nsp@puck.nether.net > Cc: > Bcc: > Date: Sun, 17 Apr 2022 10:49:44 -0500 > Subject: [j-nsp] Advertising inactive routes to iBGP neighbors > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
