6

I'm Having problem with CRC on E1 interface, after I found clock slips, I have configured "network-clock-participate wic" and "network-clock-select". But I think that is not the cause of CRC, when I ping and packet loss occurs, its always 10 consecutive packets, and CRC counter increases accordingly.

PS: No CRC on PE side. Provider has checked the SDH, it should be error free.

Thanks for any advice.

Add Config:

CE#sh run | sec troller|clock|0/1/0
network-clock-participate wic 1 
network-clock-select 1 E1 0/1/0
controller E1 0/1/0
 framing NO-CRC4 
 channel-group 1 timeslots 1
interface Serial0/1/0:1
 description WAN to CUP
 ip address 172.16.192.110 255.255.255.252

CE#ping 172.16.192.109 re 1000 
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 172.16.192.109, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!..........!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (990/1000), round-trip min/avg/max = 180/187/232 ms
CE#

CE#ping 172.16.192.109  re 1000 si 1500
Type escape sequence to abort.
Sending 1000, 1500-byte ICMP Echos to 144.217.237.73, timeout is 2 seconds:
!!..........!!!!!!!!

Success rate is 50 percent (10/20), round-trip min/avg/max = 548/551/576 ms


CE#sh controllers e1
E1 0/1/0 is up.
Applique type is Channelized E1 - balanced
No alarms detected.
alarm-trigger is not set
Version info FPGA Rev: 08121917, FPGA Type: PRK1
Framing is NO-CRC4, Line Code is HDB3, Clock Source is Line.
International Bit: 1, National Bits: 11111
Data in current interval (839 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 24 hours)
0 Line Code Violations, 0 Path Code Violations,
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
1 Errored Secs, 1 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
CE#


CE#sh int s0/1/0:1
Serial0/1/0:1 is up, line protocol is up 
Hardware is DSX1
Description: WAN to CUP
Internet address is 172.16.192.110/30
MTU 1500 bytes, BW 64 Kbit/sec, DLY 20000 usec, 
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:37:09
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
6046 packets input, 437043 bytes, 0 no buffer
Received 218 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles 
123 input errors, 123 CRC, 0 frame, 0 overrun, 0 ignored, 123 abort
6605 packets output, 528735 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
CE#
pswolfwind
  • 61
  • 2
  • You should edit your question to include the controller and serial configurations, along with your clock configurations. – Ron Maupin Jun 03 '16 at 03:28
  • You didn't set the clock source under the controller, and it defaults to line. You should ask your provider how you should set that. The controller is seeing errors, and that will translate to errors on the serial line. – Ron Maupin Jun 03 '16 at 04:05
  • Hi Ron, Clock master is the PE, that 1 Errored Secs probably is not the casue. I had not seen any error before I posted this, and I have keep doing ping test for a few days, all show similar packet loss pattern. There is a "modem" between CE and SDH, would it be the cause? – pswolfwind Jun 03 '16 at 05:02
  • "Provider has checked the SDH, it should be error free" This does not sound as it is error-free. You have following options by now, make the DCE (modem) powerless for ca. 1 minute A-side and B-side. Then recheck if the error still occurs. Then make the router powerless. Same procedure here, check if the the error still ocurrs. Finally ask your provider to re-provision the line in their backbone. –  Mar 21 '19 at 12:20

0 Answers0