Hi Stuart, Thanks for your great response, all makes perfect sense.
I will start with OpenOSPFd and OpenBGPd and see how I get on. I was initially thinking of using BIRD for the previously mentioned reasons, but considering all the points discussed I will start testing, testing testing... Wish me luck and thank you everyone for all your comments! :) Andrew Lemin On Sat, 18 May 2013 22:33:21 +0100, Stuart Henderson <[email protected]> wrote: > On 2013/05/18 18:10, andy wrote: >> Hi, >> Sorry for the slow reply, have just got back home from the RIPE 66 >> conference in Dublin. Which was great by the way :) >> Thank you very much for your comments and suggestions. When building >> something like this it is really important to me to hear the experience >> and >> thoughts of others. >> >> Ok, so I think Quagga is out the Window. >> This is what I have got it down too.. I have put question marks next to >> the items which I am not 100% sure on, and a score of 1 to 10 on how >> important it is. >> >> >> *BIRD; >> - Pro's >> Widely deployed - 7/10 >> Heavily tested - 10/10 >> Great interoperability with Cisco - 10/10 >> Fast development with many developers working on it - 5/10 >> >> - Con's >> All routes treated with same priority - 4/10 >> No CARP demote - (Not sure if this is important or not?) - ?/10 > > Important con here if you're talking about running it on OpenBSD is that > this is not a primary platform for them. I think it's safe to say that > far fewer people will be running BIRD on OpenBSD than will be running > OpenOSPFd on OpenBSD. (I mostly just imported it to ports in case it's > useful for interoperability testing rather than to actually use it..) > >> *OpenBGPd/OpenOSPFd; >> - Pro's >> Tightly integrated into OBSD code - 7/10 >> Routes support different priorities - 5/10 > > This is important when you're running with multiple routing daemons > but less important if everything is done in one process. > >> Supports CARP demote - (Not sure if this is important or not?) - ?/10 > > If you are using ospfd on a machine (firewall, etc) which is also > running carp, yes it's very important, otherwise a machine can become > carp master when ospf is down so it has no onward routes. > >> Better configuration interface compared to Bird(?) - 3/10 >> >> - Con's >> Not so widely deployed(?) - 7/10 > > I don't think it's really possible to say which is more widely deployed.. > I'm pretty sure Quagga is more deployed than either, still that wouldn't > make me want to use it unless it was the only option ;) > >> Not as well tested(?) - 10/10 > > see above; definitely better tested than BIRD on OpenBSD. > >> More likely to have interoperability issues with Cisco maybe(?) - 10/10 > > no known problems, and we do minimal dead time for sub-second failover. > >> I seem to remember seeing something when googling like OpenOSPFd once had >> assert fail problems when receiving packets from other routing daemons >> with >> unknown attributes, is this true or still the case? I can't remember >> where >> I heard that so not sure if thats even true. > > You're thinking of something else (possibly quagga's ospfd?) > OpenBSD's ospfd has never had asserts. > >> What is the level of integration with CARP for OpenBGPd and OpenOSPFd? >> I.e. Can I have both the Primary 'and' the Backup firewalls sending and >> receiving routes all the time, but referring to the CARP IPs in the route >> entires so the forwarding plane uses the CARP Masters etc, and the >> routing >> control plane always involves all firewalls etc? This would mean that a >> CARP fail-over would effectively be an instantaneous re-convergence? >> (this >> is very important). > > With OpenOSPFd normally both carp master *and* carp backup will advertise > the route, master with a low (more preferred) metric, backup with a high > metric. So when a failover occurs, the route will not drop out at all, > it will switch straight over. I think this is what you're looking for. > Other routing daemons do not do this. > >> The network I am building is as follows; >> I have 3 data centres (one primary, one DR/backup, one >> staging/development). >> I am building 2 brand new POPs at two new central locations using two >> Cisco ASR 1002 routers to join the data centres and firewalls I have >> inherited together, and bring all POPs/DCs under the same ASN and global >> IP >> prefixes etc. >> >> The DR/backup and staging/dev DCs just have single layer 2 back-haul >> links >> (one to one POP, and the other to the other POP). >> The primary data center has a fibre to the first POP, and a second >> diverse >> path fibre to the other POP, and the two POPs have a fibre between them. >> >> Transits&IXPs >> | >> -------POP1----DR_DC >> Primary_DC-| | >> -------POP2---------Dev_DC >> | >> Transits&IXPs >> >> The two Cisco ASRs are going to run eBGP to announce our ASN and full >> prefix globally etc, eBGP with announce filtering for our IXP peerings, >> iBGP to redistribute full internet table routes between them, and OSPF to >> redistribute the local DC sub-prefixes etc. >> >> Each of the DR and Dev DCs have two OpenBSD firewalls (in CARP >> configuration), and the Primary data centre has six OpenBSD firewalls (3 >> pairs) to physically separate out the different internal networks in that >> data centre (Public DMZ network behind different firewalls to the >> corporate >> business networks etc). >> >> The layer 2 connectivity between the 3 pairs of firewalls at the primary >> data centre and the two POPs is provided by VPLS from our Primary >> colocation data centre provider who we have a close working relationship >> with. >> >> Naturally I have sliced up our public global IP prefix so each pair of >> firewalls host their own aggregated IP ranges from the global prefix etc, >> and I would like each of these sub-prefixes to be redistributed around >> using OSPF between all POPs and all firewalls in all locations etc. >> >> So in the case of the Primary data centre firewalls, they should receive >> equal cost multi-path routes for global transit and IXP access via POP1 >> and >> POP2, and routes with different preferences for the DR DC and Dev DC >> depending on whether going via POP1 (one hop to DR, and two hops for Dev) >> or POP2 (one hop to Dev, and two hops to DR) for example. >> >> >> So considering the pro's and con's above, this network design, Cisco >> interoperability being critical, and firewall fail-over providing >> instantaneous re-convergence, is their any advice you can offer regarding >> BIRD or OpenOSPFd for the OpenBSD firewalls? > > Given what you want to do, I definitely think openospfd is preferred. > >> To add another can of worms to the mix, although not entirely important >> for the core dynamic routing design under normal operation, the Transits >> and IXP access are being provided by our VPLS network provider who have >> multiple transits each from Telecom Italia, Level 3 and NTT, and multiple >> connections to LONAP (our IXP). This means we only need two 10 GBit >> uplinks >> on our ASRs instead of lots of physical layer 1 connections (Our new POPs >> will be in the same racks as their POPs..). > > FWIW I personally know of 2 networks at lonap using openbgpd/openospfd > (one being mine. ;) > >> It also means that if both of our ASR routers were to go down, they can >> continue providing the layer 3 Transit and IXP access for the Primary DC >> only (DR and Dev would be offline of course), and so for the 3 pairs of >> firewalls at the Primary DC only, I am also thinking about running >> additional eBGP instances as a backup for announcing our ASN and prefixes >> (should the ASRs be down) and so I would need to run openBGPd (if using >> the >> OpenOSPFd/OpenBGPd option), or create a BGP domain in BIRD on those >> primary >> DC firewalls. >> >> >> Thank you for reading this far, I hope this all clear. And thanks again >> for your thoughts and ideas, they are greatly appreciated. >> Humbly yours, Andrew Lemin >> >> >> >> On Thu, 16 May 2013 22:15:40 +0000 (UTC), Stuart Henderson >> <[email protected]> wrote: >> > On 2013-05-16, andy <[email protected]> wrote: >> >> Hello, >> >> I would like to appeal to the knowledge and experience of this mailing >> >> list to offer any opinions/preferences for which routing daemon would >> be >> >> best to use (openospfd or bird or quagga) on OpenBSD when >> interoperating >> >> with Cisco IOS XE routers for redistributing IPv4 and IPv6 routes? >> >> >> >> I am planning to install 2 Cisco ASR 1002 routers as POPs to >> interconnect >> >> our many OpenBSD firewalls at our data centres, and would like OSPF to >> >> redistribute all the prefixes. >> >> >> >> I like BIRD and have used it before to a basic extent, but wonder if >> the >> >> OpenOSPFd daemon would be better seeing as it seems to be more closely >> >> coupled with OpenBSD development? >> >> >> >> Thank you in advance for your time. >> >> Kind regards, Andy. >> >> >> >> >> > >> > I would suggest sticking with the routing daemons from the base OS on >> > OpenBSD if possible. They are designed to work with the OS and in most >> > cases if a problem can be clearly identified or reproduced it will >> > usually get fixed. >> > >> > OpenBSD is a fairly minor target for the other daemons, in particular >> > part of quagga's current ospf code needed to be reverted to an older >> > version to even build on OpenBSD and it's not really well tested. >> > >> > If on an OS other than OpenBSD I'd probably go for BIRD (though I'm >> > not really keen on the config language). But it has a few things >> > missing that would really be wanted for working alongside some >> > other parts of OpenBSD e.g. it doesn't support route priorities, >> > it just adds everything at RTP_DEFAULT (below the priority >> > of other routing daemons), doesn't support carp demote, etc. >> > Also IIRC it doesn't support some other nice things that ospfd >> > does, like fast hellos ("router-dead-time minimal" in ospfd).
