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
No, my proposal works as long as the customer advertizes their prefixes
via BGP, not matter how long the path or what community attributes are
set (for example NOEXPORT). No matter how they send it, as long as they
send it, it works fine. Unlike uRPF which depends on exactly this path
being the best path of all path available. All this trouble of routing
decisions which affect uRPF is avoided. That is also why it feeds the
received prefixes into an ACL which then is applied to the interface
versus doing two FIB lookups (one on source IP and one on destination
IP).
So, your proposal is loose-mode uRPF?
Andre Oppermann wrote:
No, my proposal works as long as the customer advertizes their prefixes
via BGP, not matter how long the path or what community attributes are
set (for example NOEXPORT). No matter how they send it, as long as they
send it, it works fine. Unlike uRPF which depends on exactly this path
being the best path of all path available. All this trouble of routing
decisions which affect uRPF is avoided. That is also why it feeds the
received prefixes into an ACL which then is applied to the interface
versus doing two FIB lookups (one on source IP and one on destination
IP).
And my proposal works as long as the customer advertises their prefixes via BGP, with the added caveat that ACLs don't have to be updated (i.e. uRPF works and is used). I'd have to re-check my customer-side route maps, but I think they'll open the uRPF for all possible permutations of <community>.
pt
Joe Abley wrote:
I guess it's been a while since I've played with it, but isn't this pretty
well what happens with uRPF anyhow?
No, my proposal works as long as the customer advertizes their prefixes
via BGP, not matter how long the path or what community attributes are
set (for example NOEXPORT). No matter how they send it, as long as they
send it, it works fine.
So, your proposal is loose-mode uRPF?
I thought that loose-mode uRPF is what was recommended for any connected entity that is multi-homed. And that makes sense.
What happened to that? Whats next? uRPF in core?
At which point do we stop breaking things?
There must be a safe way to solve the problem of spoofing routed space without breaking multi-homing.