I guess it's been a while since I've played with it, but isn't this pretty well what happens with uRPF anyhow? The asymmetric routing problem is illustrated ascii stylee below. AS1 / ASYOU - AS-OTHERGUY \ / CUSTOMER Say somebody in AS1 wants traffic from your customer. The request comes in through you, and to your customer. For whatever reason (internet exchange peering is more attractive to the customer, whatever - the point is, ignore the AS-path, because the customer has fiddled with their traffic - ie: always follow the money) their return traffic is going via AS-OTHERGUY. Their shortest path to AS1 is through you, so they throw the return traffic your way. Of course, your routing table resolves the best path for all customer routes to AS-CUSTOMER, so it drops all traffic coming in from AS-OTHERGUY. I don't think your solution would fix that, as AS-OTHERGUY's announcements would have a longer AS-path than your direct peering with the customer. (I reserve the right to be totally wrong and have completely misunderstood all mechanisms involved, btw ;) ) Internet nanog-list@nrg4u.com - 03/06/2005 14:58 To: Christian MACNEVIN cc: christopher.morrow, will, nanog Subject: Re: URPF on small BGP-enabled customers? christian.macnevin@uk.bnpparibas.com wrote:
At an old transit provider I was at, we had a pig of a time dealing with uRPF. It doesn't like asymmetric routing at all, which is commonplace when you've got customers homed at exchange points for one.
This is why I say there should be a feature that will work like a dynamic ACL but is fed from BGP. All the prefixes you learn from customer A via BGP are put into an automatic ACL, default is deny. Then you apply this dynamic ACL to the interface the customer is connected to. Of course it still doesn't work if you send traffic from prefixes you don't announce but for 70-80% of the cases it's a big step forward in automation. This also gets rid of any differences between ACL on the forwarding plane and on the routing protocol plane. All prefix filters are defined in BGP configuration. Forwarding layer follows and never gets out of sync again. Random example syntax: router bgp 65500 neighbor 192.168.2.2 remote-as 65501 neighbor 192.168.2.2 dynamic ACL 10001 receive #put received prefixes here neighbor 192.168.2.2 prefix-list CUST65501 ... #usual stuff #only this one is controlled ip prefix-list extended CUST65501 permit ip 172.16.0.0/16 any permit ip 10.0.0.0/8 any #ACL on interface follows BGP received prefixes interface f0/0/0 ip access-group 10001 in #same as in BGP neighbor config And Voila! Problem automagically solved. -- Andre This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. ********************************************************************************************** BNP Paribas Private Bank London Branch is authorised by CECEI & AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Securities Services London Branch is authorised by CECEI & AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Fund Services UK Limited is authorised and regulated by the Financial Services Authority.