Re: Frame-relay again

Hi Carlos,

What you have found appears to be an artefact of the built in frame switch
in Dynamips - to get around this in my environment I emulated a 2600 with a
bunch of serial ports and built the frame-routes myself. When you do it
this way, you should see the expected behaviour others have been describing.

Cheers,
Adam

On Fri, Aug 27, 2010 at 10:07 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:

> Ok, I was wrong, tired and stressed.
> So let's get over it.
>
> Here, my point was that the switch can do switching (never intended to
> mean NNI) even w/o LMI. He was trying not to get the full list of DLCIs,
> so that sounded like LMI had to be disabled.
>
> Now, in trying to find out any way to make it work, I discovered some
> weird behaviour:
> As Christopher found, if you disable LMI at the FRsw, ping works.
> That means disabling LMI at both links, to R1 and to R2.
> But if you enable LMI at just one, any one, it works too.
>
> So:
> R1: no keep
> FRtoR1: keep
> FRtoR2: no keep
> R2: no keep
>
> ping: works
> weird.
>
> -Carlos
>
>
> Narbik Kocharians @ 26/08/2010 16:47 -0300 dixit:
> > Once again you missed the point, the question here pertains to the
> behaviour
> > of Cisco routers in a lab environment for the CCIE lab, and had nothing
> to
> > do with Nortel boxes. I am sure in the past you have contributed a
> > tremendous amount of stuff and helped resolved huge number of
> > issues/confusions that people had, and i am sure that you will continue
> to
> > do so, your contribution is very valuable.
> > But when your assumption is wrong, you have to just admit it, instead of
> > changing positions and scenarios, it's cool with me when we are
> Unicasting,
> > but when we are Multicasting to the group, lots of students will form an
> > opinion, specially when it comes from a CCIE. I have made lots and i mean
> > lots of mistakes (two, just kidding), hey in 33 years, you will make
> > mistakes and this is the learning process; but when a person is wrong, it
> > does not mean that he is no good or he does not know anything. All it
> takes
> > is "hey....i guess you are correct, i did not see it that way, thanks for
> > clearing it up" or " i have not had my coffee yet" or "let me think about
> > it" but constantly arguing is what turns off people. A discussion is
> > different, a discussion is GR8 when both sides focus and try to work to
> > resolve an understanding.
> >
> > I am sure people like Anthony, Brians, Scott M, Marko, Scott Tyson *and
> I**
> > *have been wrong in many occasions, but hey this is life and it is what
> it
> > is.
> >
> > As Forest Gump says, "That's all i have to say about that"
> >
> > On Fri, Aug 27, 2010 at 5:18 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar
> >wrote:
> >
> >> Narbik,
> >>
> >>> *R1 - FRsw - R2*
> >>> *Even with no LMI in one end, data can go throw from R1 to R2.*
> >>>
> >>> And you were wrong.
> >> I am not wrong, people with experience in the field with a different
> >> brand backed me up. No LMI at the DTE does not prevent the link from
> >> being used.
> >> I never said you had LMI up the other side, in fact you have to turn it
> >> off too for the traffic to come back. But I said "from R1 to R2" there,
> >> did not I ?
> >>
> >> I'm over my quota of agression in here. It's been a long time since I
> came
> >> to GS, and have been contributing more or less regularly. But
> >> may be it's time to let go.
> >>
> >> So long,
> >> -Carlos
> >>
> >> Narbik Kocharians @ 26/8/2010 15:02 -0300 dixit:
> >>
> >> Carlos,
> >>> What routers and IOS version did you do your test on, i like to see
> that
> >>> bug
> >>> or the thingy as you mentioned earlier.
> >>>
> >>> Because on real routers, Grammer's test is what i agree with, because
> as i
> >>> stated earlier, if you disable LMIs on one of the two routers, the
> state
> >>> of
> >>> the PVC will transition into "inactive" on the other router and
> therefore,
> >>> YOU WONT BE ABLE TO PING ACROSS. This is what we learned in CCNA class,
> no
> >>> disrespect to anyone.
> >>>
> >>> This is what you stated earlier, it's still there, i do not understand
> why
> >>> you made a statement like that? specially after going back and forth:
> >>>
> >>> *R1 - FRsw - R2*
> >>> *Even with no LMI in one end, data can go throw from R1 to R2.*
> >>>
> >>> And you were wrong.
> >>>
> >>> But you see we started with a simple question, and you were WRONG, but
> you
> >>> dragged this simple issue all the way to this point, and you are still
> >>> wrong. I hate to see your next scenario where you are going to prove
> your
> >>> point.
> >>>
> >>> Hey it's cool to make mistakes. We did not come to this world with
> CCNP+
> >>> knoweldge, that ONLY appplies to my Gandma.
> >>>
> >>> Thanks everyone else for participating. Thanks Grammer for your test
> that
> >>> was cool.
> >>> On Thu, Aug 26, 2010 at 8:19 AM, Grammer, Christopher <
> >>> cgrammer_at_essilorusa.com> wrote:
> >>>
> >>> I put this in the lab and here are the results:
> >>>> R1 ---- Frame Switch ----- R2
> >>>>
> >>>> Frame Switch: DLCI Config
> >>>> connect R1_R2 Serial1/0 102 Serial1/1 201
> >>>>
> >>>>
> >>>>
> >>>> *****************************************************
> >>>> LMI is ON everywhere...everything works as expected.
> >>>> R2#ping 1.1.1.1
> >>>> Type escape sequence to abort.
> >>>> Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
> >>>> !!!!!
> >>>> Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
> >>>>
> >>>>
> >>>> ****************************************************************
> >>>> LMI is OFF on R1:
> >>>> On R1:
> >>>> int s0/0
> >>>> no keepalive
> >>>>
> >>>> When "no keepalive" is configured on R1, the frame-switch does this:
> >>>> 00:23:07: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0,
> >>>> changed
> >>>> state to down
> >>>>
> >>>> PVC state on Frame Switch goes to Switched Inactive
> >>>> PVC state on R1 is static
> >>>> PVC state on R2 is Inactive
> >>>> And, obviously, no ping works.
> >>>> ****************************************************************
> >>>> LMI is OFF on R1 and R2:
> >>>>
> >>>> On R1 and R2:
> >>>> int s0/0
> >>>> no keepalive
> >>>>
> >>>> When no keepalive on R1 and R2 is configured, same result on Frame
> >>>> Switch:
> >>>> 00:27:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/1,
> >>>> changed
> >>>> state to down
> >>>>
> >>>> PVC state on Frame Switch goes to Switched Inactive
> >>>> PVC state on R1 is static
> >>>> PVC state on R2 is static
> >>>> And, no ping works.
> >>>>
> >>>>
> >>>>
> **************************************************************************************
> >>>>
> >>>> LMI is OFF on R1, R2 and the Frame Switch:
> >>>>
> >>>> Frame Switch immediately:
> >>>> 00:29:50: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0,
> >>>> changed
> >>>> state to up
> >>>> 00:29:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/1,
> >>>> changed
> >>>> state to up
> >>>>
> >>>> PVC state on Frame switch is ACTIVE SWITCHED
> >>>> PVC state on R1 is LOCAL STATIC
> >>>> PVC state on R2 is LOCAL STATIC
> >>>>
> >>>> Ping works without issue:
> >>>>
> >>>> R2#ping 1.1.1.1
> >>>>
> >>>> Type escape sequence to abort.
> >>>> Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
> >>>> !!!!!
> >>>> Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
> >>>>
> >>>>
> >>>> Hope this helps,
> >>>>
> >>>> Chris
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Aug 26, 2010 at 6:58 AM, Marcelo Rosa <MRosa_at_multirede.com.br
> >>>>
> >>>>> wrote:
> >>>>> I have to disagree. If you disable LMI on BOTH sides of the PVC,
> there
> >>>>>
> >>>> Will
> >>>>
> >>>>> be traffic running through. I tell this by Field experience. Nortel
> >>>>>
> >>>> routers
> >>>>
> >>>>> used to come with LMI disabled by default, and worked fine, as far as
> my
> >>>>> experience goes. All you have to do is statically map the DLCI on the
> >>>>> interface.
> >>>>>
> >>>>> -----Mensagem original-----
> >>>>> De: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] Em nome de
> >>>>>
> >>>> Narbik
> >>>>
> >>>>> Kocharians
> >>>>> Enviada em: quarta-feira, 25 de agosto de 2010 20:57
> >>>>> Para: Carlos G Mendioroz
> >>>>> Cc: Kambiz Agahian; selamat pagi; Cisco certification
> >>>>> Assunto: Re: Frame-relay again
> >>>>>
> >>>>> Carlos,
> >>>>>
> >>>>> Our discussion here has nothing to do with Switch-Switch
> >>>>> connection/communication or Route reflectors or the NAP so why
> confuse
> >>>>>
> >>>> this
> >>>>
> >>>>> gentlman. We are disabling the LMIs on the router and NOT the switch.
> >>>>>
> >>>>> It was a very basic question, you have R1 connecting to R2 through
> frame
> >>>>> switch, if you disable LMIs on one end let's say R1, the status of
> the
> >>>>>
> >>>> PVC
> >>>>
> >>>>> will go into "inactive" state on R2.
> >>>>>
> >>>>> R1 will NOT get ANY DLCI information from the switch, even if you try
> to
> >>>>> ping R1 from R2, R1 will NOT see any packets coming from R2 (Through
> its
> >>>>> DLCI), so that tells me that the Switch is NOT forwarding packets to
> R1.
> >>>>> Even if you configure a frame-relay map statically on R1 for R2's IP
> >>>>> address.
> >>>>>
> >>>>>
> >>>>> 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
> >>>>
> >>>>
> _______________________________________________________________________
> >>>> Subscription information may be found at:
> >>>> http://www.groupstudy.com/list/CCIELab.html
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >> --
> >> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
> >>
> >
> >
> >
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>
>
> 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 - 11:20:21 ART