Archive for the ‘ont’ tag
Two down, two to go. After much groaning and moaning, I’ve finally passed my ONT test. The path to this point has been full of road blocks and covered in potholes, but I finally managed to power through it. Thank $deity.
If you remember, I’ve had quite a time with finding a testing center that’s convenient (or open for that matter), so I took the test at yet another center to see what they offer. The facility was great; it was very quiet and clean, and the people were wonderfully friendly, which is a new concept to me. Usually, the people don’t care about testers, but, being a center for inmates at state prisons (yes, prisoners), they do nothing but vocational and professional testing there. That’s a lot better than the facilities who give their own students priority or who make money on training instead of testing. The center is just over 2 hours away, but I think this place may be the best so far. I’ll have to see what the future holds, though.
The test itself was nothing strange; I only had two or three question I hadn’t seen, and even those were basic and easy to answer. Each time I failed this test, I jotted down what I missed and studied up on those topics. The first time was mainly FRTS. The second was VOIP. The brute force method, as mentioned by @ciscovoiceguru seemed to be the key this time – eventually, I’d get a passing score by studying what I didn’t know the last time. Of the 55 questions, I would guess that 35 of them were on both previous attempts. Of the remaining 20, about 17 or 18 of them were on either of the previous tests, so it turned out quite well this time.
The materials I first studied were pretty disappointing. The Cisco Press books didn’t really help. The content in them is so outdated that they’re pretty worthless for getting the details needed for a passing score, but what can one really expect for a test that’s expiring in a few months. A few people made suggestions of other resources to study, but I found them to be too expensive for passing a single test. Some unnamed solutions were $800, which means I could just take the test 5 times for the same cost; instead of paying that much for a $150 test, I decided to use the test itself as a study guide and to use Cisco’s docs to fill in the details. This seems to have worked out eventually.
The next step is a switching test of some kind. I can’t really decide if I want to do BCMSN or SWITCH. I’ve got to look over the material to decide, but, in the meantime, I’m starting to read through the SWITCH book on Safari. I hope it’s not outdated already. I’m scheduled to be in the ROUTE class with Global Knowledge mid-May, so I’d like to finish up the switching test by then. I think I can do it since this material is a lot more familiar to me than Cisco VOIP and Wireless; neither of which we run at the office. In theory, it’s going to be filling in the details than building a new skill set as with the ONT.
Thanks to everyone for their support. At the risk of sounding cheesy, it’s hard to keep going, and the words of encouragement kept me from getting down on myself.
Any suggestion on which switching test to take would be greatly appreciated. Has anyone actually taken the SWITCH test yet?
Send any Safari credits questions my way.
It’s not what you think.
I was talking with a buddy online last night, and he made a good point. If you keep putting off taking a test, you’ll never make any progress. I took that to heart, went online, and scheduled another sitting of ONT for today at 3pm at the closest center. I took the day off, too, so I could get some tax stuff done and get over to the center and back before dinner. I got some really good rest last night for sure, too, and had some very productive study time before heading off for my day’s adventures.
I ran my errands and headed over to Statesboro, GA, for the test. There’s a technical college over there that’s the closest testing center to the house, thought still an hour and a half drive for me. On the way over there, I was going over 802.11e stuff in my head and generally enjoying the sunny and warm day. I pulled into the school and noticed that they were repaving the parking lot up front where I usually park. No biggie. I pulled around back and noticed there were 5 cars in the whole lot. Last week when I was there, there were at least 200 people there signing up for classes, but there was no one around today. I didn’t think much of it, though; it was late in the afternoon on a Friday, and I figured everyone just bolted for home early.
It’s an open campus with buildings all around a few courtyards. I walked around the building in the back (I have no idea what building that was) and walked towards the Assessment Center where the tests are given. The long drive was taking a toll, so I stopped by the main building to heed nature’s call. The door was locked. So was the door to the next building. So was the door to the Assessment Center. It was dark. Nobody was there. I finally found a sign that said everyone was on furlough until next Tuesday. Nice.
I called Pearson and told them the story. They verified I was in the right place and there at the right time. They even called the testing center to see if they could find anyone, but, of course, no one answered. The support person with whom I spoke told me that their team would have to get in touch with the testing center to see what had happened and that they would contact me when it was all straightened out. They were very apologetic for the mixup and promised to straighten everything out.
I guess we’ll see what happens on Tuesday. Of course all of this means another half day off of work and another 150 miles on the car. Will I ever get to pass this test?
The Director’s Commentary is here again. Let me know if you like the audio, or if I should burn my terrible voice with fire.
I took the ONT again today. The stench of failure is upon me for a second time, and I’m beginning to think I’m not the god-like person that everyone thinks I am. I went into the test very confidently. I did extra time on my weak points from the last attempt and knew it inside and out. I put hours and hours of lab time in and got other books and online materials involved. I was absolutely convinced that I would blow this thing away, but, alas, it was not to be.
If you ignore the wireless questions, the test was pretty fair. There were questions in the usual poor wording that made you doubt things that you know are absolutely true. Unlike last time, though, I didn’t find any questions where I was totally lost. There were some questions that were very ambiguous, but only one was out of realm of possibility (it actually required a calculator to answer correctly). All in all, it was a good test sans the wireless stuff.
Ah, the wireless questions. I complained last time that there was one needlessly-obscure questions about WLC CLI, and that exact question was on the test today. The additional CLI questions were downright sadistic, though, and the question about how to do initial configuration was really uncalled for. Oh, I almost forgot about the question asking what model of WLCs support feature X. Really? Has there always been a requirement to know the features of each model in a product line? I think I got two (maybe three) questions about the technologies like WPA and DCF.
Yes, I know it sounds like I’m making excuses, but I’m not the kind of person who shifts the blame. If I’m the cause of the problem, I’ll fess up to it. If I thought I could have done better, I’ll admit it. If I chose to ignore a topic and get bitten for it, I’ll happily say it was my fault. In this case, I did more than what I thought was appropriate and still failed.
I believe this puts me far enough behind my schedule to have to take another path to CCNP. My first reaction would be go the ROUTE/SWITCH/TSHOOT path. Since I’m already scheduled to take a ROUTE class, it seems the obvious choice.
Hear the Director’s Commentary on this post:
I’m still working on the ONT test and doing labs, so I marked up a lab for me to work. I’m using the same setup as I did last time. The two routers are 3640s running 12.4(25b).
Part of the lab was to identify HTTP traffic coming into F0/0 and mark it as CS3. That’s pretty easy, right? Of course, the lab I made up was a little more complicated, but the point comes clear with a simpler example.
class-map match-all HTTP match protocol http ! policy-map PM-F0/0-IN class HTTP set dscp cs3 ! interface FastEthernet0/0 service-policy input PM-F0/0-IN
I fired off a small script on TestHost1 to repeatedly do NMap scans on TCP/80 of TestHost2 to generate some traffic.
root@bt:~#while ( true ) do nmap -sT -p 80 -v -n 172.16.2.101; done
I let that run for a while and checked out the service policy on F0/0; there were absolutely no matches on that class.
R1#sh policy-map int f0/0 input class HTTP FastEthernet0/0 Service-policy input: PM-F0/0-IN Class-map: HTTP (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: protocol http QoS Set dscp cs3 Packets marked 0
I thought that was strange, so I kept the script running and captured the traffic coming out of S1/0. Looking at the packets in Wireshark showed that none of the HTTP packets were showing up as being marked as CS3; they’re all set to the default DSCP value.
On a whim, I enabled NBAR protocol discovery on F0/0 to see if that would shed any light on my mess. Guess what I found. That’s right; there were no HTTP matches to NBAR, either. That makes sense since the class-map I defined uses the NBAR protocol. Alright, so it seems that it’s NBAR that doesn’t see the packets as HTTP, but why?
Looking through the packet captures again, I noticed that there was no real data in the streams. I saw the 3-way TCP handshake (a.k.a., my signature wrestling move) and then a RST,ACK. I only told NMap to check if the port was open, so I changed the while loop a bit and enabled version detection with the “-sV” flag. This time when I can the script, NMap was actually getting the HTTP banner. It was much traffic, but it was an actual HTTP conversation, so I checked NBAR again. Success! The same for the class, too.
For craps and smiles, I created a class-map that matched SIP, added it to the same policy-map, and set NMap after TCP/5060 without version detection. Without having a real SIP conversation, the class counters incremented as long as I was sending packets. That would seem unexpected until you realize that NBAR has some advanced knowledge of HTTP; you can actually match on URLs, hostnames, and MIME-types. I guess that means it also know when a real HTTP conversation is taking place.
To finish out the testing, I added an ACL to the router that matched any-any-eq-80. I made the class-map into a match-any and added the ACL. Since the ACL just matches the destination port and doesn’t care what the content is, every packet sent matched the class as expected. I remember reading several places and seeing a couple videos that said that you can use NBAR matching and ACLs interchangeably. That may not really be true when it comes to HTTP.
Cisco learning credits questions my way.
I’m still studying for the ONT test, so I did some labs tonight. One of them was to demonstrate the qos pre-classify command for tunnel interfaces. When you have a packet sent over a GRE tunnel, the ToS field gets copied to the GRE packet, but there’s no way to see the original packet’s higher-level headers on the way out the interface. This can be a problem if your service policy needs to see protocol, port, IPs, etc. The fix for that is to enable qos pre-classify on the tunnel interface and cyrpto map; doing so will provide a copy of the original packet to the physical interface to classify the packet thoroughly.
Here’s the lab. I was testing from TestHost1 to TestHost2 and configuring R1 to do the pre-classification. Both R1 and R2 are 3640s running IOS 12.4(25b) and have a GRE tunnel between them.
I created a policy map that simply acknowledges the existence of ICMP packets; the router doesn’t do anything except match them in a class-map and smile at them on the way through. Here’s the snippet.
class-map ICMP match protocol icmp ! policy-map PM-S1/0-OUT class ICMP ! interface S1/0 service-policy output PM-S1/0-OUT ! interface tunnel 0 qos pre-classify
Not much going on there. We match ICMP using NBAR’s built-in protocols and do absolutely nothing. I did a few pings and noticed that there were no matches to the ICMP class and that all the packets were classified as class-default . I thought that the pre-classify wasn’t working, so I cursed for a while after making no progress at all. I had no idea what was wrong.
R1#sh policy-map int s1/0 Serial1/0 Service-policy output: PM-S1/0-OUT Class-map: ICMP (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps Match: protocol icmp 0 packets, 0 bytes 5 minute rate 0 bps Class-map: class-default (match-any) 467 packets, 39832 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any
I need to stop here so people don’t get confused. The configuration that you see is correct; the problem was actually with the NBAR protocols in the class-map. As Jeremy Stretch notes at the bottom of this article, there’s some issue with matching NBAR protocols. I later used an extended ACL to match ICMP which worked. The same is true for the SSH stuff later. Back to the show.
Here’s what I wound up with after cursing a lot and making random configuration changes to get the blasted thing to work. Notice the order of the classes.
class-map match-any TUNNEL match protocol gre ! policy-map PM-S1/0-OUT class TUNNEL class ICMP
I know that order is going to be important, but these are matching two totally different things, so it shouldn’t matter, right? I checked out the policy-map again and saw that every packet was matching the TUNNEL class-map, and none were matching the ICMP class-map.
R1#sh policy-map int s1/0 Serial1/0 Service-policy output: PM-S1/0-OUT Class-map: TUNNEL (match-any) 441 packets, 49392 bytes 5 minute offered rate 2000 bps Match: protocol gre 441 packets, 49392 bytes 5 minute rate 2000 bps Class-map: ICMP (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps Match: access-group name ICMP 0 packets, 0 bytes 5 minute rate 0 bps Class-map: class-default (match-any) 467 packets, 39832 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any
I finally went downstairs, talked it over with my wife who is my rubber duck, and finally figured it wouldn’t hurt to change the order of the classes. Once I put ICMP before TUNNEL, it started matching. I thought that was odd, so I left ICMP and added an SSH class and put it after the TUNNEL class. I saw the ICMP match and the tunnel match, but I didn’t see a single match on SSH even though I was SSHed through (not to) the router.
R1#sh policy-map int s1/0 Serial1/0 Service-policy output: PM-S1/0-OUT Class-map: ICMP (match-any) 252 packets, 28224 bytes 5 minute offered rate 0 bps Match: access-group name ICMP 252 packets, 28224 bytes 5 minute rate 0 bps Class-map: TUNNEL (match-any) 5 packets, 440 bytes 5 minute offered rate 0 bps Match: protocol gre 5 packets, 440 bytes 5 minute rate 0 bps Class-map: SSH (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps Match: access-group name SSH 0 packets, 0 bytes 5 minute rate 0 bps Class-map: class-default (match-any) 547 packets, 46588 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any
When I moved SSH above TUNNEL, it started incrementing as it should. The best that I can tell is that both the original packet and the GRE packet are being evaluated when pre-classification is enabled. Since all the packets in the lab are going over a GRE tunnel, GRE will always be matched if you assess before everything else.
For the record, I did this lab twice – once with the GRE tunnel encrypted and once without encryption. The results of the pre-classification were the same in both attempts; GRE matches every time.
ROUTE class vouchers questions my way.
I failed the ONT test today. It was an utter lack of subject matter knowledge that did me in from the beginning. When the first three questions mention things that I’ve never even heard, it’s going to be a long test. I’ll take blame on it for sure, but the test was a lot darker than I imagined it would be.
I heard from a couple people that the ONT test was the easiest of the 4 CCNP test. I must say today’s test was a LOT harder than the ISCW test I took back in December. Most of the questions were fair, but there were a few that were down-right evil or unanswerable. Without giving too much away, there were some matching questions that had multiple items with multiple answers, rendering the answer to a guess. I even ran into a CLI question about the WLC, which surely wasn’t mentioned anywhere I studied, and I don’t have a spare sitting around on which to test. The icing, though, was the number of questions about FRTS; I know I need to understand it, but the magical question dice landed on that topic way too many times in my opinion.
At the heart of it, I think my demise stemmed from using only the Cisco Press book. I really needed to get a wider exposure to the topics. Though the CP books might have mentioned some topics that I missed, a lot of it is mentioned in passing but appeared in detail on the test. I would think getting different training would fix that problem and I’ll be using some of our CLCs this week to do just that
The facility was great, though. I was comfortable and couldn’t hear traffic or the lecture across the hall this time. At least I know a good place to take tests now. I hope somebody gets some value from my absolute failure.
Send any test vouchers questions my way.
Elements of Cisco Unified Wireless Network
- Client devices – Cisco compatible extensions on WLAN clients
- Mobility platform – allows configuration of LWAPs through WLCs
- Network unification – integration into the rest of the network with WLCs doing RF management, IPS, etc.
- World-class network management – centralized management through WCS
- Unified advanced services – supports advanced technologies and threat detection
Autonomous and LWAP
|Access Point||Autonomous APs||LWAPs|
|Control||Individual configurations||Configuration through WLCs|
|Dependency||Independent operations||Dependent on WLC|
|Management||CiscoWorks WLSE and WDS||WCS|
|Redundancy||Through APs||Through WLCs|
Wireless LAN Services Engine (WLSE)
- Part of CiscoWorks
- Manages autonomous APs
- Centralized configuration, firmware, and radio management
- Autoconfig of new APs
- Misconfiguration and rogue AP alerts
- Proactive monitoring of APs, bridges, and 802.1x servers
- Supports SSH, HTTP, CDP, SNMP for up to 2500 APs
- WLSE Express supports 100 devices in either automatic or manual setups
Wireless Control System (WCS)
- Supports 50 WLCs and 1500 APs
- Three versions
- Base – can determine with which APs a devices in associated
- Location – Base plus RF fingerprinting
- Location + 2700 Series Wireless Location Appliance – Tracks devices in real time and stores historical location data
- Traditional WLAN weaknesses
- SSID for security
- Vulnerable to rogue APs
- MAC filtering for security
- WEP weaknesses
- Disribution of static keys is not scalable
- WEP keys can be cracked easily
- Vulnerable to dictionary attacks
- No protection against rogue APs
- Benefits of 802.1x
- Centralized authentication through Radius via AAA
- Mutual authentication between client and auth server
- Can use multiple encryption algorithms (AES, WPA, TKIP, WEP)
- Automatic dynamic WEP keys
- Requirements of 802.1x
- EAP-capable client (supplicant)
- 802.1x-capable AP (authenticator)
- EAP-capable auth server
|User authentication DB||AD||AD, LDAP||OTP, LDAP, NDS, AD||OTP, LDAP, NDS, AD||AD|
|Requires server certs||No||No||Yes||Yes||Yes|
|Requires client certs||No||No||Yes||No||No|
|Works with WPA/WPA2||Yes||Yes||Yes||Yes||Yes|
- Authenticated key management – auths prior to key management
- Unicast and broadcast key management – keys are distributed and stored on the client and the AP
- TKIP and MIC
- Temporal Key Integrity Protocol (TKIP) – per-packet keying
- Message Integrity Checking (MIC) – integrity checking
- Initialization vector (IV) expansion – from 24 bits to 48 bits
- Relies on RC4
- Firmware support required in NICs, APs
- Susceptible to DoS attacks
- Dictionary attacks can discover PSKs
- 802.1x authentication or PSK
- Key distribution and renewal
- Proactive Key Caching (PKC) – allows roaming
- IDS for rogue APs and attacks
- Supplicant must have WPA2-compliance firmware
- AAA server must support EAP
- WPA2 uses more CPU, so a hardware upgrade may be required
- Older devices may not be upgradeable and must be replaced
- Wireless LANs (WLANs)
- Extensions to wired LANs
- Carrier sense multiple access collision avoidance (CSMA/CA) as media access method
- Uses distributed coordinated function (DCF) for collision avoidance
- DCF is based on RF carrier sense, inter-frame spacing (IFS), and random wait timers
- Wifi QoS standards
- IEEE standard
- 0-7 priority levels
- Wifi Multimedia (WMM)
- Four access categories
- Platinum (voice) – 6 or 7 802.11e
- Gold (video) – 4 or 5 802.11e
- Silver (BE) – 0 or 3 802.11e
- Bronze (Background) – 1 or 2 802.11e
- Four access categories
- WMM and 802.11e replace DCF with EDCF
- Cisco Split-MAC
- Splits functions between Lightweight access points (LWAPs) and WLAN controllers (WLCs)
- LWAPs handle real-time functions
- Beacon generation
- Probe transmission and response
- Power management
- 802.11e/WMM scheduling and queuing
- Packet buffering
- Control frame/message processing
- WLCs handle non-real-time functions
- 802.11e/WMM resource reservation
- 802.1x EAP
- Key management
- Ethernet-WLAN bridging
- End-to-end QoS
- Step 1: WLC copies DSCP from switch to outer DSCP and outer 802.1p and sends to LWAP over LWAPP tunnel
- Step 2: LWAP copies outer DSCP from WLC to 802.11e/WMM field and sent to client
- Step 3: LWAP copies 802.11e/WMM value from the client to outer DSCP and sends it to WLC
- Step 4: WLC copies outer DSCP from WLAP to 802.1p (CoS) fields and sends it to the switch
- Web interface (do you even need to know this?)
- Controller>QoS Profiles
- Per-User Bandwidth Contracts – set avg data rate, burst data rate, avg real-time rate, and burst real-time rate
- Over the Air QoS
- Maximum RF usage per AP (%)
- Queue Depth – queue size before dropping packets
- Wired QoS Protocol – 802.1p or None
- For each WLAN ID, set the QoS value: plat, gold, silver, bronze
- WMM Policy
- Disabled – 802.11e/WMM QoS requests are ignored
- Allowed – 802.11e/WMM QoS requests are sent
- Required – 802.11e/WMM QoS requests are required
- Controller>QoS Profiles
- AutoQoS benefits
- Automates QoS for most deployments
- Protects business-critical apps to maximize availability
- Simplifies QoS deployments
- Reduces configuration errors
- Cheaper, faster, and simpler deployments
- Follows DiffServ
- Allows complete control over QoS configs
- Allows modification of auto-generated configs
- AutoQoS phases of evolution
- AutoQoS VOIP – Early version that configures the basics without discovery
- AutoQoS for Enterprise – Second version that only runs on routers and uses two-step process
- Autodiscovery using NBAR
- Generation of class maps
- AutoQoS key elements
- Application classification
- Policy generation
- Monitoring and reporting
- Interfaces that you can configure AutoQoS on
- Serial ifs with PPP and HDLC
- FR point-to-point subifs (NOT multipoint)
- ATM point-to-point subifs
- FR-to-ATM links
- No Qos policy already configured on if
- CEF enabled on if
- Correct bandwidth configured on if
- IP address on low-speed if
- Configuring AutoQoS Enterprise on a router (NOT a switch)
- auto qos discovery – begins discovery process
- auto qos – generates and applies MQC-based policies
- Configuring AutoQoS VOIP
- auto qos voip [ trust | cisco-phone ]
- Verifying AutoQoS on router
- show auto discovery qos – get autodiscovery results
- show auto qos – examine configuration generated
- Number of classes
- Classification options
- Marking options
- Queuing mechanisms
- Other QoS mechanisms
- If, subif, PVC where policy is applied
- show policy-map interface – look at if stats
- Verify AutoQoS VOIP
- show auto qos
- show policy-map interface
- show mls qos maps – shows CoS to DSCP mappings
- Possible issues with AutoQoS
- Too many traffic classes – manually consolidate some
- Configuration doesn’t change – rerun AutoQoS
- Configuration may not fit your situation – fine-tune it by hand
- Fine-tuning AutoQoS
- Use QPM
- copy policy into editor, change, reapply
- AutoQoS can match on characteristics besides ACLs and NBAR
- match input interface
- match cos
- match ip precedence
- match ip dscp
- match ip rtp