Skip navigation
Cisco Learning Home > Certifications > Routing & Switching (CCNA) > Discussions

_Communities

This Question is Not Answered 1 Correct Answer available (4 pts) 1 Helpful Answer available (2 pts)
5406 Views 8 Replies Latest reply: Dec 1, 2009 12:05 AM by Conwyn RSS

Currently Being Moderated

Frame Relay Keep alives

Nov 29, 2009 1:21 AM

SenthilKumar 9 posts since
Jun 28, 2008

HI,

 

1. when LMI flowing between DTE(HQ router) and DCE(first switch), how i can know about the status of other end of remote DTE.i can't understand the PVC status displayed as "inactive".whether the keep alive flow through all the switch up to remote dce switch and how it updates HQ router.if cisco supporting end to end keep alive what about other two ANSI and Q.933A LMI.

 

2.can anyone tell me the packet structure of the inverse arp request and inverse arp reply.

  • Conwyn 7,907 posts since
    Sep 10, 2008
    Currently Being Moderated
    1. Nov 29, 2009 2:38 AM (in response to SenthilKumar)
    Re: Frame Relay Keep alives

    Hi Senthil

     

    1) Status of the PVC. The DCE device reports the status, and the DTE device receives the status. The PVC status is exchanged using the LMI protocol:

    ACTIVE— The PVC is operational and can transmit packets.

    INACTIVE—The PVC is configured, but down.

    DELETED—The PVC is not present (DTE device only), which means that no status is received from the LMI protocol.

    If the frame-relay end-to-end keepalive command is used, the end-to-end keepalive (EEK) status is reported in addition to the LMI status. For example:

    ACTIVE (EEK UP) —The PVC is operational according to LMI and end-to-end keepalives.

    ACTIVE (EEK DOWN)—The PVC is operational according to LMI, but end-to-end keepalive has failed.

     

     

    2) See https://learningnetwork.cisco.com/message/32798#32798 item 7

        See http://www.faqs.org/rfcs/rfc1293.html section 6

     

    Regards Conwyn

  • Conwyn 7,907 posts since
    Sep 10, 2008
    Currently Being Moderated
    3. Nov 29, 2009 4:04 AM (in response to Conwyn)
    Re: Frame Relay Keep alives

    Hi Senthil

     

    In my answer maked 2) it show a debug which contain the packet and the RFC which describes the layout. Is it possible to determine from the information provided the answer to your question.

     

    Also see http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/FRKeep.html

    and http://www.thebryantadvantage.com/CCNPCertificationBCRANExamFrameRelayEndToEndKeepalives.htm

    Regards Conwyn

  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,398 posts since
    Oct 7, 2008
    Currently Being Moderated
    4. Nov 29, 2009 2:29 PM (in response to SenthilKumar)
    Re: Frame Relay Keep alives

    Original stuff:

     

    1. when LMI flowing between DTE(HQ router) and DCE(first switch), how i can know about the status of other end of remote DTE.i can't understand the PVC status displayed as "inactive".whether the keep alive flow through all the switch up to remote dce switch and how it updates HQ router.if cisco supporting end to end keep alive what about other two ANSI and Q.933A LMI.

     

    2.can anyone tell me the packet structure of the inverse arp request and inverse arp reply.

     

    LMI technically flows THROUGH the frame-relay network.  It's a set of status messages.  if you have multiple frame-relay switches strung together, they would each exchange information as well.

     

    Picture:   Router1 -- FRS1 -- FRS2 -- FRS3 -- Router3

     

    When Router1 goes online, it will exchange LMI messages with FRS1.  Every 6th keepalive, it will request a Full Status Update which is where we get status of every known PVC.  All the DLCIs that FRS1 knows about for the port that Router1 is connected to will be sent down with either Active or Inactive.  In case Router3 isn't on yet, all of them would have an Inactive status.

     

    If Router1 is sending up a request for a DLCI that FRS1 doesn't know about, that will get returned as Deleted.  But Active or Inactive both mean it's a valid DLCI for the network.

     

    Once we get Router3 configured and online, the exchange of LMI between Router3 and FRS3 makes things locall active.  FRS3 will exchange LMI with FRS2.  FRS 2 with FRS1 and finally down to Router1 where the DLCI will change from Inactive to Active.  It may take some time based on that 60-second window (6 x 10-second keepalive timer) by default.  but it'll come up!

     

    After Router1 or Router3 see a DLCI as active, THEN the Inverse ARP process can begin.  They will send out packets ON that DLCI basically saying "Hi, My Name Is: (insert IP here).  What is your name?"  And once each of the router sees an incoming frame from that DLCI, they can dynamically map the sender's IP to that DLCI giving us inverse ARP.

     

    End to End Keepalive as Conwyn mentioned is another mechanism for protecting our end devices.  The problem is that no real-life service provider these days has a TRUE end-to-end frame-relay network, so the example of LMI between frame switches I laid out above is no longer realistic.  It's the theory about how things worked, and was the reality in the "old days".  Just not now.

     

    Now days, between FRS1 and FRS3 will most likely be an MPLS network.  The problem with that is that FRS1 will believe EVERY PVC is active as long as it has a route to get to FRS3.  Which doesn't accurately give information to Router1 or Router3.  Without accurate information, they may well send traffic into the cloud that can't possibly get out the other side.  So we use EEK to help with that.  It sends data packets between Router1 and Router3 along the PVC.  And if those fail, even though FRS1 or FRS3 may say that the DLCI is Active, we'll deem it EEK Down and not use it for packet forwarding.

     

    Check out www.protocols.com if you want to see frame formats for some reason, but unless you are being tested on packet/frame formats that's not generally something you care about on a day to day basis!

     

    HTH,

     

    Scott

  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,398 posts since
    Oct 7, 2008
    Currently Being Moderated
    6. Nov 29, 2009 10:22 PM (in response to SenthilKumar)
    Re: Frame Relay Keep alives

    Details...  Devil's in the details. 

     

    1.  yes, it's a frame-relay packet.  Kinda hard not to be!  LMI will be over either DLCI 0 or DLCI 1023 depending on which "version" we are talking about.  Remember, there's "cisco" (actually it's Nortel's version, but who's counting?), ANSI and ITU (Q.933a).

     

    They are just part of the reserved group of DLCIs.  0-15 are reserved, and 997-1023 are reserved.  That means they can't be used for "data DLCIs" but rather for control information of different types.  Many of those reserved DLCIs were never really used in the reality of frame-relay deployments, and most of the others are well out of scope for anyone knowing or caring about these days. 

     

    2.  Reading the RFCs is a great way to do things, but sometimes gives more confusing information than what you originally bargained for!  The term (and RFC) "Inverse ARP" was created as a generic (e.g. media independent) method of dynamic lookup.  So hence the "# bytes" field for the HW address, then the HW address itself.

     

    In frame-relay, that signifies the DLCI.  Take a look at section 7.2 of that RFC for a little more appropriate detail!

     

    HTH,

     

    Scott

  • samiullah channa 188 posts since
    Jul 1, 2008

    Hi sir Scott,

     

     

    Long time no c, first of all I would liek to say well come back to the forum, I missed u a lot for the time u were un available here, sir I have got a little issue regarding VTP, which is Cisco Proprietary, and will only work for cisco switches, I want to know which protocol shall we use as the VTP competitor for open standard or other vendors like Juniper, Huawei, etc...

     

    Some one told me something like GVRP is a protocol, can u help me understand what is it, and is there any other protocol, kindly make me understand the difference and working mechanism. I would be grateful to you for this kind act, I you help me plz.....

     

     

    Brgds

     

    Samiullah

  • Conwyn 7,907 posts since
    Sep 10, 2008

    Hi Samiullah

     

    If you wish to discuss GVRP rather than frame-relay keepalive please start a new discussion otherwise people will become confused.

     

    Here are some references.

     

    http://www.javvin.com/protocolGVRP.html

    http://en.wikipedia.org/wiki/Multiple_Registration_Protocol  Notice MVRP is the new name for GVRP

    http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/catos/6.x/configuration/guide/gvrp.html  on the larger Cisco switches including 3750.

     

    Regards Conwyn

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)