On 10/Oct/19 16:13, Melchior Aelmans wrote:
>
>
> this is being worked on as we speak.
This is most appreciated!
Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
On Thu, Oct 10, 2019 at 2:41 PM Mark Tinka wrote:
> > These should be -according to RFC6907- considered as invalid,
> > not as unknown (what JunOS currently does).
>
> Agree that Junos is broken.
>
this is being worked on as we speak.
Cheers,
Melchior
___
On 10/Oct/19 12:28, Job Snijders wrote:
> The question that still seems to be open: how to we reject BGP
> announcements that contain an AS_SET anywhere in the AS_PATH?
Aside from building a filter, bank on Juniper to fix this as they said
they would earlier in this thread.
On the Cisco side,
On 10/Oct/19 12:25, Weber, Markus wrote:
> Still in to see if Cisco XR would not accept this.
Will check again once it has done the rounds.
>
> Sorry again for the non j-nsp noise, should shift this conversation away
> from here ... but I couldn't leave this wrong-with-first-shot code readin
On 10/Oct/19 11:29, Weber, Markus wrote:
> https://github.com/RIPE-NCC/rpki-validator-3 ...
Well, we are still on 2, as we found 3 to be just a hot mess.
> Interesting. 7018 mentioned for another prefix "2402:7500::/32.
> Our IOS-XR routers see the received as-path as '2914 9924 9924 9924
>
On 10/Oct/19 11:16, Weber, Markus wrote:
> Nothing [*].
You say that, but it would be interesting to learn why the validator
isn't seeing the Invalid path.
I'll take Job up on his observations and reach out to RIPE to understand
if they think this a bug.
> These should be -according to RFC6
Thanks Markus. Good sleuthing.
The question that still seems to be open: how to we reject BGP
announcements that contain an AS_SET anywhere in the AS_PATH?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/
> If I'm not mistaken, the RIPE validator uses
> http://www.ris.ripe.net/dumps/
> which lists for the two /24 test prefixes:
> {517} 194.45.182.0/24 242
> {517,12469} 194.45.183.0/24 241
> and seems to use - Asn.parse of net.ripe.ipresource.Asn - when loading
> this
Markus wrote:
|Mark wrote:
|> So the validator is not even showing either /24, only the /23.
|> Could it be implementing RFC 6907?
|https://github.com/RIPE-NCC/rpki-validator-3 ...
If I'm not mistaken, the RIPE validator uses
http://www.ris.ripe.net/dumps/
which lists for the two /24 te
Mark wrote:
> So the validator is not even showing either /24, only the /23.
> Could it be implementing RFC 6907?
https://github.com/RIPE-NCC/rpki-validator-3 ...
> All of my IOS XR routers do not have the /24's in RIB, even if
> marked as Invalid. So either IOS XR is implementing RFC 6907
> agg
Mark wrote:
> So what is the validator's role in this decision-making?
Nothing [*].
> My IOS XR boxes have accepted the route for installation.
It's not about 194.45.182.0/23. It's about 194.45.182.0/24
and 194.45.183.0/24.
These should be -according to RFC6907- considered as invalid,
not as u
On 10/Oct/19 10:25, Job Snijders wrote:
>
> The "BGP Preview" is only showing the /23, but the issue at hand is
> expressed in the two /24s covered by the /23.
So the validator is not even showing either /24, only the /23. Could it
be implementing RFC 6907?
All of my IOS XR routers do not hav
On Thu, Oct 10, 2019 at 10:19:42AM +0200, Mark Tinka wrote:
> On 10/Oct/19 09:58, Job Snijders wrote:
> > Can you show a screenshot? Not entirely sure what you are looking at.
>
> The list said my screenshot was too big.
>
> But I'm sure you got it.
Yup, I got it!
It appears there is a bug in t
On 10/Oct/19 09:58, Job Snijders wrote:
> Can you show a screenshot? Not entirely sure what you are looking at.
The list said my screenshot was too big.
But I'm sure you got it.
Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https:/
Can you show a screenshot? Not entirely sure what you are looking at.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
On 1/Oct/19 18:20, Weber, Markus wrote:
>
> RFC6907 (7.1.8-7.1.12 - considering RFC6472) clarifies this: If
> there's a covering ROA and the announcement contains an AS_SET,
> it should be considered invalid (no matter if there's a ROA for
> e.g. a member of the AS_SET (apparently IOS XR behav
> On Oct 2, 2019, at 12:37 AM, Weber, Markus wrote:
>
> Melchior Aelmans wrote:
>> All, please be assured that, thanks to all PRs, cases, etc, it’s on
>> our (Junipers) Radar and we are looking into it.
>
> Thanks, looking forward to see this showing up in the very near future/
> with the next
Melchior Aelmans wrote:
> All, please be assured that, thanks to all PRs, cases, etc, it’s on
> our (Junipers) Radar and we are looking into it.
Thanks, looking forward to see this showing up in the very near future/
with the next updates of all current in-use releases.
> Agreed on the usefulness
Job,
> Op 1 okt. 2019 om 23:12 heeft Job Snijders het volgende
> geschreven:
>
> I think we'll also all agree that no fallback to the old behavior is
> needed, as the old behavior is not useful.
Agreed on the usefulness part, but would there be unwanted situations or
behavior someone could ru
On Tue, Oct 01, 2019 at 10:50:29PM +0200, Melchior Aelmans wrote:
> All, please be assured that, thanks to all PRs, cases, etc, it’s on
> our (Junipers) Radar and we are looking into it.
I think we'll also all agree that no fallback to the old behavior is
needed, as the old behavior is not useful
All, please be assured that, thanks to all PRs, cases, etc, it’s on our
(Junipers) Radar and we are looking into it.
Cheers,
Melchior
> Op 1 okt. 2019 om 18:20 heeft Weber, Markus het
> volgende geschreven:
>
> Dear all,
>
> Juniper seems to implement by now just RFC6483 behaviour for ROV
Dear all,
Juniper seems to implement by now just RFC6483 behaviour for ROV
(that is, if there's an AS_SET in the path, the origin AS can't
be determined and as such validation result is always unknown).
Checked on 16.1R7-S5/17.3R3-S5/18.2R3-S1.
RFC6907 (7.1.8-7.1.12 - considering RFC6472) clarifi
22 matches
Mail list logo