This was a visit to Beck’s Hybrids and a visit with one of our Clients.
Splynx 2.1 released
Skinny cables and the lowdown
The new ANSI/TIA-568.2-D cabling standard which now allows for the use of 28 AWG patch cords. What does this mean and how does it affect you? Read this article from Fluke networks.
Number one takeaway.
-Recommended length no more than 15 meters. This means it is great for dense racks and patch panels.
http://www.flukenetworks.com/blog/cabling-chronicles/skinny-28-awg-patch-cords
New Mikrotik hardware
Winbox brute Force
You really should not have your winbox port open to anything but a management network, but if you need a script to help with brute force on the Mikrotik.
add action=drop chain=input comment="drop winbox brute forcers" dst-port=8291 \
protocol=tcp src-address-list=winbox_blacklist
add action=add-src-to-address-list address-list=winbox_blacklist \
address-list-timeout=1w3d chain=input connection-state=new dst-port=8291 \
protocol=tcp src-address-list=winbox_stage3
add action=add-src-to-address-list address-list=winbox_stage3 \
address-list-timeout=1m chain=input connection-state=new dst-port=8291 \
protocol=tcp src-address-list=winbox_stage2
add action=add-src-to-address-list address-list=winbox_stage2 \
address-list-timeout=1m chain=input connection-state=new dst-port=8291 \
protocol=tcp src-address-list=winbox_stage1
add action=add-src-to-address-list address-list=winbox_stage1 \
address-list-timeout=1m chain=input connection-state=new dst-port=8291 \
protocol=tcp
add action=drop chain=forward comment="drop WINBOX brute downstream" dst-port=8291 \
protocol=tcp src-address-list=winbox_blacklist
Of course changing your Winbox port number and disallowing access from anything but trusted Ip addresses is one of the best ways.
Ac Wave 1 vs Wave 2
There has been much discussion on the performance of going from an N Series outdoor wireless system to AC. Not all AC is created equal. Right now there is AC Wave 1 and AC Wave 2. Just about all the AC stuff currently in the pipeline for outdoor wireless is wave 1. There is wave 2 indoor gear available, but for a WISP you are interested in the outdoor gear.
So what’s the difference?
For some reading about spatial streams, channel sizes, etc. look at this article https://info.hummingbirdnetworks.com/blog/80211ac-wave-2-vs-wave-1-difference
For the WISP folks who want the Cliff Notes version here are some key differences.
-Wave 1 uses 20,40,and 80 Mhz Channels. Wave 2 can support 80 and 160mhz channels. The 160mhz channel would be two 80mhz channels bonded together.
-Wave 1 can do 3 spatial streams. Wave 2 does 4. This requires an additional antenna to take advantage of wave2. This is a hardware upgrade from wave1 to wave 2.
-Wave 2 supports MU-MIMO. The AP can talk to 4 clients individually at once. The client must also support this, which is a hardware upgrade from wave 1 to wave 2 on both the client and the AP.
The question to ask your vendors is what is the upgrade path if you are using existing AC gear. If you are running AC currently you are most assuredly going to have to replace your AP radios and antennas. Will your existing clients work with the new AC wave 2 aps? An important thing to ask.
What is a BGP Confederation?
In network routing, BGP confederation is a method to use Border Gateway Protocol (BGP) to subdivide a single autonomous system (AS) into multiple internal sub-AS’s, yet still advertise as a single AS to external peers. This is done to reduce the number of entries in the iBGP routing table. If you are familiar with breaking OSPF domains up into areas, BGP confederations are not that much different, at least from a conceptual view.
And, much like OSPF areas, confederations were born when routers had less CPU and less ram than they do in today’s modern networks. MPLS has superseded the need for confederations in many cases. I have seen organizations, who have different policies and different admins break up their larger networks into confederations. This allows each group to go their own directions with routing policies and such.
if you want to read the RFC:https://tools.ietf.org/html/rfc5065
UBNT EDGEMAX 1.10.3 update route flushing
From UBNT:
New features:
Offloading – Add CLI commands to disable flow-table flushing in offloading engine when routing table changes: set system offload ipv4 disable-flow-flushing-upon-fib-changes set system offload ipv6 disable-flow-flushing-upon-fib-changes
Discussed here
Prior to 1.10.3 firmware flow-table in offloading engine was always flushed when route was updated in linux routing table. Flow flushing ensured that offloading engine got routing updates instantly but it wasted a lot of CPU time and decreased performance if routing table was constantly updated for (instance in Full BGP, big OSPF or flapping PPPoE interface scenarios)
In 1.10.3 firmware by default disable-flow-flushing-upon-fib-changes is not set which means that flow table in offloading engine is always flushed upon routing table changes same way as it used to be in previous firmware.
If you have Full-BGP table or large OSPF network they you are advised to set disable-flow-flushing-upon-fib-changes this will ensure less CPU-load and increase max throughput.
Important note for multi-WAN environments – if nexthop interface of default-gateway changes and disable-flow-flushing-upon-fib-changes is set then it will take up to flow-lifetime seconds before all existing offloaded flows switch to new nexthop interface (up to 12 seconds by default).
Offloading – Add CLI command to modify flow-lifetime in offloading engine (expressed in seconds):
set system offload flow-lifetime 24Prior to 1.10.3 firmware flow-lifetime parameter was hardcoded and was not synchronized between different ER platforms: 12 seconds on ER-Lite/ER-Poe, 6 seconds on ER/ER-pro/ER-4/ER-6 and 3 seconds on ER-Infinity.
In 1.10.3 firmware default value of flow-lifetime is set to 12 seconds for all ER platforms and now it can be modified. By modifying flow-lifetime parameter you control how much traffic skips from offloading engine into linux network stack.
If you increase flow-lifetime then:
a) Offloaded IP flows will expire less frequently and less packets will be forwarded to linux
b) CPU load will decrease and max throughput will increase
c) if disable-flow-flushing-upon-fib-changes parameter is set then it will take more time for offloading engine to detect changes in routing table
If you decrease flow-lifetime then:
a) Offloaded IP flows will expire more frequently and more packets will be forwarded to linux
b) CPU load will increase and max throughput will decrease
c) if disable-flow-flushing-upon-fib-changes parameter is set then it will take less time for offloading engine to detect changes in routing table
Offloading – add CLI command to show flows in offloading engine: show ubnt offload flows Offloading – add CLI command to show offloading engine statistics: show ubnt offload statistics
Enhancements and bug fixes:
LDP – fixed regression in 1.10.0 when LDP configuration failed. Discussed here LoadBalancing – fixed regression in 1.10.1 when LoadBalancing failed to recover if WAN interface lost&restored link in 3 second interval. Discussed here DHCP – fixed bug when DHCP server configuration failed to commit with networks other than /8, /16, and /24. Discussed here TrafficControl – fixed regression in 1.10.0 when “command not found” output was printed when running “show traffic-control …” commands. Discussed here
MTIN participates in FCC Commissioner Brendan Carr Visit
On May 3rd, On-Ramp Indiana and Beck’s Hybrids hosted FCC Commissioner Brendan Carr and Congresswoman Susan Brooks from Indiana District 5 to discuss rural broadband and technology. We are extremely honored for the opportunity to share our experiences in deploying rural broadband with them.
The FCC defines broadband as any connection capable of 25/3Mbps. 47% of “rural” residents of Indiana District 5 do not have any choice for broadband internet. There are over 2000 Wireless ISPs in our country working hard to fill the gap and provide affordable access to underserved areas. While fiber, and other technologies will be part of the solution, we also are asking the FCC to work with WISPs to create an environment where we can access much needed spectrum to rapidly and cost effectively deploy broadband in rural areas.
A special thanks to Beck’s Hybrids (Sonny, Brad & Jeremy) for hosting the meeting at their incredible facility in Atlanta, IN. They are a huge proponent of rural broadband as it helps achieve their mission of helping farmers succeed. Rural Broadband is helping move the immense amount of data collected in modern farming into the computing data centers for analysis. The end result is a more efficient and productive farming process which greatly benefits our economy.
We would also like to thank Justin Wilson of MTIN Consulting for assisting in the presentation. Thanks also to Tracy Barnes & Ryan Heater with Lt Governor Crouch’s office, and Jodi Golden with the Office of Community and Rural Affairs, we appreciate you attending and it was great to meet everyone!
Mikrotik Destination Nat
Scenario
You have a customer with a Mikrotik router that needs a port forwarded to an internal IP address. In our case, a customer has a camera that communicates on port 80 with a static IP add of 192.168.21.49 on their internal LAN.
Solution
add action=dst-nat chain=dstnat dst-port=80 protocol=tcp to-addresses=192.168.21.49 to-ports=80