You want to use BGP to exchange routes with an external peer router that is more than one hop away. This situation can arise when the router at the edge of the network doesn't support BGP.
Cisco provides a useful option called eBGP multihop, which allows you to establish eBGP peer relationships between routers that are not directly connected to one another:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#ip route 172.20.1.2 255.255.255.255 192.168.1.5 2 Router1(config)#router bgp 65500 Router1(config-router)#neighbor 172.20.1.2 remote-as 65530 Router1(config-router)#neighbor 172.20.1.2 update-source Loopback0 Router1(config-router)#neighbor 172.20.1.2 ebgp-multihop Router1(config-router)#end Router1#
In this example, we have only shown the configuration for one of the routers, although you will need to configure the ebgp-multihop keyword for the corresponding peer device as well.
This feature is not a standard part of the BGP protocol, but several router vendors implement it. The standard behavior requires eBGP routers to be adjacent to one another.
You might want to use this feature, for example, if the router at the edge of either your AS or the AS you are connecting to doesn't support BGP. The router will also need to have a route to the destination device, because it is not directly connected. We have included a static route for this purpose.
The ebgp-multihop keyword takes an optional argument, which can be any integer between 1 and 255. This represents the maximum number of hops between this router and the neighbor, which is used in the TTL field of the IP packet when establishing the peer connection. If you don't specify ebgp-multihop, the router will assume that the peers are adjacent and use a TTL value of 1. However, if you specify this keyword without an argument, the router will default to a TTL value of 255.
Note that you can cause some seriously strange routing problems using a high TTL value with this option. Suppose you have two ISPs, and your connection to one of them becomes unavailable. The routers could discover another path to one another, and reestablish their BGP peer relationship through the second ISP. This would cause extremely inefficient routing. You can avoid this problem by using static host routes and directing traffic for each peer router through the correct circuit.
In general, we recommend using the lowest possible value that still reaches the destination. However, the IETF has recently published the draft document, http://www.ietf.org/internet-drafts/draft-gill-btsh-02.txt, which describes another extremely interesting way of using this feature to improve security. The idea is that the only way that a packet can reach its destination with a TTL value of 254 or 255 is if the source is adjacent to the destination. If a more distant device were to attempt a BGP spoofing attack, the packets would arrive with a lower TTL value unless the attacker was also on a physically adjacent network.
This document suggests deliberately configuring your routers to use the highest possible TTL value. Then the routers would check the TTL value and discard any BGP packets with a TTL of less than 254. Unfortunately, we are not aware of any way to implement this idea on a Cisco router today because IP access lists do not include a way to filter based on TTL values. However, if this idea catches on, it seems likely that Cisco would provide a way to do this.
In the meantime, the best way to secure your BGP peers is to use MD5 authentication, as discussed in Recipe 9.16.
Recipe 9.16; The BGP TTL Security Hack (BTSH), http://www.ietf.org/internet-drafts/draft-gill-btsh-02.txt, December 2002
|
|
|
| Top |