issues setting up OpenOSPFD between local and remote OpenBSD routers.
Good day.
I hope this is the appropriate forum for my questions. It is both
OpenBSD and OpenOSPFD related, but quite networking-centric. My
apologies if there is a better forum.
I've scoured the various examples out on the internet, referenced
relevant information in the various OpenBSD FAQs and elsewhere, yet
still am experiencing problems.
Basically, I am trying to run OpenOSPFD to manage my routes between 4
routers (2 local, 2 remote, each managing a unique network). I have a
backbone network on each of the routers for router communication, and
the remote routers have backbone network IP addresses via an OpenVPN
connection.
I know pictures are preferred, but with the amount of information it
seemed daunting, so here's a semi-picture (where the connection between
all routers is via the 10.10.10.x network):
local routers
router A (OBSD4.4) router B (OBSD 4.4)
-- ---
em0: 10.80.1.0/24xl0: 10.80.2.0/24
em1: 10.10.10.1 em0: 10.10.10.2
tun1: backbone VPN
bridge1: em0 + tun1
remote routers
router C (OBSD4.3) router D (FBSD 7.2)
-- ---
re0: 10.81.1.0/24xl1: 10.82.1.0/24
tun1: 10.10.10.4 tap1: 10.10.10.5
router B bridge1:
/etc/bridgename.bridge1
---
add em0
add tun1
up
*** IP forwarding is enabled on all routers.
*** In pf rules on all routers, I am telling pf to skip the backbone
and tun interfaces (so it doesn't somehow complicate things).
Objective: Trying to run OSPF to manage routes between the routers,
each of which manages a 10.8x.y.0/24 network.
* the 10.10.10.x network is designated as the communications network
between the routers (aka "backbone network").
* the remote routers join the backbone via an OpenVPN connection
hosted by "router B" (the tun1 interface on "router B").
* tun1 and em0 on "router B" are bridged, in the belief that it
will facilitate communication from routers C and D communicating
on the backbone network.
* the backbone VPN works. I can set static routes as appropriate and
traffic routes as desired.
* although I have 4 routers, I am playing with A, B, and C at this
point, as I still have to figure out how to get OpenOSPFD on a
FreeBSD box (it doesn't seem to be actively supported in ports
anymore?)
OpenOSPFD config (/etc/ospfd.conf)
--
router A (OpenOSPFD 4.4.1)
--
router-id 10.10.10.1
redistribute connected
area 0.0.0.0 {
auth-type none
interface em1
}
router B (OpenOSPFD 4.4.1)
--
router-id 10.10.10.2
redistribute connected
area 0.0.0.0 {
auth-type none
interface em0
}
router C (native OpenOSPFD to OBSD4.3)
--
router-id 10.10.10.4
redistribute connected
area 0.0.0.0 {
auth-type none
interface tun1
}
Observations: There appears to be problems on "router B" when OSPFd
is trying to establish full communication amongst all the routers.
Output of "ospfctl show neighbor" when all 3 are running
router A
10.10.10.4 1 FULL/DR 00:00:31 10.10.10.4 em1 09:55:14
10.10.10.2 1 FULL/OTHER 00:00:31 10.10.10.2 em1 16:11:21
router B
10.10.10.4 1 DOWN/OTHER 00:02:04 10.10.10.4 tun1 -
10.10.10.1 1 FULL/BCKUP 00:00:30 10.10.10.1 em0 16:11:47
router C
10.10.10.1 1 FULL/BCKUP 00:00:34 10.10.10.1 tun1 09:55:50
10.10.10.2 1 INIT/OTHER 00:00:34 10.10.10.2 tun1 -
If I just run ospfd on routers A and C, they seem to talk just fine.
When I start ospfd on router B, if I tell it to use "interface em0" it
seems to be able to talk okay with router A (but has issues talking to
router C), whereas if it is using "interface tun1", it can talk to
router C, but has issues talking to router A (I see lots of "unknown
neighbor ID" messages from ospfd-- a tcpdump seems to show traffic
destined to router A from B is going down tun1, never getting to the
right place-- but this is usually when I tell router B to use BOTH em0
and tun1, just two consecutive interface statements in the area stanza).
When I have "router B" use tun1 (the backbone VPN link), I have to
assign it an IP (10.10.10.6 for the sake of experimenting). This tends
to have an effect of popping up on routers A and C as a neighbor.
I thought what might be a way to solve the problem was to tell router B
to use the bridge1 interface... but I cannot seem to apply an IP address
to it.
The questions I think I have are:
- Do I need to do something more with the br
Re: issues setting up OpenOSPFD between local and remote OpenBSD routers.
Claudio Jeker wrote: On Mon, Aug 03, 2009 at 09:53:00AM -0400, Matthew Haas wrote: Good day. I hope this is the appropriate forum for my questions. It is both OpenBSD and OpenOSPFD related, but quite networking-centric. My apologies if there is a better forum. Which version of OpenBSD are you using. There was a multicast fix going into bridge(4) some time ago (IIRC after 4.5) that is necessary in your case. On the other hand I don't understand why you need to have the bridge, why not use two different networks one for em(4) and one for tun(4) and let ospfd handle the rest. Running a dynamic routing protocol allows you to do that without much issues. Right now a mix of OpenBSD 4.4 and 4.3 machines. So certainly nothing that would have taken advantage of that multicast bridge fix. Your statement regarding running separate networks for OSPF makes sense.. I'm still in the process of wrapping my head around everything, so I believe I may have inadvertently committed an act of network micro-management where I should just step back and let OSPF handle things. Thank you, I will explore that. Additionally, is there some repository of OpenOSPFD config files out on the internet I could reference? All examples I can readily find deal only with one "area", and if I understand Claudio's suggestion, setting up two areas would be in order. New questions: - If I just set up two OpenOSPFD areas in the same config file, segregating the network interfaces properly, will OpenOSPFD know to handle communication between the two? - Or do I need to somehow tell it to merge them together? (That's where I'm unsure) Thanks! -Matthew
Re: issues setting up OpenOSPFD between local and remote OpenBSD routers.
Claudio Jeker wrote:
Additionally, is there some repository of OpenOSPFD config files out
on the internet I could reference?
Not that I know of. The manpage and the example rule file is a start.
Normaly you want to start with a simple setup (one area, no passwords) so
something like:
router-id 0.0.0.1
redistribute static
redistribute connected
area 0.0.0.0 {
interface em0
interface tun1
}
If that is working as expected you can start changing the config.
Amusingly, I actually had this identical configuration which I tried
during one of my many tests. While running the dual-homed router in
non-detaching verbose mode, it spits out some messages indicating a
questionable level of operation, and certainly not 100% happiness
(unknown neighbor ID, states constantly being ELECTed to switch from
EXSTA to some other state).
But, this time when I tried it, after a few minutes everything seemed
to latch into place. It was working great... so I left it to sit, and
about 3 hours later, all the OSPF-provided routes just got up and
vanished. So that leaves me back at square one.
What I did try was running this configuration with and without em0/tun1
being bridged... when they were not bridged, things absolutely did not
work. When they were bridged, there was that message spew, but things
seem to at least entertain some sporadic form of communication.
Thanks for your suggestions. I'll keep poking away at it and see if I
can get everything happily talking.
-Matthew
Re: issues setting up OpenOSPFD between local and remote OpenBSD routers.
Jussi Peltola wrote: I'd suggest running ospf over pointopoint links (gif/gre, on ipsec if desired) instead of faking a layer 2 backbone where there isn't one. I've been getting the impression my current setup isn't overly conducive to OpenOSPFD as the sole route sharing mechanism. The VPN link suffers from connection hiccups, and I think that may have been the cause of some of the problems I experienced (especially when they last more than just a couple seconds, potentially tripping the dead router timeout). I'm exploring running OpenOSPFD only on the local networks (ie talking between my two local routers), but then talk amongst all the sites via OpenBGPD. We'll see how it turns out. -Matthew
Re: issues setting up OpenOSPFD between local and remote OpenBSD routers.
Matthew Haas wrote: I'm exploring running OpenOSPFD only on the local networks (ie talking between my two local routers), but then talk amongst all the sites via OpenBGPD. We'll see how it turns out. Good day everyone, Just wanted to offer an update of where I stand-- thanks to all for your suggestions. As it turns out, last night I sat down and banged out an OpenBGPD config on all affected routers (and there is an up-to-date FreeBSD port of OpenBGPD which also made some things nicer), and there was a clear difference in connectivity happiness. Peers came up and established each other's presence quite nicely. Watching new routes propagate was also rather impressive, not to mention seeing a distinct lack of communication errors I was regularly experiencing watching the OSPF peers try to negotiate with one another. I was hoping to only run 1 BGP server at each geographic location (of which there are 3 involved), and then running an OSPF server between all local routers at each location, but I couldn't get BGP-acquired routes to be shared via OSPF. It looks like some other implementations of OSPF have a "redistribute ospf" option, which doesn't look to be available in OpenOSPFD 4.4.1. Just trying it with "redistribute connected" and "redistribute static" didn't seem to have any effect. So as a result, I'm currently running OpenBGPD on all routers (which I guess isn't a problem, as each router is uniquely responsible for serving its own subnet, regardless of whether the machines are located at the same geographic location or remotely over the VPN. I'm not sure if I'm looking at this the wrong way (assuming I can have OSPFD extract acquired routes from BGPD and share them across the local network, just as I would expect BGPD to acquire OSPF-propagated routes from the local network and share them with the remote peers), but for the time being, I am pleased to have something working, so I can continue to whittle away at it with any further customizations I want to explore. One thing I do know, is that OpenBSD consistently comes through for me when it comes to easily setting up and having access to somewhat more complex network communication facilities. pf-based firewalls, and now route management; I am now plotting the demise of the sole Linux router in my environment to replace it with OpenBSD just to have full and headache-free access to these capabilities. -Matthew
