Neighbor Configuration Issues

There is very little overhead in establishing a peer group, even with only a single member. This approach makes it very easy to add members with identical outgoing policy to the group at a later stage. You may consider defining a peer group for all neighbors, even if the peer group membership consists of only one neighbor.

A description can be added to a peer group or an individual neighbor using the neighbor { ip-address | peer-group-name } description textcommand. Because you cannot store free-text comments in Cisco configurations, this is an ideal way to add documentation to a particular peering session.

Applying the neighbor { ip-address | peer-group-name } next-hop-selfcommand to a neighbor or peer group ensures that all next hops for the EBGP-learned routes are set to the peering address for this session. As discussed in conjunction with the next hop attribute earlier in this chapter, this configuration command can obviate the need to carry external networks used for peering within your IGP, and ensure that you meet the peering policies of providers at public NAPs by removing any third-party next hops.

Using physical interface addresses for BGP peering purposes can reduce network reliability. If the physical interface goes down, any BGP sessions using the IP address of the interface as an endpoint will also be closed. Reliability can be increased by using the addresses of loopback interfaces instead of physical interfaces for peering purposes. Loopback interfaces are virtual interfaces on the router; they are always up, unless disabled by a software switch on the router.

IBGP sessions can be configured to use loopback addresses by using the neighbor { ip-address | peer-group-name] update-source loopback BGP router configuration command. It is highly recommended that you use this approach for IBGP.

For EBGP, the situation is not as critical because most peering is performed over a single physical link or LAN. However, if you wish to perform EBGP peering over redundant physical links, this can be achieved using neighbor { ip-address | peer-group-name} ebgp-multi-hop [ttl] This BGP router-configuration command enables the establishment of EBGP peering to neighbors beyond a directly connected physical interface. The optional ttlsets the TTL of outgoing IP packets used in establishing the BGP session—this limits the number of router hops the EBGP session may traverse. If you use the command, the update source can be set to a loopback address as for IBGP peers; once again, this ensures that the peering session will survive the failure of physical infrastructure.

EBGP sessions are automatically reset if the physical interface over which the session is held goes down. In large networks, possibly containing many links that are not completely reliable (loss of carrier may occur for brief periods), you may wish to disable this behavior and opt for session-reset due to keepalive failure only. This is achieved using the no bgp fast-external-fallover BGP router command. The drawback of this command is that, in the event of sustained link outage, the convergence time on a new route will increase.

BGP will auto-negotiate version. However, to save any surprises (for example, because BGP versions before 3 were not classless), it is also wise to explicitly set the neighbor version to 4.

Finally, consider using passwords on all BGP sessions. This prevents the session from being established if the remote end does not have the same password configured. This also can provide increased protection from "hacker attacks" on BGP architecture. In addition, if you use different passwords for each neighbor, this can protect against accidental misconfiguration, such as applying the wrong IP address to a peer.

Was this article helpful?

0 0

Post a comment