You Are Here: Home » Router » -Router Cisco » QoS Policy Propagation via BGP (QPPB)

QoS Policy Propagation via BGP (QPPB)

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 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 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

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 remote-as 200
neighbor update-source Loopback 0
neighbor send-community
neighbor route-map MARK_PREFIX out



BGP Standard and Extended communities are removed from the reflected routes. To force RR to send these communities with the reflected-routes, usesend-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 with community 100:200.

R4 receives with community 100:200

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

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 command shows that prefix is marked with qos-group ID 10. marked with qos-group 10

R4# show ip cef, version 19, epoch 0, cached adjacency
0 packets, 0 bytes, qos-group 10
  via, 0 dependencies, recursive
    next hop, FastEthernet0/0 via
    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 in AS 100, the incoming interface will be Serial 1/0 on R4. If the traffic is destined for AS 300 from 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 destinationindicates 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
 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

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 prefix, R4 classifies this traffic based on qos-group ID and applies policing on the traffic.

Policy in action

R5# ping

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, 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


  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
          cir 50 %
          cir 772000 bps, bc 24125 bytes
        conformed 5 packets, 520 bytes; actions:
        exceeded 0 packets, 0 bytes; actions:
        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

About The Author

Number of Entries : 295

Leave a Comment

© 2011 Powered By Wordpress, Goodnews Theme By Geeks Docuementation

Scroll to top