Proper HQoS Configuration for ETH + GRE Circuit

[simone.menoncin]

Hello everyone,

this is my first post in the community and I would like to thank you all for the great support and guidelines this Community provides.

Now I jump into my query.

I have an hub location connected to 2 spoke sites through a L2 cloud with an Ethernet 2M CCT from carrier (this cloud does not support CoS).

The 2 Spoke Sites have have 1M SDSL ccts ( from same provider).

I have business traffic to be prioritized over the non corporate one.

Main traffic flow is outgoing from the Hub and I am using GRE Tunnels from hub to Spokes (one per Spoke site) with HQoS applied.

My concern here is value to be configured on shaping (per each Tunnel) to proper considering the GRE + ETH encapsulation overhead , avoiding to  exceede the 2M of bandwitdh contractualized with the carrier (and conseguently drops from their PE).

Hope I provided all the details required for a feedback of yours.

If not I am more than happy to provide.

Thanks a lot in advance

[jamie.grive]

Simone,

I think to know what you need to shape at you need to consider the applications in use and their average requirement.

Let's take your voice as an example assuming it is G729

60 bytes per packet (G.729 voice (20 bytes Payload + 20 bytes IP + 8 bytes UDP + 12 bytes RTP))

24 bytes per packet (IP GRE overhead)

14 bytes per packet (Ethernet overhead)

= 98 bytes per packet

Multiply by 8 for bits = 98*8 = 784 bits per packet

Assume 50 packets per second for G.729

784 * 50 = 39.2Kbps

So 24Kbps for the G.729 packet becomes 39.2Kbps after overheads

But remember voice is always the worst case when it comes to overheads as it is such small packets.

So what sort of spread do you expect the traffic across the WAN 2Mbps link?

[simone.menoncin]

Hi Jamie and thanks for reply

Traffic is composed by SAP GUI, MS Exchange, CIFS, FTP and Internet Browsing.

Do you suggest a "Try and Tune" approach to set the shaping on the Tunnel and see it is not exceeding the 1M on the physical interface?

Thanks a lot

Simone

[jamie.grive · Accepted solution]

Simone,

I think that would be a good start. With that type of traffic I would start with a shaper at 90% of the provider's CIR.

You should also check with your SP that their values don't already consider the L2 overhead (e.g. they may be policing to around 110%)

[Joseph W. Doherty · Accepted solution]

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

My belief is most Cisco shapers don't account for L2 overhead.  So, you need to allow for that if the shaper doesn't.  Unfortunately, L2 overhead, as a percentage, varies per packet size.  You might shape for worst percentage or average percentage.  What to allow for depends on just how critical correct QoS operation is required.  For example, if you're dealing with VoIP packets, you'll probably want to allow more toward the worse case percentage.

If you're DSL is using PPPoE, don't also forget to allow for the 8 bytes used by it.

Whether you need to also account for GRE overhead would, I believe, depend on whether your shaper is configured on the tunnel interface or on the physical interface.  Like L2 overhead, GRE, as a percentage, would vary per packet size.  With GRE you also have the chance of fragmentation, although if your device supports (and it's enabled) ip tcp adjust-mss should preclude it (at least for TCP packets).

[simone.menoncin]

Thank you guys,

I will have that tested and keep informed about results.

Have a great day