[j-nsp] IS-IS POI

[James Bensley]

Hi All,

Have anyone used this feature, did it actually help you pin-point the
source of an IGP issue?

https://www.juniper.net/documentation/en_US/junos/topics/concept/isis-poi-tlv-overview.html

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/purge-originator-edit-protocols-isis.html

As always in a mixed vendor network it can only add a limited amount
of mileage as not all our other vendors support it but, that is where
the "empty" knob could help.

Cheers,
James.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Saku Ytti]

Hey James,

Post by James Bensley
Have anyone used this feature, did it actually help you pin-point the
source of an IGP issue?

I doubt many people have ever encountered the problem.

The problem is rogue or misconfigured ISIS speaker with duplicate
address. This ISIS speaker can re-advertise every LSP with superior
SEQ or even MAX_SEQ.

Outcome of rogue ISIS speaker advertising MAX_SEQ is that you need to
first remove the rogue speaker and then reload whole network
simultaneously or renumber every ISIS speaker. If you reload all
network except one, whole network will relearn the bad information
from the remaining speaker once it comes up.

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.

[Pierre Emeriaud]

Post by Saku Ytti
Hey James,

Post by James Bensley
Have anyone used this feature, did it actually help you pin-point the
source of an IGP issue?

I doubt many people have ever encountered the problem.
The problem is rogue or misconfigured ISIS speaker with duplicate
address. This ISIS speaker can re-advertise every LSP with superior
SEQ or even MAX_SEQ.

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.

Post by Saku Ytti
Outcome of rogue ISIS speaker advertising MAX_SEQ is that you need to
first remove the rogue speaker and then reload whole network
simultaneously or renumber every ISIS speaker. If you reload all
network except one, whole network will relearn the bad information
from the remaining speaker once it comes up.
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.

Yes. I really want to never need such a feature, but as this scenario
is what our ops nightmares are fueled with, I asked for some more
monitoring of purge messages, so as updates per seconds and some other
metrics.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.

[James Bensley]

Post by Saku Ytti
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.

Post by Saku Ytti
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.

Post by Saku Ytti
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 juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Clinton Work]

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.

Post by James Bensley
Have anyone used this feature, did it actually help you pin-point the
source of an IGP issue?
https://www.juniper.net/documentation/en_US/junos/topics/concept/isis-poi-tlv-overview.html
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/purge-originator-edit-protocols-isis.html
As always in a mixed vendor network it can only add a limited amount
of mileage as not all our other vendors support it but, that is where
the "empty" knob could help.

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Saku Ytti]

Hey Clinton,

Have you since deployed MD5?

Post by Clinton Work
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.

Post by James Bensley
Have anyone used this feature, did it actually help you pin-point the
source of an IGP issue?
https://www.juniper.net/documentation/en_US/junos/topics/concept/isis-poi-tlv-overview.html
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/purge-originator-edit-protocols-isis.html
As always in a mixed vendor network it can only add a limited amount
of mileage as not all our other vendors support it but, that is where
the "empty" knob could help.

_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp