Dice Update

After updating our 6500 switches with SUP2T supervisors and with some Nexus switches on the way, I decided to play around with ERSPAN. Being able to capture traffic from a remote data centre directly to my workstation is very useful so I took the opportunity to update Dice to correctly format ERSPAN packets.


When the ERSPAN capture is sent directly to the host running the packet capture software, the captured data is encapsulated within GRE and an ERSPAN header as above. I thought it would be useful to be able to extract the original frames from the capture so added this option as well. When you save a capture you can now request that ERSPAN captures are extracted. For example, the frame above becomes:


ASA 9.0 AnyConnect License Change

I have been looking at the new features in ASA 9.0. Two in particular that caught my eye were:

  • Allow up to eight ASA’s to be clustered
  • VPN and dynamic routing are now supported per context.

It is to be hoped that clustering, initially only available on the high-end boxes, becomes available on the smaller boxes sooner rather than later.

In the Q&A document I noticed the following:

Q. Is next generation encryption available on all ASA platforms?

A. No. Next Generation Encryption is fully supported on the ASA 5585-X, 5500-X Series, and 5580, as well as on the Catalyst 6500 Series ASA Services Module. It can only be partially supported on the ASA 5505, 5510, 5520, 5540, and 5550 due to hardware limitations. AnyConnect 3.1 or greater and an AnyConnect Premium License are also required to use next generation encryption for remote access connections.

If I read this correctly, AnyConnect with the previous generation encryption only needs an Essentials License. AnyConnect with the next generation encryption needs the much more expensive Premium License’.

The word ‘Sneaky’ springs to mind.

Cisco ACE–Oh what a calamity

Over the last few months I have been studying and testing a number of load balancers (Sorry Application Delivery Controllers) for a couple of upcoming projects. The short list includes F5 at the expensive end and Kemp in the bargain basement. As we are already using the Cisco CSS, I also looked at the Cisco ACE, available as a service module for the 6500 and as an appliance. Our core switches are 6500s, so this was, on paper at least, an attractive choice.

However just over a week ago a story broke that Cisco had confirmed that development was to stop on the ACE. Although not officially EOL’d, it seemed the ACE was following the MARS appliance and short lived ACE Web Application Firewall down the plughole.

There has followed many days of confusion, not least from Cisco, about the true fate of the product. Cisco are saying that development of the existing product will continue but the roadmap for the next generation has changed.

There is a great blog post on the subject, particularly interesting are the comments from Cisco trying to convince the author and others that the product is not dead.

You would  think a company like Cisco would have all it’s ducks in a row on this before any news was released, frankly they are putting out a confusing and unconvincing story.

It may well be that the ACE has a long and glorious future ahead of it, but I strongly suspect not. Even if it does, short of a personal call from John Chambers, who is going to believe it – certainly not I.

Christmas has come early for F5, A10 and friends.

While on the subject of load balancers, once you have issued the ‘show group’ command on a Cisco CSS, you will always have a soft spot for it:

CSS11501# show group


 The Group
      O                                O
     /|\         _._   \  O  _._      /|\
   (o\_)=="=#     |     \/ _> |      (\_)="=#
      |\          | [_] __[_] |       /|
      |/          |  | /  \|  |       \|
      ~~         /|\/|\\__/|\/|\      ~~

Annoying Cisco ASA/ASDM Bugs–Part 2

You might get an argument from Cisco that this one is a bug, but it sure is annoying:

On an ASA you can apply firewall rules in two places (in ASA 8.3 and above). Rules can be applied on an interface or globally. When applied on an interface they can operate on traffic entering the interface (incoming rules) or on traffic egressing the interface (outgoing rules).

When using ASDM to create a new rule, you can right-click on a rule and select Insert After to add a new rule after the existing right-clicked rule. When you do that you are presented with a dialog box allowing you enter the required details:


The dialog box presented allows the common details to be entered with an option to expand the dialog to include further options if needed. Selecting More Option reveals the following additional fields:


The second additional option allows the traffic direction to be set. In this example, the direction is set to In – that is the rule is an Incoming rule.

Unfortunately, the Traffic Direction is set to ‘In’ even if you are inserting a rule after an outgoing rule. If you don’t notice this, and with the unexpanded dialog box why should you, the rule is added in the wrong place and will not work as expected.

Annoying Cisco ASA/ASDM Bugs–Part 1

We have a number of Cisco ASA devices and on one high availability pair we run OSPF. We do this to allow us to exchange routes with our MPLS provider. When we first set this up we made use of ASDM to display the external routes in the OSPF database – that is type 5 LSAs. This was useful to verify that the expected routes were being redistributed to us from the providers BGP.


Unfortunately the display only listed a few LSAs with the majority missing. After some time chasing our tails to try to resolve the problem, we used the CLI to display the OSPF database and were surprised, but happy, to see all the external routes we had expected.

After some investigating we discovered that the list displayed by ASDM was being truncated at the first LSA with an address that matched an ASA object name. We reported this problem to Cisco and they accepted it as a bug (CSCtq48552 if you are interested).

Well, over a year later it still has not been fixed. I guess the moral from the story is: if in doubt use the CLI and having a bug accepted by Cisco does not mean it will ever get fixed.