Posts Tagged ‘Cisco’
Using the CLI to install and IOS in .tar format.
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
Control roaming behavior on your Cisco wireless network.
Roaming is just another expectation from your end users. They expect to walk freely around the office to conference rooms or far off cubicles and have their laptop or handheld remain connected while downloading files or in the middle of a conversation. If the roaming process is not quick enough then you could see conversations and clients gets dropped forcing them reconnect to the WLAN, and I can guarantee you your end users will be calling.
Now, if you have done a proper site survey and have solid data to work off of, you can control the roaming behavior of your WLAN clients. The reason you need to know the details of your wireless environment is because you are going to set RSSI limits concerning when your clients should begin looking for a new AP to associate to and, how quickly they are roam between access points. Just keep in mind, making these settings will effect the entire WLAN not just individual sections.
I would also like to mention your clients should be CCXv4 or higher to take advantage of these features. To see if your clients are CCXv4 compliant go to Monitor -> Clients -> click on the client in question.
On your Cisco Wireless LAN Controller, you want to navigate to Wireless -> 802.11a/n or 802.11b/g/n (depending on which frequency you want to customize) -> Client Roaming.
The first thing you need to do when you want to customize these settings is change the mode to custom this will allow you to edit the default values for the rest of the parameters.
The next option is minimum rssi. If a clients RSSI value is below this threshold it will not associate/authenticate to the access point, instead it will continue to look for a better signal from different access points. Valid values for this field are -80 through -90. The understanding is that the signal strength/quality will be so low reliable communication will not be established.
Next we have a setting called hysteresis this value is in dB and states how much stronger the signal of another access point has to be before a client decides to roam to it. This is useful if you have multiple access points in close proximity of each other or clients are moving between the edge of coverage of different access point. The higher this value the closer a client needs to be to an access point for it to associate to the second access point. Valid ranges are from 2 through 4 dB.
Now we have the scan threshold this is another RSSI value range. When the wireless client’s RSSI drops below this threshold the client will begin actively scanning for another access point it can receive a stronger signal from. Valid values range between -70 through -77.
The last field on the page is the transition time this is the amount of a client is going to see a better signal from neighboring access, before it attempts to associate to the second access point. The client determines a better signal when its RSSI drops below the scan threshold and it sees a signal from a neighboring access point higher than the scan threshold.
So all these factors do work together and can be customized for your environment. Normal data traffic is more forgiving since it’s not as delay sensitive, but If you have voice on your WLAN you will want to fine tune these settings to avoid dropped calls.
Configuring a SPAN session.
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.
Cisco WLC Interfaces.
If you have ever worked with a Cisco WLC or have looked through any configurations for a WLC, then you have no doubt seen the interfaces that make it work. You’ve probably also seen that diagram concerning how these interfaces relate to the physical interfaces on a Cisco WLC.
Now their are only five different types of interfaces (Management, AP-Manager, Virtual, Service-Port, and Dynamic Interfaces), I figured I would just take some time to quickly touch on them.
- Management Interface – As you can suspect this interface is for in-band management and handles any communication with AAA servers. This interface will also handle the layer 2 communication between the controller and any APs. Needless to say the configuration of this interface is mandatory and can not be skipped.
- AP-Manager – If you want to have APs on different subnets other then the subnet the WLC is on then this interface must be configured, it’s a requirement for Layer 3 LWAPP transport mode. So as you would suspect this interface handles all layer 3 traffic between the WLC and the APs. Since higher end WLCs can have multiple AP-Managers only 1 AP-Manager interface can be configured per physical port.
- Virtual Interface – Another mandatory interface that must be configured (once again like the management interface you don’t get the option to skip the configuration of this interface). This interface handles any mobility management, VPN Termination, Web authentication, and is also a DHCP relay for WLAN clients. You really want to give this interface a bogus type address (Like 1.1.1.1 or something) since it’s only accessed and used by the WLC, the APs and WLAN clients will not interact with this interface. (Other then it’s purpose as the DHCP relay, but it’s all in done within the controller unknown to the AP’s or clients)
- Service-Port – This is also a physical port for out of band management, so it’s configuration is optional. The port doesn’t even support 802.1Q, so you can’t use it for anything other then accessing the controller. (Note: This is only physical port that is active while the controller is booting)
- Dynamic Interface – Now these are the interfaces you can create and use to link specific SSID’s to specific VLAN’s on the wire. So this is where and how you can separate your wireless client traffic, this interface will also double as the DHCP relay for it’s subnet/VLAN (Note: A WLC can have up to 512 dynamic interfaces)
Secure Cisco Device Management.
One thing that should be standard in your setup, is secure management. Being a network engineer requires you to secure your management interfaces, whether the management interface is a web page or remote CLI session, it should be encrypted and authenticated. After all configuring port security and firewalls are useless if your administrative credentials are sniffed off the network in clear text, or worst case your entire configuration.
First thing you want to do is activate the secure protocols and disable the weak protocols. So we would issue the following commands:
As you can see we first disabled the HTTP protocol, and then enabled HTTPS (Note: the first time you enable HTTPS a certificate may be generated), then configured the vty lines to accept only SSH, and not telnet connections.
Note: Prior to disabling telnet and enabling SSH, you want to configure the aaa new-model parameters along with any local users DB entries. See this Cisco guide for configuring SSH in more detail. Last thing you want to do is lose remote access to your device.
Now this device can only be managed via HTTPS or SSH, telnet and HTTP access have been disabled. This will prevent the administrative credentials of your network devices from being sniffed off the network in clear text, only encrypted cipher text will be found.
Just to push the point home some more, here is a TCP stream where I telnetted into a lab switch and issued the sh run command. First off you see the password I entered to access the switch and secondly the entire output of the sh run command is right there in clear text!
Now, I did a second capture where I accessed the switch via SSH and issued the same commands.
Very different output, as you can see, in the beginning you see I used Putty after that the encryption algorithm exchange and the rest is cipher text.
You can also verify this by using NMAP to perform a port scan on the device to see what ports the device is listening on.
Here is a NMAP Scan with all four protocols enabled (Telnet, SSH, HTTP, and HTTPS)
Here you can see, the lab switch is listening on all four ports, so individuals can connect to this device in an insecure manner. (The option should not even be out there)
Now a second NMAP scan after the commands shown above were entered.
Now the device is only listening on 22 and 443. This device can only be managed in a secure way.
I’ll end this on a final note… The tools I used here are all free to download NMAP, WireShark, and Putty. So it doesn’t take much for some barely knowledgeable (and bored) user on your network to start sniffing packets on your network.
Cisco Band Select.
Thought I would shift gears to wireless for a little bit. Cisco introduced a feature some time ago called band select were the dual band clients have a better chance at joining the 5 GHz radio compared to the 2.4 GHz range. This is mainly due to the influx of dual band clients nowadays and how the 2.4 GHz range is generally over utilized.
The Cisco accomplishes this is by ignoring/delaying the first few 802.11b/g probe frames in hopes of it accepting the 802.11a probes because it will appear to have a quicker response time. I would also like to point out that this feature only works when the client first associates to the Access Point. So this feature will not kick in on the fly when the AP notices a high client count or high channel utilization. Plus this feature only goes in one direction from the 2.4 GHz range to the 5 GHz not visa-versa. So this is not a load balance mechanism.
This feature is configured very simply all from one screen in the WLC, under Wireless -> Advanced -> Band Select:
Now you’ve only got a few settings to configure here, but you still need to take care with these settings like anything on the network you are going to configure. Probe Cycle Count, tells the AP how many probe beacons/frames to ignore/delay. Scan Cycle Period Threshold tells the AP how often in milliseconds it can expect each probe from the client, this setting can be changed depending on the client Wi-Fi cards you are using in your environment and how often the send out probe requests (Check vendor documentation for this). Age Out Suppression, this is the time-out for when the clients will be declared as “new” and may have their probe frames delayed/ignored again. Age Out Dual Band is the very similar to age out suppression, however age out dual band only applies to dual band clients so it will not effect everyone. Just keep in mind something will need to happen for the client to disassociate and re-associate with access point. Acceptable Client RSSI just states the minimum RSSI value a client registers for it to be eligible for band select.
Also keep in mind this feature can be controlled per-WLAN, under the “Advanced” tab
This can also be done via the CLI of the WLC using the following commands:
config band-select cycle-count cycle_count
config band-select cycle-threshold milliseconds
config band-select expire suppression seconds
config band-select expire dual-band seconds
config band-select client-rssi client_rssi
config wlan band-select allow {enable | disable} wlan_ID
And if you want to verify the band select configuration use the following command:
show band-select
CCIE or Null! 