QoS qualification for passing various traffic/services in one Point-to-Point GRE Tunnel over IPSEC

[nOosadz88]

Hi Guys,

I need your advices regarding our topology network plan, hope someone could give me an effective advice/solution to work around this for passing a smooth flow over one tunnel interface into our remote branch. Ok here it is, we're planning to pass the traffic/services into point-to-point GRE Tunnel over IPSEC to our remote branch, this tunnel passes a various of services to be routed into our remote destination. I was wondering if this would work well passing the traffic smoothly and wouldn't affect network performance. Details below stated to be more comprehensive.

Total Bandwidth = 12mb Dedicated Internet

Services/Traffic that will must pass:

- 1680K for POS

- 1344K for Voice Traffic

- 1200K for Data Traffic

- 2200K for DB Replication

- 5000K for Internet Access

Since there are various traffic/services will be pass into tunnel, apparently we would need to implement QoS for this, I was thinking combination both shaping and policing, but regardless with both of them, i don't think they would work. Because first of all if I implement shaping, it would cause delay on transmitting traffic to remote since it will commit queuing which we prioritize that the voice traffic must be continuously flowing, and regarding with policing, we don't prioritize to drop various traffic especially with Voice and DB replication since we need to have smooth communication thru VOIP which wouldn't drop the calls as well as the DB Replication must sync completely to remote branch. Actually implementing this VPN and Routing on this topology which make me simple to configure but still I'm thinking deeply about which would be qualified type of QoS passing thru GRE tunnel to implement on this type of objective. I was hoping someone could give me an effective advice regarding this. Thanks in advance.

[Marcin Latosiewicz]

Jason,

If I understand correctly all your problems should be addressed by HQF.

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/qos_frhqf_support.html

There is an example for GRE tunnel (Shaping on a GRE Tunnel)

which also should apply to GRE over IPsec tunnels.

Just bare in mind that the 12mb throughput most likely does not take into account GRE+IPsec overhead.

The concepts are described here:

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/sol_ov_c22-708224.html

This one is pretty new and pretty well done, bells and whistles :-)

M.

[nOosadz88]

Hi Marcin,

Thanks for your response.

Correction above with my total bandwidth, it should 12Mbps total bandwidth dedicated internet.

Anyway, the links you provided above enlightens me more and give me some idea with my target objective.

I would like to ask an advice from you regarding with Shaping on a GRE Tunnel.

As I read it on the said link,

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/qos_frhqf_support.html#wp1089229

it does give me an idea and it includes to my plans on implementing QoS by using HQF. Ahm does the priority command will be consider prioritize first compared to bandwidth command to pass on egress traffic across the tunnel interface? Actually, my plan is to prioritize first the Voice traffic inside the queue to be pass out on tunnel interface and other services/traffic will be remain equally inside the queue until they could pass out the tunnel interface. Hope you get it Marcin, as this is only my concern, if you could give me an effective idea/advice regarding this then probably I could now start it to implement on my network.

Thanks in advance.

Cheers,

Jason

[Marcin Latosiewicz]

Jason,

"priority" will effectively make sure that voice packet don't get delayed in the buffers. You make sure that it's not going to leave other protocols to starve by assigning a certain rate/amount of badnwidth.

"bandwidth" makes sure there is certin amount of rate/bandwidth available for given protocol.

"priority" makes sure that rate/bandwidth never makes it over a certain threshold and drops the rest.

"shape" very much like priotity, but it will queue up should the rate be exceeded.

Now this explanation might make a few QoS purists cringe (and I do suggest reading up on QoS either in the Routing and switching CCIE guide book or in routing TCP/IP volume 1) , but it's just meant to give you an overview of the differences.

That explain why we shape overall (to your 12mbps) and withing that 12mbps we carve smaller chunks for different protocols/uses.

Hope that sheds a bit more light on it.

M.