Subject: Re: Loop Detection

From: Hummel Heinrich <[email-masked]>
Date: Tue, 2 Jul 2002 10:16:59 +0200

Wouldn't it be a fine goal to standardize a tool/mechanism/protocol
which double-checks, within milliseconds, that all routing tables of some network domain are in sync ?
Or at least, that the topological view, aquired by all nodes of some network domain complies with the physical reality ?
Wouldn't this be a powerful OAM-application ? IMHO:it would be better than the religious fights on OAM-MPLS.

Heinrich Hummel
Siemens AG

 On Tue, 4 Jun 2002, Jing Shen wrote:

> Given a network with several routers, is there any tool/application to
> detect loops in the routing tables?

As far as I know, there isn't.
Also if the loop is due to a misconfiguration which does not show up
in BGP updates, then it's harder to detect.

-Sue

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: "David Allan" <[email-masked]>
Date: Thu, 4 Jul 2002 09:10:27 -0400

Issue is it only tells you ***somthing*** is broken.

Similarly simply ensuring that the routing databases are synchronized does
not perform a sanity check on the local derivative by-products (FIBs, FTN,
NHLFE etc.) or the hw that implements them.

cheers
Dave

> -----Original Message-----
> From: John Renwick [mailto:[email-masked]]
> Sent: Wednesday, July 03, 2002 6:59 PM
> To: Amir Hermelin; Hummel Heinrich; [email-masked]
> Subject: RE: Loop Detection
> 
> 
> Isn't TTL a very direct and immediate form of loop detection?  
> If you had a network tool that would illuminate the routers that 
> are counting a lot of packets dropped because of TTL expiration, 
> it could be showing you points on a routing loop.
> 
> --
> John Renwick                          Agere Systems
> Software Technical Manager            1230 Northland Drive
> Phone: (651) 675-2986                 Mendota Heights, MN 55120
> FAX:   (707) 897-7928                 Cell:  (612) 669-9397
> mailto:[email-masked]             http://www.agere.com
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Amir Hermelin
> > Sent: Wednesday, July 03, 2002 5:12 PM
> > To: Hummel Heinrich; [email-masked]
> > Subject: RE: Loop Detection
> > 
> > 
> > my 2 cents:
> > * Yes, such a tool would be very nice. Although, a small portion 
> > of our salaries is due to the fact that routing loops are 
> so scary ;-)
> > * The approaches would be different for types of protocols. In 
> > IGPs, assuming correct implementations, the protocol takes care 
> > of loop possibilities as long as the lspdb is in sync. When its 
> > not due to transient states, a tool wouldn't help since you'd 
> > have to run it constantly for every router's view.
> > * I agree that detecting BGP mis-configuration is hard. As for 
> > MPLS, there are methods that are more susceptible to loops than 
> > others (e.g. one implementation of TE-shortcuts can lead to loops 
> > even in a seemingly correct configuration, due to metric values).
> > * If this stuff moves forward, it might even mandate a whole new 
> > workgroup. 
> > 
> > --
> > Amir Hermelin                  <mailto:[email-masked]>
> > Charlotte's Web Networks Inc.   <http://www.cwnt.com>
> > 
> > 
> > > -----Original Message-----
> > > From: Hummel Heinrich [mailto:[email-masked]]
> > > Sent: Tuesday, July 02, 2002 11:17 AM
> > > To: [email-masked]
> > > Subject: Re: Loop Detection
> > > 
> > > 
> > > which double-checks, within milliseconds, that all routing 
> > > tables of some network domain are in sync ?
> > > Or at least, that the topological view, aquired by all nodes 
> > > of some network domain complies with the physical reality ?
> > > Wouldn't this be a powerful OAM-application ? IMHO:it would 
> > > be better than the religious fights on OAM-MPLS.
> > > 
> > > Heinrich Hummel
> > > Siemens AG
> > > 
> > > 
> > >

---

From: Hummel Heinrich <[email-masked]>
Date: Mon, 8 Jul 2002 17:14:40 +0200

It is not about TTL (which is to control a particular IP-packet on its way to the destination).
Its about a  sanity check w.r.t. the distributed view of the intra-domain network topology. Whether or not IP flows are
on the go is something else (they may do TTL). 

This sanity check may be simple and fast. And if you want, there may be different types of sanity checks:
some which controls just the topology without reachability info,and  without link parameters. It will be the fastest
(microseconds). Next there may be slower but more comprising sanity checks. At last there may even be checks on
proper derivatives (Routing Tables, NHLFEs,...)
Heinrich

Title: RE: Loop Detection
Issue is it only tells you ***somthing*** is broken. 

Similarly simply ensuring that the routing databases are synchronized does not perform a sanity check on the local derivative by-products (FIBs, FTN, NHLFE etc.) or the hw that implements them.

cheers 
Dave

---

From: "David Allan" <[email-masked]>
Date: Mon, 8 Jul 2002 13:35:07 -0400

Heinrich:

I'd be concerned with scalability, as the derivative by-products are usually
context sensitive, e.g. unique to a node because of its position in the
topology, so whereas scaling a comparison of commonly flooded information is
a very tractable problem (simple exchange of digests), comparing node-unique
derivatives is not...

rgds
Dave

> Sent: Monday, July 08, 2002 11:15 AM
> To: [email-masked]; [email-masked]'; 
> [email-masked]'; Allan,
> David [CAR:NS00:EXCH]
> It is not about TTL (which is to control a particular 
> IP-packet on its way to the destination).
> Its about a  sanity check w.r.t. the distributed view of the 
> intra-domain network topology. Whether or not IP flows are
> This sanity check may be simple and fast. And if you want, 
> there may be different types of sanity checks:
> some which controls just the topology without reachability 
> info,and  without link parameters. It will be the fastest
> (microseconds). Next there may be slower but more comprising 
> sanity checks. At last there may even be checks on
> Similarly simply ensuring that the routing databases are 
> synchronized does not perform a sanity check on the local 
> derivative by-products (FIBs, FTN, NHLFE etc.) or the hw that 
> implements them.
> 
> cheers 
> Dave 
>

---

From: "Li, Ke Qin (Peter)" <[email-masked]>
Date: Wed, 10 Jul 2002 10:19:11 +0800

Yes, it is not about TTL.

Is there any existing work about the sanity check?

And would you please give more detailed explaination about the 3 kinds of
sanity check?

Keqin Li

> Sent: Monday, July 08, 2002 11:15 PM
> [email-masked]'; [email-masked]'

---

From: Hummel Heinrich <[email-masked]>
Date: Wed, 10 Jul 2002 08:59:02 +0200

See my answers inserted.
Heinrich

HH=> I haven't heard of any work being done in the IETF. And I have just asked the question
whether there were interest on doing such work.

HH=> Sure, but before, I would suggest to agree on a different subject line than "Loop Detection"
because it is really not about TTL. Instead it is about checking whether all nodes have the identical view of the network.
Routing tables don't have loops but may be inconsistent.
E.g. "OAM: Network view sanity check" might be a more appropriate subject line.

Also,the less you check, the faster and simpler is the sanity check. I first of all thought about checking the
topological view only/mainly.

Keqin Li

---

From: "Amir Hermelin" <[email-masked]>
Date: Thu, 11 Jul 2002 11:22:19 +0300

I don't think MPLS is more susceptible - it's just, being familiar with a feature such as TE shortcuts, I know for a fact some implementations' manipulation of metrics (relative, absolute) can create loop scenarios if not configured properly. And since these metrics and how they work are different than IGP, you can't really say the occurrence will be on the same level.
Generally, since MPLS has different loop detection mechanisms, than it's different than traditional routing in this aspect (as are IGP and EGP also different).

If you want, I can detail a scenario privately, but it's not the specifics that matter here.

--
Amir Hermelin                    < mailto:[email-masked]>
Charlotte's Web Networks Inc.     < http://www.cwnt.com>

>From: Jing Shen [mailto:[email-masked]]
>Sent: Thursday, July 11, 2002 4:34 AM
>To: Amir Hermelin
>Cc: Hummel Heinrich; [email-masked]
>Why do you think MPLS is more susceptible to loop than other 
>technology? 
>As I think, LSP is set up by signalling along the path computed by edge
>router or
>following the items of routing tables. That is, if we just set up 
>LSPs according to routing table of IGP or EGP, the occurance of loop
>will be
>the same level of  traditional routing. 
>
>To detect loop in network, I think it's nearly impossible for a node to
>detect
>loops on some directions if it could not track routing tables at real
>time. But,
>if CR-LDP is used to set up transmission tunnel in networks, 
>the problem
>may 
>be overcomed at the stage of setup.
>
>
>
>
>Amir Hermelin wrote:
>> 
>> my 2 cents:
>> * Yes, such a tool would be very nice. Although, a small 
>portion of our salaries is due to the fact that routing loops 
>are so scary ;-)
>> * The approaches would be different for types of protocols. 
>In IGPs, assuming correct implementations, the protocol takes 
>care of loop possibilities as long as the lspdb is in sync. 
>When its not due to transient states, a tool wouldn't help 
>since you'd have to run it constantly for every router's view.
>> * I agree that detecting BGP mis-configuration is hard. As 
>for MPLS, there are methods that are more susceptible to loops 
>than others (e.g. one implementation of TE-shortcuts can lead 
>to loops even in a seemingly correct configuration, due to 
>metric values).
>> * If this stuff moves forward, it might even mandate a whole 
>new workgroup.
>> 
>> --
>Jing Shen
>Email: [email-masked]
>
>**********************************************************************
>* The SunShine of life is made up of very little beams which is      *
>*  bright all the time                                               *
>**********************************************************************
>