[69366] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

RE: BGP TTL check in 12.3(7)T

daemon@ATHENA.MIT.EDU (Blaine Christian)
Thu Apr 8 14:39:00 2004

From: "Blaine Christian" <blaine.christian@mci.com>
To: "'Iljitsch van Beijnum'" <iljitsch@muada.com>,
	"'Hank Nussbacher'" <hank@att.net.il>
Cc: <nanog@merit.edu>
Date: Thu, 8 Apr 2004 14:37:55 -0400
In-reply-to: <4A533414-8983-11D8-B512-000A95CD987A@muada.com>
Errors-To: owner-nanog-outgoing@merit.edu


>=20
> However, this says a TTL of 254 will be accepted. Now the=20
> fact that I =20
> can talk to boxes running a slightly older IOS with a TTL of=20
> 0 without =20
> any problems suggests to me that emitting packets with a TTL=20
> of 255 on =20
> router A and accepting packets with a TTL of 254 on router B=20
> allows for =20
> the presence of a router C in the middle. That can't be good.

I suspect they set the limit to 254 because they expected to decrement =
the
TTL on ingress (or that the box sending the packets would decrement on
send).  You have an interesting point WRT the TTL 0.  Perhaps if you =
receive
a packet with a TTL of 0 that is destined for yourself you should just
accept it?  It is not clear to me exactly when you "have" to throw away =
the
packet (on ingress/themiddle/egress).  I believe it is valid to accept a
packet that is destined for yourself with a TTL of zero.

Since I have observed that packets received from some types of routers =
have
their TTL set to 255 (on upon reaching the receiving device route =
processor)
I would have to assume that the TTL is not being decremented for route
processor packets.  Of course I was only playing with one router and it =
may
be vendor dependant (the vendor was not Cisco).

I am not sure that 254 is a good maximum number.  Perhaps someone "in =
the
know" can enlighten all of us as to why they chose to stop at 254 =
instead of
255.

Regards,

Blaine


home help back first fref pref prev next nref lref last post