Advertising interface addresses via OSPF

[Ryan Whelan]

On Tue, Jul 26, 2011 at 7:20 PM, Ondrej Zajicek <santiago at crfreenet.org> wrote:
> On Mon, Jul 25, 2011 at 03:03:57PM -0400, Ryan Whelan wrote:
>> On Mon, Jul 25, 2011 at 2:04 PM, Ryan Whelan <rcwhelan at gmail.com> wrote:
>> > I have 3 Linux machines connected to one another by point-to-point
>> > links. With the end point of each tunnel using a tun device, there are
>> > a total of 6 tun devices used on across the 3 machines. 2 per machine.
>> >  Using OSPF, Bird is not advertising the addresses on the tun devices
>> > to the other nodes.  This causes an issue because each device is
>> > unaware of the addresses on the tun devices on tunnels it is not
>> > connected to.  In other words, node 'C' is unaware of the addresses on
>> > the tunnel between nodes 'A' and 'B'.  Thats an issue because if the
>> > link between 'A' and 'B' fails, 'A' will get the routes 'B' knows
>> > about thru 'C', but 'B' does not know the tun address of 'A' thats
>> > connected to 'C' so all the traffic 'C' routes from 'A' to 'B' comes
>> > from an address 'B' can't route back too.  (Sorry its so hard to
>> > follow)
>> >
>> > I've been able to alleviate it by adding a `stubnet` for each tun
>> > device on each machine, but I'm afraid that will become increasingly
>> > difficult to maintain as the number of nodes increases.
>> >
>> > Is there another way? I've been unsuccessful at getting bird to import
>> > (and advertise) the routes associated with the tun devices.  (using
>> > the 'device' protocol I can get bird to import them, but ospf doesn't
>> > advertise them to the other nodes)
>> >
>>
>> I think I figured it out.  Adding the 'direct' protocol (i called it
>> 'device' in my last message) and an 'export all;' to ospf seems to
>> have done it.
>
> Yes, this is one way, but probably not the good one. First, by export to
> OSPF these addresses are addes as external routes (which is a bit
> strange, they have large metrics, but probably not a big deal). Second,
> direct protocol for ptp addresses generates (perhaps unintuitively, but
> it has a reason) /32 routes not for local address, but for neighbor
> addresses (specified in ptp addresses). Therefore each router in your
> setting probably propagates not his address, but addresses of neighbors,
> which could lead to some strange behavior (like choosing suboptimal
> routes, or even the broken ones).
>
>
> It is true that for ptp links with ptp addresses BIRD does not add these
> addresses to the router LSA, that is because these addresses are often
> taken from another local IP range, which is already propagated. And if
> they are needed, they can be added using 'stubnet' option (but that
> could be cumbersome).
>
> I would suggest this strategy:
>
> 1) create dummy/loopback interface (probably using 'dummy' module),
> add some /32 address (not ptp address) to that iface (the 'central'
> address of a node).

I ended up doing this very thing for sending traffic to the machine.
I think I thought I could use specific tun addresses for testing
individual link availability; but the usefulness of that is likely
minimal

>
> 2) add this iface to OSPF as stub iface (this will propagate the
> address through OSPF).
>
> 3) set krt_prefsrc kernel route option to the central address when
> exporting OSPF routes to the kernel. This forces the OS to choose the
> central address as a source address when originating traffic going
> through these routes.
>

This sounds perfect, but reading the documentation its not clear to me
how to set this attribute.  Bird complains about syntax when I try to
set krt_prefsrc to the address of the dummy interface.  I'm clearly
missing something basic.  What is the config file syntax for setting
krt_prefsrc?

> 4) use just central addresses, do not use ptp addresses as a destination
> address (so it does not matter that they are not in routing tables of
> other routers).
>
>
> Alternatively, instead of 3) you could just change all ptp addresses to
> be the same as the central address (you could use the same ptp address
> for multiple ifaces without problems if they have different neighbor
> addresses). Or choose some nontrivial prefix (e.g. /29) for the central
> address and use other addresses from that prefix for local ptp addresses.
>
>
> --
> Elen sila lumenn' omentielvo
>
> Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAk4vS9EACgkQw1GB2RHercMHaACfUj2VR9eVGD8mW8NphMxCAyqU
> vXMAn12Q5OwHk2TXs/hXlkcODA+heNMd
> =Ueec
> -----END PGP SIGNATURE-----
>
>

Thanks for your help; this is truly helpful!