thank you very much your explanation is crystal clear
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2000 1:50 PM
To: [EMAIL PROTECTED]
Subject: RE: keepalive set in frame-relay circuit?
10 seconds is the default, and should generally be fine. Your circuit is
probably down for some other reason.
Is this a test setup, with the routers connected back-to back (or with
another
cisco as a switch), or is the frame relay circuit a 'real' circuit from a
telco?
Assuming it's a real circuit, try the 'show frame lmi' command. Your 'num
status enq. sent' and 'num status msgs recv' values should be the same (or
very
similar), and non-zero. If they aren't the same, clear the counters, wait a
minute or so, and check again.
If you are not receiving any LMI messages, then you're not talking to the
frame
relay switch. This is not a good thing. Either your router config is wrong
(wrong encapsulation? wrong lmi type? could be a few things) or the telco
service is broken (or dud hardware, potentially).
If the LMI looks OK, try the command 'show frame pvc', or turn on term mon
and
do a 'debug frame lmi' (it's a fairly safe debug to do even in a production
environment, unless your routers are very overloaded or you have zillions of
PVCs. But I take no responsibility if it breaks your network :-). See what
PVCs are defined, and which ones the telco knows about. See if they match
what
you think they should be.
With the debug frame lmi command, you will see (hopefully) LMI messages
coming
from the switch. Check that they're coming in every ten seconds. If not,
change your keepalive to match. Every now and again (every minute on mine,
YMMV) the LMI message will include the status of all the PVCs the switch
knows
about, and their status (I believe the exact format of the messages varies
between frame switch types. On mine, an active PVC has status 0x2, and an
inactive one has status 0x0).
Even if you force the interface up/up by fiddling with the keepalives, it
won't
pass any data if the circuit's broken.
JMcL
---------------------- Forwarded by Jenny Mcleod/NSO/CSDA on 10/10/2000
04:33 pm
---------------------------
"Yee, Jason" <[EMAIL PROTECTED]> on 10/10/2000 11:49:45 am
Please respond to "Yee, Jason" <[EMAIL PROTECTED]>
To: "'Jay Hennigan'" <[EMAIL PROTECTED]>
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc: (bcc: JENNY MCLEOD/NSO/CSDA)
Subject: RE: keepalive set in frame-relay circuit?
if that is the case setting keepalives to what value is optimal?
10 , I tried setting it to 10 but it went down
Jason
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Jay Hennigan
Sent: Monday, October 09, 2000 5:35 PM
To: [EMAIL PROTECTED]
Subject: Re: keepalive set in frame-relay circuit?
On 9 Oct 2000 01:54:14 -0400, Yee, Jason <[EMAIL PROTECTED]> wrote:
:hi anyone
:
:knows why after having set my keepalive to be zero my frame-relay circuit
:straight away went up ie line protocol is up
The keepalive setting on a frame-relay interface determines the LMI
interval.
Turning it off stops the router from sending or expecting LMI.
:I believe there is no need to set keepalive as the LMI is taking care of it
:right?
The keepalive of an interface with frame-relay encapsulation _is_ LMI.
:Correct me if I am wrong
Can you pass traffic over the interface with no keepalive? No keepalive
is a means of forcing an interface into an up-up state from the router's
viewpoint even if the interface may in fact be disconnected. While this
is useful for test purposes, it doesn't carry any traffic. While the
interface shows "line protocol is up" with or without anything plugged in
it isn't going to move data from point A to point B.
If it _is_ connected, and the other end also is set to "no keepalive",
then in most cases you can use it to pass data. However, this is not
usually a good idea because the routers will have no means of detecting
a link failure (other than timeouts on a dynamic routing protocol).
If this frame-relay interface is connected to a real carrier's frame
switch, then the "no keepalive" will cause the router to stop sending
LMI, which will cause the carrier's switch to show the link as inactive.
You may be able to make it work in a lab situation with no keepalive
on a router configured as a frame switch, but it isn't a good idea.
As a rule, keepalives are a good thing on an active interface passing
real-world traffic, and turning them off should not be necessary to
bring the line protocol up.
--
Jay Hennigan - Network Administration - [EMAIL PROTECTED]
NetLojix Communications, Inc. NASDAQ: NETX - http://www.netlojix.com/
WestNet: Connecting you to the planet. 805 884-6323
**NOTE: New CCNA/CCDA List has been formed. For more information go to
http://www.groupstudy.com/list/Associates.html
_________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
**NOTE: New CCNA/CCDA List has been formed. For more information go to
http://www.groupstudy.com/list/Associates.html
_________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
**NOTE: New CCNA/CCDA List has been formed. For more information go to
http://www.groupstudy.com/list/Associates.html
_________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
**NOTE: New CCNA/CCDA List has been formed. For more information go to
http://www.groupstudy.com/list/Associates.html
_________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
