Today Cisco announced their new CRS-3 that replaces the CRS-1.  The CRS-3 has some damn impressive numbers for sure with 322Tbps, or about 1 LOC/sec (that’s a Library of Congress per second).  In three to five years, it might enable some technologies that we can’t use today, but I think “chang[ing] the Internet” is a bit of a stretch.  I’m sure it’s ultra-cheap, too.

CRS-3 in Action Demonstration

John Chambers Introduces the CRS-3

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.

No matter how many NMap scans cycled through, the class never incremented a bit.  I let it run for two full minutes and generated a few hundred HTTP packets, but there was still nothing.

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.

Send any Cisco learning credits questions my way.

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.

Send any ROUTE class vouchers questions my way.

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.

• 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

WLAN Implementation

Autonomous and LWAP

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

• WPA
  • Features
    • 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
  • Shortcomings
    • Relies on RC4
    • Firmware support required in NICs, APs
    • Susceptible to DoS attacks
    • Dictionary attacks can discover PSKs
• WPA2
  • Features
    • 802.1x authentication or PSK
    • Key distribution and renewal
    • Proactive Key Caching (PKC) – allows roaming
    • IDS for rogue APs and attacks
  • Shortcomings
    • 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