Juniper Interface-Range: A Use Case

It’s holiday break! That means I have more discretionary time for topics such as… Juniper interface-ranges! Yay! Right?

Unenthusiastic Fry from Futurama

Ok, not the most exciting topic in the world, but hear me out — I think there’s a pretty good use case for using Juniper interfaces-ranges, which is a Junos feature that I think really stands out from other NOS’ that I’ve had exposure to. What is the use case? Simple: campus switch port configurations.

What is a Juniper interface range?

Let’s start by explaining what it is and is not, because if you’re coming from other vendors, the concept may be foreign and/or you may conflate it with features from others.

An interface-range is a logical construct in a Juniper configuration that aggregates multiple port configurations and places them into one configuration. Here is an example:

Here I have two interfaces that are members of the interface-range ‘workstations201’; they both are access ports and both belong in VLAN 201. Here’s the configuration if I were to separate out the interfaces into separate configurations:

As you can see above,  interface configurations are often repeated multiple times if you configure them one-by-one, but interface-ranges simplify port configurations and reduce the number of lines of these repeated configurations (in a 48-port switch with each port the same, theoretically using an interface-range could remove up-to 384 lines). If you need to change a port to a different VLAN or different configuration, simply delete the interface’s membership from one interface-range and place it in another.

What interface-ranges are not: CLI commands for making mass interface changes. For that, Juniper has the wildcard range command. For more info on that here.

Configurations Beyond the Individual Interface

So reducing the number of lines of configuration is great, but so what? If you come from the world of other vendors, you’re already used to the idea of keeping port configurations and their protocols all in the interface’s configuration, so configuring edge ports this way isn’t going to offer you much.

In the Junos world though, interface’s don’t hold all the configurations for the ports. For example, if you want to configure a voice/auxillary VLAN, that configuration on Junos (well, in post ELS change*) is in the switch-options stanza of the configuration. Sure you could configure switch-options like this and have all access ports configured for VoIP like this:

But what if you have devices that will utilize the voice/auxiliary VLAN, but you want them specifically in a separate VLAN than your voice/auxiliary VLAN? You would have to configure each port specifically for that protocol like this:

If you needed to make a change for an interface, and you’re doing this via CLI, managing these changes could get daunting.

Let take another place where configurations aren’t located in the same location: spanning-tree. It’s not enough in Junos to just turn on spanning-tree on all ports; you need to specify which ports are edge (to block BPDUs) and which ones are a downstream switch (ignore BPDUs). Often I have seen Junos configurations for campus gear look like this:

But from my experience, all that does is turn on RSTP, and ‘bpdu-block-on-edge’ does nothing because no ports are designated as ‘edge’. In order to accomplish the above, you need to designate edge ports and ports for downstream switches (no-root-port):

Great, so now you’re having to manage port configurations in three stanzas, and you’re adding a hundreds of lines of configurations to each switch configuration. WTH, Juniper?

If only there was a way to simplify this…

Where Interface-Range Shines

Interface-range does simplify all of this and reduce the lines configuration! Instead of blabbing on and on about this, let me just show you exactly how this is simplified:

Using interface-range, we can treat the interface-range as an interface object and apply configurations to it just like you would individual interfaces. For ports needing voice/aux VLANs, we can configure only the ports needing it; for spanning-tree, we can designate edge and no-root-port more simply.

Another great example: what if you needed to quickly power cycle all IP speakers? Sure, you could set the following in CLI:

But what if you’re working in a virtual-chassis, and your wildcard range command won’t work to get all the ports in one line? Using interface-range, you can get them all in one line like this:

Then BAM! You’ve turned off PoE and you can just rollback the config (or delete it, whatever floats your boat), and the IP speakers are rebooted.

Interface-range, for me, just seems like a more efficient way of managing ports configurations (even if you automate). Here’s an example that brings it all together:

Why Not Use Junos Groups Instead of Interface-Range?

From my experience, and from I can tell from working on campus switch configurations, groups don’t seem to offer the simplicity for port configurations like interface-range does, and, from all that I can gather, I cannot configure VLANs for interfaces and interface modes with  the group feature like I can with interface-range. When dealing with hundreds of campus switches and VC stacks, with all the port additions and changes, it just seems like interface-range is best approach for campus switching.

That said, once you get into the distribution and core layers, I’m less certain about the applicability for interface-range, but groups seem to be better suited here.

Edit (20191124.1945) – For a perspective from some people with more experience with apply-groups than myself, check out this post I made on the Juniper subreddit. There’s even examples for how to approach this from an apply-groups model. That said, I still think interface-range is a better approach for campus switching simply for the operational benefits you get with using them.

Caveats/Miscellaneous

There are a few caveats to keep in mind with interface-range, so I’ll note them quickly:

  • You can’t stage interface-ranges. An interface-range needs a member in order for it exist, so you can’t preconfigure them (although perhaps you could comment them out), and if your interface-range loses all members, you’ll need to either delete them or comment them out. Edit (20191124.1945) – This isn’t entirely true; one comment on Reddit suggests creating fake interfaces to stage them, but I’m not entirely sure if there aren’t any effects with that.
  • There are two ways to add members: member or member-range. I prefer to avoid member-range because if an interface changes in the range, you have to break up the range (IIRC). That said, if ports are static, you could use member-range or member (wildcard) statements to configure members.
  • I have had the CLI bark, but still commit, when interfaces were blank/missing, but had configurations in the interface-range area. I should verify this, but as of the time of writing this, this is what I recall.
  • Network admins/engineers who come from other vendors can get confused with interface-ranges, especially if you mix interface-ranges and standalone interface configurations. They make think something is missing and so forth; just make sure to brief them on it.

Final Thoughts

Junos has a lot of ways of accomplishing what you want, so what I’ve demonstrated here is just one way of accomplishing interface configurations; but from my experience, this seems like the more efficient way for campus switches.

Please let me know if there any mistakes in here or if you have a different way of using interface-ranges. Would love to be corrected or see other uses!

Thanks for reading.

* Enhanced Layer 2 Switching. Junos changed how configurations were done a few years back. Follow the link for more info.

Juniper EX3400: How to Recover from PoE Firmware Upgrade Failure

Did you know Juniper EX switches have PoE firmware updates to be applied?

Chelsea Lately - Great question. I had no idea.

Well, I didn’t until about a year ago when I did an upgrade and was checking on PoE power. Looking at the controller info from show poe controller, I noticed the following:

Juniper poe firmware available

Huh. Ok. Well, I’ve got a eight unit stack here, and the Juniper EX software upgrade is usually pretty solid, so let’s upgrade it — and it goes off without a hitch.

Fast forward nine months later, and I’m running into strange issues with PoE and Mercury door controllers, particularly model ‘MRE62E’. Basically the Juniper switches won’t provide power to this model, but the older MRE52’s had no problem. Checking out the firmware version using show chassis firmware detail, I noticed that the switch had the older 1.x firmware and not the new 2.x.

PoE firmware 1.6.1.21.1

 

Alrighty then — let’s upgrade this stack. I upgrade the software using the latest JTAC recommended version (staying in 15.x), then upgrade the PoE firmware — no problem. Door controller is now getting power, I see a MAC address. Everything is hunky dory.

Now let’s upgrade this other stack.

No problems on EX software upgrade. Great. Now upgrade PoE firmware…

Ten minutes later, I get the following on the terminal:

Magic Thread Message

Of note, and the thing that made me panic, was that out of nine switches in the stack, only one came back online. Checking the firmware versions, I see the following:

Various PoE firmware versions, some missing, some 0.0.0.0.0, only one 2.x

Okay… F***. Well, let’s reboot the stack; perhaps a reboot is needed*. After reboot, I get the following:

PoE Device Fail on FPC 8. All but FPC 2 are missing.WTF.

Guy shaking head mouthing WTF

In the past when I’ve done a PoE firmware upgrade (between now and when I first learned about it), I had no recourse but to RMA the switch. Well in this case, I don’t have eight spare switches to fill this temporarily while I wait for an RMA! WTF am I going to do?!

Solving the PoE Firmware Upgrade Failure

If you’re in the same situation as I was in, take a deep breath — you’re not dead in the water.

There are two scenarios for a PoE firmware upgrade failure that I’ve encountered, and I have a solution for both:

  • PoE Firmware Failure #1 – After firmware upgrade, you see a mixed result of firmware versions, some being 0.0.0.0.0, some being correct (2.1.1.19.3**), and some missing/blank (see picture above showing mixed/missing versions)
  • PoE Firmware Failure #2 – Perhaps you did as I did and rebooted and the PoE controller shows one with the message ‘DEVICE_FAILED’ (see above)

Solution for PoE Firmware Failure #1

If you encounter this failure, DON’T REBOOT THE STACK. You’ll make your life harder if you do.

Next, Juniper TAC (finally) has a solution — and it requires remote/on-site hands. If you’re going on-site or working with someone remotely, get yourself a cup of coffee (or beverage of choice) and some podcasts lined-up, because you’re going to be doing this awhile (~10 minutes for each switch/fpc).

From their site, the solution is the following (with my own notes):

  1. Power cycle the affected FPC (re-seat the power cord). Do not perform a soft reboot.
  2. After the FPC joins the VC or the standalone device reboots, execute one of the following commands in operational mode:

    OR

    JTAC Note: You need to change the fpc-slot number accordingly. Also, it is recommended that you push the PoE code one by one instead of adding all members in the virtual-chassis setup. (Emphasis mine)
  3. After the above command is executed, the FPC should automatically reboot. If not, reboot from the Command Line Interface.
    Note: Be patient and wait. No, seriously…wait. It takes awhile. If you need to reboot, you’re rebooting the whole unit AFAIK:
  4. After the FPC is online, check the PoE version with the show chassis firmware detail command. The PoE version should be the latest version (2.1.1.19.3) after the above steps are completed.
  5. If the version is correct, the PoE devices should work.
  6. Repeat the above steps to upgrade the PoE versions on other FPCs in the virtual-chassis setup.

The one thing to note that when it’s doing its upgrade is that you can see the progress with show poe controller, but at some point it will hang at 95%, then disappear, then come back, then the process will be complete — in other words…WAIT, unless you want to try out the solution for failure #2. 😆

Solution for PoE Firmware Failure #2

In this scenario, you rebooted the stack and something failed. The following is similar to solution #1, but the failed PoE controller requires to basically upgrade it twice. The steps:

  1. Execute the following command to reload the firmware on the FPC:

    Note: You need to change the fpc-slot number accordingly.
    The PoE controller will disappear when you run show poe controller, then come back and start upgrading like this:
    PoE firmware upgrading
  2. After the firmware upgrade completes, the firmware will likely be incorrect (it always was for me). Power cycle the affected FPC (re-seat the power cord). Do not perform a soft reboot.
  3. After the FPC joins the VC or the standalone device reboots, execute one of the following commands in operational mode:

    JTAC Note: You need to change the fpc-slot number accordingly. Also, it is recommended that you push the PoE code one by one instead of adding all members in the virtual-chassis setup. (Emphasis mine)
  4. After the above command is executed, the FPC should automatically reboot. If not, reboot from the Command Line Interface.
    Note: Be patient and wait. No, seriously…wait. It takes awhile. If you need to reboot, you’re rebooting the whole unit AFAIK:
  5. After the FPC is online, check the PoE version with the show chassis firmware detail command. The PoE version should be the latest version (2.1.1.19.3) after the above steps are completed.
  6. If the version is correct, the PoE devices should look like this:
    Successful PoE firmware upgrade
  7. Repeat the above steps to upgrade the PoE versions on other FPCs in the virtual-chassis setup.

Just like solution #1, one thing to note is that when it’s doing its upgrade you can see the progress with show poe controller, but at some point it will hang at 95%, then disappear, then come back, then the process will be complete — in other words…WAIT! You don’t really want to re-apply this whole process, do you?

Final Thoughts

Here’s the kicker for me: I’ve had this work just fine for stacks and single switches alone, and fail on stacks and single switches alone — I can’t find the common denominator here. Perhaps there’s a hardware build that has this more than others, but I can’t figure it out. The official documentation doesn’t hint on a best practice for this (other than maintenance hours), so I’m uncertain on the best approach.

Here’s some ideas I have to change my PoE firmware upgrade procedure (unsure if this will help):

  • Turning off PoE on all interfaces
  • Upgrading one at a time.
  • Trying an earlier version of the JTAC software, the going to the latest recommended. Example: I had no problems with 15.1X53-D59.4 or 15.1X53-D590, but the sample size for determining that is small (only two stacks attempted).

Time will tell.

Hope this helps! If it doesn’t I’d love to know the different experiences others have.

* I swear I saw a message that a reboot is required, but I can’t confirm this (I didn’t screencap it)

** There is a version 3.4.8.0.26, but that’s on the 18.x software version line, and it requires a whole different set of upgrade procedures. This is outside the scope of this post.

ztpgenerator: A ZTP Python Script for Juniper Devices (Maybe more?)

This is a script I’ve been working on for simplifying the ZTP process for Juniper switches.

https://github.com/consentfactory/ztpgenerator

What does it do?

  • Updates ISC-DHCP for ZTP devices (creates DHCP reservations)
  • Creates Juniper configurations based on Jinja2 templates
  • Can also create virtual chassis configurations if desired

There’s some pre-work that needs to be done for set up, but it’s fairly simple to deploy and doesn’t require a lot.

All of the documentation is there on Github.

Hoping this helps others out there.

Juniper Lessons Learned Compilation

My experience with Juniper Networks and JunOS was never too deep, especially since I was trained in the Cisco world. Working for a VAR that sold Juniper gear and offered system services, I was a system engineer that knew enough about Juniper gear to get servers connected and off to the races. Fast-forward a few years, and being bored with system engineering/administration at my organization, an opportunity came up because of my Juniper experience to join the network engineering team and I grabbed onto it.JUNOSThis post is just a quick compilation of things I’ve learned about JunOS that I thought I’d share, be it good, bad, or maybe even ugly. Some of these things you can learn from the ‘Day One’ books, but I feel like some things just aren’t that clear for whatever reason.

Showing Juniper Configuration As Commands

Coming from the Cisco IOS command line world, I was always a little annoyed with the configuration of Juniper because it was in a dictionary/JSON type of format. I mean, it’s great for reading and breaking down configurations into a structured data format, but it always felt a little inefficient on display space, and if you need to make a quick change to copy-edit-paste the configuration, it’s a little bit of a pain.

Then I learned about the ‘display’ command, which opened up a few doors.

Typical Juniper configurations look something like this:

However, you can get your configuration as commands with by piping your ‘show config’ command to ‘display set’, like this:

Which gives you the above configuration like this:

You can then show all the interfaces, make a quick copy-edit-paste change, and be done. Personally, I like this better then the ‘load merge|replace|set terminal” method, but that’s just me.

Even cooler about this is that when you do this, you can pipe your ‘show config’ command to ‘display set’ and then to your ‘match “0/0/0″‘ statement to find the configuration you’re looking for and identify the stanza it’s in. Something like this:

Which, in the above example, which show you all configurations that include “0/0/0” in it, like this:

The other thing about the display command is that it also has a bunch of cool output formats that I think are interesting to look at (‘display detail’ sure is interesting, and ‘json’ or ‘xml’ sure is helpful).

Juniper Wildcard Ranges for Configurations

When you’re in edit mode and you’ve just come from the Cisco world, you’re probably wondering where the heck the ‘interface range’ command is. If you’re like me, you started using ‘interface-range’ statements and just assumed JunOS is just quirky and resigned to not having range commands.

Well, you’re in luck if you’re reading this because JunOS does have the same feature and the command is ‘wildcard range’.

In Cisco, you may be used to doing something like this:

With Juniper, it’s like this:

Commit Sync By Default on Virtual Chassis’d Systems

This is a small one, but I thought it was worth sharing. One thing on any virtual chassis’d switches/routers that you want to remember to do is a ‘commit synchronize’ when you’re committing configurations. However, I’d prefer to not have to type ‘sync’ and just be done with it so I can ‘commit and-quit’ super quick. The solution is simple; run/add this to your config:

Do one last ‘commit sync’ and then this is done automatically.

Juniper Has Rapid-PVST Interoperability

One of the issues my org has dealt with at our Juniper-deployed networks is that our Cisco routers completely block the VLANs for downstream ports when a loop is detected. Almost always it’s that a user has plugged their phone into two ports on the network, and since spanning tree was only set to the default configuration (RSTP) on our Juniper gear, these outages were somewhat frequent.

After doing some research and testing, I found out that Juniper has developed a protocol for rapid-pvst interoperability called ‘VSTP’. I’m still developing and ironing-out the details about our configuration, but here’s the base configuration we’ve done.

Of note, I’ve deleted RSTP because I don’t know the ramifications of keeping it in there (which Juniper notes is supported).

Also of note, if you choose to configure each interface individually instead of ‘interface all’, VSTP has an interface configuration limit of just over 300 ports (I found this out the hard way while trying to configure a 8-count virtual chassis stack). Juniper notes this somewhere in it’s documentation, but they don’t give the exact number and they just vaguely say there’s a limit because of processing load.

I plan on fleshing what I’ve learned with Juniper spanning tree in a future post.

No-More Using That Spacebar

Finally, here’s a super quick one. If you run a ‘show config’ and just need it to print out the configuration before a software update, pipe the command to ‘no-more’ and it will print out the entire configuration, much like setting your terminal length to 0. Command:

Final Thoughts

Don’t really have much else to say other than I’ve come to appreciate JunOS a lot more than when I originally learned it. Overall, I think learning Juniper has made me a better engineer because I’ve had to think about network configuration and protocols in a broader sense, much like how learning Linux made me a better Windows administrator.

From my initial experience going down the Python networking development road, Juniper certainly is easier to work with than screen-scraping with Cisco. NAPALM is certainly my tool of choice as of right now.

SNMP with Juniper, however, leaves something to be desired. For example I added MIBs and configured some sensors in PRTG, but I get weird issues with interfaces such as getting their ‘logical’ interfaces in the form of something like ‘0/0/0.0’, but missing the interfaces that actually work in the form of ‘0/0/0’.

Lastly, what I’ve learned working between Cisco and Juniper is that I just don’t think Cisco has any special sauce with access switching anymore. As a result, what Cisco (and Juniper and others) are doing is selling you a platform instead of just hardware now. You have to buy into a giant platform narrative instead of just letting hardware compete with other hardware.

Kirk Byers Python for Network Engineers Videos

Over the last three months I’ve been transitioning back over to network engineering. When I first started working in IT, my role was as a network technician, but slowly I took on more and more systems administration and engineering, and the work I was doing was mostly with PowerShell.

As a result, my Python skills have atrophied over the years since I was so focused on PowerShell, and if there’s one thing I’ve learned while being put in charge of managing thousands of switches, it’s that I need some scripting in place to handle mass changes.

 

Python Logo

The perfect class to get myself back in the Python game was from reddit, offered by Kirk Byers called “Python for Network Engineers“. It’s a introductory course on some Python basics, which for offered enough to get me going again.

I’m putting this list of the videos online for myself since I hate referencing my emails all the time, but if someone else finds it useful, awesome.

Lesson 1: Why Python, the Shell, and Strings
Lesson 2: Numbers, Files, Lists, and Linters
Lesson 3: Conditionals and Loops
Lesson 4: Dictionaries, Exceptions, and Regular Expressions
Lesson 5: Functions and the Python Debugger
Lesson 6: Netmiko
Lesson 7: Jinja2, YAML and JSON
Lesson 8: Libraries, PIP, and Virtual Environments

Lesson 1: Why Python, the Shell, and Strings

  1. Introduction 
    Video https://vimeo.com/243034300
    Length is 7 minutes
  2. Why Learn Programing?
    Video https://vimeo.com/243905715
    Length is 1 minute
  3. Why Python?
    Video https://vimeo.com/243909371
    Length is 3 minutes
  4. Python2 versus Python3
    Video https://vimeo.com/243912631
    Length is 2 minutes
  5. Characteristics of Python
    Video https://vimeo.com/243918300
    Length is 5 minutes
  6. The Python Interpreter Shell
    Video https://vimeo.com/242411259
    Length is 9 minutes
  7. IPython
    Video https://vimeo.com/242460561
    Length is 4 minutes
  8. Printing to stdout and Reading from stdin
    Video https://vimeo.com/243028886
    Length is 6 minutes
  9. Dir, Help, and Variables
    Video https://vimeo.com/243480156
    Length is 10 minutes
  10. Python Strings (Part 1)
    Video https://vimeo.com/243481392
    Length is 6 minutes
  11. Python Strings (Part 2)
    Video https://vimeo.com/243482081
    Length is 8 minutes
  12. Python Strings (Part 3)
    Video https://vimeo.com/243482871
    Length is 10 minutes
  13. Python String Formatting (Part 1)
    Video https://vimeo.com/243936489
    Length is 12 minutes
  14. Python String Formatting (Part 2)
    Video https://vimeo.com/243956669
    Length is 4 minutes

Lesson 2: Numbers, Files, Lists, and Linters

  1. Numbers
    Video https://vimeo.com/244128549
    Length is 9 minutes
  2. Files
    Video https://vimeo.com/244127459
    Length is 10 minutes
  3. Lists
    Video https://vimeo.com/244257596
    Length is 6 minutes
  4. List Slices
    Video https://vimeo.com/244259492
    Length is 4 minutes
  5. Lists are Mutable
    Video https://vimeo.com/244287000
    Length is 5 minutes
  6. Tuples
    Video https://vimeo.com/244153105
    Length is 3 minutes
  7. Using .join()
    ​Video https://vimeo.com/245464488
    Length is 3 minutes
  8. sys.argv
    Video https://vimeo.com/245464766
    Length is 2 minutes
  9. Linters
    Video https://vimeo.com/245102246
    Length is 6 minutes

Lesson 3: Conditionals and Loops

  1. Conditionals
    Video https://vimeo.com/245104620
    Length is 8 minutes
  2. Boolean Logic (Booleans, Ternary Operator, None)
    Video https://vimeo.com/245112558
    Length is 8 minutes
  3. Python For Loops
    Video https://vimeo.com/245466297
    Length is 5 minutes
  4. For Loops (Enumerate)
    Video https://vimeo.com/245477015
    Length is 6 minutes
  5. For Loops (Break and Continue)
    Video https://vimeo.com/245478016
    Length is 9 minutes
  6. While Loops
    Video https://vimeo.com/245545155
    Length is 5 minutes
  7. Loops Miscellaneous
    Video https://vimeo.com/245552604
    Length is 6 minutes

Lesson 4: Dictionaries, Exceptions, and Regular Expressions

  1. Dictionaries
    Video https://vimeo.com/246157566
    Length is 6 minutes
  2. Dictionaries Methods
    Video https://vimeo.com/246163031
    Length is 7 minutes
  3. Sets
    Video https://vimeo.com/246167477
    Length is 9 minutes
  4. Exceptions
    Video https://vimeo.com/246174686
    Length is 15 minutes
  5. Regular Expressions (Part1)
    Video https://vimeo.com/246184715
    Length is 15 minutes
  6. Regular Expressions (Part2)
    Video https://vimeo.com/246532117
    Length is 7 minutes
  7. Regular Expressions (Part3)
    Video https://vimeo.com/246534450
    Length is 8 minutes
  8. Regular Expressions, Other Methods
    Video https://vimeo.com/246535038
    Length is 4 minutes

Lesson 5: Functions and the Python Debugger

  1. Functions (Part1)
    Video link https://vimeo.com/247570174
    Length is 8 minute
  2. Functions (Part2)
    Video link https://vimeo.com/247581011
    Length is 11 minutes
  3. Misc Topics (Part1)
    Video link https://vimeo.com/247582360
    Length is 10 minutes
  4. Misc Topics (Part2)
    Video link https://vimeo.com/247655574
    Length is 8 minutes
  5. Python Debugger (pdb)
    Video link https://vimeo.com/247724017
    Length is 10 minutes

Lesson 6: Netmiko

  1. Netmiko Introduction and Basics 
    Video link https://vimeo.com/254569911
    Length is 8 minutes
  2. Netmiko Show Commands
    Video link https://vimeo.com/254578980
    Length is 13 minutes
  3. Netmiko and Prompting
    Video link https://vimeo.com/254587832
    Length is 12 minutes
  4. Netmiko and TextFSM
    Video link https://vimeo.com/254611876
    Length is 10 minutes
  5. Netmiko Config Changes
    Video link https://vimeo.com/254614073
    Length is 8 minutes
  6. Netmiko Troubleshooting
    Video link https://vimeo.com/254786724
    Length is 9 minutes

Lesson 7: Jinja2, YAML and JSON

  1. Jinja2 Basics
    Video link https://vimeo.com/257997257
    Length is 7 minutes
  2. Jinja2 For-Loops and Conditionals
    Video link https://vimeo.com/257999160
    Length is 9 minute
  3. Jinja2 and CSV
    Video link https://vimeo.com/258142987
    Length is 5 minutes
  4. Jinja2 Dictionaries and Nested Loops
    Video link https://vimeo.com/258145504
    Length is 11 minutes
  5. YAML Basics
    Video link https://vimeo.com/258161182
    Length is 9 minutes
  6. YAML Part2
    Video link https://vimeo.com/258169427
    Length is 10 minutes
  7. Using Python to Write YAML
    Video link https://vimeo.com/258171559
    Length is 3 minutes
  8. JSON
    Video link https://vimeo.com/258178243
    Length is 5 minutes
  9. Managing Data Structures
    Video link https://vimeo.com/258181273
    Length is 5 minutes

Lesson 8: Libraries, PIP, and Virtual Environments

  1. Importing Libraries
    Video link https://vimeo.com/259422351
    Length is 5 minutes
  2. sys.path and PYTHONPATH
    Video link https://vimeo.com/259423316
    Length is 7 minutes
  3. pip
    Video link https://vimeo.com/259424573
    Length is 7 minutes
  4. Virtual Environments
    Video link https://vimeo.com/259426537
    Length is 6 minutes
  5. Creating a Simple Python Module
    Video link https://vimeo.com/259427586
    Length is 4 minutes

Virtualbox VLANs in Ubuntu

Wanted to add quick note about VLANs, VirtualBox, and Ubuntu.

Virtualbox does VLANs a little differently on Ubuntu than other hypervisors. In order to get a VLANs working for a Virtualbox VM, you have to create a subinterface that is for a specific VLAN (of course, assuming your NIC supports 802.1q tagging). To create a subinterface in Ubuntu, follow the instructions here:

https://wiki.ubuntu.com/vlan

Then in Virtualbox, you set the network interface to ‘bridged mode’, then select the subinterface. Assuming your new subinterface is permanent, the VM will use that subinterface and be within that VLAN.

I’m not entirely sure how to accomplish this for Virtualbox on Windows. It would seem like you would need a separate physical interface, especially for Windows 10 and probably others.

Unrelated note: Virtualbox on Windows 10 is horrible, and so is the native Hyper-V, but that’s for another post, maybe.

Edit (20180705): A few years later, and I can honestly say VirtualBox on Windows 10 is stable now, and has been for awhile. Felt the need to update this. :-p

Skill Atrophy

One of the greatest threats to a young IT professional is skill atrophy. You work hard at developing a skill set over a given period of time, and you even go so far as to earn a certification in such a skill set — and then you quit using it.

The old appropriate is appropriate here: “Use it or lose it.”

Recently while working at a site, and much to my frustration, my skills in router and switch configuration — even just layer 2 and 3 protocols — had started to atrophy because I hadn’t touch a device in five months — then bam! I’m setting up not just layer 5-7 devices, but I’m also setting up layer 2 and 3. I’ve been working so long in the higher layers that I started to forget basics in layer 2 and 3.

 

Layer 3 Switch

 

The hard part is that it was something rather ridiculous. It was a layer 3 switch, and turned the gateway port into a routed port instead of a switched port, thinking that I would separate out a server farm from the layer 2 network that it was attached to through that port. Nothing was getting DHCP requests on this switch and it was frustrating me to no end, not to mention I had to local techs looking over my shoulder and just standing there wondering what was going on! In the end, it was by getting help from my boss and co-worker that lead me down the road to figure out what I had been doing wrong.

So how does one prevent skill atrophy? The obvious answer is to practice, but that may not always be an option, especially if you’re in an environment where the work constantly changes and you’re insanely busy (that’s my excuse at least). Perhaps doing Packet Tracer simulations — for CCNA folks like myself — would be really helpful here.

Another idea is just good documentation, even trying to take a snapshot in time to see what you were doing. Copy your configs and annotate the configs to explain what the heck you were thinking — even encouraging this at your company so that other techs, or future techs, can get an idea of what’s going on.

Asking for help is always an option, especially if you’re really stumped. Time wasted can never be taken back (it’s a sunk cost), so realizing you’re failing bad early on can help mitigate future problems. To quote Freakonomics writer Steve Levitt, “Fail quickly.” However, at the same time, realize your failure is also a learning and/or reinforcement opportunity and will make you a better IT professional.

And of course, there’s also a good IT professionals google-fu, but you should be relying on that constantly, otherwise, are you learning any of this stuff?

All this being said, I’ve learned my lesson and I’m better because of it.