Re: FORT monitoring/visibility
On Tue, Oct 26, 2021 at 04:58:20PM -0700, Randy Bush wrote: > i run a FORT RPKI relying party instance. i am looking for some > visibility into its operation. > > is it up: both ways, fetching and serving routers? > > from what CAs has it pulled, how recently and frequently with > what success? > > what routers is it serving with rpki-rtr 323? > > blah blah blah > > my old DRL RP instances produce MRTG graphs etc of the CA > fetching side, though nothing on the rpki-rtr side. Have you taken a look at 'rtrmon' (RPKI-To-Router Monitor) https://github.com/bgp/stayrtr#monitoring-rtr-and-json-endpoints Kind regards, Job
Re: FORT monitoring/visibility
> On 20211027, at 09:26, Lukas Tribus wrote: > > On Wed, 27 Oct 2021 at 08:47, Mark Tinka wrote: >> >> On 10/27/21 01:58, Randy Bush wrote: >>> my old DRL RP instances produce MRTG graphs etc of the CA >>> fetching side, though nothing on the rpki-rtr side. >> >> Randy, I actually have an ongoing discussion with the Fort developers >> about this after a BGPSec bug left me with stale VRP's for several days, >> with no clear indication that Fort had "kind of" crashed and "not fully" >> crashed (fair point, I need to work on better internal monitoring of >> Fort, as well). > > That's the reason I preached about stale RTR servers before: > > https://labs.ripe.net/author/lukas_tribus/rpki-rov-about-stale-rtr-servers-and-how-to-monitor-them/ > https://github.com/lukastribus/rtrcheck > https://gist.github.com/lukastribus/695c9e780d118755271519d4d3cb54f3 > (the latter is a check against IOS XR devices via NETCONF which makes > some sanity checks, absolute and relative) Lukas, thanks for these, will align my own checks with the details you check for. Do tag your repo's with a "RPKI" tag and similar so that it is easier to find these kind of tools! Tooling is severely lacking in the RPKI space, in numbers and quality, thus any tool like this helps. Greets, Jeroen
Re: FORT monitoring/visibility
On Wed, 27 Oct 2021 at 08:47, Mark Tinka wrote: > > On 10/27/21 01:58, Randy Bush wrote: > > my old DRL RP instances produce MRTG graphs etc of the CA > > fetching side, though nothing on the rpki-rtr side. > > Randy, I actually have an ongoing discussion with the Fort developers > about this after a BGPSec bug left me with stale VRP's for several days, > with no clear indication that Fort had "kind of" crashed and "not fully" > crashed (fair point, I need to work on better internal monitoring of > Fort, as well). That's the reason I preached about stale RTR servers before: https://labs.ripe.net/author/lukas_tribus/rpki-rov-about-stale-rtr-servers-and-how-to-monitor-them/ https://github.com/lukastribus/rtrcheck https://gist.github.com/lukastribus/695c9e780d118755271519d4d3cb54f3 (the latter is a check against IOS XR devices via NETCONF which makes some sanity checks, absolute and relative) However judging by the absolute zero feedback and support requests from anyone (other than likes/thumbs up), I'm pretty sure no one actually does this - other than where I set it up directly. Fort is also working on a prometheus endpoint, which probably would allow easier monitoring/integration: https://github.com/NICMx/FORT-validator/issues/50 Lukas
Re: FORT monitoring/visibility
On 10/27/21 01:58, Randy Bush wrote: i run a FORT RPKI relying party instance. i am looking for some visibility into its operation. is it up: both ways, fetching and serving routers? from what CAs has it pulled, how recently and frequently with what success? what routers is it serving with rpki-rtr 323? blah blah blah my old DRL RP instances produce MRTG graphs etc of the CA fetching side, though nothing on the rpki-rtr side. Randy, I actually have an ongoing discussion with the Fort developers about this after a BGPSec bug left me with stale VRP's for several days, with no clear indication that Fort had "kind of" crashed and "not fully" crashed (fair point, I need to work on better internal monitoring of Fort, as well). Will feedback once I have better info. For now, if you haven't yet done so, recommend upgrading to 1.5.2 to avoid this specific issue. The good news is this issue made the case for running different validation RP code, so your NLRI does not share fate, given it's the basis of the Internet. Mark.
FORT monitoring/visibility
i run a FORT RPKI relying party instance. i am looking for some visibility into its operation. is it up: both ways, fetching and serving routers? from what CAs has it pulled, how recently and frequently with what success? what routers is it serving with rpki-rtr 323? blah blah blah my old DRL RP instances produce MRTG graphs etc of the CA fetching side, though nothing on the rpki-rtr side. randy --- https://seclists.org/nanog/2021/Jun/259 and ggm's excellent decoding thereof, https://blog.apnic.net/2021/07/15/some-handy-roa-advice-from-randy-bush/
