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).
