DS3 to Ethernet MUX Corrupting Packets?

[d-garnett]

We have an all Ethernet over wireless 802.11A (designed as Point to Point - not running PPPoE)spanning many sites

the post concerns only 2 of the sites

site #1 has a 10Mpbs router (2621) and site #2 has a 10/100 router (2621XM) so that WAN is scaled down to 10Mbps full duplex.

a couple months ago, we replaced all the networking equiptment in site #2 because of a lightning storm (lightning hit the Antenna and static electricity fried everything in it's path Routers and Switches)

With that said after we replaced the equiptment, we began to see a high amount of CRC errors on the WAN link between the 2 sites. I suspect the Multiplexer that is converting ethernet to ds3 format is to blame. all was well before the new products. anyone else seen this before?

^^^^^^Ethernet-DS3-MUX<-------->Ethernet-DS3-MUX

Router#1^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^Router#2

site #1

R1#sho int e1/2

Ethernet1/2 is up, line protocol is up

Hardware is AmdP2, address is 0030.9440.8632 (bia 0030.9440.8632)

Internet address is 172.16.30.1/24

MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

reliability 255/255, txload 2/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters 12w4d

Queueing strategy: fifo

Output queue 0/40, 0 drops; input queue 0/75, 900 drops

5 minute input rate 29000 bits/sec, 24 packets/sec

5 minute output rate 99000 bits/sec, 26 packets/sec

73960530 packets input, 3239582016 bytes, 0 no buffer

Received 3470829 broadcasts, 0 runts, 0 giants, 0 throttles

196039 input errors, 196039 CRC, 97372 frame, 0 overrun, 0 ignored

0 input packets with dribble condition detected

78622028 packets output, 387007812 bytes, 0 underruns

0 output errors, 0 collisions, 5 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

R2# show inter f0/1

FastEthernet0/1 is up, line protocol is up

Hardware is AmdFE, address is 000c.3092.b441 (bia 000c.3092.b441)

Internet address is 172.16.30.2/24

MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

reliability 254/255, txload 1/255, rxload 2/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 10Mb/s, 100BaseTX/FX

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/8/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 86000 bits/sec, 18 packets/sec

5 minute output rate 18000 bits/sec, 17 packets/sec

57172669 packets input, 1402768735 bytes

Received 3701885 broadcasts, 0 runts, 0 giants, 0 throttles<b>

352543 input errors, 352543 CRC, 177295 frame, 0 overrun, 0 ignored</b>

0 watchdog

0 input packets with dribble condition detected

56564734 packets output, 669839161 bytes, 0 underruns

0 output errors, 0 collisions, 4 interface resets

0 babbles, 0 late collision, 0 deferred

7 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

R2#

[rseide]

I'd like to help you with this, but this is a tech support question. I'd suggest that you contact Cisco's Technical Assistance Center for assistance.

[scottmac]

I'm thinking it's more likely a setting between the muxes. The first place I'd check is the settings for "C Bit."

It almost sounds like one side is set for C bit and the other side is set for M13 (M-1-3 or D4 same thing, different terms).

You don't mention what the muxes are, or whether you've looked at the MUX stats to see if the receiver of the mux(es) are showing similar CRC / framing errors.

If the muxes are mutalating the Ethernet, you wouldn't know until the next Ethernet port. You may be able to check by putting a "Sniffer" / protocol analyzer in-between the MUX and the AP/bridge. The analyzer show if the CRC for the Ethernet Frame/packet is correct for the payload. If not, the MUX is transmitting bad data (which could be caused by the DS3 side of the link being misconfigured).

If the data checks OK from the MUX, then there's some other issues at the receiver of the AP; perhaps you have some encaps setting, the cable could be bad/poorly constructed/ out-of-spec, etc ...

I hope for this setup you now have a fiber segment between the rooftop equipment (AP/Antenna) and the rest of your network stuff. I'm still suprised that Cisco doesn't have a "fiber link only" verson of their units, just for external p2p setups.

Take a shot at sniffing the AP--> MUX segment and let us know what you find.

Good Luck

Scott