Suggestions to achieve multiple VRFs?
Hi all, Presently I am testing a network design consisting of BIRD routers running a fairly unexciting "OSPF on linknets and loopback interfaces, iBGP mesh" type network. I am interested in suggestions for sensible ways to split a network of BIRD routers like this in to multiple VRFs - for instance to define a "management" VRF alongside the standard inet table. It seems simple to set up multiple routing tables on any given router and to learn routes in to those tables, however I am interested in suggestions for ways to distribute that routing information, as there seem to be several mechanisms that could be used. I'd like to avoid running multiple linknets and OSPF instances over my linknets if possible. -- Michael
Hi, Maybe you've already thought about it, but what about using network namespaces (in Linux, or whatever equivalent they have in other OSs) to separate cleanly the management network from everything else? Or are you sharing interfaces? - P
-----Original Message----- From: owner-bird-users@atrey.karlin.mff.cuni.cz [mailto:owner-bird- users@atrey.karlin.mff.cuni.cz] On Behalf Of Michael Fincham Sent: Tuesday, October 21, 2014 1:17 AM To: bird-users@network.cz Subject: Suggestions to achieve multiple VRFs?
Hi all,
Presently I am testing a network design consisting of BIRD routers running a fairly unexciting "OSPF on linknets and loopback interfaces, iBGP mesh" type network.
I am interested in suggestions for sensible ways to split a network of BIRD routers like this in to multiple VRFs - for instance to define a "management" VRF alongside the standard inet table.
It seems simple to set up multiple routing tables on any given router and to learn routes in to those tables, however I am interested in suggestions for ways to distribute that routing information, as there seem to be several mechanisms that could be used.
I'd like to avoid running multiple linknets and OSPF instances over my linknets if possible.
-- Michael
Hi Pierluigi, On Tue, 21 Oct 2014 16:27:21 +0000 "Pierluigi Rolando" <pierluigi@embrane.com> wrote:
Maybe you've already thought about it, but what about using network namespaces (in Linux, or whatever equivalent they have in other OSs) to separate cleanly the management network from everything else? Or are you sharing interfaces?
I'd quite like to share the backhaul "core" links between routers if I can, and avoid duplicating configuration on them. One possibility that did occur to me is to use communities to separate which BGP prefixes get learned in to which kernel route tables, possibly by learning all the iBGP routes in to one separate non-kernel table then using pipes to the various different kernel tables. I need to check if this works, though :) -- Michael
On Wed, 22 Oct 2014 08:04:04 +1300 Michael Fincham <michael@hotplate.co.nz> wrote:
One possibility that did occur to me is to use communities to separate which BGP prefixes get learned in to which kernel route tables, possibly by learning all the iBGP routes in to one separate non-kernel table then using pipes to the various different kernel tables. I need to check if this works, though :)
Upon further consideration, no this will not work as there cannot be overlapping prefixes, among other reasons. Running multiple BIRD processes in separate namespaces seems the most likely solution. -- Michael
participants (2)
-
Michael Fincham -
Pierluigi Rolando