OpenSolaris

Printable Version Enter a New Search
Bug ID 6533097
Synopsis UDP adds flimsy cache entries and compromises network performance
State 10-Fix Delivered (Fix available in build)
Category:Subcategory kernel:tcp-ip
Keywords rtiq_reviewed
Responsible Engineer Jonathan Anderson
Reported Against solaris_10u3
Duplicate Of
Introduced In solaris_2.0
Commit to Fix snv_78
Fixed In snv_78
Release Fixed solaris_nevada(snv_78)
Related Bugs 4416636 , 4978063 , 6507765 , 6620964 , 6624164 , 4157198
Submit Date 9-March-2007
Last Update Date 21-November-2007
Description 
Note: also seeing this on Sun4v.  Seeing this on multiple networks around the world.
We have servers that are not maintaining arp entries for the default, and/or set times.  They are also arp'ing excessively, even when answered, for an address.  Changing the arp_cleanup_interval manually has not helped.  A static entry in the arp table resolves the issue.  We are seeing this between S10 machines, some running 3/05, some 11/06.  We are running kernel -24 and -33, respectively.  Snoop data has been examined, and the packets seem to contain valid information, and are being sent and received.

Notice:
$ while true
> do
> arp -a | grep -i mf-ubrm-01
> echo "here"
> sleep 2
> done

here
ce0    mf-ubrm-01           255.255.255.255       00:03:ba:f7:21:8d
here
ce0    mf-ubrm-01           255.255.255.255       00:03:ba:f7:21:8d
here
here
here
here
here
here
ce0    mf-ubrm-01           255.255.255.255 U
here 
here
here

Also notice the snoop data (captured in < 1 second) :

sr1-ubrm-26 -> (broadcast)  ARP C Who is 129.147.9.5, mf-ubrm-01 ?
  mf-ubrm-01 -> sr1-ubrm-26  ARP R 129.147.9.5, mf-ubrm-01 is 0:3:ba:f7:21:8d
 sr1-ubrm-26 -> (broadcast)  ARP C Who is 129.147.9.5, mf-ubrm-01 ?
  mf-ubrm-01 -> sr1-ubrm-26  ARP R 129.147.9.5, mf-ubrm-01 is 0:3:ba:f7:21:8d
 sr1-ubrm-26 -> (broadcast)  ARP C Who is 129.147.9.5, mf-ubrm-01 ?
  mf-ubrm-01 -> sr1-ubrm-26  ARP R 129.147.9.5, mf-ubrm-01 is 0:3:ba:f7:21:8d
 sr1-ubrm-26 -> (broadcast)  ARP C Who is 129.147.9.5, mf-ubrm-01 ?
  mf-ubrm-01 -> sr1-ubrm-26  ARP R 129.147.9.5, mf-ubrm-01 is 0:3:ba:f7:21:8d
 sr1-ubrm-26 -> (broadcast)  ARP C Who is 129.147.9.5, mf-ubrm-01 ?
  mf-ubrm-01 -> sr1-ubrm-26  ARP R 129.147.9.5, mf-ubrm-01 is 0:3:ba:f7:21:8d
 sr1-ubrm-16 -> (broadcast)  ARP C Who is 129.147.9.253, 129.147.9.253 ?
 sr1-ubrm-26 -> (broadcast)  ARP C Who is 129.147.9.5, mf-ubrm-01 ?
  mf-ubrm-01 -> sr1-ubrm-26  ARP R 129.147.9.5, mf-ubrm-01 is 0:3:ba:f7:21:8d
 sr1-ubrm-26 -> (broadcast)  ARP C Who is 129.147.9.5, mf-ubrm-01 ?
  mf-ubrm-01 -> sr1-ubrm-26  ARP R 129.147.9.5, mf-ubrm-01 is 0:3:ba:f7:21:8d
 sr1-ubrm-26 -> (broadcast)  ARP C Who is 129.147.9.5, mf-ubrm-01 ?
  mf-ubrm-01 -> sr1-ubrm-26  ARP R 129.147.9.5, mf-ubrm-01 is 0:3:ba:f7:21:8d
 sr1-ubrm-26 -> (broadcast)  ARP C Who is 129.147.9.5, mf-ubrm-01 ?
  mf-ubrm-01 -> sr1-ubrm-26  ARP R 129.147.9.5, mf-ubrm-01 is 0:3:ba:f7:21:8d
 sr1-ubrm-26 -> (broadcast)  ARP C Who is 129.147.9.5, mf-ubrm-01 ?
  mf-ubrm-01 -> sr1-ubrm-26  ARP R 129.147.9.5, mf-ubrm-01 is 0:3:ba:f7:21:8d
 sr1-ubrm-26 -> (broadcast)  ARP C Who is 129.147.9.5, mf-ubrm-01 ?
  mf-ubrm-01 -> sr1-ubrm-26  ARP R 129.147.9.5, mf-ubrm-01 is 0:3:ba:f7:21:8d
Work Around 
Due to 6620694, the max hash chain length for the IRE cache buckets isn't being set
correctly (hence tuning the max values has no effect). Tune:

ip[6]_ire_min_bucket_cnt

in /etc/system. These currently default to 3. I would suggest setting them to the
current max values (10).
Comments 
N/A