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
*OpenBGPd/OpenOSPFd;
- Pro's
Tightly integrated into OBSD code - 7/10
Routes support different priorities - 5/10
Supports CARP demote - (Not sure if this is important or not?) - ?/10
Better configuration interface compared to Bird(?) - 3/10
- Con's
Not so widely deployed(?) - 7/10
Not as well tested(?) - 10/10
More likely to have interoperability issues with Cisco maybe(?) - 10/10
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.
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).
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?
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..).
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).
