Debugging route maps and BGP

Debugging route maps is very similar to debugging access lists for routing policies since both deal with manipulating routes. For the most part, the same techniques I covered with routing access lists can be used to find problems with route maps. There are, however, some problems and commands unique to working with route maps, and I discuss these in this section.

First of all, you need to know the most convenient way to see the contents of route maps and AS-path access lists. While showing the running configuration shows you all your route maps, this may be time-consuming if you have a long configuration. The show route-map command prints out all your route maps. When followed by a route map name, a specific route map is displayed. Recall the route map I created called ROUTES-OUT:

route-map ROUTES-OUT permit 10 match ip address 1

set metric 10

route-map ROUTES-OUT permit 20 match ip address 2

set metric 20

The show route-map output of this route map looks like this: Router1>show route-map ROUTES-OUT

route-map ROUTES-OUT, permit, sequence 10 Match clauses:

ip address (access-lists): 1 Set clauses:

Metric 10

Policy routing matches: 0 packets, 0 bytes route-map ROUTES-OUT, permit, sequence 20 Match clauses:

ip address (access-lists): 2 Set clauses:

Metric 20

Policy routing matches: 0 packets, 0 bytes

The output divides each route map entry into match and set clauses. The policy route matches should be ignored when looking at route maps for BGP.

AS-path access lists are treated similarly to access lists. The show ip as-path command, followed by an optional access list number, displays AS-path access lists. The AS-path access list below:

as-path access-list 5 permit ^3$ appears as:

Router1>show ip as-path 5

AS path access list 5 permit ^3$

One problem you may encounter is that despite extensive work on your route maps and associated access lists, the routing policy you have been trying to change may not be any different than when you started. The first reason to consider is that you may have forgotten to

force your peers to recognize the change, either through a soft reconfiguration or a hard reset. A good way to check this is with the show ip bgp command. Output from this command shows a version ID for BGP:

Router1# show ip bgp

BGP table version is 23029, local router ID is 192.168.18.100

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

The BGP table version should increase after a change. Another way to check is with the show ip bgp summary command. This command will show you how long each BGP session for each of a router's peers has been up, and this information tells you the last time each session was reset or how long it has been down:

Router1# show ip bgp summary

BGP table version is 10302748, main routing table version 1030748

61505 network entries (182249/244040 paths) using 14333788 bytes of memory 25192 BGP path attribute entries using 2952896 bytes of memory

12170 BGP route-map cache entries using 194720 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State 192.168.30.1 4 2 2713633 103161 1030743 0 0 2w2d

192.168.31.1 4 3 123449 103186 1030743 0 0 2w2d

In this example, you can see that this router connects to AS 2 and AS 3, and that each BGP connection has been running for more than two weeks. This is a better way to see if a reset has occurred.

The nature of the BGP route selection process creates a whole new set of ways to make a mistake. Often a route map change does not change actual policy because another route attribute was set that takes precedence over the changes you made. As an example, let's revisit the network in Figure 6.2. Let's say we want the 6-Mb line to be used only for backup. To affect the policy, we use the following:

! define AS path access lists and standard access lists to build policy sets

as-path access-list 5 permit^3$ access-list 5 permit any

!

! build route map

route-map INCOMING-UPDATES-6Mbit-LINE permit 10 match ip address 5

set as-path prepend 3 3 !

! define route map

route-map TO-AS-3 permit 10 set as-path prepend 1 1 ! router bgp 1 network 172.28.0.0 network 192.168.10.0 neighbor 192.168.30.1 remote-as 2 ! neighbor 192.168.31.1 remote-as 3

neighbor 192.168.31.1 route-map TO-AS-3 out neighbor 192.168.31.1 weight 15

AS-path prepending is used as a way to make the path through the 6-Mb line appear less preferred. Despite the route maps, however, traffic will still go out through 6-Mb line. Why? The path through the 192.168.31.1 has a higher weight than the other path through 192.168.30.1. Weight takes precedence over AS hops, and the BGP router configuration line that sets the weight needs to be deleted in order for the intended policy to work.

The directionality and scope of attribute changes is another potential problem. We may try to implement our previous policy using local preferences as shown:

! define AS path access lists and standard access lists to build policy sets

access-list 5 permit any ! build route map

route-map INCOMING-UPDATES-6Mbit-LINE permit 10 match ip address 5

set local-preference 80 ! define route map

route-map TO-AS-3 permit 10 set local-preference 80 ! router bgp 1 network 172.28.0.0 network 192.168.10.0 neighbor 192.168.30.1 remote-as 2 neighbor 192.168.31.1 remote-as 3

neighbor 192.168.31.1 route-map INCOMING-UPDATES-6Mbit-LINE in neighbor 192.168.31.1 route-map TO-AS-3 out

While traffic does not go out of the 6-Mb line from AS 1, it still uses the 6-Mb line to AS 1. The route map TO-AS-3 does not work because local preference applies only to incoming routes. AS path prepending or communities (if supported by AS 3) are the only solutions for the route map TO-AS-3.

Another key attribute to look out for is prefix length. Remember that BGP uses the most specific route (longest prefix) to make a routing decision. Let's say that we had the following configuration for Router 1 for the network in Figure 6.4:

! Router 1 route map

access-list 1 permit 172.28.0.0 access-list 2 permit any

access-list 3 permit 172.28.35.0 !

route-map ROUTES-OUT permit 10 match ip address 1

set metric 10

route-map ROUTES-OUT permit 20 match ip address 2

set metric 20 !

route-map SUPPRESS-172-28 permit 10 match ip addess 3

! bgp

router bgp 1

network 172.28.11.0 network 172.28.23.0 network 172.28.24.0 network 172.28.25.0 network 172.28.35.0 network 12.28.36.0

aggregate-address 172.28.0.0 255.255.0.0 suppress-map SUPPRESS-172-28 network 192.168.10.0

neighbor 192.168.30.1 remote-as 2

neighbor 192.168.30.1 route-map ROUTES-OUT out

Recall that we want to route traffic for 172.28.0.0 through AS 2 and network 192.168.10.0 through AS 3. We use only a few networks in network 172.28.0.0/16, but we aggregate all of them together as a /16 network. The routing policy we intend will not work, however, for traffic going to 172.28.35.0/24. Since we suppressed aggregation for this part of 172.28.0.0/16, it is treated differently from the 172.28.0.0/16 aggregate. Removing the suppress-map clause or adding the access list entry:

access-list 1 permit 172.28.35.0

fixes the problem. You might wonder how such a suppress-map got left on. At one point, a network administrator may have had a separate routing policy for that route map and forgot to take it off at one point. Outdated configurations can be another source of problems, especially if you have to change policies quickly and often.

Many ISPs have a maximum length prefix length for a given IP address range that they accept. ISPs that you purchase transit from are usually more generous in terms of allowing a longer prefix length. If you are advertising networks to multiple ISPs outside of the traditional class B and class C spaces, I suggest that you advertise routes to be a /19 or shorter. Otherwise you may find that some ISPs reject routes with longer prefixes. This can result in unpredictable behavior, such as some sites on the Internet being unreachable from particular networks while others are reachable.