Client routers after bridge CPE, What works and what doesn't

[gunther_01]

The main question for this is what works and what does not. I recently was told by a distributor of my CPE that the Linksys has all kinds of problems with their units. They said that D-link works best for them.

If that is the case. I was wondering, if you are willing to share. What kinds of routers do you provide/suggest and what configuration do you use? i.e. router settings PPPoE, DHCP or static IP. And most importantly does it work and is it SOLID. This would be a great place for us all to figure out what and why things don't work like they are suppose to.

[titan_wireless]

We used to use Linksys routers with no issues on a bridged network. Dlink worked well for us, but Linksys seemed to perform better with DHCP requests. Now we use WRAP based CPE's and there is no need for a client router. The customer does not get control of the router, but its more stable that way for us.

[lonnie]

I Echo the thoughts on using WRAP for CPE. The design you are taking uses a client bridge, but it is not a true bridge so it has trouble, so you have to add a router to "fix" it up.

Add it all up and you are not saving very much money BUT you are adding a lot more complexity and you still do not have the control you would have with a WRAP board running StarOS. By the time you fool around with it and have a few "issues" you would have been much better off to have gone with a bit more money but simpler and more reliable solution.

But, hey if you enjoy contact with the subscriber, don't change just to make me happy.

[gunther_01]

Here is what I have working so far. We use a WRAP with prism for ap.

client devices include. And I should add, The routers are my customers additions

1 High Gain antennas 2400/b radio device, Working like a champ with built in PPPoE,NAT router and DHCP server on ethernet for client. (Primary use was for a single computer home/location)

2 High gain antennas 1100 series (cb-3?). Dislike the software a lot. Bridges go to two different linksys routers that didn't like to stay alive with PPPoE. Both set for static IP's now. Work Fine.

2 High gain antennas carrier class 2400 b/g in bridge mode going to a d-link running PPPoe (solid so far about a week 400mb) and a Linksys that I made static since PPPoE wouldn't hold.

I currently have some signal interference that I need to resolve. That is/was the culprit with PPPoE. I wouldn't lose association but would lose enough signal to maybe miss the three PPPoE pings and the client was gone. The 1100 radio would not let the routers sync back up with out a reboot. The new Carrier 2400b/g will.

I personnaly didn't like the DHCP method. Couldn't centralize the server. One linksys would not stop trying to get an IP even thought it had one, another linksys worked fine but I could not tell if it was still hooked up or not very easy. (a DHCP client listing would be nice: Hint) So my resolution- "static IP" it is there after client reboots, power fluctuations, it just works. Takes a little more time initially but not near the time I was spending on the other crap.

For me and my small town people. Why in the world, or how I should say, would I want to force my clientel to use only my equipment in their homes, businesses or wherever. Fact is, around here If all I put in was an Ethernet jack I would still have a linksys or d-link plugged in to it weather I wanted it plugged in or not. I choose to use a CPE device (HGA 2400b/g)that frankly has issues, but is a router,bridge,bandwidth controller, DHCP server or client, Port fowarder, PPPoE client with a nice gui and a host of other things in a nice enclosure for $209.00 and that is 1 unit pricing. I like Star or I wouldn't be using it but why do I need to use it for a CPE for my system to work? It's not like I am the only one out there using this device or even this kind of device. If you (Lonnie) had a $200 stripped down, SIMPLE GUI (web based preferably) good looking CPE, I WOULD BUY IT. It has taken me over a year to be confident enough with star and linux to even try and start my WISP. There is no way I could train a decint installer to configure one on site, and have it work the way I wanted.

When a customer wants thier linksys or whatever for the home network that is what they want, I don't have the option of arguing, denying or anything else. I put it in... I have to make it work or I don't get that customer. I am one of four WISPs covering the outlieing areas of this first town we built up. The only one located in this town, but not around this town. They don't have to go with me..And I need them to be my customer.
Man, what a rant. I gotta eat some dinner;)

[bradg]

Guther_01,

The biggest problem with not "forcing" customers to use your router (NAT or otherwise) that is primairly or totally under your control is that you lose any and all control over that network segment - God forbid it's a big bridged network. You've now lost the control and stability you could have had if they were using the (carefully selected) equipment you provided them and have control over ("forced" them to use).

If I understand your post right, I agree with your sentiment on a philosophical basis only. The cold, hard reality is that without some very strict control over your network (and what traverses it - and how it traverses it), once you have more than a handful of clients on it, you will find it a troublesome beast nearly 100% of the time.

The products available make wireless networks "easy" to construct and "get working". The harder lesson is understanding that just "getting it working" doesn't mean it's really "working", and an even harder lesson is that it can (and does) "break" in many more ways than you think.

I guess what I'm trying to say is if you're just starting out, don't consider giving up control of your network lightly - your QoS will fall to the dirt, and you will regret it later. I'm not saying you necessairly need WRAP's as CPE's, but you should make every attempt to control it right to the customer's network.

On competition, if your competitors don't have control of their networks, they have an inferior product. Price is one thing, but cheapest doesn't mean much if it doesn't work.

And, now that I've somewhat contradicted myself in regard to my earlier post about a quest for a cheaper CPE, I'll go back in the house and watch TV for a bit before bed :)

Brad

[gunther_01]

I can say at least we have a routed network up untill these bridge client devices. We do bandwidth control at the AP and edge. And part of the reason for PPPoE initially was to have an easier way to set-up the customer radio and for authentication reasons. It is unfortunate that all of these devices don't work well "together". I would much rather have complete control over everything but I can't. So with that said I control what I can, and give up what I can't. Some of our competition uses Canopy (Speednet), others just use pci cards on the custumer computer, and some bridge devices for the multiple computers in a household. Heck some of them let you buy your own Client device of your choosing and install it yourself, Not here, No way...

We use a mix as well, our lowest price teir mandates our CPE with NAT router built in with PPPoE to a public IP. So at least the individual computer does not have a bridge directly to our AP, it is on it's own subnet. We use the same radio (trying to) for all installs so if a customer has a single computer regardless of speed package they have NAT'ed subnet at the premise always. We NAT at the premise for all installs one way or another. But as most are seeing I imagine, everybody has more then one computer in the household now a days. I tried to start this system up with it being as solid and stable as I could, reading everything I could get my hands on. In the process getting A+ and Network+ certified. It has been an interesting and learning experience only to be more challanging everyday, I love it..

The biggest problem is being the "Start-UP", I have not learned the things that arn't tought. The little things that add up I suppose, and the fact that things don't always work how you designed them. Mainly cause I didn't design the individual components that need to work together. I understand there will always be something, but after all the reading and experimenting to implementing. It pisses me off that things don't work like I think they should, it's all simple stuff, just agrevating to get off from my full time job, get home to find out a problem came back again with authentications, interference or whatever. Two weeks after we opened up, the main AP antenna broke in half, ya know, things like that. The stuff that really should not happen but do. Oh well another 18 hour day and time to "try" and go to bed.

[bradg]

It's at least a relief to hear you're not running the "big piece of wire" bridge setup! That issue right there is at least half of the battle IMHO, and you've started out on the right foot. Bravo!

I fear that this is going to go way OT, but here it goes anyway...

The biggest problem with enforcing QoS is that you can control what enters your network from the Internet (outside), the speed to your customer, etc at the "edges". But, what you give up is the control over what your customer puts "into the air" at your AP.

At first glance, you may not think that's a problem because you can control it at the AP (which is better than nothing and better than many do). However, there are cases (been there, done that) where even that isn't good enough - you really need to try to control the data as it leaves the customer's CPE, before it even sees the "air".

TCP can be effectively throttled any where in the data path because it is a stateful protocol - when packets start being dropped, the protocol will start to slow transmission to compensate until reliability returns, and all of this happens at the protocol level without the software application's intervention.

UDP (most times) does not respond to this type of traffic control measure (unless it's implemented in the application somehow), and the application will continue to send packets as fast as it likes, with traffic effectively being slowed only after the point of control.

You can quickly find your AP segment a cyber free-for-all, having very low to no throughput at all - quality of service destroyed (often by a single customer totally unaware of the problem).

Also, let's take NetBIOS for example. I don't allow traffic to those destination ports anywhere on my network (whenever possible). It's fine to filter that at the AP before it hits the backhaul, but what about from the customer to the AP? If it's merely filtered at the AP, the customer can still attempt to access those ports, and packets doing so are transmitted from the CPE to the AP, slam into the firewall rule and die. In the process, you've used one/many (thousands/hundreds of thousands/millions in the case of an infected zombie client) radio frames for *nothing* - those frames were a complete waste of segment bandwidth, resources, AP horsepower, and QoS. And, those resources could have been used (or needed) to provide other AP customers with high quality service. One thing to remember - radio frames/packets are a finite resource per second, so it's wise to not allow them to be wasted needlessly if possible.

I'm not ranting, just trying to point out why control at the CPE is a "good thing". And, I do understand the pricing issues involved. The point is that if you can afford an extra few dollars up front, it could save you one/several "truck rolls" later on. When you're just getting started, I do understand that it really difficult to do - an occasional truck roll (by you I'm assuming) seems to be a decent compromise to save some cash. But later on, as you grow, a few calls can turn into dozens, and then it won't seem like a decent tradeoff. The problem at that point is that you've got so many of the current CPE configurations deployed that it would cost a fortune in both time and money to re-tool them all into something less problematic, so the solution is to re-tool the customers who you think or have identified as "problem children" and hope for the best.

And, yes, I've seen this *exact* scenario as I've been slowly unraveling my sister company's "big piece of wire" bridged network and dozens upon dozens of "PCI card in the client PC with the 75 foot LMR400 run-of-shame" network. A process that's taken about a year and a half, many thousands of dollars in equipment, and several hundred hours of my time in the process - and it's still not what it "should" be, but about four orders of magnitude better than before. In retrospect, had I been less of a nice and loyal guy, I would have demanded a King's Ransom for it - and will if I ever have to do it again.

I'm not trying to be a jerk or harsh at all, I'm just tying to help you understand some of the tradeoffs I've seen is all. I just hope they're of value to you (or someone).


Brad

[gunther_01]

Every post, forum, book, video, or real life experience I hear is of value to me. Thank you for your insight on this and I plan to at least look into throttling at the CPE as well. I'm not sure about protocols (which I can firewall with my CPE) but I may change some of that as well. At least I can do some of the things that Star can do. Maybe not as well, but at least can try.

[titan_wireless]

Bradg,

BRAVO! I have had that speech with many customers. Very well put. I have gone through the growing pains of Bridged vs. Routed as well in the past. Lonnie had told me many times to do it right and I was always short sighted at the price of a WRAP CPE and a routed network vs. a bridged CB3 network.

I will bookmark this thread to share with others. :)

Later,
Tasos..

[gunther_01]

So I guess for the sake of clarification. If I am routed all the way from WAN to AP. It's a routed network.. If I am routed to the AP have an IP of 10.1.0.1 on WPCI1, the client radio has 10.1.0.2 and has a built in router with NAT for a different subnet for client computers, then that is a true and full routed network right.

But using the same routed backhaul, same IP on AP, except this time I use a bridge radio with a 10.1.0.2 IP going to a seperate router with an IP of say 10.1.0.3 with NAT and a different subnet for the client, that is a bridge network?

I ask since this thread became the bridge vs. routed /QOS thread ( which is fine and valuable reading:)) but It seems to me I am using a routed network. I just have a bridge in the middle of my last mile. Now, what is so terribly wrong with that. If things are routed on both sides of the bridge

Customer LAN is on own private subnet, my stuff is routed all the way through. I realize I am not using a /30 per customer PtP link, but how is it that bad? And is a /30 what I would have to do in order for it to be the "best" method?

[bradg]

So I guess for the sake of clarification. If I am routed all the way from WAN to AP. It's a routed network.. If I am routed to the AP have an IP of 10.1.0.1 on WPCI1, the client radio has 10.1.0.2 and has a built in router with NAT for a different subnet for client computers, then that is a true and full routed network right.

But using the same routed backhaul, same IP on AP, except this time I use a bridge radio with a 10.1.0.2 IP going to a seperate router with an IP of say 10.1.0.3 with NAT and a different subnet for the client, that is a bridge network?

I ask since this thread became the bridge vs. routed /QOS thread ( which is fine and valuable reading:)) but It seems to me I am using a routed network. I just have a bridge in the middle of my last mile. Now, what is so terribly wrong with that. If things are routed on both sides of the bridge

Customer LAN is on own private subnet, my stuff is routed all the way through. I realize I am not using a /30 per customer PtP link, but how is it that bad? And is a /30 what I would have to do in order for it to be the "best" method?

If I understand your configuration right, yes, you have a "routed network". And, no, your network configuration is not bad :)

A "routed network" refers to each network segment (which is a group of connected hosts sharing the same medium) being assigned a separate, non-overlapping subnet of IP's (all hosts sharing the same range of IP's and subnet mask), and data is routed (routing table examined, appropriate next hop selected, etc) between segments (which appear as hops in a traceroute) to reach it's destination.

In your case, since all connected wireless clients are using the same physical interface and transmission medium, having a single subnet assigned amongst them is very typical of the networking world in general (one subnet per interface, VLAN, SSID, etc).

You could do multiple PtP subnets to each customer, but it really wouldn't make much sense, or have much (if any) technical advantage in most cases. In the end, unless you have a very specific purpose and problem to solve, it will only serve to make routing way more complex and record keeping more of a chore.

A "bridged network" generally refers to multiple interfaces connected together (bridged) to appear to the network as one medium. In the WISP world, this typically ends up being several AP's (maybe the whole network - shudder) that are all bridged/chained together as one flat network, appearing as one - a "big piece of wire" so to speak. All clients and interfaces everywhere on the network usually share the same subnet, and traffic flows from point to point based on MAC addresses. Broadcasts are seen in every corner of the network, ARP issues abound, rogue DHCP servers drive you insane, it very quickly turns into a *massive* mess.

The fact the the AP is assigned one subnet with multiple clients connected doesn't make it a "bridge" - it's one interface and medium with multiple hosts is all, a network segment.

Hopefully that makes some sense. In review - you have a routed network, don't worry. I would have thrown in somme ASCII art, but I suck at it (not to mention it'd be quicker for me to draw it and post the graphic), so you're stuck with textual descriptions for now. If it didn't make sense, let me know and I can take some time to draw up some simple diagrams and post them.


Brad

[gunther_01]

That's kinda what I thought. It seemed as though people thought I was using a bridged network. I didn't think I was. At least that was my hope anyway.