sowmini.varad...@oracle.com wrote:
> On (04/12/10 16:47), James Carlson wrote:
>> Sebastien Roy wrote:
>>> This case proposes a new "hostmodel" property for the IP module that
>>> can have 3 settings: strong, weak and src-priority. Some sample
>>> incantations for setting the tunable are provided in the Examples
>>> section.
>> It looks like there's a fourth (reportable, not settable) value
>> documented in the man page changes: "custom".
>
> Yes, I believe that was flagged in the man page updates (no?). In case
> it was missed in the fast-track, here's what was intended:
That's all that was missed. In the quoted text above, it says "3"
settings, but there are actually 4. It's just a nit on the fast-track
materials.
> However, in src-priority mode, the definition of "best" match is modified
> thus:
> - first look up the longest match that also satisifes the
> source-address/interface constraint (i.e., routing table lookup as in
> the strong ES mode).
> - if that fails, then remove the source-address/interface constraint
> and find the longest match for the dst.
I might be straying outside of ARC review (and feel free to redirect
this to networking-discuss), but that doesn't sound quite right to me.
Consider this network:
+--------+ +--------+
| | | |
<---A--->+ Host 1 +<---B--->+ Host 2 |
| | | |
+--------+ +--------+
Network A is x.x.x.0/24, and connects to "the Internet." Network B is
an internal network, say x.x.y.0/24.
This means that Host 1 will have a default route pointing somewhere on
network A, and an interface route pointing to x.x.y.0/24 for network B.
Host 2 will have a default route pointing to Host 1's address on network B.
What happens if Host 2 sends a packet to Host 1's address on network A,
and then Host 1 goes to respond? It sounds like you're saying that
we'll discover the default route _before_ the interface route, and we'll
see that the interface address matches and thus send the packet
(erroneously) out on interface A.
This will cause forwarding loops with normal routing protocols.
Does the definition of "src-priority" mode mean that I can't get "source
preference" behavior with the existing variables? It's "source
preference" (i.e., if there are multiple matching routes that are
exactly equivalent -- same prefix length -- then choose the one with an
interface with the same source, and if no such interface, then choose
one with the same subnet configured as the source, and if no such, then
pick any) that I was hoping for, not "source first."
For what it's worth, I think it's "source preference" that fixes the
dual-homed problem.
>> If there's only one best
>> route, then we pick that without regard to source address.
>> In other words, if hme0 has only a default route, and hme1 has a
>> specific subnet route, we'll send out hme1 when we match the specific
>> subnet route destination, even if the source address is hme0's. Correct?
>
> no, in the example above, the first lookup would find hme0 because it
> is the longest match that also satisfies the interface constraint.
>
> And the documentation should make sure to clarify this with an example..
Indeed. It doesn't sound like a generally usable mode to me.
>> If this is the case, then why not just make src-priority the default?
>> It doesn't seem to have any effect on correctness from a routing point
>> of view, and potentially affects only load-spreading in some narrow
>> cases when not using vni interfaces.
>
> Well, in addition to the load-spreading problem, the longest match
> may be rejected in preference for a src-match, so we've not made
> it the default, in the interest of being cautious.
Rejecting longest match means that it just doesn't work with IP routing.
--
James Carlson 42.703N 71.076W <carls...@workingcode.com>
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
