ERSPAN v.s Promisc Mode

The AMD isn't a ERSPAN destination, so can't receive that traffic.

Now - the following is unsupported/untested, just something I've given some thought to as this has been raised at a customer I deal with.

There are two (that I know of) potential options to add ERSPAN end point capability to a linux server, these may or may not - I never got to a testing phase as I don't have a switch that can do ERSPAN available to me - work.

• Gulp - http://staff.washington.edu/corey/gulp/
• RCDCap - http://sourceforge.net/projects/rcdcap/

The IP address on the ERSPAN is not necessarily connected to the  destination interface of the AMD it is specifically used to terminate the tunnel and can simply belong to the switch itself, you can also then use local SPAN to take the ERSPAN destination port and "mirror" it to the desired output/destination port. As Chris points out the AMD is not capable of terminating ERSPAN, which is why it needs to be terminated on the switch itself. There may be other caveats associated with this which is why you're not seeing any traffic on the AMD, for ERSPAN to work any switch or device the tunnel passes through must be capable of supporting ERSPAN otherwise the header will not be recognized and teh tunnel will not establish correctly. In your set up how do you traverse between the two enclosures, you need to ensure that any devices on that interacting path is ERSPAN capable.

As always - looking at virtual TAPs is a viable option, though not cost neutral.

They usually have the capbilities to direct themselves to other ports and enclosures and specifically designed to do so, something that isn't always the case with the various SPAN capabilites that initially was a bolt on solution to get insight into switches and now how become a troublesome legacy solution.