|
| Top | Log In | Cart Contents | Checkout |
Getting Started with ET/HDLC For LinuxInstallation
Configuring Serial Lines
Using the multilink Utility
Extras
Using the ifhdlc Routing Utility Debugging HDLC Serial Lines with hdebug 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/HDLC Installation and Configuration Manual for information on the specific board that you have received. When configuring ISA communications boards, be certain that there are no conflicts with other devices. PCI board shouldn't require any configuration and should function in the majority of environments with factory settings. Loading the ET/HDLC HDLC/Frame Relay Distribution The ET/HDLC distribution for Linux includes drivers and support utilities for HDLC, PPP, Frame Relay and X.25. The latest version of the software is available from ftp.etinc.com/pub/linux/linux24_hdlc.tgz. All of the files are stored with full paths (although tar may strip these, depending on what version you are using) and can be extracted by simply entering the following commands: cd / This will unpack the distribution into /usr/hdlc and /usr/x25. The distribution directories are as follows:
Installing the Driver Modules in Linux In order to use our cards in your v2.4 LINUX system, you will need to either build a compatible kernel or use one of our pre-built kernels. Installing the Pre-built 2.4 kernels in LINUX If you are using an IDE hard drive you can use pre-built kernels that include the changes necessary for our
drivers. The kernels are located at ftp://ftp.etinc.com/pub/linux/kernels/osversion where version is the
version of kernel you need. Each kernel has 3 components: Making Your own LINUX v2.4 Kernel If you need to make a custom kernel or for some reason don't want to use ours, you will need to replace dev.c with our modified version. The dev.c file is located on your system in /usr/src/linux/net/core directory, if you are using a standard installation. The modified version is located in our distribution at /usr/hdlc/dev/modules/version/dev where "version" is the version of your OS. To copy the file, do something similar to the following: cd /usr/src/linux/net/core After that, you can build your kernel as you would normally. Make certain that you disable modversions or you will not be able to load the ET/BWMGR module. For v2.2 Linux, the entire HDLC subsystem is provided in the form of a loadable module (ie no changes are required for the kernel). You will, however, need to use our modified ethernet drivers if you will be using the bandwidth manager. Please check the ET/BWMGR User Manual for more information on the procedure for installing ethernet modules.. Installing the HDLC Driver Using insmod The ET HDLC board drivers and HDLC subsystems are contained in the module, ethdlc.o, which is located in /usr/hdlc/dev/modules/version. You need to copy the module into the appropriate directory in your system so that it can be loaded with the insmod utility. Modules in most linux v2.4 distributions should be placed in /lib/modules/version/kernel/build/drivers/net where version is the version of the OS you are using (obtainable by using 'uname -r'). You simply need to copy the modules up to the directory and them use insmod to install it. For example, if you are using linux kernel version 2.4.5, you would do the following: cd /usr/hdlc/dev/modules/2.4.5 this installs all of the ET supplied modules into the modules directory for kernel version 2.4.5 (note that you may want to backup the original modules first!). Once this is done, you can install the module into the system with the insmod utility. The insmod utility can be run from the command line and accepts as an argument the name of the module. For version 2.0.x kernels the driver name is et5025.o. For version 2.2.x and 2.4.x kernels the driver name is ethdlc.o. If you have a PCI (ET/5025PQ, ET/PCISYNC or ET/HSSI) card, then no parameters are required. All that's needed to load the module with PCI cards installed is as follows: insmod -f ethdlc insmod should print the results, either to the console or to the syslog file, indicating whether or not the procedure was successful. Note that sometimes insmod is not reliable in being able to find modules using the procedure above. If you have problems, you can always load the modules using the full path name of the file. For example: insmod -f /usr/hdlc/dev/modules/2.4.5/ethdlc.o The above command can always be expected to use the exact filename specifed (note you DO need the .o on the end). If successful, you should get a printout telling you what adapter was found and the network interfaces that were established. For example: <ET/PCISYNC Quad Adapter>
This is a typical display for a quad port PCI interface. ISA cards require that you provide the IO and IRQ settings (See Below). Loading the Linux Driver Module with ISA card parameters Unlike PCI cards, ISA cards require the operator to tell the driver at what address the card can be found, and also what IRQ the card is jumpered for. You supply the address and irq info on the command line with the insmod utility to tell the driver what addresses and irqs to use. For example: For Linux 2.2.x insmod ethdlc.o io=0x240 irq=5 This command would probe a single port ISA board with default parameters. The Linux 2.2.x driver will dynamically allocate an interface for the card depending on what other cards are in the system. PCI boards are always probed first, so if you had a quad PCI card and a single port ISA card the ISA card would be at interface ets4. Probing More Than 1 ISA Card If you have a dual port card or multiple ISA cards, you can also specify the probing information on the command line. The ethdlc.o driver for version 2.2.x is very flexible but you do have to make note of where boards are found. For a dual port ET/5025-16 board , the following syntax is required: insmod ethdlc.o io=0x240,0x250 irq=10,0 If the dual port board is the only board in your system, then the ports should be found and assigned ets0 and ets1. This same procedure can be carried out for any number of ISA cards. Note that the v2.2.x driver supports 16 total ports. If you had 2 single port cards, you would specify the base and irq of each: insmod ethdlc.o io=0x240,0x280 irq=5,4 Rebuilding Your Kernel without CONFIG_MODVERSIONS If your current kernel does have the CONFIG_MODVERSIONS option set to yes, you will need to rebuild your kernel with the option disabled (set to no). When you run the configure utility, answer set CONFIG_MODVERSIONS to "no" when prompted and then rebuild the O/S as usual. If you are unsure of whether or not your current kernel has this option set, look at /usr/src/linux/.config and check to see if modversions is enabled. Our driver is a pre-compiled binary and is not compiled with SMP (multi-processor support) enabled. Our drivers will not run in SMP systems in LINUX. We do support SMP in FreeBSD if this is a requirement. 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 (ets0.fr.cfg), PPP (ets0.ppp.cfg) and Cisco HDLC (ets0.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 ets# (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 ets0 192.45.32.1 pointopoint 192.45.32.2 will set the internet address of the ets0 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: ets0 Link encap: UNSPEC HWaddr: 00-00-00-00-00-00-00-00-00 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 eth0 192.45.17.1 These commands tell the IP subsystem that ethernet adapter eth0 is attached to network 192.45.17 and that interface ets0 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. Note that you must have the IP Forwarding (Gateway) parameter in LINUX set to use your LINUX system as a WAN router. Check linuxconf to make sure forwarding is set. Alternatively, you can check /etc/sysconfig/network and make sure that the parameter is set as follows: IPV4_FORWARD="YES" 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 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. Another, and perhaps better implementation method is to provide logical "mapping" of channels, allowing for the use of more appropriate and higher performance data structures than are available for physical device resolution. The Emerging Technologies' Frame Relay implementation utilizes a combination of both methods to guarantee both performance and flexibility. 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 ets0.fr.cfg It is not necessary to configure ets0 with an address in version 2.2 of LINUX, however you must bring the interface UP otherwise the device will not be "opened". In LINUX v2.2.x kernels use: ifconfig ets0 up to open the device properly. 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 ets + 'a'+line# + DLCI all lines begin with 'ets'. 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 'etsa100'. To configure DLCI 94 on line 3, the interface would be 'etsc84'. 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 etsa16 should not complain that etsa16 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 etsa16 192.45.1.1 pointopoint 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 gw 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 etsa16, 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 etsa16 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 etsa16 192.17.1.2 pointopoint 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 gw 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 ets0 might display something like the following: ets0 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 ets0 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 Tuning a Serial Line with our Bandwidth Management Tools Once you've gotten to routers to "talk" over a serial or frame relay connection, you may want to tune the serial lines to get better performance. There are several tools that we provide that allow you to customize a serial connection to get the most out of your available bandwidth. See bwman.htm for information on configuring bandwidth management. 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 The usagemon utility can be used 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 1 second to 6 hours (21600 seconds). You can enable usage monitoring with the following syntax: usagemon ets0 600 Where ets0 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 ets0 will yield output similar to the following: ets0 running PPP link state:UP LCP state: CP_OPENED IPCP state: CP_OPENED Utilization In: 42374bps Out: 15618bps (600 Seconds) This can similarly be done on a DLCI/channel basis for frame relay, simply by indicating the sub-interface name: usagemon etsa16 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 ets0 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 ets0 Data Compression - To Compress or Not to Compress When connecting 2 Linux devices, data compression can be enabled to increase throughput on the line. Data compression is available for lines configured as HDLC, PPP, 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. Using 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 (ets0) was configured for LAPB. To enable compression on this line, use the following command syntax: ifhdlc ets0 compress To disable compression in the line, use the following: ifhdlc ets0 -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: maproute DLCI18 -b -g -c 192.67.21.1 ipxconfig ipxwan ets0 0.0.11.78 18 -c 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: maproute DLCI18 -b -g 192.67.21.1 ipxconfig ipxwan ets0 0.0.11.78 18 ifhdlc ets0 18 compress This sequence of commands properly maps the IP and IPX protocols and then enables data compression for all protocols on line 0, DLCI 18. |
Support
Bandwidth Control