Re: Frame-relay again

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