On Tue, Jul 26, 2011 at 7:20 PM, Ondrej Zajicek <santiago@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@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@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!