cisco2800, GRE and CPU utilisation

[Konstantin Dunaev]

Hi,

I'm looking for a possibility to limit somehow the CPU utilisation on cisco2800 which uses GRE tunnels.

The problem is that somtimes to much traffic goes via GRE tunnels causing 100% CPU utilisation and the router loses all its routing Adjacencies.

I know thet e.g. catalyst6500 posses such a feature, one can say that CPU utilisation should not exceed let say 80% and such prevent some DoS attack on a network infrustructure. 

[Laurent Aubert]

Hi,

What you could try is:

1- Do some scaling tests to find out the max number of pps the box can switch with your configuration for the max CPU usage you are ready to accept. Once you have this number, you can easily convert it into BW knowing the average packet size of the traffic in your network

2- Enforce this BW with some ingress policing.

As this platform is 100% software based, each feature you add will impact the CPU so don't forget to test the policing to make sure the cure is not worst than the decease ;-)

Otherwise, work with your account team so they will help you to position the right HW based on your requirements.

HTH

Laurent.

[Konstantin Dunaev]

Hello Laurent,

thank you very much for the response!

I was considering the possibility to use QoS but had exactly the same concerning's about performance. 

Actually 2821 is not so bad in performance, it has integrated VPN HW acceleration and this module, if I corectly understood the docus, supports GRE tunnels. We're running about 20 GRE tunnels on it without big problem, CPU is OK in normal case, because most of them are 2-5 Mbits connection (physical).

The problem is MTU   as always, I put the command "ip mtu 1524" under the tunnel interface on both side, because firstly I'd like to hide (yes I know it's not good ) GRE path and secondly to illuminate the problem with MTU's on customer side, I know it produces fragmentation, but, as I said normally it doesn't make any problems, problems are starting if many customers generating the traffic or when one customer is a destionation for a DDos attack.

If I get back the "ip mtu 1524"  then CPU doesn't increase, no meter how much traffic are forwarding. But then come the problems with HTTPs and other MTU related things.

Actually I don't know how we can improve this part of our network, I simply hate it and don't want to spend a lot time and/or money on it.

Would it be better if we use a "xconnect" instead GRE?

[Laurent Aubert]

As you said Fragmentation is very bad and must be avoided at all cost !!

Please try the following template and let me know if it solve your issue:

int tunnel x

ip mtu 1400

!

On the interface facing your internal network (not the one on which you are receiving the GRE traffic), apply the following command:

ip tcp adjust-mss 1360

With this config, we prevent UDP traffic from being fragmented and all TCP session will have a MSS set to max 1360 so IP MTU will never be higher than 1400 so no fragmentation of the TCP traffic.

HTH

Laurent.

[Kishore Chennupati]

Hi,

Note: The MTU value of 1400 is recommended because it covers the most           common GRE + IPsec mode combinations. Also, there is no discernable downside to           allowing for an extra 20 or 40 bytes overhead. It is easier to remember and set           one value and this value covers almost all scenarios.

taken from the below link.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

Fragmentation is bad . So setting anything higher than 1500 if not required can only cause grief. I have noticed with several customers that the ip mtu on the tunnels is normally 1400 as per cisco recommendation

HTH

Regards

Kishore

[Konstantin Dunaev]

Hello!

thank you all for the answers, all this issues with MTU were known to me, but I wanted somehow hide that we're usung any type of GRE tunneling, that is why we tried to use "ip mtu 1524"

now I configured the Tunnel with "ip mtu 1476" and LAN interface with "ip tcp adjust-mss 1436" and it seems to be working without much CPU utilisation. But if one send traceroute then he can see that MTU value is not 1500 over the whole path.

But I got you point about fragmentation, thank you again.