Writings from Justin Wilson
What’s new in 7.1beta4 (2021-Feb-03 09:39):
*) api – added support for REST API;
*) crs3xx – fixed Layer3 hardware offloading;
*) route – routing rules improvements;
*) winbox – added support for wifiwave2;
*) winbox – updated User Manager, OSPF and BGP menus;
*) wifiwave2 – authentication and functionality improvements;
*) other fixes and improvements;
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.
Distributors
ISP Supplies
Texas-based distributor carrying a big number of product lines such as Cambium, Mikrotik, Airspan, and many others
Baltic Networks
Chicagoland based distributor carrying product lines such as Mikrotik, Cambium, and others.
CTIconnect
Distributor of fixed wireless and telecommunications infrastructure for Internet Service Providers (ISP’s), Cable Operators, Telephone Companies
Billing
Azotel
Mature billing solution which can
manage all aspects of your ISP.
Sonar
Modern Billing software with many backend automation
VISP
Automation and control of your WISP customers
More Billing providers can be found at xISP billing platforms
Manufacturers
Baicells
LTE and CBRS based solutions
Cambium Networks
Manufacturer of fixed wireless products such as EMP, 450, and cnPilot wireless.
Mikrotik
Manufacturer of Mikrotik routers and RouterOS routing and switching products
Ubiquiti
Manufacturer of WISP and WIFI products. Product lines include AirFiber and Unifi.
Tower Related
TowerOne
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.
Voice
Atheral
Unified communications with experts to help you migrate and stay compliant. Here is a link to a podcast I did with Ateral.
True IP Solutions
Unified communications solutions integrated
with access and camera solutions.
Training
Rick Frey
mikrotik training and certification as well
as consulting and integrations solutions
LinkTechs
Training on Mikrotik and distributor of related products
More info on training for the xISP
Supporting Services
TowerCoverage
RF Mapping and Modeling for tower sites and customer pre-qualification
Wireless Mapping
Radio Mapping, two-way radio, mark study information, and Municipal broadband.
IntelPath
Microwave and Millimeter Wavechannel procurement.
Organizations, web-sites, and groups
WISPA
Trade Organization supporting Wireless Internet Service Providers=
Cambium Users group on Facebook
YouTube Channels
TheBrothersWISP
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.
Mikrotik CCR1072 for an ISP network running BGP.
If you have a Baicells eNodeB you wish to restrict access to these Mikrotik rules will help. There are some assumptions made. The following rules are meant to be a base for incorporating into your network.
/ip firewall filter
add action=drop chain=forward src-address=10.0.0.2 src-port=443 protocol=tcp \
dst-address-list=!baicells_cloud
add action=drop chain=forward src-address=10.0.0.2 src-port=8082 protocol=\
tcp dst-address-list=!baicells_cloud
add action=drop chain=forward src-address=10.0.0.2 src-port=48080 protocol=\
tcp dst-address-list=!baicells_cloud
add action=drop chain=forward src-address=10.0.0.2 src-port=4500,500 \
protocol=udp dst-address-list=!baicells_cloud
add action=drop chain=forward src-address=10.0.0.2 dst-port=80,443 \
protocol=tcp dst-address-list=!WHITELIST
/ip firewall address-list
add address=baiomc.cloudapp.net list=baicells_cloud
add address=baicells-westepc-03.cloudapp.net list=baicells_cloud
add address=baicells-eastepc04.eastus.cloudapp.azure.com list=baicells_cloud
add address=1.2.3.4/24 list=baicells_cloud
add address=1.2.3.4/24 list=WHITELIST
10.0.0.2 is your eNodeB
The 1.2.3.4 above is your management Subnet.
You can tighten these rules up by combining them, or create a new chain. This is quick and easy and anyone can understand. What it does is allows the eNodeb to only communicate with the Baicells cloud and your management network. It also only allows you to access your eNodeB from your management network. These are not a complete ruleset but something to build upon.
I am starting to see the following scenario more and more as IPv4 space is hard to get, but isn’t.
With ARIN it is still possible to get an IPv4 allotment. Many smaller ISPs qualify for a /24 and can get one if they wait long enough on the ARIN waiting list. a /24 of IPv4 space is the smallest block that 99% of the Internet allows to be advertised on the Capital I Internet. There are filter rules in place that drop smaller prefixes because that is the agreed upon norm.
So what happens if you are an ISP and you have a shiny new /24 but you have two networks which are not connected. Let’s look at our scenario.
The above network have no connectivity between the two of them on the internal side. These could be half way across the world or next door. If they were half way across the world it would make sense to try and get another /24. Maybe they are either side of a big mountain or one is down in a valley and there is no way to get a decent link between the two networks.
So what is a way you can use this /24 and still be able to assign IP addresses to both sides of the network? One way is to use a tunnel between your two edge routers.
Without the tunnel the scenario is traffic could come into network1, but if the IP is assigned on network 2 it will come back as unreachable. BGP is all about networks finding the shortest path to other networks. You don’t have much control over how networks find your public IP space if you have two providers advertising the same information. Some of the Internet will come in Network2 and some will come in Network1.
By running a tunnel between the two you can now subnet out that /24 into two eqal /25s and assign one /25 Network1 and one /25 to Network2 or however you want to. You can make the tunnel a GRE, EOIP, or other tunnel type. If I am using Mikrotik I prefer to use EOIP. If it’s another vendor I tend to use GRE.
Once the tunnel is established you can use static routing, OSPF, or your favorite IGP (interior Gateway Protocol) to “tell” one side about the routes on the other side. Let’s look at a fictional use.
In the above example our fictional ISP has an IPv4 block of 1.2.3.0/24. They have two networks separated by a tall mountain range in the center. It’s too cost prohibitive to run fiber or a wireless backhaul between the two networks so they have two different upstream providers. The ISP is advertising this /24 via BGP to Upstream1 from the Network 1 router. Network 2 router is also advertising the same /24 via BGP to Upstream 2.
We now create a Tunnel between the Mikrotiks. As mentioned before this can be EOIP, GRE, etc. We won’t go into the details of the tunnel but let’s assume the ISP is using Mikrotik. We create an EOIP tunnel (tons of tutorials out there) between Network 1 router and Network 2 router. Once this is established we will use 172.16.200.0/30 as our “Glue” on our tunnel interfaces at each side. Network 1 router gets 172.16.200.1/30. Network 2 router gets 172.16.200.2/30
To keep it simple we have a static route statement on the Network 1 Mikrotik router that looks like this:
/ip route add dst-address=1.2.3.129/25 gateway=172.16.200.2
This statement routes any traffic that comes in for 1.2.3.128/25 via ISP 1 to network1 across the tunnel to the Network 2 router. The Network 2 router then send it to the destination inside that side of the network.
Conversely, we have a similar statement in the Network 2 Mikrotik router
/ip route add dst-address=1.2.3.0/25 gateway=172.16.200.1
This statement routes any traffic that comes in for 1.2.3.0/25 via ISP 2 to network2 across the tunnel to the Network 2 router. The Network 2 router then send it to the destination inside that side of the network.
It’s as simple as that. You can apply this to any other vendor such as Cisco, Juniper, PFSense, etc. You also do not have to split the network into even /25’s like I did. You can choose to have os of the ips available on one side and route a /29 or something to the other side.
The major drawback of this scenario is you will takef a speed hit because if the traffic comes in one side and has to route across the tunnel it will have to go back out to the public internet and over to the other ISP.
#packetsdownrange
So, due to Covid, weather and everything else I am quite behind on blog updates and such. this is one that kinda fell through the cracks. I meant to get this out much sooner than now. My buddy Schylar Utley has a pretty cool projects for optimizing CPE deployments and such.
Check them out at https://github.com/MajesticFalcon
I have included an old video to give you an idea. I am sure things have changed since this video was created.
There always is a lot of talk about Mikrotik RouterOS CPU usage. I wanted to take a few minutes and go over a real-world example and explain some of the ins and outs when discussing Mikrotik CPU usage.
Let’s talk about the router in question. This is a CCR1016-12s-1S+. This is a 16 core 1.2GHz per core and 2GB RAM tilex based router. It is currently pulling in 1,764,849 IPv4 routes. There are two transit provider BGP feeds, multiple direct peers, an Internet Exchange peer to dual-route servers. The router handles a little over 3 gigs of routed traffic at peak times. Most of the traffic is on VLANs coming from a Cisco switch to the SFPPlus port.
One of the first things people turn on is the overall CPU usage within winbox. I like to think of this as an overall view of the CPUs on this router. Keep in mind there are 16.
Th next thing to investigate when it comes to CPU is to open up System..resources. Once there clock on CPU.
It will then bring up a screen that looks like the following.
Oh My we have 100% CPU! Must replace this router ASAP! Calm down, remember you have 16 cores. So, why is this CPU at 100% and what ramifications does this have?
Remember earlier when we talked about BGP? In Mikrotik, BGP is not a multi-core aware process. This means BGP is limited to just one core to do it’s work. Since there are always routes being withdrawn and re-added to the routing table it is a busy process. Lots of math calculations going on. The key thing is this is expected behavior on a router running multiple BGP peers such as this one. This is not a bad thing, but not ideal. Throwing more cores at BGP is not the answer. Optimizing the process, as it has been done in V7 is the way to go.
If we expand the CPU window we will notice other processes are multi-core aware and.or are spreading their load among different cores.
As you can see we are in pretty good shape. We have a few CPUs above 50% utilization but, only a few. I will keep reminding you of the fact we have 16 of them.
Closing notes:
Diagnosing CPU issues can get a little complicated because routers like the 3011 have some have the majority of their ports shared with a single CPU bus. https://wiki.mikrotik.com/images/f/f3/Switch_chip_block_diagram.png. As you can tell in the diagram there are 5 ports which share 1 Gig to the CPU. The fact that an actual switch chip with hardware offloading is in the middle helps, but the bus is still oversold. This is one reason consolidating routers to an actual switch will make a difference.
Janis Megis from Mikrotik had presentation at MUM, which is a little older now, still sheds a lot of light on how Mikrotik CPU works. https://mum.mikrotik.com/presentations/US10/Megis.pdf There is some pretty interesting stuff starting on page 14
With Mikrotik switching to ARM processors we will see huge differences with them and RotuerOS7. We will see less cores, but better utilization of those cores. The new 2004 with all SFP and 2 25 gig ports only has 4 CPU.
So the next time you look at a router, take a few moments to see how utilized the entire CPU architecture is instead of just one CPU.
#packetsdownrange #mikrotik
Unlock with Patreon