The Cisco PPDIOO Life Cycle.
The PPDIOO network life cycle is something covered in the CCDA Exam objectives, and it provides a foundation on how/when a network should be implemented/designed/upgraded, of course this is a “best practice” type of thing, and people do not have to adhere to this life cycle but after you go over it a few times you have to agree it does make sense.
Prepare – This first prepare phase is not very technical at all. In fact the primary purpose of this phase to justify the network upgrade. This phase will involve speaking with high level managers to figure out what business goals the company has and what products could be used to provide that functionality to the business.
Example: If the customer wanted to implement a WLAN you would want to ask various questions. How many users will use the WLAN, what kind of people will utilizing the WLAN (employees/guests), what kind of applications will run on the WLAN, required WLAN security (Do any compliances have to be taken into consideration SOX, HIPPA, etc), what kind of speeds will be required, and so forth. Then you would want to look for products that meet the customer’s requirements.
Plan – In this phase, you would audit the existing network, now depending on the type of project would consider what you are going to look at. A few things you could look at in an audit is to inventory all affected networking devices checking on IOS versions, CPU/Memory utilization, look at the existing traffic via Netflow, link utilization, and so on making sure the network is in an already healthy state prior to making any changes and also to make sure the existing network can handle the additional project. Based on the results you will plan your implementation in this phase (who would have thought), step by step instructions including stop points to test the configuration and roll back plans in case things don’t go well. (Sure we hate to admit it but sometimes things happen out of our control)
Example: Your customer wants to implement an 802.11n WLAN, their are going to be a few things you want to verify (or plan for). Does the customer have 802.3at compliant switches to provide the required amount of power to operate 802.11n radios, does the customer have 1 GB switches to connect the AP’s to. It would also be wise to verify the network backbone will be able to handle the new traffic load. Also in this phase you will want to perform a site survey to locate sources of interference and existing WLANs.
Design – This is where some of the fun begins. Based on the business requirements (from the prepare phase) and the technical information (from the plan phase) you can begin designing the new network topology. The design you create in this phase will contain everything (IP Addressing, VLANs, Redundancy, Security, etc) you are going to need for the project and be referenced throughout the rest of the project.
Example: After performing the site survey, and inventorying the customer’s network you design a plan for customer to purchase multiple dual band 802.11n AP’s, the required amount of 802.3at compliant switches, dual WLC’s for redundancy, along with RADIUS software for security. You also provide and updated network diagram concerning how/where the new equipment will combine with their existing network.
Implement – As the title says, this is where the new equipment is configured and physically setup at the customer’s location. If you’ve spent a good amount of time in the plan phase, the implement phase is usually carried out word for word as described in the documentation. It is also best practice to test the design at certain points this way if you find that something does work it’s usually easier to troubleshoot before too many changes are in the equation. (I emphasized this point more then once for a reason.)
Example: The new switches, AP’s, RADUIS software have been purchased and have arrived at the customers site. You follow the implementation plan and begin the installation of the new switches, then setup the two WLCs, deploy the AP’s, verifying the AP’s power up and join the WLC as each of them are deployed, also testing WLAN client connectivity. You then proceed to setup the RADIUS server and configure the WLC & AP’s to authenticate through the RADIUS server, then verify client connectivity again.
Operate – The network has been deployed and is being utilized by the end users. Appropriate support personnel are also monitoring and maintaining the network. In this phase it is acceptable to perform software updates and monitor the overall health of the devices/links.
Example: The WLAN is fully configured and now end users and guests are able to bring in their laptops and PDA’s. They successfully associate/authenticate to the WLAN and access the company resources, all the while being mobile.
Optimize – In this phase the network is proactively monitored & changed to improve performance or resolve issues. These changes can be minor or major depending on the amount and type of issues that occur. If the changes are big enough this life cycle could begin again back at the prepare phase.
Example: WLAN users in a particular location are experience slow wireless performance and are disconnected from the WLAN multiple times throughout the day. Support personnel show up with a spectrum and protocol analyzer to investigate the issue, it appears a new cordless operating at 5 GHz has been placed in this area that was not previous there during the site survey. This leaves 2 options advise management to have the cordless phone removed, or move the users to another frequency that is uneffected by the phone.
Well, there is a quick and dirty look at the PPDIOO life cycle. More information can be found in Cisco’s design curriculum or Cisco Press’s network design publications. I would also like to add the examples I provided are merely that, simple examples real projects require much more documentation and detail.
CWNP Question of the Day
Well, it appears after a few months of visiting CWNP’s website (Yes, even on the weekends) their daily questions have finally started to repeat themselves. I knew it would end eventually and considering the price (free) 3 months of questions is a pretty good deal.
I really recommend anyone who is studying for a CWNP exam (or anything wireless related) to head over to this page and take a shot at the daily question. Don’t let the fact that they are free put you off they are good quality questions, and every question has a detailed explanation so if you get the question wrong or don’t understand it at first the explanation will lead you in the right direction. These questions will also touch on many different topics within the world of wireless, I’ve seen stuff ranging from non-technical security questions to questions concerning the 802.11 frame so this is a quick and dirty way to see inside the CWNP Professional level tracks (CWSP, CWAP, CWDP) just no where near as in-depth.
You can find a link to the CWNP Question of the day right here, their is also a link my Blog Roll. I am going to leave the link in my Blog Roll for any new visitors to find, so it won’t be going anywhere anytime soon. Hopefully CWNP will update the question as time goes on so we will see.
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.
CCIE or Null! 