cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3863
Views
2
Helpful
10
Replies

Catalyst 6500 Ethernet Subinterfaces & re-using 802.1q tags?

Is this possible with a Catalyst 6500 running Native IOS (Sup720).

interface GigabitEthernet0/0

no switchport

!

interface GigabitEthernet1/1.10

encapsulation dot1q 10

ip address 10.10.10.254 255.255.255.0

!

interface GigabitEthernet1/1.20

encapsulation dot1q 20

ip address 10.10.20.254 255.255.255.0

!

interface GigabitEthernet1/2

no switchport

!

interface GigabitEthernet1/2.10

encapsulation dot1q 10

ip address 10.1.1.254 255.255.255.0

!

interface GigabitEthernet1/2.20

encapsulation dot1q 20

ip address 10.1.2.254 255.255.255.0

!

At the other end of each link is a 3750 with a typical trunk interface:

interface GigabitEthernet1/0/1

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

switchport nonegotiate

switchport trunk allowed vlan 10,20

!

What the customer wants to do is re-use VLAN Tags in the access-layer, but have them separated - i.e. no VLANs spanning wiring closets.

For example Wiring Closet A will have two VLAN's 10 & 20, these are trunked back to the distribution switch. Wiring Closet B will also have VLAN's 10 & 20 and they will be trunked back to the same distribution switch, however they need to be different subnets. We need VLAN Tag consistency but have separate broadcast domains.

I know I could do it with a routed interface between the distribution-layer and the access-layer, however the access switches have only IP Base and the routing protocol in use is OSPF (no option of EIGRP stub).

I haven't got a spare 6500 nearby to take a look.....

Andy

1 Accepted Solution

Accepted Solutions

Edison Ortiz
Hall of Fame
Hall of Fame

You are only allowed to create one Vlan 10 on a switch (vlan database) - that's your broadcast domain.

Within that broadcast domain, you are allowed to have multiple IP subnets and ranges which is basically the example you posted above.

10.10.10.0/24 will share with 10.1.1.0/24 the same Vlan (Vlan 10) as the broadcast domain however they will be on different IP subnets.

HTH,

Edit: Ok, as per your original query - you can't reuse the same tag.

rack3-6509(config-if)#int g6/1.1

rack3-6509(config-subif)#encapsulation dot1Q 3

If the interface doesn't support baby giant frames

maximum mtu of the interface has to be reduced by 4

bytes on both sides of the connection to properly

transmit or receive large packets. Please refer to

documentation on configuring IEEE 802.1Q vLANs.

rack3-6509(config-subif)#int g6/2

rack3-6509(config-if)#no switchport

rack3-6509(config-if)#int g6/2.1

rack3-6509(config-subif)#encapsulation dot1Q 3

Command rejected: VLAN 3 not available

__

Edison.

View solution in original post

10 Replies 10

Typo there... First line of configuration should have been

interface GigabitEthernet1/1

no switchport

Cheers

Andy

Hi

AFAIK think Sub-interfaces are not supported on this chassis.

Thanks

Mahmood

They are, I was looking at this today. I created the subinterfaces and added the 'encapsulation dot1q x' to each of them. What I couldn't test was a 2nd access switch and the re-use of the dot1q tags.

Andy

Edison Ortiz
Hall of Fame
Hall of Fame

You are only allowed to create one Vlan 10 on a switch (vlan database) - that's your broadcast domain.

Within that broadcast domain, you are allowed to have multiple IP subnets and ranges which is basically the example you posted above.

10.10.10.0/24 will share with 10.1.1.0/24 the same Vlan (Vlan 10) as the broadcast domain however they will be on different IP subnets.

HTH,

Edit: Ok, as per your original query - you can't reuse the same tag.

rack3-6509(config-if)#int g6/1.1

rack3-6509(config-subif)#encapsulation dot1Q 3

If the interface doesn't support baby giant frames

maximum mtu of the interface has to be reduced by 4

bytes on both sides of the connection to properly

transmit or receive large packets. Please refer to

documentation on configuring IEEE 802.1Q vLANs.

rack3-6509(config-subif)#int g6/2

rack3-6509(config-if)#no switchport

rack3-6509(config-if)#int g6/2.1

rack3-6509(config-subif)#encapsulation dot1Q 3

Command rejected: VLAN 3 not available

__

Edison.

Cheers Edison, that has saved me a job. Is it the same behaviour on a 'real' router?

Thanks

Andy

Yes,

Rack1R2(config)#int f0/0.1

Rack1R2(config-subif)#en

Rack1R2(config-subif)#encapsulation ?

dot1Q IEEE 802.1Q Virtual LAN

isl Inter Switch Link - Virtual LAN encapsulation

Rack1R2(config-subif)#encapsulation do

Rack1R2(config-subif)#encapsulation dot1Q 4

Rack1R2(config-subif)#int f0/0.2

Rack1R2(config-subif)#encapsulation dot1Q 5

Rack1R2(config-subif)#encapsulation dot1Q 4

%Configuration of multiple subinterfaces of the same main

interface with the same VID (4) is not permitted.

This VID is already configured on FastEthernet0/0.1.

Rack1R2(config-subif)#

michaelchoo
Level 1
Level 1

"I know I could do it with a routed interface between the distribution-layer and the access-layer, however the access switches have only IP Base and the routing protocol in use is OSPF (no option of EIGRP stub). "

Are you sure about this? It doesn't make any sense to include OSPF in IP BASE but not EIGRP Stub Routing.

I did a quick search on Feature Navigator, and found that 3750's IP BASE image comes with EIGRP Stub Routing, and no OSPF. I looked at IOS 12.2.25SEE.

IP Base supports EIGRP Stub (& PIM Stub) but the customer uses OSPF as their IGP so EIGRP Stub isn't an option currently. We could use EIGRP Stub, however it would mean a conversion from OSPF to EIGRP or some nasty redistribution.

Cheers

Andy

OK. I misunderstood your original post.

I can't think of a way to reuse VLAN IDs with a single distribution switch. Well... actually, you can sort of reuse the VLAN ID by using assigning secondary IP addresses to the SVIs, but I don't think that's what you want, is it?

OK, let's take a step back here. Why does your customer want to reuse VLAN ID? I'm guessing that it's because they have this rather draconian VLAN number standard that they want to abide by (I've come across this sort of scenario many times). Sometimes, you have to give your customer the cold hard truth, that what they want to do contradicts their own policy (in other words, their policy is fundamentally flawed! But you don't want to tell them that!). Let's assume that they're willing to put in a 2nd distribution switch to facilitate reusing of VLAN ID. OK... that's fine and dandy. But the end result is more complicated design which translates into higher admin overhead. All because of their inflexible, draconian, standard. I've been faced with this type of scenario in pretty much every customer I've worked with. As long as we communicate all the facts to them clearly, they'll see the error of their ways. Then it's up to you to redefine the new, more appropriate, standards for them, which means more consulting revenue! ;-)

HTH.

We are trying to come up with a plan that fits in with how they administratively assign users to VLAN's. They are looking at 802.1x and/or WEB Authentication. The problem is they want a value to be stored in LDAP that the Radius Server queries and then uses this to assign a VLAN tag. I am trying to cover off what options are available, I think we can probably use VTP transparent and re-use the same VLAN Name on each of the access switches and get the VLAN assigned based on the name - i.e. Access Switch 1 has VLAN 10 named Admin and VLAN 20 named Guest, Access Switch 2 has VLAN 11 named Admin and VLAN 21 named Guest. When a User authenticates (802.1x or WEB Authentication) as an 'Admin' the access port they are connected to gets changed to the Admin VLAN.

There is a fair bit of other work to do around this, however at the moment we are trying to get a plan together and do some testing to see what we can and can't do.

Thanks for the replies.

Andy

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco