Category: Equipment and tools

For a shorter update procedure guide check abbreviated article: Short list of upgrade steps without extensive explanations “Cisco Catalyst 6880-X VSS ISSU Upgrade Steps“

Intro

Cisco spoiled us over the years with great and detailed documentation on each technology and hardware component they support. Still, I managed to find a part where documentation is not detailed enough to give you definite number of steps to get things done.

While preparing for software upgrade of Cisco Catalyst 6880-X VSS cluster I stumbled on one of the first examples of outdated and vague procedure for upgrade of Cisco device. Here is my successful ISSU (In-Service Software Upgrade) procedure which I done few days ago. I hope it will help you avoid sweating and hoping that you typed the right thing on a VSS cluster that should not go down at any point 🙂

I included an Acronym Guide at the bottom of the post to guide you trough VSS, ISSU, Cluster, and other mentioned abbreviation which are not described in details here

In my case the environment was Catalyst 6880-X and four 6800ia Fabric Extenders FEX. The same procedure is valid for more on for no FEX extenders.

Cisco Catalyst 6880-X VSS

Get the info on which IOS version is supported to be upgraded with ISSU

Not all IOS images can be upgraded to new IOS versions using In Service procedure to avoid network traffic downtime. In order to get things working, you need to get into Cisco docs and find ISSU supported upgrade matrix document.

This is a short version without comments and explanations for those that need to get things done quickly without reading through my extensive waffle.

For detailed update procedure with all the explanations check extended article: “ISSU Upgrade of Cisco Catalyst 6880-X VSS cluster and its four 6800ia FEX extenders“

Let’s start!

1. Get the info on which IOS version is supported to be upgraded with ISSU

Google for ISSU or EFSU IOS upgrade support or use this Cisco doc “SX_SY_EFSU_Compatibility_Matrix1” to select supported IOS for ISSU upgrade from your current version.

2. Upload IOS to both Chassis

copy ftp://admin:[email protected]/c6880x-adventerprisek9-mz.SPA.151-2.SY7.bin bootdisk:

and same for slavebootdisk:

As you can see from my article list, I’m going through some VRF configuration in the last few weeks 🙂

I ran into this today and it sounded interesting enough to share it with you. The issue with TFTP IOS image copy to flash when having all interfaces in specific VRF and no interface in Global Routing Table.

Long story short, you kick in this command for normal IOS download to the router:

R1#copy tftp://10.10.10.11/c890-universalk9-mz.154-3.M5.bin flash:
Destination filename [c890-universalk9-mz.154-3.M5.bin]? 
Accessing tftp://10.10.10.11/c890-universalk9-mz.154-3.M5.bin...
%Error opening tftp://10.10.10.11/c890-universalk9-mz.154-3.M5.bin (Timed out)

…and it isn’t working of course.

Network Packet Generator or Network Traffic Generator is a tool every network engineer will sooner or later want to use. Here’s one I found and it’s great!

First time I saw an Ethernet frame in details on my CCNA class back in 2010 I immediately got the idea about generating some packets on my own. It was logical next step to ask myself: “Ok, so how can I make one of those and see what happens when I send it out on the network?”. I was not really sure that there is a tool that would make it possible.

Don’t get me wrong, net surfers don’t need this!

I mean, Yeah, ok, I know I am generating a lot of packets right now by not doing anything because my Mac is surely syncing who knows what across the Internet. The thing is, you are not really in control of your machine’s applications network layer which is talking across the network, so you can not really make much changes in frames header format and whats inside headers. Apps are sending out standard packets with standardised header format (flags, addresses etc.). The thing that we control is only the data that we send, the payload of those packets, headers, they do their thing to make the transfer possible.

You can control the packet source IP address of course, maybe MAC address sometimes on some Linux machines by editing your NIC configuration but I am sure you know that if you are still here 🙂

Network engineers do need this!

But I am a network engineer and I usually want:

• to test something
• make something that does not exist so far or is not standardised.
• I want to try to create a new protocol that will talk using IP.
• I want to change protocol implementation bugs from some vendor.
• I need a way to create test packets to investigate strange firewall packet drops.
• I want to see what will happen if some packets header flags are changed in strange way, how will that affect the packet forwarding.
• I want to send stuff across the network and see what happens.
• I need other stuff too.

As this is networking blog I will focus mostly on the usage of CAM and TCAM memory in routers and switches. I will explain TCAM role in router prefix lookup process and switch mac address table lookup.

However, when we talk about this specific topic, most of you will ask: how is this memory made from architectural aspect?

How is it made in order to have the capability of making lookups faster than any other hardware or software solution? That is the reason for the second part of the article where I will try to explain in short how are the most usual TCAM memory build to have the capabilities they have.

CAM and TCAM memory

When using TCAM – Ternary Content Addressable Memory inside routers it’s used for faster address lookup that enables fast routing.

In switches CAM – Content Addressable Memory is used for building and lookup of mac address table that enables L2 forwarding decisions. By implementing router prefix lookup in TCAM, we are moving process of Forwarding Information Base lookup from software to hardware.

When we implement TCAM we enable the address search process not to depend on the number of prefix entries because TCAM main characteristic is that it is able to search all its entries in parallel. It means that no matter how many address prefixes are stored in TCAM, router will find the longest prefix match in one iteration. It’s magic, right?

Image 1 shows how FIB lookup functions and points to an entry in the adjacency table. Search process goes through all entries in TCAM table in one iteration.

Router

In routers, like High-End Cisco ones, TCAM is used to enable CEF – Cisco Express Forwarding in hardware. CEF is building FIB table from RIB table (Routing table) and Adjacency table from ARP table for building pre-prepared L2 headers for every next-hop neighbour.