06-16-2008 11:18 AM - edited 03-05-2019 11:39 PM
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
Solved! Go to Solution.
06-16-2008 02:05 PM
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.
06-16-2008 01:09 PM
Typo there... First line of configuration should have been
interface GigabitEthernet1/1
no switchport
Cheers
Andy
06-16-2008 01:15 PM
Hi
AFAIK think Sub-interfaces are not supported on this chassis.
Thanks
Mahmood
06-16-2008 01:21 PM
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
06-16-2008 02:05 PM
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.
06-17-2008 06:55 AM
Cheers Edison, that has saved me a job. Is it the same behaviour on a 'real' router?
Thanks
Andy
06-17-2008 07:17 AM
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)#
06-16-2008 07:15 PM
"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.
06-17-2008 06:48 AM
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
06-17-2008 02:50 PM
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.
06-18-2008 06:19 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide