<div dir="ltr"><div>Hi Just,<br>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.<br>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.<br><br>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.<br>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).<br><br>Regards,<br>Robért</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 24 Oct 2023 at 20:29, Justin Cattle <<a href="mailto:j@ocado.com">j@ocado.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Robért,</div><div><br></div>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.<div><div><div dir="ltr" class="gmail_signature"><div>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.</div><div><br></div><div>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.</div><div>I would suggest taking a look at least for some inspiration, and a starting point.</div><div><br></div><div><a href="https://github.com/unixsurfer/anycast_healthchecker" target="_blank">https://github.com/unixsurfer/anycast_healthchecker</a><br></div><div><br></div><div>Hope that helps.</div><div><br></div><div><br></div>Cheers,<div>Just</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 24 Oct 2023 at 18:25, Robért Guhr <<a href="mailto:rguhr@cronon.net" target="_blank">rguhr@cronon.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi,<br>I see - thanks for the feedback.<br><br>Regards, Robért</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 24 Oct 2023 at 19:07, Maria Matejka via Bird-users <<a href="mailto:bird-users@network.cz" target="_blank">bird-users@network.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p><font face="Gentium">Hello Robért,</font></p>
<p><font face="Gentium">BIRD basically doesn't set IP addresses to
interfaces. This is a design choice of the current team. Please
use external tooling for this.<br>
</font></p>
<p><font face="Gentium">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:</font></p>
<ul>
<li><font face="Gentium">setting tunnel endpoint IPs</font></li>
<li><font face="Gentium">implementing DHCP client</font></li>
<li><font face="Gentium">implementing VRRP</font></li>
<li><font face="Gentium">creating and destroying tunnel interfaces</font></li>
<li><font face="Gentium">setting interfaces up and down</font></li>
<li><font face="Gentium">setting up wireguard links<br>
</font></li>
<li><font face="Gentium">…</font></li>
</ul>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p><font face="Gentium">Thank you for your understanding<br>
Maria<br>
</font></p>
<div>On 2023-10-24 17:29, Robért Guhr wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>is it possible to set an ipv4 address (e.g. "<a href="http://10.186.100.11/32" target="_blank">10.186.100.11/32</a>" ) via bird on a
dummy interface called "anycast"?</div>
<div>I mean via the bird config not via bgp/ospf pushes.</div>
<div><br>
</div>
<div>Background:<br>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>I have setup four DNS server in two sites. All these DNS
servers announces <a href="http://10.186.100.11/32" target="_blank">10.186.100.11/32</a>
(and <a href="http://10.186.100.12/32" target="_blank">10.186.100.12/32</a>) up to the
routers to create an anycast environment.</div>
<div>Currently <a href="http://10.186.100.11/32" target="_blank">10.186.100.11/32</a> (and <a href="http://10.186.100.12/32" target="_blank">10.186.100.12/32</a>) are set fixed
on the dummy interface. Bird just imports these IP
addresses.</div>
<div><br>
</div>
<div>We would like to use <a href="http://10.186.100.11/32" target="_blank">10.186.100.11/32</a>
and <a href="http://10.186.100.12/32" target="_blank">10.186.100.12/32</a> as resolver in
/etc/resolv.conf</div>
<div>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.</div>
</blockquote>
<div><br>
</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>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.</div>
</blockquote>
<div><br>
I was hoping the direct protocol converts a route also to an
ip address but this seems not to be the case.<br>
With the kernel protocol I can export the route to the kernel
routing table but that is not was I was want.<br>
<br>
pns-b2-ns02 ~ # cat /etc/bird.conf<br>
# Ansible managed<br>
<br>
router id 10.186.244.12;<br>
<br>
protocol device {<br>
scan time 10;<br>
}<br>
<br>
protocol direct {<br>
ipv4 {<br>
import none;<br>
export all;<br>
};<br>
interface "anycast";<br>
}<br>
<br>
protocol static {<br>
ipv4 {<br>
import all;<br>
export all;<br>
};<br>
route <a href="http://10.186.100.11/32" target="_blank">10.186.100.11/32</a> via "anycast";<br>
}<br>
<br>
protocol kernel {<br>
ipv4 {<br>
import none;<br>
export all;<br>
};<br>
}<br>
<br>
<br>
<br>
<br>
<br>
pns-b2-ns02 ~ # birdc show route; echo; ip a show dev anycast;
echo; ip r | grep 10.186.100<br>
<br>
BIRD 2.13.1 ready.<br>
Table master4:<br>
<a href="http://10.186.100.11/32" target="_blank">10.186.100.11/32</a>
unicast [static1 17:22:18.282] * (200)<br>
dev anycast<br>
<br>
4: anycast: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UNKNOWN group default qlen 1000<br>
link/ether 8e:b5:2b:bf:0d:5e brd ff:ff:ff:ff:ff:ff<br>
inet <a href="http://10.186.100.9/32" target="_blank">10.186.100.9/32</a> scope global
noprefixroute anycast # <----- here should also be
the address <a href="http://10.186.100.11/32" target="_blank">10.186.100.11/32</a><br>
valid_lft forever preferred_lft forever<br>
<br>
10.186.100.11 dev anycast proto bird scope link metric 32 <br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Regards,<br>
Robért</div>
</div>
</blockquote>
<pre cols="72">--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</pre>
</div>
</blockquote></div></div>
</blockquote></div>
<br>
<p style="margin:0px;background-color:rgb(255,255,255)"><font face="Calibri, sans-serif" color="#aeaaaa"><span style="font-size:14.6667px">Notice: <br>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.<br><br>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.<br><br>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.</span></font></p></blockquote></div></div>