Can you check this infrastructure configuration will work from Floor to Core?

[chris.george]

I would like to optimise our existing core to floor infrastructure:

We have 4 floors altogether with rougly 4x 48 port switches per floor.

Each floor has its only dedicated fibre link direct to the Core switch in our Data Centre (some 10Gb and some 1Gb uplinks - we are slowly upgrading to 10Gb uplinks throughout).

The DC core switch is configured as a layer 3 switch and has all the vlan interfaces set with an IP address which is in fact the default gateway address assigned to PCs and Servers. For example - PCs are on VLAN 22, interface VLAN 22 is set as IP address 172.22.1.252/24 which is the PC configured gateway. And the Server VLAN 20 interface on the Core switch has IP address 172.16.1.252/24 representing the default GW of the Servers. In effect the Core switch is the Layer 3 switch Gatway.

The VTP mode on the Core switch is set to SERVER.

Each floor switch is a Layer 2 switch - for those capable of running Layer 3 they have been dumbed down to only be a Layer 2 switch (no IP routing).

The uplink trunks allow VLAN 20 and 22 from Core to Floors.

The floor switches VTP mode is TRANSPARENT.

Is this an optimised configuration for our estate? Are there any glaring mistakes here?

[Joseph W. Doherty]

Ideally, in a logical topology as you describe, you don't span VLANs across switches that transit the L3 switch core.

[chris.george]

So ideally I should not be spanning vlans across to a central L3 switch (in my case the core) - why is this? And how else would I configure a central point of routing if I am strictly not really allowed to do this?

Incidently, I went round to all floor switches and cleaned up the excess vlans by changing them all from client to transparent then deleting vlans that were not needed so that I could control which vlans were stored on which switch.

I don't fully understand VTP and how it helps apart from just automatically uploading vlan information to the clients from the server which I can control manually myself? Do VTP domains have any further use?

[Joseph W. Doherty]

"So ideally I should not be spanning vlans across to a central L3 switch (in my case the core) - why is this?"

Yup and why is a student exercise.

"And how else would I configure a central point of routing if I am strictly not really allowed to do this?"

An you're doing. I.e. your central L3 switch would be configured almost like it is now, you just wouldn't have the same VLAN on more than one trunk.

"I don't fully understand VTP and how it helps apart from just automatically uploading vlan information to the clients from the server which I can control manually myself?"

That's it's primary purpose, to reduce manual maintenance. It was more useful in olden days of yore when you might have hundreds of switches and didn't have L3 switches. (Personally, I always liked it but then I really more of a software developer than a network engineer. I like software doing things rather than people doing things.)

I recall (?) Cisco doing something that uses VTP (besides auto pruning), but I don't recall the particulars. It might have been something added to VTPv3.

[chris.george]

Hi Joseph - can you clarify this - I don't fully understand.

"And how else would I configure a central point of routing if I am strictly not really allowed to do this?"

An you're doing. I.e. your central L3 switch would be configured almost like it is now, you just wouldn't have the same VLAN on more than one trunk.

I didn't add this earlier, but the management vlan between the floor switches and the core is vlan 120 name SWITCH-MGMT-VLAN. So the switches to the core are accessed via the addressing on VLAN 120 - i.e. the core IP address is 10.10.120.1/24, and 1st Floor Switch A has address 10.10.120.11/24 etc. This is in addition to the two vlans I mentioned earlier - vlan 20 server vlan and vlan 22 client PC network.

[Leo Laohoo]

---

@chris.george wrote:

The VTP mode on the Core switch is set to SERVER.

---

Ideally, VTP should be set to Client or OFF.

[Joseph W. Doherty]

BTW, to OP, if the VTP options Leo suggests aren't available, you could also set your core to transparent mode.

[chris.george]

Sorry it's been a while getting back to you guys...

So "ideally" the core switch should be set transparent or off - OK good advice - but why? Will the core switch being the only VTP mode SERVER in the estate be detrimental or confusing for it? Will this perhaps cause the odd hiccup in the network for example?

[Deepak Kumar]

Hi,

A clear definition about VTP mode server:

VLAN Trunking Protocol (VTP) Server mode is the default VTP mode for all Catalyst switches. At least one server is required in a VTP domain to propagate VLAN information within the VTP domain. We can create, add, or delete VLANs of a VTP domain in a Switch which is in VTP Server mode and change VLAN information in a VTP Server. The changes made in a switch in server mode are advertised to the entire VTP domain.

So it is advisable to stop advertising the VTP information and avoid updated from any wrong server.

Regards,

Deepak Kumar 

[chris.george]

OK so nothing serious then in terms of routing, switching packets, spanning tree etc.

Just an advisory to prevent switches being updated.

[Joseph W. Doherty]

"why?"

In VTP v1 and v2, "server" mode allows you to change the VLAN info, on that device, for the VTP domain. However, even VTP clients can update your VTP domain. If fact, introducing a misconfigured VTP client can "erase" your whole VTP domain. This is why many consider not using VTP a best practice.

Also in versions 1 and 2, if you have more than one VTP server, its possible two VTP servers can issue an update at the same time and then you have a "race" to which update programs all the other VTP devices. You also, I believe, have a chance with multiple VTP servers that VTP devices could have different VTP VLAN information, as VTP devices accept updates based on VTP revision number. This is another reason why many consider not using VTP a best practice.

There are other "got chas" with VTP versions 1 and 2, security being another.

In VTP v3, communication between VTP hosts is much more controlled, so "accidental" changes are very unlikely. A VTP server is the control for the VTP domain. Version 3 attempts to address the issues found in the prior versions, but it's not widely used. Plus older Cisco switches often didn't support it.

[Bruno Ferreira]

Hello Chris!

I don´t see any problem with your topology. You are doing something as known as "Collapsed Core" architecture which is the way to go when working with small networks. So, having the "core" switch routing among VLANs is fine, don´t worry. 

Regarding the VTP, VLANs etc, the way you did is OK also. However, if there are no VTP clients on your network there is no use for a VTP server. You could set all of them to transparent, and configure the VLANs individually/manually on each of them if that´s what you want. 

Because VTP domains are tricky sometimes, I would only run it on such a small network in cases where the ITIL is boldly applied, meaning that I would have to register a CHANGE process to all of the Configuration Items being involved (boring). So, let´s say that the client requests you to add the VLAN XYZ to all of the floors. To accomplish that without VTP, you will have to place a CHANGE to all the 5 switches, while with VTP, the CHANGE will actually occur only at the DC switch. 

I hope this helps you!

Cisco - Small Enterprise Design

[chris.george]

I've been reading some of that Cisco documentation - looks like I have some changes to make.

In my collapsed backbone infrastructure ALL the floor switches are set to vlan 22 (which I guess isn't horrendous because we are a small network) - each floor consists of 4x 48 port switches, and we have 4 floors in total.

The Server room switches are set to vlan 20 for the Servers (there are other vlans of course with more specific duties).

I've noticed a couple of switches have 'low memory' as a result of my change to try and streamline our solution (i.e. floor switches that were layer 3 have been stripped down for layer 2 duties only).

What really annoys me is that ARP seems to want to tell all the switches in my network were everything is on vlan 22 and vlan 20 so it populates those CAM tables which I assume is eating up memory resources.

I'm just trying to work out how to lessen the overhead on the floor switches. I don't want the floor switches learning information automatically from ARP broadcasts about all the other clients on vlan 22 because I don't do client to client comms (peer to peer). All I want is for the floor switches to be populated with the necessary vlan 20 mac addresses because obviously the clients (vlan 22) need access to the servers (vlan 20).

How do I optimise this?

[Joseph W. Doherty]

"What really annoys me is that ARP seems to want to tell all the switches in my network were everything is on vlan 22 and vlan 20 so it populates those CAM tables which I assume is eating up memory resources."

That shouldn't be happening unless the switch "knows" of both VLANs.

How are the ports on both the core and downstream VLAN 20 switches configured?

[chris.george]

Yes the floor switches do know about each other I guess because all the floor switches a configured for the user vlan of 22.

The one fibre link from each of the floor switches (of which in total there are about 16) 802.1Q trunk down and converge to the Core switch in the computer room.

The Core switch is configured mostly for vlan 20 which are where the servers reside.

On each of the fibre uplinks from the Core to the Floor I have 'allowed vlan 20,22'.