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
From: Tim Rand 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
On Thu, 27 Feb 2003, Tim Rand wrote:
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
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. --- Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On Thu, 27 Feb 2003, Tim Rand wrote:
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
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).
===== David Barak -fully RFC 1925 compliant- __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
On Thu, Feb 27, 2003 at 07:29:29PM -0800, David Barak wrote:
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
participants (7)
-
alex＠yuriev.com -
David Barak -
Iljitsch van Beijnum -
Jack Bates -
Jared Mauch -
Steve Carter -
Tim Rand