Re: Frame-relay again

I was trying to show you that having sub-interfaces in the scenario that you
mention below, will buy you nothing. Isn't this what you stated?

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!)

In the above statement you are saying that if the main does not work then, a
sub-interface will. I was proving to you that you were wrong AGAIN.

By saying changing scenarios, you are now mentioning sub-interfaces. You are
so far off, its incredible, i have learnt nothing from you, the ONLY thing i
learned here, is that you like to argue and have no clue and keep changing
your postion to justify your statements.

Let's put this to rest. You like to continue, unicast me.
On Fri, Aug 27, 2010 at 11:38 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:

> Narbik Kocharians @ 27/08/2010 14:07 -0300 dixit:
> > Unbelievable
> > My last post on the subject
> >
> > Its a nice pattern Carlos.
> >
> > 1^st item-------correct
> > 2^nd item-------Wrong
> > 3^rd item--------correct
> > 4^th item--------Wrong (The proof is here, I have included the config)
> > 5^th item---------correct
> > 6^th item--------Wrong
> >
> > Notice your yet another new topology is NOT transferring anything, I
> > have configured a sub-interface and it still does not work.
>
> Yep, unbelievable the ammount of work you put into trying to disqualify
> something using psychology tricks. But I'm keeping it technical now,
> sort of :-)
> Many algorithms do use a try and get better "iterative" way of reaching
> target, may be I'm using that!
>
> BTW, I don't know how "R1 - FRsw - R2" is perceived by you as a new
> topology, may be you have a different semantics for topology.
>
> > 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)
>
> And you hoped it would work ? Didn't I say that the frame switch would
> drop it if one end had LMI configured and up ?
>
> > 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)
>
> I'm glad you now see it, it's been 3 or 4 mails ago when I mentioned it.
>
> >
> > 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.
>
> Right, also mentioned by me some time ago. Glad you learned something too.
>
> Enough of this already. Agreed.
> -Carlos
>
> --
> 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