Are they plugged into the same board on the mux? I had a multiport OC12
board in a OC 192 mux behave this way.
If their timing or other setting is off, the hard loop of the two MUX
ports will be tolerant of each other, but when connected to a different
piece of gear you start seeing the errors.
Deepak Jain
AiNET
On Fri, 20 Oct 2000, Mike Gibbs wrote:
>
>
>
> On Fri, 20 Oct 2000, Martin, Christian wrote:
>
> > Nope. If it is muxed service, then you should be OK w/ 'clock source line'.
>
> Have it that way.
>
> >
> > Check the fiber. If the fiber and dB levels are correct, then you may have
> > POS card issues.
> >
>
> Maybe, it is happening on 2 routers on 2 different lines, in which the
> only issue is the same mux that they pllug into.
>
> > chris
> >
> > > -----Original Message-----
> > > From: Mike Gibbs [mailto:gibbs@servint.com]
> > > Sent: Friday, October 20, 2000 12:18 PM
> > > To: Martin, Christian
> > > Cc: cisco-nsp@puck.nether.net
> > > Subject: RE: Problems with a PA-POS card
> > >
> > >
> > > On Fri, 20 Oct 2000, Martin, Christian wrote:
> > >
> > > > How is the network designed? Are these intra-pop
> > > connections (back to back)
> > > > or through a mux? If they are back to back, then you have
> > > to set clocking
> > > > to internal on one (and maybe both) of the cards. In the
> > > case of both, this
> > > > is because there are some issues with Cisco POS chips that
> > > affect clock
> > > > recovery when the timing source is Cisco generated. Maybe
> > > they have a
> > > > Stratum 3.00037 clock??? :)
> > >
> > > Bell south is using Stratum 1 bit clocking. That have the
> > > same problem?
> > >
> > > >
> > > > Check the cards. If you have a T-Berd 310 unit, try
> > > measuring the transmit
> > > > and receive from both cards for an extended period to see
> > > if you are getting
> > > > timing problems.
> > > >
> > > > chris
> > > >
> > > > > -----Original Message-----
> > > > > From: Mike Gibbs [mailto:gibbs@servint.com]
> > > > > Sent: Thursday, October 19, 2000 1:17 PM
> > > > > To: Martin, Christian
> > > > > Cc: cisco-nsp@puck.nether.net
> > > > > Subject: RE: Problems with a PA-POS card
> > > > >
> > > > >
> > > > >
> > > > > Adding to this, all the routers I use, on 2 different
> > > OC-3 lines are
> > > > > saying the same thing. IS there a bad batch of OC-3 cards?
> > > > >
> > > > > On Thu, 19 Oct 2000, Martin, Christian wrote:
> > > > >
> > > > > > Mike,
> > > > > >
> > > > > > You are getting a high number of BIP3 errors. This is
> > > > > generally caused by
> > > > > > bad transmit at the far end, or a problem in the
> > > carrier network.
> > > > > >
> > > > > > Regards,
> > > > > > chris
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Mike Gibbs [mailto:gibbs@servint.com]
> > > > > > > Sent: Thursday, October 19, 2000 10:30 AM
> > > > > > > To: cisco-nsp@puck.nether.net
> > > > > > > Subject: Problems with a PA-POS card
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > What would cause these errors? I assumed it was light
> > > > > > > intensity too high,
> > > > > > > since the telco sent us -12.2 dBm so we built it out to -23
> > > > > > > dBm and are
> > > > > > > getting the same errors.
> > > > > > >
> > > > > > >
> > > > > > > *Oct 18 17:32:38: %SONET-4-ALARM: POS8/0/0: B3 BER exceeds
> > > > > > > threshold, TC alarm declared
> > > > > > > *Oct 18 17:32:48: %SONET-4-ALARM: POS8/0/0: B3 BER below
> > > > > > > threshold, TC alarm cleared
> > > > > > > *Oct 18 17:40:46: %SONET-4-ALARM: POS8/0/0: B3 BER exceeds
> > > > > > > threshold, TC alarm declared
> > > > > > > *Oct 18 17:40:56: %SONET-4-ALARM: POS8/0/0: B3 BER below
> > > > > > > threshold, TC alarm cleared
> > > > > > > *Oct 18 17:46:48: %SONET-4-ALARM: POS8/0/0: B3 BER exceeds
> > > > > > > threshold, TC alarm declared
> > > > > > > *Oct 18 17:46:58: %SONET-4-ALARM: POS8/0/0: B3 BER below
> > > > > > > threshold, TC alarm cleared
> > > > > > > *Oct 18 18:04:09: %SONET-4-ALARM: POS8/0/0: B3 BER exceeds
> > > > > > > threshold, TC alarm declared
> > > > > > >
> > > > > > >
> > > > > > > Cisco Internetwork Operating System Software
> > > > > > > IOS (tm) RSP Software (RSP-K3PV-M), Version 12.0(9)S,
> > > > > EARLY DEPLOYMENT
> > > > > > > RELEASE SOFTWARE (fc1)
> > > > > > > Copyright (c) 1986-2000 by cisco Systems, Inc.
> > > > > > > Compiled Fri 04-Feb-00 20:18 by htseng
> > > > > > > Image text-base: 0x60010908, data-base: 0x60D2E000
> > > > > > >
> > > > > > > ROM: System Bootstrap, Version 11.1(8)CA1, EARLY
> > > > > DEPLOYMENT RELEASE
> > > > > > > SOFTWARE (fc1)
> > > > > > > BOOTFLASH: GS Software (RSP-BOOT-M), Version 11.1(22)CA,
> > > > > > > EARLY DEPLOYMENT
> > > > > > > RELEASE SOFTWARE (fc1)
> > > > > > >
> > > > > > > Telephonica uptime is 1 week, 1 day, 20 hours, 1 minute
> > > > > > > System returned to ROM by reload
> > > > > > > System image file is "slot0:rsp-k3pv-mz_120-9_S.bin"
> > > > > > >
> > > > > > > cisco RSP4 (R5000) processor with 262144K/2072K bytes
> > > of memory.
> > > > > > > R5000 CPU at 200Mhz, Implementation 35, Rev 2.1,
> > > 512KB L2 Cache
> > > > > > > Last reset from power-on
> > > > > > > G.703/E1 software, Version 1.0.
> > > > > > > G.703/JT2 software, Version 1.0.
> > > > > > > X.25 software, Version 3.0.0.
> > > > > > > Chassis Interface.
> > > > > > > 1 GEIP controller (1 GigabitEthernet).
> > > > > > > 1 VIP2 R5K controller (1 POS).
> > > > > > > 1 GigabitEthernet/IEEE 802.3 interface(s)
> > > > > > > 1 Packet over SONET network interface(s)
> > > > > > > 123K bytes of non-volatile configuration memory.
> > > > > > >
> > > > > > > Mike Gibbs
> > > > > > >
> > > > > >
> > > > >
> > > > > Mike Gibbs
> > > > >
> > > >
> > >
> > > Mike Gibbs
> > >
> >
>
> Mike Gibbs
> Director of Engineering and Operations
> ServInt Corp
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:19 EDT