Subject: RE: [Isis-wg] AreaMisMatch Event

From: Jeff Parker <[email-masked]>
Date: Fri, 9 Nov 2001 12:33:31 -0500

> 	According to ISO/IEC 10589, section 8.4.2.2, item a)
> 	
> "If a match is not found between any pair (i.e. the local
> and remote system have no area address in common), the
> IS shall reject the adjacency"
> 
> My understanding of the phase  "reject the adjacency" means:
> 1) If the IS  is not already have an adjacency with the 
> remote IS, then don't form any adjacency 
>
> 2) If the IS  is already have an adjacency with the remote 
> IS, then the IS shall "reset the adjacency with the remote 
> IS." 

Spot on.   
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Ravindra Sunkad <[email-masked]>
Date: Fri, 9 Nov 2001 09:57:04 -0800

Yes. You should delete the adjacency in this case.

Ravi 

-----Original Message-----
From: Chan, Chung Ming [mailto:[email-masked]] 
Sent: Friday, November 09, 2001 7:59 AM
To: [email-masked]'
Cc: Chan, Chung Ming
Subject: [Isis-wg] AreaMisMatch Event

Hi,
	I've a question regarding to Area Address mismatch. Hope someone can
clarify that to me.

My understanding of the phase  "reject the adjacency" means:
1) If the IS  is not already have an adjacency with the remote IS, then
don't form any adjacency using the received IIH (Essentially drops/discards
the IIH)
2) If the IS  is already have an adjacency with the remote IS, then the IS
shall "reset the adjacency with the remote IS." (i.e. the IS goes back to
Enabled state, sending IIH without the MAC address of the remote IS).  My
reasoning is that  if the remote IS's area address is changed and there is
not area address in common any more, there is no more reason for keeping the
adjacency.

I know #1 shall be TRUE; but not sure about #2.

Could anyone help to clarify that?

Thanks,

Ming Chan

---

From: Jeff Learman <[email-masked]>
Date: Fri, 09 Nov 2001 13:00:52 -0500

That would be my interpretation.  If you continue sending IIHs with
your MAC address in it, that would goof up DR election.

The intent is that you would have no L1 adjacency for this system
at all.  (If you're a L2 router, you'd form or retain a L2 adjacency.)

Regards,
Jeff

Disclaimer - I don't work in IS-IS at Cisco, so what I say has
nothing to do with Cisco's implementation.  Opinions expressed
are my own, and may not be those of my employer.  And when I
say something really wrong, Les Guinsberg usually disabuses
everyone ;-)

---

From: Les Ginsberg <[email-masked]>
Date: Fri, 9 Nov 2001 16:10:44 -0800

It is probably also worth mentioning that deliberately configuring routers
on a LAN which operate as L1 routers but are in different areas is a dubious
practice at best. This is the reason the spec calls for an AreaMismatch
event to be generated when such a condition is detected.

Using a LAN as an L2-only backbone - where none of the routers operate as L1
routers on that circuit - makes sense.

Having a mixture of routers, all in the same area, some of which are L2
capable, all connected to the same LAN also makes sense.

The case which sparked the original question, although certainly not unheard
of, should be discouraged.

  Les

-----Original Message-----
From: Henk Smit
To: [email-masked]
Cc: [email-masked]
Sent: 11/9/01 3:29 PM
Subject: Re: [Isis-wg] AreaMisMatch Event

  Seems like I am the only one to disagree with the rest. :-)

  I would prefer my code to just ignore the incoming IIH and drop it.
 If the other router was really reconfigured with different area
address(es)
 then the next few IIHs will be dropped too, causing the adjacency to
time
 out eventually.

  This will take some time. And could be speed up by bringing down the
 adjacency immediately. What do you gain ? If a network admin really
 wants the adjacency to be reset quickly, he can clear it manually after
 the manual area address change.

  The downside of clearing the adjacency is that you are making your
 network less robust.
  Remember that IIHs have no layer3 checksum. So in case you are
 receiving a (partially) corrupted packet, this one corrupted packet
 can take down an adjacency immediately. If you just ignore the packet,
 and it was really an incidental corruption, the adjacency stays up.
  In a previous life I've seen this happen on ATM networks.

        Henk.

---

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Sat, 10 Nov 2001 20:27:59 -0500 (EST)

I'd agree with Henk. Henks's suggested behavior (throwing away and
perhaps logging the IIH) will eventually bring down the adjacency,
where "eventually" is no longer than it would take to notice a dead
router neighbor.
And the other behavior (bringing it down immediately) would make it
easier, when no authentication is being used...how often is
authentication used these days?...to disrupt a network by sending bogus
packets. Though I could imagine the argument that if someone can
send bogus IS-IS packets and there's no authentication, you're pretty
much gonna lose anyway.

Radia