sr7000dl advanced management config guide - increasing

2

Increasing Bandwidth

Contents

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Configuring MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

LCP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

MLPPP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

MLPPP Configuration Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

Enabling MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

Binding Multiple Carrier Lines to a PPP Interface . . . . . . . . . . . . . . . . 2-7

Configuring MLFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8

Enabling MLFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

Binding Multiple Carrier Lines to a Frame Relay Interface . . . . . . . . 2-10

Configuring the Bundle ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11

Troubleshooting Multilinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12

Standard Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12

Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12

Data Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12

Troubleshooting MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15

MRRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15

ED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16

Troubleshooting MLFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16

Quick Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19

MLPPP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20

MLFR Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21

2-1

Increasing BandwidthOverview

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 limita-tions 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 avail-able 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 1.544-Mbps T1-carrier lines into a virtual single network con-nection with an underlying bandwidth of 3.088 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 reassem-bled by the receiving peer. (See Figure 2-1.)

2-2

Increasing BandwidthOverview

Figure 2-1. MLPPP, a Link Aggregation Protocol

PPP Frame E1 Line

Router

PPP Frame

a b c

d fFrame fragments

PPP Frame

Frag a

Frag d

Frag cRouter

MLPPP

PPP

E1 Lines

e

2-3

Increasing BandwidthConfiguring 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.)

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 authentica-tion, they proceed to the next stage.) After both peers authenticate themselves successfully, they proceed to the next stage.

1. Link establishmentLCP

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

ProCurve Secure Router

2-4


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 recon-structed 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


■ 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-to-point 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 connec-tion 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 1ProCurve(config-ppp 1)# ppp multilink

2-6


Binding Multiple Carrier Lines to a PPP Interface

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: Configur-

ing 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 1ProCurve(config)# bind 2 e1 1/2 1 ppp 1ProCurve(config)# bind 3 e1 2/1 1 ppp 1

2-7

Increasing BandwidthConfiguring MLFR

Configuring MLFR

Like MLPPP, MLFR aggregates several physical connections into a single logical connection. MLFR helps provide greater access rates for PVCs, partic-ularly 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


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.

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 1ProCurve(config-fr 1)# frame-relay multilink

E1

E1

Router A Frame Relay network

Router B

Router C

MLFR bundle

DLCI 101DLCI 102

2-9


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: Configur-

ing 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 1ProCurve(config)# bind 2 e1 1/2 1 fr 1ProCurve(config)# bind 3 e1 2/1 1 fr 1

2-10


N o t e 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 connec-tion will go down briefly and then go back up while the new bundle ID is negotiated.

2-11

Increasing BandwidthTroubleshooting 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 2-12. (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.

N o t e 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 trouble-shooting 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


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.

C a u t i o n Messages resulting from debug ppp commands consume processing power and in a live network may compromise network functions.

Table 2-1. PPP Debug Commands

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.

Command Syntax View

debug ppp verbose all PPP debug messages

debug ppp negotiation PPP messages dealing with negotiation of the link

debug ppp authentication PPP messages dealing with authentication

debug ppp errors errors and mismatches in negotiation and authentication

2-13


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 View

show interfaces frame-relay <interface number> Frame Relay port:• signaling type• interface type (UNI or NNI)

show interfaces frame-relay <subinterface number> Frame Relay subinterface:• PVC status• DLCI• IP address

show frame-relay pvc PVC end-to-end:• PVC status• DLCI• packets in and out• DE packets• FECN/BECN packets

show frame-relay lmi LMI statistics—polls sent and received

ProCurve# show frame-relay lmiLMI statistics for interface FR 1 LMI TYPE = ANSI

Num Status Enq. Sent 24 Num Status Msgs Rcvd 7Num Update Status Rcvd 1 Num Status Timeouts 3

Number of polls received

Number of polls sent

2-14


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


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.

2004.07.26 02:14:37 PPP.NEGOTIATION —-->>>>:

PPPrx[t1 1/1] LCP: Conf-Req ID=133 Len=29 ACCM(00000000) MAGIC(c0b82465) MRRU(1500) ED(3:0000000c045b) PPPtx[t1 1/1] LCP: Conf-Ack ID=133 Len=29 ACCM(00000000) MAGIC(c0b82465) MRRU(1500) ED(3:0000000c045b)PPPrx[t1 2/1] LCP: Conf-Req ID=11 Len=29 ACCM(00000000) MAGIC(c0b130b4) MRRU(1500) ED(3:0000000c045b)PPPtx[t1 2/1] LCP: Conf-Ack ID=11 Len=29 ACCM(00000000) MAGIC(c0b130b4) MRRU(1500) ED(3:0000000c045b) 2004.07.26 02:14:37 PPP.NEGOTIATION t1 1/1: LCP up

:2004.05.26 02:14:37 PPP.NEGOTIATION PPPFSM: layer up, Protocol=c021

:2004.07.26 02:14:37 PPP.NEGOTIATION t1 2/1: LCP up2004.07.26 02:14:37 PPP.NEGOTIATION Links bundled

:2004.07.26 02:21:15 PPP.NEGOTIATION PPPFSM: layer up, Protocol=80212004.07.26 02:21:15 PPP.NEGOTIATION IPCP up2004.07.26 02:21:16 INTERFACE_STATUS.ppp 1 changed state to up

Multilink support

T1 1/1 and T1 2/1 are the same link

2-16


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.)

Figure 2-7. MLFR Link Does Not Go Up

Figure 2-8 shows a carrier line that was successfully added to a bundle.

ProCurve# debug frame-relay multilink2005.07.12 12:12:39 FRAME_RELAY.MULTILINK (I): msg=HELLO, Link=t1 1/2 1, Bundle=MFR1, BL state=UP

2005.07.12 12:12:39 FRAME_RELAY.MULTILINK (O): msg=HELLO_ACK, Link=t1 1/2 1, Bundle=MFR1, BL state=UP

2005.07.12 12:12:40 FRAME_RELAY.MULTILINK (O): msg=HELLO, Link=t1 1/2 1, Bundle=MFR1, BL state=UP2005.07.12 12:12:40 FRAME_RELAY.MULTILINK (I): msg=HELLO_ACK, Link=t1 1/2 1, Bundle=MFR1, BL state=UP

Routers confirm a link is still active.

Message from service provider router

Message from local router

ProCurve# debug frame-relay multilink2005.07.12 12:11:54 FRAME_RELAY.MULTILINK (O): msg=ADD_LINK, Link=t1 1/1 1, Bundle=MFR1, BL state=ADD_SENT2005.07.12 12:11:54 FRAME_RELAY.MULTILINK (O): msg=ADD_LINK, Link=t1 1/2 1, Bundle=MFR1, BL state=ADD_SENT2005.07.12 12:11:54 FRAME_RELAY.MULTILINK (O): msg=ADD_LINK, Link=t1 1/1 1, Bundle=MFR1, BL state=ADD_SENT2005.07.12 12: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

2-17


Figure 2-8. Successfully Adding a MLFR Link

ProCurve# debug frame-relay multilink2005.07.12 12:11:54 FRAME_RELAY.MULTILINK (O): msg=ADD_LINK, Link=t1 1/2 1, Bundle=MFR1, BL state=ADD_SENT

2005.07.12 12:11:54 FRAME_RELAY.MULTILINK (I): msg=ADD_LINK, Link=t1 1/2 1, Bundle=MFR1, BL state=ADD_SENT

2005.07.12 12:11:54 FRAME_RELAY.MULTILINK (I): msg=ADD_LINK_ACK, Link=t1 1/2 1, Bundle=MFR1, BL state=ADD_SENT2005.07.12 12:11:56 FRAME_RELAY.MULTILINK (I): msg=ADD_LINK, Link=t1 1/2 1, Bundle=MFR1, BL state=ADD_RX2005.07.12 12:11:56 FRAME_RELAY.MULTILINK (O): msg=ADD_LINK_ACK, Link=t1 1/2 1, Bundle=MFR1, BL state=ADD_RX

Routers exchange requests to add a carrier line to the bundle

Link ID Bundle ID at least one peer has confirmed the carrier line

Message from local router

Message from service provider router

2-18

Increasing BandwidthQuick 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


port


port

existing line TDM group number

channels

logical interface type

logical interface number

IP address (logical interface)

2-19


MLPPP Configuration

Before you begin completing these instruction, you should connect the phys-ical 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-31c. Activate the interface:

ProCurve(config-e1 1/2)# no shutdownd. 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 1ProCurve(config-ppp 1)# bind 3 e1 2/1 1 ppp 1

2-20


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]


ProCurve(config-ppp 1)# ip address 10.1.1.1 /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 phys-ical 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 shutdownd. 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


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> frame-relay <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 1ProCurve(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 1.101

8. 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>]


ProCurve(config-fr 1.101)# ip address 10.2.2.1 /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

sr7000dl advanced management config guide - increasing

Documents