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:email@example.com/c6msfc3-rm2.srec.122-17r.SX5 sup-bootflash:
copy ftp://cisco:firstname.lastname@example.org/s72033-boot-mz.122-33.SXI2.bin bootflash:
copy ftp://cisco:email@example.com/s72033-adventerprisek9_wan-mz.122-33.SXI2.bin disk0: