dot1q encapsulation overhead?

Jonathan Lassoff jof at
Thu Sep 6 16:11:15 UTC 2012

On Thu, Sep 6, 2012 at 7:55 AM,  <up at> 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
that affects the MTU calculations of tunnels, for which the source
address is specified by an interface, after a reboot. Worth knowing


More information about the NANOG mailing list