Link Aggregation, 10.4.8 Server, D-Link problems.

Ok a bit of an update. With both server and switch configured I can connect to the server and the server can connect to the local sub-net only via ip address. So I can ssh or http to an ip not a FQDN. The reason is the server can't connect to the DNS or ping the address for the DNS. I have tested en1 with a solo static ip to the switch and it runs fine. Once again after teaming stuff like SA & WGM take a long time to connect and en1 has very little traffic. Managed clients can log in and afp works to the server. If I unplug en1 everything goes back to normal without changing any of the config, so Link Aggregation is set in both switch and server. Just when i connect en1 stuff begins not to work right and traffic to en1 is minimal. I have a extra partition on the startup volume and I'm gonna install the 10.4.7 client to see if I can get Link Aggregation working. 10.4.8 client displays the same problem as server so far.

10.4.7 seem to have the same problem. When I set it up and left the DHCP in place and no DNS or domain in the tcp/ip it was ... working but was a bit slow on responses. Most likely due to the DNS calls going to the DHCP server first. I did some more ping tests in 10.4.7 client and found I could ping a lot of address in the local sub-net but not all. Even with the DHCP address I could not ping my DNS. The first note in the ping test was "No route to host". In netstat it show an entry for the DNS w/MAC address being correct. Some Pings would work instantly other not right away or on the first try and some not at all. I can't figure any pattern to it yet. Once again if I unplug en1 everything works perfect. Even with en1 plugged in I see very little packet traffic to it.

One setting on the switch that I'm not sure about. Link Aggregation Algorithm? The default in the switch is MAC-source anyone know if this needs to be different or what setting on a working Link Aggregation 10.4.8 setup has? Other options are MAC-destination, MAC-source-dest, IP-source, IP-destination, and IP-source-dest.

Someone made a post that made me look at the netstat. It was suggested that that not only do the IP's on en0 & en1 need to be the same but also the MAC addresses. On my Mac Pro en0 & en1 retain different MAC address. Here's the read out.
<pre>osxserver:~ root# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lo0 16384 <Link#1> 301253 0 301252 0 0
lo0 16384 localhost ::1 301253 - 301252 - -
lo0 16384 localhost fe80::1 301253 - 301252 - -
lo0 16384 127 localhost 301253 - 301252 - -
gif0* 1280 <Link#2> 0 0 0 0 0
stf0* 1280 <Link#3> 0 0 0 0 0
en0 1500 <Link#4> 00:17:f2:00:10:12 3117722 0 3747823 0 0
en1 1500 <Link#5> 00:17:f2:00:10:13 0 0 0 0 0
fw0* 494 <Link#6> 00:16:cb:ff:fe:6b:7b:5a 0 0 0 0 0
bond0 1500 <Link#7> 00:17:f2:00:10:12 3107388 0 3709075 0 0
bond0 1500 osxserver.l fe80::217:f2ff:fe 3107388 - 3709075 - -
bond0 1500 192.168.1 osxserver.qchro 3107388 - 3709075 - -
osxserver:~ root# netstat -r
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default routerlan.qchron.n UGSc 45 11340 bond0
127 localhost UCS 0 0 lo0
localhost localhost UH 32 296823 lo0
169.254 link#7 UCS 0 0 bond0
192.168.1 link#7 UCS 17 0 bond0
ns2.mycompany.com 0.50.e4.9e.ef.29 UHLW 0 2977 bond0 1034
osxserver.mycompany.c localhost UHS 1 1776 lo0
rays.mycompany.com 0.3.93.a4.c2.e6 UHLW 1 7541 bond0 762
markw.mycompany.com 0.7.e9.db.eb.62 UHLW 0 7314 bond0 723
edit120.mycompany.com 0.d.93.62.c5.18 UHLW 2 25439 bond0 994
edit121.mycompany.com 0.14.51.0.92.36 UHLW 1 55664 bond0 304
edit122.mycompany.com 0.d.93.62.5e.f8 UHLW 5 19449 bond0 1044
edit123.mycompany.com 0.30.65.b8.5a.14 UHLW 1 164064 bond0 1200
edit125.mycompany.com 0.d.93.64.a2.c2 UHLW 3 8418 bond0 4
edit126.mycompany.com 0.11.24.7e.a2.9c UHLW 4 16093 bond0 1124
edit127.mycompany.com 0.d.93.61.6.38 UHLW 6 238746 bond0 854
art135.mycompany.com 0.a.95.be.2f.88 UHLW 3 382196 bond0 730
art136.mycompany.com 0.a.95.ae.96.10 UHLW 4 139562 bond0 672
art137.mycompany.com 0.a.95.ae.94.a UHLW 3 328845 bond0 866
art138.mycompany.com 0.a.95.ba.f4.4a UHLW 0 30 bond0 624
mikespowerbook.qch 0.3.93.a4.7a.1c UHLW 2 5320 bond0 506
192.168.1.223 0.a.95.bb.c.78 UHLW 0 142 bond0 546
routerlan.mycompany.c 0.d.bd.a1.89.98 UHLW 46 605 bond0 928

Internet6:
Destination Gateway Flags Netif Expire
localhost localhost UH lo0
localhost Uc lo0
localhost link#1 UHL lo0
link#7 UC bond0
osxserver.local 0.17.f2.0.10.12 UHL lo0
ff01:: localhost U lo0
ff02::%lo0 localhost UC lo0
ff02::%bond0 link#7 UC bond0
</pre>

Found some more info and i bolded some points which may mean Link Aggregation will not work on Intel Mac Pro.
http://www.hmug.org/man/8/ifconfig.php

ifconfig interface bonddev iface
bonddev iface
If the interface is a bond pseudo device, associate physical
interface iface with it. The bond pseudo device conforms to the
IEEE 802.3ad Link Aggregation specification.

If this is the first physical interface to be associated with the
bond interface, the bond interface inherits the ethernet address
from the physical interface. Physical interfaces that are added
to the bond have their ethernet address re-programmed so that all
members of the bond have the same ethernet address. If the phys-
ical interface is subsequently removed from the bond using
-bonddev, a new ethernet address is chosen from the remaining
interfaces, and all interfaces are re-programmed again with the
new ethernet address. If no remaining interfaces exist, the bond
interface's ethernet address is cleared.

If the specified physical interface iface is not capable of hav-
ing its ethernet address re-programmed, the bonddev command will
fail.

Once the physical interface iface is successfully associated with
the bond interface, all received packets are diverted to the bond
interface. The physical interface is no longer useable on its
own, and remains that way until it is removed from the bond using
-bonddev.

It is possible that the specified interface iface is not capable
of aggregating, and may remain unused until the operating condi-
tions change.

The link status of the bond interface depends on the state of
link aggregation. If no active partner is detected, the link
status will remain inactive.

To monitor the 802.3ad Link Aggregation state, use the -b option.

A physical interface that is associated with a vlan pseudo device
cannot at the same time be associated with a bond pseudo device.
A physical interface cannot be associated with more than one bond
pseudo device at the same time.

It is not possible to associate a bond with pseudo interfaces
such as vlan. Only physical ethernet interfaces may be associ-
ated with a bond.

Well according to sudo networksetup -isBondSupported device the Mac Pro devices are supported.
I tried to do the setup with ifconfig but it won't stay after a reboot. When i use the CLI networksetup it will stay but still not working right.
As far as the d-link goes it appears to work well. I tried a many different configs and I found one where at least I get full "ping" ability to the sub-net. The algorythem is set to MAC-destination or IP-destination. With the Dlink I get the proper responces from the Mac Pro like if the Group is not set up the Mac says no partner and so on. It is a traffic issue to en1. en0 works fine in both ports on the switch when used solo with Link Aggregation setup. en1 will no work at all solo.
Can someone with Link Aggregation on any working XServer Intel or PPC post the results on the following commands. assume your bond is bond0.
1. sudo ifconfig -b bond0
2. sudo networksetup -listBonds
3. netstat -r

maybe also a ifconfig -a might be needed but i just need to study the results on a working system.

Thank You so much steve because you have confirmed my problem. It is the MAC address setup on the Mac Pro via network setup. Here is my ifconfig.

<pre>
osxserver:~ root# ifconfig -b bond0
bond0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::217:f2ff:fe00:1012%bond0 prefixlen 64 scopeid 0x7
inet 192.30.40.2 netmask 0xffffff00 broadcast 192.30.40.255
ether 00:17:f2:00:10:12
media: autoselect (1000baseT <full-duplex,flow-control>) status: active
supported media: autoselect
bond key: 0x0001 interfaces: en0 (selected) en1 (unselected)
bond interface: en0 priority: 0x8000 state: 0xbd partner system: 0x0001,00:0f:3d:f8:12:8f key: 0x0013 port: 0x0013 priority: 0x0001 state: 0x37
bond interface: en1 priority: 0x8000 state: 0x05 partner system: 0x0001,00:0f:3d:f8:12:8f key: 0x0013 port: 0x0014 priority: 0x0001 state: 0x37</pre>

See my "ether" address it DOES NOT match the Mac addresses assigned to the Bonded en0 & en1 as yours does. Apple does it again, sometimes I love them then hate them, lol.

<pre>osxserver:~ root# networksetup -listBonds
interface name: bond0
{
user-defined-name: bond0
devices: en0, en1
}
</pre>

Please does anyone know what CLI commands will fix this?

Aww, Camelot don't do that to me. I was so happy to see a post from a senior forums member like you. Now I'm really depressed, 😉 lol.

Well as far as I can see this is a Intel hardware /10.4.x Problem not any problem with the switch. If I get time I have a Dual G5 and a spare Apple NIC I can pop in and see if it works. Someone in the XServe forum responded saying Apple knows about the problem but my case is still open and I have yet to hear anymore about it from Apple.

http://discussions.apple.com/message.jspa?messageID=3743666#3743666

Ok Apple Engineers have confirmed the problem and it will hopefully "be fixed in a future update" we hope. It is an Intel based system problem they did not say if it's hardware/firmware issue or software. I would think hardware/firmware fix needed since they offered no way to do a CLI fix but we will see.