QoS Policy on GRE tunnel not activating

[mhattar]

Hi all,

Just wondering if someone ran into a similar issue like mine , I tried configuring a policy on a GRE tunnel in the outbound direction , it takes it into the config no problem , then you add the bandwidth statement on the interface , you get the message that the policy is activated ,  you do a "show policy-map int tu 0" , and its still showing in suspended mode.

s207-81-129-56(config-if)#do show policy-map int tu 0

Tunnel0

  Service-policy output: POLICYIN

    Service policy POLICYIN is in suspended mode

here are the relevant lines of config:

class-map match-any POLICYIN

match access-group name POLICYIN

policy-map POLICYIN

class POLICYIN

  priority percent 40

class class-default

  queue-limit 8 packets

  random-detect

=============

-also tried a nested parent policy with shaping average feature , instead of a single policy with a bandwidth statement on the interface.

-tried bandwidth qos-reference statement on the interface

- tried qos-preclassify with no use either

- also tried applying policy (both the shaping /nested policy) or the bandwidth statement with a single policy on the underlying interface loopback 0

[paul driver]

Hello

Is this tunnel part of a etherchannel?

Also on the tunnel interface have you applied?

int tun xx

qos pre-classify

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[mhattar]

Hi Pdiver,

I have tried that (As indicated in the description )

.

thanks,

[paul driver]

Hello

Apologies I didnt see that.

Please don't forget to rate any posts that have been helpful.

Thanks.

[Rodrigo Pires]

Hi Murad,

As fas as i know, when the allocated bandwidth exceeds the amount of available on the traffic policy remains suspended.

Have you tried to modify the traffic policy?

Also, i found this from cisco website "

For instance, if a traffic policy is attached to a tunnel interface  while another traffic policy is attached to a physical interface--with  which the tunnel interface is associated--only the traffic policy on the  tunnel interface works properly."

Here is the document:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/12-4t/qos-mqc-12-4t-book/qos-mqc.html

[]s

Please rate

[thiagohubes]

Murad,

Try this:

policy-map PARENT

     class class-default

          service-policy POLICYIN

          shap average percent XX

!

interface tunnel0

     service-policy output PARENT

[mhattar]

Hi Thiago and Rodrigo,

interface Tunnel0

bandwidth 5800

ip vrf forwarding outside

ip address 10.3.3.3 255.255.255.0

ip nat inside

ip inspect INSPECTION in

ip virtual-reassembly in

tunnel source Loopback0

tunnel destination 10.1.3.4

service-policy output POLICYINPARENT

s207-81-129-56#show policy-map POLICYINPARENT

  Policy Map POLICYINPARENT

    Class class-default

      Average Rate Traffic Shaping

      cir 5000000 (bps)

      service-policy POLICYIN

s207-81-129-56#show policy-map POLICYIN

  Policy Map POLICYIN

    Class POLICYIN

      priority 2000 (kbps)

    Class class-default

      queue-limit 8 packets

       wred, exponential weight 9

... So basically tried to place a parent policy so I would be able to trigger a congestion state..but that didn't help , it kept telling me the policy is in suspended mode. Thanks you all for your efforts though!

Cheers,

[Vishesh Verma]

Hi Murad,

What is the platform & IOS?

what is the interface through which this tunnel is going out?

show ip cef 10.1.3.4

Provide the configuration of the interface which comes in the ouput of command above.

-Vishesh

[mhattar]

Hi vishesh,

It's an 891 running C890-UNIVERSALK9-M), Version 15.2(4)M4.

#  show ip cef 10.1.3.4

10.1.3.4/32

  receive for Loopback1

show run int lo1

Building configuration...

Current configuration : 64 bytes

!

interface Loopback1

ip address 10.1.3.4 255.255.255.255

end

#show int lo1

Loopback1 is up, line protocol is up

  Hardware is Loopback

  Internet address is 10.1.3.4/32

  MTU 1514 bytes, BW 8000000 Kbit/sec, DLY 5000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation LOOPBACK, loopback not set

  Keepalive set (10 sec)

  Last input 00:00:00, output never, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: fifo

  Output queue: 0/0 (size/max)

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

     0 packets input, 0 bytes, 0 no buffer

     Received 0 broadcasts (0 IP multicasts)

     0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     15 packets output, 855 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 unknown protocol drops

     0 output buffer failures, 0 output buffers swapped out

cheers,

[paul driver]

Hello

What is the tunnel built upon - are the physical interfaces aggregated?

Are the source/destination addresses of the tunnel reachable to each other?


Res
Paul

Sent from Cisco Technical Support iPad App

[mhattar]

Hi Paul ,

the tunnel is sourced from a loopback interface on a VRF instance  no aggregation of any sort.

interface Tunnel0

bandwidth 5800

ip vrf forwarding outside

ip address 10.3.3.3 255.255.255.0

ip nat inside

ip inspect INSPECTION in

ip virtual-reassembly in

tunnel source Loopback0

tunnel destination 10.1.3.4

service-policy output POLICYINPARENT

the tunnel endpoints should be able to talk to each other I suppose as I am getting an internet feed though the tunnel . both endpoints are in UP/UP state.

Regards,

Murad

[paul driver]

Hello

The tunnel will be up anyway as you have no keepsalives specified

Do you have reachability between source and destination addresses of the tunnel with/without the qos policy applied


Res
Paul

Sent from Cisco Technical Support iPad App

[Vishesh Verma]

Hi Murad,

This is not making any sense to me. Tunnel is sourced from this router from loopback0 and is destined to loopback1 of the same router? Or is it that 10.1.3.4 is also a remote router which is routable through the VRF?

!

interface Tunnel0

  ip vrf forwarding outside

  tunnel source Loopback0

  tunnel destination 10.1.3.4

!

interface Loopback1

  ip address 10.1.3.4 255.255.255.255

!

end

Also, note that egress QoS features on 800 series router is supported only on the WAN links ATM, Routed Gigabit port. If the tunnel is going out of a physical interface which is part of Etherswitch Module(Vlan) QoS would be in suspended mode.

-Vishesh

[mhattar]

Hello Vishesh,

This is exactly why I have it setup like that , its because it's an 800 series router and I would like to apply Qos in the inbound direction. We know that the WAN interface only supports QoS in the outbound so I found the solution by creating a VRF and called it outside . created a tunnel interface between this VRF and the "global router" so that I can apply the policy on the tunnel interface 0  in the outbound direction , essentially being able to apply QoS in the inbound direction. I didn't mention these details in the initial description of the problem because I didn't want to overcomplicate it and incl. the details that are relevant to my problem.

The solution is found on this document on page 47 :

stor.balios.net/Live2012/BRKRST-3500.pdf

‎

router#show ip int br | e una

Interface                  IP-Address              OK? Method Status                Protocol

FastEthernet8              207.45.45.56   YES  DHCP   up                    up

Loopback0                  10.1.3.3              YES manual up                    up

Loopback1                  10.1.3.4              YES manual up                    up

NVI0                       207.45.45.56          YES  unset  up                    up

Tunnel0                    10.3.3.3                 YES  manual up                    up

Tunnel1                    10.3.3.4                  YES manual up                    up

Vlan1                      192.168.110.251   YES  manual up                    up

#show ip vrf outside

  Name                             Default RD          Interfaces

  outside                          1:1                 Tu0

                                                       Fa8

Also ping to 4.2.2.2 works as well when sourced from vlan 1 which means the packets are traversing the tunnel between global and outside VRF just fine .

#ping 4.2.2.2 source vl 1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 4.2.2.2, timeout is 2 seconds:

Packet sent with a source address of 192.168.110.251

!!!!!

Success rate is 100 p

Hope it makes sense now,

Cheers,

[Vishesh Verma]

Hi Murad,

It is kind of a Hack, and it is awesome. But as per BRKRST-3500.pdf it worked prior to HQF. Your router runs 15.2(4)M4, which implements HQF.

If you want to imlement it you have to downgrade the IOS code to some prior to 12.4(20)T. As HQF was introduced in this IOS code.

-Vishesh