[c-nsp] RPKI validation weirdness

[Mark Tinka]

On 8/May/20 11:23, Robert Raszuk wrote:

>
> But in what you pasted in I do not see statement that paths received
> over IBGP with no state information should be considered VALID. I
> think they just thought North - South then if you validate on ingress
> rest of the domain should assume the IBGP path received is VALID.

Yes, agreed on that. The e-mail I got from someone back in 2016 on that
issue was "this is designed as per normal".

The link I sent was specific to them documenting a mis-interpretation of
the RFC on policy application, despite being called out on it years ago.


> With that they apparently  never thought about iBGP also going
> East-West between ASBRs or via RRs where you are using add-paths or
> best external :)

We just disabled RPKI on our ASR1000 edge routers, especially since they
only handle about 2 customers across the entire backbone. Much of that
heavy-lifting is done by our MX480's, which implement ROV correctly.

One of the issues we hit that led us to this decision was when you learn
a non-ROA'd customer route via eBGP in one location, but that specific
edge router decides to send the traffic back to them via iBGP to another
site where they may have a second connection to you or via a peering
partner, because on the local edge router, Cisco automatically applies
NotFound for the route, but Valid for the iBGP-learned route. Since
Cisco will automatically apply policy by default the moment you enable
RPKI, the local eBGP route will never be chosen as the best path, even
though it is.

Utter madness!

Mark.