[ LiB ]

Frame Relay Subinterfaces

To support a partially meshed Frame Relay network, you should use Cisco IOS's subinterface capabilities. Most protocols in use today need to believe that they have transitivity on a logical network. They assume that if Station A can talk to Station B, and Station B can talk to Station C, Station A should be able to talk directly to Station C. Although this concept of transitivity is mostly true on LANs, it is not true on a Frame Relay network unless Station A is directly connected to Station C.

One other item that certain protocols have an issue with on partially meshed networks, such as AppleTalk and transparent bridging, is split horizon. Split horizon states that when a packet is received on an interface, it cannot be sent out the same interface, even if it is received and transmitted on different VCs.

Frame Relay uses subinterfaces to overcome the issues raised by split horizon by ensuring that a single physical interface is treated as multiple virtual interfaces.

Virtual interfaces are seen as being separate from other virtual interfaces. This allows packets that are received on one virtual interface to be forwarded out another virtual interface, even if the virtual interfaces are configured on the same physical interface.

Subinterfaces also address the limitations of Frame Relay networks by giving you a way to subdivide your partially meshed Frame Relay network into a number of smaller, fully meshed (or point-to-point) subnetworks. You assign each subnetwork its own network numbers, making it appear to the protocols as if these networks can be reached through a separate interface. If you have transparent bridging in your networking environment, each subinterface is viewed as a separate bridge port.

Subinterface Addressing

When you use point-to-point subinterfaces, the destination is identified or implied by the use of the frame-relay interface-dlci command. When you use multipoint subinterfaces, the destinations can be dynamically resolved through the use of Frame Relay Inverse ARP or can be statically mapped through the use of the frame-relay map command.

Addressing on Point-to-Point Subinterfaces

You can use the following command to address a point-to-point subinterface:

R2(config-subif)#frame-relay interface-dlci dlci

Inverse ARP on Multipoint Subinterfaces

Inverse ARP provides dynamic address mapping for Frame Relay. Inverse ARP sends a request to map the next-hop protocol address for a specific connection given a DLCI. Responses to the Inverse ARP request are entered in an address-to-DLCI mapping table on the FRAD. The table entries are then used to supply the next-hop protocol address or the DLCI for outgoing traffic.

Because you now have a physical interface that is logically divided into multiple subinterfaces, you must provide information so that a specific subinterface can be distinguished from the physical interface and can be associated with a specific DLCI.

You can use the following command to accomplish this task:

R2(config-if)#frame-relay interface-dlci dlci

Inverse ARP is enabled by default for all the protocols it supports, but you can disable it for specific protocol-DLCI pairs. Because of this option, you can use dynamic mapping for some protocols and static mapping for others on the same DLCI. You can also explicitly disable Inverse ARP for a protocol-DLCI pair if you know that the protocol is not supported on the other end of the connection.

Static Address Mapping on Multipoint Subinterfaces

You can use a static map to link a specified next-hop protocol address to a specified DLCI. When you use static mapping, inverse ARP is automatically disabled for the specified protocol on the specified DLCI.

You are required to use static mapping if the router at the other end either does not support inverse ARP or does not support inverse ARP for a specific protocol you want to use.

You can use the following commands to establish static mapping according to your network needs:

R2(config-if)#frame-relay map protocol protocol-address dlci [broadcast] [ietf]
  [cisco]
R2(config-if)#frame-relay map clns dlci [broadcast]
R2(config-if)#frame-relay map bridge dlci [broadcast] [ietf]

Table 9-2 lists the supported protocols and their corresponding keywords.

Table 9-2. Supported Protocols for Static Mapping

Supported Protocol	Corresponding Keyword
IP	ip
DECnet	decnet
AppleTalk	appletalk
XNS	xns
Novell IPX	ipx
VINES	vines
ISO CLNS	clns

You must use the broadcast keyword for routing protocols such as OSI protocols and the Open Shortest Path First (OSPF) protocol.

Configuring a Backup Interface for a Subinterface

You can use a backup interface with both a point-to-point subinterface and a multipoint Frame Relay subinterface. This allows individual PVCs to be backed up in case of failure rather than depending on the entire Frame Relay connection to fail before any redundancy takes over. You can configure a subinterface for backup on failure only, not for backup based on loading of the line.

Any backup interface you configure for the main interface has precedence over any subinterface backup interface you have configured when a complete loss of connectivity is experienced. Because of this, a subinterface backup is activated only if the main interface is up or if it is down and does not have a backup interface defined. If a subinterface fails while the backup interface is in use, and the main interface goes down, the backup subinterface remains connected.

You can use the following commands to configure a backup interface for a Frame Relay subinterface:

R2(config)#backup interface type number
R2(config-if)#backup delay enable-delay disable-delay

[ LiB ]