<div dir="ltr">Thanks Ondrej,<div><br></div><div>In our case, we're assigning peer point-to-point addresses on veth interfaces that we use for LXC containers. So they're essentially mini subnets with two interfaces. I didn't expect bird to treat peer addresses differently, so it took a few hours to figure out exactly what the problem was and how to work around it. So, I'd vote for either always allowing peer addresses, or adding a configuration option to make that behaviour more explicit. We'll work around that for now by adding a second /32 IP address to each interface.</div><div><br></div><div><br></div><div>Cheers,</div><div>--</div><div>Noel</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 16, 2014 at 7:42 AM, Ondrej Zajicek <span dir="ltr"><<a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Oct 15, 2014 at 11:00:03AM -0700, Noel Burton-Krahn wrote:<br>
> Is there something about point to point addresses that could keep bird<br>
> from forwarding them? I'm assigning a point-to-point address to a<br>
> veth pair like so:<br>
><br>
> ip link add veth1 type veth peer name veth2<br>
> ip addr add <a href="http://10.0.0.1/32" target="_blank">10.0.0.1/32</a> peer <a href="http://10.0.0.2/32" target="_blank">10.0.0.2/32</a> dev veth1<br>
> ip addr add <a href="http://10.0.0.2/32" target="_blank">10.0.0.2/32</a> peer <a href="http://10.0.0.1/32" target="_blank">10.0.0.1/32</a> dev veth2<br>
><br>
> Neither of those addresses get forwarded via OSPF to other hosts.<br>
> They *do* get forwarded if I add the addresses without a peer like<br>
> this:<br>
><br>
> ip addr add <a href="http://10.0.0.1/32" target="_blank">10.0.0.1/32</a> dev veth1<br>
><br>
> Now I've added the same address (<a href="http://10.0.0.1/32" target="_blank">10.0.0.1/32</a>) to veth twice, and bird<br>
> is forwarding a route for that address to OSPF peers.<br>
><br>
> Is there a way for bird to accept the "peer" address? I tried "learn"<br>
> in the kernel but that didn't help.<br>
<br>
</div></div>.. also ..<br>
<br>
On Fri, Oct 10, 2014 at 12:05:30PM +0200, Thomas Goldberg wrote:<br>
> Hello,<br>
><br>
> we've OSPF running over a openvpn ptp tunnel and some problems with<br>
> the routes injected by bird (v1.4.5).<br>
...<br>
> Shouldn't bird inject routes like this on the corresponding router<br>
> (without having to learn them via the direct protocol)?<br>
> <a href="http://10.176.3.29/32" target="_blank">10.176.3.29/32</a> dev lo [o_internal 2014-10-09 00:00:00] * I (150/0) [10.176.3.29]<br>
<br>
Hello<br>
<br>
This is IMHO the same issue. It is an intentional behavior, BIRD does not<br>
inject local address for links with peer addresses, mainly based on idea<br>
that links with such addresses are just variants of 'unnumbered' ptp<br>
links and these addresses are just general 'loopback' addresses and are<br>
usually also used on other interfaces (like the explicit loopback<br>
interface) [*].<br>
<br>
Also note that it is usually simpler to add wanted addresses (using<br>
explicit loopback interface or using 'stubnet' option) in use cases where<br>
they should be propagated than remove unwanted addresses in use cases<br>
where they should not be propagated.<br>
<br>
But in retrospect i am not sure if this behavior was really a good idea.<br>
Perhaps automatic adding of host routes should be configurable and<br>
enabled by default for peer addresses to ensure that all addresses on<br>
OSPF-enabled interfaces are reachable in OSPF area.<br>
<br>
Any comments (esp. arguments for or against it) to this issue?<br>
<br>
<br>
<br>
[*] i.e. configuration like:<br>
<br>
ip addr add <a href="http://10.0.0.1/32" target="_blank">10.0.0.1/32</a> dev lo / dummy0<br>
ip addr add <a href="http://10.0.0.1/32" target="_blank">10.0.0.1/32</a> peer <a href="http://10.0.0.2/32" target="_blank">10.0.0.2/32</a> dev eth0<br>
ip addr add <a href="http://10.0.0.1/32" target="_blank">10.0.0.1/32</a> peer <a href="http://10.0.0.3/32" target="_blank">10.0.0.3/32</a> dev eth1<br>
ip addr add <a href="http://10.0.0.1/32" target="_blank">10.0.0.1/32</a> peer <a href="http://10.0.0.4/32" target="_blank">10.0.0.4/32</a> dev eth2<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Elen sila lumenn' omentielvo<br>
<br>
Ondrej 'Santiago' Zajicek (email: <a href="mailto:santiago@crfreenet.org">santiago@crfreenet.org</a>)<br>
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, <a href="http://wwwkeys.pgp.net" target="_blank">wwwkeys.pgp.net</a>)<br>
"To err is human -- to blame it on a computer is even more so."<br>
</font></span></blockquote></div><br></div>