In the previous post I showed how bgp table-map can be used for the selective route download. Here we will take a look at another use of this command, that is, associating IP Precedence values with selected BGP prefixes.

By applying QoS policy to inbound prefixes we can easily mark traffic coming from a given AS, or going to a particular client. We can set IP Precedence value using route-map, and prefix list, ACLs, or communities to classify match prefixes of interest.

Topology for the examples to follow is shown below. We have an ISP router in the middle and two client routers, C1 and C2.

Client C1 advertises prefix 172.24.1.0/24 and C2 advertises prefix 172.16.1.0/24. ISP has both of those prefixes in its BGP and routing tables:

ISP#sh ip bgp | b Netw
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.1.0/24    10.1.1.2                 0             0 65027 i
*> 172.24.1.0/24    10.1.1.6                 0             0 65009 i

ISP#sh ip route | in B
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
B       172.16.1.0 [20/0] via 10.1.1.2, 00:00:15
B       172.24.1.0 [20/0] via 10.1.1.6, 00:00:15

So far so good. The next step is to create prefix lists, and route maps, which we will us use to set IP precedence values.

!!## ISP config

ip prefix-list PL_C1 permit 172.24.1.0/24
ip prefix-list PL_C2 permit 172.16.1.0/24

route-map RM_TMQOS permit 10
 match ip address prefix-list PL_C1
 set ip precedence 3
route-map RM_TMQOS permit 20
 match ip address prefix-list PL_C2
 set ip precedence 4

router bgp 65003
 table-map RM_TMQOS

Force refresh of the BGP routes:

clear ip bgp table-map

The below output confirms that both of the routes are now marked in the FIB.

ISP#sh ip cef 172.16.1.0
172.16.1.0/24, version 21, epoch 0, cached adjacency 10.1.1.2
0 packets, 0 bytes, Precedence flash-override (4)
  via 10.1.1.2, 0 dependencies, recursive
    next hop 10.1.1.2, FastEthernet0/1 via 10.1.1.2/32
    valid cached adjacency

ISP#sh ip cef 172.24.1.0
172.24.1.0/24, version 22, epoch 0, cached adjacency 10.1.1.6
0 packets, 0 bytes, Precedence flash (3)
  via 10.1.1.6, 0 dependencies, recursive
    next hop 10.1.1.6, FastEthernet0/0 via 10.1.1.6/32
    valid cached adjacency

Even though routes are marked in the FIB, no packets will have marking applied to them. To apply the policy to packets entering an interface we need to add the bgp-policy command to interface's configuration.

A FIB lookup for policy application can be performed on the source, destination, or both. If both, source and destination, are specified the lookup is done for source and then destination, essentially making destination policy override the source one.

In our example we will make CEF apply QoS based on the source of the packets.

!!## ISP router
int f0/0
 bgp-policy source ip-prec-map

int f0/1
 bgp-policy source ip-prec-map

Let's configure ACLs on C1 and C2 to match packets marked with IP Prec values of 3 and 4. We will also run a few pings to show that packets are indeed being marked.

!!## C1 router
ip access-list ext AL_TM_QOS
 permit ip any any precedence 3 log
 permit ip any any precedence 4 log
 permit ip any any dscp ef log
 permit ip any any

int f0/0
 ip access-group AL_TM_QOS in

!!## C2 router
ip access-list ext AL_TM_QOS
 permit ip any any precedence 0 log
 permit ip any any precedence 3 log
 permit ip any any precedence 4 log
 permit ip any any

int f0/0
 ip access-group AL_TM_QOS in

Time for ping testing. We will run pings with TOS of 0 and 184 (DSCP EF) to show that CEF remarks the packets on the ISP router.

Counters before:

C1#sh ip access-lists
Extended IP access list AL_TM_QOS
    10 permit ip any any precedence flash log
    20 permit ip any any precedence flash-override log
    30 permit ip any any dscp ef log
    40 permit ip any any

C2#sh ip access-lists AL_TM_QOS
Extended IP access list AL_TM_QOS
    10 permit icmp any any precedence routine log
    20 permit ip any any precedence flash log
    30 permit ip any any precedence flash-override log
    40 permit ip any any

Ping from C1, with TOS of 0:

C1#ping 172.16.1.1 source l10

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
Packet sent with a source address of 172.24.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/28/40 ms

Counters on C2:

C2#sh ip access-lists
Extended IP access list AL_TM_QOS
    10 permit icmp any any precedence routine log
    20 permit icmp any any precedence flash log (5 matches)
    30 permit icmp any any precedence flash-override log
    40 permit icmp any any (1 match)

Ping from C2, with TOS of 184:

C2#ping
Protocol [ip]:
Target IP address: 172.24.1.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.16.1.1
Type of service [0]: 184
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.24.1.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/33/48 ms

Counters on C1:

C1#sh ip access-lists
Extended IP access list AL_TM_QOS
    10 permit icmp any any precedence flash log
    20 permit icmp any any precedence flash-override log (5 matches)
    30 permit icmp any any dscp ef log
    40 permit ip any any (4 matches)

ACL counters confirm that the correct marking has been applied to all packets. ISP router remarked packets marked with IP Precedence 0 and DSCP EF, changing them to the values we set for each of the prefixes in our route-map.

Setting QoS based on the values associated with BGP prefixes is another interesting use of the bgp-table command and it's good to know how, and why, would you implement this feature.