Subject: [Isis-wg] Interface loop detection in IS-IS

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 3 Apr 2008 15:36:27 +0200

Hi,

With current trend using Ethernet for backbone links and running IS-IS
(often using p2p hello) would it be not good idea to add extra level of
protection in IS-IS to detect interfaces which are looped? With
traditional serial interfaces one could force interface to go down when
a loop detected, with Ethernet this is most of the time not the case.
I've observed in personal practice that certain types of IS-IS
implementations get at least upset if they see HELLO with the same
sys-id, worst case I've seen was messed up LSDB on all routers that
share it (i.e. all level-2 routers) and some traffic was blackholed.

Simple solution to the interface loop could be adding some sort of a
cookie to hello PDU. If a router detects HELLO with its own sys-id which
also contains cookie that this router send, then it can deduce that
there is a loop on the interface and should stop further processing of
such HELLO. The cookie could be implemented either by introducing new
TLV or extending existing TLV. Taking into account that there is
currently effort to refine 3-way handshake (draft-ietf-isis-rfc3373bis),
one approach would be to add cookie field at the end of TLV #240.

Is there interest in this group to consider such functionality extention
for IS-IS? If yes, but you think TLV #240 and draft-ietf-isis-rfc3373bis
in general are wrong place for this, would it be of interest to have
separate draft for interface loop detection mechanism for IS-IS?

Cheers,
iLya
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: James Carlson <[email-masked]>
Date: Thu, 3 Apr 2008 10:57:39 -0400

> cookie to hello PDU. If a router detects HELLO with its own sys-id which

Such a cookie already exists, at least on media that have multiple
connected endpoints and MAC-layer addresses: the source MAC address
will tell you whether what you've received is one of your own messages
with a fairly high degree of confidence.

For media without MAC-layer addresses (point-to-point), the link layer
should have its own looped-back detection, but checking System ID
alone should be good enough.

The only thing I could see a cookie helping with would be a spoofed
(or manually misconfigured) source MAC address ... but it doesn't
sound like that's the concern here.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 3 Apr 2008 17:19:32 +0200

On Thu, Apr 03, 2008 at 03:36:27PM +0200, Ilya Varlashkin wrote:
| With current trend using Ethernet for backbone links and running IS-IS
| (often using p2p hello) would it be not good idea to add extra level of
| protection in IS-IS to detect interfaces which are looped? With
| traditional serial interfaces one could force interface to go down when
| a loop detected, with Ethernet this is most of the time not the case.
| I've observed in personal practice that certain types of IS-IS
| implementations get at least upset if they see HELLO with the same
| sys-id, worst case I've seen was messed up LSDB on all routers that
| share it (i.e. all level-2 routers) and some traffic was blackholed.
| Simple solution to the interface loop could be adding some sort of a
| cookie to hello PDU. If a router detects HELLO with its own sys-id which
| also contains cookie that this router send, then it can deduce that
| there is a loop on the interface and should stop further processing of
| such HELLO. The cookie could be implemented either by introducing new
| TLV or extending existing TLV. Taking into account that there is
| currently effort to refine 3-way handshake (draft-ietf-isis-rfc3373bis),
| one approach would be to add cookie field at the end of TLV #240.
| 
| Is there interest in this group to consider such functionality extention
| for IS-IS? If yes, but you think TLV #240 and draft-ietf-isis-rfc3373bis
| in general are wrong place for this, would it be of interest to have
| separate draft for interface loop detection mechanism for IS-IS?

ilya,

can you explain why matching our own sysid against the sysid in the IIH
(and subsequent discard of such PDUs) is not sufficient for loop prevention ?

/hannes

---

From: "Parker, Jeff" <[email-masked]>
Date: Thu, 3 Apr 2008 11:56:01 -0400

I assume this is to distinguish between the case of a duplicate SysID and the case of a looped interface.

- jeff parker
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hannes Gredler [[email-masked]]
Sent: Thursday, April 03, 2008 11:19 AM
To: Ilya Varlashkin
Cc: IETF IS-IS
Subject: Re: [Isis-wg] Interface loop detection in IS-IS

ilya,

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 3 Apr 2008 18:10:57 +0200

well, whats the point distinguishing those two cases ?
the ultimate action -> "log and discard" is the same.

for troubleshooting purposes looking at the contents
(extended local circuit-id!) and length of TLV #240,
should provide enough information to distinguish between
the two.

/hannes

On Thu, Apr 03, 2008 at 11:56:01AM -0400, Parker, Jeff wrote:
| I assume this is to distinguish between the case of a duplicate SysID
| and the case of a looped interface.
| 
| - jeff parker
| ________________________________________
| From: Hannes Gredler [[email-masked]]
| Sent: Thursday, April 03, 2008 11:19 AM
| To: Ilya Varlashkin
| Cc: IETF IS-IS
| Subject: Re: [Isis-wg] Interface loop detection in IS-IS
| 
| On Thu, Apr 03, 2008 at 03:36:27PM +0200, Ilya Varlashkin wrote:
| | With current trend using Ethernet for backbone links and running IS-IS
| | (often using p2p hello) would it be not good idea to add extra level of
| | protection in IS-IS to detect interfaces which are looped? With
| | traditional serial interfaces one could force interface to go down when
| | a loop detected, with Ethernet this is most of the time not the case.
| | I've observed in personal practice that certain types of IS-IS
| | implementations get at least upset if they see HELLO with the same
| | sys-id, worst case I've seen was messed up LSDB on all routers that
| | share it (i.e. all level-2 routers) and some traffic was blackholed.
| | Simple solution to the interface loop could be adding some sort of a
| | cookie to hello PDU. If a router detects HELLO with its own sys-id which
| | also contains cookie that this router send, then it can deduce that
| | there is a loop on the interface and should stop further processing of
| | such HELLO. The cookie could be implemented either by introducing new
| | TLV or extending existing TLV. Taking into account that there is
| | currently effort to refine 3-way handshake (draft-ietf-isis-rfc3373bis),
| | one approach would be to add cookie field at the end of TLV #240.
| |
| | Is there interest in this group to consider such functionality extention
| | for IS-IS? If yes, but you think TLV #240 and draft-ietf-isis-rfc3373bis
| | in general are wrong place for this, would it be of interest to have
| | separate draft for interface loop detection mechanism for IS-IS?
| 
| ilya,
| 
| can you explain why matching our own sysid against the sysid in the IIH
| (and subsequent discard of such PDUs) is not sufficient for loop prevention ?
| 
| /hannes

---

From: "Parker, Jeff" <[email-masked]>
Date: Thu, 3 Apr 2008 12:18:08 -0400

One case is due to misconfiguration, and takes human intervention to chance the system ID of one of the two boxes using the same ID.
I think we introduced an SNMP trap for just this purpose.

The other case could be dealt with mechanically, as Ilya is suggesting, as a bridge would when it detects a loop.

- jeff parker
________________________________________
From: Hannes Gredler [[email-masked]]
Sent: Thursday, April 03, 2008 12:10 PM
To: Parker, Jeff
Cc: Ilya Varlashkin; IETF IS-IS
Subject: Re: [Isis-wg] Interface loop detection in IS-IS

/hannes

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 3 Apr 2008 18:24:17 +0200

> -----Original Message-----
[...]
> | Is there interest in this group to consider such functionality 
> | extention for IS-IS? If yes, but you think TLV #240 and 
> | draft-ietf-isis-rfc3373bis in general are wrong place for 
> this, would 
> | it be of interest to have separate draft for interface loop 
> detection mechanism for IS-IS?
> 
> ilya,
> 
> can you explain why matching our own sysid against the sysid 
> in the IIH (and subsequent discard of such PDUs) is not 
> sufficient for loop prevention ?
> 

Hi Hannes,

Sysid can be misconfigured (e.g. when using config templates). It might
well be that some implementations treat duplicate SysID exactly as
configuration issue. On the other hand, a cookie can be generated in
such way as to insure that it's unique with sufficiently high
probability (i.e. generated in such way that virtually guarantees that
only this given system could have generated that cookie and not any
other even if they use same algorithm).

Because of such difference cookie is more sure way to tell a loop from
misconfiguration.

/iLya

---

From: "Jeff Learman (jlearman)" <[email-masked]>
Date: Thu, 3 Apr 2008 12:29:51 -0400

What would be the difference in behavior for looped vs. duplicate SysID?

Thanks,
Jeff 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ilya Varlashkin
Sent: Thursday, April 03, 2008 12:24 PM
To: IETF IS-IS
Cc: Hannes Gredler
Subject: Re: [Isis-wg] Interface loop detection in IS-IS

[...]

Hi Hannes,

/iLya

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Thu, 3 Apr 2008 11:30:15 -0500

It seems that using the MAC address as suggested by James Carlson would suffice for the case where config templates were in use -- and it would also give enough resolution to distinguish if an SNMP trap should be sent...
 
Or are you suggesting that the config templates affect the i/f's MAC address?  That would cause a whole host of other problems that adding a cookie wouldn't be able to solve...
 
Jonathan Sadler

________________________________

From: [email-masked] on behalf of Ilya Varlashkin
Sent: Thu 4/3/2008 11:24 AM
To: IETF IS-IS
Cc: Hannes Gredler
Subject: Re: [Isis-wg] Interface loop detection in IS-IS

[...]

Hi Hannes,

/iLya

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 3 Apr 2008 18:34:29 +0200

> From: James Carlson [mailto:[email-masked]] 
> Sent: Thursday, April 03, 2008 4:58 PM
> To: Ilya Varlashkin
> Cc: IETF IS-IS
[...]
> Such a cookie already exists, at least on media that have 
> multiple connected endpoints and MAC-layer addresses: the 
> source MAC address will tell you whether what you've received 
> is one of your own messages with a fairly high degree of confidence.
> 

James,

There is even keepalive mechanism on Ethernet to detect more complex
loop scenarios than simple interface loop. However, IS-IS does not rely
on such mechanism. Moreover not every router implementation will even
shut down the interface if it detects a loop. My motivation of writing
original mail was that I've observed on moderate sized network that when
interface was unexpectedly looped back, it werecked havoc in IS-IS
causing distruption for some prefixes for which affected system was
next-hop.

I agree that MAC addresses could serve as a cookie, but IS-IS should
have a mechanism to detect loops (either directly via MAC or more
generic cookie check or indirectly via e.g. BFD).

/iLya

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 3 Apr 2008 18:42:34 +0200

IMO we have already everything that we need.

- for broadcast media one can look at the mac adress as a "cookie"
  (as previously suggested on the list)

- for p2p media (C-HDLC, PPP) we have magic-numbers, mineseen yourseen
  etc. to detect loops) - as soon as the interface is loop detected
  and downed, higher layers (=IS-IS) won't see the PDUs anyway.

/hannes

On Thu, Apr 03, 2008 at 12:18:08PM -0400, Parker, Jeff wrote:
| One case is due to misconfiguration, and takes human intervention to chance the system ID of one of the two boxes using the same ID.
| I think we introduced an SNMP trap for just this purpose.
| 
| The other case could be dealt with mechanically, as Ilya is suggesting, as a bridge would when it detects a loop.
| 
| - jeff parker
| ________________________________________
| From: Hannes Gredler [[email-masked]]
| Sent: Thursday, April 03, 2008 12:10 PM
| To: Parker, Jeff
| Cc: Ilya Varlashkin; IETF IS-IS
| Subject: Re: [Isis-wg] Interface loop detection in IS-IS
| 
| well, whats the point distinguishing those two cases ?
| the ultimate action -> "log and discard" is the same.
| 
| for troubleshooting purposes looking at the contents
| (extended local circuit-id!) and length of TLV #240,
| should provide enough information to distinguish between
| the two.
| 
| /hannes
| 
| On Thu, Apr 03, 2008 at 11:56:01AM -0400, Parker, Jeff wrote:
| | I assume this is to distinguish between the case of a duplicate SysID
| | and the case of a looped interface.
| |
| | - jeff parker
| | ________________________________________
| | From: Hannes Gredler [[email-masked]]
| | Sent: Thursday, April 03, 2008 11:19 AM
| | To: Ilya Varlashkin
| | Cc: IETF IS-IS
| | Subject: Re: [Isis-wg] Interface loop detection in IS-IS
| |
| | On Thu, Apr 03, 2008 at 03:36:27PM +0200, Ilya Varlashkin wrote:
| | | With current trend using Ethernet for backbone links and running IS-IS
| | | (often using p2p hello) would it be not good idea to add extra level of
| | | protection in IS-IS to detect interfaces which are looped? With
| | | traditional serial interfaces one could force interface to go down when
| | | a loop detected, with Ethernet this is most of the time not the case.
| | | I've observed in personal practice that certain types of IS-IS
| | | implementations get at least upset if they see HELLO with the same
| | | sys-id, worst case I've seen was messed up LSDB on all routers that
| | | share it (i.e. all level-2 routers) and some traffic was blackholed.
| | | Simple solution to the interface loop could be adding some sort of a
| | | cookie to hello PDU. If a router detects HELLO with its own sys-id which
| | | also contains cookie that this router send, then it can deduce that
| | | there is a loop on the interface and should stop further processing of
| | | such HELLO. The cookie could be implemented either by introducing new
| | | TLV or extending existing TLV. Taking into account that there is
| | | currently effort to refine 3-way handshake (draft-ietf-isis-rfc3373bis),
| | | one approach would be to add cookie field at the end of TLV #240.
| | |
| | | Is there interest in this group to consider such functionality extention
| | | for IS-IS? If yes, but you think TLV #240 and draft-ietf-isis-rfc3373bis
| | | in general are wrong place for this, would it be of interest to have
| | | separate draft for interface loop detection mechanism for IS-IS?
| |
| | ilya,
| |
| | can you explain why matching our own sysid against the sysid in the IIH
| | (and subsequent discard of such PDUs) is not sufficient for loop prevention ?
| |
| | /hannes
| 
| _______________________________________________
| Isis-wg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 3 Apr 2008 18:42:44 +0200

Jonathan,

I agree with James suggestion. My idea with cookies was just one of the
possible solutions. The concern here is that there should be clear
mechanism how to deal with such situation, and implementations should
stick to such mechanism. Unfortunately I don't have access to original
ISO 10589 and couldn't find anything in IETF documents how proper
implementation should behave in case of seeing itsown system id, only
saw how practical implementations behave.

/iLya

	From: Sadler, Jonathan B. [mailto:[email-masked]] 
	Sent: Thursday, April 03, 2008 6:30 PM
	To: Ilya Varlashkin; IETF IS-IS
	Cc: Hannes Gredler
	Subject: RE: [Isis-wg] Interface loop detection in IS-IS

	It seems that using the MAC address as suggested by James
Carlson would suffice for the case where config templates were in use --
and it would also give enough resolution to distinguish if an SNMP trap
should be sent...
	 
	Or are you suggesting that the config templates affect the i/f's
MAC address?  That would cause a whole host of other problems that
adding a cookie wouldn't be able to solve...
	 
	Jonathan Sadler

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 3 Apr 2008 18:48:58 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hannes Gredler
> Sent: Thursday, April 03, 2008 6:43 PM
> To: Parker, Jeff
> Cc: IETF IS-IS

Agree that mac address can be used as a cookie so a tool is given. But
is it used in practice? I saw that apparently that's not the case. The
question comes whether or not it's clearly defined in IS-IS
specification how to deal with the problem and if not, whether or not
should/can this be added to specification to provide clear guidelines
for how to properly implement this part of the protocol.

>   and downed, higher layers (=IS-IS) won't see the PDUs anyway.

My initial concern was only about Ethernet (and alike) since serial p2p
interfaces on many platforms have option to shutdown whole interface if
it's looped. On the other hand, for operational/troubleshooting reason
it might be desirable not to shutdown interface itself so then situation
is the same as with Ethernet - IS-IS should detect and deal with such
interface loops on its own, i.e. it should be robust enough to sustain
such situations.

/iLya

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 3 Apr 2008 19:08:10 +0200

> Sent: Thursday, April 03, 2008 6:52 PM
> To: Ilya Varlashkin
> Cc: IETF IS-IS
[...]
> Given that there are in fact suitable mechanisms that would 
> avoid damage caused by loops _today_, and that some seem to 
> be unable to employ those existing mechanisms, how does it 
> help to invent a new mechanism that the same designers would 
> (presumably) just ignore as well?
> 
> How does this bit of added complexity solve a new problem?
> 
Although there are in some cases mechanisms outside of IS-IS to deal
with loop problems, such mechanism may not always be in place for
various reasons (e.g. not implemented by specific platform or
deliberately switched off for troubleshooting purpose). Shouldn't IS-IS
be robust enough to deal with a problem if it faces one? The issue with
looped interface is of the same sort as one addresses by 3-way handshake
- link-level issues which are not necessary considered as a problem or
not detected by link-level.

/iLya

---

From: James Carlson <[email-masked]>
Date: Thu, 3 Apr 2008 12:52:27 -0400

> causing distruption for some prefixes for which affected system was

I guess I don't quite understand.

Given that there are in fact suitable mechanisms that would avoid
damage caused by loops _today_, and that some seem to be unable to
employ those existing mechanisms, how does it help to invent a new
mechanism that the same designers would (presumably) just ignore as
well?

---

From: Dave Katz <[email-masked]>
Date: Thu, 3 Apr 2008 11:16:40 -0600

Exactly.

Broken implementations are unlikely to become unbroken by the  
invention of a redundant mechanism.

The right answer is to threaten to throw away the broken boxes.  This  
has been effective when used against my code in the past.  ;-)

--Dave

On Apr 3, 2008, at 10:52 AM, James Carlson wrote:
> James Carlson, Solaris Networking              <[email-masked] 
> >

---

From: James Carlson <[email-masked]>
Date: Thu, 3 Apr 2008 13:15:10 -0400

> not detected by link-level.

Noticing that the System ID is wrong and dropping the packet gives you
that level of protection already.

As you've noted, there may be implementations that fail to check
System ID.  I still don't see why, if they fail to check that, they're
going to suddenly start checking some _new_ parameter that's yet to be
defined.  That seems like an unusual level of engagement where there
was previously much less.

If you mess up the existing features, why does adding more features
address the problem?  Isn't the real problem just a bug in some
implementations rather than a missing feature in the specification?