Network Ninja

Common VLAN configuration errors made when configuring VLANs are listed below.

802.1Q Native VLAN Problem

An 802.1Q trunk link doesn’t encapsulate frames but adds a tag and re-calculates the frame-check sequence (FCS) of the frame. The 802.1Q trunk also allows for untagged frames to pass through the trunk on the NATIVE VLAN. A common configuration error is when there is a trunk link and the NATIVE VLAN is not the same on both sides of the trunk causing connectivity issues.

802.1Q Native VLAN Resolution

• NATIVE VLANs must coincide on both ends of the trunk link otherwise a trunk link may not form.
• Cisco NATIVE VLAN is default VLAN 1, for security purposes make the NATIVE VLAN something that is not used for normal purposes.switch(config-if)#switchport trunk native vlan 1-4094
• If there is a NATIVE VLAN mismatch CDP (if used and active) will issue a “native VLAN mismatch” error.
• On select versions of IOS CDP may not be transmitted if VLAN 1 is not working or automatically be disabled on the trunk.
• If there is a NATIVE VLAN mismatch on either side of an 802.1Q trunk, layer-2 loops may occur because VLAN 1 STP bridge protocol data units (BPDUs) are sent to the IEEE STP MAC untagged.
• When troubleshooting VLANs note that a link can have one NATIVE VLAN association when in access mode and another when in trunk mode.

Trunk Link Problems

There are certain elements that determine whether a trunk link is formed or not, the elements that determine this are the trunking mode, the encapsulation type, the VTP domain, and the hardware capabilities of the connected ports.

Trunks can be configured to either statically or autonegotiate trunks with the use of Dynamic Trunking Protocol (DTP), for autonegotiation the switches must be in the same VTP Domain. There are however certain other small things to take note of about the configuration with trunk links.

Through the use of the switchport command trunks can be autonegotiated. There are certain variations of the command that will not setup a successful trunk through; the command is below and there are some of the options available: swtich(config-if)#switchport mode dynamic / auto / desirable / trunk We wish to config a trunk link the following options will not create a trunk. swtich1(config-if)#switchport mode auto
swtich2(config-if)#switchport mode autoThis shows both interfaces in switchport mode auto and will not config a trunk.swtich1(config-if)#switchport mode dynamic
swtich2(config-if)#switchport mode accessThis shows one interface switchport mode dynamic desirable and the other static access and will not config a trunk.swtich1(config-if)#switchport mode trunk
swtich2(config-if)#switchport mode auto

This shows one interface switchport mode trunk and the other interface switchport interface auto. This config will not create a trunk because the interface set to trunk will not send DTP frames and then the auto interface will switch to being an access port.

This topic is something I can feel in my bones will come up in tests you either have this topic down or don’t have a clue and guestimate. I think I am going to try and know it because it’s easy enough to make a table and just learn; check out CCIE Pursuit for a table on the 3550/3560 routers and bitmindframes for more info on each DTP config state.

DTP Requirements

The reason a Network Administrator would deploy DTP is to automate to a degree the trunking process. To give you more of an explanation if a port can become a trunk (switch-switch not supported on routers), it may also be able to trunk automatically, and in some cases even negotiate the type of trunk (ISL/802.1Q). This is where DTP comes in to provide the negotiation of the trunking method with the neighbour device.

There are however requirements for DTP the main one being support for ISL or 802.1Q on both ends of the trunk (Switch A and Switch B must support and be configured with one or the other) so that DTP can do its job.

This can be expanded slightly where the switch platform does or doesn’t provide support for ISL but does support 802.1Q trunking and supports DTP like the Catalyst 4500/4000 (CatOS), which includes 2948G/2980G/4912G also the Catalyst 2950/2955/2940 series. This simply means all trunking will be done using 802.1Q.

Lastly where both ISL and 802.1Q is supported but DTP is not like the Catalyst 2900XL/3500XL/2948G-L3/4908G-L3/4840G/8500 Series.

Trunk Link Resolution

Trunk Negotiation is managed by DTP, which is Cisco proprietary, and is a point-to-point protocol (see any problems with this yet) when using DTP make sure that both ends of the link are in the same VTP Domain otherwise it wont work. Secondly because it is Cisco proprietary certain network devices wont support DTP which could cause misconfiguration cross-brands (when configuring on an interface that is connected so something non-cisco turn off DTP). Find some more information here that’s doesn’t assume you know something about DTP before jumping right in and also covers some other topics in the same post.

The correct way then to configure a port to either trunk or not would be for access ports swtich(config-if)#switchport mode access for trunking without DTP swtich(config-if)#switchport mode trunk
swtich(config-if)#switchport mode nonegotiate then finally for encapsulation type on the trunk port swtich(config-if)#switchport trunk encapsulation dot1q
swtich(config-if)#switchport trunk encapsulation isl. Keeping in mind that dot1q is cross-vendor and isl is also Cisco proprietary.

VTP Problems

The VTP Resolution and best practices are dealt with in a previous post

Trunk and VLAN Specific

Sometimes it is needed to only carry specific/certain VLANs accross trunk links. You will remember from the CCNA that by default all VLANs are allowed across a trunk link when it is created unless specifically told otherwise. This will mean that VLAN 1 through x will traverse a trunk unless you as Admin say otherwise. In some situations having all vlans moving across trunks is not the desired sitatuation.

As an example if you have VLAN 1 through 10, assume 1,3,6, and 9 is actively used on one Switch 1 and  2,4,6,8 and 10 on Switch 2.

There is no “active” users for VLANs 2,4,6,8, and 10 on Switch 1 and no active users for VLaN 1,3,6, and 9 on Switch 2 why then send these VLANs all over the place when this will be wasteful?  To change this situation one can use any one of these commands:

Switch(config-if)switchport trunk allowed vlan remove/except/add x,x,x

Using either the remove 2,4,6,8 and 10, except 2,4,6,8,10 or add 1,3,6,9 command will have the same end result of allowing only 1,3,6, and 9 across the trunk link.

Notes and Notices:

This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.