Friday, March 18, 2011

BGP Peer Groups, BGP Synchronization, Source IP Address, EBGP Multihop, and Next-Hop Attribute Configuration

Advanced BGP Network

In BGP, many neighbors are often configured with the same update policies, eg: they have the same route filtering applied. Neighbors with the same update policies can be grouped into peer groups to simplify configuration and improve route update efficiency and save resources, in which updates are generated once per peer group, rather than once for each neighbor. This approach is highly recommended when a router has are many peers.

Instead of separately defining the same policies for each neighbor, a peer group can be defined with these policies (similar to a template) assigned to the peer group. Individual neighbors are then configured as the members of the peer group; the template is then applied upon all the members of the peer group. Note that only the options that affect the incoming updates can be overridden for particular members of a peer group – a peer group is a set of BGP neighbors that share the same outbound policy, but their inbound policies may be different.

The neighbor {peer-group-name} peer-group BGP router subcommand creates a peer group. The peer group name is local only to the router it is configured on and not passed to other routers. The neighbor {ip-addr} peer-group {peer-group-name} BGP router subcommand assigns a neighbor as a member of a peer group. A neighbor can be a member of only one peer group.

The BGP synchronization rule states that a BGP router cannot use an IBGP-learned route and advertise it to an EBGP neighbor; unless the BGP and IGP routing tables are synchronized. When BGP synchronization is disabled, BGP can use IBGP-learned routes that are not present in the local routing table. BGP synchronization can be disabled for stub ASes; or if all routers in the BGP transit path with a transit AS are running BGP – full-mesh IBGP. Disabling this feature reduced the number of routes carried in IGP and allows BGP to converge more quickly.

The neighbor command tells the BGP process the destination IP address of the BGP packets; the BGP process must decide the IP address to use as the source IP address for the BGP packets. When the BGP process creates a packet, it performs a routing table lookup for the destination address and use the IP address of the outbound interface towards the destination address as the source address for BGP packets by default.

The source IP address must match the address in the corresponding neighbor command on the other BGP router. Otherwise, the BGP routers will not be able to establish a BGP session. BGP does not accept unsolicited packets; it must have a neighbor statement for every neighbor.

The IP addresses of loopback interfaces are often being used to establish IBGP sessions when there are multiple paths between the IBGP neighbors. The neighbor {ip-addr | peer-group-nameupdate-source loopback {intf-num} BGP router subcommand informs a BGP router to use the IP address of its loopback interface as the source for BGP connections to its neighbors.

Peering using loopback interfaces adds resiliency to the IBGP sessions, as the IBGP sessions no longer tied to any physical interface, which might go down for many reasons. Note that the routers must have a route to the loopback address of the other neighbor in their IGP routing table.

BGP does not require neighbors to be directly attached to the same subnet. BGP routers use TCP Port 179 connections for exchanging BGP messages; therefore allowing neighboring routers to reside on the same subnet, or separated by several routers, which is relatively common.

When peering with an EBGP neighbor, BGP can reach the IP address of the directly connected EBGP neighbor without further configuration, and it is used as the destination address by default. Since loopback is never directly connected and EBGP neighbors never run IGP between them, static routes pointing to the physical address of the directly connected neighbor must be used, and EBGP multihop must also be enabled.
Tip: Peer between loopback interfaces when peering between routers within the same AS – IBGP; peer to physical interfaces when peering with external ASes – EBGP, for faster failover.

EBGP packets have a Time To Live (TTL) of 1 and hence only directly connected neighbors are allowed by default. The neighbor {ip-addr | peer-group-name} ebgp-multihop [ttl] BGP router subcommand configures a BGP router to accept and attempt EBGP connections to EBGP neighbors that are not directly connected. The neighbor ebgp-multihop command sets the TTL to 255 by default if the optional ttl parameter is not specified. This command must be used whenever the EBGP neighbors are more than one hop way, includes peering to loopbacks.
Note: IBGP packets always have a TTL of 255 and no command is available to change it.

When there are multiple physical connections between EBGP neighbors, using loopback interfaces and static routes to the loopback interfaces allow load balance between the connections.

It is sometimes necessary to override the default behavior of a BGP router and configure it advertise itself as the next-hop for the routes advertised to a neighbor.

In this sample scenario, instead of advertising the route to RT1 – through an IGP, the next-hop-self configuration can be implemented on the AS border BGP routers, RT2 in this case, to override the default next-hop address – with the IP addresses of the AS border routers, in this case. IBGP peers (RT3 and RT4) within AS 65002 would then forward packets destined to the external networks – through RT2.

No comments:

Post a Comment