On 2024-01-25 18:23, Alexander Zubkov wrote:
On Thu, Jan 25, 2024 at 6:11 PM Maria Matejka wrote:
On 2024-01-25 17:08, Alexander Zubkov wrote:
But I think the problem with no filters is bigger when the RTR server is out.
It is not just the short period of time when the peer can announce anyt
On Thu, Jan 25, 2024 at 6:11 PM Maria Matejka wrote:
>
> On 2024-01-25 17:08, Alexander Zubkov wrote:
>
> But I think the problem with no filters is bigger when the RTR server is out.
> It is not just the short period of time when the peer can announce anything.
> If rpki autoreload is on it wil
On 2024-01-25 17:08, Alexander Zubkov wrote:
But I think the problem with no filters is bigger when the RTR server
is out. It is not just the short period of time when the peer can
announce anything. If rpki autoreload is on it will cause all bad
announces that was rejected before to pass the f
But I think the problem with no filters is bigger when the RTR server is
out. It is not just the short period of time when the peer can announce
anything. If rpki autoreload is on it will cause all bad announces that was
rejected before to pass the filter now. And if we turn rpki autoreload off,
it
AFAIK in RPKI AS0 means implicit invalid.
On Thu, Jan 25, 2024, 14:31 Maria Matejka via Bird-users <
bird-users@network.cz> wrote:
> On 2024-01-25 11:55, Erin Shepherd wrote:
>
> Spitballing slightly here, but could you avoid this problem by adding
> 0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and ac
On 2024-01-25 11:55, Erin Shepherd wrote:
Spitballing slightly here, but could you avoid this problem by adding
0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?
Obviously the disadvantage here is that if your IRR RTR server goes
down you're basically unfiltered, but it at le
On Thu, Jan 25, 2024 at 11:55:14AM +0100, Erin Shepherd wrote:
> Spitballing slightly here, but could you avoid this problem by adding
> 0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?
>
> Obviously the disadvantage here is that if your IRR RTR server goes
> down you're basical
On Thu, Jan 25, 2024 at 11:41:25AM +0100, Job Snijders wrote:
> On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users wrote:
> > a quick stab at generating the slurm file:
>
> why use SLURM though? SLURM doesn't have a 'maxLength' field like the
> regular JSON input formatted in t
Spitballing slightly here, but could you avoid this problem by adding
0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?
Obviously the disadvantage here is that if your IRR RTR server goes down you're
basically unfiltered, but it at least avoids the availability problem
- Erin
On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users wrote:
> a quick stab at generating the slurm file:
why use SLURM though? SLURM doesn't have a 'maxLength' field like the
regular JSON input formatted in this style has:
https://console.rpki-client.org/rpki.json - which might h
> On 25 Jan 2024, at 09:23, Maria Matejka wrote:
>
>
>
> On 25 January 2024 08:34:36 CET, Jeroen Massar wrote:
>>
>>
>>> On 24 Jan 2024, at 11:08, Maria Matejka wrote:
>>>
>>>
>>>
>>> On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users
>>> wrote:
> On 23 Ja
On 25 January 2024 08:34:36 CET, Jeroen Massar wrote:
>
>
>> On 24 Jan 2024, at 11:08, Maria Matejka wrote:
>>
>>
>>
>> On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users
>> wrote:
>>>
>>>
On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users
wrote:
> On 24 Jan 2024, at 11:08, Maria Matejka wrote:
>
>
>
> On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users
> wrote:
>>
>>
>>> On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users
>>> wrote:
>>>
>>>
>>> Hello bird users,
>>>
>>> I am wondering how you handle matching
Hi,
I want to also show some example of configuration generation:
https://gitlab.com/qratorlabs/example-automatic-filters
There are also a couple of links to other similar projects. Jeroen,
thanks for the reference to kees, I've added it to the list there too.
Regards,
Alexander
On Wed, Jan 24,
On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users
wrote:
>
>
>> On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users
>> wrote:
>>
>>
>> Hello bird users,
>>
>> I am wondering how you handle matching both IPv6 and IPv4 prefixes
>> efficiently.
>>
>> We have tons of blocks
> On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users
> wrote:
>
>
> Hello bird users,
>
> I am wondering how you handle matching both IPv6 and IPv4 prefixes
> efficiently.
>
> We have tons of blocks in our config like these:
Generate the configs.
Especially when doing IRR filterin
That is almost the same methodology I used in other engines(RPL and XPL).
But, after having some issues on performance of control plane, I needed to
change a bit...
Splitting the IFs of v4 and v6, and then inside that IF testing for the
Prefix-list.
Doing that recursion on IFs, reduced a bit the im
Hello Nico,
I make separate defines per family (like you did) and then in my filters
I just use:
if (net.type = NET_IP4 && ! (net ~ ASxxx_IPV4)) then reject;
if (net.type = NET_IP6 && ! (net ~ ASxxx_IPV6)) then reject;
Best,
Luiz
On 23/01/2024 14:13, Nico Schottelius via Bird-users wr
Hello bird users,
I am wondering how you handle matching both IPv6 and IPv4 prefixes
efficiently.
We have tons of blocks in our config like these:
define net_genauso_v6 = [
2a0a:5480::/29+
];
define net_genauso_v4 = [
185.203.113.0/24,
185.116.114.0/24
];
And then later
19 matches
Mail list logo