Basic & Advanced Catalyst Layer 3 Switch Configuration: Creating VLANs, InterVLAN Routing (SVI), VLAN Security, VTP, Trunk Link, NTP Configuration. IOS License Requirements for SVI Routing

This article covers basic and advanced configuration of Cisco Catalyst Layer-3 switches such as the Cisco Catalyst 3560G, 3560E, 3560-X, 3750, 3750E, 3750-X, 3850, 4500, 6500 , 9300, 9400 series, and extends to include the configuration of additional features considered important to the secure and correct operation of these devices.

In many cases, these Catalyst Layer 3 switches are purchase and installed with basic configuration or features enabled, without leveraging their layer 3 capabilities.

After observing many installations that fell into this category (almost out of the box configurations), we decided it was a great idea to begin covering configuration best-practices that will help engineers understand the capabilities of this equipment and better adapt configurations to their company needs.

By correctly leveraging the capabilities offered by any Cisco Catalyst Layer 3 switch we can create a solid network backbone with high security standards that will have the necessary flexibility to ensure the smooth operation of our network.

Article Key Topics::

• Layer 2 Switching Limitations
• Introduction to Layer 3 Switches
• IOS License Requirements for InterVLAN Routing/ SVI IP Routing
• Creating, Configuring and Verifying VLANs
• Enable InterVLAN Routing (SVI - ip routing) and Configuring Default Gateway
• VLAN Security: Moving Ports (interfaces) off the Management VLAN (VLAN1)
• Configuring & Securing Access & Trunk Links Against VLAN Hopping
• Configuring Virtual Trunk Protocol (VTP) Server
• Configuring Network Time Protocol (NTP) - Understanding Why NTP is Essential

Layer 2 Switching Limitations

Cisco's portfolio of catalyst switches is designed to meet any network requirement (in speed, capacity, expandability and security) from small companies up to very large enterprises. Take for example the popular Catalyst Cisco 2960 series switches – these Layer 2 switches provide a healthy amount of features in speed, functionality and security, leaving very little to be desired even in very demanding network environments.

The biggest problem with Layer 2 switches is that while they can support the creation of multiple VLAN, Layer 2 switches are unable to route packets between VLANs – a process known as InterVLAN routing. Making InterVLAN routing possible requires a switch (or any other device) that operates at the 3^rd layer of the OSI model, this translates to a router (Router-on-a-stick method), layer 3 switch or server.

Note: VLAN concepts and InterVLAN routing theory is covered in great depth at our popular Firewall.cx VLAN section.

Introducing Cisco Catalyst Layer-3 Switches

Cisco produces a number of high-end switches that are capable of delivering Layer 3 routing functionality within an enterprise network of any size. The most popular models found on the market are as follows:

• Cisco Catalyst 3560, 3560G, and newer 3560-E & 3560-X
• Cisco Catalyst 3750, 3750G and newer 3750-E & 3750-X
• Cisco Catalyst 3850
• Cisco Catalyst 4500 series. Includes 4503-E, 4506-E, 4507R+E, 4510R+E etc.
• Cisco Catalyst 6500 series. Includes 6503-E, 6504-E, 6506-E, 6506-E, 6509(E,V, NEB) & 6513 etc.
• Cisco Catalyst 9300 series
• Cisco Catalyst 9400 series

These Layer 3 switches are usually found at the Core Network Layer, interconnecting all other Layer 2 switches, providing secure access to all VLAN networks according to the company’s security policy. VLANs are created at the Core Layer (on these switches) and InterVLAN routing is configured according to the company’s requirements.

While some might consider Layer 3 switching unnecessary, the truth is that if there is more than one VLAN on the network, chances are that a Layer 3 switch is necessary as it will allow control of VLAN communications and integrate security, flexibility and network performance into one (or more) physical device(s).

IOS License Requirements For InterVLAN Routing – SVI IP Routing

Due to Cisco’s new licensing model, purchasing a Layer 3 switch doesn’t really mean that essential features such as InterVLAN routing can be used.

In order to enable features such as InterVLAN routing, the switch must have the appropriate license. This is applicable for the newer 3560-E, 3560-X, 3750-E, 3750-X models & all 4500/6500 Supervisor engines using the new Universal Cisco IOS software image (IOS 15.x onwards).

Thankfully Catalyst switch models 3560, 3560G, 3750, 3750G, Catalyst 4500/4000 Series with Sup II+ or later, or Catalyst 6500/6000 Series that run Cisco IOS system software, support basic InterVLAN routing features in all their software versions.

So if purchasing a Layer 3 switch is on the company's plans, special attention must be given to ensure it has the correct license that will allow InterVLAN routing or other desired features.  In the event an incorrect model number/license is purchased, the only way to enable the feature required is to purchase an additional license – an exercise that will increase costs significantly and should be avoided. For this reason it is very important the correct license is selected with the initial purchase.

The table below outlines the Feature Set Characteristics and Differences of all available licensing models:

As a rule of thumb, any newer 3560-E, 3560-X, 3750-E or 3750-X switches must be purchased with the IP Base license in order to support InterVLAN routing. The LAN Base license will allow Switched Virtual Interfaces (VLANs) to be created, however, it does not support InterVLAN routing or IP routing.

Now that we’ve got the licensing covered, it’s time to begin creating our VLAN interfaces.

Creating & Configuring VLANs

First step on any Layer 3 switch is to create the necessary VLANs.  

By default, VLAN1 exists on every switch. VLAN1 is also known as the Management VLAN and it's highly advisable VLAN1 is not used to carry user data/traffic, as VLAN1 is used only for the management of the network’s switches. Company traffic (Servers, workstations etc) should be placed on a different VLAN, for example, VLAN2.  Voice traffic e.g IP Phones, CallManager, CallManager Express or Voice Gateways, should also be placed on a VLAN of their own – also known as the Voice VLAN.

As part of the design and implementation phase, we strongly advise to create a list of the VLANs that will be created along with their name and any additional information to help identify their purpose and of course the IP address that will be assigned to every VLAN interface on the core Layer 3 switch. This will ensure all VLANs are created and everything is documented for future reference.

Below is an example of a VLAN list we created during the installation of our Cisco Catalyst 3560G:

Before we begin creating our VLANs, let’s take a look and see the default VLANs that exist on Catalyst Layer 3 switches using the show vlan brief command:

First step is to create and name the new VLANs in the switch’s VLAN database. This is accomplished by using the vlan command, followed by the name command. Depending on the switch model, these commands might or might-not appear in the configuration:

We can verify the new VLANs have been created in the VLAN database by issuing the show vlan brief command:

Note that created VLANs are stored in the switch’s VLAN database. The VLAN database is a file named vlan.dat and is located in the switch’s FLASH memory:

Looking carefuly at the creation/modified date of the files, it seems like we are off by a bit more than 10 years, so it is evident the correct date and time have not yet been configured. We’ll take care of this later.

 
Next, we create our VLAN interfaces and assign IP addresses and descriptions:

Note: When configuring the new VLAN interfaces, the switch will show the following message on the console for each VLAN interface configured: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan2, changed state to down. This message can safely be ignored as the VLAN Line protocol will come up as soon as ports on the switch are assigned to the VLAN.
 
There is a possibility that Interface VLAN1 might have the shutdown command configured. This can be checked by issuing the show run command. In the case the shutdown command is present under VLAN1 interface, it is imperative to issue the no shutdown command so that the Management VLAN interface comes up.
 
The show ip interface brief command will verify all VLANs are up (Status), but with a protocol down status as explained earlier:

Enable SVI InterVLAN Routing – IP Routing & Configuring Default Gateway

A Switch Virtual Interface (SVI) is a VLAN of switch ports represented by one interface to a routing or bridging system. Since there is no physical interface for the VLAN, the SVI provides the Layer 3 processing for packets from all switch ports associated with the VLAN. Once VLANs have been created and VLAN interfaces are configured with their IP addresses, we can enable ip routing on our switch, effectively switching ‘on’ the InterVLAN routing capabilities of the switch and enabling the supported routing protocols.

Let’s take a look at the routing capabilities before enabling ip routing. This can be done using the show ip route command:

Notice the ip routing protocol is not enabled, and therefore no entries exist in the switch’s routing table. 

It is important to mention that hosts belonging to different VLANs are not able to communicate or ‘ping’ each other at this point. IP routing must be enabled to allow the switch to pass (route) packets from one VLAN to another.

IP routing is easily enabled using the ip routing command:

At this point, ip routing has been enabled. When issuing the show ip route command, the switch shows all networks learnt from the supported routing protocols (none active at the moment).  Hosts between different VLANs are now able to communicate with each other as long as they have their IP gateway set to the 3560’s VLAN IP interface of their network.

Next, we need to configure a default gateway for the Layer 3 switch. This will instruct the switch to send any packets not belonging to the local network(s), to the next hop, which is usually a router: 

With the default gateway set, we can now issue the show ip route command again and check the results:

VLAN Security: Moving All Ports (interfaces) Off The Management-VLAN

When configuring a switch, it is very important not to leave any ports (interfaces) assigned to the Management VLAN. Doing so will expose the backbone network to anyone who connects to a port assigned to VLAN1. All ports should be configured for another VLAN or, even better, shutdown any unused ports.

The 3560G in our lab has 48 Gigabit Ethernet ports plus 4 SFP ports, but we will use the interface range command to apply the configuration changes to all 48 Gigabit Ethernet ports at the same time, saving us valuable time:

Issuing the show vlan brief command will verify our new configuration changes:

As shown, only the last four ports (0/49 – 0/52) are still on VLAN1. These ports represent the four SFP ports on the switch, normally used to connect to other switches via fiber optic links.  We’ll talk about them soon.

Configuring & Securing Access & Trunk Links Against VLAN Hopping

VLAN Hopping is a well-known attack method by which an attacker uses insecure switch ports to help him jump from one VLAN to another, gaining access to multiple networks. Preventing attacks such as VLAN hopping can be easily achieved by following some basic steps.

The previous section explained why it is important all access ports are configured with a VLAN other than the management VLAN. In addition to the switchport mode access command, the switchport nonegotiate command will ensure that the specific port configured to never negotiate trunks automatically:

On the other hand, Trunk links are essential on any VLAN network as they carry traffic from all VLANs, allowing switches to connect between each other and move traffic between them as necessary. A port is usually configured as a Trunk when it connects to one of the following:

• Switch
• IP Phone
• Access Point configured with multiple SSIDs

Trunk links are also configured with a native VLAN. A Trunk link’s native VLAN carries untagged traffic, just like any port configured as an access link. So if we were to connect an access device (e.g computer) to a port configured as a Trunk link, then the computer will have access to the Trunk's native VLAN. The problem here is that, by default, all Trunk links have their native VLAN configured to VLAN1 - the Management VLAN!

The workaround here is to ensure the native VLAN of any Trunk link is set to an unused VLAN. For this reason we normally create a ‘dummy’ VLAN and configure it as the native VLAN for our Trunk Links. Assuming we have created VLAN 20 as our 'dummy' VLAN, we configure the Trunk Links native VLAN to that.

By using a few additional commands under our switch port interfaces, we can secure our switch interfaces and effectively avoid these attack methods.

Configuring Virtual Trunk Protocol Server (VTP)

Configuring VTP is essential in any Cisco powered network infrastructure. The VTP protocol ensures all VLAN information is propagated to all Cisco switches that are part of the configured VTP Domain.  VTP is analysed extensively at Firewall.cx’s Virtual Trunk Protocol section. The section provides in-depth analysis of the VTP protocol structure with 3d protocol structure frames, how VTP works, VTP modes and advantages offered, plus a lot more. For more information on VTP, please visit the Virtual Trunk Protocol section.

VTP configuration consists of a few basic parameters and a number of optional parameters.  We’ve selected a number of these parameters that are necessary to get VTP working in any working environment:

• Configuration of VTP Mode
• Configuration of VTP Domain
• Configuration of VTP Password
• Verification of VTP Status

Configuring the VTP mode is essential for VTP’s correct functionality.  In any given network of switches only one switch is assigned with the VTP Server role, while all other switches are set to VTP Client or VTP Transparent mode.

Configuration of VTP Mode

By default, all switches are configured in VTP Server mode. We can view the mode status by using the show vtp status command:

Notice the VTP Operating Mode is set to Server and the amount of VLANs (12) already contained in the database. The Configuration Revision number is automatically incremented every time a change is made to the existing VLAN database.

Configuring the VTP Mode to server is accomplished with the vtp mode server command:

If the switch is already in Server Mode, expect to see the Device mode already VTP SERVER message.

Configuration of VTP Domain

Configuring the VTP Domain is accomplished with the use of the vtp domain command. Network switches configured as VTP Clients and the same VTP Domain will ‘listen’ to the VTP Server. VLANs created at the VTP server will automatically be made available on all other switches configured as VTP Clients:

As shown, the initial VTP Domain is by default set to NULL. This changes as soon as we set the VTP Domain.

Configuration of VTP Password

Setting the VTP password is very important as it ensures only VTP clients with the correct password are able to exchange VTP information for the specified VTP Domain.

Verification of VTP Status

Finally, we can verify our VTP setup and status using the show vtp status command:

Of course VTP offers a number of additional parameters that can be tweaked to reduce broadcast traffic (VTP Pruning), increased security (VTP v2 mode) and more,  but these commands are out of this article's scope.

NTP Configuration – Understanding Why NTP Service is Essential

The NTP service is used by the switch to synchronize its internal clock and date with an NTP server. This ensures that the switch is correctly synced at all times. Many engineers wonder why it is so important to configure a switch’s clock, considering the device is simply a switch and not a file server or domain controller. The truth is that NTP configuration is extremely important and we will explain why.

A switch with a properly configure NTP service allows us to easily analyse the switch log messages to help determine when specific events might have happened. If for example a file server’s network card was disconnected briefly from the network, we could then view the switch’s log messages and see when exactly this occurred. Another frequently observed example is when switch ports in violation are automatically shutdown by the switch. Examining the logs, we can view when a specific violation occurred and why it caused the switch to shutdown its port. As a last example, if a syslog server is configured to track all switch messages, errors and events or if we are using a Radius server to restrict network access for specific days of the week and times, then NTP configuration is mandatory.

In every case, it’s good practice to ensure NTP is configured on the network equipment we are responsible for. Along with NTP, it’s always important to remember to configure the correct timezone and daylight saving, so that the switch automatically adjusts the time when necessary.

When configuring NTP, we can select either an internal or public NTP server from which the switch will synchronize. In the event a public ntp server is the preferred choice, we advise visiting the NTP Pool Project homepage http://www.pool.ntp.org/en/  and selecting a server from the available lists. Currently there are over 4000 servers all over the world to choose from.

Let’s take a look at the current date and time our lab switch has:

First step is to configure a preferred NTP server. We’ve selected 0.europe.pool.ntp.org from the European NTP Pool. Note that in order for our switch to resolve 0.europe.pool.ntp.org to an IP address, we must have configured a valid name server. We used Google’s public DNS server 8.8.8.8:

Notice how the switch will automatically attempt to translate the FQDN into an IP address. The IP address of the NTP server is then stored into the configuration. Viewing the date and clock after executing the above commands will show that the switch has correctly synchronized with the selected NTP server:

Notice that the time is synched for UTC or GMT 0. Since we are located in Greece, we need to instruct the switch to use the correct timezone (GMT +2) and daylight saving:

As soon as the above commands are entered, the switch will automatically adjust the time:

Finally, issuing the show clock command will confirm everything is configured correctly:

As a final note, do not forget to save the configuration!