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!