Subject: [Isis-wg] Overload & Attached bits

From: "Erez Morabia" <[email-masked]>
Date: Mon, 12 Nov 2001 17:12:36 +0200

Hi all,
I have some questions regarding the 'overload bit' and the 'attached
bit' 
and their possible relations.

1. Can a router have both bits set at the same time?

2. Should we consider overloaded routers in our search 
   for the nearest attached level-2 intermediate system? 
   (if we do, we might insert a default route with a next-hop 
    to the overloaded router to the forwarding database...)

3. When we want to check if we are 'attached', we check if we can
   reach at least one intermediate system which resides in
   another area. Should we consider overloaded routers in our
   search?

Thanks,
Erez 

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

---

From: Ravindra Sunkad <[email-masked]>
Date: Mon, 12 Nov 2001 09:43:59 -0800

-----Original Message-----
From: Erez Morabia [mailto:[email-masked]] 
Sent: Monday, November 12, 2001 7:13 AM
To: [email-masked]
Subject: [Isis-wg] Overload & Attached bits

Hi all,
I have some questions regarding the 'overload bit' and the 'attached bit' 
and their possible relations.

Yes. 

No. You do not want any traffic (except destined for the local subnets of
the overloaded IS) to be forwarded to the overloaded IS.  

I think so. If you don't, the local subnets of the overloaded IS will not be
reachable by networks in other L1 areas.

Thanks,
Erez

---

From: stefano previdi <[email-masked]>
Date: Mon, 12 Nov 2001 23:50:20 +0100

>the overloaded IS) to be forwarded to the overloaded IS.

In some cases you would prefer not to make such "exception". I
think it depends on the reason why you did set the overload bit:
if the overloaded router is also one of the iBGP next-hops in your
network, you may not want to forward traffic to it....unless the
router is not "overloaded" enough to re-route internet traffic...

Now of course, I'm not sure if a router is ever used as L1L2 _and_
peering point...

s.

---

From: "Erez Morabia" <[email-masked]>
Date: Tue, 13 Nov 2001 16:59:02 +0200

Hi,
Thanks for the useful replys.
I added some questions/thoughts inline.

> From: stefano previdi [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 12:50 AM
> To: Ravindra Sunkad
> Cc: Erez Morabia; [email-masked]
> Subject: RE: [Isis-wg] Overload & Attached bits
> 
> 

I agree with Ravindra.

> >reachable by networks in other L1 areas.

That's a good argument, but on the other hand, we might
end up with default route towards L1/2 router which can't
really reach another area (except for directly connected info
on the overloaded router).
I hope the following example will clearify this:

 L1RtrA(AreaX)------L1/2RtrB(AreaX)------L2RtrC(AreaY,Overloded)- - -
(AreaY/Backbone) 

 Note: 
  RtrA and RtrB have L1 connection
  RtrB and RtrC have L2 connection

RtrA will insert a default route towards RtrB although RtrB doesn't
really know any
other area because RtrC is overloaded (and shouldn't be used as a
"transient" IS).

A more problematic case can be when we have another "real" attached
router which we
won't choose as our nearest L2 as a result of metric considerations.
example:

L1/2RtrB(AreaX)--------L2RtrC(AreaY,Overload)--------1/2RtrD(AreaX)- - -
(L2 backbone)
        |
|
 
+-----------+----------------------------------------------------------+
                     |
                   RtrA(AreaX)

 Note: 
  RtrA and RtrB have L1 connection
  RtrA and RtrD have L1 connection
  RtrB, RtrC and RtrD have L2 connection

Suppose RtrA-RtrB is a low cost connection and RtrA-RtrD is a high cost
connection.
If we consider overloaded routers in our attached algorithm, RtrB will
be considered as
attached.  As a result, RtrA will insert a default route towards RtrB
and this will 
cause a loss of data because RtrC separates RtrB from the backbone.
If we won't consider overloaded routers in our attached algorithm, a
default route will
be inserted towards RtrD...

It seems to me that avoiding the above presented case may be more
important than 
avoiding a situation where local subnets of overloaded IS will not be
reachable by 
networks in other L1 areas.
But I might be wrong... :-)

> >Erez

Thanks again,
Erez

---

From: Ravindra Sunkad <[email-masked]>
Date: Tue, 13 Nov 2001 14:39:18 -0800

Erez,

My comments are inline.

Ravi

> Sent: Tuesday, November 13, 2001 6:59 AM
> To: Ravindra Sunkad; [email-masked]
> Cc: [email-masked]
> Subject: FW: [Isis-wg] Overload & Attached bits
> 
> 
> Hi,
> > In some cases you would prefer not to make such 
> "exception". I think 
> > it depends on the reason why you did set the overload bit: if the 
> > overloaded router is also one of the iBGP next-hops in your 
> network, 
> > you may not want to forward traffic to it....unless the 
> router is not 
> > "overloaded" enough to re-route internet traffic...
> > 
> on the overloaded router). I hope the following example will 
> clearify this:
> 
> RtrA will insert a default route towards RtrB although RtrB 
> doesn't really know any other area because RtrC is overloaded 
> (and shouldn't be used as a "transient" IS).
> 

Since RtrC is overloaded, RtrB will not install routes for networks in L1
areas other than AreaY. So, RtrC will not get transit traffic destined to
networks in other L1 areas.

> A more problematic case can be when we have another "real" 
> attached router which we won't choose as our nearest L2 as a 
> result of metric considerations.
> example:
> 
>  
> L1/2RtrB(AreaX)--------L2RtrC(AreaY,Overload)--------1/2RtrD(A
> reaX)- - - (L2 backbone)
>         |
> |
>  
> Suppose RtrA-RtrB is a low cost connection and RtrA-RtrD is a 
> high cost connection. If we consider overloaded routers in 
> our attached algorithm, RtrB will be considered as attached.  
> As a result, RtrA will insert a default route towards RtrB 
> and this will 
> cause a loss of data because RtrC separates RtrB from the 
> backbone. If we won't consider overloaded routers in our 
> attached algorithm, a default route will be inserted towards RtrD...
> 
> It seems to me that avoiding the above presented case may be 
> more important than 
> avoiding a situation where local subnets of overloaded IS 
> will not be reachable by 
 
This is a trivial case of the overloaded IS creating a disconnected
backbone. If RtrB was also connected to say 
L2RtrE(AreaZ) then RtrB would have been attached but still disconnected from
the rest of the backbone.

---

From: Nagasta Bagamba <[email-masked]>
Date: Tue, 13 Nov 2001 22:57:29 -0800 (PST)

Hello Erez and WG,
I want to make some comments about the 2 first issues
you brought up.

I understand you agree the answer for that is Yes.
But, I know at least one major vendor which doesn't
allow to set this 2 bits at the same time. The reason
for that is a kind of a mystery to me...
Does anyone have an idea what that reason might be?

You decided that the answer is No. But, I know of at
least 2 major vendors which consider overloaded
routers in the search for the nearest attached level-2
IS.
If vendors-mixture ISIS topology will be built,
routing loops may occure. Does anyone have an idea how
to avoid routing loops in such a topology?

10x,
Nagasta

__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Nagasta Bagamba <[email-masked]>
Date: Wed, 14 Nov 2001 00:33:57 -0800 (PST)

Hello Erez and WG,

I understand you agree the answer for that is Yes.
But, I know of at least one major vendor which doesn't
allow to set this 2 bits at the same time. The reason
for that is a kind of a mystery to me...
Does anyone have an idea what the reason for that may
be?

10x,
Nagasta