Advanced BGP – Border Gateway Protocol Route Filtering – Part 1

In Cisco IOS software, there are many techniques that can be used to implement a route filtering policy when using BGP. As previously stated, BGP is first and foremost a policy configuration tool. Given this, it is important to understand not only basic BGP implementation, as described in the earlier chapter and in previous sections of this chapter, but also how to implement an effective policy control solution when using BGP. The following route filtering policy control tools are described in this section:

• Effective Policy Control Using IP Prefix Lists
• Effective Policy Control with Communities
• Effective Policy Control Using AS PATH Filters

Effective Policy Control Using IP Prefix Lists

Prefix lists, which were described in detail earlier in this guide, can be used for inbound and outbound filtering policies. For BGP, prefix lists can be applied in two ways:

• Using the neighbor [address] prefix-list [name] <in|out> command
• Using the neighbor [address] route-map [name] <in|out> command

The neighbor [address] prefix-list [name] <in|out> command applies prefix list filtering in the inbound or outbound direction for the specified neighbor or peer group. As an example, the following output shows the BGP RIB of an iBGP speaker that is receiving prefixes from another iBGP speaker:

If, for example, we only wanted this router to accept the 172.16.0.0/24 and 172.16.2.0/24 prefixes, the following configuration would be implemented on the local router:

Following this configuration, the BGP RIB on the same router now shows the following:

Following the configuration of inbound or outbound prefix list filters, you can use the show ip bgp neighbors [address] command to verify the filter applied to the neighbor as follows:

In addition to showing the prefix list used for inbound filtering, this command also shows the current number of received prefixes, as well as the count of prefixes denied by the prefix list filtering configuration, as whether those are in the inbound or outbound direction. These two sections are printed in bold font in the previous output.

In Cisco IOS software, the show ip bgp prefix-list [name] command can also be used to further valid inbound or outbound prefix list filtering. This command filters the BGP RIB output based on the configuration in the specified prefix list. The following example illustrates how to use this command to filter BGP RIB output based on the named prefix list:

NOTE: Keep in mind that the same configuration could also have been applied in the outbound direction on the router advertising these prefixes.

The neighbor [address] route-map [name] <in|out> command can also be used to perform prefix list filtering. The primary advantage of using route maps is their flexibility, as has been demonstrated in previous chapters. For example, in addition to matching a specified prefix list, the same route map could also be used to perform other functions, such as path attribute manipulation, within the same configuration. The following example illustrates how to use a route map to perform the same filtering illustrated in the previous example:

As with direct prefix list configuration, the show ip bgp neighbors command can be used to validate the applied route map and view information on the number of prefixes

And finally, the show ip bgp route-map [name] command can be used to filter the contents of the BGP RIB, showing only those matched by the specified route map:

NOTE: The same policy could also be implemented in the outbound direction on R1 and the same commands used to validate this configuration.

In enterprise networks, one of the most common (and recommended) uses for prefix lists is to filter Martian addresses. Martians are networks that should not be routed on the Internet.  In essence, these addresses are illegal on the Internet, although they may be used within private enterprise networks. When implementing an inbound route filtering policy for BGP, the following Martian addresses should be filtered in UPDATE messages received from the ISP:

• Network 0.0.0.0/8 Addresses – 0.0.0.0/8 (This does not include the default 0.0.0.0/0)
• RFC 1918 Address Space – 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16
• System Local Address Space – 127.0.0.0/8
• Autoconfiguration Address Space – 169.254.0.0/16
• Test Network Address Space – 192.0.2.0/24
• Class D and Class E Address Space – 224.0.0.0/3

The following configuration illustrates how to configure a local BGP speaker peered to an ISP BGP speaker in AS 456 to filter Martian addresses and allow all other prefixes:

The same configuration can also be used with a route map that matches the specified prefix list.

Effective Policy Control with Communities

In the previous chapter, when we were learning about the different BGP attributes, we learned that the COMMUNITY attribute provides a way of grouping destinations, called Communities, to which routing decisions (such as acceptance, preference, and redistribution) can be applied.

The attribute is encoded as a four-octet value where the first two octets represent an AS number and the remaining two octets represent a locally defined value. There are two types of communities that exist. These two types are:

• Well-known Communities
• Private Communities

The well-know communities are communities that have predefined meanings. These are:

• NO_EXPORT
• NO_ADVERTISE
• INTERNET
• LOCAL_AS

Unlike the well-known communities, private communities must be manually defined by the network administrators and actions for prefixes assigned those communities must also be explicitly defined. Private communities are typically configured using the AA:NN format, where AA represents the AS Number and NN is a randomly selected number.

NOTE: The implementation, use and configuration of private communities is beyond the scope of the current ROUTE exam and will not be illustrated in this chapter. Instead, the chapter will focus exclusively on the use of well-known communities.

To better understand the use of well-known communities, consider the topology in Figure 7-14:

Fig. 7-14. Understanding BGP Communities

Figure 7-13 shows an enterprise that is multihomed to two ISPs as well as two partners. This enterprise is receiving full Internet tables from both ISPs as well as routes for the prefixes owned by the two partners. Without any type of route filtering, the Internet prefixes received from the ISPs will be advertised to the partners. In addition to this, the prefixes that are also received from the partners will be advertised to the ISPs. This is not desirable.

The first reason is that if the enterprise advertises the Internet routes to the partners, these two routing domains might prefer the path via the enterprise to reach prefixes in AS 1 and 2, in addition to any other Internet-based prefixes that have a shorter AS_PATH via the enterprise network.  The second reason is AS 1 and AS 2 might also prefer the path through AS 123 for prefixes originated in AS 456 and AS 789. The third reason is that the partner ASes could also now prefer the path via AS 123 to reach each other. Regardless of the way you look at it, the enterprise becomes a transit autonomous system for both the partner networks and the ISPs.

Instead of using prefix lists to filter prefixes in the inbound and outbound directions, AS 123 could simply route filtering by using communities. For example, using a simple policy, the enterprise edge routers could be configured to set the NO_EXPORT community on all of the prefixes received from the ISPs and the partners.

The NO_EXPORT well-known community prevents BGP prefixes that are specifically assigned this predefined community attribute value from being advertised to any eBGP peers. The prefixes, however, will continue to be advertised to all other iBGP speakers within the local AS. This solution means that the Internet routes received from the ISPs will not be advertised to either partner. Additionally, the prefixes received from both partners will not be advertised to the ISPs or the other partner. Only AS 123 maintains full reachability to all other ASes.

Referencing the topology illustrated in Figure 7-14, enterprise edge router is receiving a partial routing table plus a default route from the ISP. The BGP RIB on E1 shows the following routes:

The received prefixes are advertised to peers E2, E3, and E4. Taking router E2, for example, the same prefixes are then advertised to the partner router, along with the 150.254.0.0/16 prefix which is owned by the enterprise. In addition to this, the prefix that router E4 receives from Partner B is also included in the advertised prefixes. The prefixes that are advertised to router P1 can be validated using the show ip bgp neighbors [address] advertised-routes command. The output of this command on E3 shows the following advertisements: