October 07, 2001
Network Uptime - October 7, 2001
The Resource for Network Management and Protocol Analysis Professionals
A Newsletter of http://www.NetworkUptime.com
Issue 02 00 00 01 01 00 00 07
October 7, 2001
ISSN: 1529-6938
This Issue:
* Starting Delimiter - Misguided
* Q and A - Why is Size Distribution Important?
* Surf Report - SNMP Version 3
* Network Uptime Tutorial - Analyzing Frame Relay Statistics
* Network Uptime Analysis Tip - Questions, Questions!
* Ending Delimiter
*** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
====
Starting Delimiter
- Misguided -
====
It's the beginning of Fall, the schools are back in session, and football dominates the weekend television schedule. At first glance, the world seems almost normal - except that under the surface, everything is completely different.
I'm not going to write about the painful events of September 11th, perhaps because everything significant that can be expressed has already been said. I also don't think I'm capable of expressing my opinion and emotion in a way that would accurately reflect my anger and frustration. Although my feelings about the current state of world affairs doesn't seem to reflect in my newsletter, don't think that I'm not going through the same roller-coaster of anger and pride as the rest of the worldwide community.
However, there is one thing about these latest events that does bother me, and it's the misguided marketing and commercialization of this tragedy by many organizations. I can almost tolerate the don't-know-any-better t-shirt sales at the roadside gas station that promote the capture of the bad-guys ($14.99 for a large 100% cotton shirt?), but I'm at a loss to understand why any company would attempt to promote themselves at the expense of these innocent victims.
I've already seen web sites and received email messages from network-related organizations that express sorrow and concern, while at the same time (and usually in the same paragraph) promote their products or services by explaining how they are providing assistance to the organizations that are directly affected by the terrorist attacks.
It's not that I don't appreciate a company that will help a fellow human being in their time of need, but I'm disgusted when a company's assistance transforms itself into a marketing campaign that is used to promote products or services in an attempt to increase the bottom-line. If you are one of the companies that have been affected by September 11th, then you _know_ what these companies are doing to assist you. If you were fortunate that your organization wasn't tragically affected by these recent events, then you know that everyone (and every company) is doing everything they can to help those that need assistance. Not every company is taking advantage of this emotional situation, but there are some who feel the need to toot their own horn.
Here's what I want to say to the companies that can't think past their corporate profiteering mentalities and the marketing department's need to issue a press release after these recent events: It's insulting to the surviving families of these tragedies for you to promote yourself in this aftermath. It's also insulting to the rest of us for you to assume that you can impress us with these 'heartwarming' stories of how you 'saved the day' by keeping the network running during this event. The true heroes are those civil servants who've helped save lives and those that lost their own during this disaster. The rest of us just did the best we could during those days and weeks afterwards.
Every company that assisted (and who didn't?) did so because it was the right thing to do, not because their marketing department thought it would make good press. It's a shame that the management of these organizations can't make a positive statement without some type of money-making slant. Express your sorrow, tell us that you'll do whatever you can to help, and point those affected companies to a web page on your site where they can learn more about your offers of assistance (note to the misguided: this is NOT your home page). We all feel the need to express our condolences and concern, just don't let your quarterly revenue quota impact your message.
These are difficult and emotional times, and perhaps I'm overreacting. Then again, perhaps I'm now seeing more clearly than I ever have.
- James 'FDNY' Messer
Network Uptime
James@NetworkUptime.com
====
Q and A
- Why is Size Distribution Important? -
====
Almost every network analysis tool has a graph or table displaying the size of packets grouped into a distribution of size ranges. These displays show the total number of frames or bytes, and help to provide an analysis of traffic patterns over time. As traffic pattern sizes change, the size distribution display will show the severity of the change.
During a file transfer, the smallest distribution and largest distribution packet values should be relative to each other. That's because the large packets during the file transfer are acknowledged by the receiving station. If you're using a protocol to transfer the file that doesn't require acknowledgements, then you won't see this pattern in the size distribution table.
But how can the size distribution display provide assistance? Examine packet size distributions during `normal' network activity in the size distribution display. File transfers and backups can change the perspective of network traffic, and the size distribution can provide feedback on network efficiency. If a backup or file transfer is active, the number of the largest and smallest distributions should increase in response to the large number of data frames and acknowledgements. If the 1024-1518 sized packets aren't increasing with large data transfers, then the maximum packet sizes may need to be optimized.
====
Network Uptime Surf Report
- SNMP Version 3 -
- http://www.ibr.cs.tu-bs.de/ietf/snmpv3/
====
Are you using SNMP as part of your overall network management solution? If so, you'll want to get updated on the latest activity related to SNMP version 3! The Technical University of Braunschweig's Computer Science department has an extensive site that describes the SNMPv3 specification, provides lots of documentation, demonstrates practical SNMPv3 implementations, and gives updates on the SNMPv3 working group.
Visit The Technical University of Braunschweig at:
http://www.ibr.cs.tu-bs.de/ietf/snmpv3/
====
Network Uptime Tutorial
- Analyzing Frame-Relay Statistics -
====
Frame relay is an efficient wide area technology, but this increase is efficiency is countered by a more complex system of network management at the data link layer. When examining the operation of a frame relay network at the packet level, there is a lot of network management functionality that isn't found on a point-to-point WAN link.
Most frame relay networks use a management communication method called Local Management Interface, or LMI. These LMI frames allow the relay switch and the local WAN router to send keep-alive messages and status updates. These LMI frames can also transfer information about the Committed Information Rate (CIR) that is configured on the frame relay switch.
Frame relay routers or access devices are usually configured to send LMI Status Enquiry frames and receive Status frames every ten seconds. These Status Enquiry/Status frames act as the keep-alive method for the frame relay link. Here's a summary of the Status Enquiry and the Status response:
Destination Source Delta Time Protocol Summary DCE.DLCI.1023 DTE.DLCI.1023 0.000.000 LMI Keep Alive Status Enquiry DTE.DLCI.1023 DCE.DLCI.1023 0.000.260 LMI Keep Alive Status
Every sixty seconds, a Full Status message is sent from the frame relay switch. This Status Update frame contains information about each frame relay Permanent Virtual Circuit (PVC), including the channel configuration, active or inactive status, and (optionally) the CIR value that is configured for the PVC in the frame relay switch:
DLC: ----- DLC Header ----- DLC: DLC: DLC: Frame 6 arrived at 11:10:17.6444; frame size is 69 (45 hex) bytes. DLC: Destination = DTE DLC: Source = DCE DLC: FRELAY: ----- Frame Relay ----- FRELAY: FRELAY: Address word = FCF1 FRELAY: 1111 11.. 1111 .... = DLCI 1023 (LMI) FRELAY: .... ..0. .... .... = Response FRELAY: .... .... .... 0... = No forward congestion FRELAY: .... .... .... .0.. = No backward congestion FRELAY: .... .... .... ..0. = Not eligible for discard FRELAY: .... .... .... ...1 = Not extended address FRELAY: LMI: ----- Local Management Interface ----- LMI: LMI: Unnumbered Information LMI: Local Management Interface (LMI) LMI: Call reference LMI: Message type = 7D (Status) LMI: LMI: Information element 01 (Report type) LMI: Report type 00 (Full status message) LMI: LMI: Information element 03 (Keep alive) LMI: Current sequence number = 134 LMI: Last received sequence number = 131 LMI: LMI: Information element 07 (PVC status) LMI: PVC DLCI = 102 LMI: PVC status = X2 LMI: .... 00.. = Channel is present LMI: .... ..1. = Channel is active LMI: .... ...0 = Below buffer threshold LMI: Bandwidth = 32000 bits/second
Examining the information in a Full Status message can be enlightening, especially if your frame relay system is using an LMI type that sends CIR values in the Full Status messages. With this LMI type, it's easy to see if the frame relay provider has configured the PVCs with the correct CIR information.
LMI is a good source of frame relay information, but there is a frame relay header attached to each frame traversing the WAN that contains more interesting information. Each packet's frame relay header contains three important bits that will indicate Forward Explicit Congestion Notification (FECN), Backward Explicit Congestion Notification (BECN), and Discard Eligibility (DE).
FRELAY: ----- Frame Relay -----
FRELAY:
FRELAY: Address word = 1841
FRELAY: 0001 10.. 0100 .... = DLCI 100
FRELAY: .... ..0. .... .... = Response
FRELAY: .... .... .... 0... = No forward congestion
FRELAY: .... .... .... .0.. = No backward congestion
FRELAY: .... .... .... ..0. = Not eligible for discard
FRELAY: .... .... .... ...1 = Not extended address
The FECN and BECN indicators are changed by the frame relay switches if congestion is encountered in the WAN. The frame relay switches will enable the FECN bit towards the congested traffic's destination and will enable the BECN indicator as traffic moves towards the congestion's source. These bits are seen by the frame relay access device, which then controls any traffic shaping or throttling. Many routers do not modify any traffic patterns, regardless of the number of frames received with a BECN or FECN indicator.
The Discard Eligible (DE) bit is used by the frame relay switch to determine which frames could be removed by the frame relay network if the CIR values are exceeded. If WAN traffic exceeds the configured CIR, then each frame exceeding this utilization rate will have the DE bit set to 1 by the frame relay switch. From this point, the frame will be eligible for discard at any hop along the frame relay cloud. Many frame relay users set their Committed Information Rate for zero kilobits per second, and rely on the frame relay cloud's available bandwidth to get traffic through the link. If the frame relay network becomes busy, these frames are the first to go!
It's almost impossible to manually keep count of all of these bits as each frame traverses the WAN. Almost all WAN analyzers include counters that track these frame relay statistics in real-time. If any FECN or BECN counters are in constant change, then you need to contact your frame relay provider and inquire about the congestion notifications. In some cases, a FECN or BECN issue may simply be an improper buffering configuration in the frame relay network!
Frame relay networks include all of these helpful network management features. Are you taking advantage of your frame relay management tools?
====
Network Uptime Analysis Tip
- Questions, Questions! -
====
What's your favorite color? Why is the sky blue? What have we got to do to put you in this car today? Is your network analyzer asking questions? More accurately, does your network analyzer prompt you to ask questions about your network?
Many of us use a network analysis tool every day, and we often head directly to the capture/decode features of our analyzer. We'll capture some frames, decode some frames, watch some server conversations, and monitor the overall traffic traversing the network. Although traffic decodes provide detailed packet information, there may be many questions about the overall network health that you may be missing.
The monitor functions and graphing capabilities of a network analyzer should prompt the network analyst to ask questions about network usability. If the utilization of the network is high, then who's using the bandwidth? After examining a Top Talkers list, there might be a few network users who are using a majority of the bandwidth. Why do those users require so much bandwidth?
Even looking through non-filtered protocol decodes can prompt for additional questions. Why are there so many BPDU multicasts? Why is our primary application sending information in such small frames? Is there anything we can do to make this application run more efficiently?
The next time you are troubleshooting a network problem, take a few minutes to ask some questions. You may be surprised at the answers!
====
Ending Delimiter
====
If you're reading a forwarded copy of Network Uptime, sign up for your own FREE subscription:
http://www.NetworkUptime.com/newsletter/
To unsubscribe from Network Uptime, use the above URL, or email Majordomo@NetworkUptime.com with the following text in the body of the message:
unsubscribe NetworkUptime
For questions or comments, email us at James@NetworkUptime.com or visit the Network Uptime web page at http://www.NetworkUptime.com!
Posted by james_messer at October 7, 2001 02:40 PM