I have been a consultant for the Internet Service Provider (ISP) space for the better part of my working life. I have dealt with the technical side of the field and some of the business and back end. I have been an owner/operator/stakeholder in several ISPs since 2000. Some of these ventures have been self-funded, while partners funded others. This history has given me a unique perspective many others have not been able to experience.
Most of the ISP operators I have worked with boil down two one of three types
The Businessperson. These operators usually have little technical knowledge but see a business need and require technical and operational personnel to help them. An outside technical consultant helps to supplement any technical expertise.
The Techie. These are folks who know the technical side of operations. They may not necessarily have Service Provider experience. Still, they can configure gear, understand spec sheets, and follow the lingo on message boards and groups.
The Operator. They may need a consultant for a few reasons. The first is that they are racing and need outside talent on demand. Second, they may need someone to supplement higher-end tasks such as BGP, CBRS implementations, or LTE help. This person is a professional who can pick up on both the business and technical sides.
Each of the above types needs different things from a consultant and should approach a consultant differently. One of the best things to do before hiring a consultant is put a list together of what you need help with. This need can be a long wishlist or a specific task. Either way, having a defined Scope of Work (SOW) is beneficial.
From my experience, the more focused the task, the easier it is for me to get up to speed. This ease is especially true of an established network. It is much easier for me to give a time estimate when someone says, “OSPF is broken between router ten and router eleven. Can you look at that?” than it is for someone to say, “My OSPF is broken. can you look at it”. As a general topic of investigation, I will try and get more specific, so I am not spending hours looking at unaffected network segments.
One of the things I think any owner should do with a potential client is to have a general call before any work starts. If you are looking for someone to fix a specific issue, this is probably a quick call. I have jumped into a client’s screen share before within a few minutes of them calling and worked through an issue without much prep work. Suppose the operator is looking to have a consultant work on several projects and work on a medium to long-term basis. In that case, the conversation needs to be longer.
Suppose you are an operator looking to hire a consultant to be with you for a while. In that case, the initial conversation I mentioned above is more like a two-way interview process. This type of conversation tends to happen with new or startup WISPs a lot. They need direction and someone to answer many questions that are not answered outside of an ISP. In an earlier article, I go over the differences between an ISP network and an Enterprise network.
In Part two we will look at more things to ask and look for from the operator’s perspective. In Part Three we will look at some of the rationale and options from the consultant’s perspective.
SketchBloke has a good post on Mikrotik interoperability with IPSEC VPNS
Check your internet speed with Cloudflare’s very own internet speed test.
The arguments against using 0.0.0.0/0 have been pretty much quashed by the following:
Allow 0.0.0.0/8 as a valid address rangeThe longstanding prohibition against using 0.0.0.0/8 dates back to two issues with the early internet.
There was an interoperability problem with BSD 4.2 in 1984, fixed in BSD 4.3 in 1986. BSD 4.2 has long since been retired.
Secondly, addresses of the form 0.x.y.z were initially defined only as a source address in an ICMP datagram, indicating “node number x.y.z on this IPv4 network”, by nodes that know their address on their local network, but do not yet know their network prefix, in RFC0792 (page 19). This usage of 0.x.y.z was later repealed in RFC1122 (section 188.8.131.52), because the original ICMP-based mechanism for learning the network prefix was unworkable on many networks such as Ethernet (which have longer addresses that would not fit into the 24 “node number” bits). Modern networks use reverse ARP (RFC0903) or BOOTP (RFC0951) or DHCP (RFC2131) to find their full 32-bit address and CIDR netmask (and other parameters such as default gateways). 0.x.y.z has had 16,777,215 addresses in 0.0.0.0/8 space left unused and reserved for future use, since 1989.
This patch allows for these 16m new IPv4 addresses to appear within a box or on the wire. Layer 2 switches don’t care. 0.0.0.0/32 is still prohibited, of course.
Tower Climber movie coming soon
Recently I have been using the QoE solution from Cambium Networks on some networks. This software allows for the prioritization and shaping of traffic on a service provider’s network. We will go into the workings of this in some later posts. Here are some screenshots.
-Always check layer1 first. Your momma told you it’s the simplest things in life. Most times it is that simple.
-After that check layer 2. If a backhaul or fiber link can’t push data due to no connectivity then the fanciest written config in the world won’t mean a thing.
-Use a password manager. 16 character passwords should be the norm with two-factor authentication to the password manager.
-Make a decision and act on it. Too many times I see network by committee. By the time it’s actually implemented the parameters have changed. Do the best you can, with the information you have, in the time you have.
-Have a second and third way into your network
-Get used to reading release notes and scanning forums/mailing lists for bug reports
-Your network probably is not hacked
-Quit spending time trying to navigate your network on your phone’s small screen. Break down and buy a tablet or break out your laptop. Your phone is for quick assessments using the data you are fed. It’s too inefficient to make config changes.
-This Dilbert comic strip cracks my ass up
-Just emphasizing how it’s the simplest things at times
-It’s fine if you know how to program in binary but you don’t need to know the inner workings of hardware for 95% of the job. A racecar driver probably knows about engines but spends 99% of his or her time just driving the car.
-Get to know your sales reps for your hardware. They are the unsung heroes in this industry. a good salesperson picks up tidbits of knowledge and lets their customers know. Things like bad hardware runs, bugs other customers have come across, and the like.
A successful maintenance window is 75% labor and 25% documentation. An unsuccessful one is 75% labor and 25% rolling into backups.
-You only know what you know and that’s okay
-The big companies are just as clueless as you. Sometimes they are worse. They just have more people who know just enough to get by.
-There are work gadgets and fun gadgets. Keep the two separate.
-That optic you should have replaced when you were cleaning the fiber cable will probably haunt you tomorrow.
Part 3? Maybe…..
Only took me about 6 years to do. Been so busy doing IPV6 for everyone else I have not done it for me. I reached Sage level on ipv6.he.net.