Wi-Fi: Access Layer of the Future?

Is Wi-Fi the access layer of the future? Of course it is! As network professionals we all know that outside of the traditional enterprise, it’s the access layer of the now. But when will the traditional enterprise take advantage of it?

Read the rest of this post over at the Aruba Airheads Community: Wi-Fi: Access Layer of the Future?

SolarWinds Thwack Community

Screen Shot 2014-09-02 at 10.13.49 PMAugust has come and gone, and with it my Thwack Ambassador status. You might be wondering what that means. Perhaps you thought @amyengineer with her sparkly bat was the ambassador of thwack. This is not the thwack you are looking for. This thwack is the SolarWinds Thwack Community. SolarWinds, as you likely already know, is a software company that provides a variety of network and system management/monitoring tools. Their tools are good, easy to use, and reasonably priced. Their marketing is amusing and occasionally inspired (see The Joy of Whiteboarding with Rob Boss). The Thwack Community is an open forum for discussion of network management topics. Forums exist for the SolarWinds tools as well as general discussion. A Thwack Ambassador is given the job to spur conversation in their assigned topic areas in order to encourage participation in the forums. This is done through weekly blog posts on Thwack and my assigned area was network management. I’ve included the intro to each week below, but if you want to read more, you’ll have to follow the link to the thwack website. :)

The Discussions

For week one I asked, “What is a well managed network?

What is network management and what constitutes a well managed network? Is it monitoring devices and links to ensure they are “up?” Is it backing up your device configurations? Is it tracking bandwidth utilization? Network management is all this and more. We often seem to confuse network monitoring with network management, but monitoring is really just the start.

This post generated the most discussion and it was interesting to see the variety of views expressed from different perspectives. One user even created a nice outline of what we decided made up a well managed network.

On week two we discussed “Thinking in terms of availability.

Network monitoring tracks the state of the network and is primarily looking for faults. At the most basic level, we want to know if devices and interfaces are “up.” This is a simple binary reachability test. Your device is either reachable or not, it’s either “up” or “down.” However, just because a device is reachable does not mean there are no faults in the network. If a circuit is dropping packets, performance may be impacted and can make the circuit unusable even though it is “up.” Time to stop thinking in terms of reachability and start thinking in terms of availability.

The comments to this post were mostly people nodding in agreement, though one reader brought up the idea of acceptability, as well.

During week three I reminded everyone that “Useful alerts help you be proactive.

You may need to have an alert sent if an interface goes down in the data center, but you almost certainly don’t want an alert if an interface goes down for a user’s desktop. You don’t need (or want) an alert for every event in the network. If you receive alerts for everything, it becomes difficult to find the ones that really matter in the noise. Unnecessary alerts train people to ignore all alerts, since those that represent real issues are (hopefully) few. Remember the story of the boy who cried wolf? Keep your alerts useful.

This post had a nice little discussion talking about ways to make the alerts useful, like including severity in the subject of the alert.

Finally, in week four I asked, “What’s on your network?

There is a credit card commercial that asks, “What’s in your wallet?” I’m going to ask, “What’s in your network?” Sure, you might be able to tell me what’s in your network right now, but can you still tell me about a device when it’s down? Its model and serial number? The modules or line cards installed? Which interfaces are in use and how much bandwidth they use?

This question focused more on documentation, which received the obligatory head nodding and a little snark. There was also a side thread that brought up the lack of communications between teams (silos).

Closing Thought

I hope you found these discussions of interest, and maybe got you thinking a little more or a little differently about something. I can’t help but think of a rant posted by @etherealmind titled, “You Are Not A Precious Snowflake. IT Infrastructure Is The Same Everywhere.

Vendors keep telling me that every business is different and customer have different needs. We all buy the same products from the same companies, use the same deployment methodologies and best practices, have the same problems and deliver the same results to the business. You aren’t a precious snowflake.

I was looking at the discussions and thinking that we are all talking about the same sets of problems and appreciating the same sets of solutions, yet I’m sure the organizations we all work for are wildly different. I’m sure you’ve noticed this when talking with other IT professionals, too. In reality, our infrastructures are not all that dissimilar. I think that’s actually a good thing, but it is something to ponder…

FIN

Seattle Network Experts Meetup

Meetup.com Logo

I have been attending the new Seattle Network Experts Meetup, sponsored by INE. It is at their offices in Bellevue, Washington. The group has only been going for two months, but it has promise to be a useful place for networking (the between people kind) and learning. January’s meeting was a presentation on programming OpenFlow with Python. For the February meeting I presented Cisco Modeling Labs to the group. If you are in the Seattle area, come join us on the last Wednesday of each month at 5:30PM. INE has been providing dinner and giveaways and will be happy to tell you about what they do, but only if you ask. I recommend parking across the street at the 435 Building. It’s only $5 after 4PM and you can pay with cash or with QP QuickPay.

I hope to see you there!

FIN

OT: Microphone Audio Comparison

Have you noticed how bad audio can ruin a podcast or video? Having a great mic really helps improve audio quality. One of the gifts I received for Christmas was a Blue Microphones Yeti, which is a great USB microphone suitable for just about any of your audio needs. I wanted to illustrate the difference a good microphone makes, so the remainder of the blog post is in an audio file. It’s essentially a 4 minute podcast where I talk about why a good mic is needed and let you hear for yourself a comparison with common microphones that people use for podcasting.

FIN

Code of Ethics

The purpose of IT is to be a business enabler. To put it another way, IT is supposed to help others use information technologies to do their jobs. It doesn’t matter if you are a PC Tech or an Enterprise Architect, you are there to help other people conduct business of some sort. IT people are sometimes cast in an unfortunate light, mostly because of a few who do not have their priorities correct or are immature in their understanding of the purpose of IT. Mordac from the Dilbert comic comes to mind:

Dilbert.com

This is not the way we should be treating our customers and is not the image you should want projected for your IT department. I come from a sysadmin background and used to be a member of SAGE (now the USENIX LISA SIG) and LOPSA. They put together The System Administrator’s Code of Ethics, which is applicable to most IT positions. I’ve included it below for you to ponder.

We as professional System Administrators do hereby commit ourselves to the highest standards of ethical and professional conduct, and agree to be guided by this code of ethics, and encourage every System Administrator to do the same.

professionalism

  • I will maintain professional conduct in the workplace and will not allow personal feelings or beliefs to cause me to treat people unfairly or unprofessionally.

personal integrity

  • I will be honest in my professional dealings and forthcoming about my competence and the impact of my mistakes. I will seek assistance from others when required.
  • I will avoid conflicts of interest and biases whenever possible. When my advice is sought, if I have a conflict of interest or bias, I will declare it if appropriate, and recuse myself if necessary.

privacy

  • I will access private information on computer systems only when it is necessary in the course of my technical duties. I will maintain and protect the confidentiality of any information to which I may have access, regardless of the method by which I came into knowledge of it.

laws and policies

  • I will educate myself and others on relevant laws, regulations, and policies regarding the performance of my duties.

communication

  • I will communicate with management, users, and colleagues about computer matters of mutual interest. I will strive to listen to and understand the needs of all parties.

system integrity

  • I will strive to ensure the necessary integrity, reliability, and availability of the systems for which I am responsible.
  • I will design and maintain each system in a manner to support the purpose of the system to the organization.

education

  • I will continue to update and enhance my technical knowledge and other work-related skills. I will share my knowledge and experience with others.

responsibility to computing community

  • I will cooperate with the larger computing community to maintain the integrity of network and computing resources.

social responsibility

  • As an informed professional, I will encourage the writing and adoption of relevant policies and laws consistent with these ethical principles.

ethical responsibility

  • I will strive to build and maintain a safe, healthy, and productive workplace.
  • I will do my best to make decisions consistent with the safety, privacy, and well-being of my community and the public, and to disclose promptly factors that might pose unexamined risks or dangers.
  • I will accept and offer honest criticism of technical work as appropriate and will credit properly the contributions of others.
  • I will lead by example, maintaining a high ethical standard and degree of professionalism in the performance of all my duties. I will support colleagues and co-workers in following this code of ethics.

Draft of September 12, 2003, approved September 18, 2003, by the SAGE Executive Committee and September 30, 2003, by the Ethics Working Group.

Co-signed by USENIXLISA, and LOPSA 2006.

Think about your level of professionalism and your attitude towards your users. They are not clueless people ruining your day. They are the people you are supporting to do their jobs. You all are supposed to work together to achieve whatever goals your organization is trying to achieve. Do your part and be professional and ethical in your conduct.

FIN

An Unexpected Visit From Comcast

Comcast Truck by hoot2012 via flickr

‘Twas a dark and stormy night when a knock came at the door…

Actually, it was a sunny afternoon when my wife rang my mobile phone. A Comcast field technician had arrived at my home and wanted to check our cable modem. I thought this was odd, to say the least. I spoke with the technician and she really seemed on the up and up. She had a Comcast van, badge, and fancy cable tester. She told me that they periodically check modems and mine was reporting a “high transmit’ and had “a negative signal”.

This sounded odd. Comcast proactively correcting issues at customer’s residence? This is not the image of Comcast that most of us hold. Myself and a number of others on twitter thought this was #dubious. That said, she ran some tests, checked some cables. and said that the line between the wall jack and the outside needed to be repaired or replaced. We decided that the cable went through the attic and neither of us seemed interested in having her crawl around in the attic to replace it, so I thanked her and let her depart. I’ll check the cable myself.

In the mean time, I contacted a friend who works for Comcast to ask if this was legitimate and why they didn’t call. This is his fascinating response:

Yeah, it’s definitely legit!  What she was referring to was your modem has several health factors it needs in order to stay within a “good working window”.  If yours was flagged for a visit, it is because you probably have what we call a high transmit level that is either on the outside of what you’ll need to maintain a good working modem or a combination of SNR that is typically directly related.
If you’re curious, go into the GUI of the modem… not the router and look at 3 points of interest.
1.  Your downstream levels  +/- 10.
2.  Your SNR to both downstream and upstream (1 each)
3.  Your Transmit level which we want to be NO higher than 50.
When your transmit level reaches too high, it will typically bounce off and on of service.
The reason they don’t call first is MOST people will see the call coming in on their caller ID and treat it as a solicitation… go figure!?  Why not the mail?… Well that too ends up in the round file as JUNK mail, so we’ve found the best way is to stop by unannounced in hopes of catching someone at home.  Most people are and will be suspicious as YOU are and for good reason.
The computer generates calls like yours when technicians are in the area and “normal” service calls are lacking for that area.  It will then send us a job like that, where IF we make contact and are allowed to correct the problem, then we’ll do it.  OR, we’ll leave a door tag explaining the problem.  Most people that get these sort of visits will agree that their modem HAS been unreliable and its all because of the levels the modem is receiving and how hard it has to work to “transmit” back.
Its routine and recommended.  Typically a “geek” (me too!) such as yourself would question it and probably MOVED your modem from its original spot, or changed the levels to the modem by inserting another splitter in line.
Its very common around this time of year where “dad” takes Junior’s room as he moves out to college and makes an office out of it.  “Hey, why not?  It has a working cable jack there so the modem will work just fine.”
In YOUR case, if your cable has been damaged, it too will cause problems. Welcome to the world of “digital”.

So, there you go. I’m not sure I fully agree on the contacting the customer bits, but I can at least understand where they are coming from. Especially if they are just trying to usefully fill otherwise dead time and aren’t sure they’ll even get to the customer site. I asked if I could share this email and was told “absolutely!”, which is why you are now reading this. :)

FIN

The Network is the Cloud

The old Sun Microsystems used to have a slogan that said “The network is the computer.” I’ve been thinking about the role of the network, at least in an enterprise, and I think the network is the cloud. No, not the cloud like IaaS, but cloud as in a magic box that everything depends on an is taken for granted.

Clouds

It used to be that the network was something that was used occasionally for a specific business process. You had to get on the network to check inventory, look up a client record, or some other specific thing. The rest was either done on a local computer or on paper. If a network device reloaded, especially in the middle of the night, no one was likely to notice. The networking team could do maintenance during off hours and the users would be blissfully unaware. They probably didn’t even bother to send notice of the work, because no one cared. Of course, they should have, but that’s a different blog post.

Times have changed. Everything runs on the network now. Important devices like HVAC controllers migrated from dedicated POTS lines to the network. IT may not even have known until they receive a support ticket. Every business process ends up using the network in some way. Monolithic computing services turn into multi-machine clusters that blow up in bizarre ways if the members lose connectivity to each other.

Perhaps an iSCSI SAN pops up. It probably started on dedicated network gear, but after a while gets tied into the main network because running the separate network gets to be a hassle or buying “extra” 10Gb switches isn’t in the budget. It’s so easy to just make it another VLAN and let it converge.

Suddenly, after years of running in a silo, you realize you can’t do things the old way anymore. The network is now a critical service to the entire enterprise. You have to seek network equipment that can be updated without dropping packets. Designs get far more complex as HA becomes critical. Server, network, and application teams have to work together more closely because they need at least a high level understanding of each other’s designs so they can predict the impacts of changes.

Now you need some form of change management. It might not be some formalized processes, but teams at least send emails to each other to make sure there aren’t unexpected problems. There are unexpected problems, anyway. Usually complex interactions that don’t manifest themselves until business hours kick in, it seems.

Every system has become complex. Every system seems to affect every other system in some way. And all of it is running on your network. Your network is the cloud, you just didn’t know it.

FIN