Jason,

Forget the VLAN and switch approach.  They might be usable on fibre
installs but radios are not the equivalent of a fibre or wire.  A
bridge is not the equivalent of a switch.  So using wireless bridges
is not the same as using fibre and switches.

The other issue is that bridging takes more CPU than routing.  Many
people will find this hard to believe but our routing performance
exceeds the bridging performance by at least 10%.  This is due to the
requirement of the CPU to analyze every packet in bridge mode whereas
routing just passes traffic for the MAC, which is all hardware
assisted in the Ethernet controller chip.

Subnet everything and use RIP and you will not have all IP addresses
addressable and you do not have to do anything other than enter a
default route.  It is just as easy as bridging without all of the
issues.

If you question whether there are bridge issues with wireless and
bizarre behaviour from proxy arp, mac cloning and WAN/LAN mixups then
you are not paying attention to the bulk of the posts on most of the
wireless lists and support forums.

People who tell you to bridge quite frequently do not know how to
route, and for that reason I would consider their advice as quite
suspect.  Bridging requires little or no knowledge which is why the
bulk of people use it.  They take the unit out of the box and connect
a unit and all of a sudden they have a magical LAN.  Rather than stop
and design a proper subnet structure they simply start adding other
users, and wow is it ever easy.  At that point they think those were
fools telling them to route.  How can something so simple and powerful
ever give them trouble?  Unfortunately as the bridge grows they begin
to have broadcast issues and so they investigate VLAN switches.  That
fixes it up and off they tear and add more customers and every now and
then another VLAN switch and life is great.

Then you get the guy who wants to run his own VLAN between his two
offices and the Industry comes up with VLAN in VLAN.  By now it is
getting a bit complicated and they have all of these VLAN tags to deal
with but at least they did not have to learn about IP and routing.  I
have noticed it is almsot like a badge of honour to be able to say
they do not route.

At the end of the day you still have a big old flat address space and
any customer can, and often does, affect your entire network.  With no
knowledge of your IP design, they can snoop and scan you and all of
your customers and your backbone infrastructure.  With nothing to
segment your network you have a fairly tough time to even find the
area the trouble comes from because the nature of a bridge makes sure
that everybody on the network can hear the traffic.  The purpose of a
bridge is to connect two or more physical segments and make them
appear as one.

The other point is the Internet runs on routed machines.  Sure the
Telcos have switches in certain locations but the whole grand design
is IP and subnet based.  Since you connect to that bigger network I
advise that you use the same design techniques that it uses.  To be
direct, a wireless bridge is not even close to a fibre switch with
FDX, unlimited bandwidth and no latency.

Bridging causes a lot of trouble.  I know this first hand since I am
the guy my customers call to get a hand in fixing the trouble.  Sure
the guys have a bit to learn about routing and subnets, but this is
their business.  Why would they not wish to learn about networking?
How can anyone be building out networks and not have a basic knowledge
of networking?  Wireless is a combination of RF and Network
Administration, and I am sorry to say, but most people in wireless
have no clue about either of those topics, yet they are active on the
lists and give out lots of "advice".

One of the largest wireless systems is run by Matt Larsen and you
won't find him telling you to bridge.  Will you Matt?

The decision is yours, but don't make the decision based on the fact
you have to learn a few things to route and can just jump in if you
bridge.  If you don't learn those few things about routing then I am
quite sure you'll end up learning a host of other things about
bridging and the plethora of issues you can have.

Routing is the very simple application of a few basic rules of
subnetting and traffic direction.  Once people have learned the basics
they usually tell me it is actually easier than bridging and not a
single person has ever told me that they had better performance when
they were bridged.

Sorry for the long posting, but this topic has touched some trigger
points of mine.

Lonnie


On 8/23/06, Jason Hensley <[EMAIL PROTECTED]> wrote:

Thanks for the info Mac.

First, I'm not that concerned about the CPE utility working.  That's one
reason I like the static IP setup - I know what user has what IP and how to
get to their CPE.

For the VLAN switch (that I'm not familiar with at all) can you tell me how
this would work on a 2 hop setup?   Basically what I have is Tower 1 to
Tower 2 using 5.8 backhaul, then Tower 2 to NOC using another 5.8 backhaul.
Where would I drop the switch, or do I need one at each tower?

Main thing / challenge that I'm seeing right now is that, like someone else
mentioned either here or on the other list, is that I cannot do true routing
with TR-6000's (my AP's).  So, what I've got to figure out how to get past
that.  I'm considering replacing the 6000's with Mikrotik's, but not sure
about that 100% yet.

I think I've been talked out of using the public IP's on each CPE ;-)  and
am now planning to do 1-1 NAT.  But, I'm just having trouble picturing in my
head how I'm going to do this - especially with the TR6000 routing
capabilities (or lack of).

Public IP's, at least for now, are pretty easy for me to get.  I could
easily justify another /24 to my upstream, but beyond that, it would take
some pretty convincing data for me to get more.  But, once I get to that
size, I'll be looking at buying my own block(s).


----- Original Message -----
From: Mac Dearman
To: 'WISPA General List'
Sent: Wednesday, August 23, 2006 9:48 AM
Subject: RE: [WISPA] Managing CPE in routed network



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.


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.
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

www.mac-tel.us               (VoIP Sales)

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/



--
WISPA Wireless List: wireless@wispa.org

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

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





--
Lonnie Nunweiler
Valemount Networks Corporation
http://www.star-os.com/
--
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