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