Lab 1 Frame Relay

Document Sample
Lab 1 Frame Relay Powered By Docstoc
					CCNA4: WAN Technologies – Frame Relay                                             RCNA FIIIIIT STU BA
                                                                                  RCNA F IT STU BA
                                                                                  RCNA F T STU BA


A) Frame Relay operation summary

Potential Bandwidth Sharing
Frame Relay uses variable-length packets for more efficient and flexible transfers. These packets
are then switched between the various network segments (usually phone company Central
Offices or COs) until the destination is reached. Statistical multiplexing techniques control
network access in a packet-switched network. The advantage of this technique is that it
accommodates more flexibility and more efficient use of bandwidth especially between switches
within the cloud. Statistical multiplexing dynamically allocates bandwidth to active channels. If
RTA has no packets to send RTB, RTA can use all the available bandwidth to communicate with
RTC. Statistical multiplexing contrasts with time-division multiplexing (TDM). TDM is typically
used over dedicated circuits (leased lines). Using TDM, information from multiple channels can be
allocated bandwidth on a single wire based on preassigned time slots. Unfortunately, TDM
allocates bandwidth to each channel regardless of whether the station has data to transmit or
not. Frame Relay is a way of sharing existing T1 and T3 lines owned by service providers and
potentially getting better use from them. Most telephone companies now provide Frame Relay
service for customers who want connections at 56 Kbps to T1 speeds.

Virtual Circuits




Frame Relay provides connection-oriented data link layer communication. This means that a
defined communication exists between each pair of devices and that these connections are
associated with a connection identifier. This service is implemented by using a Frame Relay
virtual circuit, which is a logical connection created between two data terminal equipment (DTE)
devices across a Frame Relay packet-switched network (PSN). Virtual circuits provide a bi-
directional communication path from one DTE device to another. Each end of the virtual circuit is
assigned a Data-Link Connection Identifier (DLCI), which references the point between the DCE
and the Frame Relay switch to which the router is connected.
DLCIs have local significance. Locally significant DLCI does not reference the other end of the
PVC. In other words, two DTE devices connected by a virtual circuit may use a different DLCI
value to refer to the same connection. For example, PVC linking RTA and RTC is defined by DLCI
16 between RTA and its directly connected switch (see the figure). DLCI 20 on RTC's side of the
connection defines the same PVC. Meanwhile, RTA uses DLCI 17 to reference the PVC that
connects it with RTB. The service provider's switching equipment maintains a table that maps
DLCIs to outbound ports. When a frame is received, the Frame Relay switch analyzes the
connection identifier and delivers the frame to the appropriate outbound port.
Number of virtual circuits can be multiplexed into a single physical circuit for transmission across
the network. This capability often can reduce the equipment and network complexity required to
connect multiple DTE devices. A virtual circuit can pass through any number of intermediate DCE
devices (switches) located within the Frame Relay PSN (Packet Switched Network) or cloud.
Frame Relay virtual circuits fall into two categories: Switched Virtual Circuits (SVCs) and


                                            LAB3 - 1 -
CCNA4: WAN Technologies – Frame Relay                                                               RCNA FIIIIIT STU BA
                                                                                                    RCNA F IT STU BA
                                                                                                    RCNA F T STU BA
Permanent Virtual Circuits (PVCs). PVCs are the most common and are permanently established
connections that are used when there is frequent and consistent data transfer between DTE
devices across a Frame Relay network. SVCs are temporary connections, used when there is only
sporadic data transfer between DTE devices across the Frame Relay network. Because they are
temporary, SVC connections require call setup and termination for each connection. Cisco IOS
release 11.2 or later supports Frame Relay SVCs. Also you will need to find out whether your
carrier supports SVCs before implementing them, since many Frame Relay providers only support
PVCs.

Frame Relay and Inverse-ARP operation

1.) Order Frame Relay service from a service provider, or create a private Frame Relay cloud.
Connect each router, either directly or through CSU/DSU, to the Frame Relay switch.

2.) When the CPE router is enabled, it sends LMI Status Inquiry message to the Frame Relay
switch, notifying the switch of the router's status and asking the switch for the connection status
of other remote routers.

Note: There are three types of LMI: cisco, ansi, q933a. Different types use different reserved DLCI to communicate with
Frame Relay switch – ansi and q933a LMI uses DLCI 0, cisco LMI uses DLCI 1023. LMI messages are carried in a variant
of LAPF frames. This variant includes four extra fields in the header so that they will be compatible with the LAPD frames
used in ISDN. The address field carries one of the reserved DLCIs. Following this are the control, protocol discriminator,
and call reference fields that do not change. The fourth field indicates the LMI message type. Since IOS v11.2 LMI type is
auto-sensed.

3.) When the Frame Relay switch receives the request, it responds with LMI Status message that
includes DLCIs of all configured virtual circuits which the local router can use to send data.

4.) For each active DLCI, router sends an Inverse ARP request packet, introducing itself and
asking for each remote router to identify itself by replying with its network-layer address.

5.) For every DLCI that the router learns about through an Inverse ARP message, map entry is
created in the router's Frame Relay map table. This includes the local DLCI, the remote router's
network-layer address, as well as the state of the connection. Note that the DLCI is the router's
locally configured DLCI, not the DLCI that the remote router is using. Three possible connection
states appear in the Frame Relay map table:
- active - connection is active and routers can exchange data
- inactive – local connection to Frame Relay switch is working, but remote router's connection to
Frame Relay switch is not working
- deleted - no LMI is being received from the Frame Relay switch or no service between the CPE
router and Frame Relay switch is occurring

6.) Every 60 seconds routers exchange Inverse ARP messages. By default every 10 seconds the
CPE router sends a keepalive message to the Frame Relay switch to verify it is still active.


B) Must read information about Frame Relay:

http://www.cisco.com/warp/public/116/fr_faq.html




                                                      LAB3 - 2 -
CCNA4: WAN Technologies – Frame Relay          RCNA FIIIIIT STU BA
                                               RCNA F IT STU BA
                                               RCNA F T STU BA


LAB 7: Frame Relay scenario

SET1:




SET2:




                                  LAB3 - 3 -
CCNA4: WAN Technologies – Frame Relay                                          RCNA FIIIIIT STU BA
                                                                               RCNA F IT STU BA
                                                                               RCNA F T STU BA

Step 1 – Multipoint Frame Relay with Inverse-ARP enabled and no subinterfaces

Cables connected to the middle router (FRswitch) must be DCE in order to have this router
simulate the Frame Relay switch. Configure RIP or EIGRP as a routing protocol.

Frame Relay switch will be configured for you by the instructor.

Verify the Frame Relay switch table has correct mapping of DLCIs using:

        FRSwitch# show frame-relay route


By default serial interface is treated as multipoint and Inverse-ARP is allowed. Our Frame Relay
HUB router will be configured according to the following:

        HUB(config)# int serial 0
        HUB(config-if)# encapsulation frame-relay ietf
        HUB(config-if)# frame-relay interface-dlci 100
        HUB(config-fr-dlci)# frame-relay interface-dlci 101
        HUB(config-fr-dlci)# frame-relay interface-dlci 102
        HUB(config-fr-dlci)# ip address 192.168.255.1 255.255.255.0
        HUB(config-if)# no shutdown

Spoke1 router will be configured using:

        Spoke1(config)# interface serial 0
        Spoke1(config-if)# encapsulation frame-relay ietf
        Spoke1(config-if)# frame-relay interface-dlci 102
        Spoke1(config-fr-dlci)# ip address 192.168.255.2 255.255.255.0
        Spoke1(config-if)# no shutdown

Finish the configuration on Spoke2 and Spoke3 routers.


Step 2 - Confirm the FR configuration of serial interfaces

Use the command show interface serial0 to answer the following questions.
What is the status of the Frame Relay link?



What is the encapsulation set to? What different types of Frame Relay encapsulation are
supported by Cisco routers?



What is the LMI type and LMI DLCI number? What different types of LMI are supported by Cisco
routers? Is it required to manually configure LMI on router?




                                            LAB3 - 4 -
CCNA4: WAN Technologies – Frame Relay                                            RCNA FIIIIIT STU BA
                                                                                 RCNA F IT STU BA
                                                                                 RCNA F T STU BA


Step 3 - Verify the status of Frame Relay PVCs on the switch and all routers

Use command show frame-relay pvc to answer following questions.
What is the DLCI and status of your PVC? What other states can PVC change to?




Check the DLCI numbers of all connections. By comparing outputs of DCE and DTE devices, how
can we interpret the meaning of DLCI usage?

        Unused
        Local
        Switched


Turn on LMI debugging on all routers via command debug frame-relay lmi. Use the produced
output (entered on all routers and Frame Relay switch) to answer following questions.
What is the status of all PVCs? And their status codes?



Now, disconnect the cable from the serial interface on all Spoke routers, that connects them to
FR switch. Wait until the interface goes down and enter the command show frame-relay pvc
again on all Spoke routers. How did the PVC status changed? And the status code?



Now check the PVC status on HUB router. What is the output? And the status code?



Before continuing, restore the serial interfaces to their functional state.

Check the Frame Relay map on all routers using the command show frame-relay map and
answer following questions.
How was the entry learned?



IP addresses shown identify which routers? And DLCIs shown identify which PVCs?


Are broadcasts/multicasts supported over this PVC?


On all routers issue the command debug frame-relay packet from privileged exec mode. From
Spoke routers, ping the serial interface of HUB router. While watching the output you should
notice the ping is successful. However if you try to ping from one Spoke router to another, it will
not work. Why?



                                              LAB3 - 5 -
CCNA4: WAN Technologies – Frame Relay                                            RCNA FIIIIIT STU BA
                                                                                 RCNA F IT STU BA
                                                                                 RCNA F T STU BA


You may use the command debug frame-relay events to see Inverse-ARP packet processing
in real time. Now, check the LMI status on all devices using the command show frame lmi.
What is the LMI type used? What other command can also be used to find out LMI type?




Step 4 - Verify the network connectivity

For testing the remote network connectivity between Spoke routers, you must use extended
ping, otherwise the ping replies will not come back. Can you tell why?




Are you able to reach remote networks from each router?




One more thing to point out is split-horizon problem with distance-vector routing protocols.
Split-horizon reduce routing loops by not allowing a routing update received on one interface to
be forwarded out the same interface. This is a problem if one interface (or multipoint
subinterface) is used to connect to multiple Frame Relay virtual circuits. If you look into picture
on next page, you see that router HUB has a single physical interface serving three Frame Relay
PVCs. If you will not disable split horizon on HUB’s interface (or multipoint subinterface in next
step), routing updates coming from Spoke routers will not be forwarded to other Spoke routers
and vice versa. Two notes for disabling split-horizon:

    1.) Split-horizon does not apply to link-state algorithms
    2.) Split-horizon needs to be turned off only on HUB router


Step 5 – Multipoint subinterfaces with inverse-ARP disabled

Now assume that inverse-ARP function is not supported. Your task is to configure our Frame
Relay topology using static mappings. Inverse-ARP is automatically disabled for protocol specified
via static map. Return serial interfaces on HUB and Spoke routers to their default state using
following commands (don’t do this on FRSwitch!):

        Router(config)# default int serial0
        Router(config)# int s0
        Router(config-if)# shutdown

Then configure your routers using following commands:

        HUB(config)# int serial0
        HUB(config-if)# no ip address
        HUB(config-if)# encapsulation frame-relay ietf
        HUB(config-if)# int serial0.100 multipoint
        HUB(config-subif)# ip address 192.168.255.1 255.255.255.0


                                            LAB3 - 6 -
CCNA4: WAN Technologies – Frame Relay                                         RCNA FIIIIIT STU BA
                                                                              RCNA F IT STU BA
                                                                              RCNA F T STU BA


       HUB(config-subif)#       frame-relay map ip 192.168.255.2 100 broadcast
       HUB(config-subif)#       frame-relay map ip 192.168.255.3 101 broadcast
       HUB(config-subif)#       frame-relay map ip 192.168.255.4 102 broadcast
       HUB(config-subif)#       int serial0
       HUB(config-if)# no       shutdown

       Finish the configuration on Spoke1, Spoke2 and Spoke3 routers.

After you are done, verify your configuration using sh frame pvc and sh frame map. Does
your PVC support broadcasts or not?



If not, routing protocols will not exchange routing updates over the Frame Relay cloud. Why? Do
you remember how routing protocols exchange routing updates?

       RIPv1, IGRP – broadcast 255.255.255.255
       RIPv2 – multicast 224.0.0.9
       EIGRP – multicast 224.0.0.10
       OSPF – multicast 224.0.0.5 (all OSPF routers), 224.0.0.6 (all OSPF DRs)

Frame Relay is by default NBMA (NonBroadcast Multiple Access) topology. In OSPF configuration,
you have to manually select your DR and BDR with ip ospf priority interface configuration
command, because on NBMA topologies OSPF elects DR and BDR.

Do you see the routes? Are you able to ping now?




Step 6 – OSPF over Frame Relay

Remove previous routing protocol from your configuration and configure OSPF. Don’t forget to
include all networks. Using the command show ip ospf neighbors fill in the table bellow:

                         HUB               Spoke1            Spoke2            Spoke3
       HUB

       Spoke1

       Spoke2

       Spoke3


Because Frame Relay is Multiaccess topology for OSPF, DR/BDR election is held but poses a
problem. Suppose that Spoke3 router becomes a DR – how will Spoke1 and Spoke2 send LSA
packets to him? To solve DR/BDR election problem, configure following on all router
subinterfaces:

       Router(config-subif)# ip ospf network point-to-multipoint



                                          LAB3 - 7 -
CCNA4: WAN Technologies – Frame Relay                                            RCNA FIIIIIT STU BA
                                                                                 RCNA F IT STU BA
                                                                                 RCNA F T STU BA


Test the configuration on each router by checking that your OSPF neighbors are in FULL state
and by pinging to remote networks. If you look at routing tables, you will notice that with OSPF
running in point-to-multipoint mode you don’t need to use extended ping, as it was needed with
RIP and EIGRP, when pinging between Spoke routers.


Step 7 – Point-to-point Frame Relay subinterfaces

        In a point-to-point environment, each subinterface is acting like a point-to-point
interface, being in its own subnet and having a single DLCI. Routing update traffic is not subject
to the split-horizon rule, broadcasts/multicasts are not a problem because the links are point-to-
point (act like a leased line) and OSPF DR/BDR election is not held on point-to-point networks.
        Disadvantage of point-to-point subinterfaces is that each PVC require its own subnet,
which can waste IP addresses.

        To change our multipoint subinterfaces to point-to-point, you need to do:
        1.) delete the existing subinterface (no interface commnad)
        2.) save your configuration to NVRAM (wr mem)
        3.) reload the router and finish the configuration

When a subinterface is configured, an interface descriptor block (IDB) is defined by the Cisco
IOS. IDBs defined for subinterfaces cannot be changed without a reload. Subinterfaces that are
deleted with the no interface command are shown as deleted by issuing the show ip
interface brief or show protocol command. After you have deleted existing subinterfaces
using the no interface command, finish the Frame Relay configuration using:

        HUB(config)# int serial0.100 point-to-point
        HUB(config-subif)# ip address 192.168.255.1 255.255.255.252
        HUB(config-subif)# frame-relay interface-dlci 100

        HUB(config-subif)# int serial0.101 point-to-point
        HUB(config-subif)# ip address 192.168.255.5 255.255.255.252
        HUB(config-subif)# frame-relay interface-dlci 101

        HUB(config-subif)# int serial0.102 point-to-point
        HUB(config-subif)# ip address 192.168.255.9 255.255.255.252
        HUB(config-subif)# frame-relay interface-dlci 102

Finish the Frame Relay configuration for Spoke routers. Use following IP addresses for FR
subinterfaces:

Spoke1 – 192.168.255.2/30       Spoke2 – 192.168.255.6/30       Spoke3 – 192.168.255.10/30


After you are done, verify your configuration on all routers using sh frame pvc and sh frame
map. Does your PVC support broadcasts or not?
                                                        Yes

Verify the routing tables on all routers. Can you ping remote networks?




                                           LAB3 - 8 -
CCNA4: WAN Technologies – Frame Relay                           RCNA FIIIIIT STU BA
                                                                RCNA F IT STU BA
                                                                RCNA F T STU BA


Command summary
Frame Relay configuration

Router(config)# interface <type number> . <subif number>
            point-to-point | multipoint
Router(config-if)# encapsulation frame-relay [cisco | ietf]
Router(config-if)# bandwidth value-in-kbps
Router(config-if)# description text
Router(config-if)# frame-relay lmi-type [ansi | cisco | q933a]
Router(config-if)# no ip split-horizon

! Point-to-point subinterfaces and multipoint subinterfaces with
! Inverse-ARP enabled use:
Router(config-if)# frame-relay interface-dlci DLCI-number

! Multipoint subinterfaces with Inverse-ARP disabled use:
Router(config-if)# frame-relay map <protocol> <remote address>
                  <local DLCI> [broadcast] [cisco | ietf]


Monitoring commands

Router#      show interfaces serial
Router#      show frame-relay lmi
Router#      show frame-relay map
Router#      show frame-relay pvc [interface interface] [DLCI-number]
Router#      clear frame-relay-inarp
Router#      debug frame-relay {lmi | packet | events}




                                     LAB3 - 9 -
CCNA4: WAN Technologies – Frame Relay                                              RCNA FIIIIIT STU BA
                                                                                   RCNA F IT STU BA
                                                                                   RCNA F T STU BA


Sample output of debug frame-relay lmi command:




Use the debug frame-relay lmi command to determine whether the router and the Frame
Relay switch are sending and receiving LMI packets properly.

(out) – indicates LMI status message sent by the router

(in) - indicates LMI message received from the Frame Relay switch

type 0 - indicates full LMI status message

type 1 - indicates LMI exchange

0x2 status of virtual circuit with DLCI 100 means it is active. Possible status codes are:

    •   0x0 – Added/inactive means that the switch has this DLCI programmed but for some
        reason it is not usable. The reason could possibly be the other end of the PVC is down.

    •   0x2 – Added/active means the Frame Relay switch has the DLCI and everything is
        operational.

    •   0x4 – Deleted means that the Frame Relay switch does not have this DLCI programmed
        for the router, but that it was programmed at some point in the past. This could also be
        caused by the DLCIs being reversed on the router, or by the PVC being deleted by the
        service provider in the Frame Relay cloud.




                                             LAB3 - 10 -