BGP QoS Policy Propagation
Last updated
Last updated
Topology: russo-bgp-iol
Load unix:qpp.init.cfg
R6 is originating the IPv4 prefix 192.0.2.6/32. AS65000 (the service provider) has told AS 65006 that they can use community 65000:5 to allow destinations with this community to become mapped to IPP=5 in their core. This allows the traffic to receive higher priority.
R2 has a preconfigured QoS poilcy outbound towards R3 that matches IPP5. Configure R6 to send community 65000:5 with 192.0.2.6/32, so that traffic from R1 destined for this prefix will be marked with IPP5 at R2. Verify that traffic is indeed being marked as such by looking at the QoS policy on R2.
QoS policy propagation via BGP allows you to use communities or AS_PATH attributes to assign a precendence or QoS group to a BGP prefix. This can then be mapped upon ingress on an interface.
The solution uses the community value 65000:5 to identify destination traffic that should have IP precedence 5. This is just regular community configuration which you have seen before.
On R2, we use a route-map which matches community 65000:5 and sets IP precendence to 5. This is applied to the BGP process itself using a table-map.
At this point, we must clear the ip route for the prefix, or clear BGP. Once this is done, we should see that the prefix is associated with IP precedence 5 in the RIB and in the CEF table.
The last step is to configure the ingress interface so that it looks up either the source or destination IPv4 address of a packet in the FIB to get the corresponding IPP or QoS group value. When marking the IPP, the packet will be marked throughout the entire path. When using QoS group, the marking is only local to the router.
The command above instructs the router to look at the destination in the CEF table, and find an IPP mapping that comes from BGP.
When we ping 192.0.2.6 from R1, we should see the counters on the IPP5 class for Eth0/2 increment.
