On Tue, Jul 26, 2011 at 7:20 PM, Ondrej Zajicek <[email protected]> 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 <[email protected]> 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: [email protected]) > 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!
