Some tidy ups and allow manual IP specification rather than auto-detection

[coling]

I found I was unable to get BGP working properly when dealing with network namespaced containers.

While I appreciate I could use frr for this purpose, I found a nice, self contained tool was also quite handy considering the whole point of a container image is to keep things very much "contained" and requiring large software packages to support the container to be installed on this host machine is not overly desirable.

Happy to discuss the approach or tweak the options slightly if so desired.

There are also a couple of minor drive by changes, but these may not be desired and happy to rework the PR to exclude these.

Thanks for considering.

[tobymitico]

Hi Colin,
sorry for the delay and thanks a lot for the PR. so in your use case if I read this correctly you basically don't make use of the "autodetect" feature at all and inside your container you don't configure any IPs?

so my suggestion here would be that we do either one other the other. in other words as soon as one specifies custom/manual IPs autodetect should essentially be turned off completely and only the IPs defined are announced.
that would cover another use case that we are in need to address: if someone would like to run a active/active setup with 1 elastic being advertised as primary on another second elastic as secondary on a second instance. disabling autodetect would allow a user to run 2 instances of lelastic one as primary and one as secondary (when not using containers) and just simply announce IPs accordingly

[coling]

Sounds good! Your suggestion works for my use case certainly and I can see the value in that way of working for your use case.

I'll rework the patch a bit shortly and resubmit. I'll also make the netmasks optional when specified on the command line as that feels a bit unnecessary.

[tobymitico]

cool thx.
I think it'd be ok to require the prefix length. it makes not much sense for v4. but for v6 it could be. and since we bypass "auto" mode may as well go all in on manual :) for v4 I would just keep it for consistency....
in v6 I can see it helpful in case we add more subnet options later on and/or if someone wants to mix and match /64+/56. I could go either way though

[stephenreay]

Is this feature usable? Is there something preventing it being merged? It seems like it would solve our use case too, as we need to migrate our balancers due to the change to BGP in Dallas DC.

Our setup is two active balancer machines, and two floating IPs, one public, one private; each balancer serves as a primary for one IP, and a backup (or 'secondary') for the other IP.

From what I can see the existing release of lelastic won't work for us because

• (a) it doesn't support a node being the primary for one IP and the secondary for another
• (b) it requires the use of a /32 for IPv4 addresses, but Linode private IPs are /17's I blame a lack of coffee for this. I read and wrote /32 while thinking /24 in my head, expecting it was doing something with the net mask.

[alexgurrola]

From what I can see the existing release of lelastic won't work for us because

* (a) it doesn't support a node being the primary for one IP and the secondary for another

@tobymitico This is the same issue for our setup. We have 8 Load Balancers and each is a secondary for the other IPs, in order, so if node001 is offline, node002 takes the traffic and so on. This was possible with heartbeat, but I don't see any support in this project to handle a design like this.

[tobymitico]

I'm very sorry for being slow here, its been busy ;/

I hear you all. and I think you all have a valid point and we should add this feature as you describe it.
however I'd be cautious adding advertisements blindly for IPs that are specified by users. it allows to much human error. i.e. if the IP is not configured on the system itself it would blackhole traffic and take a system offline.
so at the very least I'd like to adjust this PR so that we can detect local configured IPs - as it is now - but allow the user to further filter that list down so that only IPs specifically listed AND found would be advertised

but the use case of having 2 linodes in active/active where each other would take over the load would still not be satisfied with this change.
one instance of lelastic is only able to run either primary or secondary so you'd have to run 2 different instances of lelastic which our network will not accept and you end up flapping both. so that would entail more work than just this described here.

I also wanna be sure we cater to the right target group for this tool. this is really just intended for very very very VERY basic usage of elastic IPs to get started for users with little to no network knowledge.
we fully support any other bgp client. so for anything more advanced I would suggest to just use classic gobgpd from upstream. that should very easily be able to accommodate any possible individual (supported) scenario :)