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.

*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>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>> 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>> 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>>> 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>>>
> > 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>>>
> > > 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/>
> > >
> > >
> > >
> > > From: selamat pagi <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>>>
> > > 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>>>
> > > 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/>
> > >
> > >
> >
> _______________________________________________________________________
> > > 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/>
> > >
> > >
> >
> _______________________________________________________________________
> > > 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>>>
> > > 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>>
> > LW7 EQI Argentina
> >
> >
> > Blogs and organic groups at 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> LW7 EQI Argentina
>

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