8 Replies Latest reply: Dec 1, 2009 12:05 AM by Conwyn RSS

    Frame Relay Keep alives

    SenthilKumar

      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.

        • 1. Re: Frame Relay Keep alives
          Conwyn

          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

          • 2. Re: Frame Relay Keep alives
            SenthilKumar

            Hi conwyn,

             

                     is the keep alive or LMI frames travel through the frame relay swithes up to the other end of the router??

             

                    if i am using ip network and frame relay wan service  then what will be the format of inverse arp frames???

            • 3. Re: Frame Relay Keep alives
              Conwyn

              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

              • 4. Re: Frame Relay Keep alives
                Scott Morris - CCDE/4xCCIE/2xJNCIE

                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

                • 5. Re: Frame Relay Keep alives
                  SenthilKumar

                  Hi Scott,

                   

                             Thanks.i got some points.there are some more questions

                   

                  1.Is LMI encapsulated in frame relay frame(like ip packets encapsulated in frame relay frame) or it is different one

                   

                   

                  2.in RFC 2390 (Inverse ARP mechanism) they stated there is source and destination hardware addresses(like in arp souce mac and destination mac),but in frame relay there is no source and destination DLCI at all.

                   

                  Packet Format

                     Inverse ARP is an extension of the existing ARP.  Therefore, it has
                     the same format as standard ARP.

                        ar$hrd   16 bits         Hardware type
                        ar$pro   16 bits         Protocol type
                        ar$hln    8 bits         Byte length of each hardware address (n)
                        ar$pln    8 bits         Byte length of each protocol address (m)
                        ar$op    16 bits         Operation code
                        ar$sha    nbytes         source hardware address
                        ar$spa    mbytes         source protocol address
                        ar$tha    nbytes         target hardware address
                        ar$tpa    mbytes         target protocol address

                  Protocol Operation

                     Basic InARP operates essentially the same as ARP with the exception
                     that InARP does not broadcast requests.  This is because the hardware
                     address of the destination station is already known.

                     When an interface supporting InARP becomes active, it should initiate
                     the InARP protocol and format InARP requests for each active PVC for
                     which InARP is active.  To do this, a requesting station simply
                     formats a request by inserting its source hardware, source protocol
                     addresses and the known target hardware address.  It then zero fills
                     the target protocol address field.  Finally, it will encapsulate the
                     packet for the specific network and send it directly to the target
                     station.

                  here above the confusion.that's why i am asking inverse arp frame relay format.


                  Thanks



                  • 6. Re: Frame Relay Keep alives
                    Scott Morris - CCDE/4xCCIE/2xJNCIE

                    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

                    • 7. VTP Compatible protocol for Open standard Environment.......
                      samiullah channa

                      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

                      • 8. Re: VTP Compatible protocol for Open standard Environment.......
                        Conwyn

                        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