Could some one PLEASE help me! Statically assigning ip addresses is not an option at this time! I've never seen this before or know anyone who has! We have four schools networked together. Each building has a Zenith Cable Homeworks Universal Modem. We also have a Remodulator and Tranceiver at the cable plant. The cable modems come into the main school and we have a Sonicwall Pro 200 as our DHCP Server and firewall. The router is out side the sonicwall and connects to a T1 line. The router is plugged into the sonicwall, and the sonicwall is plugged into a 3Com switch, the other hubs are on the switch. We are 95+% Imac computers. There is one G4 Server at each school, running appleshare and mac manager.We have static ip addresses on all main equipment. Everything works fine on pcs using DHCP, and static. This problem is effecting the imacs. When I turn the computers on, 4-5 may get an ip address and the others don't. They default to 169.x.x.x and if mac manager is on, they hang before logon for 20 minutes.If mac manager is not on they start up but with out the ip addresses. It isn't the mac manager though, cause I formatted all servers this summer and ran the network with out them or mac manager and still had the same problem. Something is distruping the macs from renewing their ip addresses. If I force it by trashing the tcp/ip preferences, and restart a few times they do get one, but as soon as the lease time expires, its back to the same thing! I can't do this to every machine in four buildings! I've spent all summer trying to figure it out! I have checked apples web site, but nothing seems to apply. All computers have 9.0.4-9.2.2 OS, and all software has been updated, firmware, everything I can think of! I can have two imacs plugged into the same hub, one gets the address and the other does not! The next day they might both get one, or none of them will get one!Its not the same computers every time either. Is there anything on a Cisco 1700 or the SonicWall Pro that would cause this behavior? I have DHCP disabled on our NT server also. Thanks, Fredette
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
PLEASE help! Here is a challange! Cisco/Sonicwall/Zenith nightmare! 2
- Thread starter fredette
- Start date
-
1
- Thread starter
- #3
-
1
- #4
My personal opinion of late is that Sonicwall is not long for the world. Their product has not been the best of late and their paid for support has been terrible.Who is serving up the DHCP addresses? the Sonicwall? Default gateway is the sonicwall? Get a freebie sniffer like Ethereal and see just what is happening to the DHCP packets. Do the Macs want DHCP or BOOTP? there is a subtle different between the two protocols even people tend say them in the same breath.
IMacs are normally pretty painless on a network configuration.
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
IMacs are normally pretty painless on a network configuration.
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
- Thread starter
- #5
- Thread starter
- #7
All Pcs in ever building work, The macs are scattered through out evey building, a few might work in each building but the others in the same room don't work. (At every school) When one building has all its macs getting IP addresses, every building gets one! I have disconnected the cablem modem coming into the main school and restarted the imacs in that building, but it still happens. I though something that was comming into the building was distrupting them, but it doesn't seem to be!So I think the issue is with the main building, I just don't know where! Make sence? fredette
Try this.. instead of using the sonic wall for the DHCP server, either setup a real DHCP server on one of the wintel boxes OR use the Cisco router as a DHCP server. It has the sound of a timeout issue where either the Macs are too fast or the Sonic wall is too slow in responding back with either the address or the ACK for the request of an address.
What version of code are your sonicwalls running? this note is from 5.1.1
"A bug was fixed which caused the DHCP server to assign invalid leases to LAN users. "
"In some cases with firmware version 5.1.0, the SonicWALL DHCP client can take up to 10 minutes to obtain an IP address from a DHCP server on the WAN. This issue has been resolved. "
Also, Sonicwall states they can only provide 254 addresses.
The Sonicwall can not provide for multiple subnets.. ugh!! I go back to my suggestion of a real DHCP server.
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
What version of code are your sonicwalls running? this note is from 5.1.1
"A bug was fixed which caused the DHCP server to assign invalid leases to LAN users. "
"In some cases with firmware version 5.1.0, the SonicWALL DHCP client can take up to 10 minutes to obtain an IP address from a DHCP server on the WAN. This issue has been resolved. "
Also, Sonicwall states they can only provide 254 addresses.
The Sonicwall can not provide for multiple subnets.. ugh!! I go back to my suggestion of a real DHCP server.
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
- Thread starter
- #9
Our sonicwall is running 6.x something, maybe it is the newest one cause I updated it. We weren't using it for multiple subnets. I saw the info about the 5.1.0 dhcp, the newest version was suppose to correct this problem. I might have to put the NT server back to a DHCP server, but after paying so much for the sonicwall, I would really hate to do that!But, there is no way I'm assigning Ips to every computer! That would be a bigger mess!
You paid for a firewall.. not a DHCP server. Keep that in mind. The DHCP is strictly a fun thing to have but I would not run a business off it. Or in this case, a school. Keep in mind that Linux can be a DHCP server just as easily and all you need is an old 133Mhz pentium to tuck into a dark corner somewhere. Even Windows 4.0 on a *old* P166/128Meg of ram will make a great DHCP/WINS server as long as you shut down all unused services.
Again, a sniffer will tell exactly what is happening and who is at fault. Ethereal is free and works very well for this sort of thing. Etherpeek is very nice and has a good 30 day demo which is crippleware but will work well enough for what you need here.
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
Again, a sniffer will tell exactly what is happening and who is at fault. Ethereal is free and works very well for this sort of thing. Etherpeek is very nice and has a good 30 day demo which is crippleware but will work well enough for what you need here.
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
- Thread starter
- #11
First of all, I am aware of the reasons that I purchased the sonicwall. No, I did not purchase "a firewall", I needed a DHCP server. I already had a firewall. The whole point of buying that equipment was to run the DHCP off of the box, and use the firewall instead of running it on the Nt server. We have already tried Etherpeek on the network. I think it was working that day so it might not have shown the problem. I can't remember. I have also tried Mac Ping and InterMapper on the network. Nothing shows up!fredette
Set up a custom filter to catch only DHCP and just let it run. Plan on several meg of captured packets but you should be able to catch a failure.
You are quite right that static IPs would be a major pain to keep going. I dont recall if there are any adjustment on DHCP timers with the sonicwall. There may be some on the Mac but I dont recall any.. of course, it's been a lone while since I've been hacking a mac.
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
You are quite right that static IPs would be a major pain to keep going. I dont recall if there are any adjustment on DHCP timers with the sonicwall. There may be some on the Mac but I dont recall any.. of course, it's been a lone while since I've been hacking a mac.
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
"You paid for a firewall.. not a DHCP server. Keep that in mind. The DHCP is strictly a fun thing to have but I would not run a business off it..."
That's dark ages thinking I'm afraid.
Especially when it comes to most schools I know of. Multi-service hosts are the rule, not the exception, and dhcp is NOT a luxury item.
"Again, a sniffer will tell exactly what is happening and who is at fault..."
Maybe...the client sends out the broadcast request..you should see this..
The reply you will not see from a non-
promiscuous monitor port on a switched network, or if you have dumb switches
as we did at one site I worked at..
HTH
That's dark ages thinking I'm afraid.
Especially when it comes to most schools I know of. Multi-service hosts are the rule, not the exception, and dhcp is NOT a luxury item.
"Again, a sniffer will tell exactly what is happening and who is at fault..."
Maybe...the client sends out the broadcast request..you should see this..
The reply you will not see from a non-
promiscuous monitor port on a switched network, or if you have dumb switches
as we did at one site I worked at..
HTH
It's been my experience that very few things that are touted to many things, do them all well. When a device tries to be too many things at once, all things will suffer at some point. I've worked in the school system both as a tech and a instructor and I know the political side and the lack of money side too well. It's good to try to combine things but when something doesnt perform as well as you would expect, it's to be expected. We have a device that is primarly designed to be a firewall, has known problems in the past with DHCP, and based on my latest experience with them(last week) the VPN code is shaky at best. This does not breed confidence that the device can perform a simple task like DHCP well. The comment about running DHCP off the Sonicwall was not a slam agaist DHCP, but against the Sonicwall's implementation of DHCP which has proven to be problematic at times. If you read all my posts, I suggested moving the DHCP to either a Linux box or a Wintel box where you are not limited to a single subnet of 254 hosts. I even suggested for troubleshooting to set up the DHCP server on the Cisco router in order to run a comparsion. If it works better, then you know the problem is the sonicwall, if it does the exact same thing, then the problem is in the architecture or on the client side.
With regard to the sniffer. Any tool is only as good as the person using it. A monkey with a snap-on wrench is completely useless even though the tool is one of the best. A smart mechanic with a Wal-Mart imported wrench can probably do the job as well as with the snap-on except for perhaps, some skinned knuckles from an ill fit on the bolt.
The sniffer will tell you exactly what is happening on the wire between the two devices provided you know how to use it correctly. Correctly can mean everything from where to place the sniffer to writing a custom AND/OR filter to get as tight of a filter as you can. If you have a switch port, either monitor the port or get a cheapo hub at 20 bucks to insert into the line. Virtually every sniffer *expert* carries a couple of cheap hub exactly for this reason. Do not expect to stay at your desk with the sniffer and get the answer, you will need to get up and go to the equipment. Even a distributed sniffer while better has limitations along these lines.
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
With regard to the sniffer. Any tool is only as good as the person using it. A monkey with a snap-on wrench is completely useless even though the tool is one of the best. A smart mechanic with a Wal-Mart imported wrench can probably do the job as well as with the snap-on except for perhaps, some skinned knuckles from an ill fit on the bolt.
The sniffer will tell you exactly what is happening on the wire between the two devices provided you know how to use it correctly. Correctly can mean everything from where to place the sniffer to writing a custom AND/OR filter to get as tight of a filter as you can. If you have a switch port, either monitor the port or get a cheapo hub at 20 bucks to insert into the line. Virtually every sniffer *expert* carries a couple of cheap hub exactly for this reason. Do not expect to stay at your desk with the sniffer and get the answer, you will need to get up and go to the equipment. Even a distributed sniffer while better has limitations along these lines.
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
Wybnormal..
I'm not going to argue the one server = two services : max
algorithm..this is a best practice. It doesn't happen in
schools.
If you know schools you know that, "the tool is as good as the person argument.." is fallacious. The tool is usually much better.
I know for a fact that many schools will let you diagnose
a problem but not have access and permission to replace core components (crap switches) for hubs even for a few minutes.
These are practical problems however and I agree with you in theory.
I'm not going to argue the one server = two services : max
algorithm..this is a best practice. It doesn't happen in
schools.
If you know schools you know that, "the tool is as good as the person argument.." is fallacious. The tool is usually much better.
I know for a fact that many schools will let you diagnose
a problem but not have access and permission to replace core components (crap switches) for hubs even for a few minutes.
These are practical problems however and I agree with you in theory.
I also learned in schools that what they dont know wont hurt them ;-) I became very good at obscuring just what it was I was doing. And I made sure I was friends with all the players on the network team.. router geeks, sysadmins and the like... amazing what a box of dougnuts can do for friendship. I also went out of my way to help in places that were not my normal areas.. not to lord it over the real players.. I would suggest things and let them take credit. The upshot was when I needed to bend the rules, I normally had the help I needed to bend them. I've also been known to cause a network *outage* in order to get something done that I could not get *permission* otherwise. Gee.. I just done understand how that network cable fell out of the jack...
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
- Thread starter
- #17
Ok, First of all I am the Lan Admin. I have full permissions to test and replace anything I feel I need to do. I'm looking for a reason between a mac and dhcp that would cause an entire district disturbance. I don't need to ask permission to make changes, I just do it. This is the only thing I can't seem to find. And I take offense to a "tool is only as good as". With a B.S. in Information Systems, I am well capable of managing our network. I presented this as a challenge. I have never come across this particular issue. fredette
You've been presented w/ a possible solution. I would take Mike's advice and try...
"moving the DHCP to either a Linux box or a Wintel box where you are not limited to a single subnet of 254 hosts. I even suggested for troubleshooting to set up the DHCP server on the Cisco router in order to run a comparsion. If it works better, then you know the problem is the sonicwall, if it does the exact same thing, then the problem is in the architecture or on the client side."
It's worth a shot right? Your problem is w/ DHCP, why not start @ the source...
"moving the DHCP to either a Linux box or a Wintel box where you are not limited to a single subnet of 254 hosts. I even suggested for troubleshooting to set up the DHCP server on the Cisco router in order to run a comparsion. If it works better, then you know the problem is the sonicwall, if it does the exact same thing, then the problem is in the architecture or on the client side."
It's worth a shot right? Your problem is w/ DHCP, why not start @ the source...
No offense intended Fredette- sometimes when you are frustrated with something , it's hard to back away and hit it from another direction. I'm just offering a different direction in troubleshooting.
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
MikeS
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
I did find this today:
Updates needed if running OS 8.6
Open Transport 2.6 - (1/4/00) (ONLY for the new CD slot-loading iMacs) Open Transport 2.6 addresses DHCP issues in Mac OS 9.0.0 and prevents Macintosh computers from being used in certain types of Denial of Service (DoS) issues. Open Transport is the networking software in the Mac OS. This software installer updates Open Transport to version 2.6. This updater is for use only on computers using Mac OS 9.0.0, and PowerMacintosh G4, iBook, and iMac (Slot-loading) computers running Mac OS 8.6.
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
Updates needed if running OS 8.6
Open Transport 2.6 - (1/4/00) (ONLY for the new CD slot-loading iMacs) Open Transport 2.6 addresses DHCP issues in Mac OS 9.0.0 and prevents Macintosh computers from being used in certain types of Denial of Service (DoS) issues. Open Transport is the networking software in the Mac OS. This software installer updates Open Transport to version 2.6. This updater is for use only on computers using Mac OS 9.0.0, and PowerMacintosh G4, iBook, and iMac (Slot-loading) computers running Mac OS 8.6.
Find me at
"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu
- Status
