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
    1. Advertising

  2. A. Bronson

    Hansang Bae Guest

    In article <>,
    says...
    > 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.


    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.



    --

    hsb

    "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
    #2
    1. Advertising

  3. A. Bronson

    A. Bronson Guest

    Hansang Bae <> wrote in message news:<>...

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


    Here's the output of:
    sh frame lmi

    LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE =
    CISCO
    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:

    http://forum.cisco.com/eforum/servl...md=MB?cmd=display_location&location=.1dd6c3ae
     
    A. Bronson, Nov 30, 2004
    #3
  4. A. Bronson

    Toby Guest

    Hi

    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.

    Regards

    Toby

    "A. Bronson" <> wrote in message
    news:...
    > Hansang Bae <> wrote in message
    > news:<>...
    >
    >> 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.
    >>

    >
    > Here's the output of:
    > sh frame lmi
    >
    > LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE =
    > CISCO
    > 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:
    >
    > http://forum.cisco.com/eforum/servl...md=MB?cmd=display_location&location=.1dd6c3ae
     
    Toby, Nov 30, 2004
    #4
  5. A. Bronson

    Hansang Bae Guest

    In article <>,
    says...
    > 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.


    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.

    http://www.cisco.com/en/US/tech/tk7...ech_note09186a008014f8a7.shtml#serialuplineup


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


    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:

    > First thing is first. Fix your ckt problem. 1464 input errors is a
    > problem - whether that's related to this is a moot point. You have a
    > problem with your circuit. By they way, have you pinged with packet
    > sizes of 1472 and patterns of 0x0000, 0x4040, and 0XFFFF?


    And add 0x8080.


    --

    hsb

    "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
    #5
  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)




    "Hansang Bae" <> wrote in message
    news:...
    > In article <>,
    > says...
    > > 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.

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

    http://www.cisco.com/en/US/tech/tk713/tk237/technologies_tech_note09186a0080
    14f8a7.shtml#serialuplineup
    >
    >
    > >
    > > 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.

    >
    > 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:
    >
    > > First thing is first. Fix your ckt problem. 1464 input errors is a
    > > problem - whether that's related to this is a moot point. You have a
    > > problem with your circuit. By they way, have you pinged with packet
    > > sizes of 1472 and patterns of 0x0000, 0x4040, and 0XFFFF?

    >
    > And add 0x8080.
    >
    >
    > --
    >
    > hsb
    >
    > "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.
    > ********************************************************************
     
    MC, Dec 1, 2004
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jose E. Calderon
    Replies:
    0
    Views:
    652
    Jose E. Calderon
    Oct 23, 2003
  2. Replies:
    11
    Views:
    4,963
    Steinar Haug
    Dec 28, 2003
  3. jmarkotic

    Frame-Relay Inverse ARP problem

    jmarkotic, Jan 7, 2004, in forum: Cisco
    Replies:
    7
    Views:
    3,572
    scott enwright
    Jan 9, 2004
  4. Replies:
    4
    Views:
    1,408
  5. bvlmv
    Replies:
    4
    Views:
    704
    bvlmv
    Jul 14, 2005
Loading...

Share This Page