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). 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: [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."
signature.asc
Description: Digital signature
