cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
532
Views
10
Helpful
12
Replies

Does this make sense p2?

visitor68
Level 4
Level 4

Hi:

This is sort of a continuation from a post from yesterday.

I have a switch that is configured with multiple vlans, but I want to focus on the data and voice vlans for now.

The data vlan is 341 and the voice vlan is 546.

I have a lot of L2 switchports configured to support MAVP interfaces for PCs and Avaya phones.

This switch has an L2 uplink (trunk) that carries this vlan traffic and others to a 6513 switch.

All pretty straightforward until this point...

What I dont understand is why this 4510 has routed, SVIs configured on it for these vlans -- and for the others, too, actually -- when the uplink to the 6513 is a L2 trunk?

6513(routed)<----L2---->4510(routed)

I dont get it.

I will attach the config. It doesnt make sense to me.

The only thing I can think of is that the designer decided to have a L2 uplink as well as a routed connection to the 6513, and that the routed connection was created the old way (before the advent of IOS-based L3 switches with routed interface capability) using SVIs and placing an access or trunk port in that vlan(s) to create a simulated routed connection.

But why do it that way (perhaps he is th eonly one who could answer that) and why both L2 and L3 uplinks? This is an access layer switch going to a routed collapsed core for this site.

Thanks

1 Accepted Solution

Accepted Solutions

The L2 trunks allow you to share the L2 Vlans. If you don't do that, then each switch will have separate L2 domain.

If you go with L3 isolation, then you need to configure a different IP subnet on the 6500 and a separate IP subnet on the 4500.

Say, you have devices roaming and connecting in either the 6500 or 4500 but they need to be on X same subnet, then the L3 isolation design isn't the best.

Again, the current design isn't a rare design and actually is the most common design out there.

There are plenty of threads on this forum on the pros/cons on the L2 vs L3 switch design. A quick search should turn up some useful results.

No, you aren't being a pain :)

HTH,

__

Edison.

View solution in original post

12 Replies 12

Edison Ortiz
Hall of Fame
Hall of Fame

Hi again :)

Based on the 4510 config and the config you posted yesterday from the 6500, the 4500 serves as the Layer3 switch for all Layer2 Vlans while the 6500 serves as the access layer switch.

You need a device to route between Vlans and that's the function the 4500 is doing on this case. The 6500 is the access layer holding Vlans for user and voice subnets and it's trunking both of these Vlans toward the 4500. The 4500, in turn, routes the communication for these Vlans (inter-vlan routing).

I see nothing wrong with this design, unless I'm missing something.

You mentioned L3 uplinks, I see none. L3 uplinks are considered having the ip address under the switchport. SVIs are not considered L3 uplinks.

__

Edison.

Hi, Edison.

I should have posted the config for the 6500 switch.

Without it, I can see why you wrote what you wrote.

The 6500 does have a L2 trunk to the 4500 but it is not the access layer switch. It also has SVI interfaces for the vlans and it sits on the edge of the network, facing the WAN.

I dont have the complete 6500 config, only the most pertinent part.

interface GigabitEthernet7/1

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 92-94,102,236,237,341,546,547

switchport mode trunk

ip arp inspection trust

tx-queue 3

priority high

ip dhcp snooping trust

!

interface Vlan546

description Avaya phone vlan 546

ip address 10.76.185.254 255.255.254.0

ip helper-address 10.76.171.1

no ip redirects

no ip unreachables

no ip proxy-arp

service-policy input user-marking

service-policy output DBL

!

interface Vlan547

description Avaya phone vlan 547

ip address 10.76.187.254 255.255.254.0

ip helper-address 10.76.171.1

no ip redirects

no ip unreachables

no ip proxy-arp

service-policy input user-marking

service-policy output DBL

Without having access to the switches to run my show commands, all I can do is surmise whats going on.

All I can think of is that the 6513 and the 4510 have users directly connected to them on those vlans. So they are both acting as L3 access switches. Furthermore, the 6513 is only running CatOS (another assumption) and that the only way to configure a simulated routed connection between the 4510 and the 6513 is to use SVIs and configure a trunk between the switches.

Based on that portion you posted, it's not running hybrid. Hybrid has the switchport configuration in the CatOS portion while you posted the switchport information from the IOS portion.

The 6513 may be serving as a L3 switch as well since it has 2 SVIs for those subnets.

It all depends on what default gateway is set on the devices. If the devices' default gateway is the IP address from the 4500, then this device is the L3 gateway for that subnet. You can also have both devices sharing the same L3 subnet for some kind of redundancy. Based on your setup, you can go as far as implementing HSRP for this task.

In addition, as I stated before, you have L2 links between switches - there isn't any L3 links.

HTH,

__

Edison.

"Based on that portion you posted, it's not running hybrid. Hybrid has the switchport configuration in the CatOS portion while you posted the switchport information from the IOS portion."

Duh, of course. What was I thinking?

"The 6513 may be serving as a L3 switch as well since it has 2 SVIs for those subnets."

Exactly, thats what I am saying.

"It all depends on what default gateway is set on the devices. If the devices' default gateway is the IP address from the 4500, then this device is the L3 gateway for that subnet."

I imagine that the DG for the devices is the local SVI interface. Otherwise, what would be the purpose of having L3 interfaces on both switches? IOW, if the users directly connected to the 4510 use the 6513 as the DG, then why have an SVI on the 4510? The same is true for the 6513.

As far as HSRP, it doesnt fit into the picture as of now.

"In addition, as I stated before, you have L2 links between switches - there isn't any L3 links"

I agree - no specifically defined L3 connections. I mentioned simulated L3 connections using SVIs.

See example below. I have 2 switches connected via an L2 access port and they are both in the same vlan. An SVI for each vlan is configured on both switches and the vlan is routing eigrp. An eigrp neighborship is formed, creating a routed connection.

Switch_2#sh run int fa0/1

Building configuration...

Current configuration : 85 bytes

!

interface FastEthernet0/1

switchport access vlan 100

switchport mode access

end

Switch_2#

Switch_2#sh run int vlan 100

Building configuration...

Current configuration : 59 bytes

!

interface Vlan100

ip address 7.7.7.2 255.255.255.0

end

Switch_2#

Switch_2#sh run | be router eigrp

router eigrp 10

network 7.7.7.2 0.0.0.0

no auto-summary

============================================================

Switch_1#sh run int fa0/1

Building configuration...

Current configuration : 85 bytes

!

interface FastEthernet0/1

switchport access vlan 100

switchport mode access

end

Switch_1#

Switch_1#

Switch_1#sh run int vlan 100

Building configuration...

Current configuration : 59 bytes

!

interface Vlan100

ip address 7.7.7.1 255.255.255.0

end

Switch_1#

Switch_1#

Switch_1#sh run | be router eigrp

router eigrp 10

network 7.7.7.1 0.0.0.0

no auto-summary

!

Switch_1#

Switch_1#

Switch_1#sh ip eigrp nei

IP-EIGRP neighbors for process 10

H Address Interface Hold Uptime SRTT RTO Q Seq Type

(sec) (ms) Cnt Num

0 7.7.7.2 Vl100 11 00:11:25 1 3000 0 1

Switch_1#

Switch_1#

Switch_1#

Therefore, the L2 trunk between the 6513 and the 4510 also provides a pseudo routed connection. I used access ports in my example, but I could have just as easily made it a trunk port.

Based on the original post and additional information, the design serves as L3 redundancy. You may have some users (local to the 6500) using the 6500 as the default gateway and other users (local to the 4500) using this device as their default gateway.

I mentioned HSRP since this can be a good solution for L3 redundancy without changing the user default gateway in case one of the switches go down but I don't want to digress from the main question.

As for the example you posted, I'm in complete agreement with the function of the SVI but we need to go by general networking terms so we can understand each other better. We don't call an inter-switch link connection 'routed' when you have a trunk configured. That inter-switch link is considered a L2 trunk link and a L3 Vlan is being shared. There is no pseudo routed connection concept in networking unless you want to start a new concept and patent it :)

__

Edison.

" There is no pseudo routed connection concept in networking unless you want to start a new concept and patent it :)"

LOL :-D

What is the proper way to describe this set up?

By the way, I agree 100% with the HSRP suggestion. When I saw the SVIs on both devices, that was my first thought.

You have a trunk inter-switch links with SVIs sharing some of the Vlans.

The term 'trunk' will imply that you have a L2 link, not a L3 link. The SVIs are just a L3 representation of those L2 Vlans. They don't form a 'routed' connection as you are still running STP on those links.

__

Edison.

So, Edison, Im not sure we answered the original question:

If users are pointing to the local SVI as the DG, which is most intuitively the case, why the L2 trunk? Why isnt it a real routed connection with L3 isolation.

I mean, they obviously have an L2 trunk to span the vlans, but why if they have SVIs on both switches and the users point locally?

Am I being a pain? ;-)

The L2 trunks allow you to share the L2 Vlans. If you don't do that, then each switch will have separate L2 domain.

If you go with L3 isolation, then you need to configure a different IP subnet on the 6500 and a separate IP subnet on the 4500.

Say, you have devices roaming and connecting in either the 6500 or 4500 but they need to be on X same subnet, then the L3 isolation design isn't the best.

Again, the current design isn't a rare design and actually is the most common design out there.

There are plenty of threads on this forum on the pros/cons on the L2 vs L3 switch design. A quick search should turn up some useful results.

No, you aren't being a pain :)

HTH,

__

Edison.

EdisoN:

"Say, you have devices roaming and connecting in either the 6500 or 4500 but they need to be on X same subnet, then the L3 isolation design isn't the best."

That to me is the only reason I can think of to want to span the vlan across both switches when HSRP is not even configured. I understand that the L2 trunk allows you to extend the vlan across both switches, I just couldnt figure out why they would feel the need to do it.

Thanks for all your guidance, Edison.

Until my next quandary...:-)

Edison:

Just a quick update for you.

I just spoke to the engineer who configured the devices and now I got some questions answered:

1.) The VACL that is applied to the VOICE vlan includes access-lists that target what seem like PC traffic -- like hhtp, https, etc -- because the IP Phones use http to download configuration information from a centralized server. It uses TFTP, too, which is the standard.

Also, the seemingly arbitrary port ranges -- 1024 to 5000 -- are a result of sniffing Avaya phone traffic and just observing what source ports it likes to grab when it boots up or has to communicate with the ttp server.

2.) The famous "pseudo routed" connection issue from yesterday. lol

All IP phones default to the 6513 only, the reason the 4510 has an SVI on it is just...are you ready for this?...for "troubleshooting purposes," according to the demands of the client. What that means, he doesnt really know, but he didnt want to argue with them. So, he also recognizes that it serves no earthly purpose in forwarding traffic. There is also nothing planned for an HSRP application.

Well, thats it...

After all the help you and Giuseppe gave me, I figured I at least owed you an update to clarify things.

Ciao

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