Possible causes of T1 UP/UP but not passing IP traffic

[jbond]

I've been having a ton of trouble getting a T1 connection to our provider's IPVPN network to work properly.

Very simple config on a 1921with a HWIC-1DSU-T1:

interface Serial0/0/0
description TW IPVPN
ip address 197.18.58.214 255.255.255.252
encapsulation ppp
no clock rate 2000000
service-module t1 timeslots 1-24
no cdp enable

The line comes up and protocol comes up but a BGP session won't establish and you cannot ping across the link.  We've checked and rechecked the ip address, linecode, framing, etc.

It seems like the traffic is only flowing one way.  Syslog messages can "escape"  and make it to my syslog server.  I'm guessing since they are connectionless and don't require traffic to flow both ways.

One other interesting point is that when working with the tech from the provider we switched to HDLC and the line protocol would not come up.  What difference between PPP and HDLC would allow PPP to come up but not HDLC?

The real kicker is that when they sent an Adtran Netvanta router out to test the line, it worked!!  We've tried multiple cisco routers running different IOS versions and each one has the same result. At this point we're looking to get them to build out a new line but that will take some time.  It would be nice to point them in the right direction on getting this fixed and get this site up and running sooner.

[John Blakley]

What difference between PPP and HDLC would allow PPP to come up but not HDLC?

It's the way that the link is encapsulated on the other end. They have to match and a serial interface defaults to HDLC. Can you post your config for your controller, serial interface, and bgp information?

HTH,

John

[Giuseppe Larosa]

Hello John,

just to add

Cisco HDLC and standards based HDLC are two different protocols with Cisco HDLC that has a protocol type field.

this might explain the difference

with PPP encapsulation the PPP session is up

check if IPCP state is open

in

show interfaces serial

Hope to help

Giuseppe

[jbond]

The only controller config is the service-module statement you see in the Serial/0/0/0 configuration.

interface Serial0/0/0
description TW IPVPN
ip address 197.18.58.214 255.255.255.252
encapsulation ppp
no clock rate 2000000
service-module t1 timeslots 1-24
no cdp enable
!
router bgp 65023
bgp log-neighbor-changes
network 10.1.211.0 mask 255.255.255.0
neighbor 197.18.58.213 remote-as 4323
no auto-summary

I believe in their end it is a Juniper router, while speaking over the phone we both set our respective interfaces to HDLC.  The line protocol never came up.   Then we both switched back to PPP.  Protocol came back up but no change with the problem at hand.

[John Blakley]

If you do a "sh controllers", do you have any errors on the link at all?

[Kishore Chennupati]

Hi,

Lets work with PPP since you are establishing a P2P between cisco and juniper. You have advised that the physical/line protocol is up/up.

For BGP to work there has to be NLRI achieved. However, you are not able to ping the IP address on their end. I guess we might need to check the PPP -IPCP state on your serial interface.That should be in open state. Try and perform a debug since its not working anyway..

*May 12 13:08:09.295: Se1/0 IPCP:    Address 10.1.1.1 (0x03060A010101)
*May 12 13:08:09.295: Se1/0: IPPOOL: validate address = 10.1.1.1
*May 12 13:08:09.295: Se1/0 set_ip_peer(4): new address 10.1.1.1
*May 12 13:08:09.311: Se1/0 EVT: Add Route 0 0x0A010101
*May 12 13:08:09.315: Se1/0 IPCP: Install route to 10.1.1.1
*May 12 13:08:10.259: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed

I heard there are some issues with MLPPP between Cisco and Juniper but with just one point to point link. it should be pretty straightforward

HTH

Regards,

Kishore

[jbond]

IPCP state is open

Yes it was taking errors on the controller.

28587 Line Code Violations, 3313 Path Code Violations

Turns out the local provider finally replaced the NIU (smartjack) and that fixed the problem.  Must have only affected the receive pair since my syslog messages could transmit.