-
Notifications
You must be signed in to change notification settings - Fork 932
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Layer 2: Metallb shouldn't reply on interface with NOARP flag #351
Comments
@danderson , what do you thinking about using https://github.com/mickep76/netlink for identify flags on interfaces such as |
I'm not a huge fan of adding a dependency, especially one that uses syscall and unsafe. Those are hard to get right, even for experienced Go programmers. The one netlink library I trust is the one by @mdlayher . It's very well tested, and Matt's got a bunch of experience with kernel interfacing. But AFAICT, he hasn't implemented interface reading, so we'd have to add that on top of the base netlink (or genetlink? Not sure) package. I mean, with that said, if I get a PR with anything, I'll probably merge it. If it's not using mdlayher's netlink packages, I'll just file an extra bug to remind me to change it later ;) |
Ok, I'm trying to parse noarp from |
Hmm, actually, it looks like that repository is mostly just copy/pasting the linux implementation of net.Interfaces, and adding support for more flags. If we're going to just do that anyway, I would prefer it if we just copy/paste our own implementation using https://golang.org/src/net/interface_linux.go as a reference. That way we can tailor it to exactly the data we need. But like I said, if you're sending a PR, I'll merge it if it's not hugely unsafe. Worst case I'll just file a bug to think about improving it later, but that's not a big deal. |
HI, I have success with another netlink library: Can you agree to using it in MetalLB? |
I would have assumed the stdlib would have the "No ARP" flag, but apparently not. vishvananda/netlink is pretty widely used. I personally am not a big fan of some of the design choices it has made, but it seems reliable enough. The equivalent in my netlink ecosystem would be https://godoc.org/github.com/jsimonetti/rtnetlink, but this one is currently less mature and less battle tested. That said, if you can read that flag from /sys, I'd just do that instead of mucking with (route) netlink for this one tiny thing. |
Unfortunately it can't be simple readed from
The result is combination of all of them is written in I have no better idea for parse this value for and apply bitwise OR for all of them. In bash I would like to use some workaround like:
|
But all you'd need to do is read that hex value and then check that flag, right? That sounds like an easy solution to the problem rather than bringing netlink into the picture. |
You're right, I have an idea, I'll try to implement it now |
This just broke on me. Apparently new openvswitchs on el7 don't tag it as noarp and don't honour the ifcfg ARP="no" flag. :( |
My issue above is not technically a metallb fault, but its repeatedly been a problem that you can't specify an interface to listen to. Can we get support for this feature now? |
Is this a bug report or a feature request?:
Feature request
What happened:
Speaker sends replies to any interface, even if arp disabled for it
What you expected to happen:
If interface have NOARP flag set, speaker should ignore it.
How to reproduce it (as minimally and precisely as possible):
Then try to arping
Anything else we need to know?:
Related #349
Environment:
uname -a
):The text was updated successfully, but these errors were encountered: