CCIE or Null!

My journey to CCIE!

Archive for the ‘Cisco’ Category

Using the CLI to install and IOS in .tar format.

with 3 comments

Recently I tried updating the IOS of a Catalyst 2960 using it’s web interface (Why I don’t know), but like everything Cisco GUI related (SDM) I had trouble getting it to actually work. The page would just sit their and cycle. So I found myself unable to update the IOS using the GUI. So I extracted the files within the .tar file to flash, told to the switch to boot using the newer IOS then issued the reload command.

Start off by putting the .tar file on your tftp server like any normal IOS upgrade, the key difference here is you want to use the following command:

archive tar /xtract tftp://192.168.1.5/c2960-lanbasek9-tar.122-58.SE1.tar flash:

The variables here are the IP Address of the TFTP server and the IOS image file name.

Next you will see the switch extract the files within the .tar file

Extract tar file in flash

The last thing you can see is the .bin IOS file. Now I issue the boot system command:

boot system flash:/c2960-lanbasek9-mz.122-58.SE1/c2960-lanbasek9-mz.122-58.SE1.bin

Note: The contents on the .tar file are extracted into a folder

This tells the switch to boot this particular IOS file. Then after you issue the reload command and the switch boots up you will see the switch loads with the new IOS version.

IOS Version loaded by switch

Written by Stephen J. Occhiogrosso

May 24, 2011 at 8:04 PM

Posted in Cisco

Tagged with , , , ,

Cisco IOS DHCP Server with Option 43 for LWAP’s

with 4 comments

Cisco routers (and switches) have the ability to hand out DHCP addresses, so if you have a relatively small branch office & you don’t want to set up a full DHCP server you can simply add that functionality to your Cisco device.

It does take quite a few lines to get this going but I wouldn’t consider it to be a complicated configuration, each parameter is pretty self-explanatory. Let’s look at a typically IOS DHCP configuration.

Now the first thing you want to do is define the DHCP pool with the ip dhcp pool poolname command this puts us into (dhcp-config)# mode where we can configure addition parameters for this pool. Next you see the network 192.168.20.0 255.255.255.0 command which defines our DHCP range followed the default gateway, DHCP lease duration (3 days in this case), the DNS Server the for the DHCP clients, and finally the domain name.

The next thing we are going to do is configure some DHCP exclusions, these are simply addresses we tell the DHCP service not to hand out. We are also going to change the amount of times the router pings an address before it declares the address available.

Now the exclusions are done from (config)# mode (but as you can see they can be entered from (dhcp-config)# mode) along with the ip dhcp ping packets 4. The Cisco device will ping an IP address within the pool to see if it available, by default the device will send 2 pings if they both time out it assumes the address is available, here you can see I changed it to send 4 pings.

You can view any DHCP leases by issuing the Sh ip dhcp binding command. (Yes I know the time is a bit off but this my lab switch)

Now for some bonus content, I was going to split this up into multiple posts but figured I would just roll it in.

We are going to configure Option 43 in our DHCP scope. Option 43 is vendor specific, and is used by Cisco LWAPs to find and join WLC controllers. It’s all done in the following line:

As you can see this is also done within the DHCP Pool at the (dhcp-config)# configuration mode. The tough part here is figuring out the hex value however the hex value consists of 3 parts. The first part is the type which is always 0xF1, followed by the length which is the number of controller management IP address times 4 (So if you have 2 controllers for redundancy it would be 2 x 4 = 0x08), the third part consists of the ip addresses of controllers management interface in hex. (Now seriously did you ever seeing yourself converting IP’s to hex, or did you use a hex calculator?). For this example I used 2 management IP addresses 192.168.2.5 which is C0A80205 in hex and 192.168.3.5 which is C0A80305 in hex. Now all that together gives us the f108C0A80205C0A80305 hex string seen the above configuration.

Now here’s a DHCP packet with the Option 43 field:

Now packet analysis can be a bit daunting at first, but if you go line by line, you can easily make out everything that was configured, you see the option number and the hex value we entered, now your LWAPs in branch offices will be able receive a DHCP address and still find your WLC’s.

For more information on setting up a Cisco device as a DHCP click here. (This guide goes much more in depth then my post)

For more information on DHCP Option 43 and Cisco LWAP click here.

Written by Stephen J. Occhiogrosso

April 29, 2011 at 5:52 PM

Automatically recover err-disabled ports.

leave a comment »

Cisco switches have a feature built-in so ports in an err-disabled state automatically reset themselves saving you the time of having to connect to the switch and manually shut and no shut these interfaces. Only two parameters need to be considered when configuring this feature.

The first parameter concerns which errors you want the switch port to automatically recover from. For example you may not want a port with a security violation to come back up without administrative intervention, but a port downed due to a flapping host you might want automatically turned back on after a few minutes. You can issue the errdisable recovery cause ? command to see a list of switch port errors that the switch can automatically recovery from.

The second option you can configure is the time  interval in which the switch waits before it re-enables the err-disabled port. The default recovery interval is 300 seconds.

As you can see, this is all down from global config mode.

While this err-disable recovery feature can be a great time saver it is still important to investigate and correct the real issue that is causing the switch ports to fail into an err-disabled state.

Written by Stephen J. Occhiogrosso

April 11, 2011 at 7:07 PM

Configuring a SPAN session.

with 2 comments

A SPAN session is a way for you to have the traffic that is transmitted and/or received from one port or VLAN and have it forwarded out another port for analysis purposes. It’s very easily configured by a few small statements and the only thing you have to decide on is which port you want to monitor, the traffic flow you want to see from that port (egress, ingress, or both) and the destination port you want the traffic sent to. (See the configuration below)

Note: For this local SPAN session both the source port and destination port must be on the same switch. RSPAN allows SPAN sessions across remote switches, but I will not be covering RSPAN in this post.

Their isn’t much to consider concerning the source port since it will not be effected at all, the destination port however is treated a bit differently. First off the destination port will be put in a “Monitor” mode, meaning traffic received on this port will be dropped. Only traffic from the source port will be transmitted out of the destination port by the switch that’s it.

You can issue the sh monitor session # command to see if their are any active SPAN sessions on the switch, or if you want to see the details of a configured SPAN session. The source port (fa0/1), traffic flow (both), destination port (fa0/2), and the encapsulation, are all shown in the command. To close down a SPAN session simply issue the no monitor session # command.

Now your next question might be, what are you going to use this for or why are you going analyze the traffic? Well, if the station at the destination port is running Wireshark, it’s a real easy way to get a glimpse at the traffic traversing your network. From their you can look through the data and see if anything sticks out. Alternatively you can have a SPAN session provide data to a IDS/IPS system so it can monitor your network for any abnormalities.

Written by Stephen J. Occhiogrosso

April 4, 2011 at 2:21 PM

Let’s look at: Cisco Discovery Protocol (CDP)

leave a comment »

Yes, yes I know if you have ever worked or studied Cisco on any level you will already be aware of Cisco Discovery Protocol (CDP), and what it is and does. I just wanted to take the time and cover it for some of it’s finer points. While I know talking about CDP is a jump from previous articles, but I was using Wireshark recently and caught a glimpse of a few CDP frames crossing my network.

Now if you ever have to map out an all Cisco network then CDP in your road map, CDP will guide you to any neighboring Cisco devices providing you the below information:

Just look at that, the only thing it doesn’t give you is the amount the memory and flash in the neighboring device, so this also an easy way to inventory your network and see what devices are connected where and what IOS is running on that device.

To see this information from within a Cisco device you want to issue the sh cdp neighbors command

The output can easily be matched with the table posted above. Additionally you can issue the sh cdp neighbors detail command to go an addition step further and get the actual IOS version running the on the neighboring devices.

Along with the IOS version, addition details about the connected interfaces, and platform are displayed. So if you were in the process of mapping or auditing a network with only the tools available CDP is one that should never be overlooked.

Another thing to consider is which version of CDP is running on your Cisco devices, the screen shots above are both from devices running CDP versions 2. Obviously version 2 has a few additions that version 1 did not have, let’s compare the two shall we.

As you can see version 2 offers improvements with PoE negotiation, which is used with other Cisco devices (VoIP phones, and Cisco AP’s), as well as duplex settings, the native VLAN of the line, and the VTP management domain information.

The last thing I want to mention is the CDP packets I sniffed off my lab can be sniffed from any Cisco device if CDP is running on the interface, which can be security risk especially on edge devices. So on any edge devices or devices that do not have any other neighboring Cisco devices then you might as well disable CDP on the device, see my previous post concerning the 1-step router lockdown, concerning some basic security practices.

Written by Stephen J. Occhiogrosso

March 3, 2011 at 2:53 PM

%d bloggers like this: