-
Notifications
You must be signed in to change notification settings - Fork 55
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
The agentIP selection is wrong when multi devices have same IPv4/IPv6 address #61
Comments
At first I thought this sounded like it might be running a version of hsflowd older than 2.0.39-9, when a correction was made to the automatic agent-address selection priorities. But on closer inspection the same thing might happen even with the latest version. Why? Because 10.145.240.15 is an RFC1918 address (which could easily be non-unique across a large network with multiple LANs) while fd00:0:201::5/64 has scope "global" and is therefore preferred as a more-likely-to-be-unique ID for the switch. In SONiC the fix is to just tell the switch what it's agent address should be. It's a CLI option. That overrides the automatic selection. Will that work for you? Note: another way to do this would be to put a thumb on the scale by adding something like: agent.cidr=10.245.0.0/16 to the file /etc/hsflowd.conf inside the sflow container - which bumps up the priority of 10.245.0.0/16 addresses. But that seems awkward for SONiC. That way only really makes sense when the hsflowd.conf config file is easily accessible and is being set by something like Puppet, Kubernetes or DNS-SD. |
The issue is that automatic agent-address selection doesn't work when there are same address for different interfaces, since the Hash key of LocalIP has no interface name. Configure agentIP explicitly is ok, however it's a new feature for SONiC... |
I see what you mean now. The setting "agent=Loopback0" is supposed to boost the chances of a Loopback0 address being chosen here: This example is a little confusing because even if it worked correctly it might still have picked the global fd00:0:201::5 address, but I can see that there might be some scenario where the address is chosen wrongly because the boost is not applied. |
I believe this is now addressed in master-branch. Let me know if you need a release to test. |
There is now a release that has this fix: 2.1.03-1. |
We used hsflowd in SONiC.
Issue:
The IPv4 address priority should be higher than IPv6 per hsflowd design "EnumIPSelectionPriority".
But it selected the IPv6 address wrongly:
The device Loopback0, Loopback1001, Loopback1002 belong to different VRF so then can have same IPv4/IPv6 address:
But in function "readInterfaces", the HASH key of localIP/localIP6 has only IPv4/IPv6 address without dev/ifname.
In our example, Loopback0, Loopback1001, Loopback1002 have same IPv4 address "10.145.240.15/32".
But after "readInterfaces", the "localIP" has only one "10.145.240.15/32" for "Loopback1001".
Then agent "Loopback0" can't select correct agentIP.
The text was updated successfully, but these errors were encountered: