Infrastructure Management and Strategic Design: Part 2 – Driving Network Efficiencies

by admin on June 16, 2006 01:21pm

Infrastructure Management and Strategic Design: Part 2 – Driving Network Efficiencies

Every computing device in existence today lives and breathes on some sort of a Network. Doesn’t matter if your Home PC is connected to a Cable Modem or if you’re office laptop is part of an extended WAN, your device is persistently living and breathing on the Network. From the minute you turn on your device, one of the very first drivers to be loaded are Networking drivers. Everything from DNS, DHCP to the simple sharing of email and office documents depends on the very basic function of the Infrastructure, the Network. So why is it that the same Network which is considered a Category-A asset in an organization is also sometimes at the very root of serious headaches for a Network Administrator. Thoughts about the faith and reliance we put towards Networking Infrastructure is simple staggering. Let’s examine why

If you’re a soccer fan like me, I am sure you have been glued to the World Cup coverage. As I sat with some friends and discussed our loss to the Czech Republic, I realized that in that group, it didn’t matter if you use Firefox or IE to get the game stats, you JUST wanted to know the score. The thought that followed was that maybe “Tools” shouldn’t be as hyped-up as they are sometimes as compared to the stream of “networking” that sustains them. Following that my thoughts turned to the topic of Net Neutrality and how Networks are ideally designed to forward packets regardless of their size, purpose and content. Hmm…this is interesting, I thought. My entire life as an Infrastructure Architect, I tried to come up with creative ways to manage and optimize network / infrastructure performance towards a better outcome for end users.

You see, some of the most perplexing problems for Network Admins is to control and manage “chatty protocols, broadcasts and bandwidth hogs”. How can we do that effectively? Let’s look at this closely: When I read a blog about Web 2.0 or something similar, some of the questions that pop in my head are “Have they considered what effect the implementation would have on their Network Performance” ? How far does the implementation of a new model go towards Application Bandwidth Testing and how inherently and intrinsically dependent we are on Networking.

Networking and the simple availability of bandwidth, wired or wireless, has become as much of an expectation as running water. A few months ago I remember someone saying “Network is like electricity – you don’t call up and thank the power company when you turn on the light, do you, nor do you ask them how much power you can use for your house”. Intriguing thought, nevertheless, for those Layer 2 and 3 warriors, the term “Port Saturation” should definitely ring a bell. Key contributors to reaching port density are instances when there just isn’t any more bandwidth to go around. To avoid choking up the network, I found some of the following tips helpful if you’re managing a small to medium sized network:


    • Auditing protocols in use: A good place to start overhauling your network can be drawing a good Physical and Logical representation of your company’s network. This will compel you to examine how majority of the devices are connected to each other as well as the medium, physical as well as protocols in place. If you have access to a Sniffer or a Fluke, you might also want to do some packet analysis and see where a majority of the “chatter” is coming from. That in turn will expose what some of the “bandwidth hogs” on your Infrastructure are, be it Application, Devices or Servers


    • Auditing ACL’s and Policies: If its been a while since you reviewed your network security policies, it may be a good time to do that. The ACL’s you put in place on various switches across your network were driven by the security policies drafted formally. An ACL audit will help provide fresh transparency into the security elements within your network


    • And the tricky one “finding alternatives to chatter-heavy Tools and Apps”: Once you have identified the bandwidth hogs on your Network, a good bet would be to limit the broadcasts and chatter they generate. Segmentation and or isolation of these tools into separate VLAN’s may be a good starting point. If an application or tool in question is culprit, investigate how many users or mission-critical LOB’s are dependent on it. If the priority is fairly low, it may be time to migrate to something less chatty or simply more efficient

Alright, that’s it. I am logging off and heading to the movies to watch the Da Vinci Code. Will be back here next week and Thank You for tuning into Port25.

Comments (1)

  1. pradeep says:

    Thank You

    The given information is very effective

    i will keep updated with the same

    <a href ="">industrial automation</a>