Peer Groups

A BGP peer group is a group of BGP neighbors that share the same update policies. Update policies are usually set by route maps, distribution lists, and filter lists. Instead of defining the same policies for each individual neighbor, you define a peer group name and assign policies to the peer group.

The use of BGP peer groups is demonstrated by the network shown in figure10-3. RTC forms similar internal peering sessions with RTD, RTE, and RTH. Instead of formulating and applying similar policies for each neighbor individually, RTC would define a peer group that contains the policies and would apply the peer group to its internal neighbors.

Figure 10-3  BGP peer groups.

RTC configuration:

       router bgp 1
        neighbor INTERNALMAP peer-group
        neighbor INTERNALMAP remote-as 1
        neighbor INTERNALMAP route-map INTERNAL out
        neighbor INTERNALMAP filter-list 1 out
        neighbor INTERNALMAP filter-list 2 in
        neighbor 172.16.11.1 peer-group INTERNALMAP
        neighbor 172.16.13.1 peer-group INTERNALMAP
        neighbor 172.16.12.1 peer-group INTERNALMAP
        neighbor 172.16.12.1 filter-list 3 in

The preceding configuration defines a peer group called INTERNALMAP that contains the following policies:

•  A route map named INTERNAL

•  A filter list for outgoing updates (filter list 1)

•  A filter list for incoming updates (filter list 2)

The configuration applies the peer group to all internal neighbors—RTD, RTE, and RTH.

Members of a peer group inherit all the configuration options of the peer group. Peer group members can also be configured to override configuration options if the options do not affect outgoing updates. That is, peer group members can be configured to override options that affect incoming policies. The configuration of RTC, for example, also defines a filter-list 3 for incoming updates from the neighbor at IP address 172.16.12.1 (RTH). Filter-list 3 will override any incoming policies set by the peer group INTERNALMAP for neighbor RTH.

The following commands configure a BGP peer group named EXTERNALMAP on RTC and apply it to the exterior neighbors in AS3 and AS2:

RTC configuration:

    router bgp 1
     neighbor EXTERNALMAP peer-group
     neighbor EXTERNALMAP route-map SETMED out
     neighbor EXTERNALMAP filter-list 1 out
     neighbor EXTERNALMAP filter-list 2 in
     neighbor 172.16.20.2 remote-as 3
     neighbor 172.16.20.2 peer-group EXTERNALMAP
     neighbor 172.16.20.3 remote-as 2
     neighbor 172.16.20.3 peer-group EXTERNALMAP
     neighbor 172.16.20.3 filter-list 3 in

    ip as-path access-list 1 permit ^$

In the preceding configuration, the neighbor remote-as router configuration commands are placed outside the neighbor peer-group router configuration commands because different external ASs have to be defined. Also note that this configuration defines filter-list 3, which can be used to override configuration options for incoming updates from the neighbor at IP address 172.16.20.3 (RTF).

Note that the external BGP neighbors RTA and RTF that belong in the same peer group EXTERNALMAP were taken from the same subnet 172.16.20.0. This restriction is needed to prevent loss of information. Placing the external neighbors in different subnets could result in RTC sending updates to its neighbors (RTA and RTF) with a non-connected next hop IP address. These updates would be dropped due to the normal EBGP behavior of ignoring routes with non-connected next hop (remember that ebgp-multihop was implemented to override this behavior).

Another restriction that also applies is that peer groups should not be set on EBGP neighbors if the router is acting as a transit between these neighbors. If the router (RTC) is passing updates from one external neighbor to the other, placing external neighbors in peer groups might result in routes being mistakenly removed. Note that filter-list 1 has been defined to allow AS1's local routes only to be sent to neighbors RTA and RTF. This way RTC will not act as a transit router between RTA and RTF.

As you can see, using peer groups with external BGP peers is no longer intuitive because of limiting restrictions. Using peer groups with EBGP peers should be done with care in order not to cause loss of routes.

Sources of Routing Updates

Routes can be injected dynamically or statically into BGP. The choice of method depends on the number and stability of routes.

Injecting Information Dynamically into BGP

The following example demonstrates how routing information can be injected dynamically into BGP. Consider figure 10-4. Assume that AS3 is getting Internet connectivity from AS1. AS3 is running OSPF as an IGP inside the AS and is running EBGP with AS1.

Figure 10-4  Injecting routes into BGP.

On the other hand, AS3 has also one customer, C1, with the following criteria:

•  C1 is pointing a default toward AS3.

•  C1 advertises all its routes to AS3 via RIP.

RTF is running two routing processes, the OSPF process and the RIP process. RTF will only listen to RIP on its connection to C1 and will redistribute the RIP updates it gets from C1 into OSPF. On the other hand, RTA will run two routing processes, the OSPF process and the BGP process. RTA will inject all its routes and customer routes dynamically into BGP.

RTF configuration:

    interface Ethernet1/0
     ip address 172.16.65.1 255.255.255.192

    interface Ethernet1/1
     ip address 172.16.1.2 255.255.255.0

    interface Serial2/1
     ip address 192.68.5.1 255.255.255.0

    router ospf 10
     redistribute rip subnets
     network 172.16.0.0 0.0.255.255 area 0

    router rip
     passive-interface Serial2/1
    network 192.68.5.0