QoS Policy Propagation via BGP

QoS Policy Propagation via BGP (QPPB)

QPPB lets you map BGP prefixes and attributes to CEF parameters (like Precedence, QoS-group and traffic-index) that can be used to enforce traffic policing. QPPB allows BGP policy set in one location of the network to be propagated via BGP to other parts of the network, where appropriate QoS policies can be created.

QPPB allows you to classify packets based on access-lists, BGP community lists and BGP AS paths.

Network topology

Within AS 200, special treatment is required for traffic between AS 100 and AS 300 to and from prefix 172.16.0.0/16. R3 router is configured as Route-Reflector for AS 200 to avoid full-mesh. AS 100 also runs OSPF as IGP for internal reachability. QPPB involves following steps-

Step 1: Identifying and Tagging BGP prefixes that require preferential treatment

When the prefix 172.16.0.0/16 is first received from R1 via eBGP, R2 tags the prefix with BGP community 100:200.

Identifying traffic on R2

ip bgp-community new-format
!
ip prefix-list 10 seq 5 permit 172.16.0.0/16
!
ip as-path access-list 10 permit ^(100_)+$
!
route-map MARK_PREFIX permit 10
 match ip address prefix-list 10
 match as-path 10
 set community 100:200
!
router bgp 200
 neighbor 2.2.2.2 remote-as 200
 neighbor 2.2.2.2 update-source Loopback 0
 neighbor 2.2.2.2 send-community
 neighbor 2.2.2.2 route-map MARK_PREFIX out
!

Note

BGP Standard and Extended communities are removed from the reflected routes. To force RR to send these communities with the reflected-routes, use send-community both on RR.

Step 2: Setting FIB policy entries based on BGP tagging

As the prefix is propagated via iBGP to R4 inside AS 200, the BGP community is propagated as well. The following output shows that R4 receives 172.16.0.0/16 with community 100:200.

R4 receives 172.16.0.0/16 with community 100:200

R4# show ip bgp 172.16.0.0
BGP routing table entry for 172.16.0.0/16, version 63
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
        2
  100
    10.12.1.1 (metric 84) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 100:200
      Originator: 1.1.1.1, Cluster list: 2.2.2.2

When R4 receives the prefix with the matching attributes, it can set various FIB policy entries using table-map command in BGP. For QPPB, either IP Precedence or QoS-group ID or both can be set.

    • QoS-group ID: User-specified number that is assigned to a packet when that packet matches user-specified criteria. The packet can then be classified based on that number.

Setting QoS-group on R4 based on community 100:200

ip community-list 10 permit 100:200
!
route-map SET_POLICY permit 10
 match community 10
 set ip qos-group 10
!
router bgp 100
 table-map SET_POLICY

This causes R4 to apply route-map to BGP routes. The results are stored in the FIB used by CEF, which allows for IP Precedence or QoS-group (here) information to be stored for a route.

The show ip cef 172.16.0.0 command shows that prefix is marked with qos-group ID 10.

172.16.0.0/16 marked with qos-group 10

R4# show ip cef 172.16.0.0
172.16.0.0/16, version 19, epoch 0, cached adjacency 10.34.1.1
0 packets, 0 bytes, qos-group 10
  via 10.12.1.1, 0 dependencies, recursive
    next hop 10.34.1.1, FastEthernet0/0 via 10.12.1.0/24
    valid cached adjacency

Step 3: Configuring traffic lookup on an interface and setting QoS policies

Until now, routes have been marked in the FIB but no packets will be marked until we configure R4 to apply policy to incoming traffic on an interface. This is done using bgp-policy interface command.

This step is to classify incoming traffic from an interface based on the FIB policy entries. The incoming interface depends on the traffic's direction. If the traffic is destined for 172.16.0.0/16 in AS 100, the incoming interface will be Serial 1/0 on R4. If the traffic is destined for AS 300 from 172.16.0.0/16 in AS 100, the incoming interface will be Fastethernet 0/0 on R4.

FIB policy lookup can be configured using bgp-policy {source | destination} {ip-prec-map | ip-qos-map} command. The source and destination indicates whether to use source or destination IP address for FIB lookup. The ip-prec-map keyword specifies that IP Precedence bits are set for the matching packet. The ip-qos-map keyword specifies that QoS-group ID is set.

Traffic lookup and setting QoS policies on R4

interface serial 0/0
 ip address 10.45.1.1 255.255.255.0
 bgp-policy destination ip-qos-map
!

Step 4: Enabling policing on the interface as traffic is received and transmitted

Once the packets are marked, QoS tools like Policing can be used on these marked packets. The sample configuration shows that Policing is done for traffic destined for 172.16.0.0/16.

Traffic policing on R4

class-map match-all TO_AS100
 match qos-group 10
!
policy-map POLICE
 class TO_AS100
  police cir percent 50
!
interface serial 1/0
 service-policy input POLICE

The following output shows that when R5 sends ICMP packets to 172.16.0.0/16 prefix, R4 classifies this traffic based on qos-group ID and applies policing on the traffic.

Policy in action

R5# ping 172.16.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 108/180/228 ms
R4# show policy-map interface serial 0/0
 Serial0/0
  Service-policy input: POLICE
    Class-map: TO_AS100 (match-all)
      5 packets, 520 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: qos-group 10
      police:
          cir 50 %
          cir 772000 bps, bc 24125 bytes
        conformed 5 packets, 520 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps
    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any