Thursday 17 December 2015

To troubleshoot VLAN issues when you have no connection between PCs that belong to the same VLAN

VLAN Troubleshooting
The following figure shows the flow for troubleshooting VLANs.

To troubleshoot VLAN issues when you have no connection between PCs that belong to the same VLAN, follow these high-level steps:
1.      Use the show vlan command to check whether the port belongs to the expected VLAN. If the port is assigned to the wrong VLAN, use the switchport access vlan command to correct the VLAN membership. Use the show mac address-table command to check which addresses were learned on a particular port of the switch and to which VLAN that port is assigned.
2.      If the VLAN to which the port is assigned is deleted, the port becomes inactive. Use the show vlan or show interfaces switchport command to verify that the VLAN is present in the VLAN database.
MAC Address Table Verification
To display the MAC address table, use the show mac-address-table command in privileged EXEC mode as shown in the following example. This command displays the MAC address table for the switch. Specific views can be defined by using the optional keywords and arguments. The example shows MAC addresses that were learned on the FastEthernet0/1 interface. It can be seen that MAC address 000c.296a.a21c was learned on the interface FastEthernet0/1 in VLAN 10. If this number is not the expected VLAN number, change the port VLAN membership using theswitchport access vlan command.
SW1#show mac address-table interface FastEthernet 0/1
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
  10    000c.296a.a21c    DYNAMIC     Fa0/1
  10    000f.34f9.9181    DYNAMIC     Fa0/1
Total Mac Addresses for this criterion: 2
Troubleshooting Missing VLANs
Each port in a switch belongs to a VLAN. If the VLAN to which the port belongs is deleted, the port becomes inactive. All ports belonging to the VLAN that was deleted are unable to communicate with the rest of the network.
As shown in the following example, use the command show interface interfaceswitchport to check whether the port is inactive. If the port is inactive, it will not be functional until the missing VLAN is created using the vlan vlan_id command or the port is assigned to a valid VLAN.
SW1#show interfaces FastEthernet 0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 10 (Inactive)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none



Monday 9 February 2015

Why is QoS Important for Enterprise Networks?

A communications network forms the backbone of any successful organization. These networks
transport a multitude of applications, including realtime voice, high-quality video and delay-sensitive
data. Networks must provide predictable, measurable, and sometimes guaranteed services by managing
bandwidth, delay, jitter and loss parameters on a network.
QoS technologies refer to the set of tools and techniques to manage network resources and are
considered the key enabling technology for network convergence. The objective of QoS technologies is
to make voice, video and data convergence appear transparent to end users. QoS technologies allow
different types of traffic to contend inequitably for network resources. Voice, video, and critical data
applications may be granted priority or preferential services from network devices so that the quality of
these strategic applications does not degrade to the point of being unusable. Therefore, QoS is a critical,
intrinsic element for successful network convergence.
QoS tools are not only useful in protecting desirable traffic, but also in providing deferential services to
undesirable traffic such as the exponential propagation of worms. You can use QoS to monitor flows and
provide first and second order reactions to abnormal flows indicative of such attacks, as will be discussed
in additional detail later in this document.

Tuesday 3 February 2015

MAC TX & RX Statistics


Counter

Description

TX_PKT_LT64

Number of frames (good and bad frames) with transmit packet size less than 64 bytes.

TX_PKT_64

Number of frames (good and bad frames) with transmit packet size equal to 64 bytes.

TX_PKT_65

Number of frames (good and bad frames) with transmit packet size between 65 and 127 bytes.

TX_PKT_128

Number of frames (good and bad frames) with transmit packet size between 128 and 255 bytes.

TX_PKT_256

Number of frames (good and bad frames) with transmit packet size between 256 and 511 bytes.

TX_PKT_512

Number of frames (good and bad frames) with transmit packet size between 512 and 1023 bytes.

TX_PKT_1024

Number of frames (good and bad frames) with transmit packet size between 1024 and 1518 bytes.

TX_PKT_1519

Number of frames (good and bad frames) with transmit packet size between 1519 and 2047 bytes.

TX_PKT_2048

Number of frames (good and bad frames) with transmit packet size between 2048 and 4095 bytes.

TX_PKT_4096

Number of frames (good and bad frames) with transmit packet size between 4096 and 8191 bytes.

TX_PKT_8192

Number of frames (good and bad frames) with transmit packet size between 8192 and 9216 bytes.

TX_PKT_GT9216

Number of frames (good and bad frames) with transmit packet size greater than 9216 bytes.

TX_PKTTOTAL

Total number of frames (good and bad frames) transmitted.

This number is the sum of all transmitted packets regardless of frame length.

TX_OCTETS

Total byte count of packet octets (good and bad frames) transmitted.

TX_PKTOK

Number of good frames transmitted.

TX_UCAST

Number of good unicast frames transmitted.

TX_MCAST

Number of good multicast frames transmitted.

TX_BCAST

Number of good broadcast frames transmitted.

TX_VLAN

Number of good 802.1Q tagged VLAN frames transmitted.

TX_PAUSE

Number of 802.3x PAUSE frames transmitted.

TX_USER_PAUSE

Number of transmitted priority flow control frames.

TX_FRM_ERROR

Number of frames with cl_im_tx_err set to 1 at EOP.

TX_OCTETSOK

Total byte count of good frames.

MAC RX Statistics


MAC RX Statistic

Description

RX_PKT_LT64

Number of frames (good and bad frames) with receive packet size less than 64 bytes.

RX_PKT_64

Number of frames (good and bad frames) with receive packet size equal to 64 bytes.

RX_PKT_65

Number of frames (good and bad frames) with receive packet size between 65 and 127 bytes.

RX_PKT_128

Number of frames (good and bad frames) with receive packet size between 128 and 255 bytes.

RX_PKT_256

Number of frames (good and bad frames) with receive packet size between 256 and 511 bytes.

RX_PKT_512

Number of frames (good and bad frames) with receive packet size between 512 and 1023 bytes.

RX_PKT_1024

Number of frames (good and bad frames) with receive packet size between 1024 and 1518 bytes.

RX_PKT_1519

Number of frames (good and bad frames) with receive packet size between 1519 and 2047 bytes.

RX_PKT_2048

Number of frames (good and bad frames) with receive packet size between 2048 and 4095 bytes.

RX_PKT_4096

Number of frames (good and bad frames) with receive packet size between 4096 and 8191 bytes.

RX_PKT_8192

Number of frames (good and bad frames) with receive packet size between 8192 and 9216 bytes.

RX_PKT_GT9216

Number of frames (good and bad frames) with receive packet size greater than 9216 bytes.

RX_PKTTOTAL

Total number of frames (good and bad frames) received.

This number is the sum of all received packets regardless of frame length.

RX_OCTETS

Total byte count of packet octets (good and bad frames) received.

RX_PKTOK

Number of good frames received.

RX_UCAST

Number of good unicast frames received.

RX_MCAST

Number of good multicast frames received.

RX_BCAST

Number of good broadcast frames received.

RX_VLAN

Number of good 802.1Q tagged VLAN frames received.

RX_OVERSIZE

Number of good frames received that are greater than CFG_xg_rx_stats_max_frame_len.

RX_TOOLONG

Number of frames (good and bad frames) received that are greater than CFG_xg_rx_stats_max_frame_len.

RX_DISCARD

N/A

The value of this counter is always 0.

RX_UNDERSIZE

Number of good frames received that are less than CFG_xg_rx_stats_min_frame_len.

RX_FRAGMENT

Number of bad frames received that are less than CFG_xg_rx_stats_min_frame_len.

RX_CRCERR_NOT_STOMPED

Number of bad frames received that are not stomped.

RX_CRCERR_STOMPED

Number of bad frames received that are stomped.

RX_INRANGEERR

Number of frames with a length field check error, but no CRC error.

Note Frame length is based on the contents of the ethertype/length field. When the ethertype/length field is less than 0x600, the contents of the field is treated as the length of the frame. This length is compared with the actual frame length. An error is raised when the lengths do not match.

RX_JABBER

Number of bad frames received with frame length greater than CFG_xg_rx_stats_max_frame_len.

RX_PAUSE

Number of good 802.3x MAC control frames received.

RX_USER_PAUSE

Number of good priority flow control frames received.

RX_OCTETSOK

Total byte count of good frames.

MAC Statistics

During normal operation, a Nexus 5000 encounters frames that cannot be forwarded.

Frames are characterized as good frames or bad frames.

•A good frame is a frame that does not have a CRC error or other kind of error

•A bad frame is a frame that has a CRC error or other kind of error

All counters include MAC Control frames where applicable.

Handling CRC errors

When a CRC error is seen in the FCS on a cut-through port, the Rx CRC counter of the show interface command is incremented. However, the frame cannot be dropped because the FCS is at the end of the Ethernet frame on the wire.

The egress interface increments a Tx CRC error and it propagates through to the next device in the path.

You can use the show hardware internal gatos counters interrupt match stomp command to determine if the Nexus 5000 is propagating CRCs or generating them.

•If stomp values exist, they should have matching CRC values on that interface.

•If Rx CRC values exist, then you know it entered the switchport with the error already. You can move on to the connected device to trace it back.

MTU violation

The Nexus 5000 is a cut-through switch at 10 Gb/s. This means that an MTU can be checked, but the frame will already be transmitting before the length is known. Therefore, the frame cannot be dropped. The frame is truncated after the MTU is reached and the CRC value is stomped. The ingress interface increments an Rx Jumbo and the egress interface will increment a Tx CRC and a Tx Jumbo.

•If jumbo frames are seen with the show interface or the show hardware internal gatos port ethernet 1/1 counters rx commands, this is not an indication that the frames are being dropped. A jumbo frame is just an Ethernet frame, greater than 1500 bytes, that was received or transmitted.

•The <b>show queuing interface <i>ex/y</i></b> command shows the current configured MTU (per class).

•A drop due to an MTU violation can be seen with the show hardware internal gatos counters interrupt match mtu* command.

•A counter that matches the Gatos number and fw_instance from the show hardware internal gatos port ethernet 1/1 | include instance|mac command is the indicator that an MTU violation has taken place and that the frame has been stomped.

Queue is full

When a queue is full, you need to increment discards in the respective queue on the ingress interface.

Example:

 switch# show queuing interface ethernet 1/1
 Ethernet1/1 queuing information:
    TX Queuing
      qos-group  sched-type  oper-bandwidth
          0       WRR             50
          1       WRR             50
    RX Queuing
      qos-group 0
      q-size: 243200, HW MTU: 1600 (1500 configured)
      drop-type: drop, xon: 0, xoff: 1520
      Statistics:
          Pkts received over the port             : 0
          Ucast pkts sent to the cross-bar        : 0
          Mcast pkts sent to the cross-bar        : 0
          Ucast pkts received from the cross-bar  : 0
          Pkts sent to the port                   : 0
      <b>    Pkts discarded on ingress               : 0 </b>
          Per-priority-pause status               : Rx (Inactive), Tx
 (Inactive)
      qos-group 1
      q-size: 76800, HW MTU: 2240 (2158 configured)
      drop-type: no-drop, xon: 128, xoff: 240
      Statistics:
          Pkts received over the port             : 0
          Ucast pkts sent to the cross-bar        : 0
          Mcast pkts sent to the cross-bar        : 0
          Ucast pkts received from the cross-bar  : 0
          Pkts sent to the port                   : 0
      <b>   Pkts discarded on ingress               : 0 </b>
          Per-priority-pause status               : Rx (Inactive), Tx
 (Inactive)
    Total Multicast crossbar statistics:
      Mcast pkts received from the cross-bar      : 0

SFP validation failed error message

The "SFP validation failed" error message occurs.

Possible Cause

This error message might occur when a 1-Gigabit SFP transceiver is inserted into a port without configuring the interface speed to 1000 mb.

By default, all ports of a Cisco Nexus 5000 switch have an interface speed of 10 Gigabits.

Solution

Set the interface speed to 1000 mb.

Possible Cause

This error message might occur when a Fabric Extender Transceiver (FET) SFP is inserted into a non-fex-fabric mode port.

Solution

FETs are only supported on fex-fabric port connections when connecting a Cisco Nexus 2000 FEX to it's parent Cisco Nexus 5000 switch. The switch port on the parent switch must be enabled for fex-fabric mode with the switchport mode fex-fabric command.

Cannot create private VLAN (PVLAN)

The private VLAN (PVLAN) cannot be created.

Possible Cause

The private-vlan feature is not enabled.

Solution

The private-vlan feature must be enabled prior to PVLAN configuration, which makes the PVLAN command available. Use the show feature command to determine which features are enabled.

Example:

 switch(config)# feature private-vlan
 switch(config)# show feature
 Feature Name          Instance  State  
 --------------------  --------  --------
 tacacs                1         disabled
 lacp                  1         enabled
 interface-vlan        1         enabled
 private-vlan          1         enabled
 udld                  1         enabled
 vpc                   1         enabled
 fcoe                  1         disabled
 fex                   1         enabled

Cannot create SVI

The SVI cannot be created.

Possible Cause

The interface-vlan feature is not enabled.

Solution

The interface-vlan feature must be enabled before configuring the SVI. Use the show feature command to determine which features are enabled.

Example:

 switch(config)# feature interface-vlan
 switch(config)# show feature
 Feature Name          Instance  State  
 --------------------  --------  --------
 tacacs                1         disabled
 lacp                  1         enabled
 interface-vlan        1         enabled
 private-vlan          1         enabled
 udld                  1         enabled
 vpc                   1         enabled
 fcoe                  1         disabled
 fex                   1         enabled

Cannot create VLAN

The VLAN cannot be created.

Possible Cause

All VLAN resources are exhausted.

Solution

For the Nexus 5000, the maximum number of active VLANs and VSANs per switch is 512 (31 reserved for VSAN; remainder reserved for VLAN). Use the show resource vlan command to determine the number of available VLANs.

Example:

 switch(config)# show resource vlan
      Resource               Min       Max      Used    Unused     Avail
     -----------            -----     -----    ------  --------   -------
      vlan                16       512        25         0       487

Configuring interface to access port does not allow VLAN <###> to go through

After configuring an interface to access a port for allowing VLAN <###>, the VLAN <###> does not go through.

Possible Cause

The VLAN was not created.

Solution

In NX-OS, configuring with the switchport access vlan <###> command on an interface does not automatically create VLAN <###>. You must specifically create VLAN <###> using the vlan <###> command. Use the show vlan command to determine if VLAN <###> exists. If it does not exist, then use the vlan <###> command to create the VLAN.

Interface VLAN is down

The interface VLAN is down.

Possible Cause

The VLAN was not created.

Solution

Although VLAN <###> is not yet created, the NX-OS allows the configuration of the interface vlan <###>. As a result, the interface vlan <###> does not come up. Use the show vlan command to determine if VLAN <###> exists. If it does not exist, use the vlan <###> command to create the VLAN. After the VLAN is created, you must bounce the interface VLAN to have it come up.

Example:

 switch(config)# interface vlan 600
 switch(config-if)# no shutdown
 switch(config-if)# show interface vlan 600 brief
 -------------------------------------------------------------------------------
 Interface Secondary VLAN(Type)                    Status Reason                
 -------------------------------------------------------------------------------
 Vlan600   --                                      down   other              
 switch(config)# show vlan id 600
 VLAN 600 not found in current VLAN database
 switch(config-if)# vlan 600
 switch(config)# show vlan id 600
 VLAN Name                             Status    Ports
 ---- -------------------------------- --------- -------------------------------
 600  VLAN0600                         active    Po1, Po11, Po30, Po31
 switch(config-if)# interface vlan 600
 switch(config-if)# shut
 switch(config-if)# no shutdown
 switch(config-if)# show interface vlan 600 brief
 -------------------------------------------------------------------------------
 Interface Secondary VLAN(Type)                    Status Reason                
 -------------------------------------------------------------------------------
 Vlan600   --                                      up     --      
Possible Cause

VLAN was suspended by the vPC configuration on the Nexus 5000 pair.

Solution

Show that the vPC consistency parameters are global and make sure that the VLAN was not suspended. Otherwise, fix the configuration mismatch on the Nexus 5000 pair:

Example:

 switch# sh vpc consistency-parameters global
     Legend:
         Type 1 : vPC will be suspended in case of mismatch
 Name                        Type  Local Value            Peer Value            
 -------------               ----  ---------------------- -----------------------
 QoS                         1     ([], [3], [], [], [],  ([], [3], [], [], [],
                                   [])                    [])                  
 Network QoS (MTU)           1     (1538, 2240, 0, 0, 0,  (1538, 2240, 0, 0, 0,
                                   0)                     0)                  
 Network Qos (Pause)         1     (F, T, F, F, F, F)     (F, T, F, F, F, F)  
 Input Queuing (Bandwidth)   1     (50, 50, 0, 0, 0, 0)   (50, 50, 0, 0, 0, 0)
 Input Queuing (Absolute     1     (F, F, F, F, F, F)     (F, F, F, F, F, F)  
 Priority)                                                                    
 Output Queuing (Bandwidth)  1     (50, 50, 0, 0, 0, 0)   (50, 50, 0, 0, 0, 0)
 Output Queuing (Absolute    1     (F, F, F, F, F, F)     (F, F, F, F, F, F)  
 Priority)                                                                    
 STP Mode                    1     Rapid-PVST             Rapid-PVST          
 STP Disabled                1     None                   None                
 STP MST Region Name         1     ""                     ""                  
 STP MST Region Revision     1     0                      0                    
 STP MST Region Instance to  1                                                
  VLAN Mapping                                                                
 STP Loopguard               1     Disabled               Disabled            
 STP Bridge Assurance        1     Enabled                Enabled              
 STP Port Type, Edge         1     Normal, Disabled,      Normal, Disabled,    
 BPDUFilter, Edge BPDUGuard        Disabled               Disabled            
 STP MST Simulate PVST       1     Enabled                Enabled              
 Allowed VLANs               -     1-2                    1-2                  
 Local suspended VLANs           2                      -                    
 switch# 

VLAN cannot be created

A VLAN cannot be created.

Possible Cause

An internal VLAN range is used.

Solution

Use a VLAN number that is not being reserved for internal use.

Nexus 5000 does not have the same VLANs as switch running VTP server

VLANs for the Nexus 5000 are not the same as for the switch running the VTP server.

Possible Cause

The Nexus 5000 currently supports VTP only in transparent mode (4.2(1)N1(1) and later releases).

Solution

This situation indicates that VLANs must be configured locally. However a VTP client and server can both communicate through a Nexus 5000 by using the following commands:

 switch(config)# feature vtp
 switch(config)# vtp mode transparent
 switch(config)# exit
 switch# show vtp status

Monday 2 February 2015

Multicast traffic is being flooded in a VPC setup

In a VPC setup multicast traffic is being flooded.
Possible Cause
IGMP snooping is disabled on one of the switches.
Solution

Enable IGMP snooping on both switches.

Multicast data traffic not received when host is registered for group

Multicast data traffic is not received when the host is registered for the group.
Possible Cause
A bug may exist in exist in the communication between the IGMP and FWM processes.
Review the output from the following commands:
•show ip igmp snooping groups vlan 1001
•show mac address-table multicast vlan 1001 igmp-snooping
•show platform fwm info vlan 1001 all_macgs verbose
Solution

Perform a shut/no-shut operation on the host interface and send the join again.