This week Greg talks to Jim Jones about his top 5 tips.
The Tips:
1. Show up.
– If you’re early you’re on time. If you’re on time you’re late. If you’re late, you’re fired.
– Never be late… especially to a client.
2. KNOW DNS.
– It’s never DNS… till it is.
– Use DNS!
3. Be humble. Ask for help.
– Have a network of peers.
– Don’t wait too long to call support! That’s what they’re there for!
4. Backup all the things.
– File data
– Systems
– Configs
5. Don’t be married to vendors. Use the right tool for the job.
– Windows vs Linux
– Mikrotik vs Cisco
– Cisco SMB vs Bruhcade
– Unifi vs Meraki
6. Bonus: Learn. Go outside your comfort zone, silo.
– Podcasts.
– Books, audio.
– Youtube, pluralsight, etc.
7. Bonus: Teach. Mentor. Give more than you take.
– Don’t limit this to tech.
– True happiness is in serving others.
*Slack Updates*
What’s in your backpack. Aside from the common Some things are: lock picks, small multimeter, 6 inch industrail laptop Tomas found a cli wireshark tool sngrep – realtime SIP packet viewer IPv6 routing subnets without routing?
Controlling traffic flow when BGP peering with the same ISP twice – MED vs Prepending ZeroTier Opensource SDN doesn’t do multipathing yet
Bridge appliance resilancy – second link bypassing it shutdown by STP(Mikrotik to Netonix)
Customer silence, not always a good thing – either acceptance or they’ve given up. Out communicate them.
Basic router configuration for business customers.
Help support us by becoming a patron! <==join our Slack team!
Keep contacting us: contactus (at) thebrotherswisp.com or https://facebook.com/thebrotherswisp
Here’s the video:(if you don’t see it, hit refresh)
*Slack Updates* ESXi set port group vlan to 4095 to pass all vlans to a VM
Edwin is asking about spacing APs in public wifi – start with client density and go from there
BGP on arista and openBGPd routers
Manipulating tcam tables
Jeremy(aussie hipster) – diverse routers with different ISPs, transport both to one or terminate ISP on each and full mesh?
MC-LAG vs Stacking – as many opinions as there are engineers. Answer…add both features LOL
Configuring switches for edge user connections – DHCP snooping, port isolation, port security, storm contol, dynamic arp inspection,vlan acl
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
*slack updates*
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
Orville season 2 e11 – lasting impressions
Wondering conversation about the impact of technology on life
Putty / WinSCP vulnerabilities – update now Udemy Complete Networking Fundamentals
This week Greg talks to Matt Whiteley about his top 5 tips, British TV, and Brexit.
The Tips:
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.
4. Understand/Replicate/Fix/Confirm
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
*Slack Updates*
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.
The 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
