Advertising interface addresses via OSPF

[Ondrej Zajicek]

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).

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.

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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20110727/a38cb0a7/attachment-0001.asc>