Ketan wrote:
> Ok James one last time i will try to describe the problem..
You're still describing it in terms of traceroute, and in terms of a
"problem," but traceroute itself isn't a terribly useful application,
and your output shows no evidence of a failure or bug of any sort.
Can you show me an actual application problem?
> nxge2:1: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 1500
> index 4
> inet 10.63.20.30 netmask fffffe00 broadcast 10.63.21.255
> nxge2:2: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 1500
> index 4
> inet 10.63.20.29 netmask fffffe00 broadcast 10.63.21.255
This shows that the system has two IP addresses on subnet 10.63.20.0/23
through the same interface.
> it uses nxge2:1 interface instead of nxge2:2 and if disable the IPMP on
> nexge2 it works fine as expected
The choice of the source address nxge2:1 or nxge2:2 is *arbitrary*.
You've told the system that the two addresses are equivalent, and thus
the system will use them in an undocumented and not necessarily
predictable way.
The way source address selection works is that the system first looks up
the destination address in the kernel forwarding ("routing") table. The
best matching (longest prefix) route is found. This route then points
to an interface and/or next hop address. That determines the output
physical interface (nxge2 in this case). The system then iterates
through the logical interfaces (source addresses) configured on that
interface, and picks one according to a set of priority rules -- on the
same subnet, in the same zone, marked "UP," not marked "DEPRECATED," and
so on. The "order" of the interface in the ifconfig output and the
logical interface index (the ":1" or ":2" number) simply play no
documented part in that process.
If you want to control which address is used, you have to exert that
control yourself. You can do so at the application level by using the
bind() call, or at the system management level by setting the
"deprecated" flag.
If you don't do either of those, then the system will just pick one and
use it. If you try unplumbing and replumbing those interfaces, I'll bet
you find scenarios where the results are reversed.
Moreover, with IPMP enabled, the system will actually attempt to use
*all* of those equivalent addresses. Try tracerouting to multiple
different remote systems with IPMP turned on, and you should see the
system choosing first one address as the source, and then the other.
This is intentional: it's how the system provides inbound load
spreading. It's a feature, not a bug.
> # traceroute 10.63.20.29
> traceroute: Warning: Multiple interfaces found; using 10.63.20.29 @ nxge2:2
> traceroute to 10.63.20.29 (10.63.20.29), 30 hops max, 40 byte packets
> 1 10.63.20.29 (10.63.20.29) 0.120 ms 0.034 ms 0.030 ms
>
> Now my question is why the traceroute uses interface nxge2:2 when IPMP group
> is disabled and goes from nxge2:1 when IPMP is enabled though i 'm tracing
> only same ip in both tries. ?
The results are arbitrary, because that's what you've told the system
you want.
The subtle difference between IPMP and non-IPMP mode is that a different
function is used to select an available source address in the two cases.
But the difference is quite subtle, and not so predictable as your
report seems to indicate.
If that sort of arbitrary selection is not what you want, then you must
configure the system differently.
--
James Carlson 42.703N 71.076W <[email protected]>
_______________________________________________
networking-discuss mailing list
[email protected]
