Open nskalis opened 4 years ago
Hi
I think the fastest way if you want that prefix to be marked as "valid", create and use static ROA.
As I see you are using Juniper device which means you can create in this way: [edit routing-options]
[edit routing-options]
validation {
static {
record destination {
maximum-length prefix-length {
origin-autonomous-system as-number {
validation-state (invalid | valid);
}
}
}
}
And I think the static is more prefered, its worth a try.
thanks @Methionyl for looking into it, but if that prefix is learnt from many locations is not the most convenient method to do so. I am interested in finding out why white-listing in RIPE's RPKI Validator doesn't work (at least to my perception).
anyone? can you please advise on how to use RIPE's RPKI validator to whitelist a ROA? what is going wrong above?
Hi,
I have tried to reproduce the situation above. I followed your steps (start validator, add whitelist entry, it is then present in slurm.json). I can not reproduce the situation.
Could you:
http://localhost:9176/api/objecs/validated
in my example)?http://localhost:8081/cache
in my example). This should be valid.When I check the ROA export endpoint of the validator,
$ curl http://localhost:9176/api/objects/validated | grep 1.37.137 --after=2 --before=2
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 12.2M 0 12.2M 0 0 20.0M 0 --:--:-- --:--:-- --:--:-- 20.0M
}, {
"asn" : "4775",
"prefix" : "1.37.137.0/24",
"maxLength" : 24
} ],
I see that the whitelisted prefix is present. This is the endpoint that is fetched by rtr server. When I look at the RTR server, I see that:
$ curl http://localhost:8081/cache | jq '.'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 160 0 160 0 0 53333 0 --:--:-- --:--:-- --:--:-- 53333
{
"data": {
"ready": true,
"sessionId": -4139,
"serialNumber": 2,
"announcementsCount": 146911,
"deltas": [
{
"serialNumber": 1,
"announcementsCount": 8,
"withdrawalsCount": 1
}
]
}
}
Its cache is valid. When I connected rtr-client to that rtr server instance:
$ rtr_client -d --host localhost -p 8323
2020-07-07-095225: CONNECT localhost.8323
+
2020-07-07-095225: NEW SESSION ID 0
.
2020-07-07-095225: REFRESHED SESSION ID 0->61397
..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
2020-07-07-095229: SESSION 61397 NEW SERIAL 0->1
2020-07-07-095232: DUMP ROUTES: session_id=61397 serial=1 announce=146904/withdraw=0
.^C
select wait: ^C
I get the currently valid ROAs (over time, this is very good for keeping history) dumped into a file. When I grep in that that:
$ cat data/2020-07/2020-07-07-095229.routes.00061397.00000001.json | grep 1.37.137 --before=2 --after=2
},
{
"ip": "1.37.137.0/24",
"asn": 4775
},
I see the whitelisted prefix.
Hi,
If we consider as an example the following network RPKI invalid prefix
1.37.137.0/24
fromAS4775
.In the network
which agrees with the published ROAs
Now, taking advantage of the app's feature whitelisting
which updates
slurm.json
accordinglyIt has the following effect in the web app, now it is depicted as valid
But, almost 1h later the router still sees it as RPKI
invalid
Should I see the above entry in the logs on the
RTR
server ? (btw, it would help using grep onprefix=
by decoding the prefix value, in which format it is encoded?)Would you be so kind to advise how I can achieve making
1.37.137.0/24
fromAS4775
seem asvalid
orunknown
? (when I don't own, I don't work inAS4775
, but let's assume it is a customer of ours and temporarily I would like to whitelist that)