Re: l2protocol-tunnel 0 decap

Cheers mate - VLAN 421 is defined on two switches only and they are
connected via the t8/1 interfaces to each other via a dot1q trunk
which is only carrying that vlan between them and they are not trunked
elsewhere or blocked.

It's really getting me down ;-)

They are not sharing VTP and the vlan is defined on both...don't think
that matters though, just thought I'd mention it. Since I sent the
email I've tried changing the native vlan and tagging that (vlan dot1q
tag native) but it has made no difference.

Thanks for the feedback.

On 8 Oct 2009, at 04:44, Bryan Bartik wrote:

> Hey Richard,
>
> I think this could happen if you have vlan 421 defined on other
> switches and trunks, and STP was blocking this vlan between the
> switches in question. Have you checked this?
>
> On Wed, Oct 7, 2009 at 9:21 PM, Richard Lowton
> <lowton_at_packetfreak.net> wrote:
> Gurus,
>
> Anyone ever had a problem with Q-inQ and l2tunnel-protocol where
> both ends show encaps but zero decaps? The tunnel ports are
> configured thus:
>
> interface TenGigabitEthernet8/2
> description XXX
> switchport
> switchport access vlan 421
> switchport mode dot1q-tunnel
> mtu 9216
> l2protocol-tunnel cdp
> l2protocol-tunnel stp
> no cdp enable
> end
>
> The Q-inQ ports are configured thus:
>
> interface TenGigabitEthernet8/1
> description XXX
> switchport
> switchport trunk encapsulation dot1q
> switchport trunk allowed vlan 421
> switchport mode trunk
> mtu 9216
> end
>
> The output from show l2p is...thus:
>
> Port Protocol Thresholds Counters
> Shutdown Drop Encap Decap
> Drop
> ------------------- -------- --------- --------- --------- ---------
> ---------
> Te8/2 cdp ---- ---- 200188
> 0 0
> --- ---- ---- ----
> ---- ----
> stp ---- ---- 5385679
> 0 0
> --- ---- ---- ----
> ---- ----
>
> Any ideas?
>
> System mtu is set for jumbo frames and the Q-in-Q is up and devices
> at either end can see each other nicely - it's just the l2tunnel
> which is broken. I appreciate it's vague and I may be running down a
> rat hole here but could this be to do with the multicast mash which
> goes on?
>
> Any help gratefully received.
>
> Rich
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
>
>
> --
> Bryan Bartik
> CCIE #23707 (R&S), CCNP
> Sr. Support Engineer - IPexpert, Inc.
> URL: http://www.IPexpert.com

Blogs and organic groups at http://www.ccie.net
Received on Thu Oct 08 2009 - 04:50:55 ART