<WARN> xxxx.ipv4: Automatic RPKI reload not active for import
Hi The warning log is outputting something like “<WARN> xxxx.ipv4: Automatic RPKI reload not active for import”. I am using roa_check() and rpki_reload switch is set to default (on). The help page on “rpki reload switch” says that the BGP channel requires import table for automatic reload, so I am aware that if I add the definition of “import table on”, this warning will no longer appear. However, in the help section on “import table switch Note that currently the import table breaks routes with recursive nexthops (e.g. ones from IBGP, see gateway recursive (p. 47)), they are not properly updated after next hop change. and we have not been able to fully determine the contents of this message. Is there any way around this warning other than “import table switch”?
Hello! On Fri, Sep 06, 2024 at 10:18:34PM +0900, ushiroz@ate-mahoroba.jp wrote:
The warning log is outputting something like “<WARN> xxxx.ipv4: Automatic RPKI reload not active for import”.
I am using roa_check() and rpki_reload switch is set to default (on).
The help page on “rpki reload switch” says that the BGP channel requires import table for automatic reload, so I am aware that if I add the definition of “import table on”, this warning will no longer appear.
However, in the help section on “import table switch Note that currently the import table breaks routes with recursive nexthops (e.g. ones from IBGP, see gateway recursive (p. 47)), they are not properly updated after next hop change. and we have not been able to fully determine the contents of this message.
This applies to the import table contents where the recursive nexthops don't get updated properly. The main table contents is not affected. Therefore you can use import table, the only problem will be that if you show routes from the import table, you should disregard what is shown as the local nexthop.
Is there any way around this warning other than “import table switch”?
You can switch off rpki autoreload but this is not recommended at all. It's better to enable the import table. Happy routing! Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
Thanks Maria for the response. The logs “Cannot reconfigure channel xxxx .ipv4” and “Cannot reconfigure channel xxxx .ipv6” that are output when the import table on <-> import table off setting is changed and the logs ” Restarting protocol xxxx” logs, but does it mean that when the import table setting is changed, a restart is performed? On Fri, 6 Sep 2024 23:40:39 +0200 Maria Matejka <maria.matejka@nic.cz> wrote:
Hello!
On Fri, Sep 06, 2024 at 10:18:34PM +0900, ushiroz@ate-mahoroba.jp wrote:
The warning log is outputting something like “<WARN> xxxx.ipv4: Automatic RPKI reload not active for import”.
I am using roa_check() and rpki_reload switch is set to default (on).
The help page on “rpki reload switch” says that the BGP channel requires import table for automatic reload, so I am aware that if I add the definition of “import table on”, this warning will no longer appear.
However, in the help section on “import table switch Note that currently the import table breaks routes with recursive nexthops (e.g. ones from IBGP, see gateway recursive (p. 47)), they are not properly updated after next hop change. and we have not been able to fully determine the contents of this message.
This applies to the import table contents where the recursive nexthops don't get updated properly. The main table contents is not affected.
Therefore you can use import table, the only problem will be that if you show routes from the import table, you should disregard what is shown as the local nexthop.
Is there any way around this warning other than “import table switch”?
You can switch off rpki autoreload but this is not recommended at all. It's better to enable the import table.
Happy routing!
Maria
-- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
Therefore you can use import table, the only problem will be that if you show routes from the import table, you should disregard what is shown as the local nexthop.
The logs “Cannot reconfigure channel xxxx .ipv4” and “Cannot reconfigure channel xxxx .ipv6” that are output when the import table on <-> import table off setting is changed and the logs ” Restarting protocol xxxx” logs, but does it mean that when the import table setting is changed, a restart is performed?
Yes. You have to fill the table with something, and although it could be technically possible to refill it just by requesting route refresh, it seems that nobody actually implemented this fast track, so it's resolved by restarting the peer. It should not be too difficult to implement, yet with the BIRD 3 upcoming (where the import table is implemented differently) this may get a little bit trickier. If there is anybody willing to do it, just let us know please to get some hints and directions. Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
Thank you, as always, for your quick answers! Currently using RPKI functionality and calls roa_check(). Allowing the output of warning messages and RPKI reload is ON and import table on is not defined. I am thinking of doing this. Is this a problem? On Mon, 9 Sep 2024 09:55:04 +0200 Maria Matejka <maria.matejka@nic.cz> wrote:
Therefore you can use import table, the only problem will be that if you show routes from the import table, you should disregard what is shown as the local nexthop.
The logs “Cannot reconfigure channel xxxx .ipv4” and “Cannot reconfigure channel xxxx .ipv6” that are output when the import table on <-> import table off setting is changed and the logs ” Restarting protocol xxxx” logs, but does it mean that when the import table setting is changed, a restart is performed?
Yes. You have to fill the table with something, and although it could be technically possible to refill it just by requesting route refresh, it seems that nobody actually implemented this fast track, so it's resolved by restarting the peer.
It should not be too difficult to implement, yet with the BIRD 3 upcoming (where the import table is implemented differently) this may get a little bit trickier. If there is anybody willing to do it, just let us know please to get some hints and directions.
Maria
-- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
On Wed, Sep 11, 2024 at 11:07:52AM +0900, ushiroz@ate-mahoroba.jp wrote:
Thank you, as always, for your quick answers!
Currently using RPKI functionality and calls roa_check().
Allowing the output of warning messages and
RPKI reload is ON and import table on is not defined.
I am thinking of doing this. Is this a problem?
You simply won't get the autoreload as the warning says. To get the autoreload for BGP, you need import table on. Thus, if ROA changes, it's your responsibility to manually request route refresh from possibly all your peers. Maria -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
participants (2)
-
Maria Matejka -
ushiroz＠ate-mahoroba.jp