I'm sorry to hear you're having problems with duplicated packets on the XL710 adapter. I think the problem here is that the tcpdump program will normally request that the capture device enter "promiscuous mode". However, the XL710 semantics for promiscuous mode have changed from previous Intel products. In our previous products promiscuous mode only referred to the physical interface so that packets appearing on the physical port would be captured no matter what their MAC address was. The XL710 has additional support for VEB bridge configuration and promiscuous mode will now also apply to any Virtual Station Interface (VSI) such that any packet sent from any VSI, including the main VSI, will also be replicated and copied back.
There are two ways to avoid this behavior. One is to use a filtering utility to add the source MAC address of the ARP packet to the main VSI filters. In Linux you can use the bridge utility to do this.
'bridge fdb add ...' <see the bridge utility man page for specifics>
Another alternative is to use not use promiscuous mode on tcpdump. You can turn off promiscuous mode on the tcpdump utility by specifying the '-p' option.
I hope this helps resolve your issue. If you have further questions do not hesitate to contact us for more help.
- Greg Rose
So, I presume this is intended behavior? This means that implementing a simple learning bridge would not be possible with the XL710. Both workarounds would break a normal learning switch.
I guess the confusion lies with the standard assumption that a bridge generally floods frames to all ports except the port it received the frame on.
Is there any way to force a direct mapping between the VSI and the physical port?
- Jan Gutter
No, this is not intended behavior - it is a problem with source pruning. It will be fixed in future products but for now we are stuck with the "feature" on the XL710. The part could be used in a learning bridge scenario as long as a SW work around for the source pruning issue were implemented. Using the 'bridge fdb add' command is essentially a manual work around for the problem.
With the SW workaround in place then the mapping between the main VSI and the physical port is direct in most cases I can think of but I can't say for sure that I've seen all corner cases, etc.
We have a patch making its way upstream and will be in our next release to work around this issue (as long as you're not trying to use SR-IOV, or NPAR modes on the adapter)