Category: Configuration

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.

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.

CoPP – Control Plane Protection or better Control Plain Policing. It is the only option to make some sort of flood protection or QoS for traffic going to control plane.

In the router normal operation the most important traffic is control plain traffic. Control plane traffic is traffic originated on router itself by protocol services running on it, destined to other router device on the network. In order to run properly, routers need to speak with each other. They speak with each other by rules defined in protocols and protocols are running in shape of router services.

Examples for this kind of protocols are routing protocols like BGP, EIGRP, OSPF or some other non-routing protocols like CDP etc..

When router is making BGP neighbour adjacency with the neighbouring router, it means that both routers are running BGP protocol service on them. BGP service is generating control plane traffic, sending that traffic to BGP neighbour and receiving control plane traffic back from the neighbour.

Usage of Control Plane Protection is important on routers receiving heavy traffic of which to many packets are forwarded to Control Plane. In that case, we can filter traffic based on predefined priority classes that we are free to define based on our specific traffic pattern.

This is really cool feature on Cisco router not usually mentioned until you dig a little deeper inside Cisco IOS. But first a bit of theory…

What is TCP SYN flood attack

TCP 3-way handshake

SYN flood DoS attack happens when many sources start to send a flood of TCP SYN packets usually with fake source IP.

This attack uses TCP 3-way handshake to reserve all server available resources with fake SYN requests not allowing legitimate users to establish connection to the server. SYN packet is the first step in TCP 3-way handshake. This is the step where client sends connection synchronization request to the server. Server receives TCP SYN from client, the server replies back with SYN ACK. SYN ACK acknowledges synchronization request.

In that moment server is waiting the client to complete the handshake by sending an ACK back to server to acknowledge the SYN ACK. With this third step, TCP session is successfully established and communication between server and client begins.

If the ACK is not received from the client side, server will wait for it for some time and then the session will timeout and get dropped. When the server deletes the session, his resources will be released.

TCP SYN flood attack

TCP SYN flood attack sends first packet of 3-way handshake SYN packet to server many times to cause the server to allocate resources for sessions that will never become established. It means that client who is attacking will never respond to server SYN ACK and the session will remain on the second step of 3-way.