Hi Lonnie,
I thought this was worth some additional discussion. Please see below:
> When the card goes into promiscuous mode for bridging the CPU sees way more
packets and has to check headers and decide what to do with the larger number of
packets.
This is just a restatement of the same point that we discussed below. The CPU
doesn't "see" any more packets at L2 than it does at L3. See the earlier
discussion for the reasons behind why CPU performance may be different when you
bridge.
> We both say the same thing. We both see better performance with routing.
Nothing to disagree about there.
Other than both agreeing that CPU load is up, we're not saying the same thing at
all. It's not a matter of semantics--other than the conclusion, we're far
apart.
> RIP is just so easy and it works so well. OSPF has to be tweaked and played
with. With wireless (my world) OSPF is not as easy as cat5 and fibre, so from a
wireless perspective we advise RIP until you get redundant links and then we
advise people to move to OLSR mesh routing.
I strongly disagree with three of your four points:
1) RIP is just so easy
Yes--you turn it on, and it goes. I agree that it is simple.
2) It works so well
Rarely. :-) If your network is small, stable (no or few routing changes) and
high-speed, you MIGHT be right. RIP is still not the best choice for those
types of networks, but it could function properly. The problem is that RIP
doesn't just update the status of the links to its broadcast partners. Instead,
routers running RIP announce EVERYTHING to every broadcast partner. RIP also
can't calculate the best link--just the one with the fewest hops...leaving you
almost no control.
If your network fluctuates (as wireless networks tend to do more often than
fiber or cat5), RIP runs into convergence problems because of the mass
broadcasts of routing tables. In addition, RIP cannot address these issues:
- Routing loops.
The implementation must trust all network participants to prevent loops on their
own. RIP has no protocol-based mechanism to handle this (the way OSPF, IS-IS,
and BGP do). RIP is unsuited to fully meshed networks (of which many wireless
networks are).
- Limited hop counts
RIP uses a hop count of 15 to denote infinity, which makes it unsuitable for
large networks and fully meshed networks.
- RIP has convergency problems
Routing inconsistencies arise because routing update message propagate slowly
across the network. In large networks or networks with slow links (ever have a
wireless link run slowly because of signal problems?), RIP routers may still
advertise a route that has vanished. This originally was one of the main
reasons that the hop count was limited to 15.
- RIP has trouble with varying subnets
and the list goes on and on...
OSPF addresses all of these issues
3) OSPF has to be tweaked and played with. With wireless (my world) OSPF is not
as easy as cat5 and fibre
I'm not sure that I understand the last part. OSPF has nothing to do with cat5
or fiber or wireless. That said, OSPF does not have to be tweaked or played
with (at worse, you don't play with it any more than RIP does with split horizon
updates or hold-downs). A simple, single-area OSPF setup requires nothing more
than turning OSPF on, specifying which netblocks you want to announce, and
leaving the defaults alone.
4) so from a wireless perspective we advise RIP until you get redundant links
and then we advise people to move to OLSR mesh routing.
I only disagree with the first part, but I'll say that if you implement OSPF
from the beginning, you don't have to move anything. OSPF works in both the
simple and more complex meshed setups. We can put you in touch with wireless
ISPs running OSPF setups in single area unmeshed and multi-area meshed networks.
You'll find that their experiences are far different from what you suggest.
OSPF goes in and works as the network grows. You don't need to make mass
adjustments to it.
One of the nicest parts about OSPF in a wireless network is the ability to drop
a new netblock in at an AP and just walk away--OSPF propagates it quickly,
safely (no routing loops), and without messing up any route aggregation (who
wants to pass around a bunch of routes with subnets less than /24 ?)
> OSPF is a 2 layer network with nodes coming off the main backbone node.
Everything must connect with good old area zero and that is fine for a backbone
but it is rather limiting for a backbone that spans many different locations and
customer locations with possibly links going from there.
Huh?
No, everything doesn't connect to the backbone area. It is entirely possible
and logical to have:
Area 0 --- Area 1 --- Area 5
|
|
Area 2 --- Area 3
if that's how you want to lay out your network. OSPF does NOT require a
hub-and-spoke setup. If you wanted, you could have area 0 be an island and
connect to nothing at all (though why you would do this, I have no clue).
> OLSR handles that amazingly well and it is awesome at rerouting if a link dies
or gets too noisy.
I agree with this part. OLSR is a nice solution, and I would recommend it over
OSPF but for interoperability issues. OSPF is more widely supported. Other
than that, OLSR is at least an equally good choice, if not a better one, for
wireless networks.
The caveat to this discussion, of course, is that no routing protocol is
perfect...even OLSR and OSPF. For every protocol, you can find a few drawbacks.
On balance, RIP has far more drawbacks than benefits. OLSR and OSPF are the
opposite.
> It propagates the default route so setup is even easier because you do not
even require a gateway setting, just enable OLSR and it talks to the LAN and
announces and gathers routes.
You don't need a gateway setting with OSPF unless, for some reason, you set your
network up that way on purpose. I wonder if you're confusing OSPF with BGP
here, since BGP _does_ require a gateway setting.
> We support RIP, OSPF and OLSR Mesh, with mesh being the one we like the best.
We ultimately agree on the outcome here--we support any of the three.
Jeff
On 8/23/06, Jeff Broadwick <[EMAIL PROTECTED]> wrote:
> Hi Lonnie,
>
> While I agree with you about routing being superior to bridging on a
> wireless network out to the radio, I have to disagree with you on a couple
other matters:
>
> > 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.
>
> I believe you have it backward, bridging typically only has to look at
> the hardware MAC destination - 1st 6 bytes of the Ethernet frame. IP
> routing has to look at the Ethernet frame's type field and if it's an
> IP frame the router's IP stack looks at the destination IP address to
> figure out where it should be routed.
>
> For us bridging does require more CPU than routing (with connection
> tracking
> disabled) - but not for the reasons you've given.
>
> Since we started using ebtables we perform the equivalent of
> connection tracking in layer 2 for bridged frames and if the packet is
> an IP packet we let the firewall inspect it as well. That does require
> about 10% more CPU than straight IP routing without connection tracking.
>
> > 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.
>
> Why would you use RIP instead of OSPF? OSPF is far superior,
> supported on more platforms, and updated regularly. RIP is a dying
> protocol. We support both, but only use RIP with legacy gear that doesn't
support OSPF.
>
>
> Regards,
>
> Jeff
>
>
>
>
>
>
> 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/
>
> --
> 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/
--
WISPA Wireless List: wireless@wispa.org
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
