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