Erm. TTL is Time To Live. It gives packets a limited lifetime in the network,
to stop routing loops and suchlike causing huge amounts of traffic to circle
the network endlessly.
It's set to a value by the process creating the packet (normally 255 I believe
for bog standard application traffic). Each router that the packet traverses
will decrement it by 1. If the value of the TTL gets to 0, the router that
decrements it to 0 will drop the packet, and should return an ICMP TTL expired
in transit message to the originating host.
In the case of eBGP multihop, the TTL is used to limit the maximum number of
hops you're willing to accept your BGP traffic traversing. F.e, you may be
peering ebgp-multihop with someone who is 3 hops away during optimum conditions,
but who can move to 15-20 hops away when a link goes down and you have to take
an alternative (worse) route to get to the peer. Setting the ebgp-multihop
TTL to 3 will mean that the BGP session will drop and any routes that it's
announcing will be dropped when using the worse route.
I think this is pretty much correct...
Cheers,
Chris.
On Thu, Oct 19, 2000 at 03:39:27AM -0400, shinoclist wrote:
> sorry for my igorance, what is this TTL thing?
>
> thks,
> Victor
>
> ----- Original Message -----
> From: Daniel L. Golding <dan@netrail.net>
> To: Josh Richards <jrichard@cubicle.net>
> Cc: <cisco-nsp@puck.nether.net>
> Sent: Thursday, October 19, 2000 10:18 AM
> Subject: Re: [nsp] Q: EBGP Multihop
>
>
> > Hmm. I set routing policy for a provider, and we do not do eBGP multihop,
> > except for testing purposes (e.g. if someone needs a full view in a test
> > lab). Why?
> >
> > 1) It is not necessary
> >
> > 2) It makes troubleshooting more difficult
> >
> > 3) If the customer doesn't understand the behavior, it can result in
> > causing one provider's traffic to transit another's network, which is
> > extrememly suboptimal. Yes, if they set TTL right, you're ok, but most
> > folks have barely enough of a clue to set up BGP in the first place.
> >
> > 4) It is a "custom" setup, and most ISP's setup BGP customers through
> > either a strictly defined procedure or an automated process (IRRd + PERL).
> > Custom work required manhours from senior engineers, which is bad for the
> > bottom line.
> >
> > 5) Customer reachability to the BGP peer requires a properly functioning
> > IGP on the customer side for next hop reachability. ISPs loath to
> > involve themselves in customer IGP issues.
> >
> > We mostly use it for testing, providing BGP views to router manufacturers,
> > and for peering with route servers.
> >
> > - Dan Golding
> >
> > On Wed, 18 Oct 2000, Josh Richards wrote:
> >
> > > * SHI NOC List <shinoclist@cyberway.com.sg> [20001018 07:43]:
> > > >
> > > > I'd like to have some light in terms of EBGP multihop kind of
> configuration.
> > > >
> > > > I know some provider doesn't run EBGP multihop with customer while the
> > > > technology itself is in the market quite sometime.
> > >
> > > I don't know I'd exactly call it a technology, more like a feature of
> the
> > > protocol that is useful in some situations.
> > >
> > > > So is there any concern or reason that those provider are not willing
> to
> > > > run EBGP multihop?
> > >
> > > Because it doesn't apply to the application/situation? :-)
> > >
> > > Really...I mean there are uses for it where it may be legitimate to
> configure
> > > multihop (example: load balancing over 'n' T1 links to a provider so you
> > > peer with their loopback address) but if there isn't a specific
> situational
> > > requirement than there is no reason to do it. And if there is a
> specific
> > > situational requirement -- you'll know it -- because there will be no
> other
> > > way to accomplish whatever you're trying to accomplish.
> > >
> > > To more directly answer your question: From the perspective of reasons
> why
> > > a service provider would have a strict policy against it:
> > > - it may not be necessary for their environment/situation (i.e. they
> never
> > > connect to customers in ways that would require it)
> > > - they've had some bad experience with it in the past (i.e. they
> didn't
> > > set the TTL parameter and had interesting consequences)
> > > - they don't really have a reason -- they just don't do it because
> they've
> > > heard it's bad or something.
> > >
> > > If the ttl parameter (e.g. "ebgp-multihop 2") is not set you can get
> strange
> > > behavior (consider that there could very well be a path to your neighbor
> > > via one of your other neighbors...). But if you have an application in
> mind,
> > > know why you are doing it, and set the ttl as low as possible there is
> > > little reason to have some organization-wide policy saying "we don't do
> > > ebgp-multihop *ever*". I'd expect that if there are service providers
> who
> > > have told you they won't do ebgp-multihop they either felt it was not
> > > necessary for the situation at hand and there was another way to do it,
> or
> > > they just said it out of habit.
> > >
> > > -jr
> > >
> > > ----
> > > Josh Richards [JTR38/JR539-ARIN]
> > > <jrichard@geekresearch.com/cubicle.net/fix.net/freedom.gen.ca.us>
> > > Geek Research LLC - <URL:http://www.geekresearch.com/>
> > > IP Network Engineering and Consulting
> > >
> >
-- |=========----- -------=======| Unix, BASIC, C, PASCAL, APL, ADA, | Chris Roberts (chrisr@pavilion.net)| and PROFANITY spoken here. |=======------- -----=========| T: 0845 333 5000 F: 0845 333 5001
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:19 EDT