BERT

So yes it’s been a while since my last post. I’ve been busy going back to school working on a BS in Electrical Engineering. Additionally got a promotion at work now Sr. Network Engineer, anyway on to the reason for the post.

Bit Error Rate Test – BERT
http://en.wikipedia.org/wiki/Bit_error_rate

I’m working on swing over to a new DS3 this weekend at work. This will be my first DS3 turn up and it turns out it’s just an over grown T1 for all extensive purposes. One important thing that I’ve learned to do though before moving production traffic is make sure L1 & L2 are actually functional. This is where BERT comes in.

I’ve worked with the provider to put a loop facing the new end of the DS3. On the interface I have the following config:

description Unused
bandwidth 44210
no ip address
no keepalive
dsu bandwidth 44210
scramble
framing c-bit
cablelength 10

I show the interface is UP UP so at least I know I have my RX and TX side of the cables connected correctly. To kick off the BERT we must make sure keep alives are disabled which you can see above it is.

From the system we issue the following command under the interface. (this may vary by platform):
bert pattern qrss interval

In this case I’m running the test for 12 hours as I want to be absolutely certain this circuit is ready to pass production traffic. Notice how I’ve used QRSS.

Per Wikipedia - QRSS (Quasi Random Signal Source) – A pseudorandom binary sequencer which generates every combination of a 20-bit word, repeats every 1,048,575 bits, and suppresses consecutive zeros to no more than 14. It contains high-density sequences, low-density sequences, and sequences that change from low to high and vice versa. This pattern is also the standard pattern used to measure jitter.

This is as close to real life traffic you can create with a simulated test. If it passes this I should be in good shape to go assuming L3 and up play nice but at that point it’s my problem to deal with.

From this point we can go back to enabled exec mode and check the progress by issuing:
show controllers serial 3/0/1

At the bottom we see:
BERT test result (running)
Test Pattern : 2^20 qrss, Status : Sync, Sync Detected : 1
Interval 720 minute(s), Time Remain : 11:27:40
Bit Errors (since BERT started): 0 bits,
Bits Received (since BERT started): 86115 Mbits
Bit Errors (since last sync): 0 bits
Bits Received (since last sync): 86115 Mbits
MDL transmission is disabled

As you can see we’ve been going for about 30 minutes with no errors so this is looking good.

CCNA Voice Study – Installing CUCME PART 1

CUCME is comprised of multiple files and file types compared to a single unified Bin file like IOS. CUCME is comprised of the following: Basic Files, GUI Files, XME Temple File, Music on Hold (MOH) Files, Script Files, and Miscellaneous Files.

To install CUCME you must first have a matching IOS version to support it such as advanced IP services or advanced enterprise services. See the Cisco download area for the proper IOS version to download to match with the CUCME version you will be installing.

Once the IOS is upgraded issue the following command:
Archive tar /xtract tftp://(ip address)/cme-full-7.0.tar flash:

Replace the details above to your actual release. This will then TFTP the tar file and extract it in real time to the flash storage. Now that all the files are on the router we need to make them accessible to the IP phones for their firmware etc. Issue the following commands:

Tftp-server flash:/phone/7940-7960/P00308000500.bin alias P00308000500.bin

What this is doing is telling the router to share out that Pxxx file via TFTP and also should a device just ask for that file and not provide a full path it will still send it. This is important as the phones will only ask for the file and not the path where that file resides. Do this for all the remaining files in that folder adjusting file names accordingly. You will also need to repeat this process for all the backgrounds, MOH files ect that the phones will need.

Now that the files are served up we need to configure some of the CUCME parameters. The majority of the commands will be issued under the telephony-service configuration mode. Four key things must be configured for the ISR to service IP Phones.

Maximum Number of Phones and DNs
Firmware load files
Source IP address information
Generated configuration files.

Commands are as follows:
Max-ephones (number of phones you’re licensed for)
Max-dn (number of lines, if you had four 2 line phones this would be 8)
Load 7960-7940 (or phone model you’re using) P00308000500
If you don’t know what firmware to use Google CME 7.x and your phone model, there will be a firmware version specified by Cisco.

More to come in part 2.