On Fri, 28 Sep 2018 at 11:48, Saku Ytti <[email protected]> wrote: > > Hey James, > > In this failure mode this feature would help to find the rogue ISIS > speaker, so looks sensible feature to me, even when very partial > support it will limit limit the domain where the suspect exists. I've > personally not used it, and very much hope I'll never have need for > it.
Hi Saku, Yeah agreed, it's really helping only in a corner case of possible issue a network might face so I'm usually against deploying features that only work or are only used in rare corners, to reduce complexity. However, I can imagine that the time I need this feature is when everything is on fire, even the fire is on fire. On Fri, 28 Sep 2018 at 14:55, Pierre Emeriaud <[email protected]> wrote: > > a subsidiary of $work had an issue with rogue purges. But it wasn't a > rogue equipment. It was just failing in the (very) wrong way. Their > network went down for several reaaaally looong hours. ^ This is my concern, multi-vendor network, not all our vendors support this feature but "some" is better than "none" in this case I think. On Fri, 28 Sep 2018 at 16:00, Clinton Work <[email protected]> wrote: > I support a multi-vendor network with Cisco, Nokia SROS, and Juniper routers. > We've had several incidents with ISIS purge messages that were very > difficult to isolate. Every router needs to support the ISIS POI TLV if you > want to isolate the source of the ISIS purge messages which is difficult in a > multi-vendor network. The cause of the ISIS purge messages was faulty > hardware that was corrupting the ISIS LSP packets. ^ Again, not all our vendors do support it but even if only the Junipers do, we can narrow an issue down to a specific Juniper and checks it's neighborus if they are not Juniper boxes. Cheers, James. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
