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.