Hi -
I have searched the archives but have not found an answer to my question - is there any danger in using excessively high TTL values with ebgp-multihop? For example, neighbor x.x.x.x ebgp-multihop 255 - 255 is generally much higher than needed, but is there any risk/danger ?? Thanks in advance. - Tim
Tim Rand
Network Engineer
OHSU Information Technology Group
ph: 503.418.1045
fx: 503.494.7143
Hi -
I have searched the archives but have not found an answer to my question - is there any danger in using excessively high TTL values with ebgp-multihop? For example, neighbor x.x.x.x ebgp-multihop 255 - 255 is generally much higher than needed, but is there any risk/danger ?? Thanks in advance. - Tim
The number of hops in an ebgp-multihop scenario isn’t usually the concern. When using ebgp sessions to null route baddies, the peer can be an unspecified number of hops away. I would consider 255 to be overkill, but not much harm. In normal routing, I would try to keep the hop count within 1 or 2. It’s just a good practice. Remember, every router between the two sessions has to also know the route. Perhaps some of the older folks have some better tidbits of advice.
-Jack
* Tim Rand <randt@ohsu.edu> [030227 16:39]:
Hi -
I have searched the archives but have not found an answer to my question
- is there any danger in using excessively high TTL values with
ebgp-multihop? For example, neighbor x.x.x.x ebgp-multihop 255 - 255 is
generally much higher than needed, but is there any risk/danger ??
Thanks in advance. - Tim
There is a potential for blackholing traffic should you be dual (or multi)
homed and if the ebgp-multihop session were able to re-establish over
another path. Better to keep it close to what you'd expect your maximum
number of hops to be to reduce the potential for undesirable modes.
-Steve
If you use this for a regular BGP feed (one where you actually send
traffic as per the routes received) you can get interesting results if
your direct connection to the peer goes down. Your BGP session will
probably survive this and simply continue to run over any other
connection(s) to the net you have. You can of course make sure this
doesn't happen by creative application of static routes with different
administrative distances (or even a filter).
Nooooo!
eBGP multihop carries with it the implicit possiblity
of session highjacking - in a normal (Multihop=1)
session, the router would not be able to find a
duplicate neighbor with the specified IP address
directly connected. Obviously, once you're saying
that the neighbor could be anywhere in the world,
what's to prevent me assigning my home Macintosh with
a second IP address and injecting whatever I want into
your network?
Second, Multihop is really a kludge: eBGP is ideally
run at the edge of a network across a point-to-point
(or shared) medium, and there really shouldn't be
multiple paths to eBGP neighbors. If your link to ISP
X goes away, do you really want to have your router
think that ISP X is still available? Or would you
rather just fail-over to a backup path?
iBGP is another matter -> there you want 255, b/c you
want the sessions to stay up even in the event of a
backbone link flap.
Nooooo!
eBGP multihop carries with it the implicit possiblity
of session highjacking - in a normal (Multihop=1)
Everyone uses md5 signature/bgp password/
authentication keys correct?
That means this isn't an issue 
session, the router would not be able to find a
duplicate neighbor with the specified IP address
directly connected. Obviously, once you're saying
that the neighbor could be anywhere in the world,
what's to prevent me assigning my home Macintosh with
a second IP address and injecting whatever I want into
your network?Second, Multihop is really a kludge: eBGP is ideally
run at the edge of a network across a point-to-point
(or shared) medium, and there really shouldn't be
multiple paths to eBGP neighbors. If your link to ISP
X goes away, do you really want to have your router
think that ISP X is still available? Or would you
rather just fail-over to a backup path?iBGP is another matter -> there you want 255, b/c you
want the sessions to stay up even in the event of a
backbone link flap.
Depends on the size of the flap and router
convergence times.
- Jared
eBGP multihop carries with it the implicit possiblity
of session highjacking - in a normal (Multihop=1)
session, the router would not be able to find a
duplicate neighbor with the specified IP address
directly connected. Obviously, once you're saying
that the neighbor could be anywhere in the world,
what's to prevent me assigning my home Macintosh with
a second IP address and injecting whatever I want into
your network?
Just because you assign that second IP address to your Mac does not mean
that anyone else in the world is going to see that announcement, which, in
turn, would not let you to hi-jack the session.
Alex