Re: Frame-relay again

I would like to nominate myself to get the last word in on this subject!

"yuyyyna - From A Hopi-English Dictionary of the Third Mesa Dialect." :)

I have been married before so it's not something I have ever had the opportunity to do!

On Aug 27, 2010, at 1:07 PM, Narbik Kocharians wrote:

> Unbelievable
>
>
>
> My last post on the subject
>
>
>
> Its a nice pattern Carlos.
>
>
>
> 1st item-------correct
>
> 2nd item-------Wrong
>
> 3rd item--------correct
>
> 4th item--------Wrong (The proof is here, I have included the config)
>
> 5th item---------correct
>
> 6th item--------Wrong
>
>
>
> Notice your yet another new topology is NOT transferring anything, I have
> configured a sub-interface and it still does not work.
>
>
>
> On R1
>
>
>
> interface Serial0/0
>
> no ip address
>
> encapsulation frame-relay
>
> *no keepalive*
>
> frame-relay lmi-type cisco
>
> !
>
> interface Serial0/0.12 point-to-point
>
> ip address 200.1.1.1 255.255.255.0
>
> snmp trap link-status
>
> frame-relay interface-dlci 102
>
>
>
> On R2
>
>
>
> R2#sh frame pvc 201 | Inc STATUS
>
> DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = INACTIVE, INTERFACE = Serial0/0
>
>
>
> On R1
>
>
>
> R1#p 200.1.1.2
>
>
>
> Type escape sequence to abort.
>
> Sending 5, 100-byte ICMP Echos to 200.1.1.2, timeout is 2 seconds:
>
> .....
>
> Success rate is 0 percent (0/5)
>
>
>
>
>
> The only one that works is when we have the following:
>
> R1 (LMI  OFF)
>
>
>
> FR(SW) S0/1 (LMI  ON)
>
>
>
> FR(SW) S0/2 (LMI  OFF)
>
>
>
> R2 (LMI  OFF)
>
>
>
> But if you go to the FR-SW and do a show frame pvc you will see that it
> says that its dropping packets and NOT forwarding any of them, and why do we
> see the ping successful, I have not had the time to do some data scoping,
> maybe it will be a different story if we have 2 frame-relay switches
> connected via an AUX port and see if it actually drops or forwards. Or maybe
> Cisco routers dont implement Fr-Sw in a 100% manner.
>
>
>
> My tests were done with the IOS that I mentioned in my previous post.
>
>
>
>
>
>
> On Fri, Aug 27, 2010 at 7:08 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:
>
>> Ok, here's my current state of understanding:
>>
>> *Question is related to what R1 sees as pvc info.
>> This is transferred via LMI and AFAIK there is no way to filter
>> it, so only chance is to disable it at R1-FRsw, if that's possible.
>>
>> *Routers as DTEs can disable LMI and work, no problem
>>
>> *LMI transfers not only DLCI availability but also other end status
>>
>> *If you disable LMI at one DTE, the other will see remote as inactive
>> and will not TX over the main interface.
>> (It will, though, tx over a subinterface even if main is UP/down because
>> of remote inactive!)
>>
>> *Cisco's implementation of frame relay switch will not transfer data over a
>> DLCI that has both ends with LMI and it's inactive!
>>
>> It makes sense, given that both ends know or are supposed to know that
>> the link is inoperative.
>>
>> *Cisco's implementation of frame relay switch *will* transfer data over a
>> DLCI that has one end with no LMI regardless of the status of a possibly
>> managed end.
>>
>> And that surprised me a little.
>> But then, if the frame relay switch is cisco, I would say that the problem
>> has no solution w/o touching the frame relay config.
>>
>> Sorry about the emotions that entered the thread, I'll *try* not to do that
>> again.
>>
>> -Carlos
>>
>>
>> selamat pagi @ 25/8/2010 15:07 -0300 dixit:
>>
>> I know this has been discussed several times here, but I still don't
>>> have/understand the solution.
>>> If there is none, I just will believe it and can continue with something
>>> more interesting :-)
>>>
>>> QUESTION:
>>> Is there a way to avoid that the FR-switch responds with all the DLCI
>>> configured ?
>>> So we will only see our configured PVC in the output of "sh frame-relay
>>> pvc"
>>>
>>> (assumed the FR-switch config cannot be changed ;-)
>>>
>>> I played around with keepalive and lmi-n391dte-values, however the type 0
>>> I
>>> don't get rid of ..?
>>>
>>> thanks, keti
>>>
>>
>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>
>
>
>
> --
> Narbik Kocharians
> CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> www.MicronicsTraining.com
> Sr. Technical Instructor
> YES! We take Cisco Learning Credits!
> Training And Remote Racks available
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Fri Aug 27 2010 - 13:48:11 ART