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 f
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" feat
--On 18 May 2011 10:02:18 +0200 Tore Anderson
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.
T
On 18 May 2011 09:02, Tore Anderson 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 Dr
* 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
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 Li
--On 17 May 2011 22:36:40 +0300 Ziyad Basheer
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 f
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 wrote:
> Ondrej,
>
> --On 16 May 2011 21:59:56 +0200 Ondrej Zajicek
> wrote:
>
>
--On 17 May 2011 17:00:07 +0530 Allan Pinto 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
maybe ucarp ?
http://www.ucarp.org/project/ucarp
On Tue, May 17, 2011 at 4:23 PM, Alex Bligh wrote:
> Ondrej,
>
> --On 16 May 2011 21:59:56 +0200 Ondrej Zajicek
> wrote:
>
>> NSSA:
>> This seems to be, surprisingly for me, the most requested
>> feature, as it does not look hard to implement i wi
Ondrej,
--On 16 May 2011 21:59:56 +0200 Ondrej Zajicek
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 ro
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 woul
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
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
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 th
On Thu, May 05, 2011 at 11:13:02AM +0200, Ondrej Filip wrote:
> >> 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?
> >
> > Our organizatio
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
>
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 bi
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 attr
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
On 5.5.2011 10:57, Oleg wrote:
> On Tue, May 03, 2011 at 04:03:20PM +0200, Ondrej Filip wrote:
>> 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
--On 3 May 2011 08:45:10 +0200 csszep wrote:
Privilege separation and running bird as non root.
FWIW I have had success running bird in a container (unshare -n) on
Linux, though you need to run birdc in the same container.
--
Alex Bligh
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
> * 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 th
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 devel
* 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 t
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
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
Privilege separation and running bird as non root.
Zajicek
Sent: Monday, May 02, 2011 8:54 PM
To: bird-us...@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
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.
>
On May 02, Ondrej Zajicek 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 B
--On 2 May 2011 23:56:20 +0400 Fedor Dikarev 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 a
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
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
em
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
36 matches
Mail list logo