Def. route to GRE tunnel - strange behaviour

[bartholomiew]

Hello

in our WAN we have the following config:

- star topology to HQ with IPSec VPNs over Internet from remote sites

- in most cases HW is C1812/2811 and C2951 in HQ

- we use GRE tunnels over IPSec and EIGRP as routing protocol

- on tunnel interface at branch side we use address summarization

- default route is available via HQ and is advertised through EIGRP

- there are no additional static routes on branch devices beside few defined for emergency SSH access via Internet

therefore

- all traffic (either to corporate network or to Internet) should be encrypted and forwarded via GRE tunnel to the HQ.

BUT

as shown below, there's a huge mismatch in amount of traffic when compare the tunnel and the physical interface. It leads me to conclusion that not all traffic is encrypted. Am I right? Or I'm missing sth here?

Also weird is that the traffic shape on Null0 interface overlays with the Tunnel interface traffic.

Many thanks for any ideas here.

Cheers

Bartek

WAN interface - F0

Tunnel interface

Null0 interface

[Peter Paluch]

Hi Bartek,

Can you perhaps post the configuration of the device from which you created these log files please? Without seeing your configuration, it is difficult to say anything.

Best regards,

Peter

[bartholomiew]

Peter,

attached is the config file. I had to clear the confidential parts.

Regards

B

[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

I haven't looked at your just posted config, but I assume the physical interface is only used for tunnel traffic?  I.e. no raw Internet traffic.

One thing that immediately pops to mind, GRE/IPSec can add a lot of overhead to small packets.  I.e. physical interface might be counting GRE/IPSec bytes and tunnels likely not.

[bartholomiew]

that's correct - F0 is only for tunnel traffic.

I considered also the IPSec overhead but I didn't think it may be such a difference. basing on these cacti plots it's about  10 times more. Is there any easy way to verify how much traffic is the encryption overhead?

How about this traffic to Null0 - is it ok?

[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

I considered also the IPSec overhead but I didn't think it may be such a difference. basing on these cacti plots it's about  10 times more.

I recall GRE/IPSec add 60 to 80 bytes; assuming you're not also encrypting fragments.  Even then, 10x should be much, much too much.

[Peter Paluch · Accepted solution]

Hello Bartek,

One thing that immediately catches my eye is that the Tunnel83 has no bandwidth command configured. The default bandwidth on Tunnel interfaces is 9Kbps (I wonder how Cisco arrived at this default constant). This reference value may be used by Cacti to calculate the utilization percentage, and has therefore to be set to a realistic value. It is possible that Cacti gets confused if the amount of data flowing through the tunnel vastly exceeds the current apparent top of 9Kbps. I suggest setting the bandwidth on the Tunnel interface to a realistic value. Assuming that your connection is 100Mbps, use the bandwidth 100000 command on your Tunnel interface (100 Mbps - values are in Kbps).

From your configuration, I am unable to comment on the following things so perhaps you could fill me in here:

• How is the route towards the tunnel destination address defined? Is it handled by the default route?
• How is the route towards the set peer address defined? Is it handled by the default route?
• Does the ACL referenced by the match address crypto map command match specifically the GRE protocol between the tunnel source and tunnel destination commands?
• Is your tunnel interface stable, i.e. no flapping, no recursive routing, etc.?

Thank you!

Best regards,

Peter

[bartholomiew]

@Joseph

how can I verify if fragments are not encrypted?

@Peter

I set up a new BW - let's give it a try.

Regarding config:

How is the route towards the tunnel destination address defined? Is it handled by the default route?

No, there's also a static route to tunnel destination.

How is the route towards the set peer address defined? Is it handled by the default route?

"set peer" and "tunnel destination" is the same public IP address on the HQ side. The same static route handles this.

Does the ACL referenced by the match address crypto map command match specifically the GRE protocol between the tunnel source and tunnel destination commands?

It matches all IP traffic between these two public IP peers. It's not restricted only to GRE protocol. See line 130 and 131 of attached config.

Is your tunnel interface stable, i.e. no flapping, no recursive routing, etc.?

Yes, absolutely no problems here.

thx

B

[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

@Joseph
how can I verify if fragments are not encrypted?

First determine what's your tunnel's MTU and then determine in any packets transiting your tunnel are larger.

[bartholomiew]

Hello Peter

it seems that it was a problem with cacti. After I updated this BW on tunnel and recreated the graph (updating only didn't help) in cacti averythings looks like it should. The plot from the tunnel overlays with the physical interface statisticts with the ~10% difference which I assume is the encryption overhead.

Thanks for the good hint!

cheers

Bartek