HP IMC – Mass Recover Active Alarms
Posted by netmanchris in HP IMC on May 30, 2012
This is going to be a quick blog.
So sometimes in IMC when you are first getting things up and running, people make the mistake of leaving their alarms for too long. Or they just alarm on everything and don’t filter out unnecessary alarms. I’ve actually seen one customer who had over 40,000 current alarms in their system.
Even at 200 alarm a page, that’s a lot of clicks to acknowledge/recover them all.
So the question has come up: How do I do a Mass Recover on all current alarms. It perhaps would be nice for a big red button,
but instead you’re going to have to follow the following procedure from the servers console ( not the web interface ).
Steps:
1. Stop imc OR just stop imcfaultdm.exe in DMA
2. Access “IMC_DIR\server\bin” from the command prompt – ( most likely c:\program files\imc\server\bin)
3. Run “start_env.bat”
4. Run “imcfaultdm.exe -clean”
5. Start imc OR just start imcfaultdm.exe in DMA
note – make sure you run this from a DOS (cmd.exe) window or it won’t work. ( windows environmental path variables )
That’s it. It’s not a big red button. But it works.
@netmanchris
Not a SPOG… but a Green House
Posted by netmanchris in IT Musings, ITSM, netman on May 12, 2012
So in my last post. I asked the question: How many Single Pane’s of Glass do we have? Does anyone actually WANT a SPOG?
I got a few comments, and the more I think about this, the more I think the answer is a resounding
HELL NO!
( quote from @neelixx )
There’s a lot of talk in the industry right now about the SPOG, and although I may be not popular for saying this, but I don’t think ANYONE wants a Single Pane of Glass to manage their entire IT infrastructure.
Let me say that again…
I don’t think anyone wants a single-pane-of-glass TO MANAGE THEIR ENTIRE IT INFRASTRUCTURE.
No. I’m not yelling, I’m just using the CAPS to emphasize the last part of that sentence, because that’s where a lot of the industry right now has started to go sideways on this concept.
Not a single-pane-of-glass… but a Green House.
Take this cube above. It’s actually built from six single-panes-of-glass. Six Unique perspectives looking in on the same contents.
Now there may be a debate on how many unique perspectives there are in any given IT infrastructure, but I think it’s safe to say that each one has a valid set of requirements and a certain way of looking at the infrastructure.
You can also see how the SPOGs connect at the edges. The blending of data between the different perspectives.
Now how does this play out in reality?
Let’s look at HPs IMC. This product is built specifically from a network perspective. And HP makes no apologies for that. It’s completely homegrown in HPN, not a set of multiple products from multiple acquisitions. ( ok… so maybe it’s a single product from a single acquisition, but the point is it’s all from the same place. )
IMC is built with the Network Professionals perspective in mind. Does this mean that I can’t do server management from within this tool? Absolutely not!
But is it the BEST place to do server management? Absolutely not!
As I tweeted out tonight, I don’t think anyone would want to do firmware mgmt from a network tool.
But… there are network based services, like DNS, DHCP, NTP, RADIUS, etc… that live on SERVERS but are of particular interest to the Network Professionals.
Or what about Virtualization? Again, IMC will give you direct access to the Networking Specific areas of interest in VMware and HyperV.
Does that mean that I’m going to use IMC to build and manage VMs? Absolutely not!
Does that mean that I”m going to use IMC to track network stats, configure vSwitches, and manage the VLAN interfaces on port groups on my ESXi hosts?
ABSOLUTELY YES!
Why? Because vCenter really isn’t built for network people to do network tasks. I’m not saying this is a bad thing. It was designed for the Server Professional ( the Virtualization Professional?) to manage the specific areas of interest ( CPUs, Memory, VMTools, FT, HA, Virtual Storage, etc..) that they require to do their job.
Now look at the cube above… imagine that IMC is one of those sides, vCenter is another, HP’s SIM is another. Maybe Microsoft SCOM is in there?
All of those tools have integration points between them.
All of them have a perspective on the exact same infrastructure.
All of them provide the right tools for a specific IT Professional to get their job done.
I understand that desire for a single tool that’s going to manage your entire IT infrastructure, but I just don’t know if that’s ever going to be a reality simply because there are way too many moving pieces. I can’t imagine an interface that would allow the network people to get what they need, the server people to get what they need, the storage to get what they need, etc…
Maybe just ensuring that the complimentary edges on our individual SPOGs are well lined up, like a green house, will allow the IT infrastructure to flourish.
Am I wrong? Right? Let me know what you’re thinking.
@netmanchris
HP IMC Multi-Factor Authentication
Posted by netmanchris in netman, Uncategorized on May 4, 2012
Hey All,
As some of you may have noticed, I’ve started doing more and more public stuff on the HP IMC platform, including making the jump into blogging on the official HP Networking blog hub. I’m still going to keep this blog around as I like the ability to have my own opinions as seperate from my employer. But after a lot of prompting from customer and peers, I’m going to try and start putting down what little info I’ve gathered over the years on this platform in hopes that someone else might find this useful. This is the first of those post. Hope you enjoy
So let’s get started.
For those of you who haven’t logged into HP’s IMC NMS platform yet, it looks like this.
Or if you wanted to get creative and know a certain wookie, you can create your own images and place them in
c:\program file\imc\client\web\apps\imc\images\login
directory and replace the file “login_hp.gif” with a file of the same size.
So your IMC could look something like this
Now for those of you who were paying attention, you might have noticed that there’s a third field that appeared on the second login screen.
The “Verify Code” field. This is you basic captchca, and although it does not offer the same level of security of a RSA key… (ok maybe an ActiveIdentity key?) it does provide administrators with a multi-factor authentication which is another layer in your basic security onion.
How did you do that?
Pretty simple actually.
Step:
1, Open “c:\Program Files\IMC\client\conf\commonCfg.properties”
2, Modify “enableValidationCode” to “true”
3, Restart IMC
Now your Login page should have the extra field and look like this
Extra Security. Same low, low price.
That’s it.
Hope someone somewhere find this useful.
@netmanchris
How many SPOGs?
Posted by netmanchris in IT Musings, netman, Uncategorized on April 21, 2012
Seems like every vendor is preaching the value of the Single Pane of Glass ( SPOG ) to their customers. For those of you who have been operations folks, the fragmented nature of xMS ( NMS, SMS (security), SMS ( server ), BSM, APM, etc.) has been a nightmare for most organizations. The data is more silo’d than the IT departments and it really doesn’t scale because of the lack of interaction between the data in the management domain.
So the industry lately has really zoomed in around the idea of the single pane of glass management system. And it got me to thinking
Does anyone really want a single pane of glass?
I think a lot of people are looking for a way to manage complex environments and the idea of having a SPOG that lets you see everything in one console is such a tempting idea. But is it realistic? And even if it was, would it even be useful?
I don’t think anyone would try to argue that convergence in the data center isn’t a reality. The network is virtual, storage is distributed. Applications are federated. Everything is built on a stack of lies and no one in the operations group has any idea where their particular domain of responsibility ends anymore.
But in meeting with many different organizations, it seems that although people want (and NEED ) the SPOG. They also seem to want to continue with the seperation of the seperate silos of servers, storage, and networking.
I’m still thinking this through, but it seems to be that the network guys ( and gals ) want to see things from a network-centric point of view. The servers want to see this through a server-centric point of view, and the storage wants to see this through a storage-centric point of view.
What’s interesting though, is that in smaller shops where the Ops team is actually one or two people who do everything, they still seem to prefer a SPOG per IT domain.
Functionaly Dysfunctional if you will.
There are some solutions out there, like Cisco UCS Manager that does have some great stuff going for it and seems to bring together the Data Center networ and the Servers. I haven’t had a lot of hands on, but it does seem to bring the data center into a SPOG, and I can see the value in that.
But I wonder about the rest of the network. What about the end-users? The data center only exists to offer services to end-users and a solution that seems to completely discount the users it is supposed to serve just seems like it’s missing something to me.
What do you guys think? Would you rather have a NMS tool that allows you to see into the networking centric portions of the virtual environment and gives you full visibility to the end-user? Full visibility into the end-to-end transaction, at least from the network perspective?
Still thinking this one through…
@netmanchris
HP and Openflow
Posted by netmanchris in IT Musings, SDN on March 21, 2012
Hey All,
Full disclosure: I work for HP.
Recently I’ve seen HP taking some flack around it’s Openflow announcements. The criticisms basicaly smack of accusing HP of jumping on the Openflow bandwagon and this bugs me because HP was out in front of this on the hardware side for quite sometime, not to mention working with Stanford directly on the actual protocol implementation. Again, there are a lot of criticisms that could be argued against any company, but sometimes we just have to look at the record to get to the truth.
The Perception:
I’d like to point out a couple of recent quotes on HP’s Openflow strategy from some VERY smart people that I have a lot of respect for:
@amyengineer
“http://amyengineer.wordpress.com/2012/02/03/a-brief-interlude-for-openflow/“
“”HP *has* an OpenFlow story. Honestly, hadn’t caught that before – but to hear them tell it they have been working with OpenFlow founders since it started as a science experiment in someone’s basement (no, not really a basement- well, maybe a basement). “
“Why does this matter? Um, because in my opinion, if these guys are doing it, the reality is OpenFlow is here and looking for a place to settle in.”
;
@ioshints
http://blog.ioshints.info/2012/03/grumpy-monday-hp-and-openflow.html
“They claim they’ve been working on OpenFlow technology for years, but when they talk about it, they use baseline open-source controllers to demonstrate the supposed benefits of OpenFlow “
Again, my point here is people seem to be thinking that HP is jumping on the Openflow bandwagon.
The Reality
I’d like to point everyone back to a www.packetpushers.net podcast from Nov 7, 2010
http://packetpushers.net/show-25-hp-networking-data-centre/
Now we all know that @etherealmind is ahead of the curve. I believe the packetpushers show has done more for getting great information out to the networking profession than probably any single podcast or blog *ever*. Greg, Ethan, Ivan, Matt, Tom, Amy, Mrs. Y are all personalities which we all feel like we kinda know now.
So when Lin Neese from HP is explaining openflow at the time and Greg is saying
” I’m looking at a webpage here. I’ve been furiously searching here while I’m talking to you. So Openflow is not Netflow or sFlow? it’s something completely different?”
” This is all new to me. I’ve sort of seen this talked about a lot, but I haven’t managed to drill into this in any level of detail to comprehend how it works in detail, so I’m sort of.. .my mind is spinning over this trying to come up with it…” ( laughs) ” take a break. “
That’s gotta tell you something.
This is the same Greg Ferro, “Openflow Expert” that put on the recent Applied Openflow symposium. No sarcasm here. Greg knows his stuff.
Considering all that the packetpushers have done to educate the world on SDN and Openflow in particular ( check out @cloudtoad blogs!!!) It’s telling that a guy from HP Networking was the guy who first brought this to the Packetpushers audience.
I’m going to let the marketing department get into defending strategy and announcements and everything else, all I”m really concerned with is the idea that HPs just jumping on the bandwagon.
Now let me make myself 100% clear, this is not a criticism of any of the people who are mentioned in this blog. They are all incredibly smart people who are lending their experience to all of us on a daily basis. But they just seemed to have missed this one…
I’m pretty sure I’m going to take some flack over this piece, so let me start by saying that I’m not going to respond to any comments at all on anything other than the topic at hand. 
As I said, I’ll let the marketing machine take on HPs official position. This blog is my personal blog, and I’ll let the company defends it’s own stance.
@netmanchris
SDN. Who’s going to run it?
Posted by netmanchris in IT Musings, SDN on March 4, 2012
Big credit goes to @cloudtoad for putting together this thought provoking-post over at www.packetpushers.net.
He makes some very interesting comments and observations, none of which I can actually disagree with.
SDN is a business dream; Where they can buy commodity hardware, do away with high priced router-jockeys, stop paying a premium for mid-range value products, and just focus on whatever their core business actually is.
Unfortunately, I think there’s a lot more to this discussion that I haven’t seen a lot of people address yet. I’m not saying I have any answers here, but I do have a few questions. Hopefully, some of you will post in the comments as to how you see this playing out, because my crystal ball is getting pretty foggy these days.
1) Skills Gap: It’s been 20 +/- years since the fallacies of distributed computing were laid out. And yet, we’re seeing the past repeat itself again and again. I was asking about the DevOps trend with a customer a few weeks ago and he laughed at the question. They had already tried it he said.
And it failed miserably.
These guys are a startup doing some pretty impressive stuff with BigData ( Hadoop ) and they have a lot of talented coders on staff. This really got me curious. So I asked him “Why?”
His response, which I think applies equally to SDN as it does to DevOps, was the following
” It took you 10-15 years to become a really good network guy. It took them”
pointing over shoulder
” 10-15 years to become really good programmers.”
” I’ll guess you aren’t a good coder, but I can TELL you that they aren’t good network people.”
This has been racing around in my brain for weeks now. Other than the odd exception like @lynxbat
( check out his awesome VMware cloud demo here
I think it’s safe to say that 99% of the network engineers I know are capable of nothing more than rudimentary scripting, and most of that is regurgitated code from examples downloaded off the Internet.
I have a hard time calling someone who downloads a perl script and hacks in a couple of locally significant values a programmer, And yet this is very much the world we are all talking about moving to.
So where are these new breed of GUI-jockeys going to come from? With the hybrid of both coder and network knowledge that they will deliver us from our current state of one-protocol-per-problem. Because sadly, I see a shortage of good network folk in general, let alone good network folk with coding skills.
We’ve been slowly automating out all the jobs that green networks kids used to cut their teeth on. So where are these new wizards of SDN going to get their network experience to learn the valuable “just because you can…” lessons that all of us have over the years?
More than likely, they are going to make some snide comment, as the young are prone to do, on how our ipv4 knowledge, just doesn’t apply here anymore. Offer us a piece of tin can with a string, and offer to write us a new protocol.
all I can tell you for sure?
“Not on my network.” : )
Is it just me? does anyone else see this as a problem? And if so, what are you doing to prepare yourself for the coming divide?
@netmanchris
it’s with great sadness and reservation I take these powers….
Posted by netmanchris in IT Musings on January 29, 2012
So first thing, I’m not taking on any powers. now that that’s out of the way, I wanted to take a little time and put together some thoughts on the current state of our industry.
We’re at an inflection point, a paradigm shift where everything that once was is about to change. I’m sure some would argue that we’ve already fallen over that edge. I don’t mean to be all dramatic ( although it does create an more interesting bit of writing!), but I truly believe our industry is in for change.
- BIG CHANGE
Like ” Fish crawling out of the ocean change “.
There’s a great book called the Aquarian Conspiracy that deals with the concept of paradigm shifts. It’s not IT related at all, but I think applicable to this topic sense we are dealing with a point where there are so many of our “beliefs” that are been destroyed that we need to find a new path forward.
what beliefs am I talking about? let’s start with this small list, although I’m sure there are more ( feel free to post in the comments if you have any!)
1) International Standards bodies work. – IEEE/IETF have been infiltrated by overly powerfull vendors with their own agendas, allowing them to force or stall individual projects on a whim. ( see Greg Ferro’s article for a great description of this in detail
2) That overlay networks are going to solve all of our problems.
3) A protocol per problem: Any problem can be solved by adding a new protocol.
Now there are a lot of solutions right now, SDN is hot. Whether that’s Nicara, BigSwitch, IBM and HP with the recent VEPA gear. ( yes, one of them is VEPA “ready” @ioshints! ), or whether we’re talking about something much more devious like vXlan or NVGRE.
There’s a lot of great work that’s been done in the Openflow arena but I’m not sure it’s gotten out of the “solution looking for a problem” stage yet.
But to be honest, there’s one player that has be a little bit concerned here. Perhaps I’ve just seen too many Star Wars movie in my time, and with the recent re-release of Episode 1, my mind is going down a strange road.
VMWare scares me.
There. I said it out loud.
Now to explain to you WHY they scare me, I have to explain a little bit of the star wars story. ( for those of you who have been living under a rock ).
Once upon a time there was a republic that had lived for a thousand years with their glorious protectors.
The Network Jedi Knights.
Now these brave men and woman had been rescuing the business for years from spanning-tree loops, layer2 data center interconnects, and the evil of double ( and single ) NATs.
But unfortunately the Senate ( IEEE/IETF ) had grown complacent with the member planets (vendors) arguing internally for placement.
“TRILL!”
” NO SPB!”
“TRILL lets us sell more hardware!”
“VEPA!!!”
“No VN-link”
“You’re proprietary!”
“No YOU’RE proprietary!”
And suddenly out of the darkness comes VMWARE and VxLAN.
” Yes, I know you haven’t done anything about that little VLAN problem, but you guys just keep arguing… it makes me really sad, but I suppose I will handle all the traffic decisions, but just until you guys get this figured out, ok? It’s with great sadness and reservation that I take on these power…”
I’m pretty sure that everyone remembers how that story ended.
Don’t believe me? Think about this, VMware introduced the vSwitch and took Cisco on as it’s “apprentice”. Cisco had the only vSwitch in the industry for the last few years that had access to the hypervisor of the major player in the industry.
And now, VMware has it’s own security suite that negates the need for a ASA. Especially when you consider that there are currently no hardware products that support the termination of VxLAN tunnels.
And if all the shady behavior is not enough to convince you, check out this little nugget that I found on the Microsoft page today.
” learn about the Cisco and NetApp pre-validated private cloud offering through the Microsoft Hyper-V Cloud Fast Track”
What the heck happened to VCE??? Now we have to deal with MCN as well?
I don’t know how this is going to play out. Will Openflow grow out of a lab toy into a solution which not only scales, but actually addresses technical requirements in a much more elegantly simplistic way than our current protocol-per-problem paradigm? I guess we’ll see…
What do you think? Anyone else worried about the state of the networking industry? Change is a constant and embracing change is the key to surviving in this industry, but I also think a healthy dose of vendor sketicism and suspicion is not only healthy, but a survival trait.
I just hope that the network industry pulls out of this before John Chambers ends up in a black suite with a respirator and all the rest of us Jedi’s are gone.
Feel free to let me know where you see this headed in the comments.
@netmanchris
How to be a Network Jedi
Posted by netmanchris in IT Musings on December 27, 2011
So it’s almost 2012 and as I get a little older each year, I’m trying to become more comfortable with my role as a mentor and influencer of the next generation. When I look at my kids at Christmas and watch all the little behaviors and endearing little qualities that come from me, it’s really amazing how much influence that we can have simply by the example we set in the world.
In light of that, I’m going to start the New Years resolution a little bit early this year, and just throw out the goals that I’m going to try to live professionally this year, and hopefully rolemodel out to the next generation. To be honest, it’s not really a New Years resolution since these are pretty much the goals I tried to live by last year too. But here they are. Hope you enjoy!
Funny enough: This was 99% written before @cloudtoad posted this great post on www.packetpushers.net
Note: So, I blatantly stole these images from a Youtube talk by Artur Bergmen of www.fastly.com. You should check it out because it’s funny, and it’s wisdom.
- 1) Learn the basics
I’ve had the honor to learn from many great masters in my years in the martial arts, and one of the lessons that really stuck with me is that the difference between a student and a master is the quality of the basic movements.
As I go into 2012 again, I’m going to really re-focus on learning the basics as I go for another round of Cisco Trivial pursuit. ( CCIE renewal ). Understanding the basics of technology will help you in so many ways and solve so many of the other mysteries for you.
2) Come ready to learn
We have been blessed with a career where we are rewarded for our insatiable curiosity.Respect how amazing a gift that is and embrace the learning opportunities which are placed before us everyday.
How does this work? Why did that break? What happens when I touch this button?Hmmm. I wonder why it did that?
I’m going to continue on in 2012 asking these questions, preferably in the safety of my own lab.
Yes honey… I promise I’ll get that fixed!
WARNING: PLEASE DON’T TEST OUT THESE THEORIES ON PRODUCTION NETWORKS. CUSTOMERS GET TESTY.
- 3) RTFM - Don’t ask stupid questions.
There’s nothing more annoying to me when someone asks me a question that can be found in the first 5 hits of a simple google search ( www.lmgtfy.com ). A stupid question is one that you obviously have spent no time trying to figure out. One that it takes me one google search to find, or one which you should have known in the first place.
I’m not saying don’t ask questions, because those often lead to design breakthroughs or really great learning experiences because of the nuance brought on by that particular angle of a question. But also, don’t be afraid to sit down and go through the manuals to see if it’s actually documented somewhere. Don’t be afraid to read through some blog posts, and also, embrace social media. Twitter has an enormous amount of shared wisdom and experience.
If you are going to ask a stupid question; come prepared. Don’t waste someone’s time.
Warning: Ask stupid questions on twitter with caution. Someone might call you stupid.
- 4) Figure it out
If Rule #3 fails you and you can’t find the answer that you’re looking for, then you need to go back to rule #1. If you know your basics, there should be almost no problem that you can’t break into its composite parts and figure out what’s happening.
Networks aren’t magic. Packets don’t teleport from point A to point B, and there are certainly no gnomes, trolls, magics elfs, or unicorn tears. ( sorry guys! ). If you don’t understand how they work from the basics, you stand no chance of understanding how they work when things get complicated.
VxLAN/NVGRE, LISP, and other overlay technologies are just that; Overlays. They don’t fix the underlying issues, and they can actually abstract the problem. As Artur says in the video, if you don’t understand the stack, you can spend a lot of resources trying to fix the problem at the wrong layer. This is the biggest issue I have with the overlays is that it will abstract the system and potentially allow the various data center factions to continue not-talking to each other. This is not a good thing.
- 5) Learn about the other parts of the system
I believe that the network folk are actually the most well rounded out of the IT disciplines. (personal bias notwithstanding )
You will often find that network professionals were once programmers, or server/os guys, or even applications guys. ( Or in the case of Voice Network guys, they still are! ).
I actually believe that this is a result of the fact that we are always the ones who get blamed and we need to understand the system to prove our innocence. ( MTTI: Mean Time to Innocence )
As blah-blah cloud becomes more and more of a reality, and technologies like Openflow start to abstract the reality of the underlying system, it is becoming more and more important for SOMEONE to have an omniscient understanding of the datacenter.
That someone could be you.
If anyone has any additional goals for the year, please feel free to post below. I’d love to hear.
@netmanchris
5 Rules for growing your SE
Posted by netmanchris in IT Musings on October 21, 2011
After reading Greg Ferro’s ( @etherealmind ) hilarious blog on fashion tips, I thought I would add my own experience and put together 5 rules for Account Executives ( aka. Sales Guys ) to follow when helping their SE’s ( aka. the brains ) to do put their best foot forward. Part of your job as our handler is to make sure that you mitigate the little eccentricities that get in the way of the dashing brilliance that we unleash in each and every meeting you bring us into.
So without further delay…
Be kind.
We SE’s have lived a hard live. Although we were blessed with an natural intelligence and an uncanny wit, our ability to understand networking mostly comes from our childhood experience playing with our imaginary friends.
We don’t dress like this on purpose. We really don’t get that certain colours don’t go together, or that comic book camera ties are never, ever, EVER appropriate. (unless your son or daughter buys you one and INSISTS you were it the whole day!) If you make fun of us, we won’t like you. If we don’t like you. We won’t work for you. Keep that in mind.
We are the brains, and if you don’t treat us nicely, there may suddenly be a lot of dead air after you introduce us at the beginning of the meeting. Or even worse, you might find that the only service you get is SAaaS. Smart Ass as a Service.
Advice your SE on body appropriate attire.
SE’s are a special breed, and we don’t always get that certain clothes don’t belong on certain people. Depending on how bad your SE suffers from lack of fashion, you may be able to give him some small tips, or you may have to take him shopping. Once he understands that his lack of style is working against him, he will let you dress him in a too-too if he thinks this will help make his point heard!
The best example of this happened a few years back. We had an manufacturer come in to present to my SE team on their product. This guy was brilliant. He VERY clearly knew the product inside and out. He was articulate and passionate, but unfortunately, the 42″ muffin-top that was dropping over his 32″ pants had caused sensory overload, preventing us from even hearing the words coming out of his mouth.
My Point? It doesn’t matter how smart your SE is, if his fashion style prevents us from hearing what his message.
Body Language and Hand Gestures:
We’ve already established SE’s are not social animals. Many of us spent large parts of our adolecense connecting to BBS’s on 2400 baud modems. I even had friends who could whistle modem tones. ( We thought he was soooooo cooolllll!!!!!!). This means that we probably didn’t interact with many people, and definitely not enough girls. So we never learned some basic social rules. This includes appropriate hand gestures and body language. Your job is to help guide us in the right direction, let us know what works and what doesn’t. ( please refer to rule number 1! We don’t know any better!)
Funny enough, the best example that comes to mind was the same guy with the muffin-top. Same meeting in fact. So you can imagine how bad this was looking already, but then add a set of hand gestures that looked like a combination of KRS-1, Marcel Marceau, and a Shaolin master. By itself, this was bad enough, but the fact that he stopped every couple of minutes or so to wipe his sweaty palms on his man-boobs.
He looked like a mime stopping his act to play with his nipples.
Do you think that anyone could have REALLY heard what this guy was talking about? We were a room full of SE’s and we could barely stop ourselves from laughing out loud, let alone pay attention to the words coming out of his mouth!
Point: If your SE suffers from mimism, tie his hands together. If that doesn’t work. Video him and make him watch it on mute. He might even tie his own hands together at this point.
Warning: He may also try to cut his own hands off. A twenty-four hour watch may be required after the initial viewing.
You are not a bus driver
As a general rule, we SE’s don’t like buses. I’m sure you’ve heard the example ” But what if he gets run over by a bus?”. These saying comes from somewhere.
We don’t like buses. we like them less when they run over us. and even less when our friend, you the AE, are at the wheel.
If you are planning something, let us know in advance. And please don’t ask us questions in front of a customer if you don’t already know the answer. We will most likely answer that question honestly. and you may not like the answer or the delivery, or both.
Lunch is Good
When we go for lunch, you pay. Always.
If you should ever doubt, please refer to the first rule.
Proprietary? So what? Don’t take away my right to choose!
Posted by netmanchris in IT Musings on October 21, 2011
I was reading @networkingnerd blog and he made a comment that started me thinking.
First the quote
Proprietary is very cut and dried. You are either entirely open and run the same implementation with everyone, like OSPF or IS-IS, or you are closed and only play well with your own kind, like EIGRP or IRF. I’ve always been of the mind that proprietary implementations of things aren’t necessarily a bad thing.
Full disclosure: I work For HP Networking. Normally I don’t bring that up because this isn’t a work blog and my tweets are my own, but I think it’s important for this particular blog post since some will think that obviously skews my position. It doesn’t.
Ok so I agree 100% with Tom’s point here. What I don’t agree with was the examples he used for proprietary protocols.
Before I go further, let me point out where Tom and I agree again. Proprietary is neither good or bad. It simply is. If it meets my business requirements and solves a problem I’m having in a cost justifiable way, GREAT!
But what any good engineer knows is that any technology decision is done with trade offs in mind. If I do X then Y will suffer a little, but that’s ok because Y is of lesser importance to our business requirements that the technology design is supposed to address.
What I see too often is that people make emotional, short term decisions without considering the consequences. This always leads them down a bad place eventually.
An example: EIGRP.
I’m not going to debate the merits of this protocol or try to Cisco-bash this in any way. It does have its challenges, but if it didn’t work, people would not still be using it more than 10 years later, right? But it does have its consequences.
I hope you REALLY liked Pix firewalls. I hope you are learning to love those ASAs. Because you couldn’t put in a checkpoint if you wanted to! Ok… I understand no one REALLY wants to put in a Checkpoint. But the point is that you can’t even make the choice because of the proprietary protocol. Right?
You can’t choose a sonicwall, a Fortinet, or even a Palo Alto. Because they don’t support EIGRP either. Now I’m not going to start questioning whether or not the ASAs are a good product. They are “good enough” for a lot of people. But wouldn’t it be nice to choose what was best for you? Of course there is route redistribution, etc… But I have to believe that it’s got to be just painful because I meet people everyday who make EIGRP support as a reason for not been able to make a move off their current network supplier. There’s of course no way this could be a rationalization to support an emotional decision, right?
Now let’s look at IRF.
First: IRF is not really a protocol. It doesn’t run on IP. It’s actually control plane extension between two hardware compatible switches. Is it proprietary? Sure! 100%
You will never get an HP 5500EI to form an IRF stack with an Cisco 3750 or a Juniper EX4200. Not ever going to happen. IRF is HP’s secret sauce.
So where is the difference?
The differences is the extent of the consequences. HP’s IRF is just a control plane technology. Very similar in principal to Cisco’s VSS on the 6500 platform, or Juniper’s Virtual Chassis on the EX line of switches. All of those technologies are very limited in how far they can extend in their current implementations.
This means that if I make a choice to move towards IRF, I am at most going to be implementing it on a couple of chassis switches, or up to 9 stackables ( typically in the same closet). Now this is where the difference starts to happen….
HP has made a choice to support open standards. All of the protocols running on top of IRF are based on the standards. Instead of HSRP, there is VRRP that will run together with Juniper, Cisco, or any other vendors standard implementation of VRRP. OSPF/ISIS/BGP? Exactly the same thing. STP/RSTP/MSTP? Same thing!
Has there been a limitation of choice?
For sure!
If you WANT IRF, you need to buy the second switch from HP as well. But that’s because it’s a good technology that you really found value in, not because we’ve created a artificial limitation which prevents you from going anywhere else. and for everything else? You can choose what load balancer you want without worrying about WCCP support, or which firewall you want without worrying about EIGRP support, or what ever server platform you want without worrying about VNTag support. Everything else just works on top of it, and it plays nice with the other kids.
Perhaps a small distinction, but I think it’s an important one.
I grew up in place where independence and freedom where strongly ingrained in the culture. I would even dare to use the word “cowboy” to describe it. And anything that outs an unreasonable amount of restriction on my choices is something which I’ve been taught to resist from birth.
so Tom; If you would have compared IRF to VSS, Stackwise, or Virtual Chassis. I would have been just fine. I hope you’ll forgive my semantics debate, but I just felt the need to get this out.
@netmanchris
