I will echo Mac's comments with just a couple of modifications. I also put 95% of my customers on private IP addresses, and that has worked wonderfully. I have a separate subnet for every access point, and this has done a great job of keeping problems isolated and making troubleshooting much easier, even though it has made my routing tables a bit complicated. FWIW, I started with 192.168.254.0/24 and am working my way down from there - that way I have little chance of intefering with a default network setting on a client router. I'm at 192.168.189.0/24 right now, so I have quite a ways to go before filling it all up. When customers need public IP addresses, the first thing that I do is try a 1:1 NAT. That keeps the customer on the private side. We have done this for a few people who are using VOIP and that seems to help them maintain better VOIP connections. If 1:1 will not work, then I set up a small routed subnet of public IP addresses on the sector. More routing complications - yes - but it is good design and conserves public IP addressing space. I have around 1300 customers, and three public class C networks spread out across 60 APs to give you and idea. For management of CPE radios, I have done a couple of things that have made it pretty simple. My billing software (freeside) automatically assigns an IP address for the customer, and then one for the CPE. We generally give the customer an even IP address and then their CPE radio is the odd number right above it (i.e. 192.168.250.2 is a customer, 192.168.250.3 is their CPE). I like this a lot better than having a separate subnet for the CPE radios. My home office and our main office are both on public IP addresses, but we are behind the router that does the NAT translations, so I can ping any private IP address on my network even though I have a public IP. That makes it simple to manage customer radios from those two locations. On the rare occasion where I need to get access to a CPE from outside my network, I have set up 1:1 NAT rules specifically for the particular radio. Anyway, that is what works for me.
Matt Larsen
[EMAIL PROTECTED] Mac Dearman writes:
Jason,
   I had one of the largest bridged networks ever as I cover 15-18% of the
State with wireless. I can tell you a few things about bridging-vs-routing
and I aint getting into that, but I can tell you that I don't think you will
want a totally static routed network either. That is not necessary unless
you have 50-60 clients to the AP and have multiple hops with that type of
traffic. You do need to be in a routed environment today, but IMHO not in
the way the majority would steer you.
Ok, this may be a simple question, but I'm trying to figure the best way to
do this.  My wireless network is currently all bridged with three different
POP's (all statically assigned private IP's).  I'm getting requests for
public IP addresses and as I add more clients, I feel like I'm really going
to need to have a routed network.
There are many ways to accomplish what you need to have done and I suggest
that you look at each one of the suggestions that will have been made and
get a good understanding of what will be required down the road to continue
what you start. There are a couple very simple solutions that will work, but
then there are many ways to accomplish the same task using static routing.
1.      Simplest and fastest (maybe best) is to use layer 2 switches
utilizing VLANS. You can get a switch like a ($250.00)  Linksys SRW224G4
(naturally there are better but that will work fine) as there are whole
Counties utilizing networks with the Linksys switches and routing and they
aren't even wireless, but fiber!  Arlington County Virginia is just one
example and they do the back up for the Pentagon and they are a huge
completely bridged network.
2.      Keep your bridged environment between your APs and your clients, but
route the backbone to all of your towers. It will break up the broadcast
packets...etc from tower to tower, will segment each tower and will not
allow a single clients virus to sweep through your entire network and have
rolling outages. It also keeps you from having to use 10 subnets/ip ranges
for 3 towers and allows for unlimited growth potential.
My biggest question is, how do you manage your CPE remotely in a routed
network?  Right now I'm pretty much 90% Tranzeo gear (mixture of CPE-15's
and CPQ gear).  If a customer calls with performance or other problems, I'm
able to log into their CPE from here to see what's going on from that end.
I would much rather maintain that ability but not sure how to do that with a
routed network.
I understand this question as only another etherant/Tranzeo CPE user would
:)  Once you enter a routed environment on the backhaul or otherwise - your
scan utility will not scan but to the first router where it will loose its
ability to go any farther as the scan tool uses broadcast packets to seek
its objects and the router kills broadcast packets. You will have to log
every IP on your network and access the antennas via HTTP. (web interface)
The scan tool will still be functional at each individual tower and will
capture the antennas on the wireless AP you are attached to at the moment.
If you maintain a bridged network w/VLANS then the scan tool and everything
else will work as it does now.
Also, I would ideally like to have a public IP assigned to each CPE.  The
double NAT'ing I've got going right now has been causing a few issues, plus,
I'm getting more business customers that want VPN and Remote Access to their
network.
I would NOT use public IPs for CPE, but I try to use public IPs for my
infrastructure. Its one of those deals where we all have our own beliefs, If
you use private IPs then you would need to do a VPN or RDP (remote desk top)
back into your network to see what's going on. The biggest advantage to
privates on infrastructure is NO HACKING from China...etc. Give only public
IPs to those who have a need and willing to pay a little extra for the
ability. VPNs work even though they are behind NAT. I would also encourage
you to keep your bandwidth shaping at the head end of your network for
convenience and easy back up. They can only send data as fast as you allow
them irregardless of where you do traffic shaping. The PC will slow down the
data it is sending thru your network to match what you set there speed to be
and it does not create a traffic jam on your network - - as some would make
you believe.
I realize this will take subnetting to make it happen.  I've got a /24 right
now and can easily bump to more when needed.
I have a huge network right now and only have 2 /24's and 2 /27's, but I
don't give public IP's to anyone who don't pay for them so 90% of my clients
have a private IP. If more public IP's are easy to get - get them! Once
again the greatest advantage of private IPs is the lack of the rest of the
world to hack on our clients. How are the rest of you handling your setups like this?
Half of my network is static routed and half is completely bridged. Which
one is faster? The bridged!  Which one is easier to maintain? The bridged!
Which one is easier to add clients to? The bridged! Tell me - is the
internet bridged or routed? It is a combination of both! Routers are only
used where routers are needed and if you counted the routers -vs- switches
on the fiber backbone of the internet which do you think have the greatest
population? I see it the same way on my network - - I will route where I
need a router and use a good switch and a VLAN everywhere else. Let the games begin :-) Mac Dearman Maximum Access, LLC. Rayville, La. www.inetsouth.com <http://www.inetsouth.com/> www.mac-tel.us <http://www.mac-tel.us/> (VoIP Sales) www.radioresponse.org <http://www.radioresponse.org/> (Katrina Relief) 318.728.8600 318.728.9600 318.303.4181 _____
Jason Hensley, MCP+I
President
Mozarks Technologies
909 Preacher Roe Blvd
West Plains, MO 65775
[EMAIL PROTECTED]
http://www.mozarks.com
417.256.7946
417.257.2415 (fax)
--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Reply via email to