How to avoid QOS bandwidth limits on SVTIs

[Paul Morgan]

Hi all,

I have a hub and spoke network with spokes connected using SVTIs back to the hub.

All the tunnels are assigned the same bandwidth command on the hub router to facilitate equal routing metrics.

But this means QOS policies applied to the SVTIs (tunnels) are all using the same bandwidth calculation to determine congestion.

Some spokes have far more REAL bandwidth than others so I want to apply QOS accordingly.

Is there any way of getting QOS to use a different bandwidth than the one specified in the bandwidth command on the tunnel?

thanks,

Paul

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Ok, so increasing queue depth removed drops, but didn't help throughput much.

What kind of throughput do you get without any QoS?

[Paul Morgan]

it is basically identical. The physical interface is quite happily chugging along at about 20Mb (which is all tunnels together). Perhaps I should do a total transmit test using the physical interface?

  30 second input rate 41000 bits/sec, 68 packets/sec
  30 second output rate 1167000 bits/sec, 117 packets/sec
     15938043 packets input, 3821538679 bytes, 0 no buffer
     Received 0 broadcasts (1193766 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     17210931 packets output, 520002042 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

You could, but does the physical interface have some aggregate CIR less than the physical egress port's bandwidth?  If so, you might be bumping into that.  (Also if so, the "correct" QoS is to shape the aggregate too, although not all Cisco implementations support that.)

[Paul Morgan]

I cant do QOS on phys and tunnel.

Im going to test some other transfers outside of QOS and test upper limits. But I need to make some changes first so it may take a little bit.

Many thanks for all your help thus far. I'll be back shortly

[Paul Morgan]

Hi Joseph,

Thought Id just add an update to this after further tests.

The throughput on the SVTIs varies greatly and doesn't follow any particular trend that I can see is related to actual bandwidth. It looks like, depending on the complexity of the data transfer (ie many small files or one large one), the throughput percentage is between 50 and 75% of the available downstream bandwidth on the tunnel.

So adding LLQ QOS is actually very challenging because the outbound (hub) end is much bigger than most of the receivers, so almost never congested, even during big transfers.

I think Im going to leave the QOS off for now as the VOIP appears unaffected.

Thanks again for your help.

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Yes, that's not uncommon, i.e. that the hub side has a larger bandwidth connection than the remote side.  When that's true, often the goal is to shape and manage possible congestion from the "cloud" to the remote site, i.e. the lessor bandwidth connection, indirectly at the hub router by shaping per remote.

It's also not unexpected that throughput varies much based on packet size.  When tunneling, especially when using IPSec on small packets, about half your encapsulated packet is tunneling overhead.