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.
The following is an estimate of loss using LTE frequencies and common building materials.
-6″ Concrete 12-20 dB
I have been working on this list for a while. The following are vendors, manufacturers, and various companies I have dealt with in my career as an ISP owner and consultant. This is not a complete list by any means. These are companies I have dealt with personally and/or are sponsors of this site. Companies with the are ones that support this blog and I personally recommend. I don’t recommend them just because they support this blog, but because they provide a good product or service. If you would like to be included on this list please contact me as I am working on more detailed lists per category. This is a starting point for those looking to narrow down some focus of their research.
Texas-based distributor carrying a big number of product lines such as Cambium, Mikrotik, Airspan, and many others
Chicagoland based distributor carrying product lines such as Mikrotik, Cambium, and others.
Distributor of fixed wireless and telecommunications infrastructure for Internet Service Providers (ISP’s), Cable Operators, Telephone Companies
Mature billing solution which can
manage all aspects of your ISP.
Modern Billing software with many backend automation
Automation and control of your WISP customers
More Billing providers can be found at xISP billing platforms
LTE and CBRS based solutions
Manufacturer of fixed wireless products such as EMP, 450, and cnPilot wireless.
Manufacturer of Mikrotik routers and RouterOS routing and switching products
Manufacturer of WISP and WIFI products. Product lines include AirFiber and Unifi.
Training and equipment to keep climbers and companies compliant and safe. Large selection of needed items such as Harnesses and rope related items for tower work.
True IP Solutions
Unified communications solutions integrated
with access and camera solutions.
mikrotik training and certification as well
as consulting and integrations solutions
Training on Mikrotik and distributor of related products
More info on training for the xISP
RF Mapping and Modeling for tower sites and customer pre-qualification
Radio Mapping, two-way radio, mark study information, and Municipal broadband.
Microwave and Millimeter Wavechannel procurement.
Organizations, web-sites, and groups
Trade Organization supporting Wireless Internet Service Providers=
Networking, ISP, and related topics
Did I forget you? Would you like to sponsor this blog and your name listed? Contact me for more information.
Recently I came across a need to do some port forwarding for wifi calling. I have assembled a resource guide to help you if you need to do such things. IPSEC should be allowed per RFC 5996 https://tools.ietf.org/html/rfc5996 for all wifi calling
UDP ports 500 and 4500 open to sg.vzwfemto.com and wo.vzwwo.com
IPv4 Address Block: 18.104.22.168/17 and 22.214.171.124/19:
UDP Ports 500 and 4500
5061 for SIP/TLS
TCP port 443 and 993
Also whitelist the CRL server for DIGITS OTT and WFC 1.0: crl.t-mobile.com 126.96.36.199
UDP Ports 500 and 4500
TCP Port 143
Whitelist the following:
UDP Ports 500 and 4500
Any of the above is subject to change.
Over the past couple of weeks, I have been fighting with getting an LTE device running The Rooter Project to establish an OpenVPN connection with a Mikrotik router. Apparently, OPENVPN is the only option when it comes to VPNs on The Rooter Project. For the purpose of this article, I am going to refer to the software as “the rooter”. This is just to denote the device running The Rooter Project software. In my case, this is a GL.iNET GL-X750 LTE device.
There are two parts to this setup. The OpenVPN setup on the Mikrotik and the setup on the rooter.
The Mikrotik setup is pretty straight forward. There are some great tutorials out there for a more in-depth setup. The RouterOS version I used for this setup is 6.47.
You will need to create 3 certificates on the Mikrotik.
/certificate add name=ca-template common-name=example.com days-valid=3650 key-size=2048 key-usage=crl-sign,key-cert-sign add name=server-template common-name=*.example.com days-valid=3650 key-size=2048 key-usage=digital-signature,key-encipherment,tls-server add name=client-template common-name=client.example.com days-valid=3650 key-size=2048 key-usage=tls-client
Once you have created the above certificates you will need to sign them with the following
/certificate sign ca-template name=ca-certificate sign server-template name=server-certificate ca=ca-certificate sign client-template name=client-certificate ca=ca-certificate
Run the following commands to add a passphrase to your key certificate and export them to files
/certificate export-certificate ca-certificate export-passphrase="" export-certificate client-certificate export-passphrase=j2sw123com
This will give you three files:
cert_export_client-certificate.key. Download these out of “files” from the Mikrotik to the same computer you have access to the rooter on. I like to rename them to
client.key so I can keep track of what is what.
Rooter Client Setup
I could not find out how to make the operating system read a config file I would edit by hand. Even after a reboot, the config file would not be read. I am not sure if there is a command to read it into the running-config. If someone knows, let me know and that will make this process much easier.
client dev tun proto tcp remote example.com 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert client.crt key client.key remote-cert-tls server cipher AES-128-CBC auth SHA1 auth-user-pass redirect-gateway def1 verb 3
In my rooter, the config is in /var/etc. I would cat this occasionally to make sure I did not have any extra options turned on. Since I could not make my edits the file stick, I would make the below changes in the GUI and verify they matched up to my above file.
If your OpenVPN is using a username and password create a file named passowrd.txt and put the username on the first line and the password on the second.
You will need that file along with the three files you generate on the Mikrotik above.
Log in to the router and create you an open VPN instance. In my case, I named it Nexstream because this is who I was working for on this project. You can name it anything you want.
Click on edit and you will be brought to the following screens. Fill them out as shown.
When you get to the bottom this is where you upload your password.text and your cert and key files. If you see anything missing go to the bottom and select the field and click add.
Make sure to hit save and apply before proceeding. Click on “switch to advanced configuration”. Match up your configuration with the following screenshots, which match up with the above config file. You are just basically making the proper checkboxes to match the plain text config I posted above. Again, if anyone knows how to get OpenVPN. on the rooter to read the config in let me know.
Once you have the GUI part done and the certs uploaded to the rooter you will need to deal with the keyphrase via the command line. Simply SSH to the rooter. The below code is a generic code for changing the client.key to not ask for a passphrase anymore.
cd /etc/luci-uploads/ openssl.exe rsa -in client.key -out client.key Enter pass phrase for client.key: j2sw123com writing RSA key
Couple of things to note about the process.
1. Your location may vary. You must either be inside the directory with your keys or provide the path to the keys in the OpenSSL command
2.when I uploaded the keys it changed them to cbid.openvpn.FRIENDLYNAME.key.
what my actual code looked like to change the passphrase
cd /etc/luci-uploads/ openssl.exe rsa -in cbid.openvpn.vpnout.key -out cbid.openvpn.vpnout.key Enter pass phrase for client.key: j2sw123com writing RSA key
If everything goes well you will be rewarded with the following screen on your OpenVPN main page. If, for some reason, it does not start the system log is actually pretty informative on what is going on.
Mikrotik RBSXTR running RouterOS 6.46.6 on an AT&T sim card. Upload stats were in the 10-15 meg range.
I have been wanting to do some photos and thoughts on the Mikrotik SXTR-LTEs and other Mikrotik LTE products. I recently fired one up using dual sims. One is from Tmobile and one is from At&T. Verizon is pretty nonexistent in my area. I am about 2.5 miles away from a Tmobile tower and about a mile from a fiber-fed AT&T monopole.
As you notice in the following photo I am pretty buried in trees.
Some initial notes. Setup of LTE is a very easy process as far as the mikrotik is concerned. I literally had to put in some information in the APN and that was it as far as LTE goes. I did set up standard Mikrotik stuff (DHCP server, security, etc.).
Adding the second sim card can be a huge pain due to the location of the sim card slot. Luckily I had some tweezers that were angled to be able to slide the card in the slot. These were part of a dental kit I picked up off Amazon for releasing stuck SFPs and the like.
Look for a more in-depth series on Mikrotik LTE coming soon.
MME – Mobility Management Entity.
The MME is responsible for initiating paging and authentication of the mobile device. MME retains location information at the tracking area level for each user and then selects the appropriate gateway during the initial registration process.
The S-GW is responsible for keeping track of devices when they move between eNobeB’s. This is typically not an extra piece of hardware just a function of the EPC
This is what connects the LTE network to the Capital I Internet. This also is typically not an extra piece of hardware just a function of the EPC
The S1 interface is described in the 3GPP TS 36.410 specification.
The X2 interface provides connectivity between two or more eNodeBs.
As some of you may have heard Mikrotik has added in some VXLAN support in the latest RouterOS7 beta. What is VXLAN and how would service providers use it? Let’s start out with some broad information about VXLAN
The always interesting RFC read
This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers
Boil it down for me. What is vxlan?
In short, VXLAN allows you to create a layer2 network on top of a layer3 network. It allows you to bind separate layer2 domains and make them look like one. If you are thinking this looks like a GRE tunnel, you are correct except the layer2 domains are still separate with tunnels. VXLAN is mainly touted as a way to interconnect data centers. If you are having to use spanning-tree then VLXLAN is an answer.
Okay, but why not use tunnels or MPLS?
VXLAN allows you to accomplish what GRE does without having to change the network design. By using VXLAN you are also able to have standalone layer2 domains that talk to each other. With the tunnel approach, you have to do a lot of manual configuration.
Is this just a data center thing?
VXLAN was designed to solve many of the edge computing and hyper-scale computing issues. Imagine having compute nodes in different parts of a data center or even in different data centers. You want all of those nodes on the same VLAN. With GRE you could extend that VLAN, but with VXLAN you can have two standalone layer2 VLANs that are merged together. VXLAN also solves the 4096 VLAN issue. This is important in hyper-scale cloud computing.
VXLAN benefits in a nutshell
- increases layer2 segments to 16 million
- Centralize control
VXLAN downsides in a nutshell
- Multicast must be available
- more overhead to layer2 packet
- no built-in encryption
- Slow adoption of ipv6 support by open source
What about the service provider? How can I use this?
In a service-provider network, you have things like broadcast issues. Basically, bridging is bad. Your layer2 networks need to be contained. Imagine you are a service provider who is providing LTE services. You may have an LTE VLAN on your network. Historically you would have to extend your VLAN across the network in order to do management and access your LTE core. Now you have this large broadcast domain across your entire network. Or worse yet, you have tunnels to other cities or locations you don’t have physically connected to your network. Now you have tunnels a part of your LTE VLAN. MTU issues and other things are now a part of your life.
With VXLAN each LTE node can have its own layer2 VLAN but still talk to the others. This prevents the broadcast storms which can occur.
Another use for VXLAN is a way to allow managed service providers to deploy large scale networks over the 4000 limits of VLANs. You could literally deploy thousands of layer2 segments to tenants
Why I should or should not care about VXLAN as a service provider?
If you just have a couple of layer2 networks to extend across your network VXLAN is not for you. However, VXLAN does allow for multipath routing and other protocols to be extended to remote networks.
VXLAN adds 50+ bytes of overhead to the layer2 frame. In many service provider networks, this is not an issue due to MTU being raised for MPLS, etc. IP multicast must be extended across the entire network. Mac addresses are used in creating a distribution network across all of the routed layer2 domains.
Large service providers have started looking at segment routing to solve many of the issues I talk about. This causing them to gravitate toward EVPN. EVPN allows for BGP for the control plane and MPLS for the data plane. More on this coming soon.
In closing, VXLAN is an ultra-cool technology and has use cases for service providers. Other methods also exist to solve these issues in the service provider world. For those of you looking to learn all you can, I will be posting a list of links for my Patreon folks.