Re: Frame-relay again

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
Blogs and organic groups at http://www.ccie.net