[email protected] wrote: > [Note modified Cc list, truncated to avoid bounces back to myself] > >>> the intended purpose of the "src-priority" model is this: if there are >>> multiple routes for the same dst/prefix, we prefer the routes that give >>> a src-addr match first. If no such routes are available, instead of >>> dropping the packet, we pick a route as in the weak hostmodel case. >> That's how you've defined it to operate. >> >> It doesn't describe to me how it might be used. Can you give an example >> where it would work properly, but the "source preference" model I >> suggested would not work? > > How about this one: > > x.x.y.host2 > | > router > : | > : | > isp1 isp2 > | | > x.x.x.0/24 | > | | > host1 > > Let's say the ":" path is a longer path than the "|" path, but both > isp1 and isp2 are doing ingress filtering. If isp1 is advertising a > default route to host1, and isp2 is advertising x.x.y.0/24 to host1, > and host1 ends up sending a packet with src x.x.x.0/24, that packet > has a better chance of getting to x.x.y.host2 thorugh isp1 than isp2. > But I believe the "source preference" model you propose would pick isp2 > because it has the longer prefix match.
Under what circumstances does an ISP advertise a /24 to someone? Is that a realistic scenario? If it is, then it falls under one of the three exceptions I mentioned before: if there's a more specific route, then either the user knows what he's doing, or he has multiple such routes to take advantage of source preference, or he gets what he deserves. In other words, with your example, the user should have either two default routes (and no x.x.y.0/24 route), or should have two x.x.y.0/24 routes -- one pointing out through isp1 and the other through isp2 -- because it's reachable through both and you want source preference to kick in. In real life, a non-default route from an ISP means that you're peering with them, and are getting BGP. If you're participating in BGP with one of your upstream providers but not with another, then that's seems like a pretty unusual case to me. I'm not sure it's legit, nor does it make sense to me that we'd dispense with normal IP prefix matching in order to support a case like that. (For what it's worth, I used "x.x.y.0" to indicate another subnet within a single network delegated by a provider. Your example uses networks reachable only through providers, which means this probably should be y.y.y.0 instead. But that's just a nit ...) >> So locally-emitted packets are forwarded differently than those received >> from elsewhere? > > Depends on what you mean by "forwarded". Esp. post IP datapath refactoring, > the code behaves differently than the traditional BSD model, and src > checks are not applied to forwarded packets. But as you yourself point out: So source preferences can't be handled in the normal IP forwarding case? That makes this feature useless for multihomed systems that route for other subnets within the same organization, or that handle port redirection. If one ISP gives me x.x.x.0/24 as my playground, and another gives me y.y.y.0/24, I'd like to be able to assign addresses out of x.x.x.0 and y.y.y.0 to my local systems on shared networks, and have the packets flow outbound accordingly without getting confused. Linux "Advanced Routing" is able to do that. >> An RFC 3704 filter would naturally exist at some sort of network >> administrative boundary, when you (the filtering party) *know* that the >> guy on the other side shouldn't be doing any routing. He's a stub >> network to you, so you know his source addresses are constrained. > > and this feature isn't really intended for use by routers (routing > and strict-ES are at odds with each other, as you have frequently pointed > out). That's *EXACTLY* why I wanted a source preference feature in the first place. Strong ES stinks. It wrecks routing. Having a source-based preference among equal-prefix routes, though, is completely compatible with routing and solves the problem without resorting to brutish solutions like Strong ES. It sounds like we still have no fix for this problem. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ networking-discuss mailing list [email protected]
