Hello all,
Currently, we have a somewhat small (a few towers) wireless network. Currently, each tower feeds back to a “main” tower that has a CMM Micro and a Cisco Router to connect to our internet backbone. We use the private range of 172.24.x.x for our wireless gear, with each tower using its own subnet in that 172.24.x.x range. We have a remote dhcp server setup to hand out public ip addresses for our end users, who connect to our Canopy Gear.
We have been testing out PPPoE on the Cisco as well for other purposes.
Currently, we have the following situation going on:
We use public ips for our end users to connect, both via DHCP and the PPPoE testing. We had a case where a user has/had his linksys router plugged in incorrectly and was causing DHCP issues since he was acting as a rogue server. We found this user with the brdiging table in our APs. However, since turning off this user, we have found at least 3 more cases of this same issue happening throughout the network. While we can find and identify the users, I hesitate to say that this issue is each user has their linksys router plugged in wrong. Is there a way that I can, in the AP or SM, block the private range 192.168.x.x from passing out of the user’s SM/AP?
very simple to cure
few things
turn on SM isolation on the AP and use the DHCP relay agent in the AP, also do this in your switches and the problem will go away.
you can also use the the sm to do the job by going to config -> Protocal filtering and put a check in the Bootp Server and the problem will also go away
we do both for extra messure and reduce extra packets on the network.
DO NOT PUT A CHECK IN THE BOOTP CLIENT ON THE SM your client will not be able to obtain an IP address from your server. also do not use this if you have a relay agent behind an SM
mgthump wrote: very simple to cure
few things
turn on SM isolation on the AP and use the DHCP relay agent in the AP, also do this in your switches and the problem will go away.
you can also use the the sm to do the job by going to config -> Protocal filtering and put a check in the Bootp Server and the problem will also go away
we do both for extra messure and reduce extra packets on the network.
DO NOT PUT A CHECK IN THE BOOTP CLIENT ON THE SM your client will not be able to obtain an IP address from your server. also do not use this if you have a relay agent behind an SM
First off, thanks for the response :)
I found the SM Isolation option before you posted, but I'll be taking the other solutions to the boss to try and get implemented as soon as possible.
Little trick I have used in the past if you have a server on the network is to manually assign several of the default DHCP server addresses to the nic, ie 192.168.1.1 and 0.1
Often its enough to remind people to change the configuration when they get IP conflict.