URPF on small BGP-enabled customers?

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.

I imagine the simplest and most foolproof way around directly connected
providers blackholing your traffic is announcing more specific prefixes
down the one you're currently favourint, and just the aggregates for same
into the second. Good luck if you've only got a bunch of non-contiguous

christopher.morrow@mci.com@merit.edu - 03/06/2005 14:21

Sent by: owner-nanog@merit.edu

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 remote-as 65501
    neighbor dynamic ACL 10001 receive #put received prefixes here
    neighbor prefix-list CUST65501
    ... #usual stuff

  #only this one is controlled
  ip prefix-list extended CUST65501
    permit ip any
    permit ip 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.

<disclaimer> Not uRPG guru </disclaimer>

Why would that work? If I see a /16 from my customer and a /19 from a peer, I will still pick the /19, and strict uRPF should drop any packets from that /19 coming the customer interface, right?

Not to mention the Really Bad Things associated with deaggregation.

Perhaps a simpler way is to announce your entire allocation and put no-export on things you want to come in your other provider? ^1239$ will still pick those routes, but no one else will see them. Although sprint is a _VERY_ large network when you include downstreams, their own AS is rather tiny compared to the whole Internet.

or perhaps 'no-advertise' and send the same length prefixes everywhere...
this IS headed down the 1000 ways to config bgp though :frowning:

It is.

Although, after reading the thread (here & on c-nsp) and thinking about it, I have a hypothesis:

Sprint configures inbound source IP filters based on BGP filters. This could be automated easily. (BGP Tech: "What prefixes are you going to announce to us?" type-type-type.... System pushes prefix and IP ACLs.) Sound reasonable? Anyone from Sprint care to confirm?

So even if you do not plan to announce all prefixes to Sprint, give them all prefixes so you can announce them, and the IP ACLs will be built properly.