RouterNotes.com

The syntax for setting up VLAN trunks on Cisco switches is straight forward, but a simple typo can keep them from working. Here are some simple troubleshooting steps to resolve trunking problems.

Trunking problems usually come down to one of two things: Either the entire trunk will not establish or there is a problem with a single VLAN communicating across the trunk. A detailed explanation of setting up VLAN trunks can be found here.


Problem 1: The trunk will not establish.

Step 1: Verify the native VLAN
When working with 802.1q VLAN trunks, the most common error is that the native vlan is different on each trunk. Both switches will produce a native VLAN mismatch error at the console. Look at the difference in the configuration with the show run int gigabit 0/1 command.

Switch A
interface gigabit 0/1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 5
switchport trunk allowed vlan 5,10,15

Switch B
interface gigbbit 0/1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 15
switchport trunk allowed vlan 5,10,15

Note that Switch A has a native VLAN of 5 and Switch B has a native VLAN of 15. This will prevent the trunk from establishing. Another problem is created when the native VLAN is specified on one switch, but not the other. The switch without a specified native vlan defaults to VLAN 1 as its native VLAN and creates the same native VLAN mismatch error as above, but finding the problem is not as obvious.

Switch A
interface gigabit 0/1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 5,10.15
No native VLAN is specified, so it defaults to VLAN 1

Switch B
interface gigbbit 0/1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 15
switchport trunk allowed vlan 5,10,15

Another problem that can keep the trunk from establishing is when the port is left is access mode. Mode access prevents the port from transmitting the proper VLAN information to the next switch. The improper configuration will look something like this:

Switch B
interface gigbbit 0/1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport mode access
switchport trunk native vlan 15
switchport trunk allowed vlan 5,10,15

Remove the mode access to resolve the problem

switchB(config-f)#int gigabit 0/1
switchB(config-f)#no switchpprt mode access


Problem 2: The trunk establishes, but there is a problem with a single VLAN on the trunk.

Step 1: Verify that the VLAN is created properly on each switch.
Cisco Switches will allow a VLAN to be added to a trunk port, but will not pass traffic unless the VLAN is configured on the switch. For example, if VLAN 15 is not working between the two switches, the show vlan command will show whether it is confgured.

SwitchA>show vlan

VLAN Name                             Status    Ports
—- ——————————– ———
5    Accounting                       active    fa0/1
10  Marketing                         active    fa0/2

switchB>show vlan

VLAN Name                             Status    Ports
—- ——————————– ———
5    Accounting                       active    fa0/1
10  Marketing                         active    fa0/2
15 Administration                   active    fa0/3

Note that VLAN 15 appears on Switch B, but not Switch A. Add the VLAN to Switch A to resolve the issue.

SwitchA(conf t)#vlan 15
Switch(config-vlan)#description Administration

Step 2: Verify that the VLANs are allowed on the trunk ports. It is a good idea to specify the vlans that are allowed on the trunk, but that means that they must be added after the fact. Look at the configuration for the trunk ports on switch A and B.

switchA
interface gigabit 0/1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 5
switchport trunk allowed vlan 5,10

Switch B
interface gigbbit 0/1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 5
switchport trunk allowed vlan 5,10,15

VLAN 15 is configured on the trunk for Switch B, but not for Switch A. Add the VLAN to switch A.

switchA(config)#interface gigbbit 0/1
switchA(config-if)#switchport trunk allowed vlan add 15

Private VLANs only govern Layer 2 communications. They do not force traffic to the router or firewall. Two hosts on the same subnet but separated by Private VLANS cannot communicate unless permitted. Traffic between the two is either enabled or disabled, it cannot be filtered like a firewall. Private VLANs must be trunked between switches in order to communicate between switches. I started to create detailed instructions, but found it well documented elsewhere on the net.

Here are few notes about Private VLANs
Enables Sticky ARP
Every port on that VLAN must be configured for Private VLANs
Ports come in three types

• Isolated - can only cummicate off-vlan
• Community - can communicate to other designated ports in the same VLAN
• Promiscuous - can communicate with any port

For more info see the PVLAN article from internetworkexperts.com and Private VLAN trunk configuration at Cisco

Some switches do not fully support private VLANs, but support a similar protected ports option which is simpler to configure. Packetlife has a complete description of protected ports.

VLAN trunks allow multiple networks to pass over a single physical connection. The trunk connection can be passed between two switches or between a switch and a computer. Before VLANs, each network connection required a separate corresponding physical connection, so using VLAN trunks reduces networking costs by reducing the need for expensive phycial connections and conserving the number of ports used on switches and servers.
Configuring VLAN trunks on Cisco switches and routers only takes a few steps.  For an in-depth look at working with vlans, look at Understanding VLANs on Cisco Switches.
First verify that the VLANs are created on both switches that are to be connected. Verify VLANs are created with the show vlan command.

Step 1: Verify VLANS
switchA>show vlan

VLAN Name                             Status    Ports
—- ——————————– ———
5    Accounting                       active    fa0/1
10  Marketing                         active    fa0/2

switchB>show vlan

VLAN Name                             Status    Ports
—- ——————————– ———
5    Accounting                       active    fa0/1
10  Marketing                         active    fa0/2

In the output above, we see that vlans 5 and 10 are configured on the switches and enabled on ports. A VLAN trunk between the two switches will allow devices on ports 1 on each switch to communicate and allow devices on ports 2 to communicate. A router is needed for all of the devices to talk to each other.

VLAN diagram on Cisco Switches

Step 2: Configure the trunk interfaces
For this example, the gigabit interfaces are used for the trunk links.

Switch A
switchA(config)#interface gigbbit 0/1
switchA(config-if)#switchport mode trunk

Switch B
switchB(config)#interface gigbbit 0/1
switchB(config-if)#switchport mode trunk


At this point, the two networks should start communicating across switches once the gigabit interfaces are connected, but it is a good practice to manually configure a few parameters to improve the stability and reliability of the trunk connection.

Switch A
switchA(config)#interface gigabit 0/1
switchA(config-if)#switchport trunk encapsulation dot1q

This command specifies the protocol that the two switches will use to communicate vlan information in the data that is transfered rather than leaving it to auto-negotiate.  Two Cisco switches will negotiate to ISL (Interswitch Switch Link) protocol which is Cisco proprietary rather than 802.1x, a recognized standard that is compatible with almost all switches and servers.

switchA(config-if)#switchport trunk native vlan 5

The native vlan command specifies the vlan that will be transmitted without VLAN tag information. It does not mtter which vlan is used, but both switches must agree for the link to operate properly. If a native vlan is not specified, then the switches will use vlan 1 by default. Using vlan 1 can cause problems because it is used as the default for so many other things in a switch network.

switchA(config-if)#switchport trunk allowed vlan 5,10
The allowed vlan command specifies which VLANs will be allowed to communicte over the trunk link. Otherwise, unnecessary traffic may go over the link.

Switch B
switchB(config)#interface gigbbit 0/1
switchB(config-if)#switchport trunk encapsulation dot1q
switchB(config-if)#switchport trunk native vlan 5
switchB(config-if)#switchport trunk allowed vlan 5,10


Adding or removing a VLAN
If VLAN 15 was configured on the switches, then it would need to be added to the trunk port on each switch.

Switch A
switchA(config)#interface gigbbit 0/1
switchA(config-if)#switchport trunk allowed vlan add 15

Switch B
switchB(config)#interface gigbbit 0/1
switchB(config-if)#switchport trunk allowed vlan add 15

A VLAN can be removed with a similar command:

Switch A
switchA(config)#interface gigbbit 0/1
switchA(config-if)#switchport trunk allowed vlan remove 15

Switch B
switchB(config)#interface gigbbit 0/1
switchB(config-if)#switchport trunk allowed vlan remove 15

Be Carefull
Verify that you used the add or remove option in the command or it will overwrite the allowed VLANS with only the VLAN that was to be added and communication between the other VLANs wil be broken.

For more detailed information, visit Cisco’s technical article on configuring VLAN trunks.

Historically, creating multiple networks required multiple switches, but VLANs (Virtual Local Area Networks) changed all of that. Now, more than one network can be created on a single switch.

If the switch has 24 ports, then it can have 24 separate networks on it. In most cases, Cisco switches support 1024 or more created VLANs per switch. Cisco’s command structure for creating multiple networks and assigning them to ports is simple and straight forward.

What are VLANs anyway?
VLANs are simply a way of separating traffic logically rather than physically. Each data packet that the switch receives is labeled with a VLAN id that tells the switch which network that the packet belongs to. Sometimes the process is called “tagging” because of the VLAN id tag that is added to the data packet. The switchport access VLAN command demonstrated above tells the switch to remove the VLAN id before the data packet is forwarded onto the computer connected to that switch port.

First, create the VLANs.
switchA>en
switchA#configure terminal
switchA(config)#vlan 5
switchA(config-vlan)#description Accounting
switchA(config)#vlan 10
switchA(config-vlan)#description Marketing

This defines two separate networks on the switch that can by used for ports. VLAN 5 could be used for the Accounting department and VLAN 10 could be used for the Marketing department. After the ports are assigned to the correct VLAN, computers in the Accounting department will not be able to see the Marketing department. It will be as if each department had its own switch.

Configure the ports
switchA(config)#int fa0/1
switchA(config-if)#description Markg-1
switchA(config-if)#switchport mode acess
switchA(config-if)#switchport access vlan 5
switchA(config)#int fa0/2
switchA(config-if)#description Acctg-1
switchA(config-if)#switchport mode acess
switchA(config-if)#switchport access vlan 10

Read the rest of this entry »

CPU spikes on switches and routers can cause crazy problems in the network because of the way that traffic flowing through the network gear can be discarded or paused. Applications like Solarwinds that track network utilization only show the processor usage average rather than tracking spikes that occur periodically. Network problems can still occur when the processor spikes close to 100 percent even for a few seconds.

Thankfully, Cisco has included a new command that can track cpu spikes. You must be at the enable prompt in order to issue this command.

routerA#show process cpu history

This command will show CPU usage charts of the switch or router for the past 60 seconds, 60 minutes and 72 hours. The charts are neatly created in text format and show average CPU usage with the # sign and maximum CPU with * symbols. Note that the charts are not retained after the router or switch has rebooted. For the most part, anything above 80 percent is a concern. If the maximum CPU reaches above that point, then the network device probably created some sort of network disruption because there wasn’t enough CPU cycles leftover to process the traffic. The symptoms are unusual, unexplainable and intermittent network problems– almost like ghosts or gremlins are causing havoc in the network.

Isolating what is causing the CPU spikes

Unfortunately, most of the detective work comes after diagnosing the CPU spike. The simplest way is to watch the device and enter the following command during the processor spike.

RouterA#show process cpu sorted

The process occupying the most processor time will pop up to the top. That should isolate what type of traffic that is causing the spike. Notice that this command shows CPU utlization for the five seconds, one minute and for five minutes

Cisco gear is designed to process typical traffic in its special hardware rather than in the CPU, so a CPU spike is a sign that something atypical is occurring on the network. The exact cause can be almost anything. For example, some types of traffic are designed to be processed by the processor in newer Cisco equipment like Appletalk and IPX, which are older protocols that have been replaced by TCP/IP. An overly complicated configuration with too many Access Control Lists can cause problems too. Perhaps the device is under attack from hackers, called a Denial of Service attack, or or the network utilization is beyond the device’s capacity and an upgrade is needed.

n a perfect world, every subnet would have its own interface or vlan, but this is far from a perfect world. Most routers start out that way, but networks change or get merged and things get a little messier.Secondary IP addresses are a great way to extend the network without readdressing every workstation and printer. At the very least, secondary IP addresses on Cisco routers can make things smoother during an IP migration.

For example, configuring an IP address on a Cisco interface is simple.

router(config)#int vlan 1

router(config-if)# ip address 10.1.1.1 255.255.255.0

This will configure the vlan 1 interface with the IP address of 10.1.1.1.

By adding the following statement, we can place two addresses on the same interface.

router(config)#int vlan 1

router(config-if)# ip address 10.1.1.1 255.255.255.0

router(config-if)# ip address 10.1.2.1 255.255.255.0 secondary

Be sure not to miss the word secondary or the primary IP address will be overwritten and traffic to that address will stop working. This is bad for users that are connected to that the primary interface of 10.1.1.1 for their network gateway and especially bad if you are connected via telnet to the router because you will lose access and have to console directly into the router to recover.

Now, the router will respond to the addresses of 10.1.1.1 and 10.1.2.1.

Users on each of the two subnets will never know that they are using the same interface.

The router will use the primary IP address to ping and traceroute unless you specify an address with an extended ping or traceroute command.

Secondary address can also be used in conjuction with DHCP superscopes. For instance, a DHCP server can be configured to assign available addresses from a pool of addresses in the 10.1.1.0 subnet and then when that is depleted go on to use addresses from the 10.1.2.0 subnet as long as both address are configured on the same router interface as explained earlier. Note that the primary IP address of the router has to match the first range of the DHCP superscope configured on the DHCP server or the server will not know which superscope to use and will not reply with an address.

The main negative in using secondary addresses is that it does not contain broadcasts and multicasts on that network. In most cases, the router and workstations can handle broadcasts from two or three subnets, but it is not a good idea to stack several subnets together on a single interface or the network will seem to slow down.

For example, configuring an IP address on a Cisco interface is simple.

router(config)#int vlan 1

router(config-if)# ip address 10.1.1.1 255.255.255.0

This will configure the vlan 1 interface with the IP address of 10.1.1.1.

By adding the following statement, we can place two addresses on the same interface.

router(config)#int vlan 1

router(config-if)# ip address 10.1.1.1 255.255.255.0

router(config-if)# ip address 10.1.2.1 255.255.255.0 secondary

Be sure not to miss the word secondary or the primary IP address will be overwritten and traffic to that address will stop working. This is bad for users that are connected to that the primary interface of 10.1.1.1 for their network gateway and especially bad if you are connected via telnet to the router because you will loose access and have to console directly into the router to recover.

Now, the router will respond to the addresses of 10.1.1.1 and 10.1.2.1.

Users on each of the two subnets will never know that they are using the same interface.

The router will use the primary IP address to ping and traceroute unless you specify an address with an extended ping or traceroute command.

Secondary address can also be used in conjuction with DHCP superscopes. For instance, a DHCP server can be configured to assign available addresses from a pool of addresses in the 10.1.1.0 subnet and then when that is depleted go onto use addresses from the 10.1.2.0 subnet as long as both address are configured on the same router interface as explained earlier. Note that the primary IP address of the router has to match the first range of the DHCP superscope configured on the DHCP server or the server will not know which superscope to use and will not reply with an address.

The main negative in using secondary addresses is that it does not contain broadcasts and multicasts on that network. In most cases, the router and workstations can handle broadcasts from two or three subnets, but it is not a good idea to stack several subnets together on a single interface or the network will seem to slow down.