GRE over IPSec QoS

[de1denta]

Hi All,

I need some advise on the following issue

We have a remote site that has a 100Mbps internet bearer with a 10Mbps CIR. This site has a GRE over IPSec connection back to our HQ which has a 100Mbps internet connection. We are running EIGRP over the GRE tunnel for internal prefixes only, Internet traffic routes over remote sites local internet connection. Traffic shapping has been configured on the remote sites tunnel interface and on the hub sites physical interface at 10mbps.

The problem that we are facing: When a remote site user downloads data from the internet they conngest the physical interface on the remote site router which causes issues with voice over the GRE tunnel and in some instances causes the EIGRP adjacency to be torn down because of dropped hellos. I have looked at configuring inbound policing on the remote site physical interface but this doesnt really help because the bandwidth is already utilised when traffic hits the interface.

What is the best method to control this? As we cant control the internet bandwidth at the remote site I was thinking of pushing all traffic over the GRE tunnel and breaking internet traffic out via the hub, I can then configure shaping in the opposite direction to control bandwidth utilisation.

Any advise would be appreciated.

[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

As we cant control the internet bandwidth at the remote site I was thinking of pushing all traffic over the GRE tunnel and breaking internet traffic out via the hub, I can then configure shaping in the opposite direction to control bandwidth utilisation.

Yes, that generally works well.  Don't forget to continue to shape from the hub to the spoke.  Also, such bandwidth caps are generally L2 values and I believe Cisco shapers don't account for all L2, so you need to shape slower than your nominal bandwidth.

Another alternative, is to obtain an inexpensive DSL or cable modem link for local Internet access and reserve your other link for just VPN traffic.

PS:

The problem that we are facing: When a remote site user downloads data from the internet they conngest the physical interface on the remote site router which causes issues with voice over the GRE tunnel and in some instances causes the EIGRP adjacency to be torn down because of dropped hellos. I have looked at configuring inbound policing on the remote site physical interface but this doesnt really help because the bandwidth is already utilised when traffic hits the interface.

Yea, inbound downstream policing does have the problem you note.  However if inbound traffic is rate adaptive (e.g. TCP) severe policing can help.  Or you can shape outbound TCP ACKs.  Neither, though, works as well as egress shaping.

[de1denta]

Thanks for this Joseph.

Regarding the L2 shaper overhead, whats normally the best way to calculate this?

[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

For non-802.1Q packets, Ethernet overhead 38 bytes per packet.  For 802.1Q packets, add another 4 bytes.

As the overhead is fixed, but packet sizes vary, you cannot be precise.  You might allow for worst case or average case.

For average case, I've found shaping 10 to 15% "slower" seems to usually work well.

PS:

What Cisco shapers/policers actually measure isn't well documented, by when I found this feature note, http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/12sl2os.html, I suspect most Cisco shapers/policers don't account for L2.

[de1denta]

Thanks Joseph.

Also with my config for the remote and hub sites I'm configuring the shaper and child policy maps on the physical interfaces. Is there a general rule when to apply these to the tunnel interfaces instead?

[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

At the hub side, often you'll want a shaper per tunnel, as you have many tunnels and the bottleneck you're shaping for is often the branch's bandwidth.  If the device support it, you might also have a QoS policy on the physical interface in cases where the aggregate of tunnel bandwidths can exceed the physical interface bandwidth.

At the spoke side, often can shape on the tunnel or the physical interface.

Whenever shaping on the physical interface, remember by default, QoS will "see" all the tunnel traffic as one flow.