Hello We (BIRD developers) would like to know which major features you miss in BIRD and would like to be implemented. If you have some opinions on that issue, please write suggested features together with several sentences about why you think that is the feature we should implement or why you need that. This inquiry is oriented on long-term, major features, but if you have some minor requests, you are also welcome. Our current short-term plan is to fix RIP (and multipath for RIP) and implement Route Origin Authorization / RPKI drafts for BGP. Some examples: OSPF NSSA OSPF opaque LSAs .. or some other OSPF extensions BGP confederations BGP extended communities .. or some other BGP extensions MRT routing table dumps Some monitoring/statistics integration (SNMP, collectd ...) Route aggregation engine Static routes depedent on ping reachability BFD (Bidirectional Forwarding Detection) IS-IS Some ad-hoc wireless routing like OSPF MANET or OLSR Multicast routing? .. or perhaps no new big features, just some more work to already implemented areas? BTW, from these examples, my personal preference is currently on BFD. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello, I'm very interested in OSPF NSSA: we use it to allow our PC-routers to inform CORE-routers about availability of services. We don't want our PC-routers to calculate topology, so we have to put them in stub area. But we need them to redistribute routes, so it must be NSSA area. It will be excelent if you'll add support for BFD-protocol. We already use separate daemon https://github.com/JakeMont/OpenBFDD but it will be nice if all will be inside BIRD. There is also one BGP NLRI extension: Flow Specification RFC 5575. From my point of view it will be good, if you'll support it. On 02.05.2011 23:53, Ondrej Zajicek wrote:
Hello
We (BIRD developers) would like to know which major features you miss in BIRD and would like to be implemented. If you have some opinions on that issue, please write suggested features together with several sentences about why you think that is the feature we should implement or why you need that. This inquiry is oriented on long-term, major features, but if you have some minor requests, you are also welcome.
Our current short-term plan is to fix RIP (and multipath for RIP) and implement Route Origin Authorization / RPKI drafts for BGP.
Some examples:
OSPF NSSA OSPF opaque LSAs .. or some other OSPF extensions BGP confederations BGP extended communities .. or some other BGP extensions MRT routing table dumps Some monitoring/statistics integration (SNMP, collectd ...) Route aggregation engine Static routes depedent on ping reachability BFD (Bidirectional Forwarding Detection) IS-IS Some ad-hoc wireless routing like OSPF MANET or OLSR Multicast routing?
.. or perhaps no new big features, just some more work to already implemented areas?
BTW, from these examples, my personal preference is currently on BFD.
-- Fedor Dikarev Rambler Internet Holding
--On 2 May 2011 23:56:20 +0400 Fedor Dikarev <fe@rambler-co.ru> wrote:
I'm very interested in OSPF NSSA
+1. Similar reasons. In this case because I want OSPF to advertise static device routes, but don't want to carry the whole DB. I suspect with hackery this could actually done without NSSA by treating them as if they were interface routes (Type 2 LSA rather than Type 5 IIRC). -- Alex Bligh
On Mon, May 02, 2011 at 11:56:20PM +0400, Fedor Dikarev wrote:
Hello,
I'm very interested in OSPF NSSA: we use it to allow our PC-routers to inform CORE-routers about availability of services. We don't want our PC-routers to calculate topology, so we have to put them in stub area. But we need them to redistribute routes, so it must be NSSA area.
BTW, you can do that by using separate OSPF instance instead of NSSA area. Just export most routes from 'stub' instance to 'main' instance, but export just static default route to 'stub' instance. But that suppose you have BIRD on the 'boundary' router. Just wondering, why you do not want to calculate topology on PC routers? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On 03.05.2011 01:48, Ondrej Zajicek wrote:
On Mon, May 02, 2011 at 11:56:20PM +0400, Fedor Dikarev wrote:
Hello,
I'm very interested in OSPF NSSA: we use it to allow our PC-routers to inform CORE-routers about availability of services. We don't want our PC-routers to calculate topology, so we have to put them in stub area. But we need them to redistribute routes, so it must be NSSA area.
BTW, you can do that by using separate OSPF instance instead of NSSA area. Just export most routes from 'stub' instance to 'main' instance, but export just static default route to 'stub' instance.
But that suppose you have BIRD on the 'boundary' router.
Just wondering, why you do not want to calculate topology on PC routers?
We are using OSPF on PC not for routing purposes: those servers are DNS, web, mail and other clusters. So on each server if it's alive: server is up, all backends are availiable and so, servers are anouncing "service ip" to OSPF. If there are some problems with backends then PC in cluster stop redistribute "service ip" or change metric for it. So for that reason I think that NSSA is better than anything else. I'm also thinking about using BGP for that purposes but we'he already have working OSPF-scheme and it will be nice if we could continue using it. -- Fedor Dikarev Rambler Internet Holding
on 02.05.2011 21:53 Ondrej Zajicek wrote:
and implement Route Origin Authorization / RPKI drafts for BGP.
excellent idea! Still reminds me that I owe you all a dinner! Please let me know when it would be most convenient. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold@nipper.de phone: +49 6224 9259 299 mobile: +49 152 53717690 fax: +49 6224 9259 333
On May 02, Ondrej Zajicek <santiago@crfreenet.org> wrote:
BGP extended communities As an IX operator I would like to see this.
MRT routing table dumps And as the zebra-dump-parser author, I think that some people would find this useful as well. :-)
Static routes depedent on ping reachability I do not really see BIRD as a good place for this.
BFD (Bidirectional Forwarding Detection) This would be very useful for route servers as well.
-- ciao, Marco
1. Troubleshooting tools like traceroutes, 2. BGP peer group Warm Regards ---------------------------------- Anibe Onuche Website : www.nixp.net -----Original Message----- From: owner-bird-users@atrey.karlin.mff.cuni.cz [mailto:owner-bird-users@atrey.karlin.mff.cuni.cz] On Behalf Of Ondrej Zajicek Sent: Monday, May 02, 2011 8:54 PM To: bird-users@network.cz Subject: Feature requests Hello We (BIRD developers) would like to know which major features you miss in BIRD and would like to be implemented. If you have some opinions on that issue, please write suggested features together with several sentences about why you think that is the feature we should implement or why you need that. This inquiry is oriented on long-term, major features, but if you have some minor requests, you are also welcome. Our current short-term plan is to fix RIP (and multipath for RIP) and implement Route Origin Authorization / RPKI drafts for BGP. Some examples: OSPF NSSA OSPF opaque LSAs .. or some other OSPF extensions BGP confederations BGP extended communities .. or some other BGP extensions MRT routing table dumps Some monitoring/statistics integration (SNMP, collectd ...) Route aggregation engine Static routes depedent on ping reachability BFD (Bidirectional Forwarding Detection) IS-IS Some ad-hoc wireless routing like OSPF MANET or OLSR Multicast routing? .. or perhaps no new big features, just some more work to already implemented areas? BTW, from these examples, my personal preference is currently on BFD. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
BGP dynamic neighbors using subnet ranges. /Tias On 5/2/11 21:53 , Ondrej Zajicek wrote:
Hello
We (BIRD developers) would like to know which major features you miss in BIRD and would like to be implemented. If you have some opinions on that issue, please write suggested features together with several sentences about why you think that is the feature we should implement or why you need that. This inquiry is oriented on long-term, major features, but if you have some minor requests, you are also welcome.
Our current short-term plan is to fix RIP (and multipath for RIP) and implement Route Origin Authorization / RPKI drafts for BGP.
Some examples:
OSPF NSSA OSPF opaque LSAs .. or some other OSPF extensions BGP confederations BGP extended communities .. or some other BGP extensions MRT routing table dumps Some monitoring/statistics integration (SNMP, collectd ...) Route aggregation engine Static routes depedent on ping reachability BFD (Bidirectional Forwarding Detection) IS-IS Some ad-hoc wireless routing like OSPF MANET or OLSR Multicast routing?
.. or perhaps no new big features, just some more work to already implemented areas?
BTW, from these examples, my personal preference is currently on BFD.
* Ondrej Zajicek
We (BIRD developers) would like to know which major features you miss in BIRD and would like to be implemented.
Hi, I'm not currently using BIRD at all (due to the lack of OSPF NSSA support), so this is free from memory from when I was evaluating it, so apologies if any of these are already implemented. Anyway, here goes, in no particular order: * OSPFv2/v3 NSSA - I'm already using NSSA extensively so BIRD needs to support it in order for me to plug it in to my network. * BFD - very useful for fast failure detection when peering through non- direct connection (e.g. like an internet exchange) * Possibility to configure the local network directly from BIRD. One of the most annoying thing when building software-based routers is that you have to configure one thing here, another thing there, and so on. In particular, configuring IP addresses would be a great (Quagga can already do this). Also VLAN-tagged interfaces, 802.3ad trunks, and so on. * VRRPv2/v3 - extensively used in my data centre environment at least. * Link-state dependent routes - I remember this was discussed on the list a while back. If a physical link goes down, all routes and adjacencies dependent on that link should be instantly removed - we don't want to wait for some timeout. * Multi-AF OSPFv3 support (RFC 5838) - currently I need to maintain two separate OSPF topologies in my network (OSPFv2 for IPv4 and OSPFv3 for IPv6). That's a maintenance burden I'd rather not have, and multi-AF OSPFv3 would allow me to throw out OSPFv2. * MPLS/VRF support - i.e. RSVP-TE and LDP. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
* BFD - very useful for fast failure detection when peering through non- direct connection (e.g. like an internet exchange)
* Link-state dependent routes - I remember this was discussed on the list a while back. If a physical link goes down, all routes and adjacencies dependent on that link should be instantly removed - we don't want to wait for some timeout.
+1 for both of these. BFD (RFC 5880) in particular is something I would really like to see implemented. -- Marty
On Tue, May 03, 2011 at 11:05:16AM -0700, Marty Anstey wrote:
* BFD - very useful for fast failure detection when peering through non- direct connection (e.g. like an internet exchange)
* Link-state dependent routes - I remember this was discussed on the list a while back. If a physical link goes down, all routes and adjacencies dependent on that link should be instantly removed - we don't want to wait for some timeout.
+1 for both of these. BFD (RFC 5880) in particular is something I would really like to see implemented.
Link-state dependent routes we support from 1.3.0 -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On 2.5.2011 21:53, Ondrej Zajicek wrote:
Hello
A few weeks ago I had presentation about BIRD at Netnod meeting. I asked very similar question and surprisingly a lot of people requested IS-IS. Is here somebody also interested in this protocol? Ondrej
We (BIRD developers) would like to know which major features you miss in BIRD and would like to be implemented. If you have some opinions on that issue, please write suggested features together with several sentences about why you think that is the feature we should implement or why you need that. This inquiry is oriented on long-term, major features, but if you have some minor requests, you are also welcome.
I have one feature request besides new protocols: Support the source attribute of routing table entries in linux. It's only important for udp-connections to a router running bird. Example: Two router (A and B) with bird on them, a lan connected to each one and a VPN link between them. OSPF is used to tell router B the route to the lan behind router A and vice versa. Router A: 192.168.254.0/24 dev eth0 proto kernel scope link src 192.168.254.1 (local lan, created with ifconfig) 10.10.254.0/24 dev tun0 proto kernel scope link src 10.10.254.1 (link to router B, created from openvpn) 192.168.1.0/24 via 10.10.254.5 dev tun0 proto bird (the lan at router B, created by bird) Router B: 192.168.1.0/24 dev lan proto kernel scope link src 192.168.1.1 (local lan, created with ifconfig) 10.10.254.0/24 dev tun2 proto kernel scope link src 10.10.254.5 (link to router A, created from openvpn) 192.168.254.0/24 via 10.10.254.1 dev tun2 proto bird (the lan at router A, created by bird) Note there is no src on the routes from bird. Now try do to a dns-lookup from lan at A to the dns-server installed on router B, using the lan ip of the router: $host fritz.box 192.168.1.1 ;; reply from unexpected source: 10.10.254.5#53, expected 192.168.1.1#53 ;; reply from unexpected source: 10.10.254.5#53, expected 192.168.1.1#53 ;; connection timed out; no servers could be reached I could use IP 10.10.254.5, but I don't want the transfer-IPs to be used. I only want to have the two lans with the two subnets used/visible. Solution: Change the routes created from bird and set the src attribute to the wanted IP. Router A: # ip r change 192.168.1.0/24 via 10.10.254.5 dev tun0 src 192.168.254.1 Router B: # ip r change 192.168.254.0/24 via 10.10.254.1 dev tun2 src 192.168.1.1 Now everything works as expected: On lan at router A: $ host fritz.box 192.168.1.1 Using domain server: Name: 192.168.1.1 Address: 192.168.1.1#53 Aliases: fritz.box has address 192.168.1.1 I hope you understand the example. So my feature request: Support of the src attribe of the linux routing table in bird. I think of setting it somewhere in bird config, maybe a filter. Thanks, Stefan Hellermann
On Thu, May 05, 2011 at 11:37:57PM +0200, Stefan Hellermann wrote:
I have one feature request besides new protocols: Support the source attribute of routing table entries in linux. It's only important for udp-connections to a router running bird.
Already implemented in v1.3.1, see route attribute krt_prefsrc in: http://bird.network.cz/?get_doc&f=bird-6.html#ss6.4
Note there is no src on the routes from bird. Now try do to a dns-lookup from lan at A to the dns-server installed on router B, using the lan ip of the router: $host fritz.box 192.168.1.1 ;; reply from unexpected source: 10.10.254.5#53, expected 192.168.1.1#53 ;; reply from unexpected source: 10.10.254.5#53, expected 192.168.1.1#53 ;; connection timed out; no servers could be reached
BTW, in this case the problem is in the dns-server - properly implemented UDP server should answer from the same address the request was sent to, without any tricks with route src attributes. Another way (simpler and more usual) to fix that is to configure dns-server to bind to the only one IP address. Most servers have some config option to do that. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Am 06.05.2011 01:44, schrieb Ondrej Zajicek:
On Thu, May 05, 2011 at 11:37:57PM +0200, Stefan Hellermann wrote:
I have one feature request besides new protocols: Support the source attribute of routing table entries in linux. It's only important for udp-connections to a router running bird.
Already implemented in v1.3.1, see route attribute krt_prefsrc in:
Oh, thank you for implementing it! It works like a charm! Is there a way to donate to this project? Cheers, Stefan
On Mon, May 02, 2011 at 09:53:39PM +0200, Ondrej Zajicek wrote:
Hello
We (BIRD developers) would like to know which major features you miss in BIRD and would like to be implemented. If you have some opinions on that issue, please write suggested features together with several sentences about why you think that is the feature we should implement or why you need that. This inquiry is oriented on long-term, major features, but if you have some minor requests, you are also welcome.
I would like to ask for support of invertion of (pair) sets. In past year we discussed that http://marc.info/?l=bird-users&m=128445986230853&w=2 Thanks for attention. -- MINO-RIPE
On Thu, May 12, 2011 at 04:19:47PM +0300, Alexander Shikoff wrote:
On Mon, May 02, 2011 at 09:53:39PM +0200, Ondrej Zajicek wrote:
Hello
We (BIRD developers) would like to know which major features you miss in BIRD and would like to be implemented. If you have some opinions on that issue, please write suggested features together with several sentences about why you think that is the feature we should implement or why you need that. This inquiry is oriented on long-term, major features, but if you have some minor requests, you are also welcome.
I would like to ask for support of invertion of (pair) sets. In past year we discussed that http://marc.info/?l=bird-users&m=128445986230853&w=2
I forgot about this one, i will add that. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Thu, May 12, 2011 at 04:19:47PM +0300, Alexander Shikoff wrote:
I would like to ask for support of invertion of (pair) sets. In past year we discussed that http://marc.info/?l=bird-users&m=128445986230853&w=2
Hello Instead of set invertion, which has some problems, i implemented clist filter operation, which works like remove operation with inverted set. Should do the trick. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello Thanks for all the answers. Here are comments to received requests: NSSA: This seems to be, surprisingly for me, the most requested feature, as it does not look hard to implement i will probably implement that in near future. BFD: As suggested in the first mail, i will probably implement that in near future. MRT routing table dumps, BGP extended communities, Flow Specification RFC 5575: These look interesting, perhaps we implement some of these (esp. MRT table dumps), but no solid plans. VRRP: Maybe. Is there any advantage if it is integrated in routing daemon (instead of using independent VRRP daemon)? I would guess that there isn't any interaction between VRRP and routing, but i don't have any experience with VRRP. Multi-AF OSPFv3 support (RFC 5838): This is interesting. Currently BIRD have complete separation of IPv4 and IPv6 (two binaries, two processes), but this is probably the first real reason for integration (or likely some kind of partial integration, like ability of bird6 to handle IPv4 routes). 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. Privilege separation: Real privilege separation is probably unnecessary complicated solution for our purposes. We implemented privilege restriction, where BIRD runs under nonprivileged user and uses Linux capabilities to keep just the required privileges. The code is in GIT and will be probably included in the next version. BGP peer group: What exactly this should solve? If just common defaults, then i think that with common filters and copy/paste in editor (or config file generated by a script) there is not a real reason for peer groups. But perhaps some generic tool for sharing common defaults would be a good idea. BGP dynamic neighbors using subnet ranges: This might be useful but it really doesn't fit well to the BIRD protocol framework. Troubleshooting tools like traceroutes: Do not see any reason to use that from BIRD if that can be easily used from Linux command line and there are already plenty of these. 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. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On May 16, 2011, at 12:59, Ondrej Zajicek wrote:
VRRP: Maybe. Is there any advantage if it is integrated in routing daemon (instead of using independent VRRP daemon)? I would guess that there isn't any interaction between VRRP and routing, but i don't have any experience with VRRP.
We often use it (vrrp or the BSD version "carp") on routers so "dumb hosts" can have a default route that always works. I agree though that it's not really related to the routing stuff per-se.
BGP peer group: What exactly this should solve? If just common defaults, then i think that with common filters and copy/paste in editor (or config file generated by a script) there is not a real reason for peer groups. But perhaps some generic tool for sharing common defaults would be a good idea.
The bird configuration is so powerful that it seems like an odd omission. We use vyatta on some of routers (which is basically a linux distribution and configuration system for various tools including quagga). They don't have peer-group support for IPv6 peers (yet) and the "copy-paste" stuff is really error-prone. On the IPv4 peers we just have ASN, description and peer IP with the occasional override -- almost impossible to make a mistake. On the IPv6 peers we have a dozen lines of configuration; each an opportunity to mess up and unless we add comments it's easy to lose track of what's configured as it is because it's our default on the IX and what's specific to the peer. In other words: Peer groups are really useful. :-) Maybe at the "route-server scale" you all generate the configuration files from a database or some such anyway; but at smaller scale it's nice to have those "tools" built-in. - ask
Hello!
BGP peer group: What exactly this should solve? If just common defaults, then i think that with common filters and copy/paste in editor (or config file generated by a script) there is not a real reason for peer groups. But perhaps some generic tool for sharing common defaults would be a good idea.
Maybe a simple inheritance scheme would be sufficient: when defining a new protocol instance, refer to a previously defined instance and use all of its settings as defaults. Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth There are two rules to success: 1. Never tell all you know.
Ondrej, --On 16 May 2011 21:59:56 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
NSSA: This seems to be, surprisingly for me, the most requested feature, as it does not look hard to implement i will probably implement that in near future.
Thanks
VRRP: Maybe. Is there any advantage if it is integrated in routing daemon (instead of using independent VRRP daemon)? I would guess that there isn't any interaction between VRRP and routing, but i don't have any experience with VRRP.
We would be interested in a sane implementation of VRRP. We'd also be even more interested in other interfaces redundancy protocols that do not "waste" IP addresses (e.g. do not use IP addresses for the native interfaces). One problem with VRRP is that it is allegedly patent encumbered. -- Alex Bligh
maybe ucarp ? http://www.ucarp.org/project/ucarp On Tue, May 17, 2011 at 4:23 PM, Alex Bligh <alex@alex.org.uk> wrote:
Ondrej,
--On 16 May 2011 21:59:56 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
NSSA: This seems to be, surprisingly for me, the most requested feature, as it does not look hard to implement i will probably implement that in near future.
Thanks
VRRP: Maybe. Is there any advantage if it is integrated in routing daemon (instead of using independent VRRP daemon)? I would guess that there isn't any interaction between VRRP and routing, but i don't have any experience with VRRP.
We would be interested in a sane implementation of VRRP. We'd also be even more interested in other interfaces redundancy protocols that do not "waste" IP addresses (e.g. do not use IP addresses for the native interfaces). One problem with VRRP is that it is allegedly patent encumbered.
-- Alex Bligh
-- Thanx and regd's. Allan. http://www.in2dwok.com
--On 17 May 2011 17:00:07 +0530 Allan Pinto <allan316@gmail.com> wrote:
maybe ucarp ? http://www.ucarp.org/project/ucarp
Thanks. I looked at that and rejected it and now can't remember why. I will try again. -- Alex Bligh
I am curious, what is the deal breaker about VRRP requirement of having participating interfaces besides that it's two less addresses from your DHCP pool? Ziyad Basheer On Tue, May 17, 2011 at 1:53 PM, Alex Bligh <alex@alex.org.uk> wrote:
Ondrej,
--On 16 May 2011 21:59:56 +0200 Ondrej Zajicek <santiago@crfreenet.org> wrote:
NSSA:
This seems to be, surprisingly for me, the most requested feature, as it does not look hard to implement i will probably implement that in near future.
Thanks
VRRP:
Maybe. Is there any advantage if it is integrated in routing daemon (instead of using independent VRRP daemon)? I would guess that there isn't any interaction between VRRP and routing, but i don't have any experience with VRRP.
We would be interested in a sane implementation of VRRP. We'd also be even more interested in other interfaces redundancy protocols that do not "waste" IP addresses (e.g. do not use IP addresses for the native interfaces). One problem with VRRP is that it is allegedly patent encumbered.
-- Alex Bligh
--On 17 May 2011 22:36:40 +0300 Ziyad Basheer <ziyadbasheer213@gmail.com> wrote:
I am curious, what is the deal breaker about VRRP requirement of having participating interfaces besides that it's two less addresses from your DHCP pool?
We allocate /29s to the (thousands of) networks in question. 1 for broadcast, 1 for network and 1 for the router is bad enough (37.5% overhead). Losing another 2 is ridiculous, as "overhead" IPs would exceed utilisable IPs. -- Alex Bligh
* Alex Bligh
We would be interested in a sane implementation of VRRP. We'd also be even more interested in other interfaces redundancy protocols that do not "waste" IP addresses (e.g. do not use IP addresses for the native interfaces). One problem with VRRP is that it is allegedly patent encumbered.
FWIW, Keepalived's VRRP implementation has a feature which allows it to 1) specify any arbitrary source address in the VRRP hellos, e.g. the loopback interface's, and 2) define the virtual address with a netmask. This probably breaks RFC compliance and interoperability with other implementations, but it does allow you to run VRRP on unnumbered interfaces, thus not wasting any IP addresses. One caveat is that you need to disable uRPF, another one is that the VRRP-speaking routers will be active/passive for egress traffic to the LAN, since the passive one(s) won't have an interface route to the network served. In any case, an VRRP implementation in BIRD could easily implement the same trick. Also, I believe it is HSRP that's patent encumbered, not VRRP. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
On 18 May 2011 09:02, Tore Anderson <tore.anderson@redpill-linpro.com> wrote:
Also, I believe it is HSRP that's patent encumbered, not VRRP.
HSRP is a proprietary Cisco technology that is (largely) unimplemented outside of the Cisco world. The IETF standard is VRRP but that *is* patent encumbered. See section 4.4 in the IETF Draft "IPR Working Group Guidelines": http://tools.ietf.org/id/draft-ietf-ipr-wg-guidelines-00.txt I've been led to believe that CARP is not affected by the patent - but is obviously not particularly inter-operable with routers from the "big vendors". Matthew Walster
--On 18 May 2011 10:02:18 +0200 Tore Anderson <tore.anderson@redpill-linpro.com> wrote:
FWIW, Keepalived's VRRP implementation has a feature which allows it to 1) specify any arbitrary source address in the VRRP hellos, e.g. the loopback interface's, and 2) define the virtual address with a netmask.
That sounds useful.
This probably breaks RFC compliance and interoperability with other implementations, but it does allow you to run VRRP on unnumbered interfaces, thus not wasting any IP addresses. One caveat is that you need to disable uRPF,
That would be a problem for us, but I presume is fixable simply by making that an exception to uRPF.
another one is that the VRRP-speaking routers will be active/passive for egress traffic to the LAN, since the passive one(s) won't have an interface route to the network served.
That's not a problem.
In any case, an VRRP implementation in BIRD could easily implement the same trick.
Yes. Or borrow the CARP implementation. As far as I can see, using L2 to do this is in some ways more sensible than using L3.
Also, I believe it is HSRP that's patent encumbered, not VRRP.
http://www.ietf.org/ietf-ftp/IPR/VRRP-CISCO http://www.delphion.com/details?pn=EP01006702A3 -- Alex Bligh
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
On Monday 02 May 2011 at 21:53 (CET), Ondrej Zajicek wrote:
We (BIRD developers) would like to know which major features you miss in BIRD and would like to be implemented. ... .. or perhaps no new big features, just some more work to already implemented areas?
or perhaps some "minor" features/changes: * Deduplication of history in the client: When doing "show protocols all" 10 times in a row, only add it to the history list once. Or perhaps even dedup the complete history. * More parser friendly output Currently the output of the client contains a fair ammount of whitespace and other cruft to align stuff etc. A less "pretty" output would make it much easier to parse it. Obviously it would require a (commandline) parameter to select this mode in other to not interfere with interactive usage. Other than that, keep up the good work! Regards, Ruben Laban
participants (19)
-
Alex Bligh -
Alexander Shikoff -
Allan Pinto -
Anibe Onuche -
Arnold Nipper -
Ask Bjørn Hansen -
csszep -
Fedor Dikarev -
Martin Mares -
Marty Anstey -
Mathias Wolkert -
Matthew Walster -
md＠Linux.IT -
Ondrej Filip -
Ondrej Zajicek -
Ruben Laban -
Stefan Hellermann -
Tore Anderson -
Ziyad Basheer