Routers are typically edge devices that connect your LANs to the Frame Relay network. However,
you can use a router as part of the Frame Relay cloud or you can use it to create your own Frame
Relay network. Frame Relay switching is the forwarding of Frame Relay frames based upon their
DLCI assignments. You have seen how to configure a Frame Relay DTE device; now, let’s look
at how to configure a Frame Relay DCE switch. Routers are DTE devices by default; however, by
changing the Frame Relay interface type to a DCE, you can provide switching of frames.
Compare Figure 29.8 to Figure 29.9. Both of these diagrams represent the same network. In
Figure 29.8, you see the Frame Relay cloud without any detail. Each router on the right side will
send traffic to the router on the left by using DLCI 100. Keep in mind that the DLCI is an identifier
and that the DLCIs in this diagram could be the same or different and still communicate.
The router on the left will use DLCIs 101 and 300 to reach each router on the right. This is the
normal way that you should think about the frame cloud. It is typically not your concern what
happens within the Frame Relay network. Figure 29.9 shows that this particular Frame Relay
cloud is a single router configured as a switch.
FIGURE 2 9 . 8 Logical Frame Relay network
DLCI 300
DLCI 100 DLCI 101
DLCI 100
Frame Relay cloud
Physical Frame Relay network
DLCI 101
DLCI 100
Frame Relay cloud
Serial 1
Serial 0
Serial 2
IT Certification CCIE,CCNP,CCIP,CCNA,CCSP,Cisco Network Optimization and Security Tips
The debug frame-relay lmi Command
The debug frame-relay lmi command is used to help you troubleshoot and verify Frame
Relay connections. As you’ll see in the router output shown next, the out parameter is an LMI
status inquiry sent out from the router, and the (in) parameter is a reply from the Frame
Relay switch:
Router#debug frame-relay lmi
Serial0(in): Status, myseq 128
RT IE 1, length 1, type 0
KA IE 3, length 2, yourseq 128, myseq 128
PVC IE 0x7, length 0x6, dlci 16, status 0x2, bw 0
Serial0(out): StEnq, myseq 128, yourseen 214, DTE up
datagramstart = 0x1959DF4, datagramsize = 13
FR encap = 0xFCF10309
00 75 01 01 01 03 02 C6 E5
Serial0(in): Status, myseq 129
RT IE 1, length 1, type 1
KA IE 3, length 2, yourseq 129, myseq 129
Serial0(out): StEnq, myseq 130, yourseen 129, DTE up
datagramstart = 0x1959DF4, datagramsize = 13
FR encap = 0xFCF10309
00 74 01 01 01 03 02 C9 E3
The type 1 is an LMI keepalive from the router to the Frame Relay switch every 10 seconds.
This tells the router that the switch is still active and vice versa. The type 0 is an IARP exchanged
between routers every 60 seconds. Now notice that when the type is 0, you have a full status message
on your hands. When the type is 1, it is the standard status message, which is the keepalive
mentioned earlier (sometimes called the heartbeat).
Remember that the DLCI is known. There is no IP address in this output. Therefore, this
would be a poor excuse for an InARP reply (notice the in designation, corresponding to a reply).
Furthermore, Status and StEnq messages go between the DTE and DCE only. These messages
do not traverse the cloud, meaning they couldn’t possibly have anything to do with InARP. Full
status messages from the switch include all PVCs known by the switch. In this case, there’s only
one—DLCI = 16. The type 1 message will always have three lines, whereas the type 0 message
will have four or more, assuming PVCs exist. You would see InARP messages coming in the
exact same way you would see any other non-LMI frames coming in (such as ICMP pings), by
using the debug frame-relay packet command. Status indicators are pretty straightforward
and adhere to the following rules:
0x0 (no bits turned on) means “inactive.”
0x2 (second bit turned on) means “active.”
0x3 means that the active DLCI cannot accept any more traffic without drops occurring—
sort of a flow-control code. (Active bit [2nd] is on, but the first bit is also on as sort of a
Receive Not Ready (RNR) bit because Cisco uses this bit even though the ITU-T indicates
the first bit is reserved.)
0x4 (third bit turned on) means “deleted.”
Looking at our status, the DLCI 16, status 0x2 means the DLCI is active.
Relay connections. As you’ll see in the router output shown next, the out parameter is an LMI
status inquiry sent out from the router, and the (in) parameter is a reply from the Frame
Relay switch:
Router#debug frame-relay lmi
Serial0(in): Status, myseq 128
RT IE 1, length 1, type 0
KA IE 3, length 2, yourseq 128, myseq 128
PVC IE 0x7, length 0x6, dlci 16, status 0x2, bw 0
Serial0(out): StEnq, myseq 128, yourseen 214, DTE up
datagramstart = 0x1959DF4, datagramsize = 13
FR encap = 0xFCF10309
00 75 01 01 01 03 02 C6 E5
Serial0(in): Status, myseq 129
RT IE 1, length 1, type 1
KA IE 3, length 2, yourseq 129, myseq 129
Serial0(out): StEnq, myseq 130, yourseen 129, DTE up
datagramstart = 0x1959DF4, datagramsize = 13
FR encap = 0xFCF10309
00 74 01 01 01 03 02 C9 E3
The type 1 is an LMI keepalive from the router to the Frame Relay switch every 10 seconds.
This tells the router that the switch is still active and vice versa. The type 0 is an IARP exchanged
between routers every 60 seconds. Now notice that when the type is 0, you have a full status message
on your hands. When the type is 1, it is the standard status message, which is the keepalive
mentioned earlier (sometimes called the heartbeat).
Remember that the DLCI is known. There is no IP address in this output. Therefore, this
would be a poor excuse for an InARP reply (notice the in designation, corresponding to a reply).
Furthermore, Status and StEnq messages go between the DTE and DCE only. These messages
do not traverse the cloud, meaning they couldn’t possibly have anything to do with InARP. Full
status messages from the switch include all PVCs known by the switch. In this case, there’s only
one—DLCI = 16. The type 1 message will always have three lines, whereas the type 0 message
will have four or more, assuming PVCs exist. You would see InARP messages coming in the
exact same way you would see any other non-LMI frames coming in (such as ICMP pings), by
using the debug frame-relay packet command. Status indicators are pretty straightforward
and adhere to the following rules:
0x0 (no bits turned on) means “inactive.”
0x2 (second bit turned on) means “active.”
0x3 means that the active DLCI cannot accept any more traffic without drops occurring—
sort of a flow-control code. (Active bit [2nd] is on, but the first bit is also on as sort of a
Receive Not Ready (RNR) bit because Cisco uses this bit even though the ITU-T indicates
the first bit is reserved.)
0x4 (third bit turned on) means “deleted.”
Looking at our status, the DLCI 16, status 0x2 means the DLCI is active.
The show frame-relay lmi Command
The show frame-relay lmi command shows you the LMI statistics for an interface, as in the
following example:
Router#show frame lmi
LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 109087 Num Status msgs Rcvd 109087
Num Update Status Rcvd 0 Num Status Timeouts 0
Router#
The important statistics to notice are the number of inquiries sent and received. This
indicates the number of LMI status messages sent by the DTE device. The DCE sends a
status message in return. Noticing this statistic enables you to see whether data is passing
between the two devices.
following example:
Router#show frame lmi
LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = CISCO
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 109087 Num Status msgs Rcvd 109087
Num Update Status Rcvd 0 Num Status Timeouts 0
Router#
The important statistics to notice are the number of inquiries sent and received. This
indicates the number of LMI status messages sent by the DTE device. The DCE sends a
status message in return. Noticing this statistic enables you to see whether data is passing
between the two devices.
The show frame-relay map Command
You can see the current map entries and information about the connections by using the show
frame-relay map command. This command shows the Network-layer-to-DLCI mappings
table in the router. An example output of this command is given here:
Router_A#show frame-relay map
Serial0 (up): ip 172.16.1.2 dlci 500(0x64,0x1840), dynamic,
broadcast, status defined, active
Router_A#
LMI used IARP to determine the address of the remote router and created this dynamic mapping.
If you want to clear the Network layer-to-DLCI mappings on a router, you can
use the command clear frame-relay-inarp, which clears dynamically created
maps on the router.
frame-relay map command. This command shows the Network-layer-to-DLCI mappings
table in the router. An example output of this command is given here:
Router_A#show frame-relay map
Serial0 (up): ip 172.16.1.2 dlci 500(0x64,0x1840), dynamic,
broadcast, status defined, active
Router_A#
LMI used IARP to determine the address of the remote router and created this dynamic mapping.
If you want to clear the Network layer-to-DLCI mappings on a router, you can
use the command clear frame-relay-inarp, which clears dynamically created
maps on the router.
The show frame-relay pvc Command
The show frame-relay pvc command displays the status of each configured connection as
well as traffic statistics. As you’ll notice in the following router output, if you type the show
frame-relay pvc command, you’ll see all the PVCs that are configured on your router and
their status. You can also use a specific PVC number at the end of the command to see only that
particular PVC information:
Router_A#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 7 output pkts 13 in bytes 2252
out bytes 1886 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 8 out bcast bytes 1366
pvc create time 00:06:54, last time pvc status changed 00:03:17
DLCI = 17, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 1 output pkts 7 in bytes 30
out bytes 832 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 7 out bcast bytes 832
pvc create time 00:01:59, last time pvc status changed 00:00:49
Router_A#
As you can see, the show frame-relay pvc command also shows you the number of BECN
and FECN packets received on the router. Please note that the BECN and FECN statistics are
per PVC, not across the entire router.
well as traffic statistics. As you’ll notice in the following router output, if you type the show
frame-relay pvc command, you’ll see all the PVCs that are configured on your router and
their status. You can also use a specific PVC number at the end of the command to see only that
particular PVC information:
Router_A#show frame-relay pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
DLCI = 160, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 7 output pkts 13 in bytes 2252
out bytes 1886 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 8 out bcast bytes 1366
pvc create time 00:06:54, last time pvc status changed 00:03:17
DLCI = 17, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 1 output pkts 7 in bytes 30
out bytes 832 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 7 out bcast bytes 832
pvc create time 00:01:59, last time pvc status changed 00:00:49
Router_A#
As you can see, the show frame-relay pvc command also shows you the number of BECN
and FECN packets received on the router. Please note that the BECN and FECN statistics are
per PVC, not across the entire router.
The show interface Command Network
The show interface command can be used with interface parameters, for example, show
interface serial 0. This provides information pertaining to just serial 0. By itself, the
show interface command provides information about all interfaces on the router.
The show interface command displays information regarding the encapsulation, layer 1 and
layer 2 status, and the LMI DLCI. In the following code, the show interface serial 0 command
is used. Notice the encapsulation is Frame Relay. The LMI information is shown as well.
Router#show interface serial0
Serial0 is up, line protocol is up
Hardware is HD64570
MTU 1500 bytes, BW 1544 Kbit,DLY 20000 usec,rely 255/255,load 1/255
Encapsulation FRAME-RELAY,loopback not set,keepalive set(10 sec)
LMI enq sent 0, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
FR SVC disabled, LAPF state down
Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 19 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=down DSR=down DTR=down RTS=down CTS=down
Router#
Notice that the LMI counter information is shown, as well as the LMI type, which is Cisco
by default. As you can see, this output shows both errors for the interface and the time that the
interface counters were last cleared.
interface serial 0. This provides information pertaining to just serial 0. By itself, the
show interface command provides information about all interfaces on the router.
The show interface command displays information regarding the encapsulation, layer 1 and
layer 2 status, and the LMI DLCI. In the following code, the show interface serial 0 command
is used. Notice the encapsulation is Frame Relay. The LMI information is shown as well.
Router#show interface serial0
Serial0 is up, line protocol is up
Hardware is HD64570
MTU 1500 bytes, BW 1544 Kbit,DLY 20000 usec,rely 255/255,load 1/255
Encapsulation FRAME-RELAY,loopback not set,keepalive set(10 sec)
LMI enq sent 0, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 1023 LMI type is CISCO frame relay DTE
FR SVC disabled, LAPF state down
Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 19 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=down DSR=down DTR=down RTS=down CTS=down
Router#
Notice that the LMI counter information is shown, as well as the LMI type, which is Cisco
by default. As you can see, this output shows both errors for the interface and the time that the
interface counters were last cleared.
Verifying Frame Relay
It is just as important to be able to verify Frame Relay as it is to be able to understand how to
configure it. In this section, you will learn about the various commands used to verify Frame
Relay. These include the following:
* show interface
* show frame-relay pvc
* show frame-relay map
* clear frame-relay-inarp
* show frame-relay lmi
* debug frame-relay lmi
configure it. In this section, you will learn about the various commands used to verify Frame
Relay. These include the following:
* show interface
* show frame-relay pvc
* show frame-relay map
* clear frame-relay-inarp
* show frame-relay lmi
* debug frame-relay lmi
Point-to-Point and Multipoint Interfaces
At times, it is useful to have a multipoint network, such as Frame Relay, behave as if each connection
were a point-to-point link. The network example in Figure 29.6 has two connections
from one location (multipoint); this type of setup can lead to network problems if not thoroughly
understood. This multipoint configuration experiences problems primarily because of
the way it handles routing updates. In distance-vector routing protocols, there is a mechanism
known as split horizon. Split horizon states that it is never advantageous to send routing information
back out on the interface through which that information was learned. Or, simply put,
“Don’t tell me what I told you.” This is used to stop possible routing loop problems. Consider
the split-horizon implication of Figure 29.6.
In this figure, Router B sends a routing update to Router A, telling it about its directly connected
networks. Router A receives the routing information on its serial 0 interface and modifies
its routing table. Router A does not send the routing information back out serial 0 because of split
horizon. Because the routing information cannot be sent back out serial 0, Router C never learns
the networks off Router B. The networks are unreachable from Router C because Router C has
not heard of Router B’s directly connected networks.
The problem in Figure 29.6 is that there is only one physical interface and there are two virtual
circuits. The solution is to create a logical interface for each circuit, which solves the split
horizon issues. A subinterface is a logical interface within the router that is mapped to a particular
DLCI. When you set up subinterfaces, the interface previously configured for multipoint
will now appear as two point-to-point interfaces to the router. This would change the previous
example, as shown in Figure 29.7.
In this figure, Router A learns of Router B’s networks on the Serial 0.1 subinterface. Without
violating the split-horizon rule, Router A can send all the network information out on subinterface
Serial 0.2 to Router C.
To configure a subinterface on an interface, use the interface type.subinterface-number
[point-to-point | multipoint] command. For illustration purposes, configure Router A
with a subinterface. (The router commands are shown next.) Both types of subinterfaces that can
be configured appear in this example: point-to-point and multipoint. Point-to-point is used when
each PVC is a separate subnet. Multipoint is used when all PVCs use the same subnet.
FIGURE 2 9 . 7 Split-horizon issues with subinterfaces
PVC 16
PVC 17
1
2
Routing
update
A
B
C
Logical
interface
Physical
interface
Subnet 1
Subnet 2
Router A
Router B
Router C
Also notice in the following configuration that you can use any subinterface number, but
for administration purposes the DLCI number can be used. The subinterface number is only
locally significant:
RouterA(config)#interface serial0.?
<0-4294967295> Serial interface number
RouterA(config)#interface serial0.16 ?
multipoint Treat as a multipoint link
point-to-point Treat as a point-to-point link
RouterA(config)#interface serial0.16 point-to-point
RouterA(config-subif)#ip address 192.168.1.1 255.255.255.0
RouterA(config-subif)#frame-relay interface-dlci 16
RouterA(config-subif)#exit
RouterA(config)#interface serial0.17 multipoint
RouterA(config-subif)#ip address 192.168.2.2 255.255.255.0
RouterA(config-subif)#frame-relay map ip 192.168.2.1 17 broadcast
The configuration of Router A will now look like this:
RouterA#show running-config
Building configuration...
Current configuration:
!
version 11.3
!
hostname RouterA
!
interface Serial0
no ip address
encapsulation frame-relay
!
interface Serial0.16 point-to-point
ip address 192.168.1.1 255.255.255.0
frame-relay interface-dlci 16
!
interface Serial0.17 multipoint
ip address 192.168.2.2 255.255.255.0
frame-relay map ip 192.168.2.1 17 broadcast
!
end
RouterA#
This configuration specifies which DLCI is associated with which subinterface. This is necessary
because the router has no way of determining which particular DLCI should be associated
with which subinterface.
Note:
Many people find the point-to-point subinterface configuration easier and less
prone to routing errors than a physical multipoint configuration.
were a point-to-point link. The network example in Figure 29.6 has two connections
from one location (multipoint); this type of setup can lead to network problems if not thoroughly
understood. This multipoint configuration experiences problems primarily because of
the way it handles routing updates. In distance-vector routing protocols, there is a mechanism
known as split horizon. Split horizon states that it is never advantageous to send routing information
back out on the interface through which that information was learned. Or, simply put,
“Don’t tell me what I told you.” This is used to stop possible routing loop problems. Consider
the split-horizon implication of Figure 29.6.
In this figure, Router B sends a routing update to Router A, telling it about its directly connected
networks. Router A receives the routing information on its serial 0 interface and modifies
its routing table. Router A does not send the routing information back out serial 0 because of split
horizon. Because the routing information cannot be sent back out serial 0, Router C never learns
the networks off Router B. The networks are unreachable from Router C because Router C has
not heard of Router B’s directly connected networks.
The problem in Figure 29.6 is that there is only one physical interface and there are two virtual
circuits. The solution is to create a logical interface for each circuit, which solves the split
horizon issues. A subinterface is a logical interface within the router that is mapped to a particular
DLCI. When you set up subinterfaces, the interface previously configured for multipoint
will now appear as two point-to-point interfaces to the router. This would change the previous
example, as shown in Figure 29.7.
In this figure, Router A learns of Router B’s networks on the Serial 0.1 subinterface. Without
violating the split-horizon rule, Router A can send all the network information out on subinterface
Serial 0.2 to Router C.
To configure a subinterface on an interface, use the interface type.subinterface-number
[point-to-point | multipoint] command. For illustration purposes, configure Router A
with a subinterface. (The router commands are shown next.) Both types of subinterfaces that can
be configured appear in this example: point-to-point and multipoint. Point-to-point is used when
each PVC is a separate subnet. Multipoint is used when all PVCs use the same subnet.
FIGURE 2 9 . 7 Split-horizon issues with subinterfaces
PVC 16
PVC 17
1
2
Routing
update
A
B
C
Logical
interface
Physical
interface
Subnet 1
Subnet 2
Router A
Router B
Router C
Also notice in the following configuration that you can use any subinterface number, but
for administration purposes the DLCI number can be used. The subinterface number is only
locally significant:
RouterA(config)#interface serial0.?
<0-4294967295> Serial interface number
RouterA(config)#interface serial0.16 ?
multipoint Treat as a multipoint link
point-to-point Treat as a point-to-point link
RouterA(config)#interface serial0.16 point-to-point
RouterA(config-subif)#ip address 192.168.1.1 255.255.255.0
RouterA(config-subif)#frame-relay interface-dlci 16
RouterA(config-subif)#exit
RouterA(config)#interface serial0.17 multipoint
RouterA(config-subif)#ip address 192.168.2.2 255.255.255.0
RouterA(config-subif)#frame-relay map ip 192.168.2.1 17 broadcast
The configuration of Router A will now look like this:
RouterA#show running-config
Building configuration...
Current configuration:
!
version 11.3
!
hostname RouterA
!
interface Serial0
no ip address
encapsulation frame-relay
!
interface Serial0.16 point-to-point
ip address 192.168.1.1 255.255.255.0
frame-relay interface-dlci 16
!
interface Serial0.17 multipoint
ip address 192.168.2.2 255.255.255.0
frame-relay map ip 192.168.2.1 17 broadcast
!
end
RouterA#
This configuration specifies which DLCI is associated with which subinterface. This is necessary
because the router has no way of determining which particular DLCI should be associated
with which subinterface.
Note:
Many people find the point-to-point subinterface configuration easier and less
prone to routing errors than a physical multipoint configuration.
Congestion Handling by Routers
The router can also play a part in determining which traffic is more or less important on the
Frame Relay network. The Discard Eligibility list (frame-relay de-list global command)
and Discard Eligibility group (frame-relay de-group interface command) give the router the
capability to set the Discard Eligibility bit on a frame.
Consider a company that notices an increased number of dropped frames on the Frame Relay
network. They determine that the primary cause is an increase in the amount of AppleTalk traffic
across the Frame Relay network. The additional traffic has impaired the performance of missioncritical
traffic.
To have the router turn on the DE bit for AppleTalk traffic, thereby dropping the noncritical
AppleTalk traffic before any other traffic, use the frame-relay de-list command. Here is an
example of how to configure a router to do this:
RouterA#config t
RouterA(config)#frame-relay de-list 1 protocol appletalk
RouterA(config)#interface serial0
RouterA(config-if)#frame-relay de-group 1 100
In this example, the frame-relay de-list command uses a list number of 1 and a protocol
of AppleTalk. The list number of 1 is then applied to the interface connected to the Frame Relay
network with the frame-relay de-group command for a specified DLCI, in this case 100.
You could also use an AppleTalk access list (600–699) to define which Apple-
Talk traffic is set with the DE bit.
The modified router configuration looks like this:
RouterA#show running-config
Building configuration...
Current configuration:
!
version 11.2
!
hostname RouterA
!
appletalk routing
frame-relay de-list 1 protocol appletalk
!
interface Serial0
ip address 192.168.1.1 255.255.255.0
encapsulation frame-relay
appletalk address 8.202
appletalk zone Sybex
frame-relay de-group 1 100
frame-relay map appletalk 8.201 100 broadcast
frame-relay map ip 192.168.1.2 100 broadcast
!
end
RouterA#
The Frame Relay DE list will match AppleTalk frames. The frame-relay de-group command
binds the DE list to the interface. In the event of congestion, these two packet types are
much more likely to be dropped than mission-critical traffic. The 100 at the end of the framerelay
de-group command specifies to use the list on DLCI 100.
Frame Relay network. The Discard Eligibility list (frame-relay de-list global command)
and Discard Eligibility group (frame-relay de-group interface command) give the router the
capability to set the Discard Eligibility bit on a frame.
Consider a company that notices an increased number of dropped frames on the Frame Relay
network. They determine that the primary cause is an increase in the amount of AppleTalk traffic
across the Frame Relay network. The additional traffic has impaired the performance of missioncritical
traffic.
To have the router turn on the DE bit for AppleTalk traffic, thereby dropping the noncritical
AppleTalk traffic before any other traffic, use the frame-relay de-list command. Here is an
example of how to configure a router to do this:
RouterA#config t
RouterA(config)#frame-relay de-list 1 protocol appletalk
RouterA(config)#interface serial0
RouterA(config-if)#frame-relay de-group 1 100
In this example, the frame-relay de-list command uses a list number of 1 and a protocol
of AppleTalk. The list number of 1 is then applied to the interface connected to the Frame Relay
network with the frame-relay de-group command for a specified DLCI, in this case 100.
You could also use an AppleTalk access list (600–699) to define which Apple-
Talk traffic is set with the DE bit.
The modified router configuration looks like this:
RouterA#show running-config
Building configuration...
Current configuration:
!
version 11.2
!
hostname RouterA
!
appletalk routing
frame-relay de-list 1 protocol appletalk
!
interface Serial0
ip address 192.168.1.1 255.255.255.0
encapsulation frame-relay
appletalk address 8.202
appletalk zone Sybex
frame-relay de-group 1 100
frame-relay map appletalk 8.201 100 broadcast
frame-relay map ip 192.168.1.2 100 broadcast
!
end
RouterA#
The Frame Relay DE list will match AppleTalk frames. The frame-relay de-group command
binds the DE list to the interface. In the event of congestion, these two packet types are
much more likely to be dropped than mission-critical traffic. The 100 at the end of the framerelay
de-group command specifies to use the list on DLCI 100.
Congestion Handling by Frame Relay Switches
A Frame Relay switch has a simple job: It forwards all the data that it can. If there is more data
than bandwidth, the switch will first drop the data with the DE bit set and will then drop committed
data if needed. In addition, the Frame Relay switch will also send out messages that congestion
is occurring.
Backward explicit congestion notification (BECN) and forward explicit congestion notification
(FECN) are the primary notification mechanisms used for handling congestion on the
Frame Relay switching internetwork. BECNs and FECNs both send notices that congestion is
occurring. A BECN is transmitted in the direction from which the traffic came, and an FECN
is transmitted in the direction in which the traffic is going.
Under normal circumstances, only Frame Relay switches send BECN and
FECN messages.
The end devices receive these notifications indicating that they should reduce the amount of
traffic that they are sending. A Frame Relay switch does not enforce the reduction; it simply
notifies the end devices. It is the responsibility of the end devices to reduce the traffic.
The congestion mechanisms are important to understand because congestion occurs frequently
on Frame Relay networks. As providers attempt to maximize the use of their lines, they sell more
bandwidth than they can actually provide. This is called oversubscription. Oversubscription is a
growing trend, so you must be aware of the implications and effects of the resulting congestion.
Some providers will attempt to sell you a zero CIR. Although inexpensive, you
have no guarantee that mission-critical data (or any data, for that matter!) will
get through.
than bandwidth, the switch will first drop the data with the DE bit set and will then drop committed
data if needed. In addition, the Frame Relay switch will also send out messages that congestion
is occurring.
Backward explicit congestion notification (BECN) and forward explicit congestion notification
(FECN) are the primary notification mechanisms used for handling congestion on the
Frame Relay switching internetwork. BECNs and FECNs both send notices that congestion is
occurring. A BECN is transmitted in the direction from which the traffic came, and an FECN
is transmitted in the direction in which the traffic is going.
Under normal circumstances, only Frame Relay switches send BECN and
FECN messages.
The end devices receive these notifications indicating that they should reduce the amount of
traffic that they are sending. A Frame Relay switch does not enforce the reduction; it simply
notifies the end devices. It is the responsibility of the end devices to reduce the traffic.
The congestion mechanisms are important to understand because congestion occurs frequently
on Frame Relay networks. As providers attempt to maximize the use of their lines, they sell more
bandwidth than they can actually provide. This is called oversubscription. Oversubscription is a
growing trend, so you must be aware of the implications and effects of the resulting congestion.
Some providers will attempt to sell you a zero CIR. Although inexpensive, you
have no guarantee that mission-critical data (or any data, for that matter!) will
get through.
Bursting network
Bursting is one of the features that has made Frame Relay so popular. Bursting enables a user
to transmit data faster than the CIR for a short period of time. Figure 29.5 shows the difference
between the CIR and the access rate and how the burst traffic rate can increase beyond the CIR.
The network controls this bursting capability, and it usually does not result in any additional fees
on the user. There is a catch, though. Some burst traffic has the Discard Eligibility (DE) bit turned
on, indicating excess traffic above CIR. If a Frame Relay switch becomes congested, traffic with
the DE bit set (excess burst traffic) is the first to be dropped.
You will see the following symbols: Bc, Be, and Tc. Committed burst size (Bc)
and excess burst size (Be) are the two types of burst sizes. Each of these sizes is measured over
the committed rate measurement interval (Tc). Bc is the maximum amount of data that the network
can guarantee will be delivered during the time Tc. Be is the amount of traffic by which the
user can exceed the committed burst size.
For example, take a user who buys a Frame Relay circuit with the following characteristics:
1,544Kbps access rate
256Kbps committed information rate
Four-second committed time interval
The user is guaranteed a CIR of 256Kbps over a four-second period. The user could transmit
256Kbps for four seconds, and the network would ensure delivery. The user could alternately
send 1,024Kbps for one second, representing the committed burst. However, for the remaining
three seconds, there would be no guarantee of delivery for the excess burst traffic.
to transmit data faster than the CIR for a short period of time. Figure 29.5 shows the difference
between the CIR and the access rate and how the burst traffic rate can increase beyond the CIR.
The network controls this bursting capability, and it usually does not result in any additional fees
on the user. There is a catch, though. Some burst traffic has the Discard Eligibility (DE) bit turned
on, indicating excess traffic above CIR. If a Frame Relay switch becomes congested, traffic with
the DE bit set (excess burst traffic) is the first to be dropped.
You will see the following symbols: Bc, Be, and Tc. Committed burst size (Bc)
and excess burst size (Be) are the two types of burst sizes. Each of these sizes is measured over
the committed rate measurement interval (Tc). Bc is the maximum amount of data that the network
can guarantee will be delivered during the time Tc. Be is the amount of traffic by which the
user can exceed the committed burst size.
For example, take a user who buys a Frame Relay circuit with the following characteristics:
1,544Kbps access rate
256Kbps committed information rate
Four-second committed time interval
The user is guaranteed a CIR of 256Kbps over a four-second period. The user could transmit
256Kbps for four seconds, and the network would ensure delivery. The user could alternately
send 1,024Kbps for one second, representing the committed burst. However, for the remaining
three seconds, there would be no guarantee of delivery for the excess burst traffic.
Committed Information Rate (CIR) network
The committed information rate (CIR) is the rate at which the provider guarantees to deliver
network traffic. The CIR is always less than or equal to the access rate. The CIR is advertised
in Kbps and is actually averaged over a specified time period, referred to as committed rate
measurement interval (Tc). This is what the cost of the Frame Relay connection is normally
based upon.
network traffic. The CIR is always less than or equal to the access rate. The CIR is advertised
in Kbps and is actually averaged over a specified time period, referred to as committed rate
measurement interval (Tc). This is what the cost of the Frame Relay connection is normally
based upon.
Access Rate
Access rate is the maximum speed at which data can be transferred to the Frame Relay network.
This number denotes the actual line speed of the connection to the provider. In a dedicated circuit,
you would consider this the actual data rate. However, in a Frame Relay network, this is
considered the maximum data rate.
This number denotes the actual line speed of the connection to the provider. In a dedicated circuit,
you would consider this the actual data rate. However, in a Frame Relay network, this is
considered the maximum data rate.
Factors Affecting Performance
Network performance at the router level is affected by three primary factors:
Access rate
Committed information rate (CIR)
Bursting
Each of these has an effect on Frame Relay.
Access rate
Committed information rate (CIR)
Bursting
Each of these has an effect on Frame Relay.
Frame Relay Congestion Control
Frame Relay is optimized for speed and contains little error control. Frame Relay will discard
errored frames and will not attempt to recover from the error either through retransmission or
repair. Ideally, users can send as much data as they want across the network without interference.
However, because user requests for bandwidth often outstrip the network’s capability to
provide bandwidth, a mechanism is needed to handle congestion in the frame switch.
In this section, you will learn about the factors that affect network performance, as well as
methods for handling Frame Relay congestion. The two primary methods of congestion handling
use Frame Relay switches and routers.
errored frames and will not attempt to recover from the error either through retransmission or
repair. Ideally, users can send as much data as they want across the network without interference.
However, because user requests for bandwidth often outstrip the network’s capability to
provide bandwidth, a mechanism is needed to handle congestion in the frame switch.
In this section, you will learn about the factors that affect network performance, as well as
methods for handling Frame Relay congestion. The two primary methods of congestion handling
use Frame Relay switches and routers.
Configuring Frame Relay cisco
The first step in configuring Frame Relay is to select the interface and then enable the Frame
Relay encapsulation on the serial interface. You do this with the
encapsulation frame-relay
command. As you will notice in the following router configuration commands, there are two
options:
cisco
and
ietf
.
Router#
config t
Router(config)#interface serial 0
Router(config-if)#encapsulation frame-relay [cisco or ietf]
Cisco is the default encapsulation, which means that you have another Cisco router on the
remote end with which your router will communicate. You will use the IETF encapsulation
when communicating with a remote router that is not a Cisco device.
After you configure the encapsulation to the serial interface, you then need to add the Network
layer address, DLCI number, and LMI type. Cisco’s capability to autosense the LMI type has
greatly simplified configuration. The following router configuration shows the process of specifying
the IP address and DLCI number, but not the LMI type because it is automatically detected:
Router(config-if)#ip address 172.16.10.1 255.255.255.0
Router(config-if)#frame-relay interface-dlci 16
Router(config-if)#no shutdown
Relay encapsulation on the serial interface. You do this with the
encapsulation frame-relay
command. As you will notice in the following router configuration commands, there are two
options:
cisco
and
ietf
.
Router#
config t
Router(config)#interface serial 0
Router(config-if)#encapsulation frame-relay [cisco or ietf]
Cisco is the default encapsulation, which means that you have another Cisco router on the
remote end with which your router will communicate. You will use the IETF encapsulation
when communicating with a remote router that is not a Cisco device.
After you configure the encapsulation to the serial interface, you then need to add the Network
layer address, DLCI number, and LMI type. Cisco’s capability to autosense the LMI type has
greatly simplified configuration. The following router configuration shows the process of specifying
the IP address and DLCI number, but not the LMI type because it is automatically detected:
Router(config-if)#ip address 172.16.10.1 255.255.255.0
Router(config-if)#frame-relay interface-dlci 16
Router(config-if)#no shutdown
Frame Relay Local Management Interface (LMI)
In 1990, the Group of Four developed extensions to the Frame Relay standard to help ease the
management and configuration burden. One of these extensions was the
Local Management
Interface (LMI)
. LMI provides for virtual circuit status messages and multicasting.
Cisco routers support three versions of the LMI standard: Cisco, ANSI, and ITU-T (Q.933a).
LMI autosense, the automatic detection of the LMI type, was introduced in IOS version 11.2. LMI
autosense determines the LMI type by rapidly trying each of them in order: ANSI, ITU-T (Q.933a),
and then Cisco. If it cannot determine the LMI type within 60 seconds, it will terminate the
autosense process and revert to the Cisco LMI type.
After LMI is established between the router and the switch, the next stage is DLCI determination
and IARP. The router will query the switch, asking what the DLCI(s) is/are for this
circuit. The router will configure itself with that DLCI(s) and query the switch to determine
the status of the circuit.
This query is the first stage of discovery. The query that is sent includes the local router’s network
information. The remote router will record the network information and reply in kind.
The local router will map the DLCI it learned from static or dynamic addressing to other network
addresses it discovered from queries.
When an IARP is made, the router updates its map table with one of three possible LMI connection
states:
Active
The connection is active, and the routers can exchange data through the PVC.
Inactive
The local connection to the Frame Relay switch is working, but the remote end of the
PVC is not communicating to the Frame Relay switch.
Deleted
No LMI keepalive information from the switch to the router is being received for this
PVC. This could be because no LMI is actually being exchanged or because the DLCI is not configured
on the ingress switch.
Figure 29.4 shows that the Chicago office PVC to Miami is deleted because the Miami office
is not receiving keepalives from the Frame Relay switch. Neither this inactive state nor this deleted
state affect the other connections (PVCs) that Chicago might have to other locations.
management and configuration burden. One of these extensions was the
Local Management
Interface (LMI)
. LMI provides for virtual circuit status messages and multicasting.
Cisco routers support three versions of the LMI standard: Cisco, ANSI, and ITU-T (Q.933a).
LMI autosense, the automatic detection of the LMI type, was introduced in IOS version 11.2. LMI
autosense determines the LMI type by rapidly trying each of them in order: ANSI, ITU-T (Q.933a),
and then Cisco. If it cannot determine the LMI type within 60 seconds, it will terminate the
autosense process and revert to the Cisco LMI type.
After LMI is established between the router and the switch, the next stage is DLCI determination
and IARP. The router will query the switch, asking what the DLCI(s) is/are for this
circuit. The router will configure itself with that DLCI(s) and query the switch to determine
the status of the circuit.
This query is the first stage of discovery. The query that is sent includes the local router’s network
information. The remote router will record the network information and reply in kind.
The local router will map the DLCI it learned from static or dynamic addressing to other network
addresses it discovered from queries.
When an IARP is made, the router updates its map table with one of three possible LMI connection
states:
Active
The connection is active, and the routers can exchange data through the PVC.
Inactive
The local connection to the Frame Relay switch is working, but the remote end of the
PVC is not communicating to the Frame Relay switch.
Deleted
No LMI keepalive information from the switch to the router is being received for this
PVC. This could be because no LMI is actually being exchanged or because the DLCI is not configured
on the ingress switch.
Figure 29.4 shows that the Chicago office PVC to Miami is deleted because the Miami office
is not receiving keepalives from the Frame Relay switch. Neither this inactive state nor this deleted
state affect the other connections (PVCs) that Chicago might have to other locations.
Configuring Frame Relays
The first step in configuring Frame Relay is to select the interface and then enable the Frame
Relay encapsulation on the serial interface. You do this with the
encapsulation frame-relay
command. As you will notice in the following router configuration commands, there are two
options:
cisco
and
ietf
.
Router#
config t
Router(config)#interface serial 0
Router(config-if)#encapsulation frame-relay [cisco or ietf]
Cisco is the default encapsulation, which means that you have another Cisco router on the
remote end with which your router will communicate. You will use the IETF encapsulation
when communicating with a remote router that is not a Cisco device.
After you configure the encapsulation to the serial interface, you then need to add the Network
layer address, DLCI number, and LMI type. Cisco’s capability to autosense the LMI type has
greatly simplified configuration. The following router configuration shows the process of specifying
the IP address and DLCI number, but not the LMI type because it is automatically detected:
Router(config-if)#ip address 172.16.10.1 255.255.255.0
Router(config-if)#frame-relay interface-dlci 16
Router(config-if)#no shutdown
Relay encapsulation on the serial interface. You do this with the
encapsulation frame-relay
command. As you will notice in the following router configuration commands, there are two
options:
cisco
and
ietf
.
Router#
config t
Router(config)#interface serial 0
Router(config-if)#encapsulation frame-relay [cisco or ietf]
Cisco is the default encapsulation, which means that you have another Cisco router on the
remote end with which your router will communicate. You will use the IETF encapsulation
when communicating with a remote router that is not a Cisco device.
After you configure the encapsulation to the serial interface, you then need to add the Network
layer address, DLCI number, and LMI type. Cisco’s capability to autosense the LMI type has
greatly simplified configuration. The following router configuration shows the process of specifying
the IP address and DLCI number, but not the LMI type because it is automatically detected:
Router(config-if)#ip address 172.16.10.1 255.255.255.0
Router(config-if)#frame-relay interface-dlci 16
Router(config-if)#no shutdown
Frame Relay Local Management Interface (LMI)
In 1990, the Group of Four developed extensions to the Frame Relay standard to help ease the
management and configuration burden. One of these extensions was the
Local Management
Interface (LMI)
. LMI provides for virtual circuit status messages and multicasting.
Cisco routers support three versions of the LMI standard: Cisco, ANSI, and ITU-T (Q.933a).
LMI autosense, the automatic detection of the LMI type, was introduced in IOS version 11.2. LMI
autosense determines the LMI type by rapidly trying each of them in order: ANSI, ITU-T (Q.933a),
and then Cisco. If it cannot determine the LMI type within 60 seconds, it will terminate the
autosense process and revert to the Cisco LMI type.
After LMI is established between the router and the switch, the next stage is DLCI determination
and IARP. The router will query the switch, asking what the DLCI(s) is/are for this
circuit. The router will configure itself with that DLCI(s) and query the switch to determine
the status of the circuit.
This query is the first stage of discovery. The query that is sent includes the local router’s network
information. The remote router will record the network information and reply in kind.
The local router will map the DLCI it learned from static or dynamic addressing to other network
addresses it discovered from queries.
When an IARP is made, the router updates its map table with one of three possible LMI connection
states:
Active
The connection is active, and the routers can exchange data through the PVC.
Inactive
The local connection to the Frame Relay switch is working, but the remote end of the
PVC is not communicating to the Frame Relay switch.
Deleted
No LMI keepalive information from the switch to the router is being received for this
PVC. This could be because no LMI is actually being exchanged or because the DLCI is not configured
on the ingress switch.
Figure 29.4 shows that the Chicago office PVC to Miami is deleted because the Miami office
is not receiving keepalives from the Frame Relay switch. Neither this inactive state nor this deleted
state affect the other connections (PVCs) that Chicago might have to other locations.
FIGURE 2 9 . 4
LMI connection states
PVC
DLCI = 16
LMI = inactive
Keepalive
PVC
DLCI = 17
LMI = deleted
No keepalive
management and configuration burden. One of these extensions was the
Local Management
Interface (LMI)
. LMI provides for virtual circuit status messages and multicasting.
Cisco routers support three versions of the LMI standard: Cisco, ANSI, and ITU-T (Q.933a).
LMI autosense, the automatic detection of the LMI type, was introduced in IOS version 11.2. LMI
autosense determines the LMI type by rapidly trying each of them in order: ANSI, ITU-T (Q.933a),
and then Cisco. If it cannot determine the LMI type within 60 seconds, it will terminate the
autosense process and revert to the Cisco LMI type.
After LMI is established between the router and the switch, the next stage is DLCI determination
and IARP. The router will query the switch, asking what the DLCI(s) is/are for this
circuit. The router will configure itself with that DLCI(s) and query the switch to determine
the status of the circuit.
This query is the first stage of discovery. The query that is sent includes the local router’s network
information. The remote router will record the network information and reply in kind.
The local router will map the DLCI it learned from static or dynamic addressing to other network
addresses it discovered from queries.
When an IARP is made, the router updates its map table with one of three possible LMI connection
states:
Active
The connection is active, and the routers can exchange data through the PVC.
Inactive
The local connection to the Frame Relay switch is working, but the remote end of the
PVC is not communicating to the Frame Relay switch.
Deleted
No LMI keepalive information from the switch to the router is being received for this
PVC. This could be because no LMI is actually being exchanged or because the DLCI is not configured
on the ingress switch.
Figure 29.4 shows that the Chicago office PVC to Miami is deleted because the Miami office
is not receiving keepalives from the Frame Relay switch. Neither this inactive state nor this deleted
state affect the other connections (PVCs) that Chicago might have to other locations.
FIGURE 2 9 . 4
LMI connection states
PVC
DLCI = 16
LMI = inactive
Keepalive
PVC
DLCI = 17
LMI = deleted
No keepalive
DCLI Mapping
There needs to be a way to link the layer 2 identifiers (DLCI) to layer 3 (Network layer) addresses.
Mapping
provides a mechanism to link one or more network addresses to a DLCI. Remember that
Frame Relay works only at the Data Link layer (layer 2 of the OSI model) and does not understand
IP addressing. In fact, to communicate via IP (because it could just as easily be IPX and AppleTalk
instead of IP), you need to convert the destination IP address to a destination DLCI (PVC) number.
The frame switch uses only DLCI numbers to communicate, not IP addresses.
Mappings can be done either statically by an administrator or dynamically via the router. If
you are mapping a static Network layer address to a DLCI number, you use the
frame-relay
map
command. It is necessary to create static mappings when the remote router does not support
dynamic addressing or when you’re using OSPF in some network configurations. It’s also necessary
even if you want to control broadcasts over your Frame Relay network.
To understand how to use static mappings, look at Figure 29.3. Figure 29.3 shows a corporate
office in Chicago connected to two other sites—one in Miami and one in New York. The
IP address of the serial interface in New York is 172.16.1.2/24, and the IP address of the Miami
serial interface is 172.16.1.3/24. It’s important to note that the Miami location is a Cisco router,
and the New York location is a non-Cisco router. A static mapping would have to be used for
different Frame Relay encapsulation methods to run under the same physical serial interface,
unless all routers used an open encapsulation type for interoperability, resulting in the ability to
use dynamic mapping.
FIGURE 2 9 . 3
Configuring Frame Relay static mappings
The following router output shows an example of how you would create static Frame Relay
mappings on the Chicago router:
Router(config)#
interface serial 0
Router(config-if)#
ip address 172.16.1.1 255.255.255.248
Router(config-if)#
frame-relay map ip 172.16.1.2 20 broadcast ietf
Router(config-if)#
frame-relay map ip 172.16.1.3 16 broadcast
Router(config-if)#
exit
The
frame-relay map
command maps the IP address of the remote location to a specific
PVC or DLCI. The first map statement tells the Chicago router that if it has an IP packet with
Chicago
Miami
Cisco router
New York
Non-Cisco router
PVC
PVC
DLCI to NY = 20
DLCI to Miami = 16
Corporate Office
172.16.1.2/24
a destination IP address of 172.16.1.2, it should use PVC 20 to get there. Also, because the New
York office is not a Cisco router (can you imagine that?), it should use the standard Internet
Engineering Task Force (IETF) encapsulation method. We’ll talk about encapsulation methods
used with Frame Relay in a minute.
Because Miami is a Cisco router, no specification of encapsulation is necessary because Cisco is
the default encapsulation method. The broadcast parameter at the end of each line specifies that
broadcasts should be forwarded over the PVC because they are not forwarded by default. The
frame-relay map
command supports many Network layer protocols, including IP, Connectionless
Network Services (CLNS), Digital Equipment Corporation’s Networking architecture (DECnet),
Xerox Network Services (XNS), and Virtual Integrated Network Service (VINES).
Dynamic addressing is turned on by default. It automatically maps Network layer addresses
to DLCI addresses rather well
.
Inverse ARP (IARP)
is used to automatically map a DLCI to a
network address (IP, IPX, and so on) without any user configuration. It provides Network
layer-to-DCLI-number translation and creates an entry in the DLCI mapping table. This table
is used by the router to correctly route outgoing traffic. No map configuration is necessary for
IARP to work.
Mapping
provides a mechanism to link one or more network addresses to a DLCI. Remember that
Frame Relay works only at the Data Link layer (layer 2 of the OSI model) and does not understand
IP addressing. In fact, to communicate via IP (because it could just as easily be IPX and AppleTalk
instead of IP), you need to convert the destination IP address to a destination DLCI (PVC) number.
The frame switch uses only DLCI numbers to communicate, not IP addresses.
Mappings can be done either statically by an administrator or dynamically via the router. If
you are mapping a static Network layer address to a DLCI number, you use the
frame-relay
map
command. It is necessary to create static mappings when the remote router does not support
dynamic addressing or when you’re using OSPF in some network configurations. It’s also necessary
even if you want to control broadcasts over your Frame Relay network.
To understand how to use static mappings, look at Figure 29.3. Figure 29.3 shows a corporate
office in Chicago connected to two other sites—one in Miami and one in New York. The
IP address of the serial interface in New York is 172.16.1.2/24, and the IP address of the Miami
serial interface is 172.16.1.3/24. It’s important to note that the Miami location is a Cisco router,
and the New York location is a non-Cisco router. A static mapping would have to be used for
different Frame Relay encapsulation methods to run under the same physical serial interface,
unless all routers used an open encapsulation type for interoperability, resulting in the ability to
use dynamic mapping.
FIGURE 2 9 . 3
Configuring Frame Relay static mappings
The following router output shows an example of how you would create static Frame Relay
mappings on the Chicago router:
Router(config)#
interface serial 0
Router(config-if)#
ip address 172.16.1.1 255.255.255.248
Router(config-if)#
frame-relay map ip 172.16.1.2 20 broadcast ietf
Router(config-if)#
frame-relay map ip 172.16.1.3 16 broadcast
Router(config-if)#
exit
The
frame-relay map
command maps the IP address of the remote location to a specific
PVC or DLCI. The first map statement tells the Chicago router that if it has an IP packet with
Chicago
Miami
Cisco router
New York
Non-Cisco router
PVC
PVC
DLCI to NY = 20
DLCI to Miami = 16
Corporate Office
172.16.1.2/24
a destination IP address of 172.16.1.2, it should use PVC 20 to get there. Also, because the New
York office is not a Cisco router (can you imagine that?), it should use the standard Internet
Engineering Task Force (IETF) encapsulation method. We’ll talk about encapsulation methods
used with Frame Relay in a minute.
Because Miami is a Cisco router, no specification of encapsulation is necessary because Cisco is
the default encapsulation method. The broadcast parameter at the end of each line specifies that
broadcasts should be forwarded over the PVC because they are not forwarded by default. The
frame-relay map
command supports many Network layer protocols, including IP, Connectionless
Network Services (CLNS), Digital Equipment Corporation’s Networking architecture (DECnet),
Xerox Network Services (XNS), and Virtual Integrated Network Service (VINES).
Dynamic addressing is turned on by default. It automatically maps Network layer addresses
to DLCI addresses rather well
.
Inverse ARP (IARP)
is used to automatically map a DLCI to a
network address (IP, IPX, and so on) without any user configuration. It provides Network
layer-to-DCLI-number translation and creates an entry in the DLCI mapping table. This table
is used by the router to correctly route outgoing traffic. No map configuration is necessary for
IARP to work.
Data Link Connection Identifier (DLCI)
Frame Relay provides statistical time division multiplexing (Stat-TDM). Time division multiplexing
(TDM) is like going to Disneyland. It’s true. Remember how you have to stand in line to get
into Space Mountain? Well, after you get to the loading area, you’re placed in a section with rails
that separate you from the other passengers. You can then get into only the one car that is in front
of you and only when it is empty. Think of the holding area as the interface buffers of a router;
the cars are the time slots on the circuit. When a time slot drives up, you can get in, but not before
that, and not if someone is already in that slot.
Now Stat-TDM is an improvement over straight TDM. Stat-TDM enables you to jump into
a different line if it is not in use and to get into any car. This is a first-come, first-served technology.
Stat-TDM is used with Frame Relay to allow multiple logical data connections (virtual
circuits) over a single physical link. Basically, these circuits give time slots to first-come, firstserved
and priority-based frames over the physical link. Going back to our analogy, you can
think of Frame Relay as the capability to send multiple cars through space on one train, each
car holding a different person.
So, how is each person (data) identified in the car (time slot)? How does the frame switch
know where to send each frame? The answer to this is a
data link connection identifier (DLCI)
.
Because Frame Relay is based on virtual circuits instead of physical ones, DLCIs are used to
identify a virtual circuit and tie it to a physical circuit. This means each frame can be identified
as it traverses the Frame Relay switch and is then sent to the routers at the remote ends.
DLCIs are considered only locally significant, which means that they see the entire virtual circuit
but only up to the point of the Frame Relay switch. The provider is responsible for assigning
DLCIs and their significance to the network.
DLCIs identify the logical virtual circuit between the customer premises equipment (CPE)
and the Frame Relay switch. The switch then maps the DLCIs between each pair of routers in
order to create the PVC. The Frame Relay switch keeps a mapping table of DLCI numbers to
outgoing ports; it uses this table to forward frames out ports on the switch. (More information
about mapping follows in the next section, “DLCI Mapping.”)
When configuring your Cisco router to participate in a Frame Relay network, you must configure
a DLCI number for each connection. The Frame Relay provider supplies the DLCI numbers
for your router. If a DLCI is not defined on the link, the switch will discard the frame.
Figure 29.2 shows an example of how DLCIs are assigned to offices in Chicago and Miami.
The Chicago office will communicate through the Frame Relay switch to Miami by using
DLCI 17. Miami will communicate to Chicago by using DLCI 16. Remember that the valid
range of DLCIs is from 16 to 991.
FIGURE 2 9 . 2
Frame Relay PVC configuration
PVC
DLCI = 16 PVC
DLCI = 17
Chicago
Miami
NOTE:
Some providers assign a DLCI in such a way that it appears that the DLCI is
globally significant. For example, all circuits that terminate in Miami could be
assigned the local DLCI 17 at each site. But remember that even though all of
these DLCIs have the same number, they are not the same because DLCIs are
typically only locally significant.
(TDM) is like going to Disneyland. It’s true. Remember how you have to stand in line to get
into Space Mountain? Well, after you get to the loading area, you’re placed in a section with rails
that separate you from the other passengers. You can then get into only the one car that is in front
of you and only when it is empty. Think of the holding area as the interface buffers of a router;
the cars are the time slots on the circuit. When a time slot drives up, you can get in, but not before
that, and not if someone is already in that slot.
Now Stat-TDM is an improvement over straight TDM. Stat-TDM enables you to jump into
a different line if it is not in use and to get into any car. This is a first-come, first-served technology.
Stat-TDM is used with Frame Relay to allow multiple logical data connections (virtual
circuits) over a single physical link. Basically, these circuits give time slots to first-come, firstserved
and priority-based frames over the physical link. Going back to our analogy, you can
think of Frame Relay as the capability to send multiple cars through space on one train, each
car holding a different person.
So, how is each person (data) identified in the car (time slot)? How does the frame switch
know where to send each frame? The answer to this is a
data link connection identifier (DLCI)
.
Because Frame Relay is based on virtual circuits instead of physical ones, DLCIs are used to
identify a virtual circuit and tie it to a physical circuit. This means each frame can be identified
as it traverses the Frame Relay switch and is then sent to the routers at the remote ends.
DLCIs are considered only locally significant, which means that they see the entire virtual circuit
but only up to the point of the Frame Relay switch. The provider is responsible for assigning
DLCIs and their significance to the network.
DLCIs identify the logical virtual circuit between the customer premises equipment (CPE)
and the Frame Relay switch. The switch then maps the DLCIs between each pair of routers in
order to create the PVC. The Frame Relay switch keeps a mapping table of DLCI numbers to
outgoing ports; it uses this table to forward frames out ports on the switch. (More information
about mapping follows in the next section, “DLCI Mapping.”)
When configuring your Cisco router to participate in a Frame Relay network, you must configure
a DLCI number for each connection. The Frame Relay provider supplies the DLCI numbers
for your router. If a DLCI is not defined on the link, the switch will discard the frame.
Figure 29.2 shows an example of how DLCIs are assigned to offices in Chicago and Miami.
The Chicago office will communicate through the Frame Relay switch to Miami by using
DLCI 17. Miami will communicate to Chicago by using DLCI 16. Remember that the valid
range of DLCIs is from 16 to 991.
FIGURE 2 9 . 2
Frame Relay PVC configuration
PVC
DLCI = 16 PVC
DLCI = 17
Chicago
Miami
NOTE:
Some providers assign a DLCI in such a way that it appears that the DLCI is
globally significant. For example, all circuits that terminate in Miami could be
assigned the local DLCI 17 at each site. But remember that even though all of
these DLCIs have the same number, they are not the same because DLCIs are
typically only locally significant.
Permanent Virtual Circuits
Permanent virtual circuits (PVCs)
are dedicated virtual paths through the Frame Relay network
that are up and running 100 percent of the time (well, at least in theory!). Unlike an SVC, a PVC
does not require the call establishment and call teardown phases. However, when the circuit initially
comes up, some parameter negotiations do pass over the wire; these communications
should occur only when the dedicated circuit goes down.
The two phases for PVCs are as follows:
Data exchange
Data is transmitted between two devices, and each device can transmit data as
needed because it doesn’t need to wait for a call to be established to do so. The data exchange
can happen at any time because the virtual connection is permanent and always available.
Idle
The connection is still active, but data is not being transmitted. The idle time can be indefinite:
the circuits will not time out. The idle time keeps the VC up and keeps the line from timing
out when no data is present. This is done by the transmission of idle frames, the sole purpose
of which is to keep line synchronization in the absence of data.
PVCs have gained in popularity as the price for dedicated lines has decreased. They are the
types of links that we will configure later in this chapter.
are dedicated virtual paths through the Frame Relay network
that are up and running 100 percent of the time (well, at least in theory!). Unlike an SVC, a PVC
does not require the call establishment and call teardown phases. However, when the circuit initially
comes up, some parameter negotiations do pass over the wire; these communications
should occur only when the dedicated circuit goes down.
The two phases for PVCs are as follows:
Data exchange
Data is transmitted between two devices, and each device can transmit data as
needed because it doesn’t need to wait for a call to be established to do so. The data exchange
can happen at any time because the virtual connection is permanent and always available.
Idle
The connection is still active, but data is not being transmitted. The idle time can be indefinite:
the circuits will not time out. The idle time keeps the VC up and keeps the line from timing
out when no data is present. This is done by the transmission of idle frames, the sole purpose
of which is to keep line synchronization in the absence of data.
PVCs have gained in popularity as the price for dedicated lines has decreased. They are the
types of links that we will configure later in this chapter.
Switched Virtual Circuits
Switched virtual circuits (SVCs)
provide an economical way to connect to a Frame Relay network.
An SVC is a type of circuit that is brought up only when there is data to send. These circuits provide
temporary connectivity to the network on an as-needed basis. Switched virtual circuits are used with
many technologies—for example, a standard telephone call.
It is rare to find a Frame Relay SVC connection, and indeed, you might never see one. Typically,
PVCs are the only connections used with Frame Relay, although Cisco routers do support
Frame Relay with SVCs.
NOTE: Because they are rarely used, SVCs are not covered further in this book and are
not on the Remote Access exam.
provide an economical way to connect to a Frame Relay network.
An SVC is a type of circuit that is brought up only when there is data to send. These circuits provide
temporary connectivity to the network on an as-needed basis. Switched virtual circuits are used with
many technologies—for example, a standard telephone call.
It is rare to find a Frame Relay SVC connection, and indeed, you might never see one. Typically,
PVCs are the only connections used with Frame Relay, although Cisco routers do support
Frame Relay with SVCs.
NOTE: Because they are rarely used, SVCs are not covered further in this book and are
not on the Remote Access exam.
Frame Relay Virtual Circuits
Frame Relay Virtual Circuits
As mentioned earlier, Frame Relay is a layer 2 (Data Link layer) connection-oriented protocol.
After a connection has been established, end devices can transmit data across the network. This
layer 2 connection across the packet-switched network is called a
virtual circuit
.
The end devices (in this case, routers) will act as
data terminal equipment (DTE), and the
Frame Relay switch will be the data communications equipment (DCE). The difference between
the two is that the DCE device will most likely be responsible for the clocking of the line and
also initiates LMI messages, which we will discuss later in this chapter.
NOTE:Two quick terms you will encounter later:
ingress
refers to Frame Relay frames
from an access device toward the Frame Relay network, and
egress
refers to
Frame Relay frames leaving a Frame Relay network toward the destination device.
From the point-of-view of the router, the virtual circuit is somewhat transparent. This means
that the router sees the virtual circuit, but only up to the Frame Relay switch, which is where
the term
locally significant
originates with regard to the DLCI. In other words, the router speaks
LMI and understands what a DLCI is. This isn’t all that transparent. The transparency comes
in when you consider that the router uses the DLCI like a MAC address for the remote router
to bind the virtual circuit to the protocol address. The previous statement, however, is not a
pure Frame Relay function. In pure Frame Relay terms, the router still has to know how to recognize
the existence of the ingress Frame Relay switch. Even though the circuit might traverse
many switches en route to its destination, the router simply sees its connection to the local
Frame Relay switch, which again is part of the VC.
Figure 29.1 shows how routers see the Frame Relay network. In the figure, notice that Frame
Relay is configured between the routers and the switching office.
FIGURE 2 9 . 1
Frame Relay operation
Frame actually traverses this
CO
PVC
Routers see this
Users only see this User Server
Hub or
switch
Hub or
switch
Router
DLCI 16
CSU/DSU Demarc Demarc CSU/DSU
Router
DLCI 17
There are two ways for Frame Relay to establish this connectivity. Either you can set up
a circuit that is enabled only when needed by using a switched virtual circuit, or you can set
up a dedicated circuit between the local router and remote router by using a permanent virtual
circuit (PVC). Each of these is discussed in more detail next.
As mentioned earlier, Frame Relay is a layer 2 (Data Link layer) connection-oriented protocol.
After a connection has been established, end devices can transmit data across the network. This
layer 2 connection across the packet-switched network is called a
virtual circuit
.
The end devices (in this case, routers) will act as
data terminal equipment (DTE), and the
Frame Relay switch will be the data communications equipment (DCE). The difference between
the two is that the DCE device will most likely be responsible for the clocking of the line and
also initiates LMI messages, which we will discuss later in this chapter.
NOTE:Two quick terms you will encounter later:
ingress
refers to Frame Relay frames
from an access device toward the Frame Relay network, and
egress
refers to
Frame Relay frames leaving a Frame Relay network toward the destination device.
From the point-of-view of the router, the virtual circuit is somewhat transparent. This means
that the router sees the virtual circuit, but only up to the Frame Relay switch, which is where
the term
locally significant
originates with regard to the DLCI. In other words, the router speaks
LMI and understands what a DLCI is. This isn’t all that transparent. The transparency comes
in when you consider that the router uses the DLCI like a MAC address for the remote router
to bind the virtual circuit to the protocol address. The previous statement, however, is not a
pure Frame Relay function. In pure Frame Relay terms, the router still has to know how to recognize
the existence of the ingress Frame Relay switch. Even though the circuit might traverse
many switches en route to its destination, the router simply sees its connection to the local
Frame Relay switch, which again is part of the VC.
Figure 29.1 shows how routers see the Frame Relay network. In the figure, notice that Frame
Relay is configured between the routers and the switching office.
FIGURE 2 9 . 1
Frame Relay operation
Frame actually traverses this
CO
PVC
Routers see this
Users only see this User Server
Hub or
switch
Hub or
switch
Router
DLCI 16
CSU/DSU Demarc Demarc CSU/DSU
Router
DLCI 17
There are two ways for Frame Relay to establish this connectivity. Either you can set up
a circuit that is enabled only when needed by using a switched virtual circuit, or you can set
up a dedicated circuit between the local router and remote router by using a permanent virtual
circuit (PVC). Each of these is discussed in more detail next.
A Brief History of Frame Relay
Currently, Frame Relay is the most prevalent type of packet switching used in North America;
however, Frame Relay’s origin is very humble. Initially, Frame Relay was not even a standard
unto itself; instead, it was an extension of the Integrated Services Digital Network (ISDN) standard.
The International Telecommunications Union-Telecommunications, or ITU-T, (formerly
known as the
Comité Consultatif International de Téléphonique et Télégraphique
, or CCITT)
was the first to define the Frame Relay standard.
Many companies that saw the value of this technology quickly adopted the ITU-T standard
for Frame Relay. After these companies showed interest, ITU-T and other organizations proceeded
to develop the standard, but very slowly. Several corporations saw a need for a more
rapid development and implementation of a Frame Relay standard. Four companies—Digital
Equipment Corporation (DEC), Northern Telecom (Nortel), Cisco, and StrataCom—bound
together to form the
Group of Four
. This group began developing Frame Relay technology
more quickly, which enabled Frame Relay to work on disparate devices. In September 1990, the
Group of Four published
Frame Relay Specifications with Extensions
. This group eventually
became what is currently known as the
Frame Relay Forum
.
however, Frame Relay’s origin is very humble. Initially, Frame Relay was not even a standard
unto itself; instead, it was an extension of the Integrated Services Digital Network (ISDN) standard.
The International Telecommunications Union-Telecommunications, or ITU-T, (formerly
known as the
Comité Consultatif International de Téléphonique et Télégraphique
, or CCITT)
was the first to define the Frame Relay standard.
Many companies that saw the value of this technology quickly adopted the ITU-T standard
for Frame Relay. After these companies showed interest, ITU-T and other organizations proceeded
to develop the standard, but very slowly. Several corporations saw a need for a more
rapid development and implementation of a Frame Relay standard. Four companies—Digital
Equipment Corporation (DEC), Northern Telecom (Nortel), Cisco, and StrataCom—bound
together to form the
Group of Four
. This group began developing Frame Relay technology
more quickly, which enabled Frame Relay to work on disparate devices. In September 1990, the
Group of Four published
Frame Relay Specifications with Extensions
. This group eventually
became what is currently known as the
Frame Relay Forum
.
Understanding Frame Relay
Before we dive right into Frame Relay we need to have a better understanding of what Frame
Relay is, how it is used, and how it came about.
What Is Frame Relay?
Frame Relay
is a telecommunications service designed for cost-efficient data transmission
across a WAN. Frame Relay puts data in a variable-size unit called a
frame
and leaves any
necessary error correction up to the end points. This provides for a high-speed, low-overhead,
efficient network.
Frame Relay is a layer 2 (Data Link layer) connection-oriented protocol that creates virtual circuits
(VCs)—usually permanent virtual circuits (PVCs)—between two end devices such as routers,
through a Frame Relay network. A Frame Relay
bearer service
was defined as a network service
within the framework of ISDN. It was designed to be more efficient and faster than X.25. The
major difference between Frame Relay and traditional ISDN is that in Frame Relay, the control
information needed to keep the link synchronized is not in a separate channel as it is in ISDN, but
instead is included with the data. This single stream of data provides for flow control, congestion
control, and frame routing. Frame Relay is a form of packet switching, whereas ISDN is still considered
circuit switching.
NOTE:You should understand that the error and congestion control works only at the
Data Link layer and that Frame Relay also relies on upper layer protocols and
applications for error correction.
Relay is, how it is used, and how it came about.
What Is Frame Relay?
Frame Relay
is a telecommunications service designed for cost-efficient data transmission
across a WAN. Frame Relay puts data in a variable-size unit called a
frame
and leaves any
necessary error correction up to the end points. This provides for a high-speed, low-overhead,
efficient network.
Frame Relay is a layer 2 (Data Link layer) connection-oriented protocol that creates virtual circuits
(VCs)—usually permanent virtual circuits (PVCs)—between two end devices such as routers,
through a Frame Relay network. A Frame Relay
bearer service
was defined as a network service
within the framework of ISDN. It was designed to be more efficient and faster than X.25. The
major difference between Frame Relay and traditional ISDN is that in Frame Relay, the control
information needed to keep the link synchronized is not in a separate channel as it is in ISDN, but
instead is included with the data. This single stream of data provides for flow control, congestion
control, and frame routing. Frame Relay is a form of packet switching, whereas ISDN is still considered
circuit switching.
NOTE:You should understand that the error and congestion control works only at the
Data Link layer and that Frame Relay also relies on upper layer protocols and
applications for error correction.
Frame Relay Cisco
THE CCNP EXAM TOPICS COVERED IN THIS
CHAPTER INCLUDE THE FOLLOWING:
Describe how different WAN technologies can be used to
provide remote access to a network, including asynchronous
dial-in, Frame Relay, ISDN, cable modem, and DSL.
Describe traffic control methods used to manage traffic flow
on WAN links.
Explain the operation of remote network access control
methods.
Identify PPP components, and explain the use of PPP as an
access and encapsulation method.
Configure Frame Relay operation and traffic control on
WAN links.
Design a Cisco Frame Relay infrastructure to provide access
between remote network components.
Troubleshoot nonfunctional remote access systems.
The use of
packet-switching
protocols has become the most
popular method for moving traffic across a wide area network
(WAN). One particular packet-switching protocol—Frame
Relay—has become the dominant player in the packet-switching market. Other methods of
passing data between routers across the WAN include dedicated lines, time division multiplexing
(TDM), ATM, ISDN, DSL, and others.
NOTE:
Because DSL is so much cheaper and faster than Frame Relay, it could eventually
replace Frame Relay and ISDN as the dominant player in the WAN markets.
As network sizes increase, you should pay particular attention to how DSL is
playing a larger role in network deployment. However, DSL presently has too
many distance limitations to completely replace Frame Relay anytime soon.
Understanding the theory and function of Frame Relay is important for numerous reasons.
Not only is it still tested on Cisco’s Remote Access exam, but when you get a Cisco-related job,
you will most likely see quite a few networks that depend on Frame Relay. Mastery of the information
covered in this chapter will enable you to gain an in-depth understanding of how and
why you would implement Frame Relay on your internetwork. This chapter goes over what
Frame Relay is, the components of Frame Relay, Frame Relay configuration, and how to verify
that Frame Relay is running properly.
CHAPTER INCLUDE THE FOLLOWING:
Describe how different WAN technologies can be used to
provide remote access to a network, including asynchronous
dial-in, Frame Relay, ISDN, cable modem, and DSL.
Describe traffic control methods used to manage traffic flow
on WAN links.
Explain the operation of remote network access control
methods.
Identify PPP components, and explain the use of PPP as an
access and encapsulation method.
Configure Frame Relay operation and traffic control on
WAN links.
Design a Cisco Frame Relay infrastructure to provide access
between remote network components.
Troubleshoot nonfunctional remote access systems.
The use of
packet-switching
protocols has become the most
popular method for moving traffic across a wide area network
(WAN). One particular packet-switching protocol—Frame
Relay—has become the dominant player in the packet-switching market. Other methods of
passing data between routers across the WAN include dedicated lines, time division multiplexing
(TDM), ATM, ISDN, DSL, and others.
NOTE:
Because DSL is so much cheaper and faster than Frame Relay, it could eventually
replace Frame Relay and ISDN as the dominant player in the WAN markets.
As network sizes increase, you should pay particular attention to how DSL is
playing a larger role in network deployment. However, DSL presently has too
many distance limitations to completely replace Frame Relay anytime soon.
Understanding the theory and function of Frame Relay is important for numerous reasons.
Not only is it still tested on Cisco’s Remote Access exam, but when you get a Cisco-related job,
you will most likely see quite a few networks that depend on Frame Relay. Mastery of the information
covered in this chapter will enable you to gain an in-depth understanding of how and
why you would implement Frame Relay on your internetwork. This chapter goes over what
Frame Relay is, the components of Frame Relay, Frame Relay configuration, and how to verify
that Frame Relay is running properly.
Remote Access with Cable Modems and Virtual Private Networks Exam Essentials
Understand how cable modems can be used as part of a remote access solution.
Be able to
compare cable modem technologies to other remote access methods, including DSL. Also
understand the internal characteristics of cable modem, including DOCSIS.
Understand VPN technologies such as IPSec.
Know the differences in various VPN technologies,
including the modes of IPSec and its encryption benefits.
Know how to configure cable modems and IPSec.
Understand the protocols and relationships
between IPSec components, including AH, ESP, and tunnel and transport mode. Knowing how to
configure IPSec can help this, but is not required for the exam.
Be able to
compare cable modem technologies to other remote access methods, including DSL. Also
understand the internal characteristics of cable modem, including DOCSIS.
Understand VPN technologies such as IPSec.
Know the differences in various VPN technologies,
including the modes of IPSec and its encryption benefits.
Know how to configure cable modems and IPSec.
Understand the protocols and relationships
between IPSec components, including AH, ESP, and tunnel and transport mode. Knowing how to
configure IPSec can help this, but is not required for the exam.
Remote Access with Cable Modems and Virtual Private Networks Summary
This chapter examined cable modem technology and presented VPN services, including IPSec.
Cable modems offer the administrator an alternative low-cost technology for remote access,
and they can provide longer-range connections than DSL. Although cable modems use a
shared medium, the overall performance is comparable to the switched DSL in real-world
deployments. The key to cable modem services is DOCSIS and the incorporated security and
other services that this standard provides.
Most remote access users will map IPSec tunnels over the cable modem network to allow
for corporate access. Although not the only VPN technology, IPSec is currently the most
popular and provides for encrypted tunneling of IP data between locations. We also briefly
noted a number of other tunneling technologies that provide solutions for remote access.
Cable modems offer the administrator an alternative low-cost technology for remote access,
and they can provide longer-range connections than DSL. Although cable modems use a
shared medium, the overall performance is comparable to the switched DSL in real-world
deployments. The key to cable modem services is DOCSIS and the incorporated security and
other services that this standard provides.
Most remote access users will map IPSec tunnels over the cable modem network to allow
for corporate access. Although not the only VPN technology, IPSec is currently the most
popular and provides for encrypted tunneling of IP data between locations. We also briefly
noted a number of other tunneling technologies that provide solutions for remote access.
VPN Technologies
Other VPN Technologies
As noted in the introduction to this chapter, VPNs can be composed of any tunneling technology
to varying degrees. Some other VPN technologies include those listed
VPN Technologies
Technology Description
Generic router encapsulation
(GRE)
GRE is not really a private technology because the data is not
encrypted, but it is a tunneling technology, and the data contained
within is somewhat transparent to the overall network.
One common use of GRE is to tunnel IPX or other non-IP traffic
over an IP-only backbone.
Virtual circuit (VC) VCs can be permanent or switched, and are found in Frame Relay
and ATM. Traffic within a VC is not encrypted, but could be considered
a tunnel and can be marketed as a virtual private network.
802.1Q in Q 802.1Q in Q also lacks privacy because the data is not encrypted,
but, like a virtual circuit, data that is tagged in one logical VLAN
is private from other VLANs. The technology for Q in Q is the
same as 802.1Q itself, except for a second .Q header being
added. This second header is controlled by the service provider.
One advantage to this model is that the original customer tag
is not changed. For those familiar with ATM, an analogy is the
virtual path identifier.
L2TP Layer 2 Tunneling Protocol is an extension to PPP, discussed in
Chapter 24, “Point-to-Point Protocol.” L2TP allows for the tunneling
of packets independent of layer 3.
Multi-Protocol Label
Switching (MPLS)
MPLS is quickly gaining as the standard service tagging model.
Many service providers are converting their data networks to
MPLS, which is simply a dynamic tag added to the front of the
packet. Again, the data is not encrypted, but vendors are selling
the service as a managed VPN. In reality, it has little functional
difference when compared to other technologies, except for the
significant benefit that it is transport agnostic. Most other technologies
require a specific set of physical layer technologies.
MPLS can also provide rapid fault detection and correction
compared to other technologies.
IPSec IP Security is a set of protocols that encrypt and authenticate the
integrity of the data between two points.
SSL Secure Sockets Layer is a popular encryption technology used for
many HTTP business transactions (HTTPS). However, the protocol
is not limited to HTTP/HTTPS and is now used for remote control
and other remote access functions, and the protocol can be used
for other services. The most significant advantage of SSL is that
the client requires no preconfiguration and the network is transparent
to the entire flow. Each end station is responsible for
encryption and decryption, and only the payload is protected.
Frame Relay and ATM These PVC-based technologies can create private paths across
the public network. Although not typically thought of in VPN
concepts, they are rightfully included in this list.
As noted in the introduction to this chapter, VPNs can be composed of any tunneling technology
to varying degrees. Some other VPN technologies include those listed
VPN Technologies
Technology Description
Generic router encapsulation
(GRE)
GRE is not really a private technology because the data is not
encrypted, but it is a tunneling technology, and the data contained
within is somewhat transparent to the overall network.
One common use of GRE is to tunnel IPX or other non-IP traffic
over an IP-only backbone.
Virtual circuit (VC) VCs can be permanent or switched, and are found in Frame Relay
and ATM. Traffic within a VC is not encrypted, but could be considered
a tunnel and can be marketed as a virtual private network.
802.1Q in Q 802.1Q in Q also lacks privacy because the data is not encrypted,
but, like a virtual circuit, data that is tagged in one logical VLAN
is private from other VLANs. The technology for Q in Q is the
same as 802.1Q itself, except for a second .Q header being
added. This second header is controlled by the service provider.
One advantage to this model is that the original customer tag
is not changed. For those familiar with ATM, an analogy is the
virtual path identifier.
L2TP Layer 2 Tunneling Protocol is an extension to PPP, discussed in
Chapter 24, “Point-to-Point Protocol.” L2TP allows for the tunneling
of packets independent of layer 3.
Multi-Protocol Label
Switching (MPLS)
MPLS is quickly gaining as the standard service tagging model.
Many service providers are converting their data networks to
MPLS, which is simply a dynamic tag added to the front of the
packet. Again, the data is not encrypted, but vendors are selling
the service as a managed VPN. In reality, it has little functional
difference when compared to other technologies, except for the
significant benefit that it is transport agnostic. Most other technologies
require a specific set of physical layer technologies.
MPLS can also provide rapid fault detection and correction
compared to other technologies.
IPSec IP Security is a set of protocols that encrypt and authenticate the
integrity of the data between two points.
SSL Secure Sockets Layer is a popular encryption technology used for
many HTTP business transactions (HTTPS). However, the protocol
is not limited to HTTP/HTTPS and is now used for remote control
and other remote access functions, and the protocol can be used
for other services. The most significant advantage of SSL is that
the client requires no preconfiguration and the network is transparent
to the entire flow. Each end station is responsible for
encryption and decryption, and only the payload is protected.
Frame Relay and ATM These PVC-based technologies can create private paths across
the public network. Although not typically thought of in VPN
concepts, they are rightfully included in this list.
Commands Used for IPSec Command Function crypto isakmp policy 10
This command creates an IKE process on the router. You
must have an IOS version that supports the IPSec feature set.
The priority number can be anything from 1 to 10,000, and 1
is the highest priority. As with other elements such as route
maps, the convention is to start with 10 and increment by 10
to allow for future changes. You are now in ISAKMP policy
configuration command mode.
hash md 5
This command specifies that you will use a preshared key
and the MD5 hash algorithm for packet authentication. It is
possible to configure a key dynamically using RSA public
key signatures, but that requires a certificate server and
other infrastructure.
group 2
This parameter is generally set to 2 to reflect the Diffie-
Hellman group number to use for key negotiation. Group 1
uses a 768-bit key exchange, and group 2 uses 1,024 bits. A
complete list of the group numbers and their related parameters
is available at
www.cisco.com/en/US/customer/
products/hw/vpndevc/ps2286/products_user_guide_
chapter09186a008015d00c.html
.
lifetime 3600
The
lifetime
parameter defines how long a security association
will last. It is defined in seconds and can range from
one minute to one day. A value of 3,600 seconds is equal
to one hour. Longer lifetimes might compromise security
but can reduce overhead.
crypto isakmp key tyler
address 10.1.1.1
This configuration command defines the key to be used and
the IP address of the far-end Ethernet segment that services
as the termination of the tunnel. In this instance, the key is
tyler and the IP address is 10.1.1.1. This key will be defined on
both routers, is case-sensitive, and can be up to 128 characters
long. Security can be enhanced by using longer keys
with alphanumeric characters.
crypto IPSec transform-set
tunnel-A ah-md5-hmac esp-des
This command defines the transforms that will be used. This
command defines AH (MD5) and ESP (56-des), but other
combinations might include specifying triple DES or LZS
compression. Depending on the choices selected, the administrator
can select up to three transforms. IOS will prevent
incompatible values.
crypto map map-A localaddress
Ethernet0
Here we define a crypto-map called map-A. It is bound to
the Ethernet 0 interface; recall that we are going to create a
tunnel from one Ethernet interface to another.
crypto map map-A 10 ipsecisakmp
This command enters crypto-map configuration mode with a
map numbered 10. Again, this is a definable value.
set peer 10.1.1.1
Here we set the peer by again defining the IP address of the
remote. This is for the map and not the key, but it would be
nice if Cisco would simplify this relationship.
set transform-set tunnel-A
This command links the map to the transform set previously
defined.
match address 110
This defines the ACL to be used in determining what traffic is
encrypted. Please note that ACLs 100 through 102 are reserved
for use by the DOCSIS configuration file and should not be
used with cable modems.
interface Ethernet0
This selects the Ethernet interface.
ip address 10.1.2.1
255.255.255.0
This defines the local IP address of 10.1.2.1/24.
interface cable-modem0
This selects the cable modem interface.
crypto map map-A
This defines that crypto-map map-A is to be used.
access-list 110 permit ip
10.1.2.0 0.0.0.255 10.1.1.0
0.0.0.255
This defines access list 110, which was assigned to
tunnel-A. This defines that all traffic destined for 10.1.1/24
from 10.1.2/24 should be encrypted. Remember that this
uses wildcard mask rules.
That’s it. Of course, a real configuration would also need routing and other parameters to
be defined. The cable modem would also require an IP address. The opposing router would
require a comparable configuration as well to establish the tunnel.
must have an IOS version that supports the IPSec feature set.
The priority number can be anything from 1 to 10,000, and 1
is the highest priority. As with other elements such as route
maps, the convention is to start with 10 and increment by 10
to allow for future changes. You are now in ISAKMP policy
configuration command mode.
hash md 5
This command specifies that you will use a preshared key
and the MD5 hash algorithm for packet authentication. It is
possible to configure a key dynamically using RSA public
key signatures, but that requires a certificate server and
other infrastructure.
group 2
This parameter is generally set to 2 to reflect the Diffie-
Hellman group number to use for key negotiation. Group 1
uses a 768-bit key exchange, and group 2 uses 1,024 bits. A
complete list of the group numbers and their related parameters
is available at
www.cisco.com/en/US/customer/
products/hw/vpndevc/ps2286/products_user_guide_
chapter09186a008015d00c.html
.
lifetime 3600
The
lifetime
parameter defines how long a security association
will last. It is defined in seconds and can range from
one minute to one day. A value of 3,600 seconds is equal
to one hour. Longer lifetimes might compromise security
but can reduce overhead.
crypto isakmp key tyler
address 10.1.1.1
This configuration command defines the key to be used and
the IP address of the far-end Ethernet segment that services
as the termination of the tunnel. In this instance, the key is
tyler and the IP address is 10.1.1.1. This key will be defined on
both routers, is case-sensitive, and can be up to 128 characters
long. Security can be enhanced by using longer keys
with alphanumeric characters.
crypto IPSec transform-set
tunnel-A ah-md5-hmac esp-des
This command defines the transforms that will be used. This
command defines AH (MD5) and ESP (56-des), but other
combinations might include specifying triple DES or LZS
compression. Depending on the choices selected, the administrator
can select up to three transforms. IOS will prevent
incompatible values.
crypto map map-A localaddress
Ethernet0
Here we define a crypto-map called map-A. It is bound to
the Ethernet 0 interface; recall that we are going to create a
tunnel from one Ethernet interface to another.
crypto map map-A 10 ipsecisakmp
This command enters crypto-map configuration mode with a
map numbered 10. Again, this is a definable value.
set peer 10.1.1.1
Here we set the peer by again defining the IP address of the
remote. This is for the map and not the key, but it would be
nice if Cisco would simplify this relationship.
set transform-set tunnel-A
This command links the map to the transform set previously
defined.
match address 110
This defines the ACL to be used in determining what traffic is
encrypted. Please note that ACLs 100 through 102 are reserved
for use by the DOCSIS configuration file and should not be
used with cable modems.
interface Ethernet0
This selects the Ethernet interface.
ip address 10.1.2.1
255.255.255.0
This defines the local IP address of 10.1.2.1/24.
interface cable-modem0
This selects the cable modem interface.
crypto map map-A
This defines that crypto-map map-A is to be used.
access-list 110 permit ip
10.1.2.0 0.0.0.255 10.1.1.0
0.0.0.255
This defines access list 110, which was assigned to
tunnel-A. This defines that all traffic destined for 10.1.1/24
from 10.1.2/24 should be encrypted. Remember that this
uses wildcard mask rules.
That’s it. Of course, a real configuration would also need routing and other parameters to
be defined. The cable modem would also require an IP address. The opposing router would
require a comparable configuration as well to establish the tunnel.
IPSec Configuration
Cisco could have made configuration of IPSec a little easier than they did, but unfortunately
they didn’t. This section defines a common IPSec configuration and illustrates some of the
options available to the administrator, including the use of Data Encryption Standard (DES) or
3DES. The code sample in Table 28.3 is the basis for our configuration.
Subscribe to:
Posts (Atom)