Re: Frame-relay again

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