[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.
> In the "source preference" case I cited, that's neatly solved by having
> two default routes -- equal prefix length -- pointing at two different
> ISPs, each possibly doing RFC 3704 filtering on our source addresses.
> When we send packets (either generated locally or forwarded) to the
> Internet, we see the two default routes, equal prefix, and choose among
> them properly based on source address. Packets we send always end up on
> the right interface.
yes, I agree, this is the normal, expected use-case. And the behavior
for that case (multiple routes with same dst/mask) is undisputed.. the
"src-priority" solution would behave as above.
> If there are any more specific routes then either (a) the user knows
> what he's doing and points those routes where they go, (b) the user
> provides multiple such specific routes so that the source preference is
> obeyed, or (c) the user is clueless and gets what he asked for, but not
> what he wanted.
I agree.
> 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:
> 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).
--Sowmini
_______________________________________________
networking-discuss mailing list
[email protected]
