Problems with Catalyst 2950 and Mac OS X 10.4 Systems

Hello,

since we have replaced our Catalyst 2924XL switches with Catalyst 2950 we get more and more problems with Apple Macintosh OS X 10.4 Systems with G5 processors. The systems get their static IP addresses from two SuSE Linux DHCP-Servers. In our campus-LAN 76 VLANs are configured.

Normally everything works well, but sometimes some Mac OS X 10.4 systems lose suddenly their server mounts. Sometimes other Mac OS X 10.4 systems don´t get an IP address while booting. After a reboot it works regularly. Deactivating the port-security doesn´t help. "Spanningtree portfast" and "switchport nonegotiate" is configured on the switchport.

Has anyone a hint on this problem? Thanks in advance! Kai Matthies

Reply to
Kai Matthies
Loading thread data ...

What about hard-coding the speed/duplex?

Reply to
Scott Lowe

Hello Scott,

we had already tested it with hard-coding (Full-Duplex - 100Mbit/s on Switch and Macintosh). No change on the behaviour. The same problem.

Greetings Kai

Reply to
Kai Matthies

Reply to
Robert B. Phillips, II

Hello Robert,

"spanning-tree portfast" is configured on all Server/Client-ports except on the trunks to the Core-Switches. (=2x Catalst 6500) By the way, we running MST (Multiple Spanning Tree) which is very stable and recovers very fast when a redundant connection is broken.

The tree DHCP-Servers are not in the same VLAN. We redirect the BOOTP/DHCP requests via three "ip helper-address" statements. But the DHCP-Servers are on the same campus. In the log, we cannot see any requests from the hardware-address in this time. Perhaps the Macintoshs send their DHCP-request before the network becomes ready. In the past there were workarounds with "spanning-tree portfast" and "switchport nonegotiate", but both is configured.

Regards Kai

Robert B. Phillips, II schrieb:

Reply to
Kai Matthies

Hi Kai,

Can you be SURE that the DHCP requests are even getting to the device with the "ip helper-address"? Are you able to snoop (or use debug) on the local segment for them?

I tend to agree, this sounds like a local segment issue so far. if you have any non-Macintosh hosts using DHCP on the same Ethernet segment, then the issue is very Mac specific.

Cheers............pk.

Reply to
Peter

Hi Peter,

since now, only Mac OS X Systems are affected. With Mac OS 9 Systems in the same segment we never had problems like this. Also with Windows PCs we hadn´t problems.

The next time this problem occurs I try to debug dhcp on the the layer-3-core-switches.

Regards Kai

Reply to
Kai Matthies

Hi Kai,

Ok, so its MAC OS X specific then. I dont know much about MAC's, but I wonder if the MAC OS X machines have something like a Firewall enabled that may be blocking DHCP traffic, or some sort of DHCP configuration issue?

If its a pure layer 2 issue that may not show much. Possibly better is using debug on the DHCP traffic to see the DHCP frames present at the Etherswitch level, before DHCP-HELPER even comes into play. Do you get any indication from your DHCP server that its seen the DHCP request arrive at all?

Cheers................pk.

Reply to
Peter

Mac OS X's underlying architecture is based on BSD and does offer the ability to use the well-regarded ipfw firewall, but it is not turned on by default. In addition, the OS X GUI only offers the ability to control inbound traffic; outbound traffic is not affected unless the user delves into the command-line. Nevertheless, checking to see if the firewall is enabled (System Preferences > Sharing > Firewall) may be beneficial.

It's certainly possible the DHCP responses just aren't getting back to the system: if these are the newer Intel-based Macs running Mac OS X

10.4, there was an issue (apparently resolved in the Mac OS X 10.4.6 update) that causes packet loss in networks using VoIP, VLANs, and 802.1q trunks. Apparently, the network driver has a problem recognizing 802.1q packets and the resulting confusion creates 40-50% packet loss. See this URL:

Perhaps this is the issue?

Reply to
Scott Lowe

Hello,

we have it! It was so easy. Our wiring-closets and the patch fields were not grounded. It is weired, that there were no errors on the switchports. Thank you for your helpful statements!

By the way, we have made the best experiences with auto-duplex on the switches and systems.

Best regards Kai Matthies

Reply to
Kai Matthies

Thanks for the report. I like Auto too.

The grounding thing seems weird to me?

I am going to post this to comp.dcom.lans.ethernet to see what they think of it there, hope you don't mind.

I had a look and to debug the UDP helpers you could likely use

deb ip udp

Reply to
anybody43

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.