Hi Ondrej, * Ondrej Zajicek
> VRRP: > Maybe. Is there any advantage if it is integrated in routing daemon > (instead of using independent VRRP daemon)? See below. > MPLS/VRF support: > That looks interesting, but i doubt that many people uses that on Linux > - for example MPLS forwarding for Linux is not even part of an official > kernel source tree. I understand that Mikrotik's RouterOS support MPLS, and that's Linux 2.6-based as far as I know. But they might have their own code for it, I don't know. > Possibility to configure the local network directly from BIRD: > Using separate independent tools to do independent things is just the > Linux way. I don't think it is a good idea to integrate this to BIRD. I'd have to disagree with you on this. It might have been the «Linux way» before, but only out of neccessity - there wasn't any better way of doing it. However, intergrated solutions are now the name of the game: * Red Hat's ifupdown suite integrates functionality from ifconfig, route, ifenslave, vconfig, and brctl, and probably more too. This is the standard way of configuring the network on a Red Hat machine. * Debian's ifupdown suite: Ditto. * kernel.org's iproute2 suite: Integrates at least functionality from ifconfig, route, and vconfig. * GNOME NetworkManager: Intergrates functionality from ifconfig, route, vconfig, openvpn, vpnc, iwconfig, wpa_supplicant, probably more. * Quagga: As well as route functionality, it intergrates ifconfig functionality. * Vyatta/xorp: route, ifconfig, vlans, brctl, iptables, setkey/openswan, tunnels, vrrp, .... * Mikrotik RouterOS: Intergrates *everything* network-related AFAIK. Also, the same goes for non-Linux based router operating systems, for example Juniper JunOS. I have several Juniper routers in my network and I've never *ever* had to resort to configuring anything through the FreeBSD shell, even though I probably could if I really wanted to. This is, in my opinion, a huge advantage of JunOS, and probably Vyatta and RouterOS as well (although I have less experience with these two). I have *one* configuration file to back up - if the box explodes I can load that file onto a new one and it'll behave in the exact same way. I can also sit down and simply read the configuration file and get a understanding of how everything ties together. Reading bird's configuration file, you can see a route A via next hop B - but where is B, exactly? No way of telling. Then you'll have to dig through /etc to find that out. Ok, found it on vlan interface C. What physical interface is that? Back to digging in /etc again...oh, 802.3ad trunk D! So which are the members on that one...? And so on, and so on. I'd strongly prefer to being able to configure A+B+C+D+[...]+Z all in one place - it makes everything much more easy to work with. Also note that if BIRD supported this, that wouldn't preclude people that actively *want* to use the «Linux way» of configuring everything in as many different places as possible from doing so. However it would also cater for people like me, that prefer intergrated solutions. :-) BTW, the desire to see VRRP as a native feature in BIRD is for the exact same reason. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27
