Monitoring system reporting interface of 1 devices having exceding “input error” threshold being set.

Information from “show interface x” , only “input error” increasing. Other like “runts” , “giants” , “CRC” , nothing , clean , zero statistics.

Googling about this “input error” , mostly said about “internal buffer” which caused by large output packets send at one time. But 30 seconds interval statistics showing traffic no more than 100Kbps on this gigabit ethernet.

Seem that not the case , and then found this interesting articles :

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008015bfd6.shtml#l3_l2

googling keyword : “cisco input error layer 2 interface”

So i check the configuration between interconnecting devices.

The link is using etherchannel 2 ports , where one side (Cat 6500) configured with L3 etherchannel , the other side (Cat 4948) configured as L2 etherchannel. Thats not the one caused the “input error” , its turn out that the configuration on L2 port was “switchport mode dynamic desirable” , which in turn will generate DTP frame toward the other end to negotiate the link as trunk. DTP frame received by L3 interface will be dropped , since the DTP is unknown encapsulation by L3.

Resolution : configure the L2 port as manual access / trunk mode.

Well each day learn new things , that a good thing.

I always confused with the native vlan relation with management protocols (VTP , CDP , PagP , DTP).

Do they use the native vlan in order to send to neighbour switch(es) ?

What happened if i changed the native vlan ?

Once , I did a packet capture , but it seem the management protocols frame were tagged (even though i change the native vlan), are they send via native vlan ?

Really confused me a lot. But following resource completely remove my confusion. Now i know that all those management protocols always use VLAN 1 , regardless the native vlan configured for the trunk link between switches.

Here what i got from cisco website.

Article :

VLAN 1 has a special significance in Catalyst networks.

The Catalyst Supervisor Engine always uses the default VLAN, VLAN 1, to tag a number of control and management protocols when trunking, such as CDP, VTP and PAgP. All ports, including the internal sc0 interface, are configured by default to be members of VLAN 1. All trunks carry VLAN 1 by default, and in CatOS software versions earlier than 5.4, it was not possible to block user data in VLAN 1.

These definitions are needed in order to help clarify some well-used terms in Catalyst networking:

• The management VLAN is where sc0 resides; this VLAN can be changed.
• The native VLAN is defined as the VLAN to which a port returns when not trunking, and is the untagged VLAN on an 802.1Q trunk. By default, VLAN 1 is the native VLAN.
• In order to change the native VLAN, issue the set vlan vlan-id mod/port command.Note: Create the VLAN before you set it as the native VLAN of the trunk.

These are several good reasons to tune a network and alter the behavior of ports in VLAN 1:

• When the diameter of VLAN 1, like any other VLAN, gets large enough to be a risk to stability (particularly from an STP perspective) it needs to be pruned back. This is discussed in more detail in the In-Band Management section of this document.
• Control plane data on VLAN 1 must be kept separate from the user data in order to simplify troubleshooting and maximize available CPU cycles.
• L2 loops in VLAN 1 must be avoided when multilayer-campus networks are designed without STP, and trunking is still required to the access layer if there are multiple VLANs and IP subnets. To do this, manually clear VLAN 1 from trunk ports.

In summary, note this information about trunks:

• CDP, VTP, and PAgP updates are always forwarded on trunks with a VLAN 1 tag. This is the case even if VLAN 1 is cleared from the trunks and is not the native VLAN. If VLAN 1 is cleared for user data, these is no impact on control plane traffic that is still sent using VLAN 1.
• On an ISL trunk, DTP packets are sent on VLAN1. This is the case even if VLAN 1 is cleared from the trunk and is no longer the native VLAN. On an 802.1Q trunk, DTP packets are sent on the native VLAN. This is the case even if the native VLAN is cleared from the trunk.
• In PVST+, the 802.1Q IEEE BPDUs are forwarded untagged on the common Spanning Tree VLAN 1 for interoperability with other vendors, unless VLAN 1 is cleared from the trunk. This is the case regardless of the native VLAN configuration. Cisco PVST+ BPDUs are sent and tagged for all other VLANs. Refer to the Spanning Tree Protocol section in this document for more details.
• 802.1s Multiple Spanning Tree (MST) BPDUs are always sent on VLAN 1 on both ISL and 802.1Q trunks. This applies even when VLAN 1 is cleared from the trunks.
• Do not clear or disable VLAN 1 on trunks between MST bridges and PVST+ bridges. But, in the case that VLAN 1 is disabled, the MST bridge must become root in order for all VLANs to avoid the MST bridge putting its boundary ports in the root-inconsistent state. Refer to Understanding Multiple Spanning Tree Protocol (802.1s) for details

SOURCE : http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a0080094713.shtml

Lesson Learned

so my understanding now are :

• - native vlan for backward compatibility with early 802.1q , and switched that does not support 802.1q
• - management protocols are always using vlan 1 , even though removed from the trunk link