> On 29. Apr 2020, at 03:01, Ondrej Zajicek wrote:
> On Thu, Apr 23, 2020 at 12:15:33PM +0200, Sebastian Hahn wrote:
>>> Well, the RFC 2545 is a bit vague and AFAIK nobody standardized
>>> link-local only sessions. Our position is that the first address is
>>> always global (as that is necessar
On Thu, Apr 23, 2020 at 12:15:33PM +0200, Sebastian Hahn wrote:
> > Well, the RFC 2545 is a bit vague and AFAIK nobody standardized
> > link-local only sessions. Our position is that the first address is
> > always global (as that is necessary for next hop resolving) and the
> > second (optional) i
> On 23. Apr 2020, at 04:35, Ondrej Zajicek wrote:
> On Wed, Apr 22, 2020 at 10:53:12PM +0200, Sebastian Hahn wrote:
>>
>> so I have an update here. My peer is now using an updated FRR, version
>> 7.3-1~deb10u1 (installed from https://deb.frrouting.org), yet it still isn't
>> working (in a n
On Wed, Apr 22, 2020 at 10:53:12PM +0200, Sebastian Hahn wrote:
>
>
> > On 20. Apr 2020, at 10:06, Sebastian Hahn
> > wrote:
> >> On 20. Apr 2020, at 04:02, Darren O'Connor
> >> wrote:
> >>
> >> Is this an ipv6 route? nh length 32 means both a global and link-local
> >> address is being set
> On 20. Apr 2020, at 10:06, Sebastian Hahn
> wrote:
>> On 20. Apr 2020, at 04:02, Darren O'Connor wrote:
>>
>> Is this an ipv6 route? nh length 32 means both a global and link-local
>> address is being set. RFC2545 section 3
>
> Yes, this is indeed an ipv6 route. I am using many IPv6 rout
> On 20. Apr 2020, at 04:02, Darren O'Connor wrote:
>
> Is this an ipv6 route? nh length 32 means both a global and link-local
> address is being set. RFC2545 section 3
Yes, this is indeed an ipv6 route. I am using many IPv6 routes with other
peers, they do not hit the same code path. Thank
> On 20. Apr 2020, at 03:36, Donald Sharp wrote:
>
> Sebastian -
>
> I cannot speak towards bird's behavior here but I can say that FRR has
> fixed a couple of nexthop related issues with what we send to our
> peers since the 6.0 release. I would please consider upgrading to a
> much later v
> On 20. Apr 2020, at 05:05, Ondrej Zajicek wrote:
> On Mon, Apr 20, 2020 at 12:46:17AM +0200, Sebastian Hahn wrote:
>> In a bird 2.0.7 setup, I was unable to import routes from one of my peers.
>> It is the only one using frr (version 6.02-2 on debian), most other peers
>> use bird1 or bird2
On Mon, Apr 20, 2020 at 12:46:17AM +0200, Sebastian Hahn wrote:
> Hi,
>
> let me preface this that I very much do not know what I am doing here, and
> have been somewhat unsuccessful in trying to understand what's going on by
> searching online. I would love an explanation though!
>
> In a bird
Is this an ipv6 route? nh length 32 means both a global and link-local
address is being set. RFC2545 section 3
On Sun, 19 Apr 2020 at 21:39, Donald Sharp
wrote:
> Sebastian -
>
> I cannot speak towards bird's behavior here but I can say that FRR has
> fixed a couple of nexthop related issues wi
Sebastian -
I cannot speak towards bird's behavior here but I can say that FRR has
fixed a couple of nexthop related issues with what we send to our
peers since the 6.0 release. I would please consider upgrading to a
much later version if you can, 7.2 or 7.3 should have the fixes.
thanks!
dona
Hi,
let me preface this that I very much do not know what I am doing here, and have
been somewhat unsuccessful in trying to understand what's going on by searching
online. I would love an explanation though!
In a bird 2.0.7 setup, I was unable to import routes from one of my peers. It
is the o
On Mon, Sep 30, 2019 at 07:28:22PM +0200, mikma.b...@lists.m7n.se wrote:
> On 30 September 2019 01:52:22 CEST, Ondrej Zajicek
>
> > Yes. Technically it is not because the other route is also BGP, but
> > because the other route is also recursive / also has indirect next hop.
> > BIRD implements on
On 30 September 2019 01:52:22 CEST, Ondrej Zajicek
Yes. Technically it is not because the other route is also BGP, but
because the other route is also recursive / also has indirect next hop.
BIRD implements only one level of indirection.
Is this a problem? Which use cases require more levels of
Hi Ondrej,
On 30/09/2019 01:52, Ondrej Zajicek wrote:
> On Sun, Sep 29, 2019 at 08:49:57PM +0200, Alarig Le Lay wrote:
>> Hello,
>>
>> It seems that bird can’t resolve the next-hop in that case. But there is
>> no issue when the next-hop is announced by OSPF.
>
> Hello
>
> Yes. Technically it is
On Sun, Sep 29, 2019 at 08:49:57PM +0200, Alarig Le Lay wrote:
> Hello,
>
> It seems that bird can’t resolve the next-hop in that case. But there is
> no issue when the next-hop is announced by OSPF.
Hello
Yes. Technically it is not because the other route is also BGP, but
because the other rout
Hello,
It seems that bird can’t resolve the next-hop in that case. But there is
no issue when the next-hop is announced by OSPF.
bird> show route all for 45.91.127.1
Table master4:
45.91.127.0/24 unreachable [ibgp_hv02_ipv4 16:16:24.927 from
89.234.186.40] * (100/-) [i]
Type: BGP un
On Wed, May 09, 2018 at 07:38:31AM +, Arvin Gan wrote:
> Hi all,
>
>I notice below description in user guide, my understand is source
> address mainly used for BGP session for TCP connection ,don't understand
> why this source is also used as next_hop_addr calculation.
Hi
Generally, BGP s
Hi all,
I notice below description in user guide, my understand is source address
mainly used for BGP session for TCP connection ,don't understand why this
source is also used as next_hop_addr calculation. If source address is related
with next hop calculation, this case is may not support: u
On Fri, Dec 04, 2015 at 02:23:04PM -0800, João Taveira Araújo wrote:
> Hi,
>
> I'm running into a difference in behaviour between bird and bird6,
> although admittedly it may come from netlink itself. I'm using bird
> 1.5.0, but have also tried with build from latest git head.
>
> Assume a connec
Hi,
I'm running into a difference in behaviour between bird and bird6,
although admittedly it may come from netlink itself. I'm using bird
1.5.0, but have also tried with build from latest git head.
Assume a connection to an upstream router over a link addressed with
10.0.0.0/31 or ::0/127 fo
21 matches
Mail list logo
