cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1118
Views
5
Helpful
5
Replies

vtp transparent question

gcdudley
Level 1
Level 1

Hi -

We have 3 switches - A, B and C.  A is connected to B and B to C via lacp etherchannel dot1q trunks.  There is no direct link from A to C.

A is a VTP server.  Additionally, it is our root bridge and has SVIs that act as default router interfaces for  ~62 vlans.

B is in VTP transparent and has 3 vlans (1, 80 and 999).

C is a VTP client and has received the complete vlan database of from the server.

Access ports on switch C cannot contact their default gateway address (and the rest of the network) unless the access vlan (say 232) is defined on the transparent switch as well.  Is this correct behavior for a VTP transparent switch?  I was under the impression that switches downstream from a vtp transparent switch would not have this problem.

Thanks,

Chris

1 Accepted Solution

Accepted Solutions

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Chris,

we have to discriminate between vlan database propagation and proper OSI layer 2 connectivity in each client VLAN.

the first is automatic as VTP frames travel untagged and are propagated by switch B that is in VTP transparent mode.

However, switch B does not examine the VTP updates so for proper OSI layer 2 connectivity you need to define locally all client vlans on switch B this is an expected behaviour.

This happens because a modern switch does not accept tagged frames for an undefined VLAN.

This is for L2 security to avoid some type of attacks. ( vlan hopping )

Hope to help

Giuseppe

View solution in original post

5 Replies 5

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Chris,

we have to discriminate between vlan database propagation and proper OSI layer 2 connectivity in each client VLAN.

the first is automatic as VTP frames travel untagged and are propagated by switch B that is in VTP transparent mode.

However, switch B does not examine the VTP updates so for proper OSI layer 2 connectivity you need to define locally all client vlans on switch B this is an expected behaviour.

This happens because a modern switch does not accept tagged frames for an undefined VLAN.

This is for L2 security to avoid some type of attacks. ( vlan hopping )

Hope to help

Giuseppe

Thank you very much, Giuseppe.  As I mentioned, we discovered how to regain access; it just ran against what I THOUGHT I knew about vtp transparent.

I thought that if all the switches are in the same VTP domain (not in null) that the server and client would exchange VTP messages.  A switch that is in transparent mode will still forward VTP updates received from another switch.

Jonathan,

Hi Jonanthan,

I thought that too.  In my example, switch C was seeing the correct output from 'show vlan' but traffic wasn't being passed when I connected a host to an access port.  Giuseppe's note warns not to equate vtp propagation w/ L2 connectivity.  This was where my understanding of vtp transparent was wrong/incomplete.  A detail everything I've read has failed to mention (or I didn't "get" while reading).

In the end, we just made switch B a vtp client.  It was simpler than maintaining a separate vlan configuration on that 1 switch.

Chris

   This is correct  , if you think about  it , the transparent switch  is being used to transport traffic on those vlans on a trunk it will have to have all those vlans created or otherwise how can it tag the packets on the trunks . 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: