Re: dot1q encapsulation overhead?

[Jonathan Lassoff <jof () thejof com>]

On Thu, Sep 6, 2012 at 7:55 AM,  <up () 3 am> wrote:
> A while back we had a customer colocated vpn router (2911) come in and we put it
> on our main vlan for initial set up and testing.  Once that was done, I created a
> separate VLAN for them and a dot1q subinterface on an older, somewhat overloaded
> 2811.  I set up the IPSec Tunnel, a /30 for each end to have an IP and all the
> static routes needed to make this work and it did.
>
> However, a few days later they were complaining of slow speeds...I don't recall,
> but maybe something like 5mbs when they needed 20 or so.  We had no policing on
> that port.  After a lot of testing, we tried putting them back on the main, native
> vlan and it worked fine...they got the throughput they needed.
>
> So my question is: could the dot1q encapsulation be causing throughput issues on a
> 2811 that's already doing a lot?  I regret that I don't recall what "sh proc cpu"
> output was, or if I even ran it at all.  It was kind of hectic just to get it
> fixed at the time.
>
> Well, a few months later (last week), the chicken came home to roost when their
> IPSec tunnel started proxy ARP puking stuff to our side that temporarily took out
> parts of our internal LAN.  I have requested a 2911 replacement for the 2811
> because I have seen the 2811 cpu load max out a few times when passing lots of
> traffic.  I am hoping it will allow us to go back to this VLAN setup again, but
> I've never heard whether dot1q adds any overhead.

It's small, but plain 802.1Q adds in a 4-byte (32-bit) header after
the normal Ethernet header and before the "actual" Ethernet payload.

That tag has to go somewhere. :p

Also, I'm not privy to the details of your "IPSec Tunnel", but that
can introduce additional overhead as well.

I'm not sure about your specific 2811/2911 and IOS combination (to
know if this feature is there or not), but you might also consider
setting "ip tcp adjust-mss" and "ip mtu" values on your tunnel
interfaces to signal the true maximum-transportable-size of the
various traffic types over the tunnel.

I've also been bit by this bug before
(http://networknerd.wordpress.com/2010/06/11/cisco-ipsec-mtu-bug/)
that affects the MTU calculations of tunnels, for which the source
address is specified by an interface, after a reboot. Worth knowing
about.

Cheers,
jof