DS3 (also known as T3) scrambling is not an issue that comes up very often. It's something every network administrator should know about, though. After all, it just might save your bacon.
Some physical layer protocols depend on the transition from 1 to 0 in a frame to maintain clocking. Therefore, a frame that has too many 1s or 0s can cause the physical layer of a DS3 to go into alarm. Generally, this results in errors on the link, but it could result in downtime.
Scrambling was designed to randomize the patterns of 1s and 0s in a frame to ensure physical layer protocols are not tripped up by long sequences. The randomization is done in hardware, so it offers no hit in terms of performance. Once it's enabled, nothing further is required.
It is important to note that scramble must be enabled on both sides of the link. Otherwise, the link will suffer rolling CRC errors and you'll suffer some embarrassment!
To enable scrambling, add the scramble command under the interface configuration:
SLAP(config)# interface Serial 4/1
SLAP(config-if)# scramble
REMINDER: Do that on both sides!
Personally, I went 10 years without needing to enable scrambling on an interface. But, after suffering through the doldrums of figuring out the problem one time, I'm convinced that it should be enabled every time. Since there is no performance hit, and it ensures a circuit that is free from timing slips (caused by long sequences of 1s and 0s, at least), it's well worth it.
Related Reading
- Internetworking Technologies Handbook, Fourth Edition by Cisco Systems Inc.
- Network Management Fundamentals by Alexander Clemm
Get Slaptijack updates delivered to your Inbox or RSS Reader for free!
Just curious what type of a situation(problem) you ran into?
@PP
I've had at least one case in the past where low traffic levels resulted in error problems because the data just wasn't random enough. Enabling scramble on the interface cleared up the problem.
I ran into this same problem. I could traceroute (which sends an incrementing payload, i.e. 0,1,2,3,4,5...) but couldn't mtr across a DS3 (mtr uses all zeros in the payload) as the circuit would go into remote alarm when I ran mtr. Found another reference to 0x0000 issues with DS3s and alerted my telco to the problem, which didn't show up on their bert tests because they don't send 0x0000 in their testing.
Turning scramble on on both sides fixed the problem.