Re: Frame-relay again

Hey Carlos,

I am not taking sides on the latest discussions but your messing with some of the big kids on the block... (Narbik, Scott , Tyson, just to name a few and no disrespect to the IEs that contribute on a regular basis) Although they are more than humble enough to accept that they are incorrect, it just doesn't happen very often!

On Aug 25, 2010, at 8:58 PM, Carlos G Mendioroz wrote:

> R1 - FRsw - R2
>
> Even with no LMI in one end, data can go throw from R1 to R2.
>
> -Carlos
>
> Narbik Kocharians @ 25/08/2010 20:56 -0300 dixit:
>> 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.
>>
>> */you can switch and run no routing protocols, like when you do static
>> routes./*
>>
>> When you configure a static route, are you NOT satisfying the control
>> plane? You don't have to have a routing protocol like RIPv2, Eigrp or
>> OSPF to have data-plane. *_In routing world_* (Old or New) if the
>> control plane is NOT there you can NOT have the data plane to work.
>> Trust me i have seen how the words and terms have changed through the
>> years, i have been in this for the past 33 years. But they all mean the
>> same.
>>
>> This gentlman asked a VERY simple question and he needs a very simple
>> answer. When someone asks a question about the LMI exchange between his
>> local router and the frame-relay switch, you are NOT going to explain
>> Frame-to-ATM-Frame internetworking would you?
>>
>>
>>
>>
>>
>>
>> On Wed, Aug 25, 2010 at 4:24 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar
>> <mailto:tron_at_huapi.ba.ar>> wrote:
>>
>> Oh my.
>> A long long time ago people used to say that routers had two functions:
>> they route (as in routing protocols) and switch (as in switching
>> packets). New age terms seem to be control plane and data plane
>> services.
>>
>> Fact is that you *can* do one without the other: you can switch and run
>> no routing protocols, like when you do static routes. You can do routing
>> and no switching, like a route reflector in a NAP.
>>
>> Back to frame relay, a frame relay switch main function is to do data
>> plane switching services, copy frames from one link based on a xconnect
>> table that maps a DLCI to some other link, possibly another DLCI.
>> You don't need LMI up to do so. (Although in real life, I wonder why
>> would you do such a thing).
>>
>> LMI runs on one DLCI to enable DTE to DCE control plane exchange.
>> If you disable it, you can still make the FR switch to switch frames,
>> some FR switches at least can do so.
>>
>> Am I talking nonsense ?
>> -Carlos
>>
>> Narbik Kocharians @ 25/08/2010 20:05 -0300 dixit:
>>> Carlos,
>>>
>>> If the LMIs are disabled (No keep) you won't talk to the Frame-relay
>>> switch, if you are not communicating with the frame switch, it means
>>> that you are not exchanging type 1 messages with Switch, nor
>>> sending Type 0 messages to the switch and as a result of that you
>> won't
>>> get the DLCI info from the switch. So what do you mean the data plane
>>> will work? If the control plane is NOT there, how could the data plane
>>> work? and what do you mean by switching data plane services????
>> Can you
>>> be a little more clear?
>>>
>>>
>>> On Wed, Aug 25, 2010 at 3:26 PM, Kambiz Agahian
>> <aussiecert_at_gmail.com <mailto:aussiecert_at_gmail.com>
>>> <mailto:aussiecert_at_gmail.com <mailto:aussiecert_at_gmail.com>>> wrote:
>>>
>>> Just keep in mind that the FR world did exist before LMI and can
>>> exist after that... :)
>>>
>>>
>>>
>>> Kambiz Agahian
>>> CCIE Instructor/Consultant
>>> M.Eng Telecom, CCIE# 25341, CCSI# 33326, MCSE, MCSA
>>>
>>>
>>> On Wed, Aug 25, 2010 at 3:13 PM, Carlos G Mendioroz
>>> <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>> wrote:
>>>
>>> You got me wrong there.
>>> If you disable LMI, you loose pvc management (knowledge of
>> what the
>>> frame relay switch is doing and state of remote link) but
>> you still
>>> can have the switching (data plane) service.
>>>
>>> Problem is, if the remote end is paying attention to LMI, the
>>> remote DTE
>>> will consider the link down and you might loose connectivity.
>>>
>>> -Carlos
>>>
>>> Narbik Kocharians @ 25/08/2010 19:07 -0300 dixit:
>>>> I agree with Carlos, if you disable the LMIs, then you are
>>> saying i do
>>>> not need the Frame-relay switching services, and
>> connectivity
>>> is lost,
>>>> unless you configure the routers back to back which is NOT
>>> what you are
>>>> asking for. Paul's solution should do the trick, that's if i
>>> understand
>>>> your scenario correctly.
>>>>
>>>> On Wed, Aug 25, 2010 at 1:11 PM, Carlos G Mendioroz
>>> <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
>>>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>>> wrote:
>>>>
>>>> basically you are saying that i don't need the switch
>>> *management*
>>>> any more.
>>>>
>>>> You still need its switching services :)
>>>> -Carlos
>>>> P.S.
>>>> hahahaha
>>>>
>>>> Narbik Kocharians @ 25/8/2010 16:21 -0300 dixit:
>>>>
>>>> If you disable the LMIs, then, you are NOT going to
>>> get any DLCI
>>>> info from
>>>> the switch, basically you are saying that i
>> don't need the
>>>> switch any more.
>>>> But if this is what you want to do then, enter "NO
>>> Keep" under your
>>>> frame-relay interface. You typically do this
>> when you
>>> have a
>>>> back to back
>>>> frame-relay configuration without using the
>>> Frame-relay switch.
>>>> Is this what you wanted?
>>>>
>>>> On Thu, Aug 26, 2010 at 5:11 AM, selamat pagi
>>> <ketimun_at_gmail.com <mailto:ketimun_at_gmail.com>
>> <mailto:ketimun_at_gmail.com <mailto:ketimun_at_gmail.com>>
>>>> <mailto:ketimun_at_gmail.com
>> <mailto:ketimun_at_gmail.com> <mailto:ketimun_at_gmail.com
>> <mailto:ketimun_at_gmail.com>>>>
>>> wrote:
>>>>
>>>> Yep, disabled inverse arp and reloaded. This
>>> clears out the
>>>> mappings in *sh
>>>> fram map.*
>>>> However, the all the other pvc are still in *sh
>>> frame pvc.*
>>>>
>>>> Carlos, how you disable LMI without changing
>> config on
>>>> FR-switch (keepalive
>>>> is enable on FR-switch)
>>>>
>>>> cheers, keti
>>>>
>>>>
>>>>
>>>> On Wed, Aug 25, 2010 at 8:24 PM, Paul Negron
>>>> <negron.paul_at_gmail.com
>> <mailto:negron.paul_at_gmail.com>
>>> <mailto:negron.paul_at_gmail.com
>> <mailto:negron.paul_at_gmail.com>> <mailto:negron.paul_at_gmail.com
>> <mailto:negron.paul_at_gmail.com>
>>> <mailto:negron.paul_at_gmail.com
>> <mailto:negron.paul_at_gmail.com>>>>
>>>> wrote:
>>>>
>>>> Did you try disabling Inverse arp and
>>> reloading the router?
>>>>
>>>> Paul
>>>> --
>>>> Paul Negron
>>>> CCIE# 14856 CCSI# 22752
>>>> Senior Technical Instructor
>>>> www.micronicstraining.com
>> <http://www.micronicstraining.com/>
>>> <http://www.micronicstraining.com/>
>>>> <http://www.micronicstraining.com/>
>>>>
>>>>
>>>>
>>>> From: selamat pagi
>> <ketimun_at_gmail.com <mailto:ketimun_at_gmail.com>
>>> <mailto:ketimun_at_gmail.com <mailto:ketimun_at_gmail.com>>
>>>> <mailto:ketimun_at_gmail.com
>> <mailto:ketimun_at_gmail.com>
>>> <mailto:ketimun_at_gmail.com <mailto:ketimun_at_gmail.com>>>>
>>>> Reply-To: selamat pagi
>> <ketimun_at_gmail.com <mailto:ketimun_at_gmail.com>
>>> <mailto:ketimun_at_gmail.com <mailto:ketimun_at_gmail.com>>
>>>> <mailto:ketimun_at_gmail.com
>> <mailto:ketimun_at_gmail.com>
>>> <mailto:ketimun_at_gmail.com <mailto:ketimun_at_gmail.com>>>>
>>>> Date: Wed, 25 Aug 2010 20:07:44 +0200
>>>> To: Cisco certification
>>> <ccielab_at_groupstudy.com <mailto:ccielab_at_groupstudy.com>
>> <mailto:ccielab_at_groupstudy.com <mailto:ccielab_at_groupstudy.com>>
>>>> <mailto:ccielab_at_groupstudy.com
>> <mailto:ccielab_at_groupstudy.com>
>>> <mailto:ccielab_at_groupstudy.com
>> <mailto:ccielab_at_groupstudy.com>>>>
>>>> Subject: Frame-relay again
>>>>
>>>> I know this has been discussed several
>>> times here,
>>>> but I still don't
>>>> have/understand the solution.
>>>> If there is none, I just will believe it
>>> and can
>>>> continue with
>>>>
>>>> something
>>>>
>>>> more interesting :-)
>>>>
>>>> QUESTION:
>>>> Is there a way to avoid that the
>> FR-switch
>>> responds
>>>> with all the DLCI
>>>> configured ?
>>>> So we will only see our configured
>> PVC in
>>> the output
>>>> of "sh
>>>>
>>>> frame-relay
>>>>
>>>> pvc"
>>>>
>>>> (assumed the FR-switch config cannot be
>>> changed ;-)
>>>>
>>>> I played around with keepalive and
>>>> lmi-n391dte-values, however the
>>>>
>>>> type
>>>>
>>>> 0 I
>>>>
>>>> don't get rid of ..?
>>>>
>>>> thanks, keti
>>>>
>>>>
>>>> Blogs and organic groups at
>>> http://www.ccie.net <http://www.ccie.net/>
>> <http://www.ccie.net/>
>>>> <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 <http://www.ccie.net/>
>>> <http://www.ccie.net/>
>>>> <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
>> <mailto:tron_at_huapi.ba.ar>
>>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
>>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>>>
>>>> LW7 EQI Argentina
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Narbik Kocharians
>>>> CCSI#30832, CCIE# 12410 (R&S, SP, Security)
>>>> www.MicronicsTraining.com
>> <http://www.micronicstraining.com/> <http://www.micronicstraining.com/>
>>> <http://www.MicronicsTraining.com
>> <http://www.micronicstraining.com/>
>>> <http://www.micronicstraining.com/>>
>>>> Sr. Technical Instructor
>>>> YES! We take Cisco Learning Credits!
>>>> Training And Remote Racks available
>>>
>>> --
>>> Carlos G Mendioroz <tron_at_huapi.ba.ar
>> <mailto:tron_at_huapi.ba.ar> <mailto:tron_at_huapi.ba.ar
>> <mailto:tron_at_huapi.ba.ar>>>
>>> LW7 EQI Argentina
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>> <http://www.ccie.net/>
>>> <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 <http://www.micronicstraining.com/>
>> <http://www.MicronicsTraining.com <http://www.micronicstraining.com/>>
>>> Sr. Technical Instructor
>>> YES! We take Cisco Learning Credits!
>>> Training And Remote Racks available
>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
>> LW7 EQI Argentina
>>
>>
>>
>>
>> --
>> Narbik Kocharians
>> CCSI#30832, CCIE# 12410 (R&S, SP, Security)
>> www.MicronicsTraining.com <http://www.MicronicsTraining.com>
>> Sr. Technical Instructor
>> YES! We take Cisco Learning Credits!
>> Training And Remote Racks available
>
> --
> 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 Wed Aug 25 2010 - 21:37:07 ART