Yes your story how you found it is exactly as mine - with just one exception that I was looking at my upstream ISPs across two ASBRs and debugging what is going on :) But the core of the issue was precisely identical !
Well I am still running it .. just enabled ext comms. Frankly this was ugly as quite unexpected - but relatively easy to see what is going on. In this space I am much more worried about RPKI db accuracy then any of the implementation issues. I found number of cases so far where what is in RPKI is just plain wrong - read INVALID :). And that is supposed to be the source of truth ... Now I am considering actually automation of detection of RPKI bad info and some sort of publishing it. See when you sign a block then sell this block without removing your RPKI signature, then the block gets cutted into chunks and sold further - and no one in this process of transaction chain cares about RPKI - this entire story of using this for validation becomes pretty weak. And this is no longer NOT-FOUND. You get false INVALIDs which some may apply to suppress or drop. Best, R. On Fri, May 8, 2020 at 11:32 AM Mark Tinka <mark.ti...@seacom.mu> wrote: > > > 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. > > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/