DBIUA Network Explained

I setup a test network in my garage last weekend, so we could test out some network changes we are going to make.  This was also a great opportunity to try and give those of you interested some more technical details about how we have things setup.

Here is a photo of the setup now on the wall of my garage.  This replicates just about all the different working parts of our network.

IMG_20170625_161006-2.jpg

And here is a youtube video explaining things.

EdgePoint Router

The DBIUA has been up and running for about 3 years now, and way back when we decided to use Ubiquity gear in our network for a various reasons, mainly their AirMax M5, M2, and M900 stuff.  We also used the 5 port toughswitch in all our relay point locations.

As time has gone on, Ubiquity has continued to evolve their product line.  And my new favorite product is the EdgePoint Router, specifically the EP-R6.  It is just a little larger than the toughswitch we are using in our relay boxes, but it’s so much more capable than the toughswitch, and will allow us to rework our network to make it much easier to manage.

ubiquiti-edgepoint-route_10807.jpg

We are in process of switching out (ha, ha) all the toughswitches with EdgePoint Routers over the summer and doing some work to simplify our network so we don’t have to program manual routes in all our radio’s.

As part of this change, I’m setting up a test network in my garage to be able to try out the different settings we will need to modify, so we can make sure we don’t accidentally brick a radio that is up in a tree when we do the real updates.

Once I get this network up and running, I will post again here showing the test network, which will give you an idea of all the pieces and parts you need to build out your own network.

No Fee Month!

JUNE 2017
is DBIUA’s first
“NO FEE” MONTH
That’s right. No monthly fees in June! The association has enough money in the bank to pay June’s expenses. And enough in our Reserve Fund to cover any “what-ifs.”
Our expenses so far this year have come in much less than budgeted. The weather, while wet and cold, was a non-event for DBIUA. No major equipment problems. No tree climbs. No downed limbs. Our system just hummed right along.
Our hope is for more non-events. Which will mean additional “No Fee” Months for our members.
For those few of you who mail your payments by check, you won’t receive a June bill from DBIUA, so please DON’T send a payment for June.
 
For those that pay for several months at a time, we will give you a credit on your account.
For members who pay automatically by credit card, you won’t see a June payment to DBIUA.
Congratulations for being a member of such a well run, buttoned-up, lean-and-mean, member-owned, volunteer-operated, local nonprofit Internet provider!

No New Members

In August, the DBIUA board decided to stop accepting new members, and those members who were still on the waiting list, we decided to refund their membership fee and not connect them to the network.

We came to this decision for a couple of reasons.

First, while we have been working on our redundant connection with Rockisland, we learned that they are putting in one of their LTE poles over on Blakely.

You may have seen these around in other locations, like at the Obstruction Pass power station, by their offices in Eastsound, over by the transfer station, and at other locations around the county.

These LTE poles are providing T-Mobile cell service as well as providing fixed LTE wireless internet from Rockisland.

This new pole on Blakely should be able to service all of the people on our waiting list.

The other reason we have decided not to expand our membership is our volunteer labor (mostly me- Chris Sutton), does not have enough time to deal with the existing membership and network, let alone install new members.

This doesn’t mean we will be shutting things down and closing up shop. It just means we will be spending our time keeping the current system running.

Billing System

One thing I have not touched on yet is what we use for billing our members, accounting, etc.

My day job is doing software development (http://smalldognet.com), and one of the products I created is software to run community foundations.  This includes a full blown online fund accounting system, credit card processing, customers, donors, AR, AP, checks, etc, etc.

So, I already had software we could use to keep the books, all I needed to add was an “ISP” module that tracked the different radio’s, determined if a radio was backbone equipment, or member equipment.

smalldognet.png

The DBIUA Network module keeps track of everything, helps with the programming of the radio’s, and also feeds the nagios monitoring system.  When we add someone new to the DBIUA Network module, this automatically gets pushed out to nagios.

smalldognet2.png

This system tracks the location of everything as well (latitude/longitude), and so we can also spit out a physical map of the network and how everything is connected.

smalldogmap.png

The best part of this is really the automatic billing each month.  My software is already setup to integrate with Stripe payment processing (http://stripe.com), and so we have a page where members can login, and give us a credit card.  This is not saved in our system, but instead is saved over at Stripe.  At the first of each month, I press a button that automatically creates invoices for everyone.  Then another button charges everyones credit card using the data saved at Stripe.

I’m sure some of you are thinking, this would be really cool to use for your own WISP.  Maybe you are using Quickbooks or something and your monthly billing is a total PITA.  For now, you will have to continue to suffer, but maybe in the future I will figure out how to make this available to others as well, but right now it is very DBIUA centric.

 

Line Loss

In my prior post, I talked about troubleshooting power issues.  And this past week we had another problem with out system that turned out to be power related again.

At our relay points, one of the difficulties is figuring out where the closest AC power is, and how to get from there to where we need our radios to live.  Generally this distance is not very far.  But in a couple cases it’s a long ways, like with the relay point in the middle of Tom’s field.  In this case we trenched the 120v AC power all the way to the relay point.

In another case over at Jim Nelson’s point, we had to run 200 feet from the closest house, out to a tree on a point, and instead of bringing 120v AC out to the tree, we ran the power over POE the 200′.

At first we only had 2 radios at this relay point, and everything worked really well.  Eventually we added a 3rd radio, and most recently we added a webcam.  Adding the webcam pushed everything over the edge and suddenly everything at that relay point was rebooting over and over and over.  WTF?

Well, there is this thing call line loss, when transmitting power over certain distances.  Here is a great little webpage and helps you with those calculations.

http://www.calculator.net/voltage-drop-calculator.html

So, we are transmissiong 24v DC power, 200′, and we are using Ubiquity Carrier Class ethernet cable, which has 24 AWG wire.  And POE uses 2 pairs to carry the power.

The last thing we need to fill in is amps.  When we had 2 radios, each using 8 watts, that means about 0.4 amps (8 watts/24 volts) per radio.

Plugging all this into our calculator shows we end up with just short of 20 volts at our radios.

Adding the 3rd radio (and amps up to 1.2), we fall to just shy of 18 volts, and adding the webcam we are under 16 volts, at which point things obviously started failing, probably the touchswitch that all this was plugged into.

So, our solution was to turn off the webcam to get everything running again, and then to order a bunch of 12/2 outdoor landscape lighting cable, and use that to bring the 24v power out to the relay point.  Plugging in 12 AWG wire into our calculator across 200′ and 2.5 amps (the max the power supply will put out), gives us 22 volts at the relay point.

So, if you are running more then a couple of radios across a long distance POE link, you really need to do something different for power because that tiny 24 AWG wire just doesn’t cut it for high power needs.

Troubleshooting

Computers and the networks they us to communicate with each other are complex things, and from time to time, things stop working, or don’t work as well as they used to, and you have to figure out why.  Troubleshooting is a bit of an art, and in this post, I will go over various troubleshooting stories, and how to try and avoid rebuilding things from scratch when you just forgot to check a checkbox on some configuration screen.

The most important part of troubleshooting is knowing there is a problem in the first place, and having as much information as possible to help figure out what is wrong. You need a system that is checking your entire network and can alert you when something goes wrong. We have installed Nagios, which is an open source network watchdog program. This checks all our backbone radios and routers every 5 minutes. Individual member endpoints are checked every 15 minutes. So, if a radio goes down, Nagios will alert us to this fact when it happens.

When you are alerted to a problem, the next useful piece of information is to be able to see what may have been happening in the past. And for this we have another system installed called Cacti, which is another open source data logging program. This system checks every router, radio and member router every 5 minutes, and logs how long it takes to contact (ping time), how long the system has been up (uptime), if it’s a radio, it records the signal and noise values as well as raw bitrate. It also records how much data has been transfered recently (bandwidth). All of these metrics are very useful in troubleshooting any problems. And without these two systems, we would really be working in the dark when something went wrong.

Start with the basics

When we see a radio go down, the first thing we first try and confirm if there is power to the radio. Lack of power is way more common than many people realize.

We have battery backups on all our backbone radios, so sometimes the power loss happened several hours before. One case is the infamous sheep. When we were first building things out and installing one of our relay points in the middle of Tom’s field, we had a temporary extension cord running out into the field to power our relay point. In the middle of the night we got an alert that “tillman-pb-5-a” was down. In the morning we went out to the field, and found that the extension cord was unplugged, and apparently a sheep had scratched up against it during the day and unplugged it, and so then about 8 hours later, the battery died, and the radio went offline.

Another time, we got an alert that “shipstad-ar” was down. This is a member wifi router, and I knew that this was probably not on a battery backup. The rest of the equipment at the Shipstad’s was still up, but my gut said it was now on battery backup. In calling to the Shipstad’s house, I found out that they were doing something in the garage and had popped a breaker turning on a heater or something. This had turned off the wifi router, and this had also stopped sending POE power to the rest of the relay point equipment at that location. It is this type of event where we are working on being able to monitor grid power at our relay points, so we know if there is a power problem and we are on battery backup.

Sometimes the power problems are not lack of power, but not enough (meaning not enough amps).

Early on in building out our network, I put 3 radios up in one of my trees, two nanostations, and one rocket. To make life easy, I ran one wire up the tree. Nanostations have 2 network plugs and allow you to daisy chain another device. Down on the ground, I tested running one POE cable into a nanostation, then on the secondary port, running another cable to the 2nd nanostation, then from the secondary port on that radio, into the rocket. Everything turned on and lit up and I was able to login to each radio on the one wire.

But, when it all went up in the tree, and we started running traffic over the radios, everything started rebooting. Well, turns out you can only daisy chain once, and when the radio started sending traffic it started pulling more amps than was available, and so things rebooted. So, the lesson on that was to run one wire for each radio up the tree.

But, there was another location where we only needed to have 2 radios in the tree and this worked well, even under load. We needed to add a 3rd radio in that location, which meant we needed to install a touchswitch, instead of running the 2 radios directly from the Tycon Power charge controller directly. So, we switched the 2 radios to one port on the toughswitch, and the 3rd radio to another toughswitch port. Then we started to get random alerts that the 2 radios where going down. Turns out you can’t run a nanostation chained to another radio off a single toughswitch port. So, we ran a dedicated wire to each radio and each had their own port on the toughswitch.

After you have made sure there is power to a location, you next should check that there is not a problem with the physical wire that carries the power to the radio.

We had one time when a radio went offline, and what happened was a small branch came down, and must have hit the ethernet cable, and the cable was not completely “clicked” into the network port on the back of the radio, and so the cable popped out.

There were several times when even though the radio had power lights and was connecting upstream, downstream on the network packets were not flowing. This was usually a problem with the crimping of the cat5 end. I had one of these recently, and even though I have done hundreds of these end crimping connections, every once in a while I’m not paying attention, it’s a little dark, or i’m taking to someone, and one wire goes in the wrong place. Then things either don’t work, or they half work.

One time we had a faulty POE power brick, where the little wires in the brick that are sprung to connect tightly to the cable end, where stuck, and only completed the connection if you pushed the cable end into the POE brick really hard. This was the intermittent power problem.

Then we just had another case where a member had a faulty powerstrip, that if you touched it wrong, it would turn off the power.

After confirming all the power related issues, we then get to the programming of the radios….which will be another post because this one has gotten really long.