Unsucking Wi-Fi - a quick and dirty guide for the neophyte wireless engineer

Recently, some of my colleagues have been coming to me for advice with wireless. There is a TON of information you need to know to get good at wireless networking, but there are also some quick tips that can get you quite far, quite fast. 

The intended audience is a technical person who's somewhat unfamiliar with wireless, or seeks to quickly learn a bit more. If you want an even more basic primer, check my previous article. 

This article doesn't particularly cover external Pt(M)P networking that may be used to cross a campus or run a WISP - it's focused on wireless supplying end clients (i.e. "traditional" in-building wireless coverage). 

It is not going to be the be all and end all of wireless (it's not several thousand pages long, for a start), and some things are context-specific, and guidelines are sometimes best broken, once you understand more; realise this is, at best, a primer to going off and doing (a lot) more reading (and careful experimentation!).

Read on...

A home for a home lab: StarTech 12U desktop open frame 2 post rack

 My wife (aka "Senior Management") decreed that I needed "a table or something" for the network gear that was starting to accumulate in the spare room I use as an office. 

Of course, since pretty much all of it either had rack mounting hardware or could be persuaded to sit on a shelf, a 19" rack made sense and forms a much more suitable home for network gear. 

After hunting around a bit online, I decided a 12U open frame 2 post rack would probably do the job well - without being the imposing monolith of a 42U four post rack, wallbox or similar, which probably would get rather more in the way of raised eyebrows from Senior Management, too - if I could even fit it in the flat. 

Juniper Configuration Groups

 Although the use of network automation / Infrastructure as Code is likely to greatly reduce their usefulness, configuration groups can be pretty handy things to include in your Juniper configuration. 

You can use them for two major things:

1. portable generic configuration you are likely to set everywhere on all your routers (something like DNS servers or NTP servers, or a management network gateway etc.), and
2. specific configuration that differs from Juniper's defaults, but is the common "base" configuration for that type of object in your network. 

The second tends to be the more useful.

People that are not familiar with Junos may find this group inheritance behaviour surprising, and surprising is not a thing you really need in an operational network - so it's worth understanding configuration types in Junos that are commonly used, but not immediately obvious. 

So, let's have a look at these handy magical blocks of group configuration!

Juniper Home Lab - virtual lab topology on a single physical device

One of the things I've wanted for a long time is a few Juniper devices lying around my home to keep my Juniper CLI skills up to scratch and to experiment with new concepts as I learn them. Sure, you can run great labs in things like EVE-NG, but you ultimately need licensed VM images (and a machine with a fair amount of RAM and CPU grunt for any complex topologies), and those licenses are quite expensive (although if you have a juniper.net login, you can download a free 60 day evaluation copy of vMX router, vSRX firewall or vQFX switch; apparently, you can simply recycle trial licenses - not that this is recommended [see e.g. page 351 of the Junos beginner's Day One guide]). Indeed, even if you (re)use trial licenses, you'll probably need a fairly hefty - expensive - server to run them on, which will cost a similar amount to quite a lot of second hand devices; the key advantage of the former, perhaps, is you're more likely to have a more current Junos image to work with in the virtualised space as opposed to from the old second hand gear market.

Old second hand Juniper gear, however, is quite cheap, and although you won't get support or upgrades, will then also not cost you any ongoing support. I'd be very wary of downloading random Junos images off the internet - some people do seem to share them if you look hard enough. I ordered two SRX 110H2-VA routers off Ebay to scratch this itch (I further scratched this itch with more gear...). I don't need anything particularly fancy, and these units are quite cheap, fairly compact, and lack fans, so they are nice and quiet. There are a lot of basic SRX firewalls available online; as Junos is somewhat consistent across most of the platforms, you will find getting a thing marketed as a "firewall" also lets you learn most of the Juniper platform features for not only firewalling, but switching and routing too from across their portfolio - aside, of course, for those features not supported on this platform or software version. 

By the end of this post, you should be able to create a single router that has 8 virtual routers configured on it with a fairly complex, but easily understood, topology. 

Read on for some ideas... 

Holistic IT education / learning: secure all the things

In July, I witnessed a very interesting PoC in a talk, sketched out against a particular vendor's routers based on the "best practice" router hardening firewall configuration example given in a well recognised, highly thought of book. 

This lead me to thinking about the need for more thorough consideration of IT security throughout careers, and in particular, the danger of blindly relying on other people's information. 

I've embargoed this post until now, because it contains a low-content description of a potential vulnerability, and I can see that steps that should address it have been taken - hence the publication date; this was written shortly after that talk spurred some thoughts...

Interview / job application preparation

I’ve sat on both sides of the interview table several times. I certainly don’t think I’ve mastered either end of that game, but certainly, there are some common key things you need to think about before you submit a CV and again before you hopefully head into a job interview...

Read it, note it, (re)do it, teach IT: How to learn effectively

It's no secret that IT is a career in which you need to keep learning. 

It's also a given that many IT professionals are not given the time, space or resources they need to do this at work, so they end up doing it in their "spare time", to the detriment of other things they might otherwise like to be doing. Others are given this at work, but at a low priority, or in a half-hearted way where you have 8 hours of work a day you're expected to get done every day - sure you can spend some time learning, but you still need to deliver that 8 hours of what the business considers "work"! 

So it makes sense that no matter what we do, we ought to maximise the ROI on our "learning time"!

Dunning-Kruger and Learning

I can't imagine you've never heard of the Dunning-Kruger effect - it is a popular and well known model of actual expertise vs. perceived expertise, and your confidence in them. I think, as IT professionals, it is useful that we know it exists, particularly as we embrace new technology or extend our learning. 

So why is this a big deal...? 

Tune your home network for Work-from-Home / Quarantine / Isolation - "Un-Suck your Wi-Fi"!

I can't authoritatively comment on COVID-19, despite a lot of years in the biological sciences, even some microbiology and a long term, vague (perhaps somewhat morbid) interest in emerging pathogens.

I certainly CAN suggest how you can tune up your home network to ensure it's going to be the best it can be to cope with you, your partner, flatmates, relatives and children (or whatever your domestic arrangement might be!) stuck at home and depending on the Internet as a life-line.

More and more countries seem to be enacting (entirely justifiable) stringent isolation measures for many weeks at a time, so I trust this information will be of some small help during this difficult time.

Funemployment

My wife and I recently moved continents, and I have now joined the ranks of the funemployed, because (for our family) moving was more important that moving to a job. I'm certainly going to miss my old job (because, aside from being given billions of dollars and told to go explore the oceans, "Network Architect" is exactly where I want to be, and I worked with great people and did fun things!).

Read on for some thoughts on how to make the most of this process, and perhaps some ideas of what to do when you move vast distances...

Trust Boundaries and Reliable Backups: Ransomware Edition

A network whose administrators I know quite well has been thoroughly compromised and critical files encrypted, and much configuration destroyed. Even their backups (such as they were) are no more.

This is, to put it mildly, a fairly catastrophic incident for any organisation.

We turned our minds to the issue and thought about how we can prevent similar things happening to us...

Happy Eyeballs. Unhappy user.

As part of the migration efforts to IPv6, many programs implement a system known as "happy eyeballs". The basic premise is that sometimes, IPv6 "is flaky", and after a while, you should give up and take the IPv4 option - resulting in some "happy eyeballs". In a dual stack system, IPv6 is preferred.

Well the thing about this is it is S L O W... and users (not unreasonably) get grumpy about it. Here's a case where something went wrong, and *everything* was subjected to this delay.

Port Mirroring in Junos

So sometimes, the manual isn't quite detailed enough...

At the moment, our telephony people are having some issues with various things like handsets logging themselves out under certain conditions.

Vendor support has requested packet captures, and rather than schlepping around to the four corners of campus, dropping off laptops by each switch stack, I thought "wait, Junos does port mirroring, and it looks straightforward".

It is, and it isn't...

Glitchy RPKI OV and uRPF: one hell of a match

I've previously written about RPKI and mentioned some of the glitches. It looks like there are some other fun interactions to be had if you're implementing all the "best practice" internet edge routing for your customers...

One year on, in a different kind of school...

A year ago (to the day), I started what I would seriously consider a "dream job title" - that of Network Architect at a University (at the first place in sub-Saharan Africa to have an Internet connection - so long ago that its first IP address allocation was done within an RFC!). It ticked all my boxes in terms of favourite things to do, and promised to throw me in at the deep end in a much more challenging environment. I didn't have any particular desire to leave my last position (which I enjoyed immensely), but when I got two phone calls some time apart strongly suggesting I ought to apply for the position, and with an interesting list of "things we need done", after much hand-wringing, I jumped at the chance, and made it through the selection process. #GreatSuccess.

Securing Internet Routing: RPKI OV and ROAs

For some time now, I've had a ticket in my queue to "Investigate RPKI". A few weeks ago, we experienced some strange internet outages that turned out to be because not all is well with RPKI Origin Validation at one of our upstream ISPs...

On the State of Firewalls: are NGFWs (becoming) obsolete?

Between the last blog post and this one, I’ve moved from K-12 into Higher Education, at the first place in Sub-Saharan Africa to have Internet connectivity. This is a vastly different environment in some ways – in particular, firewalling is quite different. You’re dealing with a user population that is entirely adults. Some of those adults engage in legitimate research on things that some would consider a bad idea (malware) or “morally dubious” (porn, pop-up ads, etc.), or needs unfiltered traffic (network telescopes, honeypots, big data “science DMZs” ). The particular University I work at has generally had a liberal outlook with regards to personal freedoms (and concomitant responsibility) – I think that’s generally a good thing and exactly where higher education should be.

We’re currently looking at doing a hardware refresh of our ~7 year old enterprise firewalls – mainly because the support on the current solutions is eye-watering. The present solution works fine (although it has quite limited capacity for logging – about 8 hours of our traffic), and it’s approaching vendor EoL status. Interestingly, even moving to a newer (and, because Moore’s law, more performant) hardware platform from the same vendor saves us money over a number of years. So we’re thinking about what we need, and that’s prompted some musings about the state of firewalls…

On PABXs...

We eventually decided that our existing PABX solution no longer met requirements. In particular, it was very opaque, and extremely expensive, with a licensing model (and vendor locked-in handset requirements) that were punishingly expensive.

We considered "DIY" with something from Yealink (most likely an S300), with an interim set of BRI and POTs links to move away from Avaya onto another platform, before investigating SIP trunks for the "uplink", but we looked at our work schedules (and the offers that came in) and we ultimately decided to get a VOIP telecommunications company to help us install it, implementing SIP from launch.

Here are a few things we learned along the way...

GSuite mail gateway using Ubuntu and Postfix

Whilst a lot of vendors will tell you they "support Gmail", it turns out the level of support can be... iffy.

In the end, it is often easiest if you create an email "gateway" that leverages the likelihood of just about everything on your campus being able to throw SMTP at port 25 (even though that's deprecated for mail submission), alongside GSuite for Education's SMTP email relay functionality.

This is particularly important once you start getting serious about email security, and that email from your domain MUST flow through particular email servers (because of SPF, DKIM & DMARC).

Read on for more!

MPLS causes some weird effects - aka Why is traceroute so much slower than ping for some hops?

Recently, my attention was drawn to something Odd about our traceroutes - namely, that traceroute and ping to an intermediate host on a route could have wildly different values.

This really bothered me, once I was forced to think about it.

I had previously assumed (wrongly) that the unexpectedly high second hop RTTs  (and similar subsequent) values across our service provider were due to low priority in processing ICMP/tracereoute packets (many routers treat these things as low priority, for various good reasons).
That was a good enough "explanation" that I'd not really thought beyond that (or, it hadn't bothered me enough to get properly intrigued).
And I hadn't done pings to those intermediate hosts, and compared them side-by-side.
Shame on me.

And sure, ping and traceroute by default use different protocols (until you do traceroute -I).
But that's not it either.

Maybe traceroute sends so many more packets at a time than a ping that you hit a rate limit (1 per 500ms is a rate limit on some routers)?  ping is ~1 per second; traceroute fires out loads in groups of 3 spaced per hop (well, TTL increment) quite closely together.
That's not it either.

Maybe a firewall was breaking things?
But no, that makes no sense; both in this case are ICMP Echo, and it's unlikely they're going to treat ICMP Echo to destination A differently to Destination B on the Internet.

I'm familiar with a bunch of other common pitfalls with interpreting traceroutes, but this wasn't one of those.

As someone who really likes networking, this should have prompted investigation long ago, but it's not bothered me enough to go work it out (aka "I had more pressing concerns").

Until someone said "Explain this" and presented a side-by-side ping and traceroute with Odd Results...

Then, of course, you start THINKING about the problem, and, if you're not familiar with the underlying configuration and particularly some potential configurations of service provider networks outside your own control will probably cause you to pull your hair out.

So why...?