Cisconinja’s Blog

Archive for the ‘BGP’ Category

QoS Policy Propagation with BGP

Posted by Andy on January 14, 2009

QoS Policy Propagation with BGP (QPPB) allows an IP Precedence value and/or QoS-group value to be associated with a BGP route entry.  This allows QoS policies to easily be applied within and between autonomous systems.  Suppose an ISP (AS 23) has 2 customers (AS 4 and AS 5) as shown below in the diagram:

qppb-topology3

Customer 1  (AS 4) is paying for premium service and should have all traffic to and from their networks marked as IP Precedence 2.  Customer 2 (AS 5) is paying for the standard level of service and should have all traffic to and from their networks marked as IP Precedence 0.  AS 1 is used as a remote network that both Customer 1 and Customer 2 are communicating with so that we can test the results of the QPPB configuration.  The initial configurations of each router are:

R1:
interface Loopback0
 ip address 1.1.1.1 255.255.255.0
!
interface Serial0/0
 ip address 192.168.12.1 255.255.255.0
!
router bgp 1
 network 1.1.1.0 mask 255.255.255.0
 neighbor 192.168.12.2 remote-as 23

R2:
interface Serial0/0
 ip address 192.168.23.2 255.255.255.0
!
interface Serial0/1
 ip address 192.168.12.2 255.255.255.0
!
router bgp 23
 neighbor 192.168.12.1 remote-as 1
 neighbor 192.168.23.3 remote-as 23
 neighbor 192.168.23.3 next-hop-self
!
ip bgp-community new-format

R3:
interface Serial0/0
 ip address 192.168.23.3 255.255.255.0
!
interface Serial0/1
 ip address 192.168.34.3 255.255.255.0
!
interface Serial0/2
 ip address 192.168.35.3 255.255.255.0
!
router bgp 23
 neighbor 192.168.23.2 remote-as 23
 neighbor 192.168.23.2 next-hop-self
 neighbor 192.168.34.4 remote-as 4
 neighbor 192.168.35.5 remote-as 5
!
ip bgp-community new-format

R4:
interface Loopback0
 ip address 4.4.4.4 255.255.255.0
!
interface Serial0/0
 ip address 192.168.34.4 255.255.255.0
!
router bgp 4
 network 4.4.4.0 mask 255.255.255.0
 neighbor 192.168.34.3 remote-as 23

R5:
interface Loopback0
 ip address 5.5.5.5 255.255.255.0
!
interface Serial0/0
 ip address 192.168.35.5 255.255.255.0
!
router bgp 5
 network 5.5.5.0 mask 255.255.255.0
 neighbor 192.168.35.3 remote-as 23

First, we’ll configure R3 to set the community attribute of routes received from Customer 1 to 4:23 and Customer 2 to 5:23:


R3:
route-map Customer1 permit 10
 set community 4:23
!
route-map Customer2 permit 10
 set community 5:23
!
router bgp 23
 neighbor 192.168.34.4 route-map Customer1 in
 neighbor 192.168.35.5 route-map Customer2 in
 
We can verify that R3 is setting the community string appropriately for these routes:  qppb-r3-community

Alternatively, we could have used an access list to match specific routes or used an AS path access list to match on the AS path attribute.  The community attribute is not sent by default, so R2 has no knowledge of what R3 has set it to:

 qppb-r2-nocommunitystring1

To configure the community string to be sent, use the neighbor send-community command on R3 and then verify that R2 is now receiving it:

R3:
router bgp 23
 neighbor 192.168.23.2 send-community

qppb-r2-communitystring

Now we can configure R2 to mark these routes with the appropriate policy by matching the community attribute:

R2:
ip community-list 4 permit 4:23
ip community-list 5 permit 5:23
!
route-map QPPB-test permit 10
 match community 4
 set ip precedence 2
!
route-map QPPB-test permit 20
 match community 5
 set ip precedence 0
!
router bgp 23
 table-map QPPB-test

 

This causes R2 to apply the route-map to the BGP routes.  The results are stored in the Forwarding Information Base (FIB) used by CEF, which allows for IP Precedence and/or QoS-group information to be stored for a route.  We can verify that the routes have been marked on R2:

 

qppb-r2-cef

At this point, the routes have been marked correctly in the FIB, but no packets will be marked until we configure R2 to apply the policy to incoming traffic on an interface.  The bgp-policy command is used to apply QPPB policy to packets entering an interface.  When a packet enters an interface with bgp-policy configured, the router can perform a FIB lookup on either the source address, destination address, or both.  However if both are used on the same interface, the router will perform 2 lookups, first on the source and then on the destination.  The packet will be classified first based on the source and then reclassified based on the destination.  To apply the appropriate policy on R2 to traffic being sent from Customer 1 and 2, we need to perform a source lookup on traffic entering S0/0, and a destination lookup on traffic entering S0/1:

R2:
interface Serial0/0
 bgp-policy source ip-prec-map
!
interface Serial0/1
 bgp-policy destination ip-prec-map

To verify that QPPB is marking packets appropriately, we will create a policy-map on R1 and R3 with 3 separate classes to match ICMP traffic with IP precedence 0, 2, and all other values.  Then we will apply the policy-map on R1 S0/0 and R3 S0/0 in each direction to check the markings being applied to traffic sent through R2: 

R1:
ip access-list extended ICMP-Prec0
 permit icmp any any precedence routine
ip access-list extended ICMP-Prec2
 permit icmp any any precedence immediate
ip access-list extended ICMP-PrecX
 deny icmp any any precedence routine
 deny icmp any any precedence immediate
 permit icmp any any
!
class-map match-all Prec0
 match access-group name ICMP-Prec0
class-map match-all Prec2
 match access-group name ICMP-Prec2
class-map match-all PrecX
 match access-group name ICMP-PrecX
!
policy-map CheckMarkings
 class Prec0
 class Prec2
 class PrecX
!
interface Serial0/0
 service-policy input CheckMarkings
 service-policy output CheckMarkings

 
R3:
ip access-list extended ICMP-Prec0
 permit icmp any any precedence routine
ip access-list extended ICMP-Prec2
 permit icmp any any precedence immediate
ip access-list extended ICMP-PrecX
 deny icmp any any precedence routine
 deny icmp any any precedence immediate
 permit icmp any any
!
class-map match-all Prec0
 match access-group name ICMP-Prec0
class-map match-all Prec2
 match access-group name ICMP-Prec2
class-map match-all PrecX
 match access-group name ICMP-PrecX
!
policy-map CheckMarkings
 class Prec0
 class Prec2
 class PrecX
!
interface Serial0/0
 service-policy input CheckMarkings
 service-policy output CheckMarkings

 

First we’ll test traffic in each direction between Customer 1 and AS 1 and clear the counters after each test:

qppb-r4-r1-ping

qppb-r4-r1-ping-r3

qppb-r4-r1-ping-r1

qppb-r1-r4-ping

qppb-r1-r4-ping-r1

qppb-r1-r4-ping-r3

As we can see, traffic between AS 1 and Customer 1 is remarked from it’s default precedence of 0 to a precedence of 2 in each direction.  Next let’s test the policy between AS 1 and Customer 2.  We’ll try having AS 1 and Customer 2 mark their traffic as precedence 4 and see if they can fool the ISP into getting better service:

qppb-r5-r1-ping1

qppb-r5-r1-ping-r31

qppb-r5-r1-ping-r1

qppb-r1-r5-ping

qppb-r1-r5-ping-r1

qppb-r1-r5-ping-r3

The traffic is remarked down to precedence 0, just as the policy specified.

Posted in BGP, QoS | Leave a Comment »