Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

IDS network design

using standalone (N)IDS what are the options (pros-cons) for the connectivity design. All 10/100 switched environment for this application. portspans,VACL's,TAP's or specialized active IDS balancer's. A broad question, but I am looking for some input from experience out there. The proposed environment is all IOS based no CAT(OS) some concern (a lot) with the limited span sessions on some platforms. Targeted environment is more of a segregated design with need of traffic monitor at static set points of transition, no dynamic changes to the monitor points are anticipated. I know that just using span sessions will not cut it, but need a solution for the design phase. Hardware Tap's look like a solution, but I understand you still have to combine the two tap monitor ports via another hub or device. The monitor points will be multiple with multiple standalone (N)IDS at distributed locations within a single physical data room. Would like to get the design half-way right so any comments from past experience are welcome.


  • Other Security Subjects
Cisco Employee

Re: IDS network design

Span sessions work well for IDS, but is often unacceptable to the network administrator who needs the span session for network troubleshooting.

On higher end switches that support multiple span sessions, this is much less of an issue than lower end switches that may only support a single span session.

Caveats for Span:

1) Most switches have limited number of span sessions.

2) Some switches may not support receiving TCP Reset packets in from the sensors on Span destination ports, while others require special flags be used on the span session to allow incoming traffic.

As for Taps, there are 2 outputs from the tap (as you've already know). In older sensors that supported only a single sniffing interface the 2 outputs had to be connected to a hub or low end switch and then connected to the sensor for monitoring. Newer sensors support multiple sniffing interfaces. There is a 4 port 10/100 card that can be placed in the IDS-4215, IDS-4235, and IDS-4250 to increase their monitoring capability to 5 ports with the version 4.1 release of the software. The sensor can combine the packets from all 5 ports when doing the monitoring. So with these sensors you could take the 2 outputs from the taps directly to 2 sensor monitoring ports.

Caveats for Taps:

1) Cisco does not officially support Taps for monitoring when the 2 outputs from the taps are directly connected to 2 sensor monitoring ports, but it should work fine.

2) TCP Resets do not work with Taps. So if your deployment will require the ability to do TCP Resets then you need to look at another alternative.

VACL Capture is another possible alternative if using the Catalyst 6000/6500 switches. It gives you similar functionality to the Span sessions with a little more granular control of the traffic you want monitored.

In all 2 scenarios you need to be aware that the sensor needs to see both sides of the connections the sensor will be monitoring (client packets + server packets).

When using span, this may mean using tx+rx to get both directions of traffic when doing port based span, but may mean only having to do an rx span if doing vlan based span (a tx+rx in a vlan based span may result in duplicate packets being sent to the sensor).

When using Taps this means the sensor needs to see packets from both outputs of the Tap.

When using VACL Capture, the VACL needs to mark both directions of the traffic for capturing.

Another thing to keep in mind is the possibility of assymetrically routed traffic. In certain network topologies, the inbound traffic may be sent through one set of devices/routers, while the outbound traffic may be sent through a different set of devices/routers. This can happen in high availability environments where both routers are actively routing traffic. A single sensor would need to monitor the traffic from both sets of devices/routers in order for that single sensor to see both sides of each connection.