Archive for the ‘OUTPUT-101’ Category

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).

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.

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.

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).

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.

The IP header is defined in RFC 791, includes a 1-byte ﬁeld called the Type of Service (ToS) byte. The ToS byte was intended to be used as a ﬁeld 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) ﬁeld. 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 ﬁeld. 3 bits (23 = 8 ) allowed 8 possible markings.