All posts by egoepfert

Why scripting will save you PT1

In a previous post I talked about documentation and planning for a change, but what can we do to really shorten the time it takes to implement and verify a change?


If we script things out ahead of time we don’t have to use our valuable time during a change window to type things out.  Plus we get to check, double-check, test, and debug all ahead of time to make sure things go how we want them to.

Here are a couple of scripts I’ve used lately to help me get info that I need quickly and format it so that it’s easier to look at.

1) Scripts in SecureCRT.

If you don’t own SecureCRT go buy it.  You can try to get everything done in putty, but a good terminal program will take you to a new level.

You can use several different scripting languages to help you out here.  You can do simple things like have it type commands for you, or complex things like read outputs and make decisions based on what comes out on the terminal.  It’s great for data entry type tasks that are horribly repetitive  but sill need to get done.

This is an example of a script I put together to go through and enter a show command for a list of vlans on a CatOS switch.  It’s sloppy from a code perspective, but it was fast and gets the job done.  (I’m working in VBScript in this case)
Sub Main
Dim counter
‘generic counter variable
Dim Arraysize
Dim RouterID
arr_VlanSet = Array(“1”, “2”, …keep listing your vlans here)
‘sloppy way to populate the vlanset…you can pull this from another file or whatever, but that’s more effort
‘than I wanted to put into this simple script
‘Creates a linear array for holding list of vlans
Arraysize = UBound(arr_VlanSet)
counter = MsgBox(Arraysize, vbOKOnly)
RouterID = “hostname of device goes here”
crt.Screen.Synchronous = True
For counter = 0 To Arraysize

crt.Screen.Send “show spantree ” & arr_vlanset(counter) & vbCr
if crt.screen.WaitForString(“–More”, 1) then
crt.Screen.Send ” ”
end if
if crt.screen.WaitForString(“–More”, 1) then
crt.Screen.Send ” ”
end if
if crt.screen.WaitForString(“–More”, 1) then
crt.Screen.Send ” ”
end if

crt.Screen.Send ” ” & vbCr


End Sub
Remember, these are supposed to save you time on the day, so you don’t need to be elegant in the code.  This goes through my list of vlans, put in the command, waits to see if a space needs to be entered (it does this 3 times) and then goes on to the next command.  If you have longer output than 3 screens it’ll wait for you to put in a keystroke manually instead of just going and missing a command.


More in PT2


Junos, olive, GNS3…should be easy, right? Pt5

Now, you remember that ISO image we made all the way at the beginning?  Well, now we actually use it.

From the command prompt “qemu -L . -m 256 -boot c -hda j.img -cdrom ..\jinstall.iso”


That’ll launch qemu again and mount the image for installation.  Login when prompted


Let’s clear some room to work with:


Mount the cdrom “mount /cdrom”

Create a temp directory for Junos “mkdir /var/tmp/j/”

Change to the new directory “cd /var/tmp/j/”

And make sure you’re actually there “pwd”

Extract the Junos files “tar zxvf /cdrom/jinstall-10.1r1.8-domestic-olive.tgz”



Make pkgtools directory “mkdir pkgtools”

Go into pkgtools directory “cd pkgtools”

Verify that you’re in the right spot “pwd”

Extract pkgtools “tar zxfv ../pkgtools.tgz”


Go to Bin directory “cd bin”

Copy true file “cp /usr/bin/true ./checkpic”

Back up one level “cd ..” (there’s a space in there)

Zip the file again “tar zcvf ../pkgtools.tgz *”


Back up one level “cd ..”

Remove pkgtools directory “rm –rf pkgtools”

Rezip to Junos “tar zcvf ../junos.tgz *


Install Junos “pkg_add –f /var/tmp/junos.tgz”


Here’s where you end up:


“init 6” then ctrl + alt + 2 “q” to kill it

Now we’ve got a working image.  Time for the GNS3 part.  Open up GNS3 and go to Edit > Preferences > Qemu.  Change the working directory, path, and img path.


Go the Junos tab and add your image…make sure to save it


You should now be able to drag Juniper routers into your topologies.


A few things I’ve found:

1)  Connect your links before starting the router, they don’t like changing things once they’re running

2)  They take a long time to boot.  Yeah, it sucks, but at least they work

3)  These images don’t do everything.  You may be able to put in a command and it seems to take, but the feature doesn’t work.  Kind of a pain…

4)  Make sure to save the nvrams and harddisks of your devices in your projects.  With Junos stuff make sure to save while the device is running.

5)  Important: hit crtl+alt to free your mouse from a qemu window should you accidently click in there.


Have fun!

Junos, olive, GNS3…should be easy, right? Pt4

It’ll dump you back to the previous screen with the line selected with an X on it.  Hit the tab key and then enter.


Select 1 to install via CD or DVD and hit yes on the next screen


It’s going to do some stuff now…be patient here, don’t freak out if it doesn’t look like it’s moving for a while.  You’ll see multiple progress bars and finally you’ll get to this…select yes when you get here.


Go down to set root password and hit enter…then type in a password for this image, please remember it


Go ahead and exit when you get to the next screen


Now exit the install…yes, you’re sure you want to exit.


This will restart the qemu application…hit Ctrl+Alt+2 to kill it…that’ll take you to this


Type Q and hit enter to exit. That’ll close the qemu window and take you back to your command prompt.


still not done yet PT5

Junos, olive, GNS3…should be easy, right? Pt3

It’ll do some more stuff and get you here.  Use the down arrow key to get to “Express” and press enter to select.



Press A for use entire disk


Press Q to quit


Select Standard


Press C to create


Type in “2048M” (caps here matters)


Select FS and type in /


Press C to create and 1024M (caps here matters) and select Swap


Press C to create and 100M (caps here matters) and select FS, type in /config


Press C to create, press enter to select whatever is left, select FS, and call the partition /var


Press Q to quit, use the arrow keys to scroll to 8 Users and use the space bar to select the line before you hit enter


Select No on the next screen




not done yet…PT4

Junos, olive, GNS3…should be easy, right? Pt2

Now let’s extract qemu.




Open a command prompt and go to your olive\qemu directory.  Here’s your first command:

qemu-img.exe create j.img -f qcow2 6G

You should see the output below


Next command, this starts qemu:

qemu.exe -L . -m 256 -hda j.img -boot d -localtime -cdrom ..\4.11-RELEASE-i386-miniinst.iso

You’ll get a new window at this point


This window will do some stuff, if you don’t press anything you’ll get to this point.  Select the first option by pressing enter.



Onward to PT3

Junos, olive, GNS3…should be easy, right? Pt1

GNS3 is just about the best thing ever.  If you’ve never used it, you should.  Talk about the amazing things that people will build and publish for free.

For those who are unfamiliar with GNS3 it is a graphic network simulator (g…n…s…get it?).   Basically you get to run virtual routers and switches that actually run IOS (it was primarily designed for Cisco gear).  It’s not a crappy emulator where commands aren’t available and you don’t actually get to see traffic flow, it’s the real deal (well…virtually).  Virtual packets get passed from device to device that you can use wireshark to sniff, you can bind physical interfaces on your computer to virtual interfaces to create even larger networks.  In short, it’s awesome.

If you need to study for a CCNA or CCNP this is the most valuable tool you can have.  I have a friend who has been using it to study for his CCIE, where he has run into some issues, but not many.  Think about how great that is: You can download a program, for free, instead of paying thousands of dollars to build a network rack, plus saving your electricity bill and keeping your friends from thinking that you’re the ultimate geek every time they walk into your place.

That’s enough about how amazing this application is (and the kind and generous souls who have put their time into developing it).  I’ll probably do some posts later about little helpful tricks I’ve found, but on to the main point of this post: Junos and GNS3.

I had a bit of trouble locating a good step by step guide to integrating a Junos Olive with GNS3.  They have posts on their forums and several other people have posted guides to do this, so am I just re-posting?  Kind of.  My problem with a lot of the guides out there is that they were done by people who run some build of Linux or Mac (which I guess would be a Linux build now…right?).

I don’t run Linux  I use Windows.  I know, I know.  “You call yourself a tech and use Windows?”  Yes.  Yes I do.  I’ve tried Linux and it’s great for what it is, but it’s not what I need in a daily OS.  That’s a different rant.

The best thing I was able to find when I was searching was this video on youtube (credit where credit is due).  It’s pretty good and got me to where I needed to be.  There are a couple of parts I modified, but for the most part it follows this video.


Time for the juicy part, the actual setup:

First thing you need to do, download all the stuff.  You can use different versions, but I know these work.  Please feel free to tinker and let me know others work better or not at all.


Save files wherever you like.  For me I found it easiest to create an Olive directory right off the root of the C drive.  As you move forward through this make sure to modify any commands with different file locations that you use.


1)  If you don’t already have it go to and pull the full install package and install it.  I’m using 0.8.3 for this guide.

2)  Grab a copy of Virtual Clone Drive ( and install that.

3)  Grab a copy of Free ISO Creator ( )

4)  …install that

5)  You’ll need qemu.  The file you’re looking for is  If only there was a way to find that.

6)  You need a juniper install package.  I used jinstall-10.1r1.8-domestic-olive.tgz  If only there was a way to find that.

7)  And you’ll need a Free BSD mini package (4.11 in this case) 4.11-RELEASE-i386-miniinst.iso  If only there was a way to find that.


Next we need to make an ISO file containing that junos install file.  Stick the olive.tgz file into a separate sub directory (in my case I called it jinstall).



Now create an ISO


If you’re paranoid you can mount it to make sure that it worked…




This is going to be long so I’m breaking it into multiple posts: PT2 PT3 PT4 PT5

Take your time, document, test, implement

If you do this job long enough you have to replace hardware.  Either hardware you installed or something somebody else engineered and installed.  For branch stuff or access hardware it’s simple, you plan an outage for that segment and swap out the gear.  Datacenter hardware can be much more tricky.  Some challenges that you’re likely to face are proprietary protocols, improperly engineered designs, and the multitude of Macgyver type solutions that were put in place because there wasn’t budget or time to do it right.

First thing you need to do is understand what you have.  Sounds simple, right?  Well, if you get dumped into a new environment you may just look at the documentation that was left for you.  DON’T TRUST THAT!  Old or just flat-out wrong documentation will kill you.  Take the time to go in, fully investigate every piece of hardware you plan on changing.  It’s a pain, but it’s worth the fact that you’ll probably still have a job when you’re done.  And I mean really get in there, check every layer and document EVERYTHING.  Interfaces, cables, layer 2, layer 3.

Next, build yourself a lab if you can.  Make sure you can build your current environment and then practice getting things to how you want them to look when you’re done, noting critical steps along the way.  If you do this you’ll hopefully find the problems before you start the real deal and can plan accordingly.  Here’s an example from a job I’m working on now:

Old firewalls need to become new firewalls and we’re cleaning up the switching topology a bit at the same time.  Now our challenges are the datacenter access switching is old and we’re changing the distribution layer to a different manufacturer.  This gear is going to be replaced later, but this project is big enough already, so we’ll have a different window to replace the access switching.

Before we put the distribution switching into production we’ve pre-configured it all, but we really wanted to test it out.  So I grabbed some smaller switches than our current access layer, but running the same old software version, so all the protocols should run the same.  I knew from my documentation how it was supposed to look when we were done, but as I was checking the final lab I noticed that while the root bridge was correct the port blocking wasn’t was I had expected.  Not a huge problem really.  There were no loops, but something didn’t look right and it’s not the sort of thing you want to try to figure out at 3am.

Turns out that the old switches were so old that they were still using the old-school “short” values to calculate path costs, so a 1gig link between two old switches was getting a cost of 4, while the new hardware was reporting a 1gig link as 20,000.

This little discovery, while it probably wouldn’t have caused major issues allows us to fix our plan, include some new changes to keep link cost consistent throughout the environment and not have to do a “clean-up” project later.  Because I think we all know that “clean-up” projects never get funded or prioritized high enough to ever get completed, so you’re left with stuff that isn’t right, and that you know isn’t right.  Which makes just about every engineer I know a little crazy.

Obviously if something breaks and you need to get a new solution in you don’t have time to do all of this.  But if this is a planned project you’ll feel way better in the end knowing that your documentation is correct and the design that is in place is one you’re fully happy with.

listing vlans

I’ve recently had to verify vlans on some switches.   Normally in a Cisco switch I look at the config for this, just do a show “run | section vlan” or maybe some “show vlans” command variations.  Now being new to Junos I tried a basic “show configuration | display set” and got to the vlan section…what a mess.

The output in the config is sorted by the name of the vlan.  Not very helpful when you have a list of numbers you want to check off quickly. “show vlans sort-by tag brief ” got me as close as I was going to get to a list of numerical vlans on the switch.  It’s at least sorted by the right field, but still displays the vlan name first.

show vlans

Serial numbers

Kind of a simple one here that you could totally figure out on your own, but I had forgotten to write down the serial numbers on some gear that I put in a remote office.

“show version” will get you:



Junos release

“show version detail” will get you the above and a bunch of other release and build numbers for software.


“show chassis hardware” is what I was looking for.  For each piece of hardware in there:



Part Number (helpful for putting in orders for replacement parts)

Serial Number (hooray!!!)


Simple, I know.  But some people may not look under chassis commands for serial numbers.  I know it wasn’t my first instinct.


Oh, and on Foundry FCX-24GS (at least) it’s “show version” to get the serial number.  Hope that helps a bit too.


Visio drawings

There’s a tendency for us engineers to make our diagrams and drawings how they look in our heads.  The problem is, when I look at my diagrams I see everything that’s there plus some stuff I keep in my head.  I also tend to ignore the aesthetics of the drawing because I’m more interested in the actual solution that I’m trying to depict rather than the picture as a whole.

Drawings that we make for ourselves can be a mess.  They’re only going to be looked at by us so it doesn’t really matter.  More often than not those drawings that we start to make for ourselves quickly turn into our working documentation for a project.  Now we’ve got a totally different beast.  Now we’ve got something that needs to be presented to change boards or managers for approval.  We’ve got a document that other engineers, both present and future, will refer to in order to figure out why we did something.

Too often I get to these meetings or go to review some artifact document and things are a mess.  There are several things that I think make drawings a mess, so here are some that I think are easy to avoid and will make your life easier when you’re trying to convey the concept behind the drawing to non-engineers.


1)  If you can avoid lines crossing over each other, do so.  I think this is my biggest pet peeve.  Yes, you will have to take more time.  Yes, you will have to “correct” the connector lines.  They might even have to go to different connection points.  You may even have to move things around to avoid crossing lines.  Here’s a fun way to practice:


2) Don’t try to fit too much into one drawing.  It sounds simple, but man I see way too many drawings that try to include EVERYTHING.  Do a different page for each OSI layer.  It will make your life easier and will make it much more simple to explain to non-engineering types.  If you feel you must put everything one drawing set different elements to different layers.


3) Round corners.  I don’t think people fully appreciate how much better shapes look with rounded corners.


4) Before you are finished with the document set a background.  Even if it’s plain white it will make your presentation more clean.  Connection lines will be much easier to follow without the grid pattern in the back.


5) Fill your shapes and use contrasting text colors.  One of the best tips I saw (I think it was on was to set your fill color in your shapes to a strong color, change the lines on the outside to a shade of grey, and make the text inside white.  It’s a simple thing, it takes but a second and people will compliment your drawings in meetings.


Here is an example of what not to do:

ugly visio


Things cross…everything looks the same, and the background is the default grid.  This is what you get if you just draw shapes and use the connector tool.  While this has become the norm I find it lazy and it won’t really impress anybody in a meeting.  Remember, the ones in the meetings that care about how things look often are the ones in charge of your paycheck, so let’s try to impress them, shall we?

much better visio

So in this example we still have lines crossing over, but that’s unavoidable with the topology.  I thickened the lines so they don’t look so dainty, including the borders on the shapes.  We changed the fill colors of the shapes, rounded the corners, changed the text to white, bolded the font, and changed the crossing connectors to “straight lines”.  Much better looking.

So there are the first few tips.  I’m sure I’ll have more.  Hopefully they help.