|
| Top | Log In | Cart Contents | Checkout |
Configuring Serial Lines
ET/BWMGR Manual
Extras
Communications Board Installation The first thing to do before loading the distribution software is to install the communications board into your PC. See the ET/PCX.25 Installation and Configuration Manual for information on the specific board that you have received. When configuring the communications board, be certain that there are no conflicts with other devices. Loading the ET/HDLC HDLC/Frame Relay Distribution The ET/HDLC distribution for FreeBSD and Linux "UNIX" includes drivers and support utilities for HDLC, PPP, Frame Relay and X.25. Note that your communications board must have the proper ID module installed in order for the driver to operate. ( Also note that if you are installing the driver is BSD/0S 2.0 or greater you will need at least version 2.20 of our driver).The software is supplied in tar (actually pax) format on a single floppy diskette. All of the files are stored with full paths (although FreeBSD will strip these) and can be extracted by simply entering the following commands: BSD/OS
FreeBSD:
The distribution is loaded at /usr/hdlc and /usr/x25. The distribution directories are as follows:
Note that the development code is only included if you purchased the dev kit. Some of the examples in this book assume that you have created the following symbolic link:
Adding the Device Driver to the KERNEL for BSD/OS and FreeBSD In order to utilize the ET/HDLC product, you must incorporate the driver code into the operating system by linking the device driver with the BSD kernel. It is assumed that you are familiar with building a BSD kernel, and that the kernel source code has been loaded onto your hard disk. If this is not the case, please read the documentation on building an operating system for BSD before continuing. It is highly recommended that you successfully build and run a KERNEL before attempting to add ET/HDLC to your system. The driver component of the HDLC subsystem is contained in a single object file named et5025.o located in the /usr/hdlc/dev directory. This file contains all of the code necessary to incorporate the HDLC subsystem into the operating system. A script has been provided which will copy the file to the proper directory in the build tree. To run the script, enter the following: /usr/hdlc/dev/update Once you have copied the files into their proper directories, you need to add some lines to a file called /sys/i386/conf/files.i386. This file contains the names of the source and object files required by devices and for build options. The file /usr/hdlc/dev/files.i386 contains the files required to be added to the configuration directory master file. With an editor (such as vi), add the lines from the appropriate version of BSD/OS in this file to /usr/src/sys/i386/conf/files.i386. Now, you need to add the device driver to the kernel definition file. The following discussion assumes that you have copied the supplied GENERIC kernel to a file named LOCAL, and edited it so that it represents your actual system configuration. As stated before, it is highly recommended that you build and test the new "LOCAL" kernel before proceeding. To add the ET/HDLC HDLC device driver to your KERNEL, edit the file LOCAL and add the following line: For BSD/OS: device eth* For FreeBSD: device eth0 where III is the I/O address of the ISA communications board, Q is the IRQ MMMMM is the physical address of the on-board RAM memory, and SSSS is the amount of RAM on the board (either 0x8000 or 0x10000). Note that the iomem parameter is not used by the device driver; the value in the configuration file loaded by hdlccfg (described later in this document) is used. If you have a PCI board then the first entry above is used (no port or memory specification is required). A sample device description (which in fact represents the default configuration of all of our boards) can be found in the file /usr/hdlc/dev/device.sample. You should check this file for any late changes for the current release. Installing the Bandwidth Manager Device If you will be using the ET/BWMGR bandwidth manager, you will have to add the bw0 device to your kernel. The sample file on your distribution disk device.sample includes a sample for your particular O/S. The line that needs to be added is: device bw0 at isa ? The device will always probe good, so if you did everything properly you should see the device in your list of devices when you reboot the machine. The bandwidth limiter requires a change to the file if_ethersubr.c, so you also must install our replacement version, if_etherbwmgr.o (for which all of the BSD license stuff applies). The update script installs this file appropriately, but you must do 2 things in order to ensure that the supplied module is built into your kernel. First, you must edit /usr/src/sys/conf/files and comment out the line that contains the if_ethersubr.c line. Then, you must edit /usr/src/sys/i386/conf/files.i386 and uncomment the line which has if_etherbwmgr.o (this is one of the lines that you added before, and is in the /usr/hdlc/dev/files.i386 on our distribution). You should also do a "make clean" in your build directory before building a new kernel. For up-to-date information on these file modifications, check the device.sample file provided with the distribution. Installing the Standalone Watchdog Timer If you purchased the standalong watchdog timer card, you need to install the wdt.o module rather than the et5025.o module. You can do this by indicating the wdt0 device in your device file rather than eth0. Note that you cannot run the ET/BWMGR with the standalone watchdog timer. To include the wdt0 device in your kernel, insert the following line in your system configuration file: For BSD/OS: wdt0 at isa? port III iomem For FreeBSD: wdt0 at isa? port III where III is the IO address of the board (default 0x280). Also you will need to include the line in your /usr/hdlc/dev/files.i386 file containing the wdt device in your system files.i386 file. Within the KERNEL definition file (LOCAL for this example), there are options which enable various network features in the operating system. If your BSD system is to be a gateway for other devices on a local network, you need to enable the GATEWAY option as follows: options GATEWAY This option enables IP forwarding in the system. If you are going to be using the ET/5025 class boards as transparent point-to-point serial interfaces for IP internetwork routing, you may need to specify the appropriate option in the system configuration file. If you are going to run PPP (Point-to-Point Protocol) on your ET synchronous card, you do not need to set the "options PPP" option in the kernel as we use our own internal implementation. If you will be using PPP in the system for other interfaces (i.e. dial-up), you will need to set the PPP option as our implementation only supports our card. Note that use of BSDI's CISCO_HDLC is NOT supported. ET supports its own version of Cisco's proprietary serial line protocol. See the section titled "Connecting to a Cisco Router with HDLC encapsulation" later in this document for configuration details. In previous versions of ET/HDLC, you needed to enable the ET_CISCO_HDLC option in the system configuration file. This option is now built into the object module as the default. Configuring a BSD System to Route IPX Packets The et5025.o module adds the capability to route Novell Netware® packets to your BSD/OS or FreeBSD system. In order to route IPX packets you will have to install the bandwidth manager (described previously). The hooks to receive IPX packets are included in the if_etherbwmgr.o module. Building the new BSD/OS or FreeBSD KERNEL Once you've set your options, you're ready to build the new KERNEL with the HDLC device driver. To build a new KERNEL, the following commands are required for BSD/OS:
Note that for FreeBSD 3.0-RELEASE only you need to add the line in the provided file /usr/hdlc/dev/isa_device.h to /usr/src/sys/i386/isa/isa_device.h inthand2_t ethintr; This is only required in FreeBSD 3.0. At this point, you should be able to build your kernel with the following commands:
After a successful build, you should reboot the machine with the new operating system. To be safe, you should not overwrite the working operating system. If you are not experienced with building BSD/OS operating systems, you should adhere to the following procedure: 1) First copy the new KERNEL to the root directory.
2) Shutdown the machine. shutdown -fh now or halt 3) Press reset. When the system starts to boot, you'll see the following message on BSD/OS:
As soon as you see this message, press and hold the space bar. You should see the following message: ...load aborted. Boot: Note that on FreeBSD you will get the Boot: prompt without having to hit the space bar. 4) Load the new kernel. At the Boot: prompt, enter:
The newly created kernel should begin to boot. The system will display devices as they are detected, and at some point you should see something similar to the following line displayed on the screen: eth0 at isa0 iobase 0x240 irq 5 maddr 0xd0000-0xd7fff This message informs you that the board was found at the specified base address and that the interrupt is at the vector specified. You are now ready to use the ET/HDLC product. If you do not get the above message, then the board was not found and you should check the jumpers on the board. If the jumpers are correct, then you should check to make sure that there are no I/O address or IRQ conflicts with other devices. Once you have tested the kernel, you can rename it to the default name (/bsd or /kernel). Running hdlccfg to Start the HDLC Subsystems The HDLC subsystem requires too much information to be properly configured at boot time, so you must run a utility (/usr/hdlc/utils/hdlccfg) which reads a configuration file and configures the board and HDLC subsystem. Before running the configuration utility, you should create a line configuration file which represents the appropriate HDLC environment. Sample files for configuring lines for Frame Relay (eth0.fr.cfg), PPP (eth0.ppp.cfg) and Cisco HDLC (eth0.cisco.cfg) operation have been provided in /usr/hdlc/utils. Please note that it is assumed that you are somewhat familiar with the HDLC protocol. The syntax for the hdlccfg utility is as follows: hdlccfg cfgfile The hdlccfg utility reads a file (cfgfile) which contains the configuration parameters for a given HDLC line (line#) installed in the system. Beginning in version 2.0, the configuration file parameters will determine what protocol you are running on the line. (A description of the configuration file format and parameters is presented in the ET/HDLC Installation and Configuration Manual). Presently supported protocols are Frame Relay, PPP, transparent HDLC and Cisco HDLC. Before any functional commands can be issued to the serial lines, the lines must be set up with all of the appropriate parameters. As an example, suppose that you have 2 HDLC lines installed in your system, the first of which will run the PPP protocol and the second of which will run Frame Relay. The following commands would be required: /usr/hdlc/utils/hdlccfg /usr/hdlc/utils/ppp0.cfg where ppp0.cfg is a PPP configuration file for line 0 and cisco1.cfg is a Cisco HDLC configuration file for line 1. hdlccfg will read the configuration file and issue a configuration request to the specified HDLC line. Upon successful completion, the communications board is initialized and the link level protocol is started. (In PPP, the LCP link protocol is started (configuration requests are sent) while in Cisco HDLC mode keep-alive processing is started. The driver will simply exit if everything is configured properly. You can use the ifhdlc utility (described later) to determine the status of your link. Setting up a Serial Line for IP Routing The HDLC subsystem can be accessed in the same manner as any other configured network interface in your system. The device name is eth# (where # is the line number) configuration commands may be issued via the ifconfig utility. If you run ifconfig and it gives you an error message such as "no such device", then the module probably wasn't properly loaded by insmod. This may happen if you've failed to configure your kernel with CONFIG_MODVERSIONS enabled or if your are running an incompatible version of Linux. When you first run ifconfig, it make show erroneous information about the link encapsulation, but this can be safely ignored. Since our product is a completely contained protocol engine, the O/S simply sees it as a raw device and our driver properly handles the encapsulations. Routing IP Packets over a Point-to-Point Serial Line The IP routing feature is initialized the first time an address is set for the interface. For example: ifconfig eth0 192.45.32.1 192.45.32.2 will set the internet address of the eth0 interface to 192.45.32.1 and also indicates that a device with address 192.45.32.2 is on the other end of this link. After issuing this command, an ifconfig should show the two addresses as entered: eth0 flags=51<UP, POINTOPOINT, RUNNING> INET: 192.45.32.1--> 192.45.32.2 From a functional standpoint, the internet addresses assigned with ifconfig to the HDLC interface represents the gateway address for the remote device on which to forward IP traffic. Likewise, the local address (in this example, 192.45.32.1) is needed for the local routing entity in order to identify the interface on which to forward packets accessible via the gateway at 129.45.32.2. It does not specifically identify any useful IP entity, however. In order to reach other devices on another real network, another network route would need to be defined via the route command or router information exchange. For example, suppose that you have an NE2000 interface connected to an ethernet network and an HDLC interface. The device on the other end of our serial link (with serial line address 192.45.32.2) is installed in a system with an ethernet interface on network 192.45.28. The following illustrates some basic setup which would allow us to route packets from devices on our network (192.45.17) to the remote ethernet network (192.45.28): ifconfig fxp0 192.45.17.1 These commands tell the IP subsystem that ethernet adapter fxp0 is attached to network 192.45.17 and that interface eth0 has the network address 192.45.32.1. The linux subsystems will automatically add the route 192.45.32.2 to your routing table when implementing this command. Hence, whenever a packet arrives destined for network 192.45.28 (or host 192.45.32.2), the IP layer will pass it off to the HDLC interface. Configuring ET/HDLC for Frame Relay Operation Emerging Technologies' Frame Relay protocol operates transparently to the user, however a basic conceptual understanding of the interaction of the IP and the Frame Relay subsystems is critical to proper configuration and operation. The philosophies for implementing multi-channel interfaces vary from vendor to vendor; the usual "UNIX" method is to map each channel to a physical pseudo-device, which can then be accessed as if it were a separate physical device. Unfortunately, this happens to be a very poor method for Frame Relay , particularly because it is inefficient and cumbersome when the number of channels is large. In order to implement some of the more complex routing protocols it is, unfortunately, a necessary evil. In order to model complex networking scenarios, we introduce the concept of sub-interfaces, which may be used to simulate separate physical networks on a single physical device. Configuring the Line for Frame Relay Frame relay lines are configured in the same manner as Point to Point serial lines using the frame relay configuration file format: hdlccfg eth0.fr.cfg Mapping IP Address to Frame Relay Channels Frame Relay uses channel units (DLCIs) which are permanently tied to another location within the Frame Relay network "clouds". These connections (called Permanent Virtual Circuits or PVCs) can logically be considered as point-to-point serial connections to destination routers. Like point-to-point serial connections, you must tell the router which networks are connected to which channels. There are two ways to configure a frame relay connection. One is to configure it like a point-to-point connection, and the other is to configure it like a multi-point network, like ethernet. The issue with configuring it like a multi-point network is that its not really a multi-point network. With Ethernet, all devices can access one another directly, although with frame relay all of the devices are not connected unless you have what is called a "full-mesh", which would require that all devices on the logical network have a DLCI to every other device. This is very uncommon and not very cost effective. However, if you are a service provider or have a central hub (and the leaf node devices do not need to talk to each other) then a "star" network model is a good way to conserve addresses. To set up a point-to-point frame relay connection, you assign a local and remote host address to the frame relay interface, just as you would with a point-to-point connection. However, in order to model this properly for the operating system, you must first allocate a sub-interface so that the routing subsystem can "see" the connection. Luckily, we have a simple utility that does most of the work for you. Using the maproute Utility to Create Frame Relay Sub-Interfaces The maproute utility is provided to simplify the configuration of Frame Relay networks and also is used to create sub-interfaces for frame relay connections. The syntax for the command is as follows: maproute newinterface -a where newinterface indicates that the target interface for the frame relay DLCI. The interface specification consists of 2 parts eth + 'a'+line# + DLCI all lines begin with 'eth'. Frame lines have a 4th letter which indicated the line#, where 'a' = line 0, 'b' = line 1, etc. The 'unit' specifies the DLCI. So, to configure DLCI 100 on line 0 the interface name would be 'etha100'. To configure DLCI 94 on line 3, the interface would be 'ethc84'. When you configure a channel with maproute, a sub-interface is created which can be used to configure the system-level mapping. After issuing the command, use ifconfig to see if the interface was created properly: maproute etha16 should not complain that etha16 does not exist. After the maproute command, you can use the sub-interface to configure the route into the system the same way that you would if you had a regular point-to-point serial line. To complete the previous example, you would issue the following command: ifconfig etha16 192.45.1.1 192.45.1.2 once you have completed this, you should now be able to reach the 192.45.1.2 address (try pinging it). This address now becomes the gateway address for this frame relay connection. If this is your default connection, you could issue the following command to complete the routing setup:If you can ping it, use hdebug (described below) to see if the packet is going out the correct interface. Now you can tell linux to use the newly created interface as the deault route: route add default 192.45.1.2 Now, all of your traffic that is not for another locally defined network will be forwarded to the router with address 192.45.1.2 on interface etha16, aka frame relay DLCI 16. Using an Unnumbered Interface Model with Frame Relay The above model adheres to addressing and networking rules that have long been a part of the standard IP routing model. Serial lines, particularly those modelled as point to point, are a special case and can be set up in a way that does not require the use of any of your network addresses. There is also an additional functional benefit that we will expain later. As an example, suppose that your class 'C' address is 197.11.4.0 and your ethernet card's address is 197.11.4.1. Also suppose that you are connecting (via frame relay) to a router with an ethernet address of 198.17.1.1 that is on a class 'C' network of 198.17.1.0. If the remote router does not require a specific frame relay address to be used, you can configure the frame relay connections using the ethernet addresses of the routers rather than dedicated addresses. For example: hdlccfg fr0.cfg 0 Note that the frame relay interface does not require specific addresses to function properly. Since the interface is set up as a point-to-point connection, the destination address (198.17.1.1) of etha16 is used as the gateway address for all routing table entries. An added benefit of this method is that your local ethernet address will be used as the source address for host transactions initiated on the router. A Simple Single DLCI Sample Configuration The following is a typical setup for a single DLCI frame relay site. Suppose that you received the following information from your provider: Your Frame Relay Address: 192.17.1.2 Their Frame Relay Address: 192.17.1.1 Your Side DLCI: 16 You could then set up your frame relay subsystem as follows: /usr/hdlc/hdlccfg /usr/hdlc/fr0.cfg maproute etsa16 ifconfig etha16 192.17.1.2 192.17.1.1 If, which is often the case, this is your default route, the next line would also be required: route add default 192.17.1.1 Using Other Routing Protocols - gated or zebra For more complex network interaction, you can run the gated or zebra daemon. Protocols supported by gated and zebra include RIP, EGP, BGP, OSPF and HELLO. A discussion of these protocols is well beyond the scope of this document. We recommend zebra as it is free and likely to stay that way. See www.zebra.org for info in obtaining zebra. Using the ifhdlc Routing Utility ET/HDLC provides additional utilities to allow users to obtain information about the configuration of the HDLC substystems. ifhdlc is an extension to the UNIX ifconfig utility which will display the serial line protocol running on the line. For example, if you issued an ifconfig on ets0, you might get a display as follows: ets0: flags=41<UP, RUNNING> All that this really tells you is that the link protocol (whatever it is) is up and the IP router is running. Since the POINTTOPOINT flag is not set, you can infer that either Frame Relay or X.25 is running. By using the ifhdlc utility, you can obtain additional protocol-related information about each of your configured HDLC interfaces. The syntax of the command is as follows: /usr/hdlc/utils/ifhdlc [all | interface] When you issue ifhdlc with the all parameter, basic information about all of the HDLC interfaces in the system is displayed. For example: ets0 (ET/PCISYNC) Running CISCO HDLC physical link: UP <DSR> To obtain additional information about a specific interface, issue the command and also specify the interface. For example, the command: ifhdlc eth0 might display something like the following: eth0 running FRAME RELAY USER mode The above display indicates that DLCIs 18 and 24 have been mapped into the system, but that the network is only reporting that DLCI18 is up. This can mean that either DLCI 24 is not configured into the Frame Relay network, or that the virtual circuit is down, or that the router on the other side is down. Connecting 2 Routers Point-to-Point If you will be connecting 2 routers via a direct line, you must chose a protocol that both routers understand. There criteria that you use to select a serial line protocol may depend on many factors, but a major factor to consider is what protocols are strongly supported by the particular router vendor. Many routers support multiple protocols, but only 1 or 2 of them are implemented efficiently. Of the serial line protocols supported by ET/HDLC, the HDLC is the most efficient for point-to-point routing. If you will be connecting 2 PCs with this product installed back to back, then you should chose the Cisco HDLC protocol (descibed later in this document). If you are connecting to a Cisco router, either PPP or HDLC will do, however Cisco routers run HDLC much more efficiently than PPP so you should probably chose CISCO HDLC. Using ET's PPP Protocol Implementation Emerging Technologies' PPP implementation is specifically designed for high speed synchronous environments. When you are connecting to other routers point-to-point and the other router is not a CISCO router you will probably use PPP. Using our PPP is as simple as using a PPP configuration file and running hdlccfg. To debug a PPP line, use hdebug with the pppevts and/or ppptrace options. Our PPP implementation utilizes a high-performance hardware implementation and is designed to maximize throughput on high speed lines. When connecting to other devices, you should disable all PPP options on the remote device to ensure compatibility. Most PPP options are designed for low-speed asynchronous circuits and only cause compatibility problems in a sync environment. Connecting to a Cisco Router with HDLC Encapsulation ET/HDLC supports a variation of HDLC encapsulation which is compatible with Cisco Systems "encapsulation hdlc" serial line protocol. To configure a serial line for Cisco HDLC serial encapsulation, simply configure the lines using the cisco?.cfg files provided with your distribution. (see cisco0.cfg as an example), and then configure the line as a standard Point-to-Point connection. For example: /hdlc/utils/hdlccfg /hdlc/utils/cisco0.cfg ifconfig eth0 192.78.11.1 192.78.11.2 Note that you must set the keep-alive mechanism to have the same interval as the CISCO router. The default keep-alive interval is 10 seconds. To change the keep-alive interval to something other than 10 seconds, use the ifhdlc utility with the following syntax: ifhdlc interface keepalive interval where interface is the serial interface name and interval is the keep-alive interval. Is is also interesting to note that keep-alive processing can be disabled to reduce the overhead on a serial line. To disable the keep-alive on a serial line, simply set it to 0. For example, to disable keepalive processing on line 0, issue the following command: ifhdlc ets0 keepalive 0 to disable keep-alive processing on a Cisco router, use the following commands: encapsulation hdlc no keepalive Load Balancing and Multi-interface Bundles Up to 8 lines or virtual interfaces can be "bundled" using ET's multilink utility. The multilink utility allows you to create "bundles" which can be used to either load balance or create fallback links between 2 or more serial lines or virtual circuits. Note the multilink is NOT PPP multilink, it is a load-balancing mechanism that is compatible with any PTP line. Creating a Multilink Bundle To create bundle, you must first create a root interface which will be used as a virtual access point for the bundle. Root interfaces must be named name? Where ? is a unit value between 0 and 8. Each bundle may have a different name, but they each must have different unit value. It is recommended that you start with 0. So, to create a load balancing "bundle", you could use the following: multilink create -b multi0 where the -b option specifies that the members of the bundle are to be load-balanced. All that this command does is create an interface to be used as an access point to the bundle. To check to see if it was created properly, run ifconfig: ifconfig multi0 should display multi0 <MULTI BALANCE> if it was created properly. Adding Interfaces to a Multilink Bundle The next step is to add interfaces to the bundle. Now adding a single interface to a bundle doesn't do much (bundle implies 2 or more), so you really need to add at least 2 interfaces. Suppose, for example, you wanted to load balance eth0 and eth1. You could use the following to set up the bundle:
This would set up a load-balanced bundle with eth0 and eth1 as the interfaces. Note that the interfaces that are added to multilink bundles must be configured as if they were separate connections (which they are) before they are added to the bundle. This means that eth0 and eth1 must be configured normally before they can be added to the bundle. The 1 is a "factor" that will be explained later. Giving all of the members of a bundle the same factor implements equal balancing. Routing Through a Multilink Bundle Note that setting up a bundle doesn't do anything by itself. In order to utilize the bundle, you must configure it like a network interface and then route packets to it. Multilink bundles are implemented as PTP interfaces, so you need to assign both local and remote addresses. To configure the above bundle and set it up as your default interface, you would use the following:
These commands give multi0 an address and then tell the routing subsystem to use the bundle as the default interface. Whenever a packet is routed through multi0, the traffic will be balanced between eth0 and eth1. Creating a Fallback Bundle with Multilink You can also add an interface as "fallback" only, which means that it will only be used if the primary interface is down. You can use this to set up redundant connections which are only used when a primary link is down, or if you have a high speed and low-speed line and don't want to load balance. For example, suppose you had a T1 line on eth0 that was your primary link and a frame relay DLCI to a remote location that could be routed through if the T1 was down. You could set up a fallback bundle as follows:
This would set up a bundle with eth0 and etha16 as members, but would only route traffic on etha16 if eth0 was down. The order that you add interfaces to a bundle determines the precedence. So, with the above example, all traffic would be passed on eth0, if eth0 was down, then etha16 would be tried, etc. Note that in this example the -f option is not required as it is the default behavior of a bundle, however you do need it in the following example:
In this example, eth0 and eth1 are load balanced, and etha16 is defined as a fallback interface only if eth0 and eth1 are both down. In a load balancing scenario, you are most likely connected to a single router on the remote end, so if the router went out of service then both load balanced lines would go down. Displaying a Multilink Bundle You can use ifhdlc to display the members of a multilink bundle. For the above example, you could use the following: ifhdlc multi0 would display
The load balancing feature in our driver also allows you to do uneven balancing either to match the available bandwidth of the line, or to control the amount of traffic on particular lines. A classic example is if you have a T1 and a 56kbs line and a T1 line that need to be balanced. The T1 line (eth0) is 24 times faster than the 56kbs line (eth1), so you could keep both of the lines filled evenly with the following:
This would allow for the traffic to be balanced at a 24 to 1 ratio. You could also use the above if you had 2 T1 lines and one was slightly over loaded to force some of the traffic over another line. There is no requirement that both lines go to the same place, as long as both have a path to the ultimate destination. Monitoring Serial Line Usage with usagemon If you aren't using interface bandwidth limiting (if you were then usagemon would be a redundent function), you could use the usagemon utility to enable or disable traffic monitoring on a specific port or channel/DLCI. Monitoring will track usage over a specified time period, which can be any interval from 10 seconds to 6 hours (21600 seconds). You can enable usage monitoring with the following syntax: usagemon eth0 600 Where eth0 is the interface to monitor and the monitoring interval is 10 minutes. Every 10 minutes, the driver will log the usage to the previous 10 minute period and store it in a user-accessable location. You must read the info before the next 10 minute interval or the information will be lost. To read the information, use the ifhdlc utility with an interface specification: ifhdlc eth0 will yield output similar to the following:
This can similarly be done on a DLCI/channel basis for frame relay, simply by indicating the sub-interface name: usagemon etha16 600 Debugging HDLC Serial Lines with hdebug Included in the ET/HDLC distribution is a utility which can help to debug communications programs as well as aid in protocol troubleshooting. The utility accepts an interface name and one or more options which set the level of debugging information required. The syntax of hdebug is as follows: hdebug interface [hevts htrace lmi frdata frhex pppevts ppptrace] Following is a description of the options:
Any number of the options can be combined. For example, the command: hdebug eth0 hevts lmi will enable HDLC event display and LMI activity debugging on line 0. To disable debugging, simply call hdebug with no options as in the following example: hdebug eth0 See the Utility Manual for more information. Debugging a Frame Relay Connection When you first get a frame relay connection, there are often configuration problems with the frame relay provider that must be identified and corrected. Remember that you are dealing with a phone company or some other like entity, and the person that you are talking to on the phone may not have a very good understanding of the technology. Customer interface people are programmed to tell you that its your equipment that is broken, when virtually all of the time it is the network provider who has the line configured improperly. Assuming that you have you CSU/DSU working properly, you can use some of the following techniques to debug a frame relay connection that isn't working properly. A common situation is that the link simply doesn't come up; you get a "LINK DOWN" message after running hdlccfg and ifconfig shows the interface is down. The network provider will simply tell you that they're not seeing any LMI (management frames), but they're not smart enough to know whats really happening. The first thing that you need to do is to prove to them (and yourself) that the card is really sending frames out onto the wire. To do this, you can put your CSU/DSU into local loopback and set HDLC tracing on. What this will do is echo back the data that is being sent out. For example, use hdebug to enable debugging as follows: hdebug eth0 htrace About every 10 seconds or so you should see a line displayed on the console similar to the following: Tx HDLC/0 len:14 00 01 03 08 00 75 95 01 01 00 This is a hex trace of the actual data that is trying to be sent out. This doesn't prove that the data is actually making it out onto the wire, however. If you now put the CSU/DSU into local loopback, the data will be sent back to the router. After doing this, you should see something like the following:
Data Compression - To Compress or Not to Compress When connecting 2 BSD or LINUX devices, data compression can be enabled to increase throughput on the line. Data compression is available for lines configured as HDLC, Frame Relay or X.25. With data compression enabled, the router will compress the data field portion of IP and IPX packets before transmitting them onto serial lines. Since serial lines generally are the main bottleneck in wide-area communications, throughput can be increased by an average of 2:1 when data compression is enabled at line speed of 256kbs or less. ET/HDLC employs an on-the-fly software data compression algorithm that is optimized for speed. Note however that software compression is highly CPU intensive and there are factors which should be considered when deciding whether or not to use compression. Factors to consider are the speed of the host CPU, the line speed, and the total serial throughput of the system. For example, it takes 3ms to compress and decompress a 1000 byte packet on a 66mhz '486. This implies that to compress 2mb/second would consume 100% of the CPU. Another factor to consider is line speed versus the speed of compression. For example, to transmit 1000 bytes on a 56kbs line requires approximately 142ms. If the average compression ratio is 2:1, that means that you can save 71ms of transmit time for each 4ms of compression time on a 66mhz machine. On a T1 line, however, it only takes 5.2ms to transmit 1000 bytes, implying that data compression would have a negative effect on a T1 line. If you're not very good at math, there are a few general rules that you can follow. Don't use compression on any machine with less than a 33mhz '486, and don't enable compression on any lines over 512k. Also, don't enable compression on a machine that is near its reasonable throughput capacity if compression would result in an increase in traffic. If you've really been paying attention, by now you've realized that the data compression feature can improve used-perceived performance for fast machines with relatively low bandwidth WAN links. You can selectively enable and disable compression on individual connections, providing great flexibility and allowing each installation to be fine-tuned to maximize performance. Data Compression on Serial Lines To enable data compression on serial line, use the ifhdlc utility with the "compress" option. For example, suppose that HDLC line 0 (eth0) was configured for CISCO HDLC. To enable compression on this line, use the following command syntax: ifhdlc eth0 compress To disable compression in the line, use the following: ifhdlc eth0 -compress On point-to-point serial lines, the compression indicator is an HDLC level flag which attempts to compress data before handing it off to the hardware. This is an ideal scenario. For multi-channel line protocols, however, there may be some locations which can receive compressed data and others that can't. With this in mind, we certainly don't want to enable compression at the hardware level. We also need to be careful not to compress any header information that a network may need in order to properly forward packets. Data Compression on Frame Relay and X.25 Connections To utilize data compression on lines running multi-channel protocols like Frame Relay and X.25, we enable and disable compression on a circuit by circuit basis. For X.25 and single protocol Frame Relay implementations, compression can be enabled and disabled by using the -c option with the maproute utilitiy (described earlier). For multi-protocol Frame Relay connections, compression should be set with the ifhdlc utility. To enable compression on an X.25 connection, use the maproute utility with the compression option (-c). For example, to enable compression on one of our previous examples, use the following command: maproute 5551212 -c -g 192.45.23.1 since X.25 connections are dynamic, the channel if tagged for compresson at the time of establishment. The compression indicator is stored in the dynamic connection table and implemented when a virtual circuit is created. X.25 is also unique in that there is only 1 protocol allowed per connection, that is, you cannot have IP and IPX traffic using the same virtual circuit. You can also use maproute to enable compression on a frame relay circuit, but because Frame Relay can carry multiple protocols per connection, you must be careful not to create conflicts. For example, if you enable compression for IP traffic (with the maproute utility) but not for IPX traffic (with ipxconfig), only the last setting will be in effect. For example, to set compression on a Frame Relay connection transporting both IP and IPX traffic, you could use the following commands:
Although this will work, if you omitted the -c option in either command the results would vary. If you omitted the compression option in the ipxconfig command, compression would be disabled for BOTH protocols, because the last setting would override the first. For Frame Relay, it is recommeded that you enable and disable compression with the ifhdlc utility. This sets compression at the "logical hardware" level and effects all protocols running on a particular channel. It is also much easier to enable and disable compression on a demand basis. For example, to enable compression on a Frame Relay channel for our previous example:
|
Bandwidth Control
Demos