In typical BGP configurations, you can use cooperative route filtering to reduce the amount of processing required for inbound BGP updates and the amount of BGP control traffic generated by BGP updates. Cooperative route filtering works by having the remote peer install a BGP speaker’s inbound route filter as its own outbound route filter. This filtering causes the remote peer to advertise only those routes that the local peer can accept.
For BGP/MPLS VPNs, route-target filtering is a better approach. Route-target filtering controls the distribution of BGP routes based on the VPNS (indicated by the route-target extended communities) to which peer routers belong. PE routers use the MP_REACH_NLRI and MP_UNREACH_NLRI attributes in BGP updates to exchange information about each router’s route-target membership.
The PE router subsequently advertises VPN NLRI—the routing information carried in MP-BGP update messages—only to peers that are members of a route target that is associated with the VPN route. The VPN routes flow in the opposite direction to the route-target membership information.
Route-target filtering works across multiple ASs and with asymmetric VPN topologies, such as a hub-and-spoke. Route-target filtering can reduce the size of the BGP routing table in PE routers, as well as the amount of VPN NLRI exchange traffic between routes in the VPN. Route-target filtering also reduces router memory requirements by reducing the amount of routing information stored and propagated. For example, route reflectors scale according to the total number of VPN routes present in their network. With route-target filtering, you can reduce the scaling requirements of the reflectors by restricting the number of VPN routes they must process to only those VPN routes actually used by the route reflector clients.
Applications such as BGP/MPLS VPNs, VPLS L2VPNs, and VPWS L2VPNs all use route targets as part of their route reachability information, and can therefore employ route-target filtering and potentially accrue the benefits of reduced traffic and smaller routing tables.
BGP peers exchange route-target membership information in the following sequence:
AS number:route-target extended community/prefix length
For example, 100:100:53/36 is a valid RT--MEM-NLRI.
BGP speakers advertise and withdraw the RT-MEM-NLRI attribute in MP-BGP update messages. BGP speakers ignore RT-MEM-NLRI attributes received from peers that have not successfully negotiated this capability with the speaker.
If dynamic negotiation for the route-refresh capability is enabled, BGP negotiates the route-refresh capability for the RT-MEM-AFI-SAFI address family when a peer is activated in that family. As a consequence, you can use the clear ip bgp soft command to refresh the RT-MEM-NLRI routes in the BGP speaker’s Adj-RIBs-Out table.
The usefulness of BGP VPN route-target filtering depends on the sparseness of route target membership among the VPN sites. In configurations where VPNs are members of many route target communities—that is, route target membership is dense—the amount of VPN NLRI exchange traffic is about the same regardless of whether route-target filtering is configured.
RT-MEM-NLRI routing updates are processed in the following sequence:
You can use the bgp wait-on-end-of-rib command to specify how long BGP waits for the End-ofRIB marker from route-target peers.
When the route-refresh capability has been negotiated for the route-target address family. BGP handles route-refresh messages for the RT-MEM-AFI-SAFI by resending all RT-MEM-NLRI routes to the remote peer
You can use the neighbor maximum-prefix command to specify the maximum number of prefixes that the speaker can receive from a BGP peer.
Route-target filtering generally follows the standard BGP rules for route advertisement to determine when to advertise RT-MEM-NLRI prefixes that have been received from BGP peers. Table 61 lists the destinations that the prefixes are advertised to based on their source. In this table, client-to-client reflection is enabled and the source and destination peers are not the same.
Table 61: Route-Target Filtering Advertisement Rules for Routes Received from Peers
Advertising to IBGP clients varies from the standard advertisement rules in terms of path attribute modifications. When locally originated RT-MEM-NLRI routes are advertised to IBGP route reflector clients, BGP does the following:
This behavior is useful when the route reflector does not advertise the Default-RT-MEM-NLRI route.
When locally originated RT-MEM-NLRI routes are advertised to IBGP route reflector nonclients, the route from the client is advertised to the nonclient peer when the best path route is advertised by a nonclient but an alternative route from a client exists. This behavior signals the client’s interest in the route target routes that were not selected as the best path.
You cannot filter RT-MEM-NLRI routes with inbound policies or outbound policies, because policy items cannot currently match a RT-MEM-NLRI prefix (origin AS number:route target). However, you can filter route-target filtering routes with policies that include items that match on other BGP attributes, such as the extended community attached to the route-target filtering route.
bgp wait-on-end-of-rib
- host1(config-router)#address-family route-target
signaling
- host1(config-router-af)#bgp wait-on-end-of-rib
360
neighbor maximum-prefix
- host1(config-router)#address-family route-target
signaling
- host1(config-router-af)#neighbor maximum-prefix
10.1.2.3 100
The following conditions must be met for routes in the route-target address family to be advertised to a BGP peer:
In a VRF, a RT-MEM-NLRI attribute represented by (origin AS number:route target) is advertised for every route target added to the VRF's route target import list when the preceding conditions have been met.
A withdrawal for the RT-MEM-NLRI attribute is generated when the route target is removed from this VRF's import list.
You can configure BGP to send a default route to indicate that the speaker accepts routes for any VPNs associated with any route target. For example, this might be desirable for a route reflector advertising to one of its PE router clients, or when a VPN provider is migrating the network to route-target filtering but one or more PEs in the provider's network do not support this feature.
When you configure the default route, the RT-MEM-NLRI attribute contains 0:0:0/0 as the Default-RT-MEM-NLRI. This 4-byte prefix contains only the local (origin) AS number field, set to zero.
By default, BGP does not generate or advertise the Default-RT-MEM-NLRI route. You can use the default-information originate command to generate the Default-RT-MEM-NLRI route and send it to all peers. You can use the neighbor default-originate command generate the route and send it to a particular peer group. The configuration must be the same for all members of the peer group.
A BGP speaker sends the Default-RT-MEM-NLRI route only to the peers with which it has negotiated the route-target filtering capability. Any other peers are considered to be unaware of this capability and have no use for that route.
default-information originate
- host1(config-router)#router address-family
route-target
- host1(config-router-af)#default-information
originate
neighbor default-originate
- host1(config)#router bgp 100
- host1(config-router)#router address-family
route-target
- host1(config-router-af)#neighbor default-originate
When route-target filtering is enabled for a peer, BGP applies outbound filters to initially prevent the speaker from advertising any VPN routes to the peer.
If the BGP speaker subsequently receives a Default-MEM-NLRI route from a peer, BGP applies outbound filters for the peer to prevent route-target filtering from suppressing any VPN routes sent to the peer.
BGP follows the standard route selection process to find the route-target filtering best path for RT-MEM-NLRI routes received from other autonomous systems. The selection is based on the AS path and other MP-NLRI path-attributes attached to the route.
The route-target membership information, which includes the route target and the originator AS number, enables BGP speakers to use the standard path selection rules to remove duplicate, less-preferred paths from the total set of paths to route-target membership peers.
For RT-MEM-NLRI routes that originated within the local AS and are received from an IBGP peer, BGP considers the route-target filtering best path to be the set of all available IBGP paths for the RT-MEM-NLRI prefix. BGP then sets outbound route filters so that VPN routes that match the route target are sent to all IBGP peers that advertised the RT-MEM-NLRI route. This behavior does not affect how the BGP speaker in turn advertises the RT-MEM-NLRI routes.
When BGP selects a RT-MEM-NLRI route from a peer as the best path for the RT-MEM-NLRI prefix, BGP modifies the outbound filters to enable the speaker to advertise to that peer all VPN routes that correspond to that route target. These filters affect the subsequent calculation of the peer's Adj-RIBs-Out entries.
EBGP confederation peers are treated as IBGP peers when the BGP speaker is selecting the route-target filtering best path. When the BGP speaker advertises routes, then the EBGP confederation peers are treated normally, as EBGP peers.
You can control the maximum number of received EBGP best paths that are considered for path selection. The external-paths command limits external route target membership, thus controlling the number of EBGP peers that receive the route target VPN routes referenced by the RT-MEM-NLRI route. BGP ignores routes received from the peer after the limit specified with the external paths command is reached.
To configure route-target filtering:
The AS number identifies the PE router to other BGP routers.
- host1(config)#router bgp 738
- host1(config-router)#neighbor 10.2.2.2 remote-as
45
- host1(config-router)#neighbor 10.2.2.2 update-source
loopback 0
- host1(config-router)#neighbor 10.2.2.2 next-hop-self
Optionally, you can use the signaling keyword with the address-family command when you configure the route-target address family to specify BGP signaling of reachability information. Currently, you can omit the signaling keyword with no adverse effects.
- host1(config-router)#address-family route-target
signaling
- host1(config-router-af)#neighbor 10.2.2.2
activate
- host1(config-router-af)#neighbor 10.2.2.2
next-hop-self
- host1(config-router-af)#default-information
originate
- or
- host1(config-router-af)#neighbor 10.2.2.2
default-originate
- host1(config-router-af)#external-paths 2
external-paths
- host1(config-router)#external-paths 45
- host1:vr1(config-router-af)#external-paths
45