This is a interesting but a trivial post. Everybody know about the interface command “load-interval” that changes the time period over which the interface packet-rate and throughput statistics are averaged.
I discovered an addition to this command on the Nexus the other day while poking around. NX-OS allows multiple counter intervals to be configured on the same interface. This allows different sampled intervals to be listed at the same time.
I previously wrote a post about the Nexus Roles and how they integrate with a TACACS server.
Cisco Documentation shows the following format to issue multiple roles from a TACACS/RADIUS server.:
We are using Shrubbery TACPLUS, instead of the Cisco ACS software. Last week I noticed that only one role was assigned when multiples should be assigned. Multiple roles are required when using one TACACS server to issue roles for VDC and non-VDC Nexus switches since they need different default User-Roles.
This was tested on a Nexus 5000, a Nexus 7000 and VDC on the same Nexus 7000. Different codes were tried. This was not a NX-OS bug.
Upon further investigation it was obvious, that the syntax above as provided by Cisco was specific their TACACS software, being the ACS software. But I still required multiple Roles to be assigned for my single TACACS configuration to work across multiple Nexus devices. First attempt was the lazy method. Ask uncle Google for any such encounters with a solution. That yielded no practical results. I then contacting Shrubbery for the solution, after that it became clear that possibly nobody else have experienced this problem before.
So the hunt began to find out exactly what was so different in the AAA response from the Cisco ACS software to the TACPLUS software that it did not yield the required results.
The Cisco Nexus Series platform has some good things going. Having spent much of my time recently using them, I have come to appreciate some very neat improvements NX-OS is offering over standard IOS. For the most part driving NX-OS is very similar to IOS, but it’s been greatly improved.
One such example is the output from the most used IOS command “show ip int brief”, which on NX-OS only shows ‘IP’ (being layer 3) interfaces. To see the brief state of all types of interfaces use “sh int brief” instead.
N5K-2(config)# sh ip int brief
IP Interface Status for VRF "default"(1)
Interface IP Address Interface Status
Vlan19 10.1.19.6 protocol-up/link-up/admin-up
Vlan22 10.1.22.6 protocol-up/link-up/admin-up
N5K-2(config)# sh int brief
Ethernet VLAN Type Mode Status Reason Speed Port
Interface Ch #
Eth1/1 1 eth trunk up none 1000(D) 51
Eth1/2 22 eth access up none 10G(D) -
Eth1/3 1 eth trunk down SFP not inserted 10G(D) 50
Eth1/4 1 eth trunk down SFP not inserted 10G(D) 50
Eth1/5 1 eth trunk down SFP not inserted 10G(D) -
Eth1/6 19 eth access down SFP not inserted 10G(D) -
Eth1/7 1 eth trunk down Link not connected 10G(D) 5
Eth1/8 1 eth trunk down Link not connected 10G(D) 5
Eth1/9 1 eth fabric down Administratively down 10G(D) 9
Eth1/10 1 eth fabric down FEX identity mismatch 10G(D) 7
Eth1/11 1 eth fabric down vpc peerlink is down 10G(D) 34
Eth1/12 1 eth fabric down SFP not inserted 10G(D) 12
Eth1/13 1 eth fabric up none 10G(D) 15
Eth1/14 1 eth fabric down Administratively down 10G(D) 9
November last year, a pair of Cisco Nexus 5010 switches, suddenly started rebooting randomly without user intervention. Since these boxes were a front to a VM environment, stability were of urgent concern. But in order to stabilize the environment, the root cause of the reboots had to be isolated, and quickly.
The Cisco Nexus platform might not be as mature as many would like, but it is quickly becoming a very needed switch in Next-Generation datacenters. Of the things I like most about the Nexus boxes are the readily available local reporting and intuitive system checks. Obviously there are many other features which is making the platform so popular. I’ll cover some of these in time.
Coming back to the rebooting issue. Unlike IOS devices that looses all local logging info, unless a crash dump was saved to NVRAM, the Nexus writes most of its log information to disk. Thus even after the reboot, you have all the information. Continue reading “Troubleshooting random Nexus reboots”→
I frequently use my iPad to console onto routers as per my earlier post. But there are so much more functionality here. The iPhone can be used as a Out-of-Band device.
Why? Because it occasionally happens that a router has no device near it that can provide console access. And if you doing risky changes, this beats having to sit next to the device while doing the changes.
A serial connector cable (30-pin Apple to male DB9 pin RS-232).
A rollover cable.
A jailbroken iPhone.
Software that supports serial communication.
Inbound connectivity to iPhone Sim.
Steps 1-5 is the same as my previous post. Only difference is with step-4. The app iSSH is not needed here as the SSH connection will not be made locally from the device. So once SSH is loaded via Cydia move along to Step-5.
The last step required is having inbound access to the cellular data IP on your iPhone. This varies between cellular providers. Some providers block inbound access, others allow it by default. If your cellular provider is blocking inbound access, you will have to request them to allow it for you SIM.
All that is left to do, is plugging your phone into the distant router, (preferably locked in the cabinet, to prevent it from being stolen). From you desk SSH to the iPhone and use Minicom to reverse console into your router.
A quick post. I’ve had many requests from guys asking details surrounding my studies and preparation. As always I am more than happy to help and aid other candidates where I can. After all I did not get this far on my own.
So first off I have create a new page called CCIE BOOKLIST (on the right) of books I bought and used for both the R&S and SP. I have added a small review of most of them.
In the next week or two, I will post the methods I used to get through the theory, labs, my approach and lab strategies etc.
I find using a terminal server to connect to routers while labbing very efficient. I personally don’t like having 10 windows open when configuring devices. I tried it back when I started studying for my R&S but found I made more errors than worth. Since then I have gotten used to jumping between terminal sessions on one screen.
Like most I used Dynamips when I studied for the SP. I built a quad-core PC at home with Ubuntu. My laptop at the time was running Windows XP, but during my 4 months trial I got a Mac Book Pro. Obviously I had to study whenever I had time regardless of the platform. So I configured the same setup across all three platforms.
Configuring a terminal server in Dynamips requires a real interface to be bridged to a virtual router interface. This is done by using a loopback interface. This is done very differently on the three platforms:
Windows XP (32-bit)
Ubuntu 9.10 (64-bit)
Snow Leopard 10.6 (32/64-bit)
The .NET file I used for the Internetwork Expert SP labs are at the bottom of the article.
Greg Mahlknecht has drawn a map of the undersea communications infrastructure around the world using Microsoft Bing. I’d say it is pretty good. It gives you a good visual idea how the continents are interconnected.
How does one localise the errors on the ATM trunk to a specific VC?
Assume for a second that the following interface ATM1/0 is terminating multiple VCs (Virtual Circuits), and when you issue the following command you see CRC errors. How would you know which one of VCs are the problem child?
#show interfaces atm 1/0
ATM1/0 is up, line protocol is up
Hardware is ENHANCED ATM PA Plus
Description: bob's ATM
MTU 4470 bytes, sub MTU 4470, BW 149760 Kbit, DLY 80 usec,
reliability 255/255, txload 7/255, rxload 5/255
Encapsulation ATM, loopback not set
8191 maximum active VCs, 16 current VCCs
VC Auto Creation Disabled.
VC idle disconnect time: 300 seconds
Signalling vc = 1, vpi = 0, vci = 5
UNI Version = 4.0, Link Side = user
0 carrier transitions
Last input 00:00:01, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:23:50
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1115
Queueing strategy: Per VC Queueing
30 second input rate 1966000 bits/sec, 1032 packets/sec
30 second output rate 3226000 bits/sec, 1025 packets/sec
885563 packets input, 129820445 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
350 input errors, 350 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort '<----Not cool'
1373823 packets output, 456299872 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Apologies for the long absence from posting. I find myself without any hours left in a day before I got to everything I wanted to do. And before you know it, more than a month has gone past.
In my previous post I presented a quick solution to an Out-of-Band network and I talked about some options. I’ve had mails asking how to show some of the configurations. I’ll cover those and do other posts I have been promising in the next couple days.
This post will focus on the current Cisco 3G WAN card, the HWIC-3G-GSM. This card is supported by Cisco’s 1841, 1861, 2800-series and 3800-series ISR routers. This card only supports High-Speed Downlink Packet Access (HSDPA) “up to” 3.6 Mb/s downlink, 384 kb/s uplink (presumably HSDPA Category 5/6, but not sure)
“3G” is a broad category of standards and services around “broadband” mobile wireless voice and data. Universal Mobile Telecommunications System (UMTS) is part of this family. High Speed Packet Access (HSPA) is a collection of mobile telephony protocols that extend and improve the performance of existing UMTS protocols. Two standards, HSDPA and HSUPA have been established and is fairly well known.
An Out-of-Band management network plays an integral part in supporting any network. Without it when core devices go down, unnecessary time is spend driving to the downed site to fix and correct the problem if remote connectivity in unavailable.
For those that don’t know, an Out-of-Band (OOB) management network is a small support network that usually runs alongside the production network at key locations, with the sole purpose to provide console level access to core devices remotely. This access can be vital to assure downtime is minimized.
The usual OOB requirements are:
Low implementation cost since it is used only for support.
Low monthly cost for the same reason.
OOB should not depend on any existing infrastructure.
Should be easily accessible from remote locations.
Must be secure, since it connects to the core devices.
ISDN and dialup technologies are most commonly used, due to the low monthly line costs. But ISDN and Dialup has the inherit cost problem if the line is connected for extended periods (days), either due engineer negligence or configuration troubles. I have also seen 64k Diginet links used, which is really not the best option cost wise, when the OOB network spans different geographical regions.
I was recently task to fix a OOB design that were using Diginet links. I looked at the design, and I cancelled all the serial links days later due to insanely high monthly costs.
Instead, to address all the required points above, I proposed a new design similar to the diagram below. (This diagram only depicts one site though)
Upgrading a 6500 is pretty straight forward, provided the necessary is done in the right order. I’ve listed the steps I would typically take to fully upgrade a single Cisco-6509-E (single Route-Processor) with a IPSEC VPN SPA blade.
Please lab this if possible BEFORE trying it in a production network. I have illustrated the steps to be taken if some of the known funnies occur during an upgrade. Feel free to use this as a guideline.
Firstly download the IOS and image versions, you need. Obviously do a little homework and check the specific IOS for known bugs using the Bug Toolkit. Don’t just pick any IOS. Make sure all the required features are relatively bug free.
Copy the downloaded files to the following locations:
ROMMON firmware to sup-bootflash
BOOTLDR to bootflash
IOS to flash disk
I always use FTP if possible, due to the higher transfer rates. 10.3.29.239 is connected to the switch and is running a FTP server, expecting a username:password of cisco:pass.
copy ftp://cisco:firstname.lastname@example.org/c6msfc3-rm2.srec.122-17r.SX5 sup-bootflash:
copy ftp://cisco:email@example.com/s72033-boot-mz.122-33.SXI2.bin bootflash:
copy ftp://cisco:firstname.lastname@example.org/s72033-adventerprisek9_wan-mz.122-33.SXI2.bin disk0:
I was asked today how to calculate the Bc values. The known formulas always add confusion. So the aim of this article is not to add more confusion, but offer an easy alternate way to calculate the Bc values used with shaping.
First lets review some basic shaping definitions.
CIR (Committed Information Rate)
Dictates the output rate one aims to average per second on the circuit/interface.
Book formula : CIR = Bc / (Tc/1000)
It is the time in milliseconds into which a second is divided for transmission intervals.
The Tc can’t be adjusted directly, but it can be changed by setting the Bc to a specific value..
The maximum value of Tc is 125ms (8 intervals per second) and the minimum value is 10ms (100 intervals per second).
Actually 8ms (125 intervals per second) on distributed platforms. On distributed platforms, the Tc must be defined in 4-ms increments. The nearest multiple of 4 ms within the 10-ms target is 8 ms.
Book formula : Tc = (Bc / CIR) x 1000
Bc (Committed Burst Rate)
Bc is the number of committed bits allowed to be sent per interval (Tc) to conform with the target-rate (CIR) per second.
If Bc worth of bits are sent every interval in a second, the output rate is the CIR.