Job Snijders writes:
Dear Jay, AT&T,
On Mon, Feb 11, 2019 at 09:53:45AM -0500, Jay Borkenhagen wrote:
The AT&T/as7018 network is now dropping all RPKI-invalid route announcements that we receive from our peers.
Thanks for filtering us! :-)
Any time! :-)
If you can share more about the experience in terms of load on the support tiers in your organisation, or questions from peering partners, that could perhaps be helpful information for others in their preparations.
A few reports of resulting connectivity loss have come in through various channels: on Jared's outages mailing list, on IRC, through our customer care ticket system, etc. Thusfar I have been very pleased with the reactions folks have had when we described how our policy change caused us to lose their affected route announcement. Everyone so far has understood the purpose of the RPKI, they understood why the affected route announcements were deemed invalid and thus were dropped, and best of all -- they understood what they needed to do to fix things. We got some very good advice watching this video from your most recent NLNOG day: https://www.youtube.com/watch?v=vrzl__yGqLE ... but there is one place where I disagree with Niels. He advised against lowering the local-pref of invalid routes. I agree that this should not be anyone's target policy, but it is a useful step along the way. To set invalid routes a lower local-pref, one needs to establish RTR sessions from routers to relying party servers, and to configure a policy that takes validation state into account. The policy here can also set community based on the validation state, which can help with flow-based traffic analysis. Then, when you are comfortable operating RPs that talk RTR to your routers and you're ready to implement a meaningful policy, it's a simple matter of changing from: if validation-state = invalid then local-pref = $LOWER community = foo fi to: if validation-state = invalid then drop fi In short: C'mon in! The water's fine! :-) Thanks. Jay B.