Question on 6500 VSS with ASA, IDS, and NAM service modules

[kbyrd]

In my current dual-6509 Sup720 non-VSS design, I have a NAM and IDSM in each switch. I have one 6509 designated as HSRP active for all VLANs and Spanning-Tree Root Primary for all VLANs. For any routed interfaces that attach to both 6509s, I prefer the link to the primary 6509. This is so with the NAM and IDSM, I'll see both ends of flows that I'm sniffing. One 6509 provides plenty of bandwidth and the other 6509 is basically for failover.

I'm building a new data center with a VSS in mind. I want to also introduce data center firewalls with the ASA SM and use the new NAM-3s and IDSMs.

I plan on having top-of-rack switches with dual uplinks LACP across both 6509s and get better throughput without concern for spanning-tree.

I'm concerned in a VSS topology with having the ability to utilize NAM-3s, IDSM, and the ASA SM effectively with all inbound/outbound traffic on a port channel.

First, looking at the NAM-3, I have a few questions:

1) would I simply span the port channel or VLAN where I expect my interesting traffic to be?

2) if a server was connected directly to a port on the secondary 6509 in the VSS, would the NAM-3 on the primary 6509 in the VSS see the traffic flow?

3) Does it make sense to have two NAM-3s in a VSS topology, or is one sufficient?

I would assume the question on the IDSMs would be similar.....

For the ASA SM - where I would need two for high availability:

1) Could I run the ASAs as active/active in a VSS or active/standby

2) Would it matter whether or not they were in routed or transparent mode?

My concern is that the traffic entering the VSS via a port-channel from Top-of-Rack switch 1, exiting the VSS via a port-channel to Top-of-Rack switch two will not be in a state that the ASA, NAM, or IDSM service modules will be able to operate on.

Thanks in advance for any input.

[Reza Sharifi · Accepted solution]

I am not sure if NAM3 is supported on Sup-720-VS.  I know currently it is not supported for Sup-2T, but it is coming to 2T in the next 6 months or so.  Couple of comments regarding your design.  If you are planning to build a new data center, why not use Sup-2T.  I believe, Cisco is matching the price for 2T to be the same as Sup-720-VS.  The next comment I have is since you are using Top Of the Rack switches, why not use 5Ks or 7ks with VPC as you distro switches instead of 6500s?

In regards to having NAM or any other services in both 6500 or one, you would need to have it in both, because if you only have them in primary and if that switch fails you loose your service module and the line cards with it.

HTH

[kbyrd]

Hi Reza, yes, we plan on using Sup 2T. I realize that NAM-3, ASA, nor IDS2 is currently supported with Sup 2T, however I am planning for the (near) future.

7K is sized much too large for this deployment. We will have Nexus 5596 as a layer 2 aggregation, however I prefer to have a proven IOS device for Layer 3 as compared to using the relatively new NX/OS as a layer 3 device.

The NAM is a good example of potentially not having a failover service module. Although we use it to gather traffic statistics while the network is in stasis, we use it for traffic sniffing occasionally. If the NAM went offline and required a replacement, we could wait a day for SmartNet to replace it without affecting production.

My question specifically is: would a NAM in the primary 6509 of a VSS be able to span/monitor a server or other device attached to a port on the secondary 6509 in the VSS? I believe the answer is "yes", but I'm unsure of the traffic flow in a VSS.

[Reza Sharifi]

Looking at VSS documentation, it says:

In a Virtual Switch domain, the number of SPAN sessions is limited by what the Virtual Switch active supervisor can provide.

This tells me that you can only span the ports from the active switch, but then again, it doesn't specify that you can not span ports from the stand-by switch. Logically  it make sense to be able to span both switches....

http://www.cisco.com/en/US/products/ps9336/products_tech_note09186a0080a7c837.shtml#span

HTH