Hi Just,
yes this is an important point. The anycast_healthchecker is/was on the
list for possible solutions. But because of the mentioned problem I'm
thinking of keepalived between bind and bird.
bind starts then keepalived checks some dns stuff, if successful it pushes
the anycast addresses to the dummy interface then bird grabs these
addresses and announced them upstream.

When briefly looking at anycast_healthchecker I had seen a withdraw
functionality upstream, but not whether also addresses of interfaces can be
removed so that the local system uses the anycast addresses from another
dns server.
On the other hand, I think keepalived is not really meant to run on one
node only (even if it seems to work at first).

Regards,
Robért

On Tue, 24 Oct 2023 at 20:29, Justin Cattle <j...@ocado.com> wrote:

> Hi Robért,
>
> If you are implementing anycast, it often makes some sense to, and you may
> already have, some automation which health checks the local instance of the
> service on a node to make sure that the service which the VIP is fronting
> is still functional on that node.
> You can use that automation as a hook to add/remove advertising of the
> prefix for the VIP, and even add/del the IP from the dummy interface.
>
> In the past we've leveraged the framework provided by the project below,
> however I've not used it recently so can't vouch for its current state.
> I would suggest taking a look at least for some inspiration, and a
> starting point.
>
> https://github.com/unixsurfer/anycast_healthchecker
>
> Hope that helps.
>
>
> Cheers,
> Just
>
>
> On Tue, 24 Oct 2023 at 18:25, Robért Guhr <rg...@cronon.net> wrote:
>
>> Hi,
>> I see - thanks for the feedback.
>>
>> Regards, Robért
>>
>> On Tue, 24 Oct 2023 at 19:07, Maria Matejka via Bird-users <
>> bird-users@network.cz> wrote:
>>
>>> Hello Robért,
>>>
>>> BIRD basically doesn't set IP addresses to interfaces. This is a design
>>> choice of the current team. Please use external tooling for this.
>>>
>>> To elaborate a bit more, because we get these kinds of questions
>>> repeatedly → Implementing of this feature would open a huge can of worms,
>>> or a very large rabbithole (choose your best option) of features:
>>>
>>>    - setting tunnel endpoint IPs
>>>    - implementing DHCP client
>>>    - implementing VRRP
>>>    - creating and destroying tunnel interfaces
>>>    - setting interfaces up and down
>>>    - setting up wireguard links
>>>    - …
>>>
>>> Yes, we could become another NetworkManager … and to be honest, I
>>> sometimes wish to go this way when seeing how badly NM is handling some
>>> specific corner cases. Anyway, it's a lot of work. A LOT of work. An
>>> absurdly huge pile of hard work to get there.
>>>
>>> Of course, if there is demand for this, and we are closely monitoring
>>> what the users think and wish, we may rethink this design choice.
>>>
>>> Thank you for your understanding
>>> Maria
>>> On 2023-10-24 17:29, Robért Guhr wrote:
>>>
>>> Hi,
>>>
>>> is it possible to set an ipv4 address (e.g. "10.186.100.11/32" ) via
>>> bird on a dummy interface called "anycast"?
>>> I mean via the bird config not via bgp/ospf pushes.
>>>
>>> Background:
>>>
>>> I have setup four DNS server in two sites. All these DNS servers
>>> announces 10.186.100.11/32 (and 10.186.100.12/32) up to the routers to
>>> create an anycast environment.
>>> Currently 10.186.100.11/32 (and 10.186.100.12/32) are set fixed on the
>>> dummy interface. Bird just imports these IP addresses.
>>>
>>> We would like to use 10.186.100.11/32 and 10.186.100.12/32 as resolver
>>> in /etc/resolv.conf
>>> But if we stop the local DNS server then the dns resolution is no longer
>>> possible because the addresses are hardcoded on the local interface and the
>>> other three dns server will not be used.
>>>
>>>
>>> Idee was to set the ip addreses via bird so that when we stop Bird and
>>> the local DNS server, we automatically forward the DNS requests to the
>>> other three servers.
>>>
>>>
>>> I was hoping the direct protocol converts a route also to an ip address
>>> but this seems not to be the case.
>>> With the kernel protocol I can export the route to the kernel routing
>>> table but that is not was I was want.
>>>
>>> pns-b2-ns02 ~ # cat /etc/bird.conf
>>> # Ansible managed
>>>
>>> router id 10.186.244.12;
>>>
>>> protocol device {
>>>   scan time 10;
>>> }
>>>
>>> protocol direct {
>>>   ipv4 {
>>>     import none;
>>>     export all;
>>>   };
>>>   interface "anycast";
>>> }
>>>
>>> protocol static {
>>>   ipv4 {
>>>     import all;
>>>     export all;
>>>   };
>>>   route 10.186.100.11/32 via "anycast";
>>> }
>>>
>>> protocol kernel {
>>>   ipv4 {
>>>     import none;
>>>     export all;
>>>   };
>>> }
>>>
>>>
>>>
>>>
>>>
>>> pns-b2-ns02 ~ # birdc show route; echo; ip a show dev anycast; echo; ip
>>> r | grep 10.186.100
>>>
>>> BIRD 2.13.1 ready.
>>> Table master4:
>>> 10.186.100.11/32     unicast [static1 17:22:18.282] * (200)
>>> dev anycast
>>>
>>> 4: anycast: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state
>>> UNKNOWN group default qlen 1000
>>>     link/ether 8e:b5:2b:bf:0d:5e brd ff:ff:ff:ff:ff:ff
>>>     inet 10.186.100.9/32 scope global noprefixroute anycast          #
>>> <----- here should also be the address 10.186.100.11/32
>>>        valid_lft forever preferred_lft forever
>>>
>>> 10.186.100.11 dev anycast proto bird scope link metric 32
>>>
>>>
>>>
>>> Regards,
>>> Robért
>>>
>>> --
>>> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>>>
>>>
> Notice:
> This email is confidential and may contain copyright material of members
> of the Ocado Group. Opinions and views expressed in this message may not
> necessarily reflect the opinions and views of the members of the Ocado
> Group.
>
> If you are not the intended recipient, please notify us immediately and
> delete all copies of this message. Please note that it is your
> responsibility to scan this message for viruses.
>
> References to the "Ocado Group" are to Ocado Group plc (registered in
> England and Wales with number 7098618) and its subsidiary undertakings (as
> that expression is defined in the Companies Act 2006) from time to time.
> The registered office of Ocado Group plc is Buildings One & Two, Trident
> Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
>

Reply via email to