Normally QoS policy will be applied based on Source IP, destination IP or combination of both, or IP header markings like DSCP/Precedence. Now with QPPB, it can also be applied based on BGP AS-PATH or community. This helps us apply QoS policy per customer.
How to configure QPPB?
QPPB can be configured by the following simple steps,
- On the edge PE devices, configure route-map to match BGP attributes like AS-PATH, community or using prefix match and mark IP Precedence or qos-group.
- Apply the same using table-map under BGP process.
- Apply BGP policy under the interface mentioning if source or destination of the incoming traffic to be matched for QoS treatment.
Below is the configuration example,
In this example, we use as-path to classify the traffic. As mentioned in Step 1, “route-map” will be configured to match 65004 in AS-PATH attribute field and will be applied to mark qos-group as 50,
R2#sh ip bgp regexp 65004
BGP table version is 3, local router ID is 172.16.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i10.1.4.4/32 172.16.3.3 0 100 0 65004 i
R2#
R2#config t
R2(config)#
R2(config)#ip as-path access-list 2 permit 65004
R2(config)#
R2(config)#route-map QPPB_USING_ASPATH
R2(config-route-map)#match as-path 2
R2(config-route-map)#set ip qos-group 50
R2(config-route-map)#exit
R2(config)#As mentioned in Step 2, Now apply the policy under BGP using “table-map” which will get reflected in RIB,
R2(config)#router bgp 65023
R2(config-router)#table-map QPPB_USING_ASPATH
R2(config-router)#end
As mentioned in Step 3, the policy will be applied in incoming interface of the traffic to apply the policy for destination address of the traffic,
R2(config)#int e0/0.12
R2(config-subif)#bgp-policy ?
accounting bgp based policy accounting of traffic (input on default)
destination use destination IP address for route lookup
source use source IP address for route lookup
R2(config-subif)#bgp-policy destination ip-qos-map ?
R2(config-subif)#bgp-policy destination ip-qos-map
R2(config-subif)#end
It should be noted that the policy will not affect any prefixes which are already present in BGP table while applying the same under BGP process.
R2#sh ip cef 10.1.4.4 detail
10.1.4.4/32, epoch 0
recursive via 172.16.3.3
nexthop 172.16.23.3 Ethernet0/0.23
Soft clearing the BGP process will not help with reflecting the policy at data plane,
R2#clear ip bgp * in
R2#clear ip bgp * ou
R2#sh ip cef 10.1.4.4 detail
10.1.4.4/32, epoch 0
recursive via 172.16.3.3
nexthop 172.16.23.3 Ethernet0/0.23
Once BGP is heard reset, policy will be applied to all required prefixes at data plane,
R2#clear ip bgp *
R2#sh ip cef 10.1.4.4 detail
10.1.4.4/32, epoch 0
QOS: qos-group 50
recursive via 172.16.3.3
nexthop 172.16.23.3 Ethernet0/0.23
R2#
For testing purpose, I have applied rate-limiting on egress port using qos-group 50 which is applied at ingress port. Now it can be observed that packet matches seen in rate-limit output,
R2#
interface Ethernet0/0.23
encapsulation dot1Q 23
ip address 172.16.23.2 255.255.255.0
rate-limit output qos-group 50 5000000 2500 2500 conform-action transmit exceed-action drop
end
R2#show int e0/0.23 rate-limit
Ethernet0/0.23
Output
matches: qos-group 50
params: 5000000 bps, 2500 limit, 2500 extended limit
conformed 0 packets, 0 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
last packet: 267139808ms ago, current burst: 0 bytes
last cleared 00:00:13 ago, conformed 0 bps, exceeded 0 bps
R2#
R4#ping 10.1.1.1 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.4.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R4#
R2#show int e0/0.23 rate-limit
Ethernet0/0.23
Output
matches: qos-group 50
params: 5000000 bps, 2500 limit, 2500 extended limit
conformed 5 packets, 590 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
last packet: 2564ms ago, current burst: 118 bytes
last cleared 00:00:29 ago, conformed 158 bps, exceeded 0 bps
R2#
No comments:
Post a Comment