Funky P-t-P T1, SBC says I have a timing problem, I say BS...

Discussion in 'Cisco' started by Doug, Jul 24, 2004.

  1. Doug

    Doug Guest

    Cisco 1600 on one end, 1700 on the other, both have WIC-DSU-T1 in
    them. Circuit was randomly failing, rebooting routers didn't always
    restore service. However, if SBC entered the circuit, looped &
    dropped, the circuit would always come back up. Taking tons of
    errors, mostly CRC.. had over 22,000 errors in 32 hours.

    Their testing says nothing is wrong, but claim to see that I have a
    timing problem. I call bullshit since this circuit has worked just
    fine for several years. I have swapped WIC's & routers on both ends.
    The circuit stopped failing, but the errors still persist. I
    contribute that to maybe one of the original routers was just less
    tollerent of the line errors.

    Here's my config, using in lots of other places without issue. Taken
    from cheat sheet for my co-workers...




    Would you like to enter the initial configuration dialog? [yes]: no

    Router> enable
    Router# config t
    Router(config)# hostname (what you want to name the router)
    Router(config)# enable secret (what you want the "enable" password to
    be)
    Router(config)# end

    Router# config t
    Router(config)# interface fastethernet0
    Router(config-if)# ip address <LAN address> <subnet mask>
    Router(config-if)# ip helper-address (DHCP, DNS, WINS servers one at a
    time, not required, only on remote routers)
    Router(config-if)# no shutdown
    Router(config-if)# end

    Router# config t
    Router(config)# interface serial0
    Router(config-if)# ip address <WAN address> <subnet mask>
    Router(config-if)# encapsulation ppp
    Router(config-if)# no cdp enable
    Router(config-if)# service-module t1 clock source line
    Router(config-if)# service-module t1 timeslots 1-24 speed 64
    Router(config-if)# service-module t1 framing esf
    Router(config-if)# service-module t1 linecode b8zs
    Router(config-if)# fair que (older IOS may only be "fair")
    Router(config-if)# no shutdown
    Router(config-if)# end

    Router# config t
    Router(config)# ip route <other LAN IP> <subnet mask> <other Serial
    IP> <metric> permanent
    Router(config)# end

    Router# config t
    Router(config)# line con 0
    Router(config)# password <console password>
    Router(config)# login
    Router(config)# line aux 0
    Router(config)# line vty 0 4
    Router(config)# password <telnet password>
    Router(config)# login
    Router(config)# end

    Router# write memory
    Router# reload
     
    Doug, Jul 24, 2004
    #1
    1. Advertisements

  2. Doug

    Scooby Guest

    "Doug" <> wrote in message
    news:...
    > Cisco 1600 on one end, 1700 on the other, both have WIC-DSU-T1 in
    > them. Circuit was randomly failing, rebooting routers didn't always
    > restore service. However, if SBC entered the circuit, looped &
    > dropped, the circuit would always come back up. Taking tons of
    > errors, mostly CRC.. had over 22,000 errors in 32 hours.
    >
    > Their testing says nothing is wrong, but claim to see that I have a
    > timing problem. I call bullshit since this circuit has worked just
    > fine for several years. I have swapped WIC's & routers on both ends.
    > The circuit stopped failing, but the errors still persist. I
    > contribute that to maybe one of the original routers was just less
    > tollerent of the line errors.
    >
    > Here's my config, using in lots of other places without issue. Taken
    > from cheat sheet for my co-workers...
    >
    >
    >
    >
    > Would you like to enter the initial configuration dialog? [yes]: no
    >
    > Router> enable
    > Router# config t
    > Router(config)# hostname (what you want to name the router)
    > Router(config)# enable secret (what you want the "enable" password to
    > be)
    > Router(config)# end
    >
    > Router# config t
    > Router(config)# interface fastethernet0
    > Router(config-if)# ip address <LAN address> <subnet mask>
    > Router(config-if)# ip helper-address (DHCP, DNS, WINS servers one at a
    > time, not required, only on remote routers)
    > Router(config-if)# no shutdown
    > Router(config-if)# end
    >
    > Router# config t
    > Router(config)# interface serial0
    > Router(config-if)# ip address <WAN address> <subnet mask>
    > Router(config-if)# encapsulation ppp
    > Router(config-if)# no cdp enable
    > Router(config-if)# service-module t1 clock source line
    > Router(config-if)# service-module t1 timeslots 1-24 speed 64
    > Router(config-if)# service-module t1 framing esf
    > Router(config-if)# service-module t1 linecode b8zs
    > Router(config-if)# fair que (older IOS may only be "fair")
    > Router(config-if)# no shutdown
    > Router(config-if)# end
    >
    > Router# config t
    > Router(config)# ip route <other LAN IP> <subnet mask> <other Serial
    > IP> <metric> permanent
    > Router(config)# end
    >
    > Router# config t
    > Router(config)# line con 0
    > Router(config)# password <console password>
    > Router(config)# login
    > Router(config)# line aux 0
    > Router(config)# line vty 0 4
    > Router(config)# password <telnet password>
    > Router(config)# login
    > Router(config)# end
    >
    > Router# write memory
    > Router# reload


    Doug,

    Make sure that you are not using service-module t1 clock source line on both
    ends. One side needs to be internal. In p2p links, the telco does not
    provide timing. This is something that can appear to work fine for a long
    time and then just fail. Other than that, looks good to me. Perhaps your
    internal csu/dsu cards are wigging out - got any to swap em out with? Last
    resort, I'd make them come change the smart jacks.

    Hope that helps,

    Jim
     
    Scooby, Jul 24, 2004
    #2
    1. Advertisements

  3. Doug

    Doug Guest

    Thanks Jim, I think it did! No errors in 36+ minutes.

    I'm not that Cisco savy, and based on some articles I had read that said
    "clock source line" on both ends was typical. Like Cisco Document ID
    10265....

    " In most applications, the CSU/DSU should be configured with the clock
    source line. For back-to-back configurations, one CSU/DSU should be
    configured with clock source internal and the other with clock source line.
    "

    Anyhow, I sincerely appreciate your assistance and will update my
    documentation AND fix the other P-t-P routers I've done this way!




    > Doug,
    >
    > Make sure that you are not using service-module t1 clock source line on

    both
    > ends. One side needs to be internal. In p2p links, the telco does not
    > provide timing. This is something that can appear to work fine for a long
    > time and then just fail. Other than that, looks good to me. Perhaps your
    > internal csu/dsu cards are wigging out - got any to swap em out with?

    Last
    > resort, I'd make them come change the smart jacks.
    >
    > Hope that helps,
    >
    > Jim
    >
    >
     
    Doug, Jul 24, 2004
    #3
  4. Doug

    Scooby Guest

    Doug,

    Good news!!! It's always nice when the nagging ones go away. Anyway, this
    is not really a Cisco thing, it is more of an interface standard. T1's are
    a techonology that requires a clock to operate correctly. When using a
    technology like Frame Relay, you would set to use the line, since the telco
    will provide the clock. However, on a p2p, the telco does not do this,
    which is why you need to set one side to do clocking. The p2p is much the
    same as the back-to-back you mentioned below.

    Jim


    "Doug" <> wrote in message
    news:xAxMc.21491$eM2.17221@attbi_s51...
    > Thanks Jim, I think it did! No errors in 36+ minutes.
    >
    > I'm not that Cisco savy, and based on some articles I had read that said
    > "clock source line" on both ends was typical. Like Cisco Document ID
    > 10265....
    >
    > " In most applications, the CSU/DSU should be configured with the clock
    > source line. For back-to-back configurations, one CSU/DSU should be
    > configured with clock source internal and the other with clock source

    line.
    > "
    >
    > Anyhow, I sincerely appreciate your assistance and will update my
    > documentation AND fix the other P-t-P routers I've done this way!
    >
    >
    >
    >
    > > Doug,
    > >
    > > Make sure that you are not using service-module t1 clock source line on

    > both
    > > ends. One side needs to be internal. In p2p links, the telco does not
    > > provide timing. This is something that can appear to work fine for a

    long
    > > time and then just fail. Other than that, looks good to me. Perhaps

    your
    > > internal csu/dsu cards are wigging out - got any to swap em out with?

    > Last
    > > resort, I'd make them come change the smart jacks.
    > >
    > > Hope that helps,
    > >
    > > Jim
    > >
    > >

    >
    >
     
    Scooby, Jul 24, 2004
    #4
  5. Doug

    MC Guest

    Poit-to-point lines can use either, depends on how the circuit is
    configured.

    If the circuit is a full T1 and only being repeated from end to end most
    likely would need provide clock on one end.

    However, Can be configured with the telco to provide clocking in case of
    fractional T1 where may be muxed and also could be a shared circuit.

    I always order point-to-point circuits from our primary vendor even if just
    going just a short distance. They run through their POP for monitoring and I
    have them provide clocking which is more stable than the clock source in the
    router itself.


    "Scooby" <> wrote in message
    news:4XxMc.13611$...
    > Doug,
    >
    > Good news!!! It's always nice when the nagging ones go away. Anyway,

    this
    > is not really a Cisco thing, it is more of an interface standard. T1's

    are
    > a techonology that requires a clock to operate correctly. When using a
    > technology like Frame Relay, you would set to use the line, since the

    telco
    > will provide the clock. However, on a p2p, the telco does not do this,
    > which is why you need to set one side to do clocking. The p2p is much the
    > same as the back-to-back you mentioned below.
    >
    > Jim
    >
    >
    > "Doug" <> wrote in message
    > news:xAxMc.21491$eM2.17221@attbi_s51...
    > > Thanks Jim, I think it did! No errors in 36+ minutes.
    > >
    > > I'm not that Cisco savy, and based on some articles I had read that said
    > > "clock source line" on both ends was typical. Like Cisco Document ID
    > > 10265....
    > >
    > > " In most applications, the CSU/DSU should be configured with the clock
    > > source line. For back-to-back configurations, one CSU/DSU should be
    > > configured with clock source internal and the other with clock source

    > line.
    > > "
    > >
    > > Anyhow, I sincerely appreciate your assistance and will update my
    > > documentation AND fix the other P-t-P routers I've done this way!
    > >
    > >
    > >
    > >
    > > > Doug,
    > > >
    > > > Make sure that you are not using service-module t1 clock source line

    on
    > > both
    > > > ends. One side needs to be internal. In p2p links, the telco does

    not
    > > > provide timing. This is something that can appear to work fine for a

    > long
    > > > time and then just fail. Other than that, looks good to me. Perhaps

    > your
    > > > internal csu/dsu cards are wigging out - got any to swap em out with?

    > > Last
    > > > resort, I'd make them come change the smart jacks.
    > > >
    > > > Hope that helps,
    > > >
    > > > Jim
    > > >
    > > >

    > >
    > >

    >
    >
     
    MC, Jul 25, 2004
    #5
    1. Advertisements

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. Scratch
    Replies:
    2
    Views:
    440
    °Mike°
    May 13, 2005
  2. Anon

    You say SIM, I say SEM

    Anon, Mar 17, 2006, in forum: Computer Security
    Replies:
    1
    Views:
    607
    Randal T. Rioux
    Mar 18, 2006
  3. Frosty
    Replies:
    8
    Views:
    459
    Frosty
    Mar 3, 2007
  4. ardz

    Telecom says "We didnt say that"

    ardz, Nov 6, 2005, in forum: NZ Computing
    Replies:
    16
    Views:
    592
    Rob J
    Nov 9, 2005
  5. Lawrence D'Oliveiro
    Replies:
    2
    Views:
    656
    Gordon
    Oct 6, 2010
Loading...

Share This Page