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 ?

Follow

Get every new post delivered to your Inbox.

Join 1,521 other followers