1 of 1 people found this helpful
The anti-spoofing can be disabled using the latest iproute2 utility. I believe you will likely need the latest igb driver and maybe kernel as well.
I'm pretty sure the spoof checking is only for VF's - are you using SR-IOV?
Thanks for the response Patrick.
No luck with iproute2 here. I'm using RHEL 6.3 x86_64 (2.6.32-279.el6.x86_64 kernel). Don't think it is available for this distro. iproute is installed though. I'm using the igb driver that comes with the kernel - 3.2.10-k.
I'm not sure what you mean by VFs or SR-IOV. I am using a server with an onboard quad port I350AM4 adapter.
1 of 1 people found this helpful
Well if you don't know what a VF is, then you are definately not using it :-)
Went and double-checked the datasheet for the Intel I350 (available at Intel® Ethernet Controllers).
The anti-spoofing feature is only used when Virtual Machines are assigned to specific and dedicated VF. Since it does not sould like you are using SR-IOV and the VF's it creates, I doubt that our anti-spoofing is the issue.
If you can figure out how, you can look at the Wrong VM Behavior Register (0x3554) and see if it is registering some malicious behavior. The register is documented in the datasheet.
I think you can use ethtool to access some specific registers - however I'm not sure, way out of my confort zone :-)
Thanks Patrick. Sounds like we need to look elsewhere for why Resonate isn't working.
I've got a couple more related questions.
When does antispoofing come into play?
Is the antispoofing a feature of the NIC and driver?
Antispoofing is part of the NIC and is configured by the driver. What it does is it makes sure that a Virtual Machine is not trying to send packets with an invalid VLAN or MAC address when using SR-IOV.
So a VM is assigned a MAC address and maybe a VLAN, and if that VM attempts to send a packet with a MAC or VLAN that doesnt' match what has been assigned to it, that packet will be dropped and all future traffic is disabled from that VM until it has been reset by the hypervisor.
Hope that helps.
We're not using VMs here. All physical boxes.
It does look like the antispoofing feature is causing a problem for us. I forgot to mention earlier that we are also using Oracle T4-1 boxes, which have onboard igb nics. All of them have the same issue with Resonate.
If you're not familiar with Resonate, it is a server-based load-balancing app which is dependent on spoofing. With no way to disable the anti-spoofing feature, we're having to scramble for new NICs for our Linux boxes (which use e1000e driver). For the Oracle boxes we're lucky that they have some nxge interfaces and are moving connection used by Resonate to it.
It would be helpful if your developers could at some point add an option in the drivers to disable anti-spoofing.
I am sorry you are having challenges. I can assure you with 100% confidence that with our drivers, the anti-spoofing capabilties are only enabled for SR-IOV. I have dug into the docs myself, and gone and asked the guys who write the drivers. This feature is only available under a SR-IOV environment, and we provide via iproute2 a mechanism to turn it off if needed.
To be sure you are not using SR-IOV, can you maybe to a lspci and grep for 'eth' (case insensitive) and see what is displayed.
I didn't see anything about SR-IOV in lspci output, but I believe the I350 is "SR-IOV Capable" (whatever that means).
Then I assume it only showed 4 Intel I350 ports. This means that SR-IOV is not active and it also means that there is no possible way that any of our anti-spoofing technology is activiated, as it only works in SR-IOV mode, as that is what it was designed for.
The I350 is an extremely popular device - deployed in very high numbers, this is the first that we've heard of any issue. I'm sure we would be happy to work with Resonate if they woudl like to contact us so we can work together to figure out the issue.
These devices are used without issue with the standard linux bonding driver, which supports load balancing as well.