On 07/13/2018 10:25 AM, Christopher Morrow wrote:
you get the option at input (from transit/peering edge say) to evaluate
the 'rpki status' of a particular route, then set normal bgp attributes
based on that evaluation, so yes you can:
valid == localopref 1000 && community-A
unknown == localpref 80 && community-B
invalid == localpref 1 && community-Z
ACK
but given:
192.168.0.0/16 - valid
192.168.0.0/17 - unknown
192.168.0.0/24 - invalid
your routing system will still forward toward the 192.168.0.0/24 prefix
because 'longest prefix match'.
*facePALM* Thank you.So the information would be carried across the network, but it still suffers from the same problem.
Job's plan, I think, is that you reject/drop/do-not-accept the 'invalid' prefix(es) and hope that you follow another / proper path.
Yep.You would almost need separate logical networks / VRF to be able to prevent the longest prefix match winning issue that you reminded me of.
Perhaps Mark could send along ONLY the valid/unknown routes to his customer, or some mix of the set based on what type of customer:super-sekure-customer - valid only sorta-sekure-customer - valid/unknown wild-wild-west-customer - all
Yep. That's what I was thinking of.
it sounded like Mark didn't want to deal with that complexity in his network, until more deployment and more requests from customers like;
Fair.
Customer: "Hey, why did my traffic get hijacked to paY(omlut)pal.com yesterday?"Mark: "because you didn't ask for 'super-sekure-customer config? sorry?" I could have misunderstood either mark or job or you.. of course.
You understood me correctly. Thank you for explaining what I was missing. -- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
