The changing RF landscape for WISPs

Recently, there have been some discussions on Facebook about waining support for 2.4GHZ .  KP Performance recently published a Future of 5GHZ and beyond blog post. So why all this focus on 5GHZ and why are people forgetting about 2.4?

To answer this question, we need to update our thinking on the trends in networks, not just wireless networks.  Customers are demanding more and more speed. Network backbones and delivery nodes have to be updated to keep up with this demand. For anything but 802.11 wifi,2.4GHZ can’t keep up with the bandwidth needs.

One of the significant limitations of many 2.4 radios is they use frequency-hopping spread spectrum (FHSS) and/or direct-sequence spread spectrum (DSSS) modulation. Due to 2.4GHZ being older, the chipsets have evolved around these modulation methods because of age.  When you compare 2.4GHZ to 5GHZ radios running OFDM, you start to see a significant difference.  In a nutshell, OFDM allows for higher throughput. If you want to read all about the differences in the protocols here ya go: http://www.answers.com/Q/Difference_between_ofdm_dsss_fhss

Secondly, is the amount of spectrum available.  More spectrum means more channels to use, which translates into a high chance of mitigating interference. This interference can be self-induced or from external sources. To use an analogy, the more rooms a building has, the more simultaneous conversations can happen without noise in 2.4GHZ we only have 3 non-overlapping channels at 20mhz. Remember the part about more and more customers wanting more bandwidth? In the wireless world, one of the ways to increase capacity on your APs is to increase the channel width. Once you increase 2.4 to 30 or 40 MHz, you do not have much room to deal with noise because your available channels have shrunk.

One of the biggest arguments in support of using 2.4GHZ for a WISP environment is the physics.  Lower frequencies penetrate trees and foliage better. As with anything, there is a tradeoff.  As the signal is absorbed, so is the available “air time” for transmission of data.  As the signal travels through stuff, the radios on both sides have to reduce their modulation rates to deal with the loss of signal.  Lower modulation rates mean lower throughput for customers.  This might be fine for customers who have no other choice.  This thinking is not a long term play.

With LTE especially, the traditional thinking is being uprooted.  Multiple streams to the customer as well as various paths for the signal due to antenna stacking are allowing radios to penetrate this same foliage just as well as a 2.4 signal, but delivering more bandwidth. These systems are becoming more and more carrier class.  As the internet evolves and becomes more and more critical, ISPs are having to step up their services.  The FCC  says the definition of broadband is at least 25 meg download. A 2.4 radio just can’t keep up in a WISP environment.  I am seeing 10 meg becoming the minimum customers want. Can you get by with smaller packages? Yes, but how long can you maintain that as the customer demand grows?

So what is the answer? Cell sizes are shrinking.  This is helping 2.4 hold on.  The less expensive radios can be deployed to less dense areas and still provide decent speeds to customers.  This same trend allows 5GHZ cells to be deployed as well. With less things to go through, 5GHZ can perform in modern networks at higher modulation rates.  Antenna manufacturers are also spending R&D to get the most out of their 5GHZ antennas. More money in the pipeline means stronger products. My clients are typically deploying 3.65 and 5GHZ on their towers.  LTE is changing RF WISP design and taking the place of 2.4 and 900.

Mikrotik Router OS 6.46.2 is out

Notables from the changelog of Mikrotik RouterOS 6.46.2

*) console – prevent “flash” directory from being removed (introduced in v6.46);
*) crs305 – disable optical SFP/SFP+ module Tx power after disabling SFP+ interface;
*) defconf – fixed default configuration loading on RBwAPG-60adkit (introduced in v6.46);
*) lora – fixed packet sending when using “antenna-gain” higher than 5dB;
*) lte – fixed “cell-monitor” on R11e-LTE in 3G mode;
*) lte – fixed “earfcn” reporting on R11e-LTE6 in UMTS and GSM modes;
*) lte – report only valid info parameters on R11e-LTE6;
*) qsfp – do not report bogus monitoring readouts on modules without DDMI support;
*) qsfp – improved module monitoring readouts for DAC and break-out cables;
*) security – fixed vulnerability for routers with default password (limited to Wireless Wire), admin could login on startup with empty password before default configuration script was fully loaded;
*) system – fixed “*.auto.rsc” file execution (introduced in v6.46);
*) traffic-generator – improved memory handling on CHR;
*) winbox – fixed “Default Route Distance” default value when creating new LTE APN;

Full changelog at
https://mikrotik.com/download

IPV6 Point-to-point addressing

Recently, there has been a discussion on what to use for point-to-point links under ipv6. Over the years I have seen providers use a wide variety of subnets across a point-to-point link.  Anything from a /64, to /122,124, and the 127. There are arguments for each. But let’s look at some RFCs.

https://tools.ietf.org/html/rfc6164
This was the original RFC on point-to-point links advocating for a /127. It was moved to a “historical” status in 2012 after a /127 was found to be damaging.

https://tools.ietf.org/html/rfc3627
This RFC explains some of the issues with using a /127. In a nutshell.

 Using /127 can be especially harmful on a point-to-point link when
   Subnet-router anycast address is implemented.

All of this brings us to some current RFC drafts and further reading
https://tools.ietf.org/id/draft-palet-v6ops-p2p-links-00.html

Some notes on point-to-point addressing
1. A subnet mask using something shorter than a /64 breaks some IPv6 functionality. A point-to-point link does not use the “broken” features anyway.

  1. The above 6164 RFC said vendors had to support /127s.  Many wrote code to comply with the RFC, which has now been obsoleted.
  2. A /64 could expose the link to security issues.

As of this writing, there are many approaches.  One approach is to set aside a /64 for the point-to-point but only use a /127 out of that /64.  You don’t re-use anything else out of that /64.  Other approaches involve using a  /126, /120 or a /112 are being accepted until this is all figured out.  So, why not a /122 or something? In short, it all has to do with the math of the subnet breakdown.

Whats new in CentOS8?

  • Cockpit web console is available by default in CentOS 8.
  • Support for up to 4PB of physical memory.
  • Nginx 1.14 is now available in the core repository.
  • PHP version 7.2 is the default PHP version.
  • Python 3.6 is the default Python version.
  • Wayland is the default display server.
  • nftables has replaced iptables to be the default network filtering framework.
  • XFS now has support for shared copy-on-write data extents.
  • RPM 4.14 (as distributed in RHEL 8) validates package content before installing.
  • A new version of YUM based on DNF which is compatible with YUM 3 (as is in CentOS 8).
  • Content is channeled through 2 main repos: BaseOS and Application Stream (AppStream).
  • The brand new CentOS Stream

Entry Level I.T.

The folks over at Webhostinggeeks.com have a good post on an Open letter to entry level IT Employees.

The world of IT can be unforgiving, especially for those just starting out. The keys to finding and maintaining success are humility, patience and an open mind.

You’ve graduated and prepped, perhaps you’ve even collected some certifications, and you’re now ready to take that first step into the corporate IT world as an entry-level IT employee. These first steps can be a challenging, but not just from a technical standpoint.

Read more here..

Antenna patterns and interference

This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
To view this content, you must be a member of Justin Wilson's Patreon at $0.01 or more
Already a qualifying Patreon member? Refresh to access this content.

Everything you wanted to know about NTP

Network Time Protocol (NTP) is a service that can be used to synchronize time on network connected devices.   Before we dive into what NTP is, we need to understand why we need accurate time.

The obvious thing is network devices need an accurate clock.  Things like log files with the proper time stamp are important in troubleshooting.  Accurate timing also helps with security prevention measures.  Some attacks use vulnerabilities in time stamps to add in bad payloads or manipulate data. Some companies require accurate time stamps on files and transactions as well for compliance purposes.

So what are these Stratum levels I hear about?
NTP has several levels divided into stratum. All this is the distance from the reference clock source.  A clock which relays UTC (Coordinated Universal Time) that has little to no delay (we are talking nanoseconds) are Stratum-0 servers. These are not used on the network. These are usually atomic and GPS clocks.  A Stratum-0 server is connected to time servers or stratum-1 via GPS or a national time and frequency transmission.  A Stratum 1 device is a very accurate device and is not connected to a Stratum-0 clock over a network.  A Stratum-2 clock receives NTP packets from a Stratum-1 server, a Stratum-3 receives packets from a Stratum-2 server, and so on.  It’s all relative of where the NTP is in relationship to Stratum-1 servers.

Why are there levels?
The further you get away from Stratum-0 the more delay there is.  Things like jitter and network delays affect accuracy.  Most of us network engineers are concerned with milliseconds (ms) of latency.  Time servers are concerned with nanoseconds (ns). Even a server directly connected to a Stratum-0 reference will add 8-10 nanoseconds to UTC time.

My Mikrotik has an NTP server built in? Is that good enough?
This depends on what level of accuracy you want. Do you just need to make sure all of your routers have the same time? then synchronizing with an upstream time server is probably good enough. Having 5000 devices with the same time, AND not having to manually set them or keep them in sync manually is a huge deal.

Do you run a VOIP switch or need to be compliant when it comes to transactions on servers or need to be compliant with various things like Sox compliance you may need a more accurate time source.

What can I do for more accurate time?
Usually, a dedicated appliance is what many networks use.  These are purpose built hardware that receives a signal from GPS. the more accurate you need the time, the more expensive it will become.  Devices that need to be accurate to the nanosecond are usually more expensive than ones accurate to a microsecond.

If you google NTP Appliance you will get a bunch of results.  If you want to setp up from what you are doing currently you can look into these links:

http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

How to Build a Stratum 1 NTP Server Using A Raspberry Pi

 

Building a Stratum 1 NTP Server with a Raspberry Pi

 

Cambium PTP 550 Data Rates

Some info on the cambium PTP 550 Data Rates

“Downlink Max Rate” specifies the maximum downlink MCS value that the Rate Adapt algorithm will choose.
MCS values range for data from MCS 9 to MCS 1 for one or two Spatial Streams (Single Stream and Dual Stream respectively). A higher MCS value (e.g. MCS 9) carries more data, but requires more link budget / stronger radio signal. Thus, MCS 9 provides the most data, but the least robust link (i.e. greatest chance data can be lost) and MCS 1 provides the least data, but the most robust link (i.e. least change data can be lost).
DS MCS provide two streams of independent data over the two transmit chains while SS MCS provide one stream of data over both transmit chains.
Setting “Uplink Max Rate” to a DS MCS 9 – DS MCS 1 value will allow this MCS and all lower dual stream MCS values to be used along with all similar or lower single stream MCS values. For example, choosing DS MCS 8 means that DS MCS 8 – DS MCS 1 and SS MCS 8 – SS MCS 1 will be used in the Rate Adapt algorithm. Setting “Uplink Max Rate” to an SS MCS 7 – SS MCS 1 value will allow this and all lower single stream MCS values.

Rates Highest to lowest
DS MCS9 – 256-QAM 5/6
DS MCS8 – 256-QAM 3/4
DS MCS7 – 64-QAM 5/6
DS MCS6 – 64-QAM 3/4
DS MCS5 – 64-QAM 2/3
DS MCS4 – 16-QAM 3/4
DS MCS3 – 16-QAM 3/4
DS MCS2 – QPSK 3/4
DS MCS1 – QPSK 1/2
SS MCS9 – 256-QAM 5/6
SS MCS8 – 256-QAM 3/4
SS MCS7 – 64-QAM 5/6
SS MCS6 – 64-QAM 3/4
SS MCS5 – 64 QAM 2/3
SS MCS4 – 16-QAM-3/4
SS MCS3 – 16-QAM 1/2
SS MCS2- QPSk3/4
SS MCS1 – QPSK 1/2

MCS\Rx Sensitivity  20 MHz       40 MHz       80 MHz
Lowest MCS          -90 dBm     -87 dBm       -83 dBm
Highest MCS .       -66 dBm     -62 dBm        -59 dBm