Cisco Troubleshooting Commands – 1

1.  Show interface counters protocol status

-Description

This command is an unpublished Cisco command that is available in ver 12.2 and above and shows us the interface and protocol status. As you can see below, each interface is listed with its corresponding list or running protocols.

-Uses

This command can be used to verify that interfaces are participating in the protocols you require them in. A good example would be Spanning Tree. If you have a protocol not participating in Spanning Tree “Fa0/7 below” it could be putting the vlan it participates in at risk for a loop. In this case, the port is not connected.

CA-A31-43W77-36#Show interfaces counters protocol status

Protocols allocated:

Vlan1: Other, IP

Vlan112: Other, IP, ARP

Vlan163: Other, IP, ARP

Vlan251: Other, IP, ARP

FastEthernet0/1: Other, IP

FastEthernet0/2: Other, IP, Spanning Tree

FastEthernet0/3: Other, IP, Spanning Tree

FastEthernet0/4: Other, IP, Spanning Tree

FastEthernet0/5: Other, IP, Spanning Tree

FastEthernet0/6: Other, IP, Spanning Tree

FastEthernet0/7: Other, IP

FastEthernet0/8: Other, IP, Spanning Tree

FastEthernet0/9: Other, IP, Spanning Tree

SG2#show interface counters protocol status

Protocols allocated:

FastEthernet0/0: Other, IP

FastEthernet1/0: Other, IP, ARP, CDP

FastEthernet1/1: Other, IP, ARP, CDP

Loopback1: Other, IP

2. Show interface accounting

-Description

This command gives you a basic break down of each interface and the associated counters for each; broken down by protocol.

-Use

This command gives you the ability to check the detailed information for each interface and allows you to see packets incrementing on a per-protocol basis.

SG2#show interface accounting

Interface FastEthernet0/0 is disabled

FastEthernet1/0

Protocol Pkts In Chars In Pkts Out Chars Out

Other 2 154 139 8340

IP 527 38100 572 45474

ARP 1 60 5 300

CDP 23 7705 24 7992

FastEthernet1/1

Protocol Pkts In Chars In Pkts Out Chars Out

Other 2 154 139 8340

IP 0 0 191 15942

ARP 1 60 5 300

CDP 23 7705 24 7992

Loopback1

Protocol Pkts In Chars In Pkts Out Chars Out

No traffic sent or received on this interface.

Loopback15

Protocol Pkts In Chars In Pkts Out Chars Out

IP 2 104 2 104

3. Show interfaces summary

-Description and Use

This command allows you to see if there are any dropped packets on your interfaces all at one time. It can be used when troubleshooting a link that is exceeding its available bandwidth or something along those lines.

CA-PR-35C51-R1#sho int sum

*: interface is up

IHQ: pkts in input hold queue IQD: pkts dropped from input queue

OHQ: pkts in output hold queue OQD: pkts dropped from output queue

RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)

TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)

TRTL: throttle count

Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL

———————————————————————

Vlan1 0 0 0 0 0 0 0 0 0

* Vlan5 0 0 0 0 0 0 0 0 0

* Vlan6 1 0 0 0 2000 1 0 0 0

Vlan13 0 0 0 0 0 0 0 0 0

* Vlan15 0 5 0 0 0 0 0 0 1

* Vlan25 0 0 0 0 0 0 0 0 0

* Vlan26 0 0 0 0 0 0 0 0 0

* Vlan27 0 0 0 0 1000 1 8000 16 0

* Vlan32 0 25 0 0 114000 188 0 0 1

* Vlan37 0 0 0 0 0 0 0 0 0

* Vlan39 0 0 0 0 0 0 0 0 0

* Vlan46 0 17 0 0 6000 9 2000 2 1

* Vlan50 0 17 0 0 682000 166 337000 69 1

4. Show interface counters

Description – this command gives you the packet count for each interface and it’s associated IN and OUT count.

Use – This can allow you to look incrementing packets for the entire device without having to go into each interface on its own. It is also nice because it breaks the packets down by type. So if you wanted to check and make sure you are receiving Multicast packets on ports 2, 4, 5 you can watch them all at once.

CA-A31-36#sho int counters

Port InOctets InUcastPkts InMcastPkts InBcastPkts

Fa0/1 0 0 0 0

Fa0/2 9554114 90717 23 1054

Fa0/3 4344241109 41095442 0 138

Fa0/4 2597053412 28027665 87 93379

Fa0/5 5027141741 38715811 62 107699

Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts

Fa0/1 0 0 0 0

Fa0/2 203190126 156315 57080 7738

Fa0/3 41398983291 303765483 32142064 35229531

Fa0/4 44024460395 69378044 34255762 7820553

Fa0/5 405998091547 2215247117 34245798 6254554

CCIE Pursuit Link

I’m an idiot.  So when I built the blogroll I apparently put in the CCIE Pursuit link in wrong.  I fixed it.  As it turns out, it’s one of the best blogs out there, so check it out when you have time.

~Brent

Goodbye To You EIGRP Neighbor

So I ran into this inform message today that I had never seem before:

As it turns out, an improvement in 12.3(14) added the Goodbye message to let EIGRP peers know the local process was being brought down.  A note in the Cisco documentation indicated that if there is a device running an earlier version of code and it is peering with the device that broadcasts this message, it will be read as a K-Value mismatch.  However, since the Goodbye message doesn’t do anything other than give peers notice to synchronize the topology without waiting for the hold-down to expire, it is not a big deal if a router with an older rev receives this message.

CCIE R&S Lab Study Update – 23 Jan

This was a horrible week for studying.  Workload was a monster, my equipment crapped out, & Dynamips is running poorly on my Macbook.  To top it off, as of today I am 90 days out.  So, the next three months are looking tougher.  I have a good supporting cast at home and at work, so I am very fortunate in that regard.  Also, the study group has agreed to give a break on the quality and frequency of my study group diatribe.  We are going to try more of a discussion group format.  As it turns out though, everyone in the group is getting smarter and thinking in different ways.  That is very nice to see.

That said.  I am moving with a sense of urgency since January was a lot less productive in the CCIE arena than I wanted it to be.  IE will be rolling out the Poly Labs in the next couple of weeks which I am really looking forward to.  Also, I am going to start participating in the Open Lecture Series.  Next week they will be covering Advanced OSPF Design and CCIE Lab strategy.

So, an inventory of accomplishments tells me that I missed big on lab time, but did alright in book study this week.  That always seems to be the case though.  A shift to focusing on flight time is my main priority right now.

Lab Execution Question

Lab 9 Task 4.8 Problem Identified

IE-WB3:Lab 9 4.8

I am having problems configuring an IPIP tunnel between Sw1 and R5 on my personal equipment. I have built the tunnel with IPs advertised into Area 0, and have ensured that the tunnel destinations are not learned via OSPF

I am pretty sure that this is an issue with my equipment. When I throw down the same configuration into Dynamips it works and switch 1 learns the Area 0 routes from R5.

Is there something Im missing in the configurations on the real equipment?

CCIE R&S Lab Study Update 16 Jan 2009

CCIE R&S Lab Update 16 Jan 2009

This weeks progress

• Completed one of the planned Core Labs

• • Lab 1

• • No Questions

• Lots of review scenarios are needed

• • OSPF Route Filtering

• • OSPF Stub Area rules

• • BGP Best Path Selection rules

• • Regular Expressions

• • TCL Scripts

• • Redistribution

• Worked through half of the Bridging & Switching section of IE-WB1

• Not making as much progress as I would like since work has been creeping into personal time

• • Work comes first

• Goals for next week

• • Complete Three Core Labs

• • Complete IE-WB1 Bridging and Switching & Frame-Relay and IE-WB1 V5 Bridging and switching

Other news of the week

• Cisco will be adding questions to the beginning of the exam.  It’s intended to add security to test, because apparently people are cheating somehow.  I have heard of this before from groupstudy, but it would seem that you would have to put the same amount of effort in cheating that you would in actually studying.  And then there’s that whole thing of having to back up the credential with actual work.

• This is sorta the reason why we started the study group.

• • First, I had read updates last year indicating that they were trying interviews out in Beijing and so this is no surprise

• Another reason why this feeds into why we started this group

• • I have failed the lab exam before

• • This time I want to make sure that I know the information, beyond the CLI

• • I want to be able to explain the technology in my own words

• • This is why we post blog articles and videos and as it turns out, it’s hard, and I am not very good at it. Which tells me that I have a lot of work to do

So I am extending an invitation to the community.  If you want to post an example of an open ended question or a video or blog entry of what your response to an open ended question would be and do not want the headache of maintaining your own blog or youtube account.  My email address is pwcs.dia@gmail.com and I will post your stuff so that we can critique each other and hopefully foster an environment for active learning.

Internetwork Expert has posted a list of example questions.  Those can be found here.

That’s it for this week… Comments and heckling welcome…

The Ladies & The Beast

These are our new ladies for the WAN edge, currently in our fit up room

2×7206 NPE-G2

And here is the beast that will hopefully see me to my lab exam.

Switchports

Switchport Presentation Transcript

Today we will be doing a general overview of the Cisco Catalyst Switchport configuration options and some of the technical details associated with the configuration of the device ports.

We will be discussing the operational modes and what configuration options can be used to end up in a particular operational mode

we will be discussing the trunk encapsulation types and the mechanics of that

we will also briefly go over DTP and its operational impact on the switchport

we will be going over etherchanel and qinq tunneling at a later date

If you are not very familiar with the Cisco catalyst switchport you may be led to believe that the operational states of the switchport leave you with three configuration options for the interface

There are, however, many ways to end up in these operational end states

For example;

An access interface is one that services one and only one VLAN.  As far as the switchport is concerned, it is connected to a station end and considers the distant to be DTE.  There is an instance where an access interface can be configured to handle multiple VLANS.  this is referred to as multi-vlan access interface and is used with voice vlan configurations.  We will not be discussing the Voice VLAN in this presentation.

To statically configure a switchport as an access interface, you would issue the sw m access command in interface configuration mode

Interestingly, there are three other ways a switchport can become an access interface.

The dynamic assignment of VLAN information to an access interface can be done two different ways.  One way is with VMPS or VLAN management policy server.  VMPS uses UDP VQP (VLAN Query Protocol) to communicate VLAN information to the Cisco Catalyst Device.  This VLAN assignment is based on the MAC address of the station end.  An add-on to ACS also exists to allow VMPS to assign VLAN based on authentication with ACS.

802.1X/EAP performs also determines VLAN based on user login credentialing.  This requires the use of a RADIUS server, and aaa configuration.  802.1x is commonly used with NAC and WiFi implementations.

The last way an interface can become an access switchport is via DTP.  Even though DTP is dynamic in nature, it is DTP’s inability to form a trunk that defaults the interface into an access configuration.

Trunks can be configured using static methods and by using active or passive dtp configurations.

The interesting thing about static configurations for trunks is that you can choose to statically configure all elements of the trunk or just the encapsulation.

If you choose to statically configure only the method of encapsulation, you choose your encapsulation type by issuing the command sw t e dot/isl.  The remainder of the trunk configuration can then be completed by DTP.

Should you want to statically configure that encapsulation and the operational mode you would first identify the encapsulation type with the above listed command and then statically configure the sw mode to trunk with the interface configuration command sw m t.

It is recommended that you then disable dynamic trunk negotiation by issuing the command sw non.  To reenable DTP issue the command no sw non.

Before exploring the configuration options for switchports further, let’s discuss our two options for trunk encapsulation.  802.1q and ISL.
ISL encapsulation is a Cisco solution used to communicate VLAN information on inter-switch links.  With ISL the entire Frame is encapsulated with 30 bytes of additional overhead in order to communicate the VLAN information.

A closer look at the ISL header identifies this as an 802.2 SNAP header.

ISL uses the link local multicast address 01.00.0c.00.00.00.  When the receiving switch receives this frame it knows by looking at the DA and SNAP value that this is ISL header has data identifying which VLAN the payload belongs to.

Because of the additional overhead of the ISL encapsulation, we can see that the minimum/maximum frame size requirements of ethernet increase over ISL links.

Our other option of trunk encapsulation is with 802.1q.

802.1q is an open standard developed by the 802 working group.

Rather than completely encapsulating the frame with another header, dot1q injects a tag into the frame.

This method greatly reduces the overhead associated with executing configuration at the LLC of the Data-Link.

So what information is kept in the tag?

The 802.1q tag can be broken down into four fields.
- The TPID: Identifies the ethertype of 802.1q/p header or x8100
- The priority field identifies the CoS value or priority assigned (marked) on the customer traffic
- The CFI is a one that identifies whether or not the MAC address is the frame is listed lsb or msb
and finally
the VID field identifies the VLAN of which the payload belongs.

Moving back to configuration of switchport modes.

DTP is a mechanism that allows for the dynamic negotiation of trunks on switchports.

DTP too, uses a SNAP header.

The DA in this case is the general use link-local multicast address used by a number of Cisco protocols, 01.00.0c.cc.cc.cc.  This is used to identify to the receiving device that it is not to forward the frame to any other interface.  For the receiving device to identify which Cisco protocol is in the payload, it looks at the SNAP field of the header.  If the value is 2004, than the payload is DTP.

The configuration of the interswitch links are what determines whether or not DTP negotiates a trunk or defaults to an access interface.  If both endpoints are configured as Dynamic Desirable, a trunk will form.  Should one side be configured as Dynamic Desirable and the other as Dynamic Auto, a trunk will form.  However, if both sides are configured as Dynamic Auto, the interface will default to an access switchport.

It is relevant to note that the default configuration for a 3560 Cisco Catalyst Switchport is Dynamic Auto, out of the box.

We will be discussing the Tunnel configuration in later presentations.