bird's not forwarding point-to-point routes via OSPF

[Noel Burton-Krahn]

Is there something about point to point addresses that could keep bird
from forwarding them? I'm assigning a point-to-point address to a
veth pair like so:

ip link add veth1 type veth peer name veth2
ip addr add 10.0.0.1/32 peer 10.0.0.2/32 dev veth1
ip addr add 10.0.0.2/32 peer 10.0.0.1/32 dev veth2

Neither of those addresses get forwarded via OSPF to other hosts.
They *do* get forwarded if I add the addresses without a peer like
this:

ip addr add 10.0.0.1/32 dev veth1

Now I've added the same address (10.0.0.1/32) to veth twice, and bird
is forwarding a route for that address to OSPF peers.

Is there a way for bird to accept the "peer" address? I tried "learn"
in the kernel but that didn't help.

TIA,
--
Noel

[Ondrej Zajicek]

Post by Noel Burton-Krahn
Is there something about point to point addresses that could keep bird
from forwarding them? I'm assigning a point-to-point address to a
ip link add veth1 type veth peer name veth2
ip addr add 10.0.0.1/32 peer 10.0.0.2/32 dev veth1
ip addr add 10.0.0.2/32 peer 10.0.0.1/32 dev veth2
Neither of those addresses get forwarded via OSPF to other hosts.
They *do* get forwarded if I add the addresses without a peer like
ip addr add 10.0.0.1/32 dev veth1
Now I've added the same address (10.0.0.1/32) to veth twice, and bird
is forwarding a route for that address to OSPF peers.
Is there a way for bird to accept the "peer" address? I tried "learn"
in the kernel but that didn't help.

.. also ..

Post by Noel Burton-Krahn
Hello,
we've OSPF running over a openvpn ptp tunnel and some problems with
the routes injected by bird (v1.4.5).

...

Post by Noel Burton-Krahn
Shouldn't bird inject routes like this on the corresponding router
(without having to learn them via the direct protocol)?
10.176.3.29/32 dev lo [o_internal 2014-10-09 00:00:00] * I (150/0) [10.176.3.29]

Hello

This is IMHO the same issue. It is an intentional behavior, BIRD does not
inject local address for links with peer addresses, mainly based on idea
that links with such addresses are just variants of 'unnumbered' ptp
links and these addresses are just general 'loopback' addresses and are
usually also used on other interfaces (like the explicit loopback
interface) [*].

Also note that it is usually simpler to add wanted addresses (using
explicit loopback interface or using 'stubnet' option) in use cases where
they should be propagated than remove unwanted addresses in use cases
where they should not be propagated.

But in retrospect i am not sure if this behavior was really a good idea.
Perhaps automatic adding of host routes should be configurable and
enabled by default for peer addresses to ensure that all addresses on
OSPF-enabled interfaces are reachable in OSPF area.

Any comments (esp. arguments for or against it) to this issue?



[*] i.e. configuration like:

ip addr add 10.0.0.1/32 dev lo / dummy0
ip addr add 10.0.0.1/32 peer 10.0.0.2/32 dev eth0
ip addr add 10.0.0.1/32 peer 10.0.0.3/32 dev eth1
ip addr add 10.0.0.1/32 peer 10.0.0.4/32 dev eth2

[Noel Burton-Krahn]

Thanks Ondrej,

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.


Cheers,
--
Noel

Post by Ondrej Zajicek

Post by Noel Burton-Krahn
Is there something about point to point addresses that could keep bird
from forwarding them? I'm assigning a point-to-point address to a
ip link add veth1 type veth peer name veth2
ip addr add 10.0.0.1/32 peer 10.0.0.2/32 dev veth1
ip addr add 10.0.0.2/32 peer 10.0.0.1/32 dev veth2
Neither of those addresses get forwarded via OSPF to other hosts.
They *do* get forwarded if I add the addresses without a peer like
ip addr add 10.0.0.1/32 dev veth1
Now I've added the same address (10.0.0.1/32) to veth twice, and bird
is forwarding a route for that address to OSPF peers.
Is there a way for bird to accept the "peer" address? I tried "learn"
in the kernel but that didn't help.

.. also ..

Post by Noel Burton-Krahn
Hello,
we've OSPF running over a openvpn ptp tunnel and some problems with
the routes injected by bird (v1.4.5).

...

Post by Noel Burton-Krahn
Shouldn't bird inject routes like this on the corresponding router
(without having to learn them via the direct protocol)?
10.176.3.29/32 dev lo [o_internal 2014-10-09 00:00:00] * I (150/0)

[10.176.3.29]
Hello
This is IMHO the same issue. It is an intentional behavior, BIRD does not
inject local address for links with peer addresses, mainly based on idea
that links with such addresses are just variants of 'unnumbered' ptp
links and these addresses are just general 'loopback' addresses and are
usually also used on other interfaces (like the explicit loopback
interface) [*].
Also note that it is usually simpler to add wanted addresses (using
explicit loopback interface or using 'stubnet' option) in use cases where
they should be propagated than remove unwanted addresses in use cases
where they should not be propagated.
But in retrospect i am not sure if this behavior was really a good idea.
Perhaps automatic adding of host routes should be configurable and
enabled by default for peer addresses to ensure that all addresses on
OSPF-enabled interfaces are reachable in OSPF area.
Any comments (esp. arguments for or against it) to this issue?
ip addr add 10.0.0.1/32 dev lo / dummy0
ip addr add 10.0.0.1/32 peer 10.0.0.2/32 dev eth0
ip addr add 10.0.0.1/32 peer 10.0.0.3/32 dev eth1
ip addr add 10.0.0.1/32 peer 10.0.0.4/32 dev eth2
--
Elen sila lumenn' omentielvo
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."