Peter Memishian writes:
> 1. The bogus diagnostic message is due to a bug in Nevada,
> covered by 6781883. I've added this fix to my IPMP wad.
If this is one of our own messages, then we shouldn't get to
ip_ndp_conflict, because dl_mp should be NULL at this point. dl_mp is
non-NULL only when there's a DL_UNITDATA_IND available, which should
happen only with multicast packets arriving from the outside world.
At least that's how it *used* to work.
>
> (The above code is from Nevada; there's similar code in the
> Clearview IPMP gate.) Previously, this code sufficed to filter
> out the unsolicited neighbor advertisements because we always
> sent those advertiments over the same ill that's tied to the
> nce. With the fix for the multicast issue above, that's no
> longer true and thus we erronously think it's a duplicate. The
There are two issues here:
- The dl_mp pointer should be NULL if this was looped back
internally. If we have an internal loopback path that results in
a non-NULL dl_mp pointer, then that's new, and may require some
work.
- If it arrived from the outside world, then you've somehow run into
a case where either a switch is sending your own transmitted
packets back to you, or you're transmitting on the ill that isn't
the one "nominated" to receive broadcast/multicast.
If it's the former, then the existing check should still catch it.
If it's the latter, and you can't somehow avoid "accidentally"
sending on the wrong interface, then I agree with the change for
nce_cmp_ll_addr -- you need to check all of the interfaces.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
