Frame Relay Protocols

Frame Relay provides delivery of variable-sized data frames to multiple WAN-connected sites. Other than point-to-point links, Frame Relay is the WAN protocol most typically seen by CCNAs. This section reviews the details of how Frame Relay accomplishes its goal of delivery of frames to multiple WAN-connected sites.

Frame Relay is a well-chosen name for reminding you that it most closely relates to OSI Layer 2. The term frame is generally associated with a collection of data bits that includes an OSI Layer 2 equivalent header. For example, an Ethernet frame includes the Ethernet header/ trailer. Frame Relay uses addresses, but that addressing does not attempt to create a logical address structure that could be used over a variety of media; therefore, Frame Relay addressing is closer to OSI Layer 2 addressing standards and is considered to be a Layer 2 protocol. (Refer to Chapter 3 for a review of OSI layers.)

The remainder of this section summarizes the Frame Relay protocol details expected to be on the exam.

Frame Relay Features and Terminology

Frame Relay is a multiaccess network, which actually means that more than two devices can attach to the medium. Multiaccess is the first and most obvious difference between Frame Relay and leased lines. However, leased lines are used as the access link component of Frame Relay networks. Consider Figure 8-4, which is a valuable resource for reviewing Frame Relay concepts.

Figure 8-4 Frame Relay Components

Figure 8-4 Frame Relay Components

The access link between the router and the Frame Relay switch is a leased line. Both sites represented in Figure 8-4 are connected to some nearby switch via a leased line. The service provider interconnects their switches to provide connectivity.

Table 8-9 lists the components in Figure 8-4 and some associated terms.

Table 8-9 Frame Relay Terms and Concepts

Table 8-9 lists the components in Figure 8-4 and some associated terms.

Table 8-9 Frame Relay Terms and Concepts

Virtual circuit (VC)

A VC is a logical concept that represents the path that frames travel

between DTEs. VCs are particularly useful when comparing Frame

Relay to leased physical circuits.

Permanent virtual circuit (PVC)

A PVC is a VC that is predefined. A PVC can be equated to a

leased line in concept.

Switched virtual circuit (SVC)

An SVC is a VC that is set up dynamically. An SVC can be equated

to a dial connection in concept.

Table B-9 Frame Relay Terms and Concepts (Continued)

Data terminal equipment (DTE)

DTEs are also known as data-circuit termination equipment. For

example, routers are DTEs when connected to a Frame Relay

service from a telecommunication company.

Data communications equipment

Frame Relay switches are DCE devices.

(DCE)

Access link

The access link is the leased line between DTE and DCE.

Access rate (AR)

The access rate is the speed at which the access link is clocked.

This choice affects the price of the connection.

Committed information rate

The CIR is the rate at which the DTE can send data for an

(CIR)

individual VC, for which the provider commits to deliver that

amount of data. The provider will send any data in excess of this

rate for this VC if its network has capacity at the time. This choice

typically affects the price of each VC.

Burst rate

The burst rate is the rate and length of time for which, for a

particular VC, the DTE can send faster than the CIR, and the

provider agrees to forward the data. This choice typically affects

the price of each VC.

Data link connection identifier

A DLCI is a Frame Relay address and is used in Frame Relay

(DLCI)

headers to identify the virtual circuit.

Forward explicit congestion

The FECN is the bit in the Frame Relay header that signals to

notification (FECN)

anyone receiving the frame (switches and DTEs) that congestion is

occurring in the same direction as the frame. Switches and DTEs

can react by slowing the rate by which data is sent in that direction.

Backward explicit congestion

The BECN is the bit in the Frame Relay header that signals to

notification (BECN)

anyone receiving the frame (switches and DTEs) that congestion is

occurring in the opposite (backward) direction as the frame.

Switches and DTEs can react by slowing the rate by which data is

sent in that direction.

Discard eligibility (DE)

The DE is the bit in the Frame Relay header that signals to a switch

to, if frames must be discarded, please choose this frame to discard

instead of another frame without the DE bit set.

Nonbroadcast multiaccess

NBMA refers to a network in which broadcasts are not supported,

(NBMA)

but more than two devices can be connected.

Local Management Interface

LMI is the protocol used between a DCE and DTE to manage the

(LMI)

connection. Signaling messages for SVCs, PVC status messages,

and keepalives are all LMI messages.

Link access procedure—frame

LAPF is the basic Frame Relay header and trailer; it includes

mode bearer services (LAPF)

DLCI, FECN, BECN, and DE bits.

The definitions for Frame Relay are contained in documents from the ITU and from ANSI. The Frame Relay Forum, a vendor consortium, also defines several Frame Relay specifications, many of which have been added to the standards body's documents. Table 8-10 lists the most important of these specifications.

Table 8-10 Frame Relay Protocol Specifications

What the Specification Defines

ITU Document

ANSI Document

Data link specifications, including LAPF header/trailer

Q.922 Annex A

T1.618

PVC management, LMI

Q.933 Annex A

T1.617 Annex D

SVC signaling

Q.933

T1.617

Multiprotocol encapsulation (originated in RFC 1490/2427)

Q.933 Annex E

T1.617 Annex F

LMI and Encapsulation Types

When first learning about Frame Relay, it's often easy to confuse the LMI and encapsulation used with Frame Relay; Cisco expects CCNAs to master the differences. The LMI is a definition of the messages used between the DTE (for example, a router) and the DCE (for example, the Frame Relay switch owned by the service provider). The encapsulation defines the headers used, in addition to the basic Frame Relay header, for transporting the frame from DTE to DTE. The switch and its connected router care about using the same LMI; the switch does not care about the encapsulation.

The three LMI protocols available in the IOS are defined by Cisco, the ITU, and ANSI, and each is slightly different and therefore not compatible with the other two. For instance, the Cisco and ANSI Q.933-A LMIs call for use of DLCI 1023 for LMI messages, whereas T1.617-D calls for DLCI 0. Some of the messages have different fields in their information elements. The DTE simply needs to know which of the two (DLCI 1023 or DLCI 0) to use; it must match the one used by the switch.

Using the same LMI type on a DTE and its connected DCE is required. LMI autosense is supported by the IOS in version 11.2, so there is no need to code the LMI type. If desired, the LMI type can be configured, but this disables the autosense feature. One LMI type exists per serial interface because the LMI controls the single physical access link, which is connected to a single switch.

The most important LMI message relating to topics on the exam is the LMI status enquiry message, which signals whether a PVC is up or down. Even though each PVC is predefined, its status can change. As with all LMI messages, status enquiry messages flow between the switch (DCE) and the DTE. For instance, a routing protocol reacts when a PVC is down, signaling that routes over that PVC are lost.

Table 8-11 outlines the three LMI types, their origin, and the keyword used in the Cisco frame-relay lmi-type interface subcommand.

Table 8-11 Frame Relay LMI Types

Name Document IOS LMI-Type Parameter

Table 8-11 outlines the three LMI types, their origin, and the keyword used in the Cisco frame-relay lmi-type interface subcommand.

Table 8-11 Frame Relay LMI Types

Name Document IOS LMI-Type Parameter

Cisco

Proprietary

cisco

ANSI

T1.617 Annex D

ansi

ITU Q.933 Annex A q933a

ITU Q.933 Annex A q933a

As with other data link protocols, Frame Relay defines a header and a trailer, with fields in each that allow the switches and DTEs to successfully deliver the frame across the network. Encapsulation refers to the process of using such headers and trailers to contain data supplied by a higher layer. (Refer to Chapter 3 for additional concepts about encapsulation.)

Frame Relay uses a link access procedure—frame bearer services (LAPF) header, defined by Q.922-A. The sparse LAPF framing provides error detection with an FCS in the trailer, as well as the DLCI, DE, FECN, and BECN fields. Figure 8-5 diagrams the frame.

Figure 8-5 LAPF Header

LAPF header

Information

LAPF trailer t_

FECN, BECN, DE (1 bit each) DLCI (Usually 10 bits)

Figure 8-5 does not show the presence of a Protocol Type field. As discussed in Chapter 3, a field in the header must define the type of header that begins the Information field. If Frame Relay is using only the LAPF header, then DTEs (including routers) cannot support multiprotocol traffic because there is no way to identify the type of protocol in the Information field. (For more information about the concept of a Protocol Type field in data link headers, refer to Chapter 3.)

Two solutions were created to compensate for the lack of a Protocol Type field. Cisco and three other companies created an additional header, which comes first in the Information field shown in Figure 8-5. It includes a 2-byte-long Protocol Type field, with values matching the same field used for HDLC by Cisco. The second solution was defined in RFC 1490, "Multiprotocol Interconnect over Frame Relay," which was written to ensure multivendor interoperability between Frame Relay DTEs. This solution includes use of a Protocol Type field and adds many options, including support for bridged frames. ITU and ANSI later incorporated RFC 1490 headers into specs Q.933 Annex E and T.617 Annex F, respectively.

NOTE RFC 1490 has been superceded by RFC 2427. You probably will want to remember both numbers, particularly the older 1490 because it is referred to often in documentation from Cisco and other vendors.

Figure 8-6 provides a conceptual diagram of the two forms of encapsulation. Because the frames flow from DTE to DTE, both DTEs must agree to the encapsulation used. However, each VC can use a different encapsulation.

Figure 8-6 Cisco and RFC 1490/2427 Encapsulations

Includes DLCI

LAPF header

CISCO

Packet

LAPF trailer

LAPF header

RFC 1490

Packet

LAPF trailer

Later added to Q.933-E and T1.617-F; includes Protocol Type Field

DLCI Addressing and Frame Relay Switching

The data link connection identifier (DLCI) is the Frame Relay address. DLCIs, not DTEs, are used to address virtual circuits. The logic and use of these addresses is very different from the addresses seen for other protocols covered in this book. This difference is mainly due to the use of the DLCI and the fact that there is a single DLCI field in the header—there is not a source and destination DLCI.

DLCIs are used to address the virtual circuit (VC); the logic behind the way routers use DLCI values is subtle. For example, in Figure 8-7, Router A has a VC to both Router B and Router C; Router A will need to use a different DLCI for each VC. The Frame Relay switches swap the DLCI in transit. For example, Router A sends a frame with DLCI 41, expecting that it will be delivered to Router B. Likewise, Router A sends frames with DLCI 42 when it wants the frame to be delivered to Router C.

Figure 8-7 Frame Relay Addressing

Frame Relay DLCIs are locally significant; this means that the addresses need to be unique only on the local access link. A popular analogy that explains local addressing is that there can be only a single street address of 2000 Pennsylvania Avenue, Washington, D.C., but there can be a 2000 Pennsylvania Avenue in every town in the United States. Likewise, DLCIs must be unique on each access link.

In Figure 8-7, as frames traverse Router A's access link, they have either DLCI 41 or 42 in the header, which meets the requirement that the addresses be unique on that access link. Likewise, for all VCs terminating at Router B, unique DLCI values must be used for each one. Because there is only one VC to Router B in Figure 8-7, there is no possibility of an overlap.

DLCIs are usually changed as the frames traverse the Frame Relay network. Consider the revised network of Figure 8-8, in which DLCI 41 and 42 are still used by Router A on the access link. Before the frames are forwarded on the access links to Router B and Router C, the Frame Relay switches convert the DLCI to a value of 40 in each case. The DLCI values are chosen by the service provider; the only requirement of local addressing can be summarized as follows:

DLCIs must be unique on each access link.The DLCI used to identify an individual

VC on one access link has no bearing on the value that is chosen to identify the VC

on the access link at the other end of the VC.

Figure 8-8 Frame Relay Local Addressing, with Different DLCIs on Each End

Figure 8-8 Frame Relay Local Addressing, with Different DLCIs on Each End

With the convention shown in Figure 8-8, the DLCI values are different on each end of the VC. However, the values shown in Figure 8-7 are also valid. In practice, the style shown in Figure 8-8 is the typical choice, but it seems to be a bit more confusing. But why? The answer lies in a term called global addressing

The concept of global addressing is the reason that typical Frame Relay networks use a different DLCI value on each end of the VC. Global addressing allows you to think of the Frame Relay network like a LAN in terms of addressing concepts. Consider Figure 8-9, with the DLCI values shown. In this figure, think of the DLCI values as an address for the DTE, which is similar to how a unicast MAC address represents a LAN card.

On a LAN, if Host B wants to send a frame to Host A, Host B sends a frame with Host A's MAC address as the destination. Similarly, if Router B wants to send a frame to Router A, then Router B (by the convention of global addressing) sends a frame with Router A's global DLCI value in the header. Likewise, Router C sends frames with DLCI 40 to reach Router A, by convention. Router A sends frames with DLCI 41 to reach Router B, and with DLCI 42 to reach Router C, again, by the convention of global addressing. Figure 8-9 shows the DLCIs used for global addressing and the actual values placed into the Frame Relay headers for correct delivery across the network. Table 8-12 summarizes the DLCIs used in the figure.

Figure 8-9 Frame Relay Global Addressing Convention, with Reality of Local Addressing

Figure 8-9 Frame Relay Global Addressing Convention, with Reality of Local Addressing

Che Carpe Montage Ligne
Table 8-12 DLCI Swapping in Frame Relay Cloud

Frame Sent by Router . . .

With DLCI Field

Is Delivered to Router . . .

With DLCI Field

A

41

B

40

A

42

C

40

B

40

A

41

C

40

A

42

Figure 8-9 shows a frame being sent from Router A to Router B in one case, and to Router C in the other case. As Router A sends a frame with DLCI 41, the Frame Relay switches send the frame toward Router B. Before being sent on the access link to Router B, the final switch changes the DLCI to 40 so that Router B knows who sent the frame. Similarly, Router A sends a frame with DLCI 42, and it is received by Router C with DLCI 40.

In fact, the DLCIs used match the sample network with local addressing of Figure 8-8. In essence:

• Local addressing is how Frame Relay addressing works. However, by following the convention of global addressing, planning is easier because the addressing appears similar to LAN addressing.

• A global address for one DTE simply means that all other DTEs with a VC to this one DTE use its global address on their local access links.

One particularly convenient benefit of global addressing is that new sites can be added with more convenience. Examine Figure 8-10, with Routers D and E added. The service provider simply states that global DLCI 43 and 44 will be used for these two routers. If these two routers also have only one PVC to Router A, all the DLCI planning is complete. You know that Router D and Router E will use DLCI 40 to reach Router A, and that Router A will use DLCI 43 to reach Router D and DLCI 44 to reach Router E.

Figure 8-10 Adding Frame Relay Sites: Global Addressing

Figure 8-10 Adding Frame Relay Sites: Global Addressing

The remaining samples in this chapter use global addressing in any planning diagrams, unless otherwise stated. One practical way to determine whether the diagram lists the local DLCIs or the global DLCI convention is this: If two VCs terminate at a DTE and a single DLCI is shown, then it probably represents the global DLCI convention. If one DLCI is shown per VC, then it is depicting local DLCI addressing.

Network Layer Concerns with Frame Relay

As a CCNA, you will need to concern yourself with three key issues relating to Layer 3 flows over Frame Relay:

• Choices for Layer 3 addresses on Frame Relay interfaces

• Broadcast handling

• Split horizon

The sections that follow cover these issues in depth.

Layer 3 Addressing

This section examines three cases of Layer 3 addressing when using Frame Relay. Figure 8-11 starts the first case with an illustration of a fully meshed Frame Relay network. In a full mesh, each router has a direct connection to every other router, allowing the Frame Relay cloud to be treated as one Layer 3 network. Figure 8-11 also shows IPX and IP addresses. The IPX and IP addresses would be configured as subcommands on the serial interface. Table 8-13 summarizes the addresses used in Figure 8-11.

Figure 8-11 Full Mesh with IP and IPX Addresses

Figure 8-11 Full Mesh with IP and IPX Addresses

Table 8-13 IP and IPX Addresses, with No Subinterfaces

IP Address of IPX Network of

Frame Relay Frame Relay

Router Interface Interface IPX Address

Mayberry 199.1.1.1 199 199.0200.aaaa.aaaa

Mount Pilot 199.1.1.2 199 199.0200.bbbb.bbbb

Raleigh 199.1.1.3 199 199.0200.cccc.cccc

The second case is a partially meshed Frame Relay network (see Figure 8-12). Because all four routers do not have VCs to each other, each VC uses a different set of Layer 3 groups. Table 8-14 shows the IPX and IP addresses for the partially meshed Frame Relay network illustrated in Figure 8-12. The addresses would be configured as subcommands on the serial interface. (Note: The notation /24 signifies a subnet mask with 24 binary 1s—in other words, 255.255.255.0.)

Figure 8-12 Partial Mesh with IP and IPX Addresses

Figure 8-12 Partial Mesh with IP and IPX Addresses

Table 8-14 IP and IPX Addresses, with Point-to-Point Subinterfaces

Router

Subnet

IP Address

IPX Network

IPX Address

Atlanta

140.1.1.0/24

140.1.1.1

1

1.0200.aaaa.aaaa

Charlotte

140.1.1.0/24

140.1.1.2

1

1.0200.bbbb.bbbb

Atlanta

140.1.2.0/24

140.1.2.1

2

2.0200.aaaa.aaaa

Nashville

140.1.2.0/24

140.1.2.3

2

2.0200.cccc.cccc

Atlanta

140.1.3.0/24

140.1.3.1

3

3.0200.aaaa.aaaa

Boston

140.1.3.0/24

140.1.3.4

3

3.0200.dddd.dddd

Subinterfaces allow the Atlanta router to have three IP addresses and three IPX addresses associated with its serial 0 interface. Subinterfaces can treat each VC as though it were a point-to-point serial link. Each of the three subinterfaces of serial 0 on Atlanta would be assigned a different IP address and IPX address from the list in Table 8-14. Example configurations follow in the next section of this chapter.

The third case of Layer 3 addressing is a hybrid between the first two illustrated in Figure 8-11 and Figure 8-12. Consider Figure 8-13, which shows a trio of routers with VCs between each of them, as well as two other VCs to remote sites.

Figure 8-13 Hybrid of Full and Partial Mesh

DLCI 501

Figure 8-13 Hybrid of Full and Partial Mesh

DLCI 501

Two options exist for Layer 3 addressing in this case. The first is to treat each VC as a separate Layer 3 group; five subnets and five IPX networks would be needed for the Frame Relay network. However, if Routers A, B, and C are considered alone, they meet the criteria that each can send packets directly to each other, like a full mesh. This would allow Routers A, B, and C to use one subnet and IPX network. The other two VCs—between A and D, and between A and E—are treated as two separate Layer 3 groups. The result is a total of three subnets and three IPX network numbers.

To accomplish either style of Layer 3 addressing in this third and final case, subinterfaces are used. Point-to-point subinterfaces are used when a single VC is considered to be all that is in the group. Multipoint subinterfaces are used among Routers A, B, and C in Figure 8-13. The section "Frame Relay Configuration," later in the chapter, provides full configurations for all three cases illustrated in Figure 8-11, Figure 8-12, and Figure 8-13. Table 8-15 summarizes the addresses and subinterfaces used.

Table 8-15 IP and IPX Addresses, and Point-to-Point and Multipoint Subinterfaces

Router

Subnet

IP Address

Network

IPX Address

Subinterface Type

A

140.1.1.0/24

140.1.1.1

1

1.0200.aaaa.aaaa

Multipoint

B

140.1.1.0/24

140.1.1.2

1

1.0200.bbbb.bbbb

Multipoint

C

140.1.1.0/24

140.1.1.3

1

1.0200.cccc.cccc

Multipoint

A

140.1.2.0/24

140.1.2.1

2

2.0200.aaaa.aaaa

Point-to-point

D

140.1.2.0/24

140.1.2.4

2

2.0200.dddd.dddd

Point-to-point

A

140.1.3.0/24

140.1.3.1

3

3.0200.aaaa.aaaa

Point-to-point

E

140.1.3.0/24

140.1.3.5

3

3.0200.eeee.eeee

Point-to-point

Broadcast Handling

Broadcasts are not supported over a Frame Relay network. In other words, no capability exists for a DTE to send a frame that is replicated and delivered across more than one VC. However, routers need to send broadcasts for several features to work. In particular, routing protocol updates and SAP updates are broadcasts.

The solution to the broadcast dilemma for Frame Relay has two parts. First, the IOS sends copies of the broadcasts across each VC that you instruct it to. Of course, if there are only a few VCs, this is not a big problem. However, if hundreds of VCs terminate in one router, then for each broadcast, hundreds of copies could be sent. The IOS can be configured to limit the amount of bandwidth that is used for these replicated broadcasts.

As the second part of the solution, the router tries to minimize the impact of the first part of the solution. The router places these broadcasts into a different queue than user traffic so that the user does not experience a large spike in delay each time some broadcast is replicated and sent over each VC.

NOTE Although the CCNP exam, not the CCNA exam, covers such issues about dealing with overhead, a short example can show the significance of this overhead. For example, if a router knows 1000 routes, uses RIP, and has 50 VCs, then 1.072MB of RIP updates are sent every 30 seconds. That averages to 285kbps. (Math: 536-byte RIP packets, with 25 routes in each packet, for 40 packets per update, with copies sent over 50 VCs: 536 x 40 x 50 = 1.072 megabytes per update interval. 1.072 x 8 / 30 seconds = 285kbps).

Knowing how to tell the router to forward these broadcasts out to each VC will be important on the CCNA exam and is covered in the "Frame Relay Configuration" section later in this chapter. The issues that relate to dealing with the volume of these updates is more likely a topic for the CCNP and CCIE exams.

Split Horizon

Split horizon is useful for preventing routing loops by preventing a router from advertising a route onto the same interface in which the route was learned. (Refer to Chapter 6, "Routing Protocols," for a full explanation.) However, split horizon could cause some problems with Frame Relay. Thankfully, several configuration options help you deal with this issue. But first, refer back to Figure 8-12. If split horizon was enabled on Atlanta, then Atlanta would learn about 140.1.12.0/24 from Charlotte but would not advertise the route to 140.1.12.0/24 in its updates to Nashville or Boston.

Split horizon logic applies to subinterfaces if they are configured. In other words, Atlanta uses a different subinterface for each VC to the three remote sites. Split horizon is enabled on each subinterface. However, because the routing updates from Charlotte are considered to enter Atlanta via one subinterface, and because routing updates to Nashville and Boston exit two other subinterfaces, then advertising 140.1.12.0/24 to Nashville and Boston is allowed.

Split horizon would be a problem in Figure 8-11, however. When all three VCs are up, no problem exists. However, if the VC from Mount Pilot to Raleigh went down, then split horizon on Mayberry would be harmful. Mount Pilot will advertise routes to 199.1.11.0, and Mayberry will receive that information in a routing update. However, because no subinterfaces are used, Mayberry would not advertise 199.1.11.0 to Raleigh with split horizon enabled.

The multipoint subinterfaces in Figure 8-13 would experience the same problems for the same reasons described for Figure 8-11.

The solution to the problem is to disable split horizon when not using subinterfaces or when using multipoint subinterfaces. The IOS defaults to disable split horizon on Frame Relay interfaces in all cases except for point-to-point subinterfaces. Table 8-16 summarizes these settings and shows that the current default settings work around the split horizon issues described in the last few paragraphs.

Table 8-16 Split Horizon and Frame Relay Interfaces

Type of Configuration

Split Horizon Is . . .

No subinterfaces

Disabled

Point-to-point subinterfaces

Enabled

Multipoint subinterfaces

Disabled

If the default value for split horizon is not desired, then the ip split horizon interface configuration command can be used to enable split horizon. Similarly, the no ip split horizon interface configuration command disables split horizon on that interface.

How Address Mapping Works

Frame Relay mapping is a topic you could ignore and still make Frame Relay work in a Cisco router. However, Cisco requires that CCNAs understand Frame Relay address mapping, for two main reasons. First, static mapping is just the kind of nasty question that is likely to crop up on the exam. Second, understanding mapping offers a good opportunity to review the concepts behind routing. As with most features implemented dynamically and by default, you can ignore mapping most of the time.

Mapping is required when using some other data links, but not all. For example, with IP, the ARP process dynamically builds a mapping between an IP address and a LAN address. This section discusses the basics behind why mapping is needed for LAN connections and Frame Relay, with a focus on Frame Relay.

Consider Figure 8-14 and the routing table that follows (Table 8-17).

Figure 8-14 Basic Point-to-Point Network

HDLC L3 Packet HDLC

Eth. L3 Packet Eth

Eth. L3 Packet Eth

Table 8-17 Partial Routing Table on Router A for Figure 8-14

Subnet

Outgoing Interface

Next Router

serial 0

The core routing logic must be considered to fully appreciate mapping. Router A receives an Ethernet frame from some host and strips the Ethernet header (and trailer). The destination IP address of the packet is compared to the IP routing table, and an entry is matched. The matched routing table entry tells the router to route the packet out serial 0 to 10.1.2.2 next (Router B's S1 IP address). Router A builds the HDLC header/trailer and sends the frame.

The fact that Router B's IP address on the common serial link is 10.1.2.2 has nothing to do with the contents of the HDLC header and trailer; Router B's IP address is immaterial in this case. If Router A can get the frame across the link, there is only one possible recipient—Router B. So, no mapping is needed between the Layer 3 address and the HDLC address on a point-to-point link.

Now consider a diagram with Ethernet between the routers (see Figure 8-15) and the routing table that follows (see Table 8-18).

Figure 8-15 Basic Ethernet Network

.2

E1

-A

E0

.3

Eth.

L3 Packet

Eth.

Eth.

L3 Packet

Eth.

Eth.

L3 Packet

Eth.

Table 8-18 Partial Routing Table on Router A for Figure 8-15

Table 8-18 Partial Routing Table on Router A for Figure 8-15

Subnet

Outgoing Interface

Next Router

Ethernet 0

Again consider the core routing logic. Router A receives an Ethernet frame from some host and strips the Ethernet header (and trailer). Router A decides to route the packet out Ethernet 0 to the next router, 10.1.2.2 (Router B's E1 IP address). Router A builds the new Ethernet header/ trailer and sends the frame.

Router A builds the Ethernet header based on the next-hop router's IP address—namely, 10.1.2.2 (Router B's E1 IP address). The destination Ethernet address in the header built by Router A is Router B's E1 address. Router A learns this information dynamically using the IP ARP protocol. Similarly, with IPX routing, the next-hop router's IPX address has the corresponding LAN address embedded in the IPX address. (With other Layer 3 protocols, there are other processes on LANs for learning the corresponding LAN address.) The information learned by IP ARP in this case is the information that maps the next-hop IP address to the LAN address used to reach it; this is called mapping. A more general definition for mapping follows:

The information that correlates to the next-hop router's Layer 3 address, and the Layer 2 address used to reach it, is called mapping. Mapping is needed on multiaccess networks.

Now consider the Frame Relay network in Figure 8-16, along with the routing table in Table 8-19.

Figure 8-16 Basic Frame Relay Network

DLCI 41

Gary

DLCI 41

DLCI 40

DLCI 42

Brice

DLCI 40

DLCI 42

0 0

Post a comment