Comparing Cisco and Juniper – Why doesn’t Cisco do this?

In Cisco land, we have all learned that when making changes to a remote router, you have to be ready for anything. Most admins that I know start any changes with the command:

Reload in X ( x=time in minutes to make and test changes)

The idea being that if a command is made incorrectly, and the remote router stops responding, it will reload itself in X minutes, and become accessible again since the changes would not have been saved. It’s a good idea to do this, and it’s saved my butt a few times.

However, it’s not the most elegant solution. If the router is a production level router, and the change that made the terminal unresponsive hasn’t affected it’s ability to route, it’s still going to reboot. Clients will figure out that you screwed up while they wait for the router to post, load, rebuild routing tables, etc. Darn those fat fingers, and enter key muscle memory.

Enter Juniper’s Commit Confirmed X command.

As some of you may know, changes in JunOS aren’t applied to the running config until they have been committed. (ANOTHER great idea.) Thus, it is easy to check, and recheck your changes without losing your session because the commands have yet to be applied. Once they are committed, they are all applied at once.

Now, I know what you are thinking. If you are able to cue all of your changes, review those changes for errors, and then apply them all at once, you shouldn’t ever need to rollback those changes, right? *Clears throat* Right.

BUT, if you did, somehow miss an important command, or maybe that subnet should have been a /22 instead of a /30, that’s where the Confirmed part of the command comes in. If the router stops responding, the changes are rolled back in X minutes to the previous config. No reloads, no angry emails, no voicemail, and no meetings.

To stop the router from rolling back those changes, simply commit the changes a second time after it is clear everything is working (and before X expires).

Filtering LLDP and CDP packets with Wireshark

I have written an update to this post, which can be found here. It has better information, better filters, and a better attitude.

We’ve all seen the picture of the IDF which looks like a tornado has ripped through it, with cables hanging everywhere. Generally there are two reactions. The type A people in the room shudder and wonder how anyone could work in that environment. The type B people shrug, and think about all of the ways that it could be worse.

Sadly, we don’t always have control of the cable management in the places we work. Whether it is a customer’s site, or we have managers that don’t care about organization, we will eventually find ourselves entangled in cable, trying to trace a wire from patch-panel to switch.

What if it was easier than that? Anyone who has ever had the pleasure of using a Fluke Optiview, knows that it happily displays CDP info right there on the home screen. The problem there exist when management sees the price point of a Fluke Optiview and begins laughing uncontrollably. There is a better cheaper way though!

With the proper Wireshark filters, it’s quite easy to find the port ID using either CDP or LLDP for those non-Cisco devices.

The best CDP Wireshark filter that I have found and used for years is this:

ether[12:2] <= 1500 && ether[14:2] == 0xAAAA && ether[16:1] == 0x03 && ether[17:2] == 0x0000 && ether[19:1] == 0x0C && ether[20:2] == 0x2000

Sadly, I don’t remember where I found this, to give credit, it was a long time ago.

For LLDP, I’ve found a much simpler capture filter that seems to work well:

ether proto 0x88cc

Yes, that is it. I found this on Wireshark’s website.

Hopefully, this will help you like it has helped me to identify ports without doing the IDF Tango.

Thoughts on the new job…

First, what were they thinking, hiring me?
Really, I’m a Cisco network engineer, with loads of Microsoft experience. Cisco wired, wireless, voice, security, you name it, I’ve done it. Microsoft NT, 2000, 2003, 2008, IIS, SQL, AD, yep, yep.

The new job:
HP.
Juniper.
Linux.

I haven’t felt lost in IT in a long time. I will say, I LOVE to learn new things, so I think I can become a very effective team member in short order.

Next, what a cool company!
From the Company Concierge, workout center, free drinks, masseuse appointments, to my own four walls and the “fun room”; everywhere I look I see things that make me laugh at my experience while working at Honda. I’m working with a strong team of individuals, who know what they are doing, and care about the future of the company. In fact, after working at Honda for 4 years, I’m not quite certain what to do: listen to the silence that comes with having a private office, or listen to PacketPushers, some other podcast, or even music * gasp* since I can do so without incurring the rath of those around me.

Finally, what I’m learning.
Luckily, I learn well under pressure. I’ll continue to post here about the things that I’m learning through these new challenges. Maybe I can help another Cisco or Microsoft engineer break free in the process.

For example, no matter what, DO NOT press CTRL+ALT+DEL while at a Linux machine to lock the station. This is not Windows.