Outbound Route Filtering (ORF) and Route Refresh Features

One of the features that helps scale the MPLS/VPN architecture is its capability to keep only the relevant routes in the PE-router?each router keeps only routes for VPNs that are connected to that router. This scalability feature is achieved by importing only the VPN-IPv4 routes that are relevant to the VRFs that are configured on the PE-router.

However, the problem with this model is that all BGP routes are kept within the BGP table even though they are not used by any of the VRFs or by the global routing table. This is quite obviously a waste of resources, both in terms of memory on the PE-routers and in the advertisement of this information across the backbone to PE-routers that do not use it.

With this in mind, it obviously is desirable either to not receive or to filter any unwanted routes from the BGP table of the PE-router. You can do this a number of ways, some of which we discuss in this chapter. You can use other, more advanced options, such as the partitioning of MP-iBGP sessions between PE-routers and the deployment of route reflectors, each of which is discussed in Chapter 12.

Automatic Route Filtering on PE-routers

Because some PE-routers might receive routing information they do not require, a basic requirement is to be able to filter the MP-iBGP updates at the ingress to the PE-router so that the router does not need to keep this information in memory. Although other mechanisms exist, such as the ones discussed in Chapter 12, that prevent the PE-router from actually receiving unwanted routing information, this method might be appropriate if the size or the complexity of the network does not justify partitioning the network into segments. It also might be appropriate if the VPN information is scattered in a topology that is difficult to partition.

The Automatic Route Filtering feature fulfills this filtering requirement. This feature is available by default on all PE-routers, and no additional configuration is necessary to enable it. Its function is to filter automatically VPN-IPv4 routes that contain a route target extended community that does not match any of the PE's configured VRFs. This effectively discards any unwanted VPN-IPv4 routes silently, thus reducing the amount of information that the PE has to store in memory. Figure 9-9 shows how this feature is implemented.

Figure 9-9 shows that the New York PE-router receives two MP-iBGP updates. It has only one VRF configured, and it belongs to the NYBank VRF, which imports routes that contain a route target of 100:26 or 100:28.

The first update, sent by the San Jose PE-router, contains a route with a route target of 100:26. This route is accepted and imported into the NYBank VRF. The second update, sent by the Paris PE-router, contains a route with a route target of 100:27. Because the NYBank VRF is not configured to import routes that contain this route target, and because the New York PE-router has no other VRFs that use this particular route target, the update is dropped. Example 9-22 provides an example showing the update being rejected because the route target is not relevant to the New York PE-router.

Example 9-22 Automatic Route Filtering Feature Debug

New York# debug ip bgp update



BGP(1): 10.4.1.21 rcvd UPDATE w/ attr: nexthop 10.4.1.21,

origin ?, localpref 100, metric 0, extended community RT:100:27

BGP(1): 10.4.1.21 rcvd 1:27:196.7.25.0/24 -- DENIED due to

:  extended community not supported;

But what if the PE-router is acting as a route reflector for other PE-routers? In this case, if it were to filter the routes automatically, the routing information would be lost. Therefore, the Automatic Route Filtering feature is acceptable only on a normal PE-router, and is disabled if the PE-router acts as a route reflector of VPN-IPv4 prefixes.

As with all service provider networks, it is safe to assume that VPN policies and VRF configurations change over time. The policy change might mean that a new customer is added (or deleted) to the VPN service, or it might mean that an existing VPN customer has a new site that needs to be commissioned into the backbone. In either case, the propagation of routing information changes, and certain PE-routers within the network need to import this information. If you refer to Figure 9-9, an example of this type of change might be that the EuroBank VPN customer needs to commission a new site in New York. Because the SuperCom New York PE-router is the best entry point into the MPLS/VPN backbone for this location, this new site is added to the New York PE-router.

The implications of this are that the New York PE-router needs all relevant routes that belong to the EuroBank VPN. However, because the New York PE-router did not have any VRFs previously configured that imported the route target used for the EuroBank VPN, it discards all routing information that was relevant to the EuroBank VPN. Therefore, further mechanisms are required in conjunction with the Automatic Route Filtering feature and these are the route refresh and ORF features.

Refreshing Routing Information Between PE-routers

When the policy of a PE-router changes, such as a new VRF is added or an existing one is modified, the PE-router needs to obtain routing information that it previously discarded. The PE-router achieves this by using a new BGP capability known as Route Refresh.

When this feature is used, the PE-router, shortly after its configuration is changed, requests a retransmission of routing updates from its MP-iBGP neighbors to obtain any missing VPN-IPv4 information. The delay is necessary because several changes to the inbound policy might occur at once, so it is desirable that only one Route Refresh be sent.

The routing information received in response to the Route Refresh is subject still to the filtering mechanisms already described. However, if a new route target is configured on the PE-router for import, for example, then all VPN-IPv4 addresses that contain that route target are no longer filtered at the PE.

Figure 9-10 provides an example of this feature, and Example 9-23 illustrates the necessary debug output.

This figure shows that a new VRF, for the EuroBank VPN, is configured on the New York PE-router (Step 1). This router sends a Route Refresh to its MP-iBGP neighbors (Step 2), in this case, the San Jose and Paris routers, which in turn re-send all their VPN-IPv4 routes (Step 3).

Example 9-23 Route Refresh Capability Debug

New York# debug ip bgp

New York# conf t

Enter configuration commands, one per line.  End with CNTL/Z.

New York(config)#ip vrf EuroBank

New York(config-vrf)# rd 1:27

New York(config-vrf)# route-target both 100:27



BGP: 194.22.15.3 sending REFRESH_REQ for afi/safi: 1/128

The Route Refresh feature is similar to the Cisco soft reconfiguration feature with the difference that there is no need to store unnecessary routing information on the PE-router. As with the Automatic Route Filtering feature, the Route Refresh feature is on by default and no additional configuration is necessary. Example 9-24 shows this capability using the show ip bgp neighbor command.

Example 9-24 Route Refresh Capability?PE Identification

New York# show ip bgp neighbor 194.22.15.1

BGP neighbor is 2.2.2.2,  remote AS 1, internal link

  BGP version 4, remote router ID 197.1.1.1

  BGP state = Established, up for 00:07:02

  Last read 00:00:02, hold time is 180, keepalive interval is 60

  seconds

  Neighbor capabilities:

    Route refresh: advertised and received

    Address family IPv4 Unicast: advertised and received

    Address family VPNv4 Unicast: advertised and received

  Received 13327 messages, 0 notifications, 0 in queue

  Sent 13434 messages, 0 notifications, 0 in queue

  Route refresh request: received 9, sent 30

  Minimum time between advertisement runs is 5 seconds

You also can achieve a manual refresh of VPN routing information using the clear ip bgp command. This command has been enhanced for the VPN environment so that it is possible to clear BGP sessions on a per-neighbor basis, or on a per?address-family basis. When this command is issued, all relevant neighbors receive a Route Refresh message and refreshed MP-iBGP or BGP information. Figure 9-11 shows a sample topology.

Figure 9-11 shows that the command clear ip bgp * vrf EuroBank in is issued on the San Jose PE-router (Step 1). This causes a Route Refresh message to be sent to the San Francisco CE-router because this is the only external neighbor that populates the EuroBank VRF through BGP.

The command clear ip bgp * vpnv4 unicast in also is issued on the San Jose PE-router (Step 2). This causes a Route Refresh to be sent to all PE neighbors, in this case the New York and Paris routers. Enhancing this command with a specific neighbor address causes the Route Refresh to be sent to that neighbor only, for example, the clear ip bgp 2.2.2.2 vpnv4 unicast in command causes the Route Refresh to be sent to the PE-router with the address 2.2.2.2. No other PE-router receives the Route Refresh message.

ORF for PE-routers

The Route Refresh and Automatic Route Filtering features provide the mechanisms to help reduce the amount of routing information that a PE-router needs to hold. However, they do not provide the capability to stop this routing information from actually arriving at the PE-router. This means that unnecessary routing information is propagated around the network only to be discarded by certain PE-routers.

The ORF feature provides this functionality and it works in conjunction with the previously described Route Refresh feature. Again, this feature is actually a new BGP capability and is exchanged during session establishment between two PE-routers through the use of the BGP OPEN message.

This feature allows a BGP speaker to advertise to downstream neighbors the outbound route filters they should use. These filters are described in ORF entries, which are part of the Route Refresh message. Figure 9-12 shows this message format.

Each ORF entry carries an ORF-type that describes the format of the ORF entry within the message. Table 9-3 shows the currently defined ORF-type.

After the Prefix-list ORF capability is advertised by a BGP speaker, its neighbor can push over its inbound prefix-list filter. This is useful between two PE-routers as they will apply the received prefix-list filter, in addition to their locally configured outbound filters (if any), to constrain/filter their outbound routing updates to each other. This mechanism can be used to avoid unwanted routing updates and thus help reduce resources required for routing update generation and processing.

The Extended Communities ORF-type capability is also very useful within the MPLS/VPN architecture. This is because it can filter any routes that contain a route target attribute that is not imported by the receiving PE-router. The advantage of this is that the routes are filtered before being advertised to the receiving PE-router rather than being discarded silently at the PE-router as with the Automatic Route Filtering feature.

The capability to filter routes based on their route target becomes particularly useful when BGP route reflectors are deployed within the MPLS/VPN topology. You can preconfigure each route reflector with a list of route targets that correspond to the routes that the route reflector should reflect between PE-routers. The route reflector treats all its clients, in this case the PE-routers, as a single BGP peer-group and all other route reflectors with which it has sessions as individual peers but not as members of the peer-group.

Because the set of route targets that should be reflected to a particular peer-group was preconfigured on the route reflector already, it can set the outbound route filters that contain the list of the preconfigured route targets on all its neighbor sessions. You can implement this feature using the rr-group command, which is discussed fully in Chapter 12.