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.
IT Certification CCIE,CCNP,CCIP,CCNA,CCSP,Cisco Network Optimization and Security Tips
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.
Subscribe to:
Posts (Atom)