QPPB for MPLS VPNs

[gauravprakash]

Hi,

I have a MPLS NNI Type C ( INter AS Option 10C)  for my inter-as L3VPNs. Now I want to police traffic per VPN or per customer, so that one VPN does not send too much traffic out of one ISPcloud over the NNI link, affecting other VPN traffic over the NNI link.

Can I do this with QPPB ? I think this is possible in IPv4 environment or if the requirement is exp based traffic policing, but now the case above.

PLz help

Thx,

Gaurav Prakash

[jcozzupoli]

Hi Gaurav,

I'd say its possible, look at this config guide:

http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_ip_prot_indep_ps6017_TSD_Products_Configuration_Guide_Chapter.html#wp1059912

Now to do it in an MPLS VPN environment look at the topology below:

CE1----PE1---------PE2----CE2

Now to implement QPPB on traffic between the 2 CEs, the following steps could be done:

1) PE1 is configured to set a community tag, say 250:1 to routes coming from CE1, who is part of vrf CUST_A

2) PE2 does a match on this BGP Community tag 250:1 and sets a qos-group value of 25 via a table-map under the BGP AF vpnv4

3) PE2 is configured with "bgp policy destination ip-qos-map" and the "rate-limit input qos-group 25" commands and traffic is rate-limited to the desired values on the interface towards CE2.

I will test this in my lab and get back to you.

HTH.

Joe.

[jcozzupoli]

Hi again,

I have tested my theory and it works. The only pre-requisit is that BGP is used as the PE-CE protocol.

I have attached the configs from my lab based on the same topology as my previous post. To explain what I did:

1. On PE2 I configured an inbound route-map under the MP-BGP VPNV4 AF to set all prefixes with BGP Community of 250:1

2. On PE2 I then configured a table-map under the ipv4 vrf CUST_A AF to match a community-list and set a qos-group value of 25

3. On PE2, under the PE-CE interface I applied the "bgp-policy destination ip-qos-map" to activate QPPB on this interface in an outbound direction (destination).

4. On PE2, again under the PE-CE interface, I applied the rate-limit command based on qos-group 25 and gave it some low values to show packets being dropped.

Here are some outputs showing how it works.

PE2 assigns Community of 250:1 to all prefixes from CE1 propagated via PE1:

PE2#sh ip bgp vpnv4 vrf CUST_A comm
BGP table version is 14, local router ID is 2.2.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
Route Distinguisher: 999:1 (default for vrf CUST_A)
*>i7.7.7.7/32       1.1.1.1                  0    100      0 65250 ?
*>i17.17.17.17/32   1.1.1.1                  0    100      0 65250 ?
*>i172.17.155.4/30  1.1.1.1                  0    100      0 65250 ?
PE2#

PE2#sh ip bgp vpnv4 vrf CUST_A 17.17.17.17
BGP routing table entry for 999:1:17.17.17.17/32, version 10
Paths: (1 available, best #1, table CUST_A)
  Advertised to update-groups:
     2        
  65250, imported path from 777:1:17.17.17.17/32
    1.1.1.1 (metric 20) from 1.1.1.1 (1.1.1.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: 250:1
      Extended Community: RT:7979:79,
      mpls labels in/out nolabel/22
PE2#

When I did a large ping to 17.17.17.17 (loopback IP on CE1) I could see QPPB taking effect, and hence I am dropping packets:

CE2#ping 17.17.17.17 r 100 si 1500

Type escape sequence to abort.
Sending 100, 1500-byte ICMP Echos to 17.17.17.17, timeout is 2 seconds:
!!!.!!.!!!.!!.!!!.!!.!!.!!!.!!.!!.!!!.!!!.!!.!!!.!!!.!!.!!.!!!.!!.!!.!
!!.!!!.!!.!!.!!!.!!.!!.!!.!!.!
Success rate is 71 percent (71/100), round-trip min/avg/max = 28/58/104 ms
CE2#

On PE2, I can see rate-limiting stats on the PE-CE interface reflecting the packet-loss seen on CE2:

PE2#sh int fa1/0 rate
FastEthernet1/0
  Input
    matches: qos-group 25
      params:  64000 bps, 1500 limit, 2000 extended limit
      conformed 114 packets, 172596 bytes; action: transmit
      exceeded 45 packets, 68130 bytes; action: drop
      last packet: 1030328ms ago, current burst: 0 bytes
      last cleared 00:26:51 ago, conformed 856 bps, exceeded 338 bps
PE2#

I hope this helped, please feel free to post further questions.

Joe.

[jcozzupoli]

Guys.

I must correct myself. You can use any IGP as your PE-CE protocol. I have updated my configs to show this. It all works the same. Silly me!!

Cheers,

Joe.

[Giuseppe Larosa]

Hello Joe,

good job.

Now, Gaurav was asking about an inter-AS VPN scenario and BGP community is not transitive so if BGP community is set on PE and not on CE it should be able to reach other provider in other AS.

OP speaks of option C.

in AF vpvnv4 I would expect send community both and not only extended

Reviewing your configuration everything is done on PE2 itself, this explains why you don't need use send-com both

Hope to help

Giuseppe

[jcozzupoli]

Hello Giuseppe,

Yeah if you look at my second bunch of configs, I am setting a community value on PE1 too (As I am redistributing OSPF into MP-BGP I have a route-map to set community on the prefixes), so I can be more controlling of what can be done on PE2 as well (i'm now trying to implement CBQoS instead of CTCAR). I did use community "both" as if left with default "extended" the community would not be sent to PE2.

I will try an Inter-AS solution in my lab, I don't see how it wouldn't work though.

Regards,

Joe.

[jcozzupoli · Accepted solution]

Hi again,

Yes I just ran an Inter-AS solution for QPPB for MPLS VPNs, worked fine. I tested with the Option A & B method (well my PE's are also acting as ASBRs, but I am VPNv4 eBGP peering), theoreticaly the other methods should work too.

Anyways. So my final answer on this is yes its possible to implement QPPB for MPLS-VPNs to control the rate of traffic going between different SPs.

HTH

Regards,

Joe.

[Giuseppe Larosa]

Hello Joe,

very good.

I had seen you were to near to test the whole solution so I tried to stimulate this last step.

Have a nice weekend

Best Regards

Giuseppe

[gauravprakash]

Hi,

Thanks for all the effort.

So we can do CTQoS & CTCAR over Inter-AS type B ( also A) NNI link for each of the VPN flowing over it separtely by using the RT.

I think we cannot do this for Type C , as VPN routes dont stay locally in ASBR where the binding bgp parameter and traffic policing is done..

Thx again,

Gaurav Prakash

[jcozzupoli]

Hi again,

Actually Option C is not a problem either! I can provide the working configurations if you like? Or I can add them to the Documentation section for everyone to access!

Regards,

Joe Cozzupoli.

[gauravprakash]

Yes, plz let share it, so that other can know it too

Thx very much for all your support..

rgds,

Gaurav

[websterc]

Hi All, great work

One quick question which would help my scenario

The example above seems to demonstate a rate-limit from CE2 towards CE1. How in an MPLS environment can you match the return traffic on PE2 ?

We are learning prefixes from an NNI which I can add a community too, but I wouldn't want to apply QOS there. My preference would be to use the PE-CE with a police in / shape out configuration. I don;t see how I apply the "bgp-policy source ip-qos-map"

Many thanks in advance

Clive