Increasing Bandwidth. Contents

Transcription

1 2 Increasing Bandwidth Contents Overview Configuring MLPPP PPP MLPPP LCP Options MLPPP Header MLPPP Configuration Concerns Enabling MLPPP Binding Multiple Carrier Lines to a PPP Interface Configuring MLFR Enabling MLFR Binding Multiple Carrier Lines to a Frame Relay Interface Configuring the Bundle ID Troubleshooting Multilinks Standard Procedure Physical Layer Data Link Layer Troubleshooting MLPPP MRRU ED Troubleshooting MLFR Quick Start MLPPP Configuration MLFR Configuration

2 Overview Overview Point-to-Point Protocol (PPP) and other Data Link Layer protocols establish point-to-point connections over a single carrier line, which may not provide sufficient bandwidth to meet a business s requirements. In a Frame Relay network, a single Frame Relay port might carry several permanent virtual connections (PVCs), all of which must share the bandwidth provided by one carrier line. If a WAN line has inadequate bandwidth, it can become congested and packets can be dropped. Purchasing a high-bandwidth E3- or T3-carrier line to sidestep these limitations is not always feasible because some environments do not support them. In addition, E3- or T3-carrier lines can be quite expensive, and you may not need the high-bandwidth they provide. Your organization may only need to double or triple its bandwidth, rather than increase it 28 fold. You cannot justify the high-cost of an E3- or T3-carrier line when much of the bandwidth will go unused. The ProCurve Secure Router supports link-aggregation protocols to address these problems. Such protocols treat multiple carrier lines as a single bundle, providing two advantages: Faster connections Traffic can access the combined bandwidth of the bundle. More stable connections If one line goes down, the other can still carry traffic. Theoretically, link aggregation is a simple idea: effectively double your available bandwidth by using two physical cables to connect your endpoints instead of only one, triple your bandwidth by using three cables, quadruple your bandwidth by using four cables, and so on. For example, you could aggregate two Mbps T1-carrier lines into a virtual single network connection with an underlying bandwidth of Mbps. The ProCurve Secure Router supports these link-aggregation protocols: Multilink PPP (MLPPP) Multilink Frame Relay (MLFR) Link-aggregation protocols such as MLPPP and MLFR take advantage of multiple physical cables by fragmenting frames into smaller frames. These fragments are passed simultaneously over separate cables and then reassembled by the receiving peer. (See Figure 2-1.) 2-2

3 Overview PPP PPP Frame Router PPP Frame E1 Line MLPPP PPP Frame Frame fragments Router a b c d e f Frag a Frag c Frag d E1 Lines Figure 2-1. MLPPP, a Link Aggregation Protocol 2-3

4 Configuring MLPPP Configuring MLPPP Although using MLPPP to increase a connection s bandwidth does not require deep technical expertise, you should understand: how a PPP session is established how MLPPP regulates the fragmentation and reconstruction of normal PPP frames Such an understanding will help you troubleshoot MLPPP connections and regulate data flow. PPP The two peers at either end of a point-to-point connection establish a PPP session in four phases. (See Figure 2-2.) 1. Link establishment LCP ProCurve Secure Router 2. Authentication (optional) PAP, CHAP, or EAP 3. Negotiation of Network Layer protocols NCP: IPCP, BCP, and so on 4. Session established PPP ProCurve Secure Router Figure 2-2. PPP Phases 1. Link establishment Peers exchange Link Control Protocol (LCP) frames to establish a link and negotiate the options for this link. These options include the maximum receive unit (MRU), which determines the size of the informational field in PPP frames, and the authentication protocol, if used. 2. Authentication Peers exchange frames for the authentication protocol agreed upon during link establishment. (If they did not select authentication, they proceed to the next stage.) After both peers authenticate themselves successfully, they proceed to the next stage. 2-4

5 Configuring MLPPP 3. Network Layer protocol Peers exchange Network Control Protocol (NCP) frames to negotiate which Network Layer (Layer 3) protocol the PPP frames will encapsulate. NCP frames serve two functions: they specify which Network Layer protocol will be used, and they negotiate options for that protocol. For example, IP Control Protocol (IPCP) is the NCP for IP. An IPCP frame can include IP addresses for DNS servers and a request to compress the IP datagram (which will be the PPP information field). 4. PPP PPP frames carry the actual information being transferred over the WAN link. In PPP terminology, this information is called a datagram. After the two peers successfully exchange LCP frames, authenticate the link (if authentication is configured), and negotiate the Network Layer protocol, a PPP session is established. The peers can then exchange PPP datagrams. MLPPP MLPPP establishes a session between two peers using the same protocols and phases as typical PPP. However, MLPPP adds: three option fields to the LCP frames an MLPPP header to the information field of the PPP frame LCP Options The receiving peer must know that the sending peer will be fragmenting PPP frames and transmitting them over multiple carrier lines. The receiving peer must also be able to recognize that these fragmented frames originate from a single peer. Three LCP options prepare peers to exchange PPP frames over an MLPPP connection: Maximum Receive Reconstructed Unit (MRRU) The MRRU option serves two functions: it indicates that the sending peer wants to, and that the receiving peer can, use MLPPP, and it specifies the size of the reconstructed frame (replacing the MRU). Short Sequence Number Header Format A peer can request to use a 12- bit rather than a 24-bit sequence number in the MLPPP header. A 12-bit sequence number enables a frame to be split into a little less than 5,000 fragments, which is more than adequate for the typical bundle of lines. 2-5

6 Configuring MLPPP Endpoint Discriminator (ED) options Peers negotiate how the receiving peer will identify the sending peer. One of these methods is an ED, which can be generated from an IP address, media access control (MAC) address, or PPP magic number. Every carrier line in the MLPPP bundle originates from the same endpoint and is given the same ED. The receiving peer recognizes that frames received from different carrier lines, but with the same ED, come from the same peer. MLPPP Header The MLPPP header helps the receiving peer reconstruct frame fragments in the correct order. When a peer sends a PPP frame across a multilink point-topoint connection, it first fragments the PPP frame. It then encapsulates fragments in new PPP frames and sends them simultaneously over each aggregated line. The new PPP frame includes: a new PPP header a four-field MLPPP header a fragment of the original PPP frame If peers agreed to use the short sequence number header format during the link establishment, the MLPPP header includes only two fields. The MLPPP header includes a flag and a sequence number. The sequence number indicates the fragment s place in the reconstructed PPP frame. MLPPP Configuration Concerns When you enable MLPPP for a connection, the LCP automatically negotiates the necessary options, such as the MRRU and ED. You simply need to bind the extra carrier lines to the PPP interface. MLPPP automatically adds the lines to the bundle. Carrier lines send keepalive signals. MLPPP automatically removes lines that go down from the bundle and adds lines that come back up. The PPP connection stays open as long as at least one line is good. Enabling MLPPP Identify the PPP interface for the connection whose bandwidth you want to increase. Move to the configuration mode context for this interface and enable multilink: ProCurve(config)# interface ppp 1 ProCurve(config-ppp 1)# ppp multilink 2-6

7 Binding Multiple Carrier Lines to a PPP Interface Increasing Bandwidth Configuring MLPPP On the ProCurve Secure Router, links are always defined by the Data Link Layer (for example, a PPP interface), rather than by the Physical Layer. You bind a physical interface to a logical interface to grant the Data Link Layer protocol access to the physical media over which to transmit data. This way of defining links makes configuring MLPPP easy: you simply bind more than one carrier line to the same PPP interface. You can bind as many carrier lines to the PPP interface as are installed on the router. The ProCurve Secure Router 7102dl provides up to 4 E1- or T1-carrier lines, and the ProCurve Secure Router 7203dl provides up to 12 E1- or T1- carrier lines, depending on the modules that you purchase. You should have already configured the physical interfaces. If you have not, see the Basic Management and Configuration Guide, Chapter 4: Configuring E1 and T1 Interfaces for instructions. To bind these interfaces to the PPP interface, you need the following information: type of carrier line (E1 or T1) dl module slot for the carrier line s module port number for the interface to which the line connects time division multiplexing (TDM) group number The TDM group number defines the range of channels used by an E1- or T1- carrier line. The carrier lines that will be aggregated can use the same or a different TDM group number, but these groups must use the same number of channels. You can enter the bind command either from the global or the PPP interface configuration mode contexts: Syntax: bind <bind number> [e1 t1] <slot>/<port> <tdm group number> ppp <interface number> Use a different bind number for each carrier line you want to bundle. For example, you might enter: ProCurve(config)# bind 1 e1 1/1 1 ppp 1 ProCurve(config)# bind 2 e1 1/2 1 ppp 1 ProCurve(config)# bind 3 e1 2/1 1 ppp 1 2-7

8 Configuring MLFR Configuring MLFR Like MLPPP, MLFR aggregates several physical connections into a single logical connection. MLFR helps provide greater access rates for PVCs, particularly in environments in which the greater bandwidth of an E3- or T3-carrier line is not available. MLFR also creates more stable PVCs: if one physical interface goes down, the other interfaces can continue to provide bandwidth for a connection. Routers that support MLFR FRF.15 bundle multiple carrier lines at the user s end. The service provider does not recognize the bundle. It assigns each line one Data Link Connection Identifier (DLCI) and carries traffic over the PVC for each line, just as it would for non-bundled lines. The remote router, which also runs MLFR FRF.15, receives the traffic from multiple PVCs but treats it as traffic from a single PVC. FRF.15 does not require the Frame Relay service provider to support MLFR. However, each bundle can support only one point-to-point connection to a remote site. The remote site must use the same number of carrier lines as the local site. The ProCurve Secure Router supports MLFR FRF.16 rather than FRF.15, which means that your service provider must support MLFR. FRF.16 provides several advantages over FRF.15. It allows a bundle to carry multiple PVCs to multiple remote sites, and these sites can use different amounts of bandwidth. FRF.16 aggregates multiple carrier lines to produce a high-speed connection to the Frame Relay service provider. The service provider supports MLFR, so it recognizes that these lines should be treated as a single bundle. The service provider assigns you a DLCI for the lines as a bundle instead of for each line individually. Rather than associating DLCI 101 with E1-carrier line 1 and DLCI 102 with E1-carrier line 2, the Frame Relay service provider associates DLCI 101 and 102 with both E1-carrier lines. (See Figure 2-3.) You can request DLCIs for PVCs to as many remote sites as your organization needs. In addition, the remote sites do not have to aggregate the same number of lines as the local site or even run MLFR at all. The multilink connection is to the Frame Relay provider, not to the remote sites. MLFR does not necessarily fragment frames. However, it can use FRF.12 to fragment large frames and minimize delay. An MLFR header is added to the original Frame Relay header to mark the fragments sequence numbers. 2-8

9 Configuring MLFR In essence, FRF.16 simply increases the committed information rate (CIR) you can negotiate for a Frame Relay port in a T1 or E1 environment. Router A E1 E1 MLFR bundle Frame Relay network Router B Router C DLCI 101 DLCI 102 Figure 2-3. MLFR FRF.16 Figure 2-3 shows a Frame Relay connection that aggregates two E1-carrier lines to connect to the Frame Relay provider. Router A establishes two PVCs one to Router B and one to Router C on this connection. You can aggregate as many carrier lines as are connected on the ProCurve Secure Router, as long as they are of equal bandwidth. The MLFR interface can carry as many PVCs as you request from your provider. Each PVC draws on the aggregated bandwidth as needed, as available, and in accordance with the CIR negotiated with the service provider. The endpoints of the PVC do not have to use the same number of carrier lines (although a great difference in bandwidth can lead to dropped packets). For example, Router A at the company headquarters can use four E1 lines, while Router C at a small remote site can connect to the network with only one line. Enabling MLFR Identify the Frame Relay interface for the connection whose bandwidth you want to increase. Then, move the configuration mode context for this interface and enable multilink. For example, you might enter: ProCurve(config)# interface frame-relay 1 ProCurve(config-fr 1)# frame-relay multilink 2-9

10 Configuring MLFR Binding Multiple Carrier Lines to a Frame Relay Interface On the ProCurve Secure Router, links are always defined by the Data Link Layer rather than the Physical Layer. You bind a physical interface to a logical interface to grant the Data Link Layer protocol access to the physical media over which to transmit data. This way of defining links makes configuring MLFR easy: you simply bind more than one carrier line to the same Frame Relay interface. You can bind as many lines to the Frame Relay interface as are installed on the router. The ProCurve Secure Router 7102dl provides up to 4 E1- or T1- carrier lines. The ProCurve Secure Router 7203dl provides up to 12 E1- or T1- carrier lines, depending on the modules that you purchase. You should have already configured the physical interfaces. If you have not, see the Basic Management and Configuration Guide, Chapter 4: Configuring E1 and T1 Interfaces for instructions. To bind the physical interfaces to the Frame Relay interface, you need this information: type of carrier line (E1 or T1) dl module slot for the carrier line s module port number for the interface to which the line connects TDM group number The TDM group number defines the range of channels used by an E1- or T1- carrier line. Lines that will be aggregated can use the same or a different TDM group number, but these lines must use the same number of channels. If you bind a physical interface to the Frame Relay interface and then enable multilink, the non-multilink binding is removed from the interface. You will have to rebind the original line as well as the new lines to the Frame Relay interface. You can enter the bind command either from the global or the Frame Relay interface configuration mode context. Enter the command for each carrier line that you want to bundle: Syntax: bind <bind number> [e1 t1] <slot>/<port> <tdm group number> frame-relay <interface number> Each physical interface should be bound to the Frame Relay interface with a unique bind number. For example, you might enter: ProCurve(config)# bind 1 e1 1/1 1 fr 1 ProCurve(config)# bind 2 e1 1/2 1 fr 1 ProCurve(config)# bind 3 e1 2/1 1 fr

11 Configuring MLFR Note You bind the physical interfaces to the Frame Relay interface, not the Frame Relay subinterface. This is because Frame Relay subinterfaces define PVCs, which are virtual connections, while the Frame Relay interface defines the physical connection available to all the virtual ones. Configuring the Bundle ID MLFR manages the connection by periodically sending out hellos across each carrier line included in the multilink connection. The hello includes the link ID of the line and the bundle ID of the connection as a whole. The link ID lets the router know which lines are up; the bundle ID lets the router know which lines are actually part of the same logical connection. By default, the Secure Router OS assigns this bundle ID to a Frame Relay multilink: MFR<interface number> For example, the router might assign the bundle ID: MFR1 You can configure a bundle ID for the connection. Move to the Frame Relay interface configuration mode context and enter: Syntax: frame-relay multilink bid <string> The bundle ID can be up to 48 characters. It is a good idea to configure the bundle ID at the same time as you enable multilink support: an active connection will go down briefly and then go back up while the new bundle ID is negotiated. 2-11

12 Troubleshooting Multilinks Troubleshooting Multilinks Troubleshooting multilinks is similar to troubleshooting a link carried on a single carrier line. You can review this process in Standard Procedure on page (For more troubleshooting tips, see the Basic Management and Configuration Guide, Chapter 6: Configuring the Data Link Layer Protocol for E1, T1, and Serial Interfaces.) Troubleshooting MLPPP on page 2-15 and Troubleshooting MLFR on page 2-16 deal with special considerations for troubleshooting multilinks. Note The show and debug commands that you use to troubleshoot are enable mode commands. You can also enter them from any context except basic by adding do to the beginning of the command. Standard Procedure When troubleshooting a multilink, follow the standard procedure for troubleshooting any PPP, Frame Relay, or Asymmetric Digital Subscriber Line (ADSL) connection: 1. Check the Physical Layer. 2. Check the Data Link Layer. Physical Layer Check the Stat LED for the module slot in which the line is installed. If the LED is green, the Physical Layer is up. If you cannot send data over the link, you will need to troubleshoot the Data Link Layer. If the LED is red, try changing the cable and checking the other hardware. (If the line is in a dual-module slot, you will need to use the show interfaces command to determine which is port down.) Next, check the configurations for the physical interface and make sure that they match those used by your public carrier. Data Link Layer Different problems arise depending on the protocol the connection uses. 2-12

13 Troubleshooting Multilinks PPP. Common PPP problems include: mismatched DS0 or E0 channels incorrect authentication information incompatible network-level protocols Use the debug commands shown in Table 2-1 to determine where the PPP session establishment ends. A good strategy can be to first view only the errors and then pinpoint the problem from there. Caution Messages resulting from debug ppp commands consume processing power and in a live network may compromise network functions. Table 2-1. PPP Debug Commands Command Syntax debug ppp verbose debug ppp negotiation debug ppp authentication debug ppp errors View all PPP debug messages PPP messages dealing with negotiation of the link PPP messages dealing with authentication errors and mismatches in negotiation and authentication You can also view the status of an interface by entering show interface ppp <interface number>. If the LCP state does not open, the E1-carrier or T1-carrier lines have probably been assigned an incorrect channel range. (This is properly a Physical Layer problem but often does not show itself until peers exchange LCP frames.) If you receive an authentication error and repeated Challenge Handshake Authenticate Protocol (CHAP) or Password Authentication Protocol (PAP) messages, you should check the router s authentication information. If you see NCP negotiation errors or if the LCP opens, but the PPP session does not, determine which network protocol the peer uses. You may be using incompatible protocols. For more information about troubleshooting PPP and PPP authentication, see the Basic Management and Configuration Guide, Chapter 6: Configuring the Data Link Layer Protocol for E1, T1, and Serial Interfaces. Frame Relay. Enter show frame-relay lmi to view the link management interface (LMI) statistics. 2-13

14 Troubleshooting Multilinks ProCurve# show frame-relay lmi LMI statistics for interface FR 1 LMI TYPE = ANSI Num Status Enq. Sent 24 Num Status Msgs Rcvd 7 Num Update Status Rcvd 1 Num Status Timeouts 3 Number of polls sent Number of polls received Figure 2-4. LMI Statistics for a Frame Relay Connection On a functioning Frame Relay connection, the polls sent and received should be approximately equal. The Frame Relay interface in Figure 2-4 has sent 17 polls without receiving a reply. Steadily increasing polls sent out without replies probably indicate: incompatible signaling type incorrect signaling role incorrect DLCI (also indicated by a deleted PVC) mismatched DS0 or E0 channels Table 2-2 gives the command syntax for displaying information about Frame Relay connections. Table 2-2. Frame Relay show Commands Command Syntax show interfaces frame-relay <interface number> show interfaces frame-relay <subinterface number> show frame-relay pvc show frame-relay lmi View Frame Relay port: signaling type interface type (UNI or NNI) Frame Relay subinterface: PVC status DLCI IP address PVC end-to-end: PVC status DLCI packets in and out DE packets FECN/BECN packets LMI statistics polls sent and received 2-14

15 Troubleshooting Multilinks View the Frame Relay interface and verify that its signaling type matches that of your service provider. You can enter show interface fr <subinterface number> to view a subinterface (the PVC endpoint) and check DLCIs and the PVC state. If the Frame Relay interface is down, you probably have a problem with the signaling type or role. If the Frame Relay interface is up but a PVC is inactive or deleted, you probably have a problem with the DLCI. Also check the TDM channels configured for the physical interface. Even though mismatched channels is a Physical Layer problem, it sometimes does not manifest itself until peers attempt to establish a link. For more information about troubleshooting Frame Relay, see the Basic Management and Configuration Guide, Chapter 6: Configuring the Data Link Layer Protocol for E1, T1, and Serial Interfaces. Troubleshooting MLPPP The most important consideration for troubleshooting MLPPP is determining whether the peer supports it. To determine this, view PPP debug messages: ProCurve# debug ppp negotiation As you examine the output, look for the following two fields in the negotiation events: MRRU ED MRRU An MRRU field automatically signals MLPPP support. In Figure 2-5, the router receives a message with an MRRU option, which indicates that the peer supports MLPPP. If the peer at the other end of the link rejects this option, the ProCurve Secure Router will terminate the link because it assumes its peer cannot support MLPPP. 2-15

16 Troubleshooting Multilinks :14:37 PPP.NEGOTIATION -->>>> : PPPrx[t1 1/1] LCP: Conf-Req ID=133 Len=29 ACCM( ) MAGIC(c0b82465) MRRU(1500) ED(3: c045b) PPPtx[t1 1/1] LCP: Conf-Ack ID=133 Len=29 ACCM( ) MAGIC(c0b82465) MRRU(1500) ED(3: c045b) PPPrx[t1 2/1] LCP: Conf-Req ID=11 Len=29 ACCM( ) MAGIC(c0b130b4) MRRU(1500) ED(3: c045b) PPPtx[t1 2/1] LCP: Conf-Ack ID=11 Len=29 ACCM( ) MAGIC(c0b130b4) MRRU(1500) ED(3: c045b) :14:37 PPP.NEGOTIATION t1 1/1: LCP up : Multilink support T1 1/1 and T1 2/1 are the same link :14:37 PPP.NEGOTIATION PPPFSM: layer up, Protocol=c021 : :14:37 PPP.NEGOTIATION t1 2/1: LCP up :14:37 PPP.NEGOTIATION Links bundled : :21:15 PPP.NEGOTIATION PPPFSM: layer up, Protocol= :21:15 PPP.NEGOTIATION IPCP up :21:16 INTERFACE_STATUS.ppp 1 changed state to up Figure 2-5. MLPPP Debug Messages ED Next, look for messages dealing with the ED option. The ED option identifies the device transmitting the packet and allows the receiving peer to recognize that frame fragments received on different carrier lines belong together. The ED should be the same for each line in the bundle. For example, in Figure 2-5 the ED for the T1 1/1 interface and the T1 2/1 interface are the same. Troubleshooting MLFR To view debug messages for MLFR, enter the following command from the enable mode context: ProCurve# debug frame-relay multilink MLFR periodically sends hellos to the remote endpoint. The local interface should receive a hello ACK in reply. The Frame Relay interface should send a hello for each carrier line. (See Figure 2-6.) If the interface is not sending hellos for one of the carrier lines, then that line is down. 2-16

17 Troubleshooting Multilinks ProCurve# debug frame-relay multilink :12:39 FRAME_RELAY.MULTILINK (I): msg=hello, Link=t1 1/ 2 1, Bundle=MFR1, BL state=up Message from service provider router Routers confirm a link is still active :12:39 FRAME_RELAY.MULTILINK (O): msg=hello_ack, Link=t1 1/2 1, Bundle=MFR1, BL state=up Message from local router :12:40 FRAME_RELAY.MULTILINK (O): msg=hello, Link=t1 1/ 2 1, Bundle=MFR1, BL state=up :12:40 FRAME_RELAY.MULTILINK (I): msg=hello_ack, Link=t1 1/2 1, Bundle=MFR1, BL state=up Figure 2-6. Frame Relay Multilink Hellos If the interface is continually sending requests to add a link instead of hellos, the endpoint probably does not support MLFR. It is also possible that carrier lines on either end of the link are configured for a different set of channels. (See Figure 2-7.) ProCurve# debug frame-relay multilink :11:54 FRAME_RELAY.MULTILINK (O): msg=add_link, Link=t1 1/1 1, Bundle=MFR1, BL state=add_sent :11:54 FRAME_RELAY.MULTILINK (O): msg=add_link, Link=t1 1/2 1, Bundle=MFR1, BL state=add_sent :11:54 FRAME_RELAY.MULTILINK (O): msg=add_link, Link=t1 1/1 1, Bundle=MFR1, BL state=add_sent :11:56 FRAME_RELAY.MULTILINK (O): msg=add_link, Link=t1 1/2 1, Bundle=MFR1, BL state=add_sent State remains ADD_SENT No messages from service provider router Figure 2-7. MLFR Link Does Not Go Up Figure 2-8 shows a carrier line that was successfully added to a bundle. 2-17

18 Troubleshooting Multilinks ProCurve# debug frame-relay multilink :11:54 FRAME_RELAY.MULTILINK (O): msg=add_link, Link=t1 1/2 1, Bundle=MFR1, BL state=add_sent Message from local router Routers exchange requests to add a carrier line to the bundle :11:54 FRAME_RELAY.MULTILINK (I): msg=add_link, Link=t1 1/2 1, Bundle=MFR1, BL state=add_sent Message from service provider router :11:54 FRAME_RELAY.MULTILINK (I): msg=add_link_ack, Link=t1 1/2 1, Bundle=MFR1, BL state=add_sent :11:56 FRAME_RELAY.MULTILINK (I): msg=add_link, Link=t1 1/2 1, Bundle=MFR1, BL state=add_rx :11:56 FRAME_RELAY.MULTILINK (O): msg=add_link_ack, Link=t1 1/2 1, Bundle=MFR1, BL state=add_rx Link ID Bundle ID at least one peer has confirmed the carrier line Figure 2-8. Successfully Adding a MLFR Link 2-18

19 Quick Start Quick Start This section provides the commands you must enter to quickly configure: Multilink PPP (MLPPP) Multilink Frame Relay (MLFR) Only a minimal explanation is provided. If you need additional information about any of these options, check Contents on page 2-1 to locate the section that contains the explanation you need. You may want to print out and complete Table 2-3 to use while you configure your router. Table 2-3. Quick Start Configuration Worksheet Line Parameter Your Setting new physical line 1 slot port new physical line 2 slot port new physical line 3 slot port existing line TDM group number channels logical interface type logical interface number IP address (logical interface) 2-19

20 Quick Start MLPPP Configuration Before you begin completing these instruction, you should connect the physical interfaces to the appropriate public carrier equipment. You should also have a non-multilink PPP connection up and running. 1. Move to the global configuration mode context and configure the physical interface(s) for the new carrier line(s): a. Move to the interface configuration mode context: Syntax: interface [e1 t1] <slot>/<port> b. TDM group numbers are significant for the interface only, so you can use the same TDM group number as the original line. You must use the same number of channels: Syntax: tdm-group <tdm group number> timeslots <channels> For example, you might enter: ProCurve(config-e1 1/2)# tdm-group 1 timeslots 1-31 c. Activate the interface: ProCurve(config-e1 1/2)# no shutdown d. Repeat these steps for each new carrier line. 2. Move to the PPP interface for the connection: Syntax: interface ppp <interface number> 3. Enable multilink functions: ProCurve(config-ppp 1)# ppp multilink 4. Bind each new physical interface to the PPP interface: Syntax: bind <bind number> [e1 t1] <slot>/<port> <tdm group number> ppp <interface number> Use a different bind number for each physical interface. For example, you might enter: ProCurve(config-ppp 1)# bind 2 e1 1/2 1 ppp 1 ProCurve(config-ppp 1)# bind 3 e1 2/1 1 ppp

21 Quick Start If you do not already have a PPP connection running, you must also: 5. Assign the PPP interface an IP address: Syntax: ip address [<A.B.C.D> <subnet mask /prefix length> negotiated] For example, you might enter: ProCurve(config-ppp 1)# ip address /30 You can also have the interface take its address from the far end of the link (negotiated). A PPP interface can take a dynamic address from a DHCP server only when it is acting as a bridge. The interface can also take its address from another router interface, such as the Ethernet interface: Syntax: ip unnumbered <interface ID> 6. Activate the PPP interface: ProCurve(config-ppp 1)# no shutdown MLFR Configuration Before you begin completing these instruction, you should connect the physical interfaces to the appropriate public carrier equipment. You should also have a non-multilink Frame Relay connection up and running. 1. Move to the global configuration mode context and configure the physical interface(s) for the new carrier line(s): a. Move to the interface configuration mode context: Syntax: interface [e1 t1] <slot>/<port> b. Configure the TDM group. You can use the same TDM group as the original line. You must use the same number of channels: Syntax: tdm-group <tdm group number> timeslots <channels> c. Activate the interface: Syntax: no shutdown d. Repeat these steps for each new carrier line. 2. Move to the Frame Relay interface for the connection: Syntax: interface frame-relay <interface number> 3. Enable multilink functions: ProCurve(config-fr 1)# frame-relay multilink 2-21

22 Quick Start 4. Enabling multilink unbinds physical lines from the interface. As well as binding each new physical interface to the Frame Relay interface, you must rebind the original line: Syntax: bind <bind number> [e1 t1] <slot>/<port> <tdm group number> framerelay <interface number> Use a different bind number for each physical interface. For example, you might enter: ProCurve(config-fr 1)# bind 1 t1 1/1 1 fr 1 ProCurve(config-fr 1)# bind 2 t1 2/1 1 fr 1 5. Assign the Frame Relay interface a bundle ID: Syntax: frame-relay multilink bid <string> If you do not already have a Frame Relay connection running, you must also: 6. Activate the Frame Relay interface: ProCurve(config-fr 1)# no shutdown 7. Add at least one PVC by configuring a Frame Relay subinterface: ProCurve(config-fr 1)# interface frame-relay Enter the DLCI for the PVC: Syntax: frame-relay interface-dlci <DLCI> 9. Assign the Frame Relay subinterface an IP address: Syntax: ip address [dhcp <A.B.C.D> <subnet mask /prefix length>] For example, you might enter: ProCurve(config-fr 1.101)# ip address /30 The Frame Relay subinterface can also act as a DHCP client and take a dynamic address from a connecting server. Use the dhcp option. The interface can also take an address from another router interface, such as an Ethernet interface: Syntax: ip unnumbered <interface ID> You might also need to change the signaling type and role for the Frame Relay interface. For more information about configuring Frame Relay, see the Basic Management and Configuration Guide, Chapter 6: Configuring the Data Link Layer Protocol for E1, T1, and Serial Interfaces. 2-22