IP+Forwarding+and+Frame+Relay

Two types of routing optimization: fast-switching and CEFtoc


 * Process Switching**: The normal process a router uses to forward a packet. Basically, checking the FCS, stripping the Data Link header, (If IP packet) looking up the destination in the routing table and then rebuilding a new Data Link Frame and checksum.


 * Fast-Switching:** In this method, the first packet is process switched. The data link header used is added to the route cache, and then all future packets going to the same designation use the cached Data Link header to speed up the process of forwarding. The downsides to this are that the cache entires time out quickly to avoid resource usage, and packets can only be load balanced per destination.


 * Cisco Express Forwarding**: Uses the Forwarding Information Base, which contains information about all known routes in the routing table. The differences are that information is added to the FIB when new routes appears in the routing table instead of when a new destination appears. This means that the first packet does not need to be process switched, the routes dont have to time out and load balancing can be based on equal cost paths. The command //**#ip cef**// is used to enable, and //**#no ip route-cache cef**// can be used to disable per interface.

=Policy Routing=

Allows routers to make forwarding decision on information other than the destination address. Interfaces using this logic must have the //**#ip policy route-map **// command configured on the policy routed interfaces. Uses the set ip next hope option inside of a route-map. To configure local policy routing, define the route-map with the //**#ip local policy route-map **// command. = = =Frame Relay=


 * DLCI**: Data Link Connection Identifier. Locally significant.

Local Management Interface
Manages the link between the router and the frame relay switch. Most common message is the LMI Status Enquiry (Router) and Status (FR Switch) messages, flowing every 10 seconds, it details the DLCIs available and the status of each VC. Every 6th message is a full status message with more detail. These messages also function as keepalives for the link. The link is considered dead after 3 keepalive intervals of 10 seconds. LMI is enabled on an interface via the //**#keepalive**// command and disabled via //**#no keepalive.**//

There are 3 types of LMI. These are normally auto-negotiated but can be set with //**#frame-relay lmi-type type **//

Frame relay contains two types of headers, the LAPF header which contains all the information needed to get the message across the link (DLCI, BECN, FECN, DE) and the encapsulation header. FR also supports two types of encapsulation: **cisco** and **ietf**. There are nearly identical. This can be configured per VC or globally wit h the commands //**#encapsulation frame-relay **// or //**#frame-relay interface-dlci **// (Can also configure with the frame-relay map command).

Congestion management
Forward/Backward Explicit Congestion Notification is used to control congestion on a FR link. When a FRS notices that a link is congested, it sets the FECN and then tracks the the VC for other messages. When a return message it sent, it sets the BECN. The router that receives the BECN now knows that is it sending packets on a congested link and reduces its speed. FECN bits can only be set by a FRS. However, BECN bits can be set by routers. The routers can be configured to detect a FECN bit and respond by sending a Q922a test frame with the BECN bit set. Configured with //**#shape fecn-adapt**// or //**#traffic-shape fecn-adapt**//.

Discard Eligibility
Switches can, but are not required, to examine the DE bit to decide if a packet should be tail dropped. Routers are typically the ones to set DE bits, but they can be set by switches as well.

DLCI Mapping
The most important configuration for a frame relay links are:

Mapping the DLCI to a interface: //**#frame-relay interface-dlci**// Mapping the DLCI to a Layer3 address: //**#frame-relay map**//

When mapping an interface to a DLCI and using LMI, any DLCIs learned via LMI that are not associated with a subinterface are assumed to be associated with the physical interface on which the DLCI was detected. On point-to-point sub interfaces, only a single DLCI is allowed. The alternative to this is mapping a layer 3 address to a DLCI, which also associates the interface using that address with the DLCI. As with the interface-dlci command, only one map is allowed per point-to-point interface. However, map commands are usually not needed on a PP subinterface.


 * Inverse ARP:** Used to discover the IP address associated with a specific DLCI. This is trigged by an LMI status message. When a PVC comes up, each router announces its IP address over the VC. If LMI is disabled, InARP will not work because there is nothing to trigger the sending of the message. This can be disabled using the command //**#no frame-relay inverse-arp**//. This command will tell the router to stop sending and to ignore all InARP messages. InARP cannot be disabled on point-to-point subinterfaces because it just ignores them anyway.

When configuration a back-back frame relay setup, the same DLCI is used and no interface-dlci is defined.

Payload Compression
Three types of compression are supported: packet-by-packet, data stream and Frame Relay Forum (FRF9). Of these 3, only FRF9 is standardized. FRF9 and data stream function in basically the same way.

Compression is configured per VC. On point-to-point sub interfaces the command //**#frame-relay payload-compress **// is used. On all other types the //**#frame-relay map**// command with the //**payload-compress **// option is used.

Header compression can be enabled under the //**#frame-relay ip**// command or as part of the //**#frame-relay map ip**// command

Fragmentation
FRF.12 defines the standard for performing LFI over a frame relay VC. Packets leaving a FRTS LLQ go into High dual FIFO queue, and all other queued packets go into a normal queue. The dual FIFO high queue is treated as a priority queue in IOS. Fragmentation is configured with the #frame-relay fragment command and must be configured the same on both ends for it to work properly.

FRF.11-c can also be used for Voice over Frame Relay VCs. In this method, voice packets are never fragmented but are always interleaved. Once a VoFR VC is configured, the LFI configuration is identical to FRF.12.

map-class
Class maps are defined with the //**#map-class frame-relay**// command. This allows you to set custom parameters such as timers. They are applied to the interface with //**#frame-relay class **//. You can also apply class maps to specific DLCIs under the //**#frame-relay interface-dlci**// command.

PPP over Frame Relay
PPP over frame relay allows additional configuration, such as authentication, that is not normally supported by the FR headers. To do this, you must first configure virtual-template interfaces. There is where you configure all of the PPP related settings.

//**#interface virtual-template 1**//

The Virtual template interfaces can then be applied to the frame-relay configuration with the following command:

//**#frame-relay interface-dlci 105 ppp Virtual-Template1**//

**Bridging over Frame Relay**
//**interface FastEthernet0/0**// //**bridge-group 1**// //**!**// //**interface Serial0/0**// //**encapsulation frame-relay**// //**frame-relay map bridge 205 broadcast**// //**bridge-group 1**// //**!**// //**bridge 1 protocol ieee**//

**Setting up a Frame Relay Switch**
Setting up a frame relay switch on a normal device requires you to first tell the device what role it will play:

//**#frame-relay switching**//

Then tell each interface attached to a client device to act as a DCE type interface:

//**#frame-relay intf-type dce**//

Since DLCIs often need to be switched to another interface, you need to connect the two interfaces to allow this:

//**#connect R1_R2 Serial 1/2 132 Serial 1/3 231**// =PPP=

LEARN ABOUT PPP