LMI Type
Mikdilly
Member Posts: 309
in CCNA & CCENT
Thought i had an understanding of lmi type but on a free test they have a question that has as the reason that a merged network is not able to connect to the private frame relay network is because the lmi types don't match between the two routers. Is there a difference between a public and private frame relay network? I thought the lmi types only had to match between the dte and dce on either end of the connection so that a configuration such as this would work:
DCE
DTE ----Frame relay
DTE
DCE
ansi Cisco
Their explanation says the lmi type between the DCE and DTE have to match on each end of an access link.
DCE
DTE ----Frame relay
DTE
DCE
ansi Cisco
Their explanation says the lmi type between the DCE and DTE have to match on each end of an access link.
Comments
-
kafifi13 Member Posts: 259All the DTE's need to have the same LMI type from what i understand. The DTE and DCE will communicate but when the traffic is routed towards the other end it will have issues if hte recieveing DTE will have issues.
-
NeonNoodle Member Posts: 92 ■■□□□□□□□□You just saved me from getting a question like that wrong because I would have answered the same. However, it's the DLCI which has the local significance, i.e. between the DTE and DCE, not the LMI type.
And this is what I found in Troubleshooting Frame RelayWhen implementing Frame Relay—and, specifically, LMI—in an internetwork, the LMI type must be consistent across all points between the end devices.I recognize the lion by his paw.
--Jacob Bernoulli -
borumas Member Posts: 244 ■■■□□□□□□□That brings to mind another question, isn't the LMI type auto-sensed by default? That was my understanding from material I've read, so if it is auto then is should match up between the 2 devices.
-
Netstudent Member Posts: 1,693 ■■■□□□□□□□yes I have read that the LMI is auto-sensed by default. I have also read that LMI only has to match between the the DCE and DTE, but it does not have to match from DTE to DTE. IS this wrong? Can anyone provide any information stating otherwise?There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1!
-
tech-airman Member Posts: 953Mikdilly wrote:Thought i had an understanding of lmi type but on a free test they have a question that has as the reason that a merged network is not able to connect to the private frame relay network is because the lmi types don't match between the two routers. Is there a difference between a public and private frame relay network? I thought the lmi types only had to match between the dte and dce on either end of the connection so that a configuration such as this would work:
DCE
DTE ----Frame relay
DTE
DCE
ansi Cisco
Their explanation says the lmi type between the DCE and DTE have to match on each end of an access link.
Mikdilly,
Firstly, your diagram is incorrect. The correct diagram is as follows...(DTE)----(DCE)---z----{Frame Relay}----z----(DCE)-----(DTE)
To the best of my knowledge, there isn't such difference between "private" and "public" frame relay. The frame relay network is owned by the Service Provider. As a customer, you would only have access to the frame relay network if you have an established service contract with the Service Provider.
Let's use your logic of "lmi types only had to match between the dte and dce on either end of the connection" with LAN switches. Let's use a crossover ethernet cable and connect on one side an Ethernet switch and on the other side a Token Ring MSAU. The crossover ethernet cable will PHYSICALLY click into both networking devices. However, the problem is that an Ethernet frame and a Token Ring frame are different therefore the protocols are different. Same thing with the Frame Relay and LMI type. So in summary, use the same LMI type on both ends of a frame relay link to avoid connection problems. -
Mikdilly Member Posts: 309Sorry for the mixed up configuration and thanks for the explanations, everything i had read up until today stated that it didn't matter what lmi type was being used between the dce and dte on either end of a connection but glad to now know otherwise.
-
borumas Member Posts: 244 ■■■□□□□□□□So LMI isn't just concerned with communication between the onsite router and the frame-relay switch at the provider? I didn't think it would affect the equipment on the other side of the cloud, that it was only for communication between the frame-relay switch and the DTE device.
-
NeonNoodle Member Posts: 92 ■■□□□□□□□□The quote I have is from Cisco's page on configuring Frame Relay.
Somebody should set up a little Frame Relay network and see what happens. (Maybe it's my inexperience, but I would be surprised if you couldn't do it.) If someone hasn't done it by the time I get home tonight, I'll do and let you know.I recognize the lion by his paw.
--Jacob Bernoulli -
floppydisk Member Posts: 60 ■■□□□□□□□□try to use ietf on both end....
good luck with the troubleshooting.....great way to learn!! -
Netstudent Member Posts: 1,693 ■■■□□□□□□□IETF is for encapsulation...That is different than LMI...There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1!
-
tech-airman Member Posts: 953borumas wrote:So LMI isn't just concerned with communication between the onsite router and the frame-relay switch at the provider? I didn't think it would affect the equipment on the other side of the cloud, that it was only for communication between the frame-relay switch and the DTE device.
borumas,
According to Cisco...Cisco wrote:In 1990, Cisco Systems, StrataCom, Northern Telecom, and Digital Equipment Corporation developed a set of Frame Relay enhancements called the Local Management Interface (LMI). The LMI enhancements offer a number of features (referred to as extensions) for managing complex internetworks, including the following:
•Virtual circuit status messages
As we know, virtual circuits, or in the case of frame relay "permanent virtual circuits" (PVC) extend end to end from one router across the frame relay cloud to the other router. Therefore, in order for the LMI on the first router to send "Virtual circuit status messages" through the PVC to the second router, the LMI types must be the same for the routers to be able to "talk" to each other. So if you have a LMI mismatch situation, then one router might be speaking "Cisco LMI" and the other router speaking "ansi LMI" or "q933a LMI" and since neither understands each other, they'll just stop talking to each other which also means connectivity between the two will stop too. So to prevent "loss of connectivity" across the PVC, you need to configure the same LMI type on both ends of the frame relay PVC.
Source:- Frame Relay - http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/frame.htm#wp1020640
- Cisco IOS Wide-Area Networking Command Reference, Release 12.4 - Wide-Area Networking Commands - http://www.cisco.com/en/US/products/ps6350/products_command_reference_chapter09186a00804474e9.html#wp1080830
-
Cucumber Member Posts: 192When implementing Frame Relay—and, specifically, LMI—in an internetwork, the LMI type must be consistent across all points between the end devices
Well perhaps the source of all this confusion is the wording being used.
For what I see, this means that if you have a Frame Relay net like this:
EndDevice---R1======R2====R3
EndDevice
You have to make sure that the LMI must match at each point between end devices.
EndDevice(cisco)-(cisco)R1(Ansi)=(Ansi)R2(q933a)=(q933a)R3(ansi)-(ansi)EndDeviceI hate pandas -
Mikdilly Member Posts: 309Just took the exam and this question was on it. I took the answer that freetest said was correct about lmi type.
-
Mikdilly Member Posts: 309Full CCNA, failed prettty badly, 732. It has to be hardest certification test i've ever taken, but then the only other ones i've had are mcse and A+, which were passed but were nothing like this. It seemed like every other question was one where it would take too long just to get grasp of some kind of topology. The sim questions are very confusing because of the layout, it's too much to take in when you're under the gun of a timer. Had a feeling going in that I wasn't prepared enough but wanted to take it to get an idea of what it was like, got thru to the last question but had to tank a sim question and couple multiple choice just to get there.
-
kafifi13 Member Posts: 259That sucks. Just study up on your weak points and take it again. It's a lot to learn at once. I'm only half way there. I decided on the 2 test option.
-
kafifi13 Member Posts: 259Just alot of the basics. Talks a bit about routing protocols but doesn't get too much into it. If you have the Cisco press books try taking a practice test and see how you do. I personally liked this method because i could really focus on a certain amount of material.
-
Mikdilly Member Posts: 309I used the CCNA self-study for 811 by Odom for the 801, realized it probably wasn't the correct book for it but thought by using Boson, transcender and a bunch of practice tests it would be enough. Did you use the intro book from ciscopress?
-
kafifi13 Member Posts: 259I used Cisco press and some other material i bought online. Also used the Flash cards. I have bought Trancender though for the ICND and trying this out. Hoping this will help alot. Just keep at it. Do you mind me asking how many hours a week do you study? For me i'm very slow and i have to live and breath this Cisco stuff. I'm always trying to memorize or learn something. Flash cards, LOTS of notes and just hours of study. Otherwise i would have failed.
-
Mikdilly Member Posts: 309It only amounted to be about an hour a night for the last 6 months or so up until about 2 weeks before the test then it was little more per night, probably isn't enough but that's about all the time I can seem to get with work and all. What kind of questions do you get on the Intro exam?
-
dtlokee Member Posts: 2,378 ■■■■□□□□□□tech-airman wrote:As we know, virtual circuits, or in the case of frame relay "permanent virtual circuits" (PVC) extend end to end from one router across the frame relay cloud to the other router. Therefore, in order for the LMI on the first router to send "Virtual circuit status messages" through the PVC to the second router, the LMI types must be the same for the routers to be able to "talk" to each other
There seems to be some confusion here about the difference between encapsulation and LMI. LMI as it's name implies is local, it allows the frame-relay switch (DCE) to communicate information to the router (DTE) about the DLCI's in use and the status of those DLCIs. The LMI types can be different at both ends (hence the local concept).
Encapsulation on the other hand needs to be the same between the DTE endpoints, because it defines the actual framing that the router sends to the other side.
Now the original post mentioned "private" frame-relay, I guess they're talking about a frame relay connection without the use of a frame switch where you have two routers connected back to back like a PPP connection but you're using encapsulation frame-relay. In this case the two endpoints would need to have matching LMI since there's no frame switchThe only easy day was yesterday! -
rossonieri#1 Member Posts: 799 ■■■□□□□□□□well,
there are private and public FR actually.
it was only how you manage your connection.
private - i mean really private that a company build for their own communication such as campuses etc.
public? well known.
not only FR - even SS7 now have been widely deploy for internal communication.
HTH.the More I know, that is more and More I dont know.