Junos Groups Part I: Basics

On my many IT adventures, I see issues, one of the biggest, is lack of network consistency. Network ports configured one way, others configured another, VLANs trunked to parts unknown, none alike, even if they share the same basic role.

Juniper Junos has a wonderful tool, that seems incredibly underused, that largely resolves this: groups. Groups are awesome, they enforce consistency, they reduce typing, and they make configs shorter, and easier to read.  Here is a quick example of how to use them to manage VLANs on a switch.

Groups are basically templates of configuration settings that can be layered on top of any section of the Junos configuration with the apply-groups statement. There is some globbing support, allowing you to fine grain control when groups are applied. For more on that, check this Juniper article.

Groups essentially follow any subsection of the Junos configuration stanza, with matching patterns in place of variable data, such as interface names, ASNs, OSPF areas, etc. Here are two groups that apply Ethernet settings, namely member VLANs, and port mode, to an any interface they are applied to.

 

In order to apply these groups, we can apply them directly to a few interfaces with the apply-groups statement:

 

In order to see and verify the applied group settings, we pipe the show configuration command to display inheritance:

 

Using groups, one can greatly simplify the configuration of a Junos device, while at the same time enforcing consistency. Groups are not limited to interfaces, and can be applied to virtually any section of the Junos configuration.  In the next part of this series, I will display some more complex examples. Please check back soon!

The Night After X-Mas

Twas the night after x-mas, post-consumerist boom,
Not a synapse was stirring, and this makes me fume.

Debt was amassed as gadgets were bought,
And the fury of installation would soon be wrought,

Upon our humble narrator, he fixes all things,
Like the stupidity of all the world’s ding a lings.

Like little Suzy’s iPOD, it played no new jazz,
For she had not read the manual, what a stupid little spaz.

She lamented and cried, and let loose a shriek,
Without my new iPod, I can’t be unique!

She dashed to her phone, and my digits she dialed,
As I answered the phone, my fury ran wild.

Tech support I answered, how can I help you this day?
You fix my iPod mister, I demand things my way!

You fix my new toy, or I’ll cancel my service,
I could tell from her voice she was a bit nervous.

I let out a sigh, and I said, do you suppose,
You forgot the power cable – it needs one of those?

Silence I heard, and then a slight scuffle,
Then bad music, some ghetto-rap shuffle.

You fixed my iPod! I love you to death!
You are so welcome! “Fucking idiot,” under my breath.

I hung up the phone, but it rang much, much more,
and from all this, there is one thing I adore.

Self sufficient people, and instruction manual readers,
To me, they alone should be allowed to be breeders.

So if you have ever called my number, which I suppose is your right,
Eat shit, goto hell, and I hope you die this very night!

Home Network of Doom Part 2.37: LDP Tunneling

/* This is fluff

This is going to be short and sweet, because it was as easy as tasty, apple pie. I’d been wanting to do this for a while, but working for yourself doesn’t generate tons and tons of disposable income. Being frugal sucks for the mad hacker in me, but I had been holding off on purchasing the last piece of hardware I needed. Enter the deadbeat client. Long story short, sold them on a network overhaul, fixed a few things for them. They bounced a few checks, and I am left holding a new Juniper SRX300. Gee, darn. What they paid that didn’t bounce mostly covered it, so I paid about fifteen bucks for a super nice new router.

Also, I paid for the lifetime Pastebin account, and installed a wordpress plugin to embed them here, I’ll be trying that out for configs.

end of fluff */

If you will think back to the first part of this series, my network was a ring of four major devices, 2 SRX300s, and 2 SRX100s(And the head end SRX210 that doesn’t actually speak MPLS). It looked like this:

Well, I can finally say goodbye to fastE ports in the core. I rewired the whole thing to incorporate the new SRX300, and pushed both of the SRX100s out to the edge, because I do own a lot of gadgets that only eat fastE. Also, I wanted to try out LDP tunneling. So the new network looks like this:

When I rolled this out, I deployed RSVP signaling everywhere, which meant bulk adding new LSPs manually to every existing device just to get the thing working. RSVP signaling lets you do some cool stuff,which I will cover if I ever decide to write part three of this series, but scaling it is indeed a pain. My brute force method lacked any proper planning, and left me with four ingress LSPs and at least 4 egress and transit LSPs on each device. In a proper network, you would clean this up, but I did this live while my wife was streaming Netflix(And she never noticed!). If it was this annoying at my tiny lab scale, imagine what it would be like on a large network.

Enter LDP, which has basically no options, no knobs, and has one truly endearing quality: Configuration scaling. It is so dirt simple, it is not a pain to deploy en masse. Since my SRX100s are now single homed to my core network, RSVP grade decision making is no longer needed, we just need to make sure labels get flung around properly.

As I tweak my graphviz skills, here is a quick and dirty best effort conceptual view of what I am about to describe.

Better image when I figure out how to make graphviz a bit more obedient.

Making LDP work over RSVP is called LDP Tunneling, and is very, very simple. The single homed devices simply need to run LDP and MPLS on their single line back to the core. Since we aren’t running RSVP, no label switched path statements are needed.

 

That is it, easy peasy. On the other sides of those links, the RSVP core speakers need to be talking LDP on their ports out to these edge devices:

 

Now, in order to get LDP signaled paths across the RSVP signaled core, we add the ldp-tunneling option to our LSP statements:

 

On a device that is not speaking LDP, in my case, garage-mpls4, ldp-tunneling is not required on the LSP statements(But it doesn’t hurt anything either). Commit confirmed, and you should be good to go. Don’t forget to commit!

As you can see, this greatly reduced the complexity of my LSPs:

 

Only time I see transit LSPs in my core is when I have a down link, or I am screwing around with wackiness.

Kthanxbai!

Makefile Quickies: How I Make Charts

My current general purpose workhorse is a Chromebook, a first generation Pixel to be exact. As my buddy Goekesmi likes to say, a Chromebook is a knife, an extremely good knife. Unfortunately, it isn’t much else, if I need tcpdump, I drop down to my FreeBSD beast, or my Kali rig, both of which weigh over 4 times as much as my beloved Pixel. Both are toolboxes, very excellent toolboxes, and they indeed contain very excellent knives, but they weigh a great deal. Since 90% of the work I do is on a computer geographically not near me, a Chromebook with an SSH client is more often than not, a very sufficient, and appreciably lightweight tool.

But I am also a huge fan of the UNIX command line way of doing things. I use LaTeX to make most of my documentation, and graphviz to make network diagrams and flowcharts. A Chromebook doesn’t exactly have a full UNIX userland installed, so I can’t just run dot locally. With my pension for working on remote machines in mind, here is how I make charts; I resort to a web server and a Makefile.

Makefiles are great for a variety of tasks, with the added benefit of allowing you to not remember much of anything, you just type make when you want a result. With that in mind, lets examine what led me to this course of action.

Since I cannot run the graphviz suite of awesome locally, I cannot expect to use a local image viewer to view my handiwork. And even if I could, viewing local content on a Chromebook is….. meh at best. It really is designed to be online, all the time, and it shows. The logical solution is to present the images via a web browser, because that is basically what a Chromebook is. I could manually run dot for each chart I make, and enable directory indexes on my apache server, so I can easily find and view them, one by one. Urgh, who wants to type that much, and click that much? Lets create a Makefile that not only generates all my charts, but also creates a simple webpage, so I can F5 to my heart’s content!

So here it is, quite simple, but I think it illustrates an excellent use of a Makefile that is slightly outside the box from their usual task.

 

That is all there is to it, this is how I make charts and diagrams. I tend to symlink this Makefile into whatever directory I am working on currently, so if I want to view older graphs, I just enter a project directory, and type ‘make’. It cleans up the old mess, and generates images for all the *.dot files in the current working directory. This also means that my base Makefile is consistent across uses, as I have been known to introduce, and usually remove, features from this little bit of scripty fun. At one point, I had it traversing sub directories, and generating a hierarchical series of html documents and images, but it was honestly overkill for my needs.

Hope you found this useful, maybe you’ve decided that the lowly Makefile deserves a closer look. I have found little tricks like this save me a great deal of time. Lets face it, time is the one commodity none of us will ever get back.

Semper Fi, kthanxbai!