Are YouTube, Bittorrent, and Skype chewing up your bandwidth and productivity? The Cisco Cat6K Sup32-PISA can help!

The Cisco Catalyst 6500 supervisor engine 32-PISA is the fastest and most feature rich access layer sup engine Cisco has ever produced. The PISA is the result of years of R&D research and testing. For the first time ever, Cisco has added a special Network processing unit (NPU) daughter card to the sup32 engine. It is called the programmable IP Services Accelerator or PISA for short. The PISA NPU consists of 16 micro engines and a hardware crypto card. The big advantage of the PISA architecture is that, unlike asic technology, you can re-program the PISA micro engines whenever the need arises. This means the shelf life and flexibility of the PISA will be longer than an equivalent asic based solution. Not even Cisco’s sup720 has this kind of technology. The beauty of the thing is that the underlying architecture, code base, and PFC are the exact same as the venerable supervisor 32 engine. This means that the same features the original sup32 supported will be supported in the new sup32-PISA. *minor caveats/differences do exist though so be sure to read the release notes.

In addition to the PISA NPU daughter card, Cisco has also beefed up the MSFC of the original Supervisor 32 itself thus making it even faster than the current non-PISA Sup32 card. Here is a side by side comparison of the two.

So what does this PISA thing do you ask? Well here are just some of the problems it can help solve on your network:

Problem #1: Need to know what applications are running across your network, at what rate/percentage, what are the top bandwidth sucking applications per port, per switch, and per campus. Once identified you need a way to control, prioritize, or block their use. For example, being able to rate limit non-business apps like peer-to-peer and YouTube while giving QoS priority to RTP voice and video streams, citrix, DiCom, and MS Exchange flows. Bottom line is you need deep packet inspection to be able to prioritize data on a per application basis.

Solution #1: Today the PISA will hyper accelerate both NBAR (network based application recognition) and FPM (flexible packet matching) features. In fact the PISA can sustain 2Gbps of throughput for NBAR and FPM inspected flows. NBAR has been around for a while now in IOS routers. In a nut shell, NBAR gives a router the ability to identify and classify applications on the network using deep packet inspection methods. NBAR has it’s own application recognition language called PDLM’s (Protocol Description Language Module).

Currently NBAR can recognize over 90+ applications using Cisco PDLM’s but you can also create your own custom PDLM’s. PDLM’s are very small files that are downloaded to the router/switches flash memory. This means that to support a new PDLM application all you have to do is download the new PDLM to flash, no code upgrade need and no switch downtime. For a current list of available PDLMs see here.

NBAR’s app classification feature is super easy to configure. It is a one line cli command and can be configured per switchport. Once it is turned on you can then gather all sorts of useful traffic statistics like those shown below:

Problem #2: Need the ability to control and block applications that tunnel through port 80 (or any other well known port). This requires the switch to be able to identify applications by their data payload not just their TCP/UDP port ranges. For example, you need to be able to control or block skype, YouTube, and kazaa traffic but allow normal html traffic, all of which use port 80 for transport. This type of inspection requires IP payload inspection along with the knowledge of how to finger print these applications reliably.

Solution #2: Again, NBAR can be used to identify, classify, and rate limit tunneling applications. Or you could use flexible packet matching (FPM) instead. FPM is basically an access control list (ACL) on steroids. An FPM ACL understands all parts of the IP packet including the data portion. This allows you to use FPM to stop worms and viruses from entering your network. Worms like slammer were hard to stop using a normal ACL because it meant you had to block a business application port to do it. In slammers case you had to block port 1434 the same port used by SQL. Using FPM you can match on port as well as payload information like shown in the figure below.

You can find more information about FPM here.

Problem #3: Need the ability to control/block traffic flow using deep packet inspection. This includes matching on any and all IP packet information, including at the application layer. In some cases an extended port based ACL just doesn’t fit the requirements. You need an application aware ACL that can protect you against worms and viruses that run across the same ports that your legit business application use.

Solution #3: This is the perfect fit for using Flexible Packet Matching. An FPM is very much like an IPS signature. It matches on a signature and can then take one of multiple actions like drop, log, permit, or rate-limit. Read the FPM FAQ for more information.

Problem #4: Need a more efficient way to recognize and prioritize IP voice traffic. Currently, networks rely on matching TCP/UDP port ranges to identify what is IP voice traffic. This method is inefficient and in some cases inaccurate. Need a method to be able to identify voice traffic (SIP, Skinny, H.323, softphones, RTP, etc.) using deep packet inspection at the application layer of the IP packet.

Solution #4: NBAR has PDLM’s that can recognize, classify, and mark all sorts of IP voice traffic. This includes SIP, Skinny, H.323, softphones, and RTP to name a few. This really comes in handy for prioritizing soft phone client traffic coming for a laptop. NBAR can even recognize the difference between a voice and video stream in a SIP call. Here is a great whitepaper on NBAR and RTP classification.

Problem #5: Need the ability to QoS prioritize traffic based on a url or hostname. In many cases one web server will host many different web sites/applications. Some are more critical than others and need to be prioritized on the network appropriately. Because they are all on the same port (80) and same host IP you can’t use an extended port based ACL to match on in a QoS policy. You need to be able to match on the full/parial URL string.

Solution #5: NBAR is the way to go for detailed http per flow specific QoS markings. NBAR allows you to classify flows based on URL, hostname, MIME type, and HTTP header fields. See the NBAR configuration docs here for more info.

The Cisco Catalyst supervisor 32-PISA engine comes in two flavors, the difference between the two being what physical Ethernet ports they have. One has (8) gigabit SFP ports + 1 10/100/1000 copper port the other model has (2) 10GE ports + 1 10/100/1000 copper port. For more PISA information see here.

Cisco is currently looking for customers to be beta testers for their upcoming 12.2(18)ZYA code on sup32-PISA. This code will include lots of new PISA features, like L2 trunk support and redirecting traffic to PISA using an ACL match instead of per switchport. If you have the time and are interested contact your Cisco account team to get signed up.



The opinions and information presented here are my personal views and not those of my employer.