I have a group of devices which are required to have a redundant communication path in the event of a link failure. Due to legacy & cost reasons the network uses serial PPP links between devices as follows: +---+----+---+ | |eth0| | | +----+ | | 1 | +----+ +----+ |ppp0| |ppp1+-----+ +-+--+--+----+ | | | | | +---+----+---+ | | | |eth0| | | | | +----+ | | | | 2 | | | +----+ +----+ | +----+ppp0| |ppp1| | +----+--+--+-+ | | | +---+----+---+ | | | |eth0| | | | | +----+ | | | | 3 | | | +----+ +----+ | +--+ppp1| |ppp0+----------------+ +----+--+----+ This shows the simplest case; the loop will be larger in most cases. The eth0 ports will generally not be used, but we'd like the flexibility to plug into a random eth0 port to access any point on the loop. Ignoring the eth0's for the moment, I'm having trouble persuading OSPF to generate *any* routing/neighbour/topology information for the PPP links. My config file is this: protocol kernel { learn off; persist on; scan time 20; export all; } protocol device { scan time 10; } protocol direct { interface -"eth*"; } protocol ospf { export all; import all; area 0.0.0.0 { interface 10.0.0.0/8 { wait 15; type nonbroadcast; # no change if omitted strict nonbroadcast on; # no change if omitted cost 100; authentication none; retransmit 7; }; }; } All the PPP's are static IP in 10.0.0.0/8 (eg 10.0.1.2 is ppp1 on node 2). I'm seeing Hello packets (sent to 224.0.0.5) on the nodes, but there's not a lot going on otherwise. I've tried explicitly setting neighbors (giving the IP addresses of the 2 adjacent PPP ports), but this has no effect either. "show route" (on node 3) from birdc gives me this: 10.0.1.2/32 dev ppp0 [direct1 09:47] * (240) 10.0.0.1/32 dev ppp1 [direct1 09:47] * (240) 192.168.1.0/24 dev eth0 [direct1 09:47] * (240) 127.0.0.0/8 dev lo [direct1 09:47] * (240) which is a start, I think, but there's no corresponding information in the kernel routing table. Any obvious pointers for an OSPF newbie? Jeremy Evans
On Fri, Mar 26, 2010 at 11:17:51AM +1300, Jeremy Evans wrote:
protocol direct { interface -"eth*"; }
protocol ospf { export all; import all; area 0.0.0.0 { interface 10.0.0.0/8 { wait 15; type nonbroadcast; # no change if omitted strict nonbroadcast on; # no change if omitted cost 100; authentication none; retransmit 7; }; }; }
Your ppp interfaces have peer addresses (instead of standard 'prefix-based' addresses). Such interfaces can be used in pointopoint mode only. Set 'type pointopoint' instead of 'type nonbroadcast' in interface config. -- 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."
On Fri, Mar 26, 2010 at 11:17:51AM +1300, Jeremy Evans wrote:
protocol kernel { learn off; persist on; scan time 20; export all; }
protocol device { scan time 10; }
protocol direct { interface -"eth*"; }
protocol ospf { export all; import all;
And two minor notes: 1) Use 'interface "*"' in protocol direct. 2) You probably don't want 'export all' to protocol ospf. That would lead to export routes from direct protocol to ospf protocol, whis is not what you want (protocol ospf generates routes for connected devices itself so these exported routes would be duplicates and would fill OSPF domain with unnecessary external LSAs). If you don't want to export static (or RIP or BGP) routes, just use 'export none' in protocol ospf. -- 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."
On Fri, Mar 26, 2010 at 12:23:53AM +0100, Ondrej Zajicek wrote:
2) You probably don't want 'export all' to protocol ospf. That would lead to export routes from direct protocol to ospf protocol, whis is not what you want (protocol ospf generates routes for connected devices itself so these exported routes would be duplicates and would fill OSPF domain with unnecessary external LSAs).
I wrote that OSPF generates routes for connected devices itself, but this is true for devices with standard (prefix-based) IP addresses. Devices with peer addresses does not generate OSPF routes itself (they are considered as unnumbered ptp links). But this is not problem (if you don't care that you wouldn't have routes to these IP addresses in routing tables) because such IP addresses should not be used anywhere else than as destination in routes. You would probably want some IP address that is used as 'canonical' address of that computers. You don't want to use IP address of some PPP iface for that purpose, as PPP ifaces might appear and disappear and most importantly, neighbors would always consider such address accessible through direct PPP link, regardless of what OSPF says (and what is a state of a link). This is usually handled by adding 'dummy' interface with canonical address (with /32 prefix) and adding this interface to OSPF (perhaps as stub interface). Often for the same purpose is used IP address of some ethernet interface with no other OSPF neighbors. Another way of exporting canonical address is to specify it using 'stubnet' declaration in OSPF area specification. This can be also used to export IP addresses of ppp links, if you really want them in routing tables. -- 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."
Thanks for the suggestions. I'll bear them in mind for when I try tuning the configuration. Turned out I shot myself in the foot by rushing into upgrading BIRD to the latest version after thinking I wasn't getting anywhere with 1.0.11 (I think - the version attached to ubuntu 8.04). I killed the daemon instead of shutting down & it left the (non-optimal at the time) routes in the kernel table. So, prior to starting up the updated BIRD, I deleted all the 10.0.0.0/8 network routes manually. Of course, this deleted the default ptp (neighbour) routes to the adjacent PPP interfaces - which I was expecting BIRD to recreate somehow. In the end, my problem appears to be solved after restarting all the PPP interfaces & letting the kernel populate the default ptp routes automatically. Now I just need to check the performance - what I'd like to be able to do is in a (say) 5-node ring, normally node 1 will talk to node 3 via node 2. If the link between 2 & 3 goes down, however, the traffic will have to redirect through 5 & 4 instead. Thanks for your help. Jeremy Evans -----Original Message----- From: Ondrej Zajicek [mailto:santiago@crfreenet.org] Sent: Friday, 26 March 2010 12:53 To: Jeremy Evans Cc: bird-users@trubka.network.cz Subject: Re: OSPF & Ring network On Fri, Mar 26, 2010 at 12:23:53AM +0100, Ondrej Zajicek wrote:
2) You probably don't want 'export all' to protocol ospf. That would lead to export routes from direct protocol to ospf protocol, whis is not what you want (protocol ospf generates routes for connected devices itself so these exported routes would be duplicates and would fill OSPF domain with unnecessary external LSAs).
I wrote that OSPF generates routes for connected devices itself, but this is true for devices with standard (prefix-based) IP addresses. Devices with peer addresses does not generate OSPF routes itself (they are considered as unnumbered ptp links). But this is not problem (if you don't care that you wouldn't have routes to these IP addresses in routing tables) because such IP addresses should not be used anywhere else than as destination in routes. You would probably want some IP address that is used as 'canonical' address of that computers. You don't want to use IP address of some PPP iface for that purpose, as PPP ifaces might appear and disappear and most importantly, neighbors would always consider such address accessible through direct PPP link, regardless of what OSPF says (and what is a state of a link). This is usually handled by adding 'dummy' interface with canonical address (with /32 prefix) and adding this interface to OSPF (perhaps as stub interface). Often for the same purpose is used IP address of some ethernet interface with no other OSPF neighbors. Another way of exporting canonical address is to specify it using 'stubnet' declaration in OSPF area specification. This can be also used to export IP addresses of ppp links, if you really want them in routing tables. -- 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."
participants (2)
-
Jeremy Evans -
Ondrej Zajicek