Archive for the ‘OUTPUT-101’ Category

h1

Troubleshooting MAC-Flushes on NX-OS

January 21, 2013

An interesting client problem in one of our multi-tenant data centers came to my attention the other day. A delay sensitive client noticed a slight increase in latency (20 ms) at very intermittent intervals from his servers in our data center to specific off-net destinations. The increase in latency was localized to the pair of Nexus 7000’s functioning as the core switch layer (CSW) and the layer3 edge for this particular data center. Beyond that all appeared normal on the N7K CSWs.

A TCP dump from a normal trunk interface attached to the N7Ks, showed unicast traffic on the N7K-2 device when the N7K-1 device was setup to receive internet traffic inbound and forward it into the data center client VLANs.  The N7Ks are setup using the Cisco VPC (Virtual Port Channels).

Read the rest of this entry ?

About these ads
h1

Output101- sh run vrf

September 4, 2010

Now that the hard work is behind me, the awesome holiday has past, I can finally get back to all the outstanding fun stuff. That said I have some good half completed posts are on the way :)

I came across the following command browsing the DOC-CD a couple months back, and I have used it ever since.

sh run vrf [vrf-name]

The show running vrf feature provides the option to display a subset of the running configuration on a router that is linked to a VRF instance. It can be used to display the configuration of a specific VRF or of all VRFs configured on a router. The command is unfortunately only available on the more recent IOS versions, but if available makes life easy.

Read the rest of this entry ?

h1

Memory problems

June 6, 2010

From a question on groupstudy; the following output was posted of a Cisco 2600 that did not boot up even after the Flash was upgraded to 32MB??????

System Bootstrap, Version 12.1(3r)T2, RELEASE SOFTWARE (fc1)
 Copyright (c) 2000 by cisco Systems, Inc.
 C2600 platform with 65536 Kbytes of main memory

 program load complete, entry point: 0x80008000, size: 0x1c8a8e4

 Error : memory requirements exceed available memory
 Memory required     : 0x04746F90

 *** System received a Software forced crash ***
 signal= 0x17, code= 0x4, context= 0x80080630
 PC = 0x0, Vector = 0x0, SP = 0x0

 System Bootstrap, Version 12.1(3r)T2, RELEASE SOFTWARE (fc1)
 Copyright (c) 2000 by cisco Systems, Inc.
 C2600 platform with 65536 Kbytes of main memory

 program load complete, entry point: 0x80008000, size: 0x1c8a8e4

 Error : memory requirements exceed available memory
 Memory required     : 0x04746F90

 rommon 1 > dir flash:
 File size           Checksum   File name
 29928068 bytes (0x1c8aa84)  0x6ee9    c2600-adventerprisek9-mz.124-23.bin
 rommon 2 >

What could the problem be?

Read the rest of this entry ?

h1

OUTPUT-101 : Frame-Relay Traffic Shaping

December 24, 2009

Often knowing the necessary show commands is not enough, you need to understand the output.
Here is a good example and breakdown of each of the fields with the command:

show traffic-shape

 VC                      = 'DLCI's'
 Access List             = 'Used to shape traffic of common type for separation'
 Target Rate             = 'CIR in bits'
 Byte-Limit              = 'Bc+Be ie the size the token bucket, express in BYTES'
 Sustain bits/int        = 'Bc value per Tc, (int is short for interval or Tc)'
 Excess bits/int         = 'Be value'
 Interval (ms)           = 'Tc value'
 Increment (bytes)       = 'How many bytes of token replenished each Tc, ie Bc value in bytes'
 Adapt Active            = 'Shows Adaptive shaping has been enabled. If a BECN is received, the flow is throttled back'

What else can be set about the configuration here?
The interface have 3 DLCI’s defined.
DLCI’s 413 and 405 have a CIR of 56k. This was not configured. This is default behaviour. When ‘frame-relay traffic-shaping’ is enabled each DLCI on that interface will be allocated a 56k CIR unless changed. Here it is clear that DLCI 403 has a map-class policy applied.

Oh and Merry Christmas guys :D

h1

Output 101 : BGP AFI/SAFI

November 26, 2009

When BGP peers set up their session between them, they send an OPEN message possibly containing optional parameters.

One optional parameter is capabilities. Possible capabilities are Multiprotocol extensions, route refresh, outbound route filtering (ORF), and so on. When the BGP peers exchange the Multiprotocol extension capability, they exchange AFI and SAFI numbers and thus identify what the other BGP speaker is capable of.

IPv6 in BGP is implementated via Multi-Protocol BGP (MPBGP) (RFC 2283), as is MPLS and VPN’s through two new attributes: MP_UNREACH_NLRI and MP_REACH_NLRI. The first two values in these two attributes contain the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI).

AFI Meaning
1 IPv4
2 IPv6
.
SAFI Meaning
1 Unicast
2 Multicast
3 Unicast and multicast
4 MPLS Label
128 MPLS-labeled VPN

Read the rest of this entry ?

h1

OUTPUT 101- Interface states

September 7, 2009

Sometimes it is necessary to go back to the basics that we have already forgotten. You can identify six possible states in the interface status line of the show interfaces serial output:

  1. Serial x/y is up, line protocol is up
  2. Serial x/y is down, line protocol is down
  3. Serial x/y is up, line protocol is down
  4. Serial x/y is up, line protocol is up (looped)
  5. Serial x/y is up, line protocol is down (disabled)
  6. Serial x/y is administratively down, line protocol is down

Read the rest of this entry ?

h1

Using Netflow’s verbose output with QOS

July 15, 2009

In the previous article I showed how useful Netflow can be, but that is only the beginning. The “verbose” output provides even more useful information, specifically the TOS-Byte. That field is necessary when you want to verify if QOS marking is correctly applied to traffic classes.

But first you have to understand a little about QOS (Quality of Service) and the TOS-byte/DS-Field in the IP header.

The IP header is defined in RFC 791, includes a 1-byte field called the Type of Service (ToS) byte. The ToS byte was intended to be used as a field to mark a packet for treatment with QoS tools. The ToS byte itself was initially further subdivided, with the high-order 3 bits defined as the IP Precedence (IPP) field. Bits 3 through 6 were not used very often, and bit 7 was never defined, so over time the entire ToS byte’s purpose was to hold the 3-bit IPP field. 3 bits (23 = 8 ) allowed 8 possible markings.

Tos-Byte

Read the rest of this entry ?

h1

Using Netflow

July 14, 2009

Ever needed to track specific flow of information or find out what ports a application is using, or verify if your QOS is working correctly? Cisco Netflow is the answer.

NetFlow is a Cisco IOS application that provides a rich set of traffic statistics on packets flowing through the router, both ingress and egress. A NetFlow network flow is defined as a unidirectional stream of packets between a given source and destination. These key fields/statistics define a unique flow:

  • Source IP address
  • Destination IP address
  • Source port number
  • Destination port number
  • Layer 3 protocol type
  • Type of service (ToS)
  • Input logical interface

If a packet has one key field different from another packet, it is considered to belong to another flow. Flows are stored in the NetFlow cache and does does consumes additional memory, but generally this is not to much of a problem. Netflow data could be exported, but here I’ll show how to use it on CLI and how to interpret it.

Read the rest of this entry ?

h1

Output-101: Cisco 3560 feature set upgrade

October 29, 2008

Error: The image in the archive which would be used to upgrade
Error: system number 1 does not support the same feature set.

Cisco it seems included this sanity check,as of 12.2(35), to prevent you from accidentally changing the feature set during a IOS upgrade, not a nice thing to happen on a production switch, when things go belly up.

You will get the above error when upgrading the IOS and changing the feature set. IE  if you upgrade the image from IPBASE 12.2(35)SE5 to ADVIPSERVICESK9 12.2(25)SEE4.

So to bypass this, you can add the /allow-feature-upgrade parameter, to the  archive download-sw command.

Example :

#archive download-sw /overwrite /allow-feature-upgrade tftp:10.1.1.1/c3560-advipservicesk9-tar.122-25.SEE4.tar

If you need more info on how to upgrade the IOS on a Cisco 3560, visit Cisco.

h1

Output-101 : Limit a Debug to an interface

October 17, 2008

Debugging is one of the best tools to use when troubleshooting problems, but also the most dangerous tool if missused in production networks.

By limiting the debug capture only to the interface that you need, instead of all 100+ client interfaces, you mitigate the risk to a reasonable degree.

The following command enables conditional debugs for interface serial1/0. This means that only debugs for ser1/0 are displayed:

Rack1R1#debug interface s1/0
Condition 1 set

Rack1R1#sh debugging
TCP:
TCP Packet debugging is on

Condition 1: interface Se1/0 (1 flags triggered)
Flags: Se1/0

-

Note that the command ‘undebug all’ does not remove conditional triggers, only the normal debugs, ie like below only the the TCP Packet debugging has been removed:

Rack1R1#un all
Port Statistics for unclassified packets is not turned on.

All possible debugging has been turned off
Rack1R1#sh debug

Condition 1: interface Se1/0 (1 flags triggered)
Flags: Se1/0

-

To remove your conditional debug, use the following:

Rack1R1#undebug interface s1/0
This condition is the last interface condition set.
Removing all conditions may cause a flood of debugging
messages to result, unless specific debugging flags
are first removed.
Proceed with removal? [yes/no]: yes
Condition 1 has been removed

Rack1R1#sh debug
Rack1R1#

Add to FacebookAdd to NewsvineAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to Ma.gnoliaAdd to TechnoratiAdd to Furl

h1

Output-101: BGP-3-NOTIFICATION

September 28, 2008

Error log:

%BGP-3-NOTIFICATION:received from neighbor 196.7.8.9 2/2 (peer in wrong as) 2 bytes 0064

Explanation:

The Obvious is true, a wrong ASN is configured, but there is more detail here. “2 bytes 0064″ : the 0064 is the received ASN in HEX, ie 0x0064 in HEX = 100 decimal.

The local router is expecting Neighbor 196.7.8.9 to come from a specific ASN, not ASN 100. Have a look at the “neighbor {IP} remote-as” command to confirm it is set correctly. If confederations are used, make sure your confederation-id is correct between the two EBGP peers.

Follow

Get every new post delivered to your Inbox.

Join 1,500 other followers