QoS on tunnel subinterface VPN

janez_drkjanez_drk Member Posts: 27 ■□□□□□□□□□
in CCNP
I can't get this to work - I've been reading and trying but the results are not as expacted.

I would appriciate any type of help very much!

Here is the situation I have:

-Direct link(10Mbps)
-Site A - tunnel interface on gigeth 0/2
-Site B - tunnel interface on subinterface gigeth 0/2.1
-Config of QoS is on both tunnel interfaces

class-map match-any XXXXXXX
match access-group 120
class-map match-any YYYYYYY
match access-group 110
!
!
policy-map QOS
class XXXXXXX
bandwidth 3072
class YYYYYYY
bandwidth 3072
policy-map SHAPER
class class-default
shape average 10485760
service-policy QOS


On tunnel interface I have
service-policy output SHAPER

I want to reserve 3Mbps for traffic that matches access-list 110 and 3Mbps for traffic that matches ACL 120.
ACLs are OK - I see matches.

Any ideas?

Thank you!
· Share on FacebookShare on Twitter

Comments

  • networker050184networker050184 Mod Posts: 11,962 Mod
    What exactly is not working?

    Have you tried placing the 'qos pre-classify' command on the tunnel interface to ensure pre tunnels headers are inspected for QoS? Then place your policy on the outgoing interface.
    An expert is a man who has made all the mistakes which can be made.
    · Share on FacebookShare on Twitter
  • janez_drkjanez_drk Member Posts: 27 ■□□□□□□□□□
    Can you please look at this. To me it looks OK.


    This is the current config of my tunnel interfaces:
    interface Tunnel0
    bandwidth 10240
    ip unnumbered Loopback1
    ip ospf cost 50
    ip ospf mtu-ignore
    qos pre-classify
    keepalive 10 3
    tunnel source GigabitEthernet0/2
    tunnel mode ipsec ipv4
    tunnel destination x.y.x.y
    tunnel protection ipsec profile P1
    !
    service-policy output SHAPER



    #show int tunn0
    Tunnel0 is up, line protocol is up
    Hardware is Tunnel
    Description: TO
    Interface is unnumbered. Using address of Loopback1 (x.y.z.c)
    MTU 17878 bytes, BW 10240 Kbit/sec, DLY 50000 usec,
    reliability 255/255, txload 50/255, rxload 110/255
    Encapsulation TUNNEL, loopback not set
    Keepalive set (10 sec), retries 3
    Tunnel source x.y.z.c(GigabitEthernet0/2), destination x.y.z.c
    Tunnel Subblocks:
    src-track:
    Tunnel0 source tracking subblock associated with GigabitEthernet0/2
    Set of tunnels with source GigabitEthernet0/2, 3 members (includes iterators), on interface <OK>
    Tunnel protocol/transport IPSEC/IP
    Tunnel TTL 255
    Tunnel transport MTU 1438 bytes
    Tunnel transmit bandwidth 8000 (kbps)
    Tunnel receive bandwidth 8000 (kbps)
    Tunnel protection via IPSec (profile "P1")
    Last input never, 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: 5413
    Queueing strategy: fifo (QOS pre-classification)
    Output queue: 0/0 (size/max)
    5 minute input rate 4452000 bits/sec, 874 packets/sec
    5 minute output rate 2045000 bits/sec, 848 packets/sec
    1316800375 packets input, 4026486884 bytes, 0 no buffer
    Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
    1581911542 packets output, 2967340772 bytes, 0 underruns
    0 output errors, 0 collisions, 0 interface resets
    0 unknown protocol drops
    0 output buffer failures, 0 output buffers swapped out

    show policy-map int tunn0
    Tunnel0

    Service-policy output: SHAPER

    Class-map: class-default (match-any)
    218342535 packets, 55446297779 bytes
    5 minute offered rate 1739000 bps, drop rate 56000 bps
    Match: any
    Queueing
    queue limit 64 packets
    (queue depth/total drops/no-buffer drops) 0/12296142/0
    (pkts output/bytes output) 205703860/68002151400
    shape (average) cir 10485760, bc 41944, be 41944
    target shape rate 10485760

    Service-policy : QOS

    Class-map: XXXXXXXX(match-any)
    2815846 packets, 979228300 bytes
    5 minute offered rate 8000 bps, drop rate 0 bps
    Match: access-group 120
    2815846 packets, 979228300 bytes
    5 minute rate 8000 bps
    Queueing
    queue limit 64 packets
    (queue depth/total drops/no-buffer drops) 0/0/0
    (pkts output/bytes output) 2815846/1201868676
    bandwidth 3072 kbps

    Class-map: YYYYYYYYY(match-any)
    8826577 packets, 2475583159 bytes
    5 minute offered rate 83000 bps, drop rate 0 bps
    Match: access-group 110
    8826577 packets, 2475583159 bytes
    5 minute rate 83000 bps
    Queueing
    queue limit 64 packets
    (queue depth/total drops/no-buffer drops) 0/0/0
    (pkts output/bytes output) 8826577/3184120278
    bandwidth 3072 kbps

    Class-map: class-default (match-any)
    206357674 packets, 51896538588 bytes
    5 minute offered rate 1633000 bps, drop rate 56000 bps
    Match: any

    queue limit 64 packets
    (queue depth/total drops/no-buffer drops) 0/12296142/0
    (pkts output/bytes output) 194061437/63616162446
    · Share on FacebookShare on Twitter
  • networker050184networker050184 Mod Posts: 11,962 Mod
    Have you tried what I suggested above? This is the recommended way to accomplish what you are trying to do.
    An expert is a man who has made all the mistakes which can be made.
    · Share on FacebookShare on Twitter
  • ZartanasaurusZartanasaurus Member Posts: 2,008 ■■■■■■■■■□
    What results are you not getting? Your policy map is getting hits on both classes although not much traffic. How are you verifying the bandwidth reservations?
    Currently reading:
    IPSec VPN Design 44%
    Mastering VMWare vSphere 5​ 42.8%
    · Share on FacebookShare on Twitter
  • janez_drkjanez_drk Member Posts: 27 ■□□□□□□□□□
    @networker050184
    I think that I'm already doing what you have recommended.

    @Zartanasaurus
    I don't have/know ways to verify bandwidth reservations. Link is very congested and my applications(for which I have reservd bandwidth)work the same as without reservationes. Can you suggest some way to verify that this is working?


    Thank you for replies!
    · Share on FacebookShare on Twitter
  • networker050184networker050184 Mod Posts: 11,962 Mod
    No, you are placing the policy-map on the tunnel interface. What you need to do is place it on the outgoing physical interface and then enable qos pre-classify on the tunnel. The issue you are going to run into is other traffic traversing the physical interface interfering with your QoS policy.
    An expert is a man who has made all the mistakes which can be made.
    · Share on FacebookShare on Twitter
Sign In or Register to comment.