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:
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:
2) See https://learningnetwork.cisco.com/message/32798#32798 item 7
See http://www.faqs.org/rfcs/rfc1293.html section 6
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.
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!
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.
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
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
here above the confusion.that's why i am asking inverse arp frame relay format.
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!
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.....
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://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.