Looks like the date of the post shifted from 03-06 to 04-07,
https://ipng.ch/s/articles/2024/04/07/vpp-ospf.html (Can be seen from
the index page, https://ipng.ch/s/articles/)
On Mon, 8 Apr 2024 at 00:41, babydr DBA James W. Laferriere via
Bird-users wrote:
>
> Hello Pim . I get 404
Hello Pim . I get 404 when trying to access the url below .
Tia , JimL
On Sun, 7 Apr 2024, Ondrej Zajicek via Bird-users wrote:
On Sat, Apr 06, 2024 at 04:54:48PM +0200, Pim van Pelt via Bird-users wrote:
Hoi Ondrej, Bird users,
TL/DR: Ondrej's patch works and allows
On Sat, Apr 06, 2024 at 04:54:48PM +0200, Pim van Pelt via Bird-users wrote:
> Hoi Ondrej, Bird users,
>
> TL/DR: Ondrej's patch works and allows Bird to use OSPFv3 with either
> completely unnumbered interfaces, where it 'borrows' a valid IPv4 address
> from a loopback device. It does so without
Hoi Ondrej, Bird users,
TL/DR: Ondrej's patch works and allows Bird to use OSPFv3 with either
completely unnumbered interfaces, where it 'borrows' a valid IPv4
address from a loopback device. It does so without breaking RFC5838!
On 05.04.2024 16:27, Pim van Pelt via Bird-users wrote:
**Let
On Fri, Apr 05, 2024 at 04:27:27PM +0200, Pim van Pelt wrote:
> Hoi,
>
> On 4/5/24 15:23, Ondrej Zajicek wrote:
> > I have almost implemented 'extended next hop' for OSPFv3. But then i
> > pivoted to supporting properly IPv4 loopback nexthop [*]. Now i have
> > doubts about usefulness of
Hoi,
On 4/5/24 15:23, Ondrej Zajicek wrote:
I have almost implemented 'extended next hop' for OSPFv3. But then i
pivoted to supporting properly IPv4 loopback nexthop [*]. Now i have
doubts about usefulness of 'extended next hop', as any IPv4 router needs
at one IPv4 address anyways (at least to
On Tue, Apr 02, 2024 at 11:49:21PM +0200, Pim van Pelt via Bird-users wrote:
> Hoi Ondrej,
>
> On 02.04.2024 16:40, Ondrej Zajicek via Bird-users wrote:
> > Although one could have option that forces it to interpret as IPv6, i
> > would prefer to have 'extended next hop' option that allows to
On Tue, Apr 02, 2024 at 11:49:21PM +0200, Pim van Pelt via Bird-users wrote:
> Hoi Ondrej,
Hi
> On 02.04.2024 16:40, Ondrej Zajicek via Bird-users wrote:
> > Although one could have option that forces it to interpret as IPv6, i
> > would prefer to have 'extended next hop' option that allows to
Hoi Ondrej,
On 02.04.2024 16:40, Ondrej Zajicek via Bird-users wrote:
Although one could have option that forces it to interpret as IPv6, i
would prefer to have 'extended next hop' option that allows to accept
both IPv4 and IPv6 next hops in Link-LSA.
Did you mean that:
1) under normal
On Mon, Apr 01, 2024 at 04:14:51PM +0200, Sebastian Hahn wrote:
> > Sebastian - my interpretation of 5838 is slightly different, and I don't
> > think it expressly forbids xAF nexthops:
> > > 2.5: Although IPv6 link local addresses could be used as next hops for
> > > IPv4 address families, it
Hi Pim,
> On 31. Mar 2024, at 11:04, Pim van Pelt wrote:
>
> Hoi Ondrej, Nico, Sebastian,
>
> I am revisiting this thread based on the question from Benoit this week
> (https://www.mail-archive.com/bird-users@network.cz/msg07961.html).
>
> On Tue, Jan 30, 2024 at 12:20:41PM +0100, Sebastian
Hoi Ondrej, Nico, Sebastian,
I am revisiting this thread based on the question from Benoit this week (
https://www.mail-archive.com/bird-users@network.cz/msg07961.html).
On Tue, Jan 30, 2024 at 3:25 PM Ondrej Zajicek
wrote:
> On Tue, Jan 30, 2024 at 12:20:41PM +0100, Sebastian Hahn wrote:
> >
Good morning Sebastian,
Sebastian Hahn writes:
>> Is there a way to purely go IPv6 only and still relay stub network IPv4
>> information via an IPv6 only internal area?
>
> I was facing the same issue before, and unfortunately, RFC 5838
> explicitly forbids IPv4 over IPv6 for OSPF.
everytime
Good morning Bernd,
Bernd Naumann writes:>
> Hi Nico,
>
> If every router has "at least" a /32 IPv4 address on loopback[1], you
> could do "OSPF unnumbered". It's not IPv4 over IPv6 but you do not need
> a bunch of IPv4 peer addresses on each and every interface.
>
> [1] IIRC I had some issues
Ondrej Zajicek writes:
>> I was facing the same issue before, and unfortunately, RFC 5838
>> explicitly forbids IPv4 over IPv6 for OSPF.
>
> Well, we could add 'extended next hop' option to override it, even if it
> would be non-standard. It is rather small deviation.
That would be amazing.
On 30.01.24 10:32, Nico Schottelius via Bird-users wrote:
>
> Good morning,
>
> if we are talking about BGP, IPv4 routing over IPv6 works
> beautifully. We just add another IPv4 channel and get BGP MP.
>
> OSPFv3 works fine on IPv6 and when creating two instances, one for IPv6
> one for IPv4,
On Tue, Jan 30, 2024 at 12:20:41PM +0100, Sebastian Hahn wrote:
> Hi Nico,
>
> > On 30. Jan 2024, at 10:32, Nico Schottelius via Bird-users
> > wrote:
> > OSPFv3 works fine on IPv6 and when creating two instances, one for IPv6
> > one for IPv4, things look correct. But how does OSFPv3
> On 30. Jan 2024, at 14:09, Juliusz Chroboczek wrote:
>
>> As an alternative suggestion, I have since evaluated babel which mostly
>> suits my purposes (except for some features not yet implemented in bird,
>> like strict bind)
>
> Could you please explain what's the feature you're missing?
> As an alternative suggestion, I have since evaluated babel which mostly
> suits my purposes (except for some features not yet implemented in bird,
> like strict bind)
Could you please explain what's the feature you're missing?
Thanks,
-- Juliusz
Hi Nico,
> On 30. Jan 2024, at 10:32, Nico Schottelius via Bird-users
> wrote:
> OSPFv3 works fine on IPv6 and when creating two instances, one for IPv6
> one for IPv4, things look correct. But how does OSFPv3 conceptually work
> if the interface of the ospf area do not have IPv4 addresses
20 matches
Mail list logo
