06-02-2008 05:33 PM - edited 03-03-2019 10:12 PM
we've been working to isolate what has been causing the errors on the WAN.It has been tested to the DSU clean.
Can please someone check if there's any possible issue with the config?It's a
DS3 link.
Thanks
version 12.3
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname
!
boot-start-marker
boot-end-marker
!
logging buffered 4096 debugging
enable password cisco
!
voice-card 0
dspfarm
!
no aaa new-model
ip subnet-zero
ip cef
!
!
no ip domain lookup
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
description
ip address 176.3.1.1 255.255.255.0
speed 100
full-duplex
no cdp enable
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface ATM1/0
mtu 1500
bandwidth 5000
no ip address
load-interval 30
atm scrambling cell-payload
no atm ilmi-keepalive
!
interface ATM1/0.1 point-to-point
description
ip address 172.32.1.2 255.255.255.0
pvc 2/33
vbr-nrt 5000 4000 100
oam-pvc manage 0
encapsulation aal5snap
!
!
router eigrp 110
redistribute connected
redistribute static
network 172.32.1.0 0.0.0.255
default-metric 64 100 250 250 1500
no auto-summary
!
ip http server
ip classless
!
!
access-list 1 permit 172.*.*.* 0.0.0.255
access-list 1 permit 172.*.*.* 0.0.0.255
access-list 1 permit 172.*.*.* 0.0.0.255
no cdp run
!
snmp-server community
snmp-server community
snmp-server host 10.*.*.*
snmp-server host 130.*.*.*
!
!
!
!
!
!
line con 0
exec-timeout 5 0
password
logging synchronous
login
line aux 0
exec-timeout 0 0
password
logging synchronous
login
modem InOut
transport input all
flowcontrol hardware
line vty 0 4
access-class 1 in
exec-timeout 5 0
password
logging synchronous
login
!
ntp clock-period 17207680
ntp server 172.31.10.2
!
end
Solved! Go to Solution.
06-08-2008 12:54 PM
thank you very much for the assistance.
does it make sense that we're tested it clean
from the carrier node with a remote loop from our CE for hours, and still we did not see anything suspicious.No cell drops at the carrier's switch.
Is there any concrete explanation why those stong/weak signal caused errors were'nt pick
up by our previous tests...
They just started throwing questions at me now...I suspected in the beginning of the stong signals, I just did not have enough knowledge to explain and convince them...
06-08-2008 01:33 PM
Hi, the point it that loopback alone is not enough sometime.
For the circuit to test clean, you need a bert testing with either controller loopback, or physical (tx to rx with cable).
Do this first, any serious telco must be able to do a bert testing.
06-08-2008 01:47 PM
thank you very much for the help...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide