All Cisco-Network Study Notes: 12/22/08

Putting It All Together cp 10

Putting It All Together

Problem

You want to combine all of best the elements in this chapter to create a good redundant ISP connection.

Solution

For simplicity, we will extend the single router dual ISP configuration of Recipe 9.4 rather than the dual router dual ISP example of Recipe 9.5. It should be clear from the discussion in Recipe 9.5 how to extend this example to the two-router case:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Serial0
Router1(config-if)#description connection to ISP #1, ASN 65510
Router1(config-if)#ip address 192.168.1.6 255.255.255.252
Router1(config-if)#exit
Router1(config)#interface Serial1
Router1(config-if)#description connection to ISP #2, ASN 65520
Router1(config-if)#ip address 192.168.2.6 255.255.255.252
Router1(config-if)#exit
Router1(config)#interface Ethernet0
Router1(config-if)#description connection to internal network, ASN 65500
Router1(config-if)#ip address 172.18.5.2 255.255.255.0
Router1(config-if)#exit
Router1(config)#ip as-path access-list 15 permit ^$
Router1(config)#ip route 0.0.0.0 0.0.0.0 192.168.101.0 1
Router1(config)#ip route 0.0.0.0 0.0.0.0 192.168.102.0 2
Router1(config)#ip prefix-list CREATE-DEFAULT seq 10 permit 192.168.101.0/24
Router1(config)#ip prefix-list CREATE-DEFAULT seq 20 permit 192.168.102.0/24
Router1(config)#ip prefix-list BLOCK-DEFAULT seq 10 permit 0.0.0.0/0 ge 1
Router1(config)#route-map PREPEND permit 10
Router1(config-route-map)#set as-path prepend 65500 65500
Router1(config-route-map)#exit
Router1(config)#route-map LOCALPREF permit 10
Router1(config-route-map)#set local-preference 75
Router1(config-route-map)#exit
Router1(config)#route-map DEFAULT-ROUTE permit 10
Router1(config-route-map)#match ip address prefix-list CREATE-DEFAULT
Router1(config-route-map)#exit
Router1(config)#router bgp 65500
Router1(config-router)#network 172.18.5.0 mask 255.255.255.0
Router1(config-router)#neighbor 172.18.5.3 remote-as 65500
Router1(config-router)#neighbor 172.18.5.3 password password_number1
Router1(config-router)#neighbor 172.18.5.3 default-origniate route-map DEFAULT-ROUTE
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#neighbor 192.168.1.5 password password_number2
Router1(config-router)#neighbor 192.168.1.5 filter-list 15 out
Router1(config-router)#neighbor 192.168.1.5 prefix-list CREATE-DEFAULT in
Router1(config-router)#neighbor 192.168.1.5 prefix-list BLOCK-DEFAULT out
Router1(config-router)#neighbor 192.168.2.5 remote-as 65520
Router1(config-router)#neighbor 192.168.2.5 password password_number3
Router1(config-router)#neighbor 192.168.2.5 filter-list 15 out
Router1(config-router)#neighbor 192.168.2.5 prefix-list CREATE-DEFAULT in
Router1(config-router)#neighbor 192.168.2.5 prefix-list BLOCK-DEFAULT out
Router1(config-router)#neighbor 192.168.2.5 route-map PREPEND out
Router1(config-router)#neighbor 192.168.2.5 route-map LOCALPREF in
Router1(config-router)#no synchronization
Router1(config-router)#exit
Router1(config)#end
Router1#

Discussion

In this recipe, we put together several of the concepts discussed throughout the chapter. This router has three BGP peers, two of which are ISPs, and the other is an internal BGP router.

We have disabled synchronization. We aren't using an IGP on this router, so synchronization doesn't serve any purpose. We have used a network statement that covers only part of a classful network:

Router1(config)#router bgp 65500
Router1(config-router)#network 172.18.5.0 mask 255.255.255.0
Router1(config-router)#no synchronization

All of the peer relationships, including the internal peer, use MD5 authentication, which we have configured by using the neighbor password command, as discussed in Recipe 9.16:

Router1(config)#router bgp 65500
Router1(config-router)#neighbor 172.18.5.3 password password_number1
Router1(config-router)#neighbor 192.168.1.5 password password_number2
Router1(config-router)#neighbor 192.168.2.5 password password_number3

Note that we have configured different passwords on each peer, and each password is between 12 and 24 characters long, as we discussed in Recipe 9.16.

We have configured an AS Path filter to each of the ISP peers to prevent them from using our network for transit purposes:

Router1(config)#router bgp 65500
Router1(config)#ip as-path access-list 15 permit ^$
Router1(config-router)#neighbor 192.168.1.5 filter-list 15 out
Router1(config-router)#neighbor 192.168.2.5 filter-list 15 out

We have followed Recipe 9.11 to replace the entire Internet routing table with a default route. This router then passes its default route along to the internal BGP router, which forces us to be careful that we don't distribute the default back to the ISP routers:

Router1(config)#ip route 0.0.0.0 0.0.0.0 192.168.101.0 1
Router1(config)#ip route 0.0.0.0 0.0.0.0 192.168.102.0 2
Router1(config)#ip prefix-list CREATE-DEFAULT seq 10 permit 192.168.101.0/24
Router1(config)#ip prefix-list CREATE-DEFAULT seq 20 permit 192.168.102.0/24
Router1(config)#ip prefix-list BLOCK-DEFAULT permit 0.0.0.0/0 ge 1
Router1(config)#route-map DEFAULT-ROUTE permit 10
Router1(config-route-map)#match ip address prefix-list CREATE-DEFAULT
Router1(config-route-map)#exit
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 172.18.5.3 remote-as 65500
Router1(config-router)#neighbor 172.18.5.3 default-origniate route-map DEFAULT-ROUTE
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#neighbor 192.168.1.5 prefix-list CREATE-DEFAULT in
Router1(config-router)#neighbor 192.168.1.5 prefix-list BLOCK-DEFAULT out
Router1(config-router)#neighbor 192.168.2.5 remote-as 65520
Router1(config-router)#neighbor 192.168.2.5 prefix-list CREATE-DEFAULT in
Router1(config-router)#neighbor 192.168.2.5 prefix-list BLOCK-DEFAULT out

Next, we have used Recipe 9.7 to make ISP #2 less attractive for outbound traffic. This may be because this ISP has higher usage charges, or perhaps it is a lower bandwidth connection. Using Local Preference for this ensures that all of the BGP routers inside the AS can share this information about the best outbound path:

Router1(config)#route-map LOCALPREF permit 10
Router1(config-route-map)#set local-preference 75
Router1(config-route-map)#exit 
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.2.5 route-map LOCALPREF in

And, finally, we have followed Recipe 9.13 to make sure that inbound traffic from the public Internet also uses the link through ISP #1 preferentially:

Router1(config)#route-map PREPEND permit 10
Router1(config-route-map)#set as-path prepend 65500 65500
Router1(config-route-map)#exit 
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.2.5 route-map PREPEND out

You should feel free to mix and match these types of configuration elements to make your configuration match your requirements.

Many backbone ISPs have looking glass servers that allow you to see how your BGP routes look several hops away from your network. These are generally web pages that allow you to submit show BGP type queries for specific routes. You can find a list of looking glass servers around the world on http://www.traceroute.org. This site also lists a large number of traceroute servers, which will allow you to test which paths inbound connections will use to reach your network.

Using BGP Route Reflectors

Problem

You want to simplify your iBGP peer relationships by using route reflectors.

Solution

There are three types of configurations to consider when working with BGP Route Reflectors: the Route Reflector itself, the Client Peer, and the Nonclient Peer. In this example, which follows Figure 9-4, the Route Reflector is Router2, and it has two Client PeersRouter1 and Router3. It also has a Nonclient Peer, Router4.

The configurations for Client and Nonclient Peers contain no special commands. Router1 is the Client Peer:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Ethernet0/0
Router1(config-if)#ip address 172.18.5.2 255.255.255.0
Router1(config-if)#exit
Router1(config)#interface Serial0/0
Router1(config-if)#ip address 192.168.1.6 255.255.255.252
Router1(config-if)#exit
Router1(config)#interface Loopback0
Router1(config-if)#ip address 172.18.6.1 255.255.255.255
Router1(config-if)#exit
Router1(config)#router bgp 65500
Router1(config-router)#no synchronization
Router1(config-router)#neighbor 172.18.6.2 remote-as 65500
Router1(config-router)#neighbor 172.18.6.2 next-hop-self
Router1(config-router)#neighbor 172.18.6.2 update-source Loopback0
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#exit
Router1(config)#ip route 172.18.6.2 255.255.255.255 172.18.5.3
Router1(config)#ip route 172.18.6.3 255.255.255.255 172.18.5.4
Router1(config)#ip route 172.18.6.4 255.255.255.255 172.18.5.10
Router1(config)#end
Router1#

Router4 is the Nonclient Peer:

Router4#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router4(config)#interface Ethernet0
Router4(config-if)#ip address 172.18.5.10 255.255.255.0
Router4(config-if)#exit
Router4(config)#interface Loopback0
Router4(config-if)#ip address 172.18.6.4 255.255.255.255
Router4(config-if)#exit
Router4(config)#router bgp 65500
Router4(config-router)#no synchronization
Router4(config-router)#neighbor 172.18.6.2 remote-as 65500
Router4(config-router)#neighbor 172.18.6.2 update-source Loopback0
Router4(config-router)#exit
Router4(config)#ip route 172.18.6.1 255.255.255.255 172.18.5.2
Router4(config)#ip route 172.18.6.2 255.255.255.255 172.18.5.3
Router4(config)#ip route 172.18.6.3 255.255.255.255 172.18.5.4
Router4(config)#end
Router4#

The only special configuration required is on the Route Reflector itself:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#interface FastEthernet0/0
Router2(config-if)#ip address 172.18.5.3 255.255.255.0
Router2(config-if)#exit
Router2(config)#interface Loopback0
Router2(config-if)#ip address 172.18.6.2 255.255.255.255
Router2(config-if)#exit
Router2(config)#router bgp 65500
Router2(config-router)#no synchronization
Router2(config-router)#neighbor 172.18.6.1 remote-as 65500
Router2(config-router)#neighbor 172.18.6.1 route-reflector-client
Router2(config-router)#neighbor 172.18.6.1 update-source Loopback0
Router2(config-router)#neighbor 172.18.6.3 remote-as 65500
Router2(config-router)#neighbor 172.18.6.3 route-reflector-client
Router2(config-router)#neighbor 172.18.6.3 update-source Loopback0
Router2(config-router)#neighbor 172.18.6.4 remote-as 65500
Router2(config-router)#neighbor 172.18.6.4 update-source Loopback0
Router2(config-router)#no auto-summary
Router2(config-router)#exit
Router2(config)#ip route 172.18.6.1 255.255.255.255 172.18.5.2
Router2(config)#ip route 172.18.6.3 255.255.255.255 172.18.5.4
Router2(config)#ip route 172.18.6.4 255.255.255.255 172.18.5.10
Router2(config)#end
Router2#

Discussion

In the standard BGP peering model that prevailed in every other recipe in this chapter, there is a strict rule that any external route learned by one of the BGP routers in an AS must be advertised to any other BGP routers in the same AS by the router that used the original route. To see what this means, consider Figure 9-4.

Figure 9-4. BGP route reflection

In this diagram, Router1 receives a routing update from external Router4. So Router1 must readvertise this information to Router2 and Router3, the other routers in the AS. When Router2 receives this update, it may pass the information along to external peers, but it must not relay it to another router in the same AS, such as Router3. The reason for this is simply to prevent routing loops.

This is a sensible rule, in most cases, but it means that every router in an AS must have an iBGP peer relationship with every other router in that AS. This full mesh of iBGP peers doesn't scale very well when you have a lot of BGP routers in one AS. So RFC 2796 provides a way to relax this rule. We can configure Router2 as a Route Reflector, and Router1 and Router3 as its Client Peers.

Note that there could be other routers in this AS as well, which may or may not also be client peers of the same route reflector. Router4 is a Nonclient Peer of Router2. The Nonclient Peers must have the usual full mesh peering relationship among one another, although they do not have to peer with any of the Client peers of the route reflector. They can get all of the information for all of the route reflector's client peers at once by simply peering with the route reflector.

You could have more complicated systems of route reflectors in an AS. For example, you might want to divide up your AS into several different regions, each represented by a pair of redundant route reflectors. The peers of each route reflector would then establish iBGP peering relationships with their own reflectors, but not with any other routers in the AS. The route reflectors would then peer with one another in a full mesh to ensure full connectivity within the AS.

It's also important to remember that the route reflectors do not have to pass all of the traffic for their respective clients. Their only special function is in making sure that all of their clients have good BGP routing information.

To configure one router as a Route Reflector, you simply configure a neighbor command with the route-reflector-client keyword for those neighbor devices that will be Client Peers:

Router2(config)#router bgp 65500
Router2(config)#router bgp 65500
Router2(config-router)#no synchronization
Router2(config-router)#neighbor 172.18.6.1 remote-as 65500
Router2(config-router)#neighbor 172.18.6.1 route-reflector-client
Router2(config-router)#neighbor 172.18.6.1 update-source Loopback0
Router2(config-router)#neighbor 172.18.6.3 remote-as 65500
Router2(config-router)#neighbor 172.18.6.3 route-reflector-client
Router2(config-router)#neighbor 172.18.6.3 update-source Loopback0
Router2(config-router)#neighbor 172.18.6.4 remote-as 65500
Router2(config-router)#neighbor 172.18.6.4 update-source Loopback0
Router2(config-router)#no auto-summary
Router2(config-router)#exit

This specifies that the two peers, 172.18.6.1 and 172.18.6.3, are Client Peers. We have not included a neighbor route-reflector-client command for the other neighbor, 172.18.6.4, making it a Nonclient Peer of this route reflector. There is no special configuration required on either Client or Nonclient Peer routers and, indeed, these devices don't even know or care about the difference. The only router that needs to do anything special is the Route Reflector itself.

When configuring two or more redundant BGP Route Reflectors, though, another little trick is required. In the current example, if we were to just turn on Route Reflection on Router4 with the same clients as Router2, this would cause some problems, as the two Route Reflectors hear about every reflected routing prefix both from the original source and from the other Route Reflector. This could cause strange behavior if the real source of the route becomes unavailable. The two Route Reflectors will both believe that the route is reachable through one another.

To prevent this problem, we need to specify a cluster ID on each Route Reflector to identify a particular group of Client Peers:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#router bgp 65500
Router2(config-router)#bgp cluster-id 1234

And you need to configure the same cluster ID on the other Route Reflector:

Router4#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router4(config)#router bgp 65500
Router4(config-router)#bgp cluster-id 1234

There is one important caveat about implementing cluster IDs, however. In a case like this one, where we had one router acting as a Route Reflector, and we wanted to either implement a new cluster ID, or to change an existing one, we had to manually remove the Client Peer configuration from the Route Reflector first. Then we configured the cluster-id command and replaced the Client Peer neighbor configuration statements.

When working with Route Reflectors, we strongly recommend implementing two or more redundant reflectors. If you have a single reflector for a large network, then this becomes a dangerous single point of failure for your entire BGP routing infrastructure.

Authenticating BGP Peers

Authenticating BGP Peers
Problem
You want to authenticate your BGP peer relationships to help prevent tampering with your routing tables.

Solution
The BGP protocol includes an MD5-based authentication system for authenticating peers:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.55.5 remote-as 65501
Router1(config-router)#neighbor 192.168.55.5 password password-1234
Router1(config-router)#exit
Router1(config)#end
Router1#

The same password must be configured on both routers:

Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#router bgp 65501
Router2(config-router)#neighbor 192.168.55.6 remote-as 65500
Router2(config-router)#neighbor 192.168.55.6 password password-1234
Router2(config-router)#exit
Router2(config)#end
Router2#

Discussion
MD5 authentication is a standard part of BGP Version 4 that was introduced in RFC 2385. The IETF went further in RFC 3013 (which is also called BCP 46) to recommend that "BGP authentication should be used with routing peers" in the public Internet. This language "should be used" indicates a strong recommendation, but not a requirement.

BGP is different than the routing protocols that we discussed in Chapters 6, 7, and 8 because you must explicitly configure the peer relationships between routers. These peers then use point-to-point TCP connections to exchange information. So it is much more difficult for a malicious user to surreptitiously establish a peer relationship with one of your routers and corrupt your routing tables. But it is still possible to hijack an existing TCP connection between two BGP peers and inject bad routes. And if the attackers are on the same network segment as one of the peers, they can potentially hijack the IP address of the legitimate peer and set up a new BGP session.

With authentication, this type of attack is considerably more difficult. This is because the attacker must not only get the TCP sequence numbers right, but he must also insert the correct encrypted authentication key.

It is worth mentioning also that some sources have claimed that this MD5 authentication scheme is not sufficient for BGP because there are effective attacks that can break it. The Internet Draft document, "Security Requirements for Keys used with the TCP MD5 Signature Option," (draft-ietf-idr-md5-keys-00.txt), comments on this threat and makes the following recommendations:

Make your keys between 12 and 24 bytes long.

In situations with multiple BGP peers, avoid using the same keys with all peers.

Change your keys at least every 90 days.

It is also important to note that introducing authentication can cause delays in BGP message passing, although it shouldn't seriously affect normal IP packet processing. It can also cause increased CPU overhead on the BGP peer routers.

Despite all of this, in a hostile network, authentication can be useful because it makes it significantly harder for somebody to disrupt your routing tables. If your ISP supports this service, it is probably a good idea to use it.

It is also worth mentioning that in your router's configuration file, the password will be stored in plain text unless you have enabled the service password-encryption global configuration command. When you turn on password encryption, the router will store the command using the Cisco proprietary Type 7 encryption:

!
router bgp 65500
neighbor 192.168.55.5 remote-as 65501
neighbor 192.168.55.5 password 7 15020A1F173D24362C7E64704053
!

As we mentioned in Chapter 3, it is quite easy to break this encryption algorithm. But as long as you maintain good control over your router configuration files, this at least prevents somebody from learning the encryption key by looking over your shoulder.

When there is an authentication mismatch between two BGP peers, they will not be able to establish a connection. You will also see the following error message on one or both routers:

Jan 7 10:01:48 EST: %TCP-6-BADAUTH: No MD5 digest from 192.168.55.6:13662 to 192.168.55.5:179

See Also

Using BGP Communities

Problem

You want to configure BGP Communities to control routing and route propagation.

Solution

Configuring Cisco routers to use BGP Communities is a two-step process. You must specify the desired Community values by using a route map associated with a neighbor command:

Router3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router3(config)#ip prefix-list 10.101/16 seq 5 permit 10.101.0.0/16
Router3(config)#ip prefix-list 10.102/16 seq 5 permit 10.102.0.0/16
Router3(config)#ip prefix-list 10.103/16 seq 5 permit 10.103.0.0/16
Router3(config)#ip prefix-list 10.104/16 seq 5 permit 10.104.0.0/16
Router3(config)#ip prefix-list 10.105/16 seq 5 permit 10.105.0.0/16
Router3(config)#route-map APPLY_COMMUNITY_A permit 10
Router3(config-route-map)#match ip address prefix-list 10.101/16
Router3(config-route-map)#set community no-advertise
Router3(config-route-map)#exit
Router3(config)#route-map APPLY_COMMUNITY_A permit 20
Router3(config-route-map)#match ip address prefix-list 10.102/16
Router3(config-route-map)#set community no-export
Router3(config-route-map)#exit
Router3(config)#route-map APPLY_COMMUNITY_A permit 30
Router3(config-route-map)#match ip address prefix-list 10.103/16
Router3(config-route-map)#set community local-AS
Router3(config-route-map)#exit
Router3(config)#route-map APPLY_COMMUNITY_A permit 40
Router3(config-route-map)#match ip address prefix-list 10.104/16
Router3(config-route-map)#set community internet
Router3(config-route-map)#exit
Router3(config)#route-map APPLY_COMMUNITY_A permit 50
Router3(config-route-map)#match ip address prefix-list 10.105/16
Router3(config-route-map)#set community 4293328976
Router3(config-route-map)#exit
Router3(config)#route-map APPLY_COMMUNITY_A permit 100
Router3(config-route-map)#exit
Router3(config)#router bgp 65500
Router3(config-router)#no synchronization
Router3(config-router)#neighbor 172.18.5.3 remote-as 65500
Router3(config-router)#neighbor 172.18.5.3 next-hop-self
Router3(config-router)#neighbor 172.18.5.3 send-community both
Router3(config-router)#neighbor 172.18.5.10 remote-as 65500
Router3(config-router)#neighbor 172.18.5.10 next-hop-self
Router3(config-router)#neighbor 172.18.5.10 send-community both
Router3(config-router)#neighbor 192.168.1.9 remote-as 65520
Router3(config-router)#neighbor 192.168.1.9 send-community both
Router3(config-router)#neighbor 192.168.1.9 route-map APPLY_COMMUNITY_A in
Router3(config-router)#exit
Router3(config)#end
Router3#

Then, for all of the downstream routers that you want to use and/or propagate the Community values that you are setting, you must include the neighbor send-community command:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#router bgp 65500
Router2(config-router)#no synchronization
Router2(config-router)#neighbor 172.18.5.4 remote-as 65500
Router2(config-router)#neighbor 172.18.5.4 send-community both
Router2(config-router)#neighbor 172.18.5.10 remote-as 65500
Router2(config-router)#neighbor 172.18.5.10 send-community both
Router2(config-router)#no auto-summary
Router2(config-router)#exit
Router2(config)#end
Router2#

Discussion

A standard BGP Community is simply a 32-bit number that BGP can attach to routing prefixes. This attribute is defined in RFC 1997, which also specifies that the values 0x00000000 through 0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are reserved. It is classed as an Optional Transitive attribute, which means that Community values are passed along with routes, across both iBGP and eBGP links, and whether the receiving router understands what to do with them or not. RFC 4360 defines the Extended Community attribute, which is nearly identical, except that it uses a 64-bit field to help reduce the potential for overlapping uses.

There are two common uses for Communities. The first simply uses the few Well Known Community attributes:

local-AS (Well Known Community): This Community value indicates that the associated route should not be advertised outside of the AS. So it is distributed among iBGP peers, but not via eBGP.
no-advertisedo not advertise to any peer (Well Known Community): The no-advertise Community instructs routers not to advertise this route to any other BGP peers, not even iBGP peers.
no-exportdo not export to next AS (Well Known Community): Routes containing the no-export Community value are not advertised to any router outside of the Confederation or to any routers outside of the AS.
Internet (Well Known Community): Routes tagged with the internet community are assumed to be associated with the Public Internet. There is no special action associated with this Community value.

Using these Well Known Community values allows you to exercise control over how routes are distributed throughout your AS and into neighboring ASs. For example, if you have a route in your BGP tables that you want to restrict to your own AS and not advertise it to any external peers, you would simply set the local-AS Community value. If you are using BGP Confederations, you can similarly restrict a route to within a given Confederation by tagging it with the no-export Community. If you are not using Confederations, then the local-AS and no-export Communities have an identical result.

The second use for Communities is a little bit more complicated and requires agreement between ISPs and their clients. The application suggested in RFC 1998 allows customers of an ISP to affect routing decisions for their own routes within their ISP's network. In this system, the customer can tag their routes with a community value containing an ASN and a Local Preference value. The ASN value defines the AS that the customer would like to affect, and is contained in the first 16 bits of the Community value. The remaining 16 bits then contain a Local Preference value. This allows the customer to affect inbound routing for their networks in real time on a prefix-by-prefix basis.

For example, suppose you have two ISPs with ASNs 65511 and 65512. If you want to specify that inbound traffic to your network for a particular prefix is to use the first ISP preferentially, you would include a Community value of 65511:100 (which is FFE7:0064 in hex or 4293328996 in decimal) to request that the ISP set a Local Preference of 100 for this route.

Conversely, if you wanted to make this ISP the backup link for this particular route prefix, you could request a lower Local Preference value such as 80 by including a Community value of 65511:80 (which is FFE7:0050 in hex or 4293328976 in decimal).

The reason why we include these different formats for Community values is because the router configuration file displays them as decimal numbers. However you can also configure them as colon-separated 16-bit decimal numbers to allow ASN:nn format:

Router3(config)#route-map APPLY_COMMUNITY_A permit 50
Router3(config-route-map)#match ip address prefix-list 10.105/16
Router3(config-route-map)#set community 65511:80

This set community command will be displayed as:

!
route-map APPLY_COMMUNITY_A permit 50
match ip address prefix-list 10.105/16
set community 4293328976
!

And some IOS versions even get confused by the 32-bit number and incorrectly display it as a signed integer:

!
route-map APPLY_COMMUNITY_A permit 50
match ip address prefix-list 10.105/16
set community -1638320
!

But however your router displays the values, they all function identically.

You use route maps to apply Communities to routes, exactly the same way that we handled Local Preference values in Recipe 9.7. For example, this part of the route map uses a prefix-list to select a particular route, and sets its Community value to no- export:

Router3(config)#ip prefix-list 10.102/16 seq 5 permit 10.102.0.0/16
Router3(config)#route-map APPLY_COMMUNITY_A permit 20
Router3(config-route-map)#match ip address prefix-list 10.102/16
Router3(config-route-map)#set community no-export
Router3(config-route-map)#exit

You then need apply this route map to a neighbor command:

Router3(config)#router bgp 65500
Router3(config-router)#neighbor 192.168.1.9 remote-as 65520
Router3(config-router)#neighbor 192.168.1.9 send-community both
Router3(config-router)#neighbor 192.168.1.9 route-map APPLY_COMMUNITY_A in

In this case, we have applied the route map to incoming routes from this eBGP peer. As a general rule of thumb, to ensure consistency across your AS, you should attach any Community values to routes on the first router to handle the routes. In this case, the required routes are outside of the AS. However, if the routes originate within the AS, then we would have applied the route map outbound on the router that originates them. In that case, we would need to be careful to apply the route map to all of the iBGP peers.

The other important command in dealing with Communities is the neighbor send-community command:

Router3(config-router)#neighbor 192.168.1.9 send-community both

By default, Cisco routers do not propagate Community values with BGP routes. So you must include this command for all of the peers that need to see this attribute. This is why, in the Solution section of this recipe, we have been careful to include this command on the other routers inside our AS, even if those routers don't update the Community attribute. The both keyword in this command indicates that this router should send both Standard 32-bit and Extended 64-bit Community values. You can configure the router to use just one or the other if you prefer, but in most cases, if you are using Communities, you will want to make sure that you a propagating all of the attributes, so we generally recommend forwarding both types.

There are three useful commands for looking at Community values on a router. The first is the common show ip bgp summary command:

Router2#show ip bgp summary
BGP router identifier 172.18.5.3, local AS number 65500
BGP table version is 37, main routing table version 37
12 network entries using 1212 bytes of memory
12 path entries using 576 bytes of memory
7 BGP path attribute entries using 420 bytes of memory
1 BGP rrinfo entries using 24 bytes of memory
3 BGP AS-PATH entries using 72 bytes of memory
5 BGP community entries using 120 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2424 total bytes of memory
BGP activity 46/34 prefixes, 54/42 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

172.18.5.4      4 65500      54      45       37    0    0 00:00:31        4
172.18.5.10     4 65500      47      65       37    0    0 00:08:35        8
Router2#

This output shows that there are five BGP routes on this router that have Community values associated with them. We can see which routes they are with the command show ip bgp community:

Router2#show ip bgp community
BGP table version is 37, local router ID is 172.18.5.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
            r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

 Network          Next Hop            Metric LocPrf Weight Path
*>i10.11.0.0/16     172.18.5.2               0    100      0 65510 i
*>i10.102.0.0/16    172.18.5.4               0    100      0 65520 i
*>i10.103.0.0/16    172.18.5.4               0    100      0 65520 i
*>i10.104.0.0/16    172.18.5.4               0    100      0 65520 i
*>i10.105.0.0/16    172.18.5.4               0    100      0 65520 i
Router2#

As you can see, the list includes four of the five routes that we tagged on Router3, plus another route that was tagged elsewhere in the network. It's worth pointing out that we don't see 10.101.0.0/16 in this table because it was tagged with the no-advertise community. Consequently, Router3 did not advertise this route to Router2. You can see exactly which communities are associated with these routes as follows:

Router3#show ip bgp 10.101.0.0/16
BGP routing table entry for 10.101.0.0/16, version 10
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to
any peer)
Not advertised to any peer
65520
  192.168.1.9 from 192.168.1.9 (10.104.0.1)
    Origin IGP, metric 0, localpref 100, valid, external, best
    Community: no-advertise
Router3#show ip bgp 10.102.0.0/16
BGP routing table entry for 10.102.0.0/16, version 11
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to
EBGP peer)
Advertised to non peer-group peers:
172.18.5.3 172.18.5.10
65520
  192.168.1.9 from 192.168.1.9 (10.104.0.1)
    Origin IGP, metric 0, localpref 100, valid, external, best
    Community: no-export
Router3#

This shows that the route 10.101.0.0/16 has the no-advertise community, and consequently is not being advertised. The route 10.102.0.0/16 has a community value of no-export, and is being advertised to two BGP peer routers.

Of course, just being able to set arbitrary Community values is not of much use. Your routers also need to be able to read and react appropriately to these values. To do this, you use a special kind of ACL called a community-list, which specifies community values for use in route maps:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#ip community-list 10 permit 65511:80
Router2(config)#route-map MATCH-COMMUNITY permit 10
Router2(config-route-map)#match community 10
Router2(config-route-map)#set local-preference 80
Router2(config-route-map)#exit
Router2(config)#route-map MATCH-COMMUNITY permit 100
Router2(config-route-map)#exit
Router2(config)#router bgp 65500
Router2(config-router)#no synchronization
Router2(config-router)#neighbor 172.18.5.4 remote-as 65500
Router2(config-router)#neighbor 172.18.5.4 route-map MATCH-COMMUNITY in
Router2(config-router)#exit
Router2(config)#end
Router2#

If we do a show ip bgp community now and compare to the output above, you can see that the Local Preference value has been changed for this route:

Router2#show ip bgp community
BGP table version is 21, local router ID is 172.18.5.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
            r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

 Network          Next Hop            Metric LocPrf Weight Path
*>i10.11.0.0/16     172.18.5.2               0    100      0 65510 i
*>i10.102.0.0/16    172.18.5.4               0    100      0 65520 i
*>i10.103.0.0/16    172.18.5.4               0    100      0 65520 i
*>i10.104.0.0/16    172.18.5.4               0    100      0 65520 i
*>i10.105.0.0/16    172.18.5.4               0     80      0 65520 i
Router2#

As you can see, the Local Preference value for this route has now been changed appropriately.

Redistributing Routes with BGP

Problem

You want to redistribute routes between an IGP and BGP.

Solution

When connecting two or more IGPs using BGP, you sometimes need to configure redistribution between the IGP and BGP on both routers. To make the example more interesting, we will assume that we need to connect an EIGRP network to an OSPF network using a pair of BGP routers.

The first router redistributes routes from BGP into OSPF:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router ospf 100
Router1(config-router)#network 172.26.0.0 0.0.255.255 area 0
Router1(config-router)#redistribute bgp 65500 metric 500 subnets
Router1(config-router)#exit
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65520
Router1(config-router)#network 172.26.0.0
Router1(config-router)#exit
Router1(config)#end
Router1#

And this is the configuration for the router that redistributes BGP routes into EIGRP:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#router eigrp 99
Router2(config-router)#network 172.25.0.0
Router2(config-router)#redistribute bgp 65520 metric 500 10 255 1 1500
Router2(config-router)#exit
Router2(config)#router bgp 65520
Router2(config-router)#neighbor 192.168.1.6 remote-as 65500
Router2(config-router)#network 172.25.0.0
Router2(config-router)#exit
Router2(config)end
Router2#

Discussion

Before we say anything about this recipe, we need to stress that redistribution with BGP is often a very messy business. The example specifically shows using BGP to handle routing between two IGPs rather than redistribution into the public Internet, because this technique is only really relevant in a large enterprise network. Even here, it's easy to create routing loops, particularly when redistributing from BGP into an IGP and then back out into BGP. This is why we have actually chosen to distribute from BGP into the other protocols, rather than full two-way redistribution. We will discuss two-way redistribution in a moment.

For Internet connections, we strongly recommend against redistributing routes from BGP into the IGP. This is because it is too easy to inadvertently wind up distributing tens of thousands of Internet routing prefixes into your IGP. And, when passing IGP routing information to the Internet, it is better to pass a few summary routes using network statements, as we have done in the above example, than to directly redistribute IGP prefixes.

In addition, there is a huge danger when you redistribute BGP routes from the Internet, into an IGP, and then back into BGP and onto the Internet. Unless you carefully filter routes, or unless your ISP filters for you, you will wind up sending routes back into the Internet with very short AS Paths that originate in your network. This could reroute the entire Internet through your IGP, which would be a Bad Thing.

However, BGP isn't just used on the public Internet. Many large enterprise networks also use BGP for interconnecting IGPs. In this case, although you have to redistribute routes from BGP into the IGP, it may not be necessary to redistribute IGP routes into BGP. So, in the above example, we have actually only used one-way redistribution from the BGP into the IGP, but not the other way around. Instead, we have relied on network statements to summarize the IGP routes into BGP:

Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65520
Router1(config-router)#network 172.26.0.0

If you need BGP to advertise a large number of IGP routes, you can use as many network statements as are necessary to accomplish this. Note that before IOS Version 12.0, you could configure a maximum of 200 network statements. However, Cisco has now removed this restriction.

Having said all of this, it is possible to redistribute prefixes from the IGP into BGP. Two-way redistribution can be convenient when you want to use BGP to connect two IGPs that use overlapping address ranges. This might happen, for example, if a single IGP became too large and needed to be split for stability reasons.

We have already discussed how to redistribute foreign routing protocols into both EIGRP and OSPF in Chapters 7 and 8, respectively, so we will focus instead on the redistribution of these protocols into BGP here.

The work is all done by a simple redistribute command in the BGP configuration clause. For simple redistribution, all we need to do is specify the IGP protocol and its process ID number:

Router1(config)#router bgp 65500
Router1(config-router)#redistribute ospf 100

However, by default, when you do this, BGP takes the IGP metric and uses it as the BGP metric, also called the MED. BGP distributes this metric with the route. Routers use the lowest metric value to select the best route if two or more BGP routes have the same AS Path length.

This may provide exactly the right behavior, selecting the BGP router that is closest to the IGP destination network. But in some cases you might want to force a particular metric value to ensure that a particular BGP router or link is used when routing to IGP destinations. You can do this most easily by simply setting a default metric for all redistributed IGP routes:

Router2(config)#router bgp 65520
Router2(config-router)#redistribute eigrp 99 metric 500

Although we have only assigned a default metric to the EIGRP routes, you can use the same syntax to give a default metric to the routes redistributed from OSPF.

We also mentioned in Chapters 7 and 8 that you can assign a route tag to external routes in both OSPF and EIGRP. This can be extremely useful when you do lots of redistribution. In particular, suppose that the EIGRP and OSPF sides of this network have a back door connection to one another, redistributing part or all of their routing tables. In this case, we will need to restrict which routes we redistribute into BGP and suppress all of these back door routes, or we will have routing loop problems.

You can do this with a route map. The simplest case, which is useful for the back door example, is to suppress all external routes when redistributing from the IGP into BGP:

Router2(config)#route-map REDIST deny 10
Router2(config-route-map)#match route-type external
Router2(config-route-map)#exit
Router2(config)#route-map REDIST permit 20
Router2(config-route-map)#exit
Router2(config)#router bgp 65520
Router2(config-router)#redistribute eigrp 99 route-map REDIST metric 500

You would need to apply a similar route map at both redistribution points to prevent loops.

However, the route map we just created will match all external routes, not just the external routes due to the back door connection. You might have some redistributed static routes in your IGP, or perhaps some isolated part of your network uses RIP to support legacy equipment. This is where route tags become invaluable. If you have external routes you need to redistribute into BGP, and you know they have a particular tag value such as 123, you can use a slightly more complicated route map like this:

Router2(config)#route-map REDIST permit 5
Router2(config-route-map)#match tag 123
Router2(config-route-map)#exit
Router2(config)#route-map REDIST deny 10
Router2(config-route-map)#match route-type external
Router2(config-route-map)#exit
Router2(config)#route-map REDIST permit 20
Router2(config-route-map)#exit
Router2(config)#router bgp 65520
Router2(config-router)#redistribute eigrp 99 route-map REDIST metric 500

This route map now allows BGP to redistribute all local routes and all external routes that have the tag value 123. But it suppresses all other external routes. You might use a redistribution system like this if you were using BGP to act as a transit between two networks. The router that redistributes routes into BGP from the other network would mark them with this tag value. Then, at this router, we can use this tag to select only these particular external routes for distribution into this particular IGP.

Removing Private ASNs from the AS Path

Problem

You want to prevent your internal private ASNs from reaching the public Internet.

Solution

You have to be extremely careful that any unregistered ASNs that you may be using don't propagate into the public Internet.

In this example, the router has a BGP connection to an ISP, which uses ASN 1. Our router uses ASN 2 and connects to another router with an unregistered ASN, 65500:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Serial0
Router1(config-if)#description connection to ISP #1, ASN 1
Router1(config-if)#ip address 192.168.1.6 255.255.255.252
Router1(config-if)#exit
Router1(config)#interface Serial1
Router1(config-if)#description connection to private network, ASN 65500
Router1(config-if)#ip address 192.168.5.1 255.255.255.252
Router1(config-if)#exit
Router1(config)#router bgp 2
Router1(config-router)#neighbor 192.168.5.2 remote-as 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 1
Router1(config-router)#neighbor 192.168.1.5 remove-private-AS
Router1(config-router)#no synchronization
Router1(config-router)#exit
Router1(config)#end
Router1#

Discussion

An unregistered ASN is a little bit like an unregistered IP address, in that anybody can use it. So if your routing prefixes have an unregistered ASN, this information is eventually passed to another router somewhere else in the Internet, and that router happens to be using the same unregistered ASN, then that router will assume that there is a routing loop, and drop your routes.

Having said this, if you look on an Internet backbone router at any given moment, there is a reasonably good chance of seeing several unregistered ASNs being propagated. This is a dangerous situation because the misbehaving networks could well be working perfectly well today. But tomorrow somebody else could start using the same unregistered ASN. Every route from the first network will look like a loop when received by the second network. So two ASs will not be able to communicate if they both use the same ASN.

All of the work in this example is done by the simple remove-private-AS command. Here is what the BGP route table looks like on this router:

Router1#show ip bgp
BGP table version is 6, local router ID is 192.168.55.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

 Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         172.20.1.2               0             0 1 i
*> 172.21.0.0       172.25.1.7               0             0 65500 i
*> 172.25.1.0/24    172.25.1.7               0             0 65500 i
Router1#

As you can see, we are receiving information about network 10.0.0.0 from the ISP router in AS 1, and 172.21.0.0 from the router with ASN 65500. Looking at the routes on the ISP router before turning on the remove-private-AS feature, you can see that this private ASN is propagating into the Internet, which is not allowed:

Router3#show ip bgp
BGP table version is 8, local router ID is 172.20.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

 Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         0.0.0.0                  0         32768 i
*> 172.21.0.0       172.20.1.1                             0 2 65500 i
*> 172.25.1.0/24    172.20.1.1                             0 2 65500 i
Router3#

But after turning on the command, as shown above, all of the private ASNs are removed, while the routes are propagated normally:

Router3#show ip bgp
BGP table version is 8, local router ID is 172.20.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

 Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.0.0         0.0.0.0                  0         32768 i
*> 172.21.0.0       172.20.1.1                             0 2 i
*> 172.25.1.0/24    172.20.1.1                             0 2 i
Router3#

Be careful of this feature, though, because it can't remove private ASNs from the middle of an AS Path. If you have a topology where there is a public ASN behind a private one, it's not safe to remove the private ASN because you could cause routing loops. So the remove-private-AS feature completely gives up and passes on the entire path for routes that have a public ASN after a private ASN.

If this is the case, your only recourse is to suppress the route with the illegal path. Then, as long as you distribute a prefix that includes this route, everything will work.

Prepending ASNs to the AS Path

Problem

You want to increase the length of an AS Path so that one inbound path looks better than another.

Solution

In situations when you have multiple connections between ASs, you will often want to make remote networks prefer one inbound path when sending packets to your network. The easiest way to do this is to prepend your own ASN to the AS PATH several times, instead of just once, as it would do by default:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip as-path access-list 15 permit ^$
Router1(config)#route-map PREPEND permit 10
Router1(config-route-map)#match as-path 15
Router1(config-route-map)#set as-path prepend 65500 65500 65500
Router1(config-route-map)#exit 
Router1(config)#route-map PREPEND permit 20
Router1(config-route-map)#exit 
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#neighbor 192.168.1.5 route-map PREPEND out
Router1(config-router)#exit
Router1(config)#end
Router1#

This example uses the same network shown in Figure 9-2, earlier in this chapter.

Discussion

We have already discussed methods for making your outbound traffic prefer one path over another in Recipe 9.7. But, as we mentioned in that recipe, that only affects your outbound path. If you also want to ensure that inbound traffic prefers one path over another, then you have to somehow trick the remote networks into believing that one path is better than the other.

As we mentioned in the Introduction to this chapter, if there are many options for different paths to a destination network, a BGP router will go through several steps to decide which one to use. You can adjust the attributes associated with each route to help force other BGP routers to select the paths that you want them to use. The easiest way to force routers outside of your AS to favor a particular route is to adjust the AS Path.

If you can simply make the path appear longer for routes that use one link, then remote networks will tend to prefer to reach you through whatever other links are available. There will always be situations when it is still closer to use the route with the artificially lengthened path. But these should be relatively rare, and the more times you prepend your ASN to the path, the less likely this will be.

Of course, it isn't safe or wise to put an arbitrary ASN into the AS Path. But you can insert your own ASN a few extra times without causing any problems, which is exactly what this recipe shows. Note that there is no hard limit to how long your AS Path can be (although it would probably cause problems if the path were so long that the routing information couldn't fit into a single BGP packet), and some sites prepend their ASN 10 or 20 times to make absolutely certain that a particular path is used only in case of a failure of the primary path. However, the longest AS Paths in the public Internet rarely have more than a dozen ASNs. So you shouldn't need to prepend your ASN very many times to make one path look better than the other from anywhere in the Internet.

This recipe also takes the precaution of only lengthening the AS Paths of locally generated routes. It does this by including a match clause in the route map that only affects routes that have an empty AS Path. Clause number 20 in the route map is a catch-all that simply passes through all other routes unchanged:

Router1(config)#ip as-path access-list 15 permit ^$
Router1(config)#route-map PREPEND permit 10
Router1(config-route-map)#match as-path 15
Router1(config-route-map)#set as-path prepend 65500 65500 65500
Router1(config-route-map)#exit 
Router1(config)#route-map PREPEND permit 20
Router1(config-route-map)#exit

But you might not want this restriction. You might prefer to rewrite all of the routes that you send. Or, you might use an outbound filter, such as the one discussed in Recipe 9.4, to suppress external routes. In both of these cases, you can make the route map considerably simpler:

Router1(config)#route-map PREPEND permit 10
Router1(config-route-map)#set as-path prepend 65500 65500 65500
Router1(config-route-map)#route-map PREPEND permit 20
Router1(config-route-map)#exit

The difference caused by prepending your ASN to the AS Path of a route is only visible on a remote router:

Router3#show ip bgp 172.18.5.0/24
BGP routing table entry for 172.18.5.0/24, version 26
Paths: (2 available, best #2)
Advertised to non peer-group peers:
 192.168.1.6
65500 65500 65500 65500
 192.168.1.6 from 192.168.1.6 (172.18.5.2)
   Origin IGP, metric 0, localpref 100, valid, external, ref 2
65531 65520 65500
 192.168.99.6 from 192.168.99.6 (192.168.99.10)
   Origin IGP, localpref 100, valid, external, best, ref 2
Router3#

Here you can see that there are two routes for the prefix 172.18.5.0/24, one passes through AS 65500 and the other through ASs 65531 and 65520 to reach AS 65500. The path that goes directly to AS 65500 is actually shorter. But, because we have prepended the ASN three times on this route, this router prefers the other path.

You can also verify that everything is working properly by disabling the peer relationship with the preferred ISP and making sure that everything still works. You can temporarily disable a peer with the by using the shutdown keyword on the neighbor command:

Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.2.5 shutown

Be sure to re-enable this peer after you have finished testing:

Router1(config)#router bgp 65500
Router1(config-router)#no neighbor 192.168.2.5 shutown

Summarizing Outbound Routing Information

Problem

You want to summarize your routing table before forwarding it to another router.

Solution

BGP includes an automatic summarization feature that is on by default:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65520
Router1(config-router)#auto-summary
Router1(config-router)#exit
Router1(config)#end
Router1#

Discussion

By default, BGP will try to summarize routes. This is not always desirable, though, which is why we have explicitly disabled this feature in many of the examples in this chapter. In fact, many engineers prefer to manually summarize their routing tables because they want to control what gets summarized and what doesn't.

The first problem with auto-summarization is that it is strictly classful. Your AS may not control all of the subnets in a classful network, and even if you do, this may not be the most useful prefix on which to summarize your networks. The second problem is that autosummarization only works on routes that are redistributed into BGP, and not on routes from BGP or routes injected via the network command. Please refer to Recipe 9.14 for more information on redistributing routes into BGP.

Suppose you wanted to summarize several routes to a single nonclassful route, or to summarize routes from several downstream BGP networks. You might be tempted to handle this by redistributing a static route for the summary and suppressing the individual routes with a filter. The problem with doing this is that the static route never goes away, even if all of the routes that you are trying to summarize become unreachable.

Cisco gets around this problem by implementing a special aggregate-address command that allows you to do the summarization without needing to manually create some routes and suppress others.

In the network shown in Figure 9-3, suppose the engineer responsible for AS 65530 wants to summarize the routes he receives from AS 65501 before passing this information along to another AS such as AS 65520. Router1 in AS 65501 advertises the prefixes 172.20.0.0/16 and 172.21.0.0/16, which it learned from Router2 in AS 65502, and adds to it the prefixes 172.22.0.0/16 and 172.23.0.0/16. All of these networks are covered by the aggregate address, 172.20.0.0/14:

Router3(config)#router bgp 65530
Router3(config-router)#aggregate-address 172.20.0.0 255.252.0.0 summary-only

Figure 9-3. Route aggregation example

The summary-only keyword here means that BGP will suppress the individual subnets. On the router doing the route aggregation, you can see which routes will be suppressed:

Router3#show ip bgp
BGP table version is 29, local router ID is 172.20.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

 Network          Next Hop            Metric LocPrf Weight Path

s> 172.20.0.0      172.21.2.2               0             0 65501 65502 ?
*> 172.20.0.0/14   0.0.0.0                            32768 i
s> 172.21.0.0      172.21.2.2               0             0 65501 65502 ?
s> 172.22.0.0      172.21.2.2               0             0 65501 ?
s> 172.23.0.0      172.21.2.2               0             0 65501 ?
Router3#

Then, in downstream ASs such as AS 65520, there is no indication of the summarized networks:

Router4#show ip bgp
BGP table version is 284, local router ID is 172.27.9.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

 Network          Next Hop        Metric LocPrf Weight Path

*> 172.20.0.0/14   172.25.1.6                         0 65530 i
Router4#

If you omit the summary-only keyword, BGP will advertise the summary address as well as the summarized subnets:

Router4#show ip bgp
BGP table version is 284, local router ID is 172.27.9.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

 Network          Next Hop        Metric LocPrf Weight Path

*> 172.20.0.0      172.25.1.6                         0 65530 65501 65502 ?
*> 172.20.0.0/14   172.25.1.6                         0 65530 i
*> 172.21.0.0      172.25.1.6                         0 65530 65501 65502 ?
*> 172.22.0.0      172.25.1.6                         0 65530 65501 ?
*> 172.23.0.0      172.25.1.6                         0 65530 65501 ?
Router4#

As long as the router doing the aggregation continues to see any routes that are within the summarized range, it will advertise the summary route. However, if all of the component routes disappear, it will stop advertising the summary. This is true whether or not you use the summary-only keyword:

Router4#show ip bgp 172.20.0.0
% Network not in table
Router4#

There is a problem with doing route summarization because it inherently discards information. To see why this can cause problems, suppose there was a link between Router1 and Router4. Router4 will advertise the summary route, which does not have Router1's ASN in the AS Path. So Router1 will accept this as a new, distinct route that passes through Router4. If Router1 then loses its route to one of the summarized addresses, say 172.23.0.0/16, it will try to use the summary route, and send packets for this prefix to Router4. Router4 will forward the packets to Router3. If Router3 still has the suppressed route in its BGP table, it will simply forward the packet back to Router1, completing a routing loop.

Eventually Router3 will purge the unreachable prefix from its routing table, but in more complex networks, it could take a while for this to happen.

To get around this problem, BGP includes the concept of an AS Set that can be used with route aggregation. An AS Set is a grouping of ASNs in an AS Path. It indicates that the route passed through one or more of the listed ASs, although it doesn't show their order. Because the AS Path now contains every ASN, you can again eliminate loops.

You can enable AS Sets with the as-set keyword in the aggregate-address command:

Router3(config)#router bgp 65530
Router3(config-router)#aggregate-address 172.20.0.0 255.255.252.0 as-set summary-only

Then, on a downstream router, the show ip bgp output includes the AS Set and represents it in curly braces:

Router4#show ip bgp
BGP table version is 36, local router ID is 172.25.26.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

 Network          Next Hop       Metric LocPrf Weight Path

*> 172.20.0.0/14   172.25.1.6                       0 65530 {65501,65502} ?
Router4#

And you can see more detail by specifying the route prefix with the show ip bgp command. Note that this output even tells you the BGP router ID of the router that did the aggregation as well as the ASN that this router resides in:

Router4#show ip bgp 172.20.0.0
BGP routing table entry for 172.20.0.0/14, version 36
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
65530 {65501,65502}, (aggregated by 65530 172.20.100.1)
  172.25.1.6 from 172.25.1.6 (172.27.9.1)
    Origin incomplete, localpref 100, valid, external, best
Router4#

You need to be careful with route summarization, particularly when you don't control all of the subnets in the range that you intend to summarize. In our example, suppose we advertised the summary for 172.20.0.0/14, but we didn't know how to route some part of this range, such as 172.21.15.0/24.

Ideally, this wouldn't actually matter because the real owner of 172.21.15.0/24 and its subnets would advertise a more precise route than our summary. But this is not a completely ideal world, and sometimes people might filter out the longer masks as a matter of course to reduce their routing tables (as we did in Recipe 9.11). So it is entirely possible that our router will be called upon to route packets for a device in 172.21.15.0/24. If our response to this is simply to toss the packet back to our default gateway, then we could easily wind up with a routing loop.

If you intend to summarize, make sure you can vouch for all the subnets you are summarizing. This is true regardless of the techniques you use.

Reducing the Size of the Received Routing Table

Problem

You want to summarize the incoming routing information to reduce the size of your routing table.

Solution

One of the easiest ways to reduce your routing table size is to filter out most of the external routes and replace them with a default. To do this, you first create a static default route pointing to some known remote network. If this remote network is up, then you can safely assume that your ISP is working properly. Then you simply filter out all of the remaining uninteresting routes:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip route 0.0.0.0 0.0.0.0 192.168.101.0 1
Router1(config)#ip route 0.0.0.0 0.0.0.0 192.168.102.0 2
Router1(config)#ip prefix-list CREATE-DEFAULT seq 10 permit 192.168.101.0/24
Router1(config)#ip prefix-list CREATE-DEFAULT seq 20 permit 192.168.102.0/24
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65520
Router1(config-router)#neighbor 192.168.1.5 prefix-list CREATE-DEFAULT in
Router1(config-router)#exit
Router1(config)#end
Router1#

Discussion

For most typical Internet connections, you will need to drastically reduce the amount of routing information that you receive. A typical Internet backbone router needs to support BGP routes for well over 100,000 prefixes. So unless you are operating the ISP and need to support a large fraction of the public address space, it is a good idea to cut out as much as possible. It is important to remember that removing routing information means that some of your routing decisions will not be as good as they might otherwise be, however. There is always a tradeoff involved in filtering routing information.

This recipe shows a good way to drastically reduce the size of your Internet routing table. It looks for two different remote networks on the Internet, 192.168.101.0/24 and 192.168.102.0/24, and points a default route to each of them. This way, if either route happens to fail because of some normal (but hopefully rare) network problem, you will still have a default route. Then we created a prefix list that allows only these two routes, and applied it to all routes that we received from the peer router at our ISP. Please refer to Recipe 9.6 for more information on prefix lists.

The result is a very small Internet routing table that consists of only these two routes and a default route with two destinations. In practice, you will probably want to use more than two routes, however. Just to guard against the possibility that the remote networks you picked happen to be down at the same time for some reason, it is a good idea to pick a wide variety of different remote networks, some very far away and some relatively close. Avoid picking all of them in the same country, so you won't lose your default just because of a telecom disaster in that country. You could even pick a dozen or so remote routes like this, giving excellent fault tolerance, while still providing a tiny Internet routing table.

Notice the two static routes in the example have different administrative distances:

Router1(config)#ip route 0.0.0.0 0.0.0.0 192.168.101.0 1
Router1(config)#ip route 0.0.0.0 0.0.0.0 192.168.102.0 2

We did this to prevent load balancing between the default routes. If you have more than one ISP, it is quite likely that the best routes for these prefixes will be through different providers. You can allow load balancing, if you prefer, by simply giving all of these static routes the same administrative distance. But bear in mind that this will balance among routes, not among ISP connections.

If you have only one ISP, on the other hand, load balancing between these default routes accomplishes nothing useful.

If you then want to pass this default route information along to other routers by using BGP, the best way to do so is to use the default-originate option on the neighbor command, and include a route map to specify the prefixes that you want to associate with your default route:

Router1(config)#ip prefix-list CREATE-DEFAULT seq 10 permit 192.168.101.0/24
Router1(config)#ip prefix-list CREATE-DEFAULT seq 20 permit 192.168.102.0/24
Router1(config)#route-map DEFAULT-ROUTE permit 10
Router1(config-route-map)#match ip address prefix-list CREATE-DEFAULT
Router1(config-route-map)#exit
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 172.18.5.3 default-origniate route-map DEFAULT-ROUTE
Router1(config-router)#exit

This is a dangerous thing to do, though, because BGP will now start to distribute default routing information to this peer, which may then start to distribute the default route out to the Internet. So it is a good idea to explicitly suppress the default route for any peers that should not receive it, and do this on all of your BGP routers:

Router1(config)#ip prefix-list BLOCK-DEFAULT permit 0.0.0.0/0 ge 1
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 prefix-list BLOCK-DEFAULT out

Another popular way to reduce the size of the Internet routing table is to simply refuse to accept any routes /24 prefixes. Over 50 percent of the routes appearing on the Internet backbone are for /24 prefixes. So eliminating them will cut the memory requirements in half:

Router1(config)#ip prefix-list BLOCK-24 permit 0.0.0.0/0 le 23
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 prefix-list BLOCK-24 in

However, if you do this, you should also use a default static route method discussed earlier. This is because some of the /24 prefixes in the Internet routing tables may not be included in other prefixes or summary routes.

We note in passing that the fraction of routes appearing on the backbone with a /24 prefix is steadily dropping over time. In early 2001, almost 59 percent of all prefixes were /24 networks, while over two years later in 2003, the number had dropped to roughly 55 percent. We expect this trend to continue over time, as ISPs improve their route summarization.

Filtering BGP Routes Based on AS Paths

Problem

You want to filter the BGP routes that you either send or receive based on AS Path information.

Solution

You can use AS Path filters, either inbound or outbound, to filter either the routes you send or the routes you receive, respectively. You must apply these filters to each peer separately:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip as-path access-list 15 permit ^65501$
Router1(config)#ip as-path access-list 25 permit _65530_
Router1(config)#ip as-path access-list 25 deny _65531$
Router1(config)#ip as-path access-list 25 permit .*
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65510
Router1(config-router)#neighbor 192.168.1.5 filter-list 15 in
Router1(config-router)#neighbor 192.168.2.5 remote-as 65520
Router1(config-router)#neighbor 192.168.2.5 filter-list 25 out
Router1(config-router)#exit
Router1(config)#end
Router1#

Discussion

One of the most common reasons for filtering routes based on the AS Path is to prevent AS transit, as we showed in Recipes 9.4 and 9.5. However, there are some other useful applications for AS Path filters. The example shown above contains two distinct filters, one of which applies to routes received inbound from one neighbor, and the other works on outbound routes sent to a second neighbor.

AS Path filters are constructed by using a subset of UNIX regular expressions. Regular expressions provide an extremely powerful and general pattern matching syntax. Many scripting languages, such as Perl, Java, awk, sed, PHP, and Python, use regular expressions for string manipulation. A detailed description of the syntax is out of the scope of this book, but fortunately, BGP path filters don't require all of the magic of the regular expression syntax. This is because all AS Paths consist of simply numbers separated by whitespace. There are no other characters to worry about, and every AS Path has a similar construction. Only the specific ASNs and the number of whitespaces ever change. For more information on regular expressions in general, please refer to Mastering Regular Expressions by Jeffrey Friedl (O'Reilly).

In Recipe 9.4, we showed a simple AS Path filter, which used the pattern ^$. In a regular expression, the symbol ^ stands for the start, and $ for the end of the field. So the pattern ^$simply means that the field is empty because the start is immediately followed by the end. In the case of a BGP AS Path, that means that this route must originate inside this AS.

Looking at the example above, then, it should be clear that access-list number 15 looks for paths that contain only one ASN, which must be 65501:

Router1(config)#ip as-path access-list 15 permit ^65501$

Because there is both a ^ and a $ in the pattern, this filter will match routes whose AS Path consists of just a single ASN, which must have a value of 65501. This filter will remove any downstream routes that AS 65501 is merely passing along. Also, as with normal access lists, AS Path filters end with an implicit deny all clause. So the router will suppress any other routes that don't match this pattern.

The second AS Path filter in the example is somewhat more complicated:

Router1(config)#ip as-path access-list 25 permit _65530_
Router1(config)#ip as-path access-list 25 deny _65531$
Router1(config)#ip as-path access-list 25 permit .*

This shows that you can have filters that span multiple lines, although the example itself is a little bit artificial. The first line in this filter permits any routes that pass through AS 65530. The ASN in this line is surrounded by _ characters. The _ character stands for whitespace, although it is a little bit confusing because, for example, _65530_ seems to imply that it will match the ASN 65530 only if it appears in the middle of an AS Path. But, in fact, _65530_ will match any path containing the ASN, 65530, even if it is at the beginning or the end of the path. Conversely, _65531$ will only match AS Paths that end with AS 65531, meaning those routes that originate in AS 65531.

This little _ delimiter character is extremely important because AS Path filters use a literal text pattern matching. For example, consider the following filter, which doesn't include this character:

Router1(config)#ip as-path access-list 26 permit 55

This AS Path filter will match not only paths containing AS 55, but any other ASN that happens to contain the digits 55, such as 65530, 7553, or 255. But it is unlikely that you actually want to match on substrings within an ASN like this. So you should always remember to include these delimiter characters.

We included the following line in the recipe example because we needed to counteract the implicit deny all at the end of any AS Path access list:

Router1(config)#ip as-path access-list 25 permit .*

This statement explicitly permits all other AS Paths that have not matched any of the earlier lines in the filter rule. The character "." in this filter matches any character, while the * indicates that there can be any number of characters. In fact, * literally means zero or more matches. In many cases, you actually need to match one or more times, for which you can use the + character.

There are many interesting uses for AS Path filters. For example, you might want to allow routes from an ISP and its immediate customers, but not from anything further away. This is easily accomplished with the following filter:

Router1(config)#ip as-path access-list 27 permit ^[0-9]+$
Router1(config)#ip as-path access-list 27 permit ^[0-9]+_[0-9]+$

This filter uses a couple of little tricks. The first trick is to specify a range, as in [0-9]. This means that the rule will match any character that falls in the range from 0 to 9, inclusive. Following this with the + character means that the rule matches one or more of these patterns. So the first line in this filter matches all paths that contain one and only one ASN, although it doesn't matter what this ASN actually is. The second line similarly matches all paths that contain exactly two ASNs. The net effect is to allow only routes from the directly attached ISP AS, and from any other AS that is directly connected to the ISP.

Another way to write the same thing is to match on the delimiters in the AS Path, instead of the actual ASN values. To do this, you might use a pattern like this:

Router1(config)#ip as-path access-list 28 deny _.+_.+_.+_
Router1(config)#ip as-path access-list 28 permit .*

In the first line of this access list, the "." character matches anything, including delimiters as well as digits. So this pattern will match an AS Path that includes at least four AS Path delimiters, with something in between them. Since the first and last delimiters could be the beginning and end of the AS Path, rather than actual whitespace, this access list causes the router to suppress any AS Path that includes three or more ASNs. It's slightly confusing because you have to think in terms of matching on delimiters rather than ASNs, but the net effect of AS Path access list number 28 is identical to 27 above. And, if you wanted to increase the maximum number of ASN values in the path from two to, say, five, this syntax is much more flexible:

Router1(config)#ip as-path access-list 29 deny _.+_.+_.+_.+_.+_.+_
Router1(config)#ip as-path access-list 29 permit .*

It's useful to remember that you can affect not only the routes you receive, but also the routes that you send using AS Path filters. In Recipe 9.4, we showed an extremely useful technique that uses AS Path filters to prevent an AS from being used for transit between external networks:

Router1(config)#ip as-path access-list 15 permit ^$
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65520
Router1(config-router)#neighbor 192.168.1.5 filter-list 15 out

In this case, the filter permits only routes that have an empty AS Path, meaning that the routes must have originated locally within this AS. This filter suppresses any external routing information when forwarding its routing table. So the external networks don't know about any downstream networks that can be reached through this router.

You could use a slightly more complicated outbound filter if you wanted. This example allows only directly connected networks to use your AS for transit:

Router1(config)#ip as-path access-list 16 deny _.+_.+_
Router1(config)#ip as-path access-list 16 permit .*
Router1(config)#router bgp 65500
Router1(config-router)#neighbor 192.168.1.5 remote-as 65520
Router1(config-router)#neighbor 192.168.1.5 filter-list 16 out

The router applies this filter before it adds itself to the AS Path. So when we deny the pattern _.+_.+_, this suppresses all AS Paths with two or more ASNs, leaving only AS Paths that have a single ASN. Any path with one ASN must originate in a directly connected AS.

This AS Path filter might seem a little bit confusing because it denies paths that we don't want rather than permitting the ones we do. If you prefer, you could create a filter that has the identical effect by explicitly permitting only the paths that we want and implicity denying the ones we don't want:

Router1(config)#ip as-path access-list 17 permit ^[0-9]+$
Router1(config)#ip as-path access-list 17 permit ^$

Both of these filters allow the router to forward routing information that originates in this AS, and in any networks that are directly connected to us. Bear in mind that this doesn't prevent a device that is fifteen hops away from reaching one of our neighbors through our network. But it does prevent them from reaching anything more distant than one of our direct neighbors through our AS.