Greg Sowell, Justin Miller, and Justin Wilson get a live demo of 6 BGP peers loading on a CCR1016 running a build version of router OS version 7.
We give all the details we have on the inner workings of the new engine.
3.5 million routes in around 3 minutes and the UI didn’t bat an eye. Per table memory utilization is about 145MB.
This week Greg, Tomas, Mike, and Wilson get down with the get down. Get ready towards the end, because we go on some nontechnical discussion on technology’s impact on us in our daily lives along with how the technology we facilitate changes people(we go deep bro).
This cast we talk about:
Mikrotik Update: GPEN to GPEN 210M, GPEN to standard ethernet device 100M Mikrotik CVE-2018-19299 issue(public release in 10 days). Memory leak due to IPv6 crafted packets moving through router – it seems SOME of it has been fixed in 6.45beta22.
MUM Austin – Gus’ chicken, live show, Master Pancake Theater
MikroTik 802.11 indoor vs. TP-Link
TP-Link Archer C5400 vs. Tik cAP
ROS 6.45beta22 fixes Steve’s EAP Radius issues
Remote admin clients –
Greg converted a Cisco 7200 to an ASR9000
Ciena sent me sales engineers, you’ll never believe what happened next
Mikrotik CRS3xx series are going into production for a lot of us – hardware DHCPsnooping, port isolation, DHCP option 82, vlan filtering, STP
Thrift quote of the week “Stacking is not suitable for highly available networks, it is a technology of convenience not of reliability” Stacking vs MC-LAG
This week Greg talks to Matt Whiteley about his top 5 tips, British TV, and Brexit.
1. If you don’t know how it works, you won’t know how to fix it.
If you’re new to wireless, put a bridge pair up and set it to auto-everything and then put it into production, you’re probably going to be spending a lot of time retrospectively learning about DFS, interference, Fresnel zones and wireless in general. Understanding how it works before you put it into production will save a lot of phonecalls which leads into
2. Bench it and break it. (Then document it and put it in production)
Then you’ll know how to fix it and also which config should go on there from the get-go. Put it in your test bed and break it every which way you can and fix it every time. Then get someone else to break it for you. You’ll know your products and your setup inside out at the end of it. In a rush to get the service up and running … don’t! At least don’t make a habit of it. It’s so much harder to try and put a proper config onto something once it’s in production and you’re trying to keep services running whilst you change the config, I estimate you will waste 4x however long it took you in the first place to put it right. Also I bet you rushed it and didn’t document it up-front and you’re now trying to retrospectively document it which takes longer. And finally because you’ve now put a new config on something probably remote from where you are, you’re not going to have the right labels on the right bits of equipment. It will be a maintenance nightmare.
3. Somebody else fixing it this time isn’t going to help you fix it next time.
Sure if you’re in a bind and your service is down then get some external help, else fix it yourself. You’ll know what to do next time and it’ll help you improve on how you set your service up to avoid it ever happening again.
Understand the issue, if a customer is explaining it or a tech is telling you what’s going on, probe them to make sure you get a good understanding of the issue and make sure their language is the same as yours. Rubbish WiFi could mean anything from WiFi connection flapping to poor signal to poor download speeds. Really nail what they’re saying.
Replicate it. If you can’t replicate the problem yourself then you’re going to have no idea when you’ve fixed it. From section 1 “Understand” you might have realized it was poor download speeds, so jump on their PC and replicate that. Ensure you can replicate it and you also get poor download speeds.
Fix it. Now you have a repeatable process from section 2, you can be sure you’ll know when you’ve fixed it.
Confirm it. No point fixing it if you don’t then get back to your client. If they still think it’s broke for the next 24 hours you’ll just get bad feedback even though you did good work . Not just an email confirmation either but a telephone conversation so they can thank you in person!
5. You can fix anything! If it’s still broke then you just don’t have enough information yet to know what the solution is.
When people come to me and tell me they can’t fix something what they normally mean is they haven’t gathered enough data to analyse. They’re normally skilled enough to fix it, they just haven’t enabled the logs yet, gone through them and picked out the line that tells them what’s wrong and often the difference between a good engineer and a great engineer is nothing than some more patience. The best engineers will have an instinct and will know how to get that information the quickest but anyone can be a great engineer just by being methodical and persistent.
This week Greg and Tomas have a chat while recovering from their respective illnesses LOL.
This cast we talk about: Nvidia acquires Mellanox Mikrotik EU MUM 2019 New Hardware
Ubiquiti has 60GHz radios with 5GHz failover in beta – $130
Fiberstore merged with an optic factory; SFP+SR $15, SFP+LR $21
Windstream in chapter 11, business as usual it seems
WISPAmerica next week
Default configs via netinstall on Mikrotik
Via Cox; Post v6.42 Mikrotik Hotspot creates hotspot server queue by default. This bricks user rate-limits. Miller suggest an on-login script that moves it to the bottom.
Thrift noticed that the new CCRs have a fan between the redundant PSUs.
Rob laments the fact that some Mikrotik switches have the top left port set as “port 2”
Steve says to watchout for fasttracking pure IPSec traffic “I’ve been burned in the past by it.”
Network statement in Cisco and Mikrotik says “Run OSPF on these interfaces”, it also happens to advertise those networks too.
Finding fiber crews; ask local municipality and colleges for recommendations.
Bostjan summarized a lot of discussion on the dangers of wireless:
1) everybody I know was running around like theirs hair is on fire and screaming how all antennas are bad for you. We all are going to die. This seemed not logical to me so I tried to ignore it.
2) A guy who works for a carrier and installs antennas on towers for them said that antennas are dangerous. I couldn’t ignore that so I came here to educate myself.
3) This is what I’ve learned so far
-WISP is using 0.2 watt radios. Cell guys are using 20 watt radios. Broadcast (AM, FM, TV) are using 20,000 watts.
-There is no health risk unless you are sleeping on the Tower’s transmitter.
-if you are cold, go stand in front of the dish to warm up (is true, but don’t do it)
-and there is this guy who makes other people nervous https://youtu.be/ii82I1IzFRY?t=486
-some proteins in your body starts to changes it’s molecular structure from about 42°C. You’ll be dead before cooked
-one more thing, I think that antennas are dangerous; they can kill you if they fall from a tower on your head
This week Greg talks to Nick Buraglio about his top 5 tips.
* Be the dumbest person in the room
* Know your network
* Failure is your friend
* Grey is the new black, grey is the new white
* Networking is largely social, technical is an artifact
* Play to strengths
This week Greg, Dave, Mike, and the ever elusive Tomas go on some rants!
This cast we talk about: Unimus update from Tomas New Weekly Feature Big Boy Switches Chi-NOG LibreNMS PHP Requirement Change
Mike K says use silicore HDPE conduit to pull fiber in underground.
Mike K also suggests the use of fiber enclosures that use standard man-hole covers
Tomas muses over the fact that opensource projects with corprate backers who make money from support always seem to be lacking in documentation.
Tomas says to safely make multiple Mikrotik changes: enable safe-mode, Use an open curly brace, put all your commands in, close curly brace. The commands will be applied after the final brace.
Companies are offering zeroday bounties for Mikrotik routers
This week Greg talks to John Osmon about his top 6 tips.
1) *BE* the packet (Know how the network works)
2) pcap or it didn’t happen (get proof)
3) don’t confuse network and physical diagrams
4) give back to the community
5) vocabulary — learn others, teach yours. Necessary for communication
6) lab it / break it — you don’t know it until you see how it behaves when broken
Austin MUM – record a little brothers wisp podcast?
Andrew Thrift is now prepared to answer all of your Fortinet questions.
Jeremy has found success with receiving and processing is abuse notifications at abuse.io NV2 for 802.11ac is broken on Mikrotik ARM kit, so avoid it.
Thrift is pushing for a standardized API with Mikrotik. 802.11 beaconing with additional SSIDs
When you think an optic may be running too hot, you can try wrapping fiber around a pencil
Tomas wants unimus feedback “If you aren’t using it, what are your reasons?”
This week Greg talks to Colin Z about his top 5 tips.
1) Look at things in terms of a Link Budget.
2) 6 dB delta to make a noticeable difference.
3) Follow basic grounding practices (R56 is a good reference).
4) Plan for outage.
5) Document what you can.