Hey there,
> I'm using bird to gather all prefixes from all routers using
add-paths > so I can easily do searches on my dashboard and graphically
map paths > to destinations and visually see other possible paths that
are not
> best path.
Interesting, how do you do this?
> I'm looking into p
On 4/29/24 19:33, Job Snijders wrote:
On Mon, 29 Apr 2024 at 21:27, Nigel Kukard via Bird-users
wrote:
Hi there Richard,
On 4/29/24 19:14, Richard Laager wrote:
Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge
and simply reject INVALID routes.
Why
On Mon, 29 Apr 2024 at 21:27, Nigel Kukard via Bird-users <
bird-users@network.cz> wrote:
> Hi there Richard,
>
> On 4/29/24 19:14, Richard Laager wrote:
>
> Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge
> and simply reject INVALID routes.
>
> Why would one want to ac
Hi there Richard,
On 4/29/24 19:14, Richard Laager wrote:
Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge and
simply reject INVALID routes.
Why would one want to accept INVALID at all?
If we agree one would reject INVALID, then what is left to tag?
For my specific
Perhaps I am naive, but I assumed one would validate RPKI on the eBGP edge and
simply reject INVALID routes.
Why would one want to accept INVALID at all?
If we agree one would reject INVALID, then what is left to tag?
--
Richard
On Sun, Apr 28, 2024 at 01:00:40PM +0200, Job Snijders wrote:
> On Sat, Apr 27, 2024 at 03:00:45PM +0200, Ondrej Zajicek via Bird-users wrote:
> > On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote:
> > > There's internet draft describing in detail, why it's not a good idea
On Sat, Apr 27, 2024 at 03:00:45PM +0200, Ondrej Zajicek via Bird-users wrote:
> On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote:
> > There's internet draft describing in detail, why it's not a good idea to
> > store RPKI validation state inside community variables at al
On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote:
> There's internet draft describing in detail, why it's not a good idea to
> store RPKI validation state inside community variables at all..
>
> https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-0
There's internet draft describing in detail, why it's not a good idea to
store RPKI validation state inside community variables at all..
https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-00.html
- Daniel
On 4/27/24 5:05 AM, Nigel Kukard via Bird-users wrote:
Hi all,
Hello Nigel,
you can always store this information to custom attributes which are faster
than communities, auto-ignored on export and can't leak to your peers.
BTW that guide looks quite outdated (regarding e.g. the support of autoreload)
and will be even more outdated with BIRD 3 optimized imp
Hi all,
I was busy reading
https://bgpfilterguide.nlnog.net/guides/reject_invalids/ and noticed the
following text...
Note: REALLY DONT store the validation state inside a bgp_community or
bgp_large_community or bgp_ext_community variables. It can cause CPU &
memory overload resulting in co
11 matches
Mail list logo
