mcast packets are kinda tricky when it comes to SPAN and there are various
platform caveats. If I remember right some 3K series just wont show them as
they are punted to CPU before SPAN happens. 6500 can't get mcast on TX SPAN
when doing egress replication, etc. If you don't use port channel tow
Hi Ben,
We aren't using port-channels towards the servers. However, I've just seen
another issue on a 3560 where IGMP joins/reports aren't replicated to the SPAN
session. This has got me wondering if the server was reissuing the join all
along but I simply failed to capture it.
Sam
On 9 Feb 2
Just taking a shot here but I don't think it's quite that if you have
port-channel configured on the switch side for the server link because the
hardware programing is not based on the receiver MAC it's based on the mcast
MAC. The MAC table will program a snooping entry for the mcast MAC to repl
On 9 Feb 2011, at 17:51, Phil Mayers wrote:
> On 09/02/11 16:57, Sam Stickland wrote:
>> All,
>>
>> I encountered some strange, but beneficial, behaviour in the lab. We
>> connected a server with teamed NICs to two 6500s running SXH2a. The
>> NIC teaming is active/standby using only a single MAC
On 09/02/11 16:57, Sam Stickland wrote:
All,
I encountered some strange, but beneficial, behaviour in the lab. We
connected a server with teamed NICs to two 6500s running SXH2a. The
NIC teaming is active/standby using only a single MAC and IP address.
The server joins a multicast group and start
All,
I encountered some strange, but beneficial, behaviour in the lab. We connected
a server with teamed NICs to two 6500s running SXH2a. The NIC teaming is
active/standby using only a single MAC and IP address. The server joins a
multicast group and starts receiving traffic. We found that if w
