Intermittent problem with Frame Relay circuits

Discussion in 'Cisco' started by A. Bronson, Nov 30, 2004.

  1. A. Bronson

    A. Bronson Guest

    Here's the problem: Every few hours or so, we stop receiving packets
    on either one of two Serial interfaces on our Cisco 2610 router.
    However, the interface line protocol stays "up" the whole time.
    Reloading the router fixes the problem temporarily, as does "shutdown"
    then "no shutdown" on the interface in question. Our ISP and Frame
    Relay providers (separate entities) said it was probably our router,
    so we bought a new one, and it's still happening. Now, both said
    entities are pointing fingers at each other instead of fixing the
    problem. Can anyone help? I can provide any information that I can
    get from our router, and some from those other two parties involved.
    Any help would be greatly appreciated.
    A. Bronson, Nov 30, 2004
    1. Advertisements

  2. A. Bronson

    Hansang Bae Guest

    YOu can look at the lmi with "sho frame lmi" command. You can also run
    a debug on LMI to see the exact nature. My guess is that you are
    running into an IOS bug of some sort. But easy way to test this would
    be to start throwing up loopbacks to see when/where it's breaking.



    "Somehow I imagined this experience would be more rewarding" Calvin
    *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    Hansang Bae, Nov 30, 2004
    1. Advertisements

  3. A. Bronson

    A. Bronson Guest

    Here's the output of:
    sh frame lmi

    LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE =
    Invalid Unnumbered info 0 Invalid Prot Disc 0
    Invalid dummy Call Ref 0 Invalid Msg Type 0
    Invalid Status Message 0 Invalid Lock Shift 0
    Invalid Information ID 0 Invalid Report IE Len 0
    Invalid Report Request 0 Invalid Keep IE Len 0
    Num Status Enq. Sent 11088 Num Status msgs Rcvd 11086
    Num Update Status Rcvd 0 Num Status Timeouts 2

    This doesn't seem out of the ordinary. Two timeouts, but my ISP says
    that's normal enough.
    How do I run a debug on LMI, and what would that show me?

    We tried putting a loopback on the Frame Relay provider's "smart
    jack", and their circuit tested good. But this is an intermittent
    problem, only happening every few hours, and we can't afford much
    downtime. Perhaps the next time it goes out, I can plug that loopback
    in and call them to test it.

    Thanks for your help. This discussion is also happening on the Cisco
    Net Pro site, if you're interested in reading more. Most of my
    config, etc, is posted there.

    Cisco Net Pro Conversation:
    A. Bronson, Nov 30, 2004
  4. A. Bronson

    Toby Guest


    I dont like to see timeouts over a short period. Your LMI stats shows 2
    timeouts in 30 hours. i.e. 1 lmi per ten seconds. Although this doesn't
    sound a lot 2 in 11,000 = 1 per 5000, how many other frames have been
    affected in between the lmi's.

    I know youv'e change your equipment so your router should be fine (if this
    is not an IOS bug). Does your log state if the problem is PVC based (sub
    interface) or interface based including protocol. 2 LMI failures even if
    concurrent wont bring the protocol down by default (takes 3). but this could
    be indicative to errors in your transmit to the frame relay provider.

    Check your Interface stats for CRC errors if clean then get your service
    provider to show their stats. CRC, LMI mismatches etc. If you or the service
    provider are seeing CRC's incrementing there is a problem with either the
    line or interface cable. If the problem is only seen with LMI i.e. you see
    timeouts and service provider sees mismatches and there are no CRC errors at
    either end then suspect a bug in the IOS. If log shows PVC problems then
    you could have a remote site problem (but could still be with the SP).

    Possibly worth starting from scratch and clearing all your counters, as just
    rebooting the device or re-connecting interfaces will cause some timeouts
    before things stabalise, so clear those counters so you can tie things
    together. just remember the following. If the logs shows PVC problems these
    are usually the Remote site (or SP problems), If the log shows Line protocol
    problems this is usually an interface/cable/line to SP problem (use show
    interface and show frame-relay lmi to help diagnose the problem) and if the
    interface itself goes down this is the physical line usually from your
    router to CSU/DSU.


    Toby, Nov 30, 2004
  5. A. Bronson

    Hansang Bae Guest

    That will most likely 'fix' the problem....I.e. bouncing it will bring
    it back up . See the link below for more info on lmi debug and what the
    status code can tell you.

    I don't really care for Cisco forum (I can only spare enough time for
    usenet) but I did look at your post. I see that you got one remote
    alarm. So I would tend to think this is a circuit problem.

    BTW, you should stress the line as well. From my previous post:
    And add 0x8080.



    "Somehow I imagined this experience would be more rewarding" Calvin
    *************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
    Due to the volume of email that I receive, I may not not be able to
    reply to emails sent to my account. Please post a followup instead.
    Hansang Bae, Dec 1, 2004
  6. A. Bronson

    MC Guest

    Frame relay does not like any errors on the physical circuit/access as does
    not handle on the fly error correction itself like x.25, utilizes the higher
    application layers (like TCP) to do that. so any errors on the access can
    cause the frame service to bounce if misses status polls, etc,

    Most of the time I get these problems is a dirty T1 access (if copper) or a
    frame switch/mux port bad at the provider.

    Check the physical serial port for any CRC or other errors, start by
    zero-ing the counters and checking for new errors if it happens again, run
    debug on LMI to see if missing LMI status/polls. I have seen where was
    getting a status every time but the PVC info was missing occasionally, was a
    problem with the PVC mapping or something on the frame switch (what the
    provider claimed)
    MC, Dec 1, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.