On Tue, 18 Jan 2005, John Neiberger wrote:
provisioned for M13, as well. However, Time Warner at the other end of
the link seems to think we're provisioned for C-bit. My question is
this: does that matter?
Yes it does. It would be analogous to having one end of a T1 being
optioned for ESF framing and the other end for SF. T1s don't operate very
well in situations like this and I don't think DS3s would fare much
better.
We see a highly intermittent burst of errors from time to time but
other than that we don't see a problem. It can run for days or weeks
Are the error bursts traffic-related? In other words, do you see errors,
when the traffic on the DS3 hits a certain level? Do you see the errors
on both sides? What does a 'show controller SerialXXX' show from the
routers at each end?
Is it possible that this problem is caused because of c-bit being used
on the Time Warner side of that part of the link?
Yes, or the interaction between the two.
We have three potential courses of action:
1. Get Time Warner to switch to M13
2. Get Qwest to switch to c-bit and change our end devices to c-bit
If either of them are willing to re-option their pieces of the line, or
convert to unframed, then I'd say go for it. If all of the intermediate
pieces are unframed, then the framing would be dictated by your equipment
on both sides. c-bit is normally used on clear-channel DS3 circuits, but
I'd imagine M13 could work too, though probably with more overhead than
c-bit.
3. Do nothing since the errors are brief and infrequent
What do you think? Could the framing mismatch cause a problem, perhaps
similar to an AMI/B8ZS mismatch in the DS1 world?
Definitely.
jms
7 messages in net.nether.puck.cisco-nsp[c-nsp] Re: DS3 framing: M13 vs. C-bit
