I hav been using NAT on most of my SM’s and have encountered problems on about 70% of the units. They work perfectly for a while and then seem to start working on and off. The SM will connect to the AP for about 7-14 Minutes and then not connect for the same peiod of time. This then continues until NAT is disabled in the unit. It will then function fine again when NAT is enabled again, but only for a couple of days, then the same problem occurs. I do have SM’s that have woked with NAT for the past 9 months with no problems. It is a nice feature, but useless if it is unreliable.
Any suggestions ???
I am currently experiencing the exact same problem. I have not had a chance to test/confirm this, but it seemed like it started for me about the same time I upgraded to 6.0 (900 MHz).
It appears to me to have something to do with the ARP cache in the SMs that causes the issues. I never lose RF connectivity, (unless I reboot, myself) the SMs just stop passing traffic from the NAT/LAN side.
I can telnet to the SM from the AP shell, and from there ping PCs that are connected to the SM, but no good from the PCs to the Internet.
Tech Support origionally thought that it had to do with my ARP cache and Bridge Entry timeouts, but I had already set those to what they recomend (reading the maunals cover to cover trying to figgure it out myself). Tech Support asked for screen shots of all my configs and its been forwarded to the engineers. I would assume they are pretty busy with the 6.1 release though.
Guess its time to wait and see…
When a SM stops working for the customer, try looking at the NAT Table found in the Expanded Stats. At the bottom of the table it shows the amount of “used” and “free” nat table entries. If there are 0 free then the SM will stop working. We have found that viruses, spy bots, and some file sharing software will fill the tables fast. Running virus scans in these cases always find at least on PC infected and when that is cleaned up everything goes back to normal
That occured to me too, pretty early on in my testing (Tech Support thought that was the culprit as well). But alas, tis not the case. During failures, I checked the NAT table and there were plenty of “slots” free.
Thanks for the help though, any other ideas?
Have your tried adjusting the garbage timeouts? I would suggest lowering both the TCP and UDP values and then check your results again.
Just to clarify my problem. It appears to be more prevalent when the users connecting through the SM are runnng Mac OSX. All the available NAT slots are used up by requests from ports in the 50000 to 60000 range and going to ports in the 10000 range.
These ports seem to be only on the Mac systems
If you lower the garbage timeout value it will decrease the time that these ports sit idle. The quicker these idle ports expire the better off you are. This will help when these ports being opened and left open.
Yup, I have 7.0 loaded into a bunch of SM’s (50) here in my office.
Testing this NAT stuff before deployment and I am having this issue. Seeems to be around 15-30 minutes and the private to public NAT stops passing packets. I can ping the radio from both side fine, but not through it (I’ve tried 6 radios so far and they all act the same). I took a look at the NAT tables in the units and there’s like 30 used and 2018 free. WTF!! Reboot and everythings fine for a bit. :evil:
I have now set all of the timers to the minimums to see what happens. This will be the biggest problem with Canopy I have encountered so far. Not impressed. Motorola may get a disturbing phone call from me soon.
Aaron :x
I’m watching this thread and am concerned. I was about to roll out NAT and filtering to improve network performance.
I am still doing a lot of testing in between other jobs. I haven’t had a chance to scream at my Motorola rep just yet. I will keep you posted.
Aaron
I have this problem on about 5% of my units, I’ve had this problem with 4. and 6. (havent used 7. yet), But I like using the NAT, this makes deployment much cleaner and more controlled, Its alos easier for my Techs, All they have to remember is the same IP when at cusomters site.,
I’m using the 169.254.1.0 subnet, I’m wondering if that has anything to do with it. I’m going to try a 10.10.10.0, to see if that makes a differnce. :evil:
schavez wrote: I have this problem on about 5% of my units, I've had this problem with 4. and 6. (havent used 7. yet), But I like using the NAT, this makes deployment much cleaner and more controlled, Its alos easier for my Techs, All they have to remember is the same IP when at cusomters site.,
I'm using the 169.254.1.0 subnet, I'm wondering if that has anything to do with it. I'm going to try a 10.10.10.0, to see if that makes a differnce. :evil:
can i ask what is NAT and what is the purpose of NAT?
NAT - Network Address Translation
http://www.monster-isp.com/glossary/NAT.html or any other search for NAT (I could write a lot about NAT in here).
I have been testing with 7.0.7. The majority of the problems I am having are with pings. I can have a continuous ping running through the SM and every few mninutes (varies) pings will start to time out (usually come back after 10 or 20 missed). After some investigation, it looks like while the pings are being dropped (somewhere?) normal web surfing is still possible. At one point I lost my pings all together (timed out for more than 5 minutes) but TCP traffice was still passing no problem. :?
I have no idea what the problem is - I turn OFF NAT and things work just fine. Erratic filtering in the SM? All filtering is turned off where it can be. I tried pinging different hosts outside the SM and same result every time. Different SM’s (20 of them), same result - time outs varied and time between varied. Also, tried going back 6.1, 4.2.3 - same result.
Canopy Guys??? :?:
Aaron
7.0.7 using hardware or software scheduler? Do you have high priority enabled or disabled?
I am using hardware scheduling, high priority is disabled.
Aaron
bump
UPDATE!!!
After some extsnive testing on our system I have found a solution to our NAT problems. I am not saying this will work for everyone having these issues but it has worked for us and we are continuing to monitor the network.
What was happening was the Canopy SM would stop passing all data through it after a few minutes. There seemed to be no rhyme or reason to the timing. When the SM was rebooted the entire system would work flawlessly (other than HWS problems). After anything from 5 minutes to 60 minutes the NAT would stop passing data from the private side to the public side. I did the best I could to verify this using a number of different ways including packet sniffers, Fluke NetTool, and just watching the stats in the SM - the SM would just suddenly start bocking all traffic, ALL traffic. It would respond to requests for the web GUI on both sides though.
My solution - or at least the thing that works for us - is to go into the IP Configuration page and DISABLE the RF Public Interface. I had both the RF Public Interface AND the NAT Public Interface set to the same address. I believe this may have been the problem. Not 100% sure about it though and the manuals don’t really help much there (everyone knows that) but disabling for now does the trick. It would appear that the SM could be set up to respond to 3 diufferent addresses - NAT Private, NAT Public, and RF Public. If most of my changes will be done using the LUID’s on the AP’s then I really don’t need the RF Public Interface.
In my complicated network achitecture I believe this is the solution I have been looking for. I’m a happy man now.
Wow, that took a long time to write in between phone calls. If anyone has any comments let me know. If this helps others then good. Perhaps Motorola can rewrite the manuals with some clarity - maybe have the engineers write them instead the marketing guys. :lol: lol
Aaron
Aaron,
I am glad you finally found the solution for this issue, to add some to your results, months ago I’ve the same situation and I tested with 3 different addresses in different subnets and no worked, the SM stopped passing data after some time, but what I didn’t try yet was disabling the RF Public interface. May be this could work for us too. So far the only costumer left doing Nat with the SM is so pissed off after reseting their SM each ten minuts so they set up a broadband router and disable the SM NAT, but I will do more testing just for fun.
Regards,
JV
I have one SM using NAT and have never experienced this problem. The SM does have its RF Public Network Interface enabled, but the static address assigned is different than the outside NAT address obtained via the SM’s DHCP client. Both addresses are on the same private IP network and use the same gateway.
If this configuration avoids whatever problem others are experiencing, I’m glad, but I did not set it this way out of prescience. I assigned a valid static address to the SM to be able to browse and telnet to it directly without going through the AP. I enabled NAT’s DHCP client and server to automatically pass DNS entries from the central DHCP server to the customer’s PC without having to add the entries to the SM.
Also, the SM can potentially respond to 4 different IP addresses:
1. NAT Inside (only responds on LAN side)
2. NAT Outside
3. RF Public
4. RF Private (only responds to AP)
I use the terms Inside & Outside for NAT (typically called LAN & WAN in SOHO routers) to avoid confusion with the terms used by Canopy (RF Private & RF Public) and the Internet Protocol (Private & Public address ranges).
We have about 250 Units at least that have NAT turned on and the RF public enabled and have never experienced what you have described. Our config is as follows:
NAT Public (Outside): 10.100.13.0/24 - 10.100.15.0/24
NAT Private (Inside): 10.1.1.0/24
RF Public: 10.100.243.0/24 - 10.100.245.0/24
RF Private (only responds to AP)