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
Allow ipv6addr to mark new address as deprecated #68
Comments
Hi, I don't have much knowledge about such configuration, but isn't address labels usable for your purpose by any chance? If we need to add a such options anyway, I would prefer using ip command rather than writing a C code in IPv6addr. Otherwise we could add some C code for IPv6addr RA but the new parameter would be very specific only for this purpose. Just for my curiosity, if you don't mind, could you tell me why do you need to preserve a static source address rather than using a virtual address? Because most of users around me want to always use the virtual (newly added) address as the source address (that's why IPsrcaddr exists in IPv4), otherwise the source address would changes every time a fail over occurred. |
First off, thanks for responding. Re: using labels for address selection, I am not an IP stack expert but I don't think it's an option. By the way I read it: Using labels is good if the destination address you're requesting is 1::1 and you are choosing between, say, two global addresses 1::1 and 2::1 -- it will choose the one with the shortest matching prefix. Or, a global address over one configured link-local. But since my global addresses are all on the same /64, they all pass the label rules the same. I'd love to be corrected on this, but I haven't found anything on the web indicating a way to use labels to select one of many same-subnet addresses. I think your suggestion of a more flexible ip command RA is best; that way you can pass any options accepted by ip (there are a lot...) the preferred_lft flag being one of them. And my reasoning is mostly with respect to predictability; calls from a server to, say, an API may be subject to IP restrictions and I shouldn't have to go back and edit those to accommodate whatever address gets added "last" at any particular time... and B) why not -- IPv6 is kinda a hobby and I'm interested in figuring it out. It's easy to accomplish this with IPv4, since the tiebreaker rule is the opposite - the FIRST address configured is the source, all other things being equal. |
Hi, I have been investigating related to this and I now consider that it could be solved using address labels by the command something like:
Would it work for your purpose too? for more details and the related discussion, please see here: I would appreciate for your any comments. |
Closing as #158 has merged. |
It would be nice to be able to preserve a single source IPv6 address on a host after additional addresses (usually a /64) are added to the interface. It appears most people (including me, outside the HA framework) are accomplishing this by passing preferred_lft 0 to ip addr. However that doesn't appear to be an option right now with the ipv6addr ocf agent.
I'm not much of a C programmer or I'd submit a patch. Figured I'd add an issue, though, to get some thoughts on this idea. Perhaps there's a better way to accomplish this, but I haven't found it? I tried to research using gar.conf, but it appears to be focused more on destination address selection than source addressing.
The text was updated successfully, but these errors were encountered: