I've been working troubleshooting an issue with a SourceFire virtual appliance. The issue is that when I setup a SPAN session within the Nexus 1000v, and send SPAN traffic from some VLANs to the monitoring port of the SourceFire virtual appliance, it only seems to see broadcast traffic, not any unicast traffic.
If I connect a linux box running OpenSUSE 11.2, and configure the monitoring port the same (it's a different port, but it's in the same vlan, has the same port profile, etc. etc.), and connect it to the exact same SPAN session, it sees everything perfectly. This is testing with the exact same TCPDUMP commands (which does put the NIC into promiscuous mode on both the Linux and SourceFire boxes, according to dmesg on each of those VMs)...
The only thing I can see that is different between the two VMs (besides the port numbers being different, e.g. veth46 versus veth48) is that the Linux box I tested with I created in vSphere 4.0, and it has VMware hardware version 7. The SourceFire virtual appliance was not created by me (nor can it be? it was supplied by SourceFire, who does not officially support the Nexus 1000v, though they do support vSphere 4.0 with VMware's distributed switch) and has VMware hardware version 4.
I'm wondering if VMware hardware version 4 doesn't work correctly with SPAN sessions, or if anyone else has had issues with SPAN sessions under the Nexus 1000v ?
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...