Siddharth, Nitin, and David,
While working on the Clearview IPMP implementation, I've uncovered a few
landmines in the interaction between ARP and SDP/IBTF IP Addressing which
merits discussion:
1. Both ibcm_arp_pr_lookup() and sdp_pr_lookup() appear to assume
that the source IRE they lookup can be directly mapped to a
hardware address via ire_ipif->ipif_ill->ill_phys_addr. This
no longer holds with the new Clearview IPMP bits because
IRE_LOCALs will be associated with IPMP ills that do not have
directly associated hardware. However, each local address can
be mapped to an "underlying" IP interface which will be used
to send and receive traffic. Thus, I plan to update the code
to perform this mapping when the ire_ipif->ipif_ill turns out
to be an IPMP interface.
2. Both ibcm_arp_pr_lookup() and sdp_pr_lookup() call routines
to check whether ire_ipif->ipif_ill is a loopback or IB
interface. Unfortunately, they do this using bcmp() on the
interface name rather than actually testing properties of the
interface itself. This is not robust, and breaks completely if
an administrator uses Clearview Vanity Naming (available in
snv_83 and later), since any IP interface can be named to start
with "ibd" or "lo". It seems like the functions in question
should be checking the ill_flags and ill_media fields of the
ill_t to determine this information.
3. As currently written, the interface that's passed into the
"check" functions mentioned in (2) would end up being the IPMP
interface after Clearview IPMP, which will never be loopback or
IB. As such, the IP interface used to send and receive packets
(determined as per (1) above) would need to be passed instead.
4. I'm having a tough time understanding the source IRE logic for
sdp_pr_lookup() -- it seems to try to use the destination IRE
for source information. Could someone please explain this code?
Regarding points 1 through 3: I've made preliminary changes in my
Clearview IPMP workspace to address these issues. In particular, could
someone look over the ibcm_arp_link.c and sbd_link.c changes at:
http://zhadum.east/ws/clearview/clearview-ipmp/webrev
[ Note 1: internal webrev because sbd_link.c is closed source.
Note 2: no need to review anything other than those two files. ]
Could someone familiar with this code to look over the changes ASAP and
provide feedback? Finally, can someone offer advice on how to test these
changes -- ideally in an automated fashion?
Thanks!
--
meem