Re: Frame-relay again

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

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