 |
I just finished reading the book titled, “Blink” by Malcolm Gladwell. It is an interesting book where the author contends that people unconsciously make first impressions of a situation, person etc which carries through in how they react to that situation or that person long after the initial encounter. In fact the author discusses the concept of “thin slicing” wherein he believes that the unconscious system in a person is able to process/assess a situation with very small amounts of information very rapidly and more often than not arrive at the right answer or the correct way to handle the situation. This is especially true in a crisis or in a emergency situation. He shares an interesting anecdote as narrated by Vic Braden,a world class tennis coach, where Vic is able to predict with great accuracy (in some instances with 90% accuracy) when a professional player is about to serve a double fault in a match. This is amazing considering the fact, in tennis, at the professional level, double faults are very rare (during the course of a professional match, out of over 100 serves, it is rare to see more than 5 to 10 double faults served by a player). The author, however also shares with the reader several other instances of how first impressions could be misleading and may not be always necessarily accurate by giving an example of how Warren Harding came about becoming the President of United States with his ability to make good first impressions.
Well I am sure by now you are thinking what Blink has got to do with Element/Network Management System. Plenty. Let me explain why. Even if we disagree with the author that first impressions made by people may not be necessarily correct, you can’t deny the fact that first impressions are very powerful and in sales/business first impressions are very critical. Better the first impression better the chance of attaining a favorable position in the mind of your prospect/customer. In fact this book basically reaffirms what mother used to always say when she wanted us to look presentable at the dinner table when guests are going to be present: “First impression is always the best impression” – Like it or not!
I believe one of the key areas of responsibility for the management system is to make that first best impression. I do agree that a management system has a host of responsibilities to fulfill such as exposing the features of the device, making it easy for the user interact with the device, be able to handle new generations of the device as well and scale to handle thousands if not millions of devices. Regardless of other requirements, I believe management application’s key responsibility should be to make that first impression of being easy to use and intuitive so that it gives the user a positive first impression. This positive first impression does set the tone of the interaction and ends up going a long way in giving an edge during the entire sales cycle (all other things being equal).
To sum up, in my opinion if the management system doesn’t do the job of making that best first impression for the device on the prospect’s mind then the management system has not done its most important job and has fallen considerably short of its objective. Therefore next time you are out shopping for a management application or planning to develop one in house, don’t forget that you may never get a second chance to make that first impression!
Dhyan Infotech Inc is a software and services company that helps Equipment Vendors differentiate their products in the market place. Dhyan's EMS technology, DNMS (Dhyan Network/Element Management System), is a component based Element Management System, which has been widely deployed by Dhyan's customers at many Service Providers both small and large
If you have questions on EMS or related topic that you would like to get answered or would like to write a guest column in this newsletter, please send an email to ems-energizer@dhyanit.com. This is a complimentary newsletter that was sent to you because of your interest in EMS. If you do not wish to receive this newsletter please click here to unsubscribe
|
 |
Today’s data centers are equipped with high-end servers that have multi-gigabit Ethernet interfaces to meet data transfer needs of applications/Virtual Machines installed in those servers. In such an instance there is a growing need to have high-end routers/switches that can route multi-gigabit traffic from one server (or VM) to another with very low latency.
Data Center operators have a critical need to continuously monitor network usage and identify network congestion. They are in need of tools and techniques to identify congestion in data transmission and also need the ability to drill-down to the individual data flow level and be able to identify the root cause of the congestion. This provides the operator with information to take necessary corrective action such as moving a high data flow VM to a separate server or restricting the bandwidth allowed for an application etc.
The process of traffic analysis is better done external to the switch for the following reasons:
| 1. |
Reports should offer statistics consolidated across switches to provide clear view of areas of congestion. |
| 2. |
Reporting process involves significant amount of data processing. For instance in a small to medium size data center with about 50 VMs, on an average, there might be about 25 – 70 flows/second (Note: The actual numbers might vary based on the usage). Delivering network-wide consolidated reports and detailed drill-down reports (to an individual flow level) requires a lot of processing power, storage space and memory. Therefore it makes sense to offload the flow correlation and consolidation task to a separate management server and allow the switch to concentrate on its “core job” of routing these flows with very low latency. |
If the traffic analysis is to be done external to the switch, very large amounts of flow statistic data has to be transmitted to the management server to enable the reporting process. Therefore the protocol that is being used to transmit the data plays a key role in differentiating a good solution from a mediocre one. Most management protocols such as SNMP, TL1, XML over HTTP etc., will prove very costly for this task as the overhead associated with these protocols is very high. For this purpose, Cisco Systems came up with the NetFlow protocol. The traditional Cisco definition is to use a 7-tuple key, where a flow is defined as a unidirectional sequence of packets all sharing all of the following 7 values:
| 1. |
Source IP address |
| 2. |
Destination IP address |
| 3. |
Source port for UDP or TCP, 0 for other protocols |
| 4. |
Destination port for UDP or TCP, type and code for ICMP, or 0 for other protocols |
| 5. |
IP protocol |
| 6. |
Ingress interface |
| 7. |
IP Type of ServiceNetFlow |
NetFlow protocol went through few revisions (v1, v5, v6, v7, v8 and v9) and later IETF came up with the IPFIX protocol (based on NetFlow version 9) as a universal standard.
IPFIX protocol has a template based support to help vendors create custom templates with the provision to include additional flow specific details. Since IPFIX has a very low overhead it became very effective in notifying the management system about each flow passing through the switch.
When there are multiple flows flowing through a port, it is also possible to combine multiple flow information into a single IPFIX notification thereby sharing the overhead across multiple flows and reducing the overall network usage.
For further details on IPFIX/NetFlow protocols refer to the following URLs
http://en.wikipedia.org/wiki/IP_Flow_Information_Export
http://en.wikipedia.org/wiki/Netflow
It is extremely critical to identify the right protocol to be used in notifying network flows. Choosing a wrong protocol will severely impact the scalability of the system irrespective of how well the system has been designed.
|
 |
A high-speed Ethernet Switching Fabric vendor had built a high-performance switching fabric that could process about 1000 flows/second in each of its 10 GE port. They noticed that in the worst case scenario they had to send about 1000 flows / per port every three seconds. Since the data that had to be transmitted became very large they chose to use an IPFIX based notification (due to its low overhead) scheme for reporting their flow statistics. In order to reduce the overhead further they also decided to send a group of flow statistics as part of each IPFIX packet.
Since the data that had to be processed was large and the end-users wanted the capability to drill-down from network-wide consolidated reports to flow-level granular reports, they decided to identify a proven vendor for their management system rather than doing it in-house. They realized that their management system should be capable of handling 20,000 IPFIX flow records per second for a network with 576 10GE ports which became a key criterion in short-listing the vendors.
To meet customer requirements, Dhyan developed IPFIX data collection and reporting component to meet the demands of high performance computing marketplace and also provided a detailed walk through to the customer explaining to them that it is actually easy to receive the 20,000 IPFIX flow records. The real challenge however is in the processing engine, which has to process that many flow records and store them in a suitable relational database and generate the desired reports in real-time. Dhyan also went ahead and developed a proof-of-concept of the management system in a couple of weeks time to demonstrate its IPFIX expertise and the capability of their tool to offer both consolidated reports at the overall network level and also be able to drill-down to an individual flow level and also debug any congestion in the network.
|
____________________________________________________________________________________
|
|
If you have any comments or questions or would like to write a guest column in the energizer, please send an email to
ems-energizer@dhyanit.com
This is a complimentary newsletter that was sent to you because of your interest in EMS. If you do not wish to receive this newsletter please click here to unsubscribe.
|
|
|
Dhyan’s customer Woven Systems, management application (Woven Fabric Manager) which is based on DNMS technology was voted as the
|
|
In addition to being the OEM for DNMS technology, Dhyan also performed the customization services and developed WFM for Woven Systems. |
|
| Participation in trade shows: |
|
September 1 -3 , 2009
Los Angeles Convention Center,
Los Angeles, CA |
|
September 15 -18 , 2009
Chicago, IL
|
|
September 21-23, 2009
Miami Beach Convention Center,
South Beach, Florida |
|
| |
|
| |
Q |
In a HPC network it is often tedious to draw the cabling map across switches. Can you tell us if there is there any specific standard that will help the management system to discover the physical connectivity between switches, thereby avoiding any user errors? |
|
A |
This is a common problem faced by most of the operators in data centers. It becomes a headache for them to go through the manual route whenever they change the cabling across switches.
|
|
IEEE has come up with a standard called Link Layer Discovery Protocol (LLDP). The IEEE 802.1ab Link Layer Discovery Protocol defines a standard way for Ethernet devices to advertise information about themselves to their network neighbors and store information they discover from other device. Since most management systems use SNMP as the standard protocol for discovery they can use the PTOPO MIB as a way to publish the physical topology of the network to high-level management stations.
Supporting LLDP / PTOPO will help the switch vendor differentiate themselves from the competition in the market place. Further details on LLDP and PTOPO can be obtained from the URL
http://www.ieee802.org/1/files/public/docs2002
/lldp-protocol-00.pdf
|
|
| |
|
| |
Dear Ram, |
Thank you for delivering phase one of Woven Fabric Manager (WFM) on time and under budget. You have definitely vindicated my choice of going with Dhyan and DNMS (Dhyan Network Management Systems) technology for WFM!
As you know during our evaluation process we evaluated DNMS technology along with several other alternatives and even though DNMS technology was strong in the FCAPS and Topology area, we noticed that Dhyan did not have any IPFIX adapter experience in the South Bound. This definitely was a cause for concern for our engineering team, because IPFIX is a critical protocol for managing our device. Since Dhyan had a strong offering in the FCAPS area our original thought was to go with you guys for FCAPS functionality and get another vendor to help us with IPFIX adapter. However, I was pleasantly surprised that during the functional spec phase your team was able to come up to speed on the IPFIX technology quickly and to my delight was able to deliver a Proof of Concept (POC) of WFM in just 3 weeks with IPFIX! It was very impressive and was extremely well received within the company.
Finally as you are aware WFM was also well received in the market place and was voted as the Product of the Week by Network World Magazine!
Please convey my sincere thanks to your team for a job well done
|
Sincerely
Sr. Product Manager |
|
|