E1 Up/Down Issue

[srpm]

So I have an E1 in India connected to a 2911 that has been nothing but problems since we connected it.  It is going up and down quite frequently, but dealing with the carrier over there through our local contact has been quite problematic.  To give you an idea, when this was first reported to them they came out, swapped the power cable to their device and told us to reboot our gateway as that would fix the problem.  LOL!

Anyway, I've been troubleshooting as much as I can and want some hard evidence that it's them.  Our controller is showing tons of errors:

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 CRC4, Line Code is HDB3, Clock Source is Line.
  International Bit: 1, National Bits: 11111
  Data in current interval (607 seconds elapsed):
     0 Line Code Violations, 41271 Path Code Violations
     9 Slip Secs, 4 Fr Loss Secs, 0 Line Err Secs, 1 Degraded Mins
     94 Errored Secs, 28 Bursty Err Secs, 18 Severely Err Secs, 4 Unavail Secs
  Total Data (last 11 15 minute intervals):
     0 Line Code Violations, 1706511 Path Code Violations,
     81 Slip Secs, 87 Fr Loss Secs, 0 Line Err Secs, 32 Degraded Mins,
     3707 Errored Secs, 489 Bursty Err Secs, 275 Severely Err Secs, 48 Unavail Secs

I turned on q921 debugging and am getting this constantly in the logs:

097200: Oct 29 00:07:38.803 IST: ISDN Se0/1/0:15 Q921: L2_EstablishDataLink: sending SABME
097201: Oct 29 00:07:38.803 IST: ISDN Se0/1/0:15 Q921: User TX -> SABMEp sapi=0 tei=0
097202: Oct 29 00:07:38.811 IST: ISDN Se0/1/0:15 Q921: User RX <- UAf sapi=0 tei=0
097203: Oct 29 00:07:48.807 IST: ISDN Se0/1/0:15 Q921: User RX <- RRp sapi=0 tei=0 nr=0
097204: Oct 29 00:07:48.807 IST: ISDN Se0/1/0:15 Q921: User TX -> RRf sapi=0 tei=0 nr=0
097205: Oct 29 00:07:58.807 IST: ISDN Se0/1/0:15 Q921: User TX -> RRp sapi=0 tei=0 nr=0
097206: Oct 29 00:07:58.815 IST: ISDN Se0/1/0:15 Q921: User RX <- RRf sapi=0 tei=0 nr=0
097207: Oct 29 00:08:08.811 IST: ISDN Se0/1/0:15 Q921: User RX <- RRp sapi=0 tei=0 nr=0
097208: Oct 29 00:08:08.811 IST: ISDN Se0/1/0:15 Q921: User TX -> RRf sapi=0 tei=0 nr=0
097209: Oct 29 00:08:09.795 IST: %CONTROLLER-5-UPDOWN: Controller E1 0/1/0, changed state to down (10 SES)
097210: Oct 29 00:08:09.795 IST: %MARS_NETCLK-3-CLK_TRANS: Network clock source transitioned from priority 1 to priority 10
097211: Oct 29 00:08:10.795 IST: %CONTROLLER-5-UPDOWN: Controller E1 0/1/0, changed state to up

I'm actually not certain what that is indicating, but am pretty sure it's saying something is wrong on their side.  Either that or they gave us the wrong information about framing and linecode and that is what is causing all of the issues.

Any other suggestions on what I can do to troubleshoot or is this clearly a case where the carrier will have to fix something?

 

[Jayanth Velkuri]

pls post your running config

[Carlo Poggiarelli]

Hi.

With this statistic, two things I would check.

First Cabling quality between 2911 and TSP Device.

Second, but most probable, an Issue with TSP equipment.

Let us know

Regards

Carlo

[Aman Soi]

Hi,

Since u are getting lot of CRC and slips, did u get the media checked.

You can try giving physical loop from your side and ask Telco to check.

can u also share show inventory/show diag from 2911 and show version?

regds,

aman

[srpm]

Here is the inventory and version.

NAME: "CISCO2911/K9 chassis", DESCR: "CISCO2911/K9 chassis"
PID: CISCO2911/K9      , VID: V07 , SN: FGL17491136

NAME: "VWIC3-1MFT-T1/E1 - 1-Port RJ-48 Multiflex Trunk - T1/E1 on Slot 0 SubSlot 1", DESCR: "VWIC3-1MFT-T1/E1 - 1-Port RJ-48 Multiflex Trunk - T1/E1"
PID: VWIC3-1MFT-T1/E1  , VID: V01 , SN: FOC17478R9G

NAME: "PVDM3 DSP DIMM with 64 Channels on Slot 0 SubSlot 4", DESCR: "PVDM3 DSP DIMM with 64 Channels"
PID: PVDM3-64          , VID: V01 , SN: FOC174596SY

NAME: "C2911 AC Power Supply", DESCR: "C2911 AC Power Supply"
PID: PWR-2911-AC       , VID: V05 , SN: DCA1744R1T0

Cisco CISCO2911/K9 (revision 1.0) with 483328K/40960K bytes of memory.
Processor board ID FGL17491136
3 Gigabit Ethernet interfaces
31 Serial interfaces
1 terminal line
1 Channelized E1/PRI port
DRAM configuration is 64 bits wide with parity enabled.
255K bytes of non-volatile configuration memory.
250880K bytes of ATA System CompactFlash 0 (Read/Write)

License Info:

License UDI:

-------------------------------------------------
Device#   PID                   SN
-------------------------------------------------
*0        CISCO2911/K9          FGL17491136

Technology Package License Information for Module:'c2900'

-----------------------------------------------------------------
Technology    Technology-package           Technology-package
              Current       Type           Next reboot
------------------------------------------------------------------
ipbase        ipbasek9      Permanent      ipbasek9
security      None          None           None
uc            uck9          Permanent      uck9
data          None          None           None

[Aman Soi]

Hi,

You can refer the link

https://supportforums.cisco.com/discussion/11879381/t1-pri-errors

I have captured the snapshot from same link .Try this if E1 media is error free.

Just went through this same scenario.  Did the whole dance with the carrier (they tested end to end, ran clean of course, threatened them etc. ). Tried on two different 3925e's with a VWIC3-4MFT in both.  Then a VWIC3-2MFT with the same result.  Tried a VWIC2-1MFT, and it came up perfectly.

Got TAC on the phone, guy found the bug (CSCua50697), said it was fixed in the verison i was running (15.2.M4 or something), we upgraded to 15.3.M3 with the same results. 

Long story short, there IS a work around.  Put this command under your controller: hwic_t1e1 equalize

It's a hidden command they put in there just for this problem.

regds,

aman

[srpm]

This gateway is on 15.0(1r)M16 so it appears the hidden command isn't doable.

[Aman Soi]

I suggest taking physical loop [physically shot the pairs ] and ask Airtel to check for the loop.this should be error free.

regds,

aman

[srpm]

Here is the config with parts left out that aren't relevant.

Building configuration...

Current configuration : 8017 bytes
!
version 15.1
no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service sequence-numbers
!
!
boot-start-marker
boot-end-marker
!
!
card type e1 0 1
security authentication failure rate 3 log
security passwords min-length 6
logging buffered 10000000
no logging console
no logging monitor
!
no aaa new-model
clock timezone IST 5 30
network-clock-participate wic 1
network-clock-select 1 E1 0/1/0
!
no ipv6 cef
ip source-route
ip cef
!
!
!
ip dhcp excluded-address 10.10.10.1
!
ip dhcp pool ccp-pool
 import all
 network 10.10.10.0 255.255.255.248
 default-router 10.10.10.1
 lease 0 2
!
!
multilink bundle-name authenticated
!
!
!
!
isdn switch-type primary-net5
!
!

voice-card 0
!
!
!
voice service voip
 ip address trusted list
 allow-connections h323 to h323
 fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
!
voice class codec 1
 codec preference 1 g729r8 bytes 40
 codec preference 2 g711ulaw
!
voice class h323 1
  h225 timeout tcp establish 3
  h225 timeout setup 3
!
!
voice iec syslog
!
!
!
license udi pid CISCO2911/K9 sn FGL17491136
hw-module pvdm 0/0
!
!
!
!
redundancy
!
!
controller E1 0/1/0
 pri-group timeslots 1-31
 description ***Airtel E1***
!
ip ssh time-out 60
ip ssh authentication-retries 2
!
!
!
!
interface Embedded-Service-Engine0/0
 no ip address
 shutdown
!
interface GigabitEthernet0/0
 description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
 ip address 
 duplex auto
 speed auto
!
interface GigabitEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface GigabitEthernet0/2
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial0/1/0:15
 no ip address
 encapsulation hdlc
 isdn switch-type primary-net5
 isdn incoming-voice voice
 isdn map address . plan unknown type unknown
 isdn supp-service name calling
 no cdp enable
!
ip forward-protocol nd
!
ip http server
ip http access-class 23
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
!
!
logging trap debugging
access-list 23 permit 10.10.10.0 0.0.0.7
!
!
!
control-plane
!
!
voice-port 0/1/0:15

[Leo Salcie Tejeda]

Hi Shanen,

If call are been established fine at least for a short time that means is not a line code or framing mismatch. Look like a layer 1 problem (cable between CME and Provider). Maybe the cable is damaged somehow.

Regards

[srpm]

Calls can be established as I do see active inbound/outbound calls on the gateway.  However, they sometimes experience busy's when dialing out or sometimes get reports of busy's when someone tries to call their local numbers.  I asked my local contact earlier this morning to replace the ethernet cable between the provider's device and our gateway.  I will see if that makes any difference.