Subject: [Isis-wg] Question about Purge LSP in RFC 1142

From: Theodore.Wang <[email-masked]>
Date: Sun, 14 Oct 2007 19:14:16 +0800

Hi, all

I have a question about Purge LSP in RFC 1142.
In RFC 1142, I find the following lines:

e)An Intermediate system receiving a Link State PDU with an incorrect LSP
Checksum or with an invalid PDU syntax shall
1)log a circuit notification, corruptedLSPReceived,
2)overwrite the Checksum and Remaining Lifetime with 0, and
3)treat the Link State PDU as though its Remaining Lifetime had expired
These lines define the way how to cope with the LSP with incorrect checksum,
that is to flood the LSP's header with zero remaining lifetime.

But in fact, in a huge network, it is hard to locate the router that
generate the Purge LSP, and which is the situation I'm facing. A Corrupted
LSP Storm is happening in the network and it lacks a efficient way to
troubleshooting because we can only use "ignore checksum error" on every
router to find the one that flooded the Purge LSP.

Therefore, is it possible to attach a new TLV in Purge LSP that defines the
originator?

Thanks in advance!
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: mike shand <[email-masked]>
Date: Fri, 19 Oct 2007 12:34:11 +0100

Theodore.Wang wrote:

Hi, all

You should not be paying any attention to RFC 1142. It is a copy of DP
10589 which is a version of ISO/IEC 10589 several stages before its
final standardisation and differs from ISO/IEC 10589 is several
important respects.

If you want to know what the standard says, get a copy of ISO/IEC
10589:2002 from

http://standards.iso.org/ittf/PubliclyAvailableStandards/

e)An Intermediate system receiving a Link State PDU with an
incorrect LSP Checksum or with an invalid PDU syntax shall

These lines define the way how to cope with the LSP with
incorrect checksum, that is to flood the LSP's header with zero
remaining lifetime.

In fact this behaviour has been changed in the second edition and now
reads

e) An Intermediate system receiving a Link State PDU with an incorrect
LSP Checksum or with an invalid PDU syntax shall

1) generate a corruptedLSPReceived circuit event,

2) discard the PDU.

see also RFC 3719 section 8, which reads

8.  Purging Corrupted PDUs

While ISO 10589 requires in section 7.3.14.2 e) that any LSP received

with an invalid PDU checksum should be purged, this has been found to

be disruptive.  Most implementations today follow the revised

specification, and simply drop the LSP.

In ISO 10589:2002 [1], Section 7.3.14.2, it states:

(e)  An Intermediate system receiving a Link State PDU with an

incorrect LSP Checksum or with an invalid PDU syntax SHOULD

1) generate a corruptedLSPReceived circuit event,

2) discard the PDU.

But in fact, in a huge network, it is hard to locate the
router that generate the Purge LSP, and which is the situation I'm
facing. A Corrupted LSP Storm is happening in the network and it lacks
a efficient way to troubleshooting because we can only use "ignore
checksum error" on every router to find the one that flooded the Purge
LSP.

It is for this reason (the purge storm) that the specification was
changed!

Therefore, is it possible to attach a new TLV in Purge LSP that
defines the originator?

No.

Thanks in advance!

---

From: "Manav Bhatia" <[email-masked]>
Date: Fri, 19 Oct 2007 17:27:18 +0530

Hi Wang,
 
Most implementations would just drop the corrupted LSPs - the problem you
describe wouldn't occur if you did this.
 
Cheers,
Manav

  _____  

From: Theodore.Wang [mailto:[email-masked]] 
Sent: Sunday, October 14, 2007 4.44 PM
To: [email-masked]
Subject: [Isis-wg] Question about Purge LSP in RFC 1142

Hi, all

 

Thanks in advance!

---

From: Dave Katz <[email-masked]>
Date: Fri, 19 Oct 2007 08:32:15 -0600

On Oct 19, 2007, at 5:34 AM, mike shand wrote:

>
>>
>> But in fact, in a huge network, it is hard to locate the router  
>> that generate the Purge LSP, and which is the situation I'm  
>> facing. A Corrupted LSP Storm is happening in the network and it  
>> lacks a efficient way to troubleshooting because we can only use  
>> "ignore checksum error" on every router to find the one that  
>> flooded the Purge LSP.

Yep.  There was a busted UUnet link in Texas, I believe, back in  
around '96, that was corrupting packets but delivering them with  
valid datalink checksums.  This caused every LSP crossing the link  
(which is, by definition, eventually *every* LSP) to be purged and  
reflooded.  And purged and reflooded.  It was quite spectacular, if  
rather unpleasant.  I don't quite remember how we found the bad  
link;  probably saw some other error indications at the ends.  A knob  
was added rather quickly.

--Dave

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 22 Oct 2007 21:31:55 +0200

On Sun, Oct 14, 2007 at 07:14:16PM +0800, Theodore.Wang wrote:
|    Therefore, is it possible to attach a new TLV in Purge LSP that defines
|    the originator?

that would not help you to fix all pathologic cases -
think of a misconfiguration where you have non-unique
system-ids somewhere in the network ...

all you can do is to ignore this LSP and throttle
your own LSP re-origination.

/hannes

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 22 Oct 2007 13:00:59 -0700

> -----Original Message-----
> From: Hannes Gredler [mailto:[email-masked]]
> Sent: Monday, October 22, 2007 12:32 PM
> To: Theodore.Wang
> Cc: [email-masked]
> Subject: Re: [Isis-wg] Question about Purge LSP in RFC 1142
> 

Hmmm...this is a different case entirely.

Now you will be receiving valid LSPs (i.e. no syntax errors, no checksum
errors) but they will look like they are self-generated when they have
actually be generated by your "evil-twin". This will force you to
regenerate or purge depending upon whether that particular LSP number is
part of your current self-generated set or not.

Throttling is important in this case to at least control the rate of
flapping, but ignoring the received LSPs is out of the question. The
network will churn until the misconfiguration is fixed.

   Les

---

From: mike shand <[email-masked]>
Date: Tue, 23 Oct 2007 11:14:46 +0100

Les Ginsberg (ginsberg) wrote:

-----Original Message-----
From: Hannes Gredler [mailto:[email-masked]]
Sent: Monday, October 22, 2007 12:32 PM
To: Theodore.Wang
Cc: [email-masked]
Subject: Re: [Isis-wg] Question about Purge LSP in RFC 1142

On Sun, Oct 14, 2007 at 07:14:16PM +0800, Theodore.Wang wrote:
| Therefore, is it possible to attach a new TLV in Purge LSP that
defines
| the originator?

Yes. This is what the "sequenceNumberSkip" event (and associated
counter) was meant for. If you have such a case both systems will start
generating sequence number skip events which will at least give you a
clue about what is going on. You should at least see these for LSP
number 0.

Mike

Les

/hannes