Archive for April 2011
Cisco IOS DHCP Server with Option 43 for LWAP’s
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.
Took the CCDA Exam 640-863.
Well after my two months of going through CCDA material I finally sat down and took the exam. I am happy to say I passed the exam with a score in the 900’s. All in all it was a good experience, similar to the CCNA exam the CCDA doesn’t focus on a single topic but instead touches on multiple technologies including routing, IP Addressing, wireless, voice, security, and a few more topics so its definitely at a different pace compared to the CCNA: Wireless and Security concentrators. Here is a link to the exam topics.
The exam took me about an hour (almost to the minute) so while I had time to spare it was not a quick exam. I found the drag and drops and the few questions concerning route summarization to be the most time consuming questions. It’s a good thing route summarization is like riding a bike and you just don’t forget how to do it (At least for me anyway). So I didn’t find this test to be very challenging just long winded.
Something I feel that sets this exam apart from the other Cisco exams I’ve taken is this exam does not rely on you learning any new configurations as long as you are familiar with the topics already. I know Cisco lists CCNP SWITCH knowledge as a recommendation prior to starting the CCDA but not as a requirement. That’s something I can agree with, while the CCDA will not test you on the configuration or the troubleshooting of SWITCH topics (L3 Redundancy, Etherchannel, QoS, and so forth) they expect you to be familiar with them and know about these topics. Instead this exams covers more of a “best practice” solution, providing guidelines about when to break a network into multiple tiers, and it also provides a recommended practice on the network life cycle (The PPDIOO methodology).
While the certification itself is nice to have under my belt, I have found the topics covered by this exam to be the most the beneficial. Even though it was less of a technical certification the knowledge about network design and best practice setup would be beneficial to any network administrator or engineer out there in the field.
So, I am rather happy I was able to get this certification under my belt before Cisco retired this version. It’s material I’ve been through countless times over the last few years but never dedicated enough time to take the test until now. After this I am going to head back into the world of wireless and pursue that CWNA certification. At the same time I will be reading though this Wireshark book, in hopes of taking to the WCNA (Wireshark Certified Network Analyst) certification test later this year (Probably near summer time June/July). I am not usually one to study for multiple topics at once, but Wireshark is a tool I use fairly often and I feel it would supplement my skills/knowledge as a network analyst without hindering me at all.
Layer 1 Troubleshooting with Cisco Switches.
Apparently Cisco switches have the capability of performing TDR tests on cables to test cable length and pin-outs. This is something I stumbled upon while browsing through the Cisco Learning Network and I just had to give it a whirl. After all sooner or later you are going to run into a cable issue, it’s just a matter of time. Whether it was not crimped, punched down correctly, or someone ignored the IEEE standard and made a cable too long. The bottom line is some user somewhere will not connect to the network and then it will be up to you to troubleshoot why (and to fix it).
To test a cable simply issue the following command: test cable-diagnostics tdr int %IntefaceType/Number% from privileged mode, and include the interface in question.
After a few seconds issue the following command to see the results: Sh cable-diagnostics tdr int %IntefaceType/Number%
The results are as follows:
Pretty straight forward, it tells you the interface the cable is plugged into, the speed of the connection, the local and remote pair of the cables, cable length (notice the “+/-” of a few meters), and finally the status.
Here is a description of the results from Cisco’s website (Found here):
This command is currently available many different switch models 2900’s, 3500’s, 3700’s, and further (Including both 10/100 MB and 1 GB ports). I would also like to mention if you perform this test on a live port, communication is not interrupted at all. The Cable Length measurement is actually very accurate, don’t let the “+/-” factor confuse you, I’ve ran this on multiple cables and the length calculation is right on the mark. This is a definitely a nifty feature to keep in your when you run into those wired connectivity issues.
Automatically recover err-disabled ports.
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.
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.
CCIE or Null! 