web analytics
  • RSS

  • Polls

    What Cisco Cert Are You Currently Studying?

    View Results

    Loading ... Loading ...
  • Search on CiscoBibles

  • Popular Posts

  • Recent Comments

  • Archives

  • « | Main | »

    Frame-Relay – Things to Remember

    By admin | August 15, 2009

    1. When “encapsulation frame-relay” command is issued on an interface, the router will learn all the DLCIs associated with that interface via LMI updates. Then once an IP address is configured on the same interface, InARP request will be sent out on all the learned DLCIs. If the other end is also configured with an IP address, it will reply with its own IP address.
    2. Any DLCIs learned with LMI that are not associated with a subinterface are assumed to be used by the physical interface.
    3. PVC status can be active, inactive, deleted.
    4. Encapsulation types are Cisco (default), IETF; e.g. “encapsulation frame-relay ietf” / “frame-relay interface-dlci 101 ietf” / “frame-relay map ip 101 ietf”.

  • LMI types are Cisco (default), ANSI, q933a; e.g. “frame-relay lmi-type ansi” / “frame-relay lmi-type q933a”.
  • DCE (Frame Relay Switch) always generates LMI.
  • The ANSI T1.617 Annex D LMI and the ITU Q.933 Annex A LMI are equivalent, use DLCI 0 for LMI flows whereas the Cisco LMI uses DLCI 1023.
  • By default, the LMI messages flow every 10 seconds. Every sixth message carries a full Status message, which includes more complete status information about each VC. A router considers its interface to have failed if the router ceases to receive LMI messages from the switch for a number (default 3) of keepalive intervals (default 10 seconds).
  • FR LMI can be disabled by using the “no keepalive” command while using back-to-back frame-relay.
  • Interestingly, the “no frame-relay inverse-arp” / “no frame-relay inverse-arp ip 101”only stops the InARP request, but it doesn’t stop the reply to the InARP request. As a result if one side is configured with “no frame-relay inverse-arp” and also if there is no static mappings at that side, still it will learn layer 3 to layer 2 mappings while replying to InARP from the other side.
  • no frame-relay inverse-arp” command in physical interface is not inherited by the subinterfaces.
  • In multipoint frame-relay configuration, an IP address can be reached if (1) the destination IP address is in the routing table with a valid next-hop and (2) a frame-relay mapping is available for that IP address. With InARP, multipoint/physical interface can’t ping its own IP address. A static mapping of its own DLCI to its own IP is required to work around this issue.
  • In point-to-point frame-relay configuration, InARP is disabled by default. And also if both routers use point-to-point subinterfaces, neither would have to be configured with a frame-relay map command, due to the “use this VC to reach all addresses in this subnet” logic. That’s why it can also ping its own IP address.
  • Point-to-point subinterfaces can only have one DLCI assigned to it.
  • Only point-to-point subinterfaces can be unnumbered.
  • Two IP addresses from the same subnet can be configured on two different subinterfaces. It is usually configured on the hub router.
  • frame-relay interface-dlci 101” command does not enable layer 3 to layer 2 resolution. Instead, it simply assigns the DLCI to the interface.
  • Frame-relay static mapping overrides dynamic mapping.
  • For PPPoFR, the virtual-template interface should be configured first, then the virtual-template should be bound to frame-relay DLCI with “frame-relay interface-dlci XXX ppp Virtual-TemplateX” command. This will eliminate lots of issues.
  • In PPPoFR, hardware compression and fancy queueing algorithms, such as weighted fair queueing, custom queueing, and priority queueing, are not applied to virtual access interfaces.
  • There is no CDP by default on a frame-relay interface with the exception of point-to-point subinterface, have to enable it on physical or logical interface separately.
  • By default, IP split horizon is turned off on frame-relay physical interfaces, but not on the subinterfaces.
  • When an interface is configured to do static mapping, there may be some IP addresses mappings due to previous the InARP configuration. We need to use “clear frame-relay inverse-arp” or we have to reload the router after saving the configuration.
  • A point-to-point subinterface can not be reassigned the same subinterface number to be used for multipoint subinterface without first rebooting the router. Instead, a different subinterface number can be used to work around this issue.
  • A physical interface is always in up/up state as long as LMIs are received, DLCIs may not be up in this case. But to be in an up/up state, the subinterface must receive LMIs and at least one of the assigned DLCIs must be up also.
  • The line protocol status of frame-relay physical interface doesn’t depend on the PVC status. So if the “backup interface” command is configured on a frame-relay physical interface, the change of PVC status will not trigger the backup interface to come up. A GRE tunnel (with keepalive) can be used to solve this issue.
  • End-to-end keepalive doesn’t change the status (up/down) of the physical interface; it can only change the status of subinterfaces.
  • By Zakir A. Khan

    * Frame-Relay – Things to Remember .Pdf  |  Download


    Topics: CCNA, CCNA Articles, CCNA R&S | 1 Comment »

    One Response to “Frame-Relay – Things to Remember”

    1. Cisco | All Days Long Says:
      August 15th, 2009 at 2:58 pm

      […] Frame-Relay – Things to Remember | Free Cisco Training & Resources … By admin When “encapsulation frame-relay” command is issued on an interface, the router will learn all the DLCIs associated with that interface via LMI updates. Free Cisco Training & Resources… – http://www.ciscobible.net/ […]


    You must be logged in to post a comment.