Arp problems after upgrade to 3.6

Arp problems after upgrade to 3.6

[Phil Oester]

Upgraded a box to 3.6.7 yesterday, and started noticing it becoming
unreachable occasionally.  Watching arp traffic, it appears it is
sometimes arping for the gateway using the wrong source IP in the requests. 
Sample trace from bond1:

11:10:13.489388 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:10:14.489372 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:10:15.489358 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:10:16.489517 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:10:16.489518 ARP, Request who-has 10.253.128.13 tell 10.253.128.14, length 28
11:10:16.490025 ARP, Reply 10.253.128.13 is-at 00:d0:04:b1:d4:00, length 46
11:11:43.618851 ARP, Request who-has 10.253.128.13 tell 10.253.128.14, length 28
11:11:43.619406 ARP, Reply 10.253.128.13 is-at 00:d0:04:b1:d4:00, length 46
11:15:05.792656 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:15:06.789369 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:15:07.789338 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28
11:15:08.789939 ARP, Request who-has 10.253.128.13 tell 10.253.128.6, length 28 

Seems to be getting bond0 and bond1 IPs confused here:

12: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether xx:xx:xx:xx:xx:20 brd ff:ff:ff:ff:ff:ff
    inet 10.253.128.6/30 brd 10.253.128.7 scope global bond0
17: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether xx:xx:xx:xx:xx:22 brd ff:ff:ff:ff:ff:ff
    inet 10.253.128.14/30 brd 10.253.128.15 scope global bond1 

This box is still up, so if there is any additional information I can provide
before rebooting it, please let me know.

Phil Oester