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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
