Problem to Solve — How can I make sure that my Cybersecurity Tools and Solutions will work in a Cisco Nexus Environment with VN-Tags?

Ok, maybe not my best lead in for a Blog article analogy.   What in world does a Cisco VN-Tag have to do with badges? To be frank, nothing … but who doesn’t remember the phrase from movies past?    (Just in case, a YouTube link to refresh your memory from the Blazing Saddles movie… ) Badges? We don’t need no stink in’ badges !!  Why the analogy reference?  Well, if you are planning to leverage a non-Cisco based security solution into your enterprise Cisco network with Nexus 9k/7k/5k/2k Switches, then keep reading. But first, what is an aggregation switch again?

Aggregation Switches Facilitate Sharing with Tools-Solutions

There are many different types of use-case deployments for putting in an aggregation switch. In a nutshell, aggregation switches are deployed to facilitate different tools and solution sets sharing network traffic to do their expected role. Examples of different types of tools-solutions to connect could include, but not limited to the following:

• Packet Capture Appliances
• VoIP Monitoring software
• Application Monitoring software
• Security tools – IDS, IPS, Malware Detection
• Compliance Solutions
• Transaction Monitoring
• Data Loss Prevention solutions

The challenge becomes that, in many cases, all of these toolsets want to leverage and utilize an existing SPAN port from the Cisco network. While there are other ways to “skin this cat” (e.g. TAPs, VACL’s), there are usually only two (2) specific SPAN monitor ports per switch. When you have 6+ toolsets that want to use the same SPAN ports, then you see where the problem lies. The Aggregation Switch solutions provided by vendors such as NetScout, Gigamon, VSS, Anue, Apcon, etc. all have their particular value-adds and differentiators, but all of them are designed to share, distribute, filter and deliver data to these toolsets. They solve the problem as the two SPAN ports from a particular switch can be connected first to the aggregation switch, and then the aggregation switch will copy / filter / condition the traffic to the respective tool solutions.

Considerations for Security Tool Deployment

1) Cisco VN-Tag Stripping – In a Cisco Nexus network deployment, there are typical VN-Tags leveraged between Nexus parent switch and Nexus fabric extender switches. A VN-Tag is inserted into each frame exchanged between the extender switch and the Nexus parent switch. This modifies the standard ethernet packet structure.  I have found that most tools sets (application or security solutions) rarely have native Cisco VN-Tag support in their devices.

Why is this Valuable?  The lack of VN-Tag support makes it critical for the aggregation switch to support “stripping the tags” away from the packet prior to delivering to the actual tool set being able to consume the packets. Otherwise, the security tool may not work as you would expect, because is may not understand the packet structures.

2) Packet De-Duplication – this feature employs removing duplicate packets from the network so the actual tool set (application or security solutions) doesn’t have to “double processing” of the same packet.

Why is the Valuable? Some aggregation switches perform this function, and some do not. In some cases, the actual end consumer tool device will have some type of de-duplication functionality on board.   I have found this de-duplication functionality to be rarely available in the actual toolsets however.

3) Easy to use GUI – Doesn’t seem like a big deal, but once you have multiple tool sets for multiple parties (Application, Network, Security, Compliance, etc.), this becomes a real value add.

Why is this Valuable? It allows day-to-day administrators across teams/silos, with various skill levels, to create drag-and-drop topologies in a GUI to do aggregation, filtering, load balancing. Some vendors create libraries of topologies and filters once, and then share and reuse them to lessen the administrative burden.

4) Multiple Domain Support — Typically, separate use case “domains” are created, so different teams can be assigned their own ports/tools, and they can build topologies and do monitoring independent of other teams.

Why is this Valuable? Minimizes impact of changes to a particular filter / condition / stream, etc. I.E. The application team will not affect the security team’s settings. No sense having your teams squabble over change controls and inadvertent configuration changes that “mess up” the traffic flow and filters to their toolsets.

5) Port Density & Expandability– one of the key pieces to think through is number of ports (1 for each SPAN connection, 2 for each TAP) that will need to be connected as inputs, as well as necessary ports for the actual tools solutions to connect. I would also suggest that you factor in and allow for growth in your deployment.

Why is this Valuable?   Experience has shown me that once this type of setup is configured, companies and departments will find all types of interesting and business relevant use cases in which to take advantage. Might as well plan to be the case up front so you can accommodate the unforeseen use cases that require more ports.

While these are not the only considerations for every deployment use case, this is what I have seen in my customer deployments as the key decision points.

Until next time …..