Re: Frame-relay again

This is my finding, i did not want to get on the racks but i thought it
could help some people:

*R1 is running *

*R1#Show ver | Inc image*

*System image file is "flash:c3725-adventerprisek9-mz.124-15.T11.bin"*

* *

*R2 is running:*

*R2#Show ver | Inc image*

*System image file is "flash:c3725-adventerprisek9-mz.124-15.T11.bin"*

* *

*The Frame-relay switch is running:*

*AS-9#Show ver | Inc image*

*System image file is "flash:c3725-ipbase-mz.124-23.bin"*

* *

* *

*First TEST:*

R1 (LMI  ON)

FR(SW) S0/1 (LMI ON)

FR(SW) S0/2 (LMI  ON)

R2 (LMI  ON)

*Pings** are successful*

*Second TEST:*

R1 (LMI  OFF)

FR(SW) S0/1 (LMI  ON)

FR(SW) S0/2 (LMI  ON)

R2 (LMI  ON)

*Pings** are NOT successful*. A Show PVC on R2 will show the following:

R2#Show frame pvc 201 | Inc STATUS

DLCI = 201, DLCI USAGE = LOCAL, *PVC STATUS = INACTIVE*, INTERFACE =
Serial0/0

*Third TEST:*

R1 (LMI  OFF)

FR(SW) S0/1 (LMI  ON)

FR(SW) S0/2 (LMI  ON)

R2 (LMI  OFF)

*Pings** are NOT successful*

*Forth TEST:*

R1 (LMI  OFF)

FR(SW) S0/1 (LMI  OFF)

FR(SW) S0/2 (LMI  OFF)

R2 (LMI  OFF)

*Pings** are successful*, because none of the devices are expecting
keepalives from their directly connected device.

*Fifth TEST:*

R1 (LMI  ON)

FR(SW) S0/1 (LMI  OFF)

FR(SW) S0/2 (LMI  OFF)

R2 (LMI  ON)

*Pings** are NOT successful.*

*Sixth TEST:*

R1 (LMI  ON)

FR(SW) S0/1 (LMI  OFF)

FR(SW) S0/2 (LMI  ON)

R2 (LMI  ON)

*Pings** are NOT successful.*

On Thu, Aug 26, 2010 at 6:31 PM, jason munns <jasonmunns13_at_gmail.com> wrote:

> Hi Adam,
>
> I don't think it's just Dynamips behavior. I am using real routers,
> and I saw exactly what Carlos described. My frame switch is a 2522
> router.
>
> R1 2600
> Frame Switch 2522
> R2 2600
>
> Regards,
> Jason
>
> On 27 August 2010 13:20, Adam Booth <adam.booth_at_gmail.com> wrote:
> > 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
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
>

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