We had an IP conflict the other day, and I’d like to keep it from happening again. Here’s the setup:
Our Canopy equipment is on a 192.168.x.x network, and we provide public IPs to customer PCs behind the SM. A DHCP server hands out the public addresses. The problem occurs when a PC behind an SM is manually configured on the 192.168.x.x network.
Example:
CMM (192.168.1.10)
±- AP (192.168.1.11) <==> SM <–> PC (192.168.1.12)
±- AP (192.168.1.12)
±- AP (192.168.1.13)
The PC and the 2nd AP have the same IP because the customer behind the SM manually misconfigured their PC.
WITHOUT setting up NAT on the SM, how can I keep this from happening??
Have a reliable router do DHCP for the tower’s customer base.
Cisco router doing DHCP (192.168.1.1)
±- CMM (192.168.1.10)
—±- AP (192.168.1.11) <==> SM <–> PC (via DHCP)
—±- AP (192.168.1.12) <==> SM <–> PC (via DHCP)
—±- AP (192.168.1.13) <==> SM <–> PC (via DHCP)
I think you misunderstood. My DHCP server is performing correctly. The problem is when a customer PC manually assigns an IP instead of using our DHCP server. Unfortunately there are always some customers who like to tinker…
The only way that I see this happening for you is if you are terminating SMs directly into hubs or switches, and the customer PCs are plugged into those same hubs and switches. Is this correct?
WITHOUT setting up NAT on the SM, how can I keep this from happening??
The way around it without setting up NAT on the SM is to setup NAT on a SOHO router. You said that you are providing routable WAN addresses to your customers, so just configure the WAN port of the SOHO router to receive an IP address via DHCP (which you said you have set up), and make sure the router is doing NAT. Any packet from the internal LAN destined to head out the WAN port will be NAT-ed to the public IP address that the router currently has, and should eliminate your conflict problem.
msmith wrote: The only way that I see this happening for you is if you are terminating SMs directly into hubs or switches, and the customer PCs are plugged into those same hubs and switches. Is this correct?
Not neccessarily, but I believe the customer did when we had this problem last week.
msmith wrote: The way around it without setting up NAT on the SM is to setup NAT on a SOHO router. You said that you are providing routable WAN addresses to your customers, so just configure the WAN port of the SOHO router to receive an IP address via DHCP (which you said you have set up), and make sure the router is doing NAT. Any packet from the internal LAN destined to head out the WAN port will be NAT-ed to the public IP address that the router currently has, and should eliminate your conflict problem.
The problem with this 'solution' is that it depends on the customer doing what they are supposed to. All it takes is one customer to manually configure their NIC incorrectly to start causing problems. I can't be in all of our customers' homes to make sure they keep things set up the way they are supposed to. I want to make it so that they CAN'T screw it up.
Unfortunately, you can’t completely eliminate this type of problem. You can, however, lessen the problem by using less common, private, statically assigned IP addresses on the Canopy units; e.g., 192.168.171.x, or 10.201.x.x, or 172.29.x.x. You could also stick with the factory default 169.254.x.x network. You could even use a block of public addresses assigned by IANA for use by someone else – such as IBM or Motorola – as long as you NAT the addresses before heading to the outside world for NTP or whatever.
You’re having a problem because so many SOHO routers, by default, pass out 192.168.0.x or 192.168.1.x addresses via DHCP. Because anyone with even limited exposure to IP networking sees this, over and over again, they’re very likely to use those networks out of habit or from the power of suggestion or just sheer laziness. Might you be guilty of this too? I was.
When I set up my first Canopy network, I installed it behind an existing LinkSys passing out 192.168.0.100+ addresses; logically, I assigned addresses below that (1-99) for the Canopy APs and SMs. The first time I hooked up a D-Link router behind an SM, however, the stupid thing wouldn’t work. Why? The D-Link, by default, had LAN addresses 192.168.0.x; its WAN interface received a 192.168.0.100+ address from the LinkSys; and routers refuse to route between identical or overlapping networks.
Fortunately, no one was looking over my shoulder at the time; I was able feel shame in private. If only I’d previously consulted some thick tome of esoteric networking details, like “IP Networking for Dummies”. Hindsight is 20/20.
Something Motorola could do to help would be to support DHCP client-capability on the Canopy’s management interface; they already support it on NAT’s outside address. If APs and SMs were getting their addresses from a DHCP server, and the server was set to ping an address before renewing a lease, and the lease time was set relatively low, the Canopy units would work around the conflicts.
The problem with dynamic addresses on management interfaces, of course, is having to check the DHCP server logs to verify an address before accessing the desired unit. It’s a nuisance.
Unfortunately, my suggestion is severe. I would change my internal ip scheme. Use the 10.xxx. for your radios and equipment. Today, linksys, cisco,dlink, netgear and all the other small routers default thier dhcp to the 192.168.xxx.xxx ip scheme. This directly conflicts with your system. If you don’t make the change you are asking for more problems and major confusion.
Here’s an example… Someone is bradcasting dhcp on the subnet, and it isn’t you. Who is it? The only way to trace it will be through the MAC address through your main router.but you have the same internal scheme as they do… You know you can only have one dhcp per subnet. Which one is taking priority… the closest one, so it onely effects some of your customers. Next, your own internal router may not be able to decipher who is who since the addresses are the same. (who got it first, therefore who should keep it) Your own dhcp won’t even know, it will only know. It will become useless becase more and more duplicates are being made.
If you insist on keeping this scheme … good luck. THen look into routed blocks.
i would also agree with the previous
i would use the 10,x,x,x range for gear and
i am using 172,x,x,x for lan2 range
so if get some one assinging a address unless they know a little bit more than nothhing nothing will happen but the connectivity will be lost
Allan11074,
If a customer installs a DHCP server visable to your network, you’ll have a problem no matter what IP address scheme you’ve selected for your own use. Two likely ways this could happen would be the customer connects the LAN port of their router to your Canopy SM, or they configure Internet Sharing in a Windows PC. If you or your other customers have any DHCP clients on the Canopy network there will be a conflict.
Tooslow,
When you say “172.x.x.x for LAN2”, are you referring to the Canopy AP’s Private RF Interface? It would be unusual for the default 192.168.101.x to cause a problem.
Also, be careful: only the address range 172.16.x.x to 172.31.x.x is available for provate use
yes i am aware of the 172.16.x.x that is what i am using for lan 2 address
because of the amount of gear that is coming out with th 192.168.x.x
i decided to change the lan2 address to something less farmiliar
Agreed. And this is really what I was trying to find a solution for. I think I just found that solution about 5 minutes ago:
Teknix wrote: Allan11074,
If a customer installs a DHCP server visable to your network, you'll have a problem no matter what IP address scheme you've selected for your own use. Two likely ways this could happen would be the customer connects the LAN port of their router to your Canopy SM, or they configure Internet Sharing in a Windows PC. If you or your other customers have any DHCP clients on the Canopy network there will be a conflict.
For customers without NAT, I need to make sure and check 'Bootp Server' under 'Packet Filter Configuration' on the 'Advanced Network Configuration' page of the SM. If I understand the user guide correctly, this will prevent any DHCP replies from getting past the SM into the Canopy network, but will still allow requests to get out -- allowing them to pull an IP from my DHCP server.