Revalidating RPKI
Maria Matějka
jan.matejka at nic.cz
Wed Oct 23 23:48:48 CEST 2019
Well, this is exactly what the documentation speaks about. You have two instances of RPKI protocol, both of them having one cache server and two channels.
Maria
On October 23, 2019 11:22:35 PM GMT+02:00, Darren O'Connor <mellow.drifter at gmail.com> wrote:
>Hi Maria.
>
>Maybe I'm misunderstanding the RPKI instances. My local bird2 instance
>is
>connected to two routinator cache servers. Both are sending IPv4 and
>IPv6
>information over. This is the outputs of both on this particular bird2
>instance:
>
>bird> show protocols all routinator1
>Name Proto Table State Since Info
>routinator1 RPKI --- up 2019-10-22 Established
> Cache server: 10.0.0.1:3323
> Status: Established
> Transport: Unprotected over TCP
> Protocol version: 1
> Session ID: 766
> Serial number: 73
> Last update: before 0.309 s
> Refresh timer : 899.690/900
> Retry timer : ---
> Expire timer : 172799.690/172800
> Channel roa4
> State: UP
> Table: roa_v4
> Preference: 100
> Input filter: ACCEPT
> Output filter: REJECT
> Routes: 96534 imported, 0 exported, 50987 preferred
> Route change stats: received rejected filtered ignored
>accepted
> Import updates: 96696 0 0 0
> 96696
> Import withdraws: 162 0 --- 0
> 162
> Export updates: 0 0 0 ---
> 0
> Export withdraws: 0 --- --- ---
> 0
> Channel roa6
> State: UP
> Table: roa_v6
> Preference: 100
> Input filter: ACCEPT
> Output filter: REJECT
> Routes: 16307 imported, 0 exported, 8638 preferred
> Route change stats: received rejected filtered ignored
>accepted
> Import updates: 16311 0 0 0
> 16311
> Import withdraws: 4 0 --- 0
> 4
> Export updates: 0 0 0 ---
> 0
> Export withdraws: 0 --- --- ---
> 0
>
>bird> show protocols all routinator2
>Name Proto Table State Since Info
>routinator2 RPKI --- up 2019-10-22 Established
> Cache server: 10.0.0.2:3323
> Status: Established
> Transport: Unprotected over TCP
> Protocol version: 1
> Session ID: 632
> Serial number: 71
> Last update: before 162.554 s
> Refresh timer : 737.445/900
> Retry timer : ---
> Expire timer : 172637.445/172800
> Channel roa4
> State: UP
> Table: roa_v4
> Preference: 100
> Input filter: ACCEPT
> Output filter: REJECT
> Routes: 96086 imported, 0 exported, 45547 preferred
> Route change stats: received rejected filtered ignored
>accepted
> Import updates: 96232 0 0 0
> 96232
> Import withdraws: 146 0 --- 0
> 146
> Export updates: 0 0 0 ---
> 0
> Export withdraws: 0 --- --- ---
> 0
> Channel roa6
> State: UP
> Table: roa_v6
> Preference: 100
> Input filter: ACCEPT
> Output filter: REJECT
> Routes: 16271 imported, 0 exported, 7669 preferred
> Route change stats: received rejected filtered ignored
>accepted
> Import updates: 16275 0 0 0
> 16275
> Import withdraws: 4 0 --- 0
> 4
> Export updates: 0 0 0 ---
> 0
> Export withdraws: 0 --- --- ---
> 0
>
> So here I see both instances with both address families, and the local
>bird instance is using both of them.
>
>On Tue, 22 Oct 2019 at 08:36, Maria Matějka <jan.matejka at nic.cz> wrote:
>
>> Hello!
>>
>> On October 22, 2019 5:51:56 AM GMT+02:00, Darren O'Connor <
>> mellow.drifter at gmail.com> wrote:
>> >I was reading the documentation for bird2 when I came across this:
>> >You can validate routes (RFC 6483) using function roa_check() in
>filter
>> >and
>> >set it as import filter at the BGP protocol. BIRD should re-validate
>> >all of
>> >affected routes after RPKI update by RFC 6811, but we don't support
>it
>> >yet!
>> >You can use a BIRD's client command reload in bgp_protocol_name for
>> >manual
>> >call of revalidation of all routes.
>> >
>> >Is there a rough timeline for when bird2 will correct re-validate
>> >affected
>> >routes? As I run multiple table, is the best thing to simply run a
>> >cronjob
>> >telling bird 'reload in all' a few times a day until that support is
>> >added?
>>
>> There is no exact time line as we found out that we want first to do
>> substantial changes in internal API between protocols and tables
>w.r.t.
>> multithreading and parallel execution plans.
>>
>> Anyway, the parallel execution thing is currently under development
>and we
>> suppose we'll get to automatic re-evaluation in several months. (To
>be
>> honest, I said the same thing last year so don't trust me.)
>>
>> One workaround you can do is to enable debug on the rpki protocol
>instance
>> and reload the affected channels on roa change detected by reading
>the log
>> file. This is somehow dirty, yet developing a consistent automatic
>route
>> reload also eats some time, sorry for the inconvenience.
>>
>> >The second item is this:
>> >We currently support just one cache server per protocol. However you
>> >can
>> >define more RPKI protocols generally.
>> >
>> >This doesn't seem true though, as I have two cache servers
>configured
>> >for
>> >both ipv4 and ipv6 and it seems to be fine?
>>
>> Do you mean two cache servers for one RPKI protocol instance? I'm not
>now
>> looking into the code, I may be wrong, I'd only suppose that the
>latter
>> server is used exclusively.
>>
>> Maria
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20191023/87df515d/attachment.htm>
More information about the Bird-users
mailing list