Stephen Griffin wrote:
Tell them they will need to register their routes in the IRR, even if they don't necessarily advertise all or any of them. Build your exceptions based upon the irr, as for all bgp-speaking customers.
not route-filtering. You use the irr-data to populate the exceptions to strict-mode rpf. The irr is more of a flight-plan of possibility. If the customer registers both sets of routes, and you use that data to build the acl, then it doesn't matter what the customer announces to you. Anything which fails the actual rpf check, will then be passed through the acl to selectively override the rpf check.
What about existing customers that don't yet use the IRR? Say you filter some BGP customers' route announcements using manually-built prefix-lists. Have found that by using distribute-list in (instead of prefix-list), one can simply refer the distribute-list # in the strict uRPF configuration and accomplish both functions (route filtering + uRPF) easily with one ACL. e.g.: ip verify unicast source reachable-via rx 49 access-list 49 permit x.x.x.x 0.0.0.255 access-list 49 permit y.y.y.y 0.0.0.252 access-list 49 deny any log Prefix-lists are preferable over ACL-based distribute-lists. Hey Cisco, please make uRPF configuration accept either distribute-lists or prefix-lists for the exception branching. I realize that to IOS ACLs and prefix-lists are not the same, but the benefits of prefix-lists vs. distribute-lists are many. It sounds that a lot of networks rely on IRRs for building BGP customer route filters. What method then is used for the cases where a customer is not already using the IRR? Forced IRR registration before BGP turnup? Or do you fallback on filtering by using prefix- or distribute-lists? What's NANOG's opinion: assuming that uRPF is implemented on all customer interfaces, are there any legitimate purposes for a customer to forward packets with source IP addresses not currently routed by the transit provider towards the customer (either static or BGP)?