From: johngibson1541@yahoo.com
Date: Sat Jul 14 2007 - 15:22:17 ART
I think this should be just 1.
But if I do "neighbor A.B.C.D ebgp-multihop" , then "neighbor
A.B.C.D ebgp-multihop 1", the first config line will be removed by IOS .
I want to peer to immediate neighbor's loopback interface but not any
hops further for security. If I set the ttl to 2, not only that the
immediate neighbor's loopback interface can be peered, but also the
immediate neighbor's neighbor. Even worse, the immediate neighbor's
neighbor's loopback interface can be peered without restriction.
Command reference says the integer following "ebgp-multihop"
is the TTL for out going packets.
The reason IOS removes the first command "neighbor A.B.C.D ebgp-multihop"
is because, when TTL is 1 , it would to reach the immediate neighbor's
loopback. And the designers don't like that.
I have tested if a peering immediate neighbor's loopback interface
is already established, then config TTL to 1 (which actually stops
allowing multihop), the keepalive message can go through with
TTL==1 and keep the peer relationship alive.
I think many users think "neighbor A.B.C.D ebgp-multihop 2" allows peering
to as far as the immediate neighbor's loopback. They
are misled to believe that. When TTL==2, the packet can go
beyond the immediate neighbor. It can reach the immediate
neighbor's neighbor AND the loopback interfaces of that "neighbor's
neighbor"!
The end result is that IOS's ebgp-multihop can NOT achieve
restricting peering to ONLY the immediate neighbor's any
interface. It either restricts to only the immediate neighbor's
interfaces facing us or allow peering to the immediate neighbor's
neighbor or beyond.
But I can't figure out why they try so hard to prevent explicit
setting TTL=1 with multihop to the level they can tolerate that
handicap.
This archive was generated by hypermail 2.1.4 : Sat Aug 18 2007 - 08:17:41 ART