weird point to point t1 problem

[PcClone]

hello everyone, thanks in advance for looking at this post.

I have a point to point that is showing errors when there is not a lot of traffic on the line.

When I ping from the head end to the remote network there will be no errors on the serial interfaces for 1000's of packets. When I stop pinging, I start getting errors (a few for every 100 packets)

We are using HDLC with inverted data on an AMI/SF line. I was wondering if anyone had any input.

The weird thing is when we start using the VoIP phones, they will show errors on the serial interface as well (Giants, CRC) and we will have interface resets as well.

Thanks again.

 

[BuckWeet]

Sounds like a clocking issue..

 

[PcClone]

I thought it might be too, but I've tried setting the routers to clock source from the line as well as tried one internal then the other internal. The problem still persists.

 

[jeter]

Has the point-to-point circuit been tested?

I am wondering if the setting are correct on the circuit for AMI, SF or B8ZS-ESF....

Also if you go end to end with laptops off the ethernet port on each router do you have similar problems?



Some people are like slinkies.
Not really good for anything but they bring a smile to your face when pushed down the stairs.


Tek-TIP Member 19,650

 

[PcClone]

I have talked to them and they contend that the everything is set for AMI/SF. I know how to test for AMI on a B8ZS line with 0x0000 pings, is there a way to do the opposite?

 

[burtsbees]

Post a sh int from the t1 interface that is getting errors...

Burt

 

[PcClone]

I can't get into the routers remotely for some reason right now, but I thought I'd bring up something I saw when working on the problem today.

The smartjack at one side has it's b8zs light lit up but not the esf. Why would the b8zs light be lit on an AMI line?

a week ago I confirmed with the CLEC that it was provisioned for AMI and they also spoke to the ILEC (AT&T) and they confirmed it was configured for AMI.

Thanks

 

[jneiberger]

Just curious...why are you using AMI for a data circuit?

 

[PcClone]

In this area most point to points I've dealt with are provisioned as AMI/SF. I don't know why but it's been that way. We are in the Chicago suburbs.

 

[jneiberger]

I'm surprised that you would use AMI for data, though. You're going to get errors if your data contains too many zeroes. I would never attempt to use AMI for data if I could avoid it.

Also, if the NIU is reporting that the span is B8ZS, I would say that it is definitely seeing B8ZS no matter what the techs are saying. Have one of them come on-site to see it for themselves.

Or just have them reprovision the line as B8ZS and you'll all be happy.

 

[PcClone]

Well after much fighting, now they are saying that they are seeing errors on their portion of the line (Probably because the smartjack thinks its b8zs).

Also, just an FYI, we have the data coding inverted with HDLC and since HDLC has 0s density when you invert it you have 1s density.

So I'll reply back when I know more from the carrier.

 

[PcClone]

Well, now they are telling me there is no problem on the line. I have put the configs below if someone can find any errors.

naperville-ptp-router#show run
Building configuration...

Current configuration : 1718 bytes
!
! Last configuration change at 20:49:23 CST Wed Dec 5 2007
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname naperville-ptp-router
!
boot-start-marker
boot system flash:c2600-i-mz.123-24.bin
boot-end-marker
!
logging buffered 4096 debugging
enable password 7 ***
!
clock timezone CST -6
no aaa new-model
ip subnet-zero
ip cef
!
!
ip name-server 4.2.2.4
ip name-server 4.2.2.3
!
!
!
!
ip tcp path-mtu-discovery
!
class-map match-any web-traffic
match protocol http
match protocol secure-http
match protocol ftp
match protocol smtp
match protocol pop3
match protocol imap
class-map match-any voip-traffic
match dscp ef
match dscp af31
match ip precedence 5
match protocol rtp
!
!
policy-map qos-policy
class voip-traffic
priority percent 65
class web-traffic
bandwidth remaining percent 100
class class-default
fair-queue
!
!
!
interface FastEthernet0/0
ip address 192.168.1.250 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
ip address 192.168.254.253 255.255.255.252
ip nbar protocol-discovery
no ip mroute-cache
service-module t1 data-coding inverted
service-module t1 framing sf
service-module t1 linecode ami
no cdp enable
service-policy output qos-policy
!
router rip
version 2
redistribute connected
network 192.168.1.0
network 192.168.254.0
no auto-summary
!
ip http server
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
!
!
line con 0
password 7 ***
login
line aux 0
line vty 0 4
password 7 ***
login
!
ntp clock-period 17180381
ntp server 130.126.24.24
ntp server 128.59.59.177
ntp server 130.126.24.44
!
end


Site 2:

palatine-ptp-router#show run
Building configuration...

Current configuration : 1979 bytes
!
! No configuration change since last restart
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname palatine-ptp-router
!
boot-start-marker
boot-end-marker
!
logging buffered 4096 debugging
enable password 7 *
!
clock timezone CST -6
no aaa new-model
ip subnet-zero
ip cef
!
!
ip name-server 4.2.2.4
ip name-server 4.2.2.3
!
!
!
!
!
class-map match-any web-traffic
match protocol http
match protocol secure-http
match protocol ftp
match protocol smtp
match protocol pop3
match protocol imap
match any
class-map match-any voip-traffic
match dscp af31
match dscp ef
class-map match-all web-trafic
!
!
policy-map qos-policy
class voip-traffic
priority percent 65
set dscp ef
class web-traffic
bandwidth remaining percent 100
class class-default
fair-queue
!
!
!
interface FastEthernet0/0
description Local LAN Link for Palatine
ip address 192.168.2.250 255.255.255.0
ip helper-address 192.168.1.5
duplex auto
speed auto
!
interface Serial0/0
description UpLink to NaperVille
ip address 192.168.254.254 255.255.255.252
ip nbar protocol-discovery
no ip mroute-cache
service-module t1 clock source internal
service-module t1 data-coding inverted
service-module t1 framing sf
service-module t1 linecode ami
no cdp enable
service-policy output qos-policy
!
router rip
version 2
redistribute connected
network 192.168.2.0
network 192.168.254.0
no auto-summary
!
ip http server
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.254.253
!
!
snmp-server community public RO
snmp-server location ***
snmp-server contact ***
snmp-server enable traps tty
!
line con 0
password 7 ***
login
line aux 0
line vty 0 4
password 7 ***
login
!
ntp clock-period 17180275
ntp server 130.126.24.24
ntp server 128.59.59.177
ntp server 130.126.24.44
!
end

 

[jneiberger]

This might be similar to a problem I had once. We had a certain file transfer that would fail every time but all other traffic seemed to pass with no problem. I ended up chopping that file up into successively smaller and smaller pieces until I found a 21-byte pattern that would not pass over the link. Very strange. It turned out to be an NIU that was beginning to fail but had not yet completely failed. Perhaps this is a case similar to that. It's not bad enough to trigger any alarms, but it's bad enough to have noticeable symptoms.

 

[PcClone]

I just wanted to update this thread with the solution in case a future user has a problem.

The issue was casused by the HDLC with data-coding inverted.

In a back to back situation this would work (I'm told), however in the real world it can rather easily cause a yellow alarm for the carrier (0 in the second bit of a frame for a long enough period I believe). After seeing a yellow alarm for a bit, something on the line was resetting to try and clear it, causing our issue.

The solution is to remove the data-coding inverted and set the channel speed to 56k instead of 64k

Thanks for all the help.

 

[jneiberger]

Very interesting. Thanks for the follow-up!

 

[brianinms]

I'm confused, this appears to be a point to point T1 ... so I can understand the HDLC issue, but not the channel speed.

 

[PcClone]

brianinms:
For AMI/SF, the normal settings are 56k per channel. However, when using HDLC it has 0's density. For AMI this is bad because you cannot pass 7 0's. So when you invert the data you now have 1s density. In "theory" this works fine so that you can have 64k per channel. In practice, the mux or smartjack or something else doesn't know about it and expected 56k.