[35340] in North American Network Operators' Group
Re: Loose Source Routing
daemon@ATHENA.MIT.EDU (Valdis.Kletnieks@vt.edu)
Wed Mar 7 01:33:31 2001
Message-Id: <200103070544.f275iP329925@foo-bar-baz.cc.vt.edu>
To: Vadim Antonov <avg@kotovnik.com>
Cc: smd@clock.org, nanog@merit.edu
In-reply-to: Your message of "Tue, 06 Mar 2001 19:24:34 PST."
<Pine.LNX.4.04.10103061902510.11495-100000@kitty.kotovnik.com>
From: Valdis.Kletnieks@vt.edu
Date: Wed, 07 Mar 2001 00:44:25 -0500
Errors-To: owner-nanog-outgoing@merit.edu
On Tue, 06 Mar 2001 19:24:34 PST, Vadim Antonov said:
> As for debugging routing - isn't it much better to ask OFRVs to add
> remotely accessible traceroute servers to their boxes? There is no
> engineering or economic justification for diagnostic fucntionality like
> LSRR to stay anywhere close to the fast packet path.
Amen, brother. ;)
Anybody want to place bets that there exists at least one majr vendor
whos routers do fast-path switching in hardware, but have buggy software
paths that will under certain circumstances (for instance, maybe while
a BGP flat is in progress) route slow-path packets differently?
I know of none offhand, but the combination of opportunity for bugs,
combined with the impact, makes it something dangerous to do. If
a bug WERE to exist in LSRR routing, the sort of border conditions
that would make it manifest are the times your peer would be poking
you with LSRR packets to test what the problem is. At that point,
you *really* want to be using traceroute servers so you know that
your test packets are as identical as possible as the packets you're
having problems with.
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
