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:

    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

Page updated

Google Sites

Report abuse