[c-nsp] Frame-relay "line protocol is down" while DTE and DCE LMI are up

[Bob Tinkelman]

I'm a bit mystified by the current situation and would (of course)
much appreciate any advice.

Background:

   New p2p MCI OC3 with working+protect pairs
   Two routers at one site, one at the other.
   All routers are 7206-vxr.
   All OC3 interfaces are PA-POS-SMI

   gw1.nycrnybb PO2/0 connected to working pair
   gw2.nycrnybb PO2/0 connected to protect pair

   gw1.nycmnycz PO2/0 connected to working pair
   gw1.nycmnycz PO4/0 connected to protect pair

   APS used to configure the interfaces "working" vs "protect"

Status:

   gw1.nycmnycz PO4/0 works either nycrnybb-site interface.
   gw1.nycmnycz PO2/0 fails with both nycrnybb-site interfaces.

Tests:

   The problem interface sees a loop at the demarc.
   The problem interface sees changes when far-end interfaces
   are "shut".

Here's what things look like at the problem interface, when all
connections are "normal":

  | gw1.nycmnycz#sho int po2/0
 >| POS2/0 is up, line protocol is down  (APS working - active)
  |   Hardware is Packet over Sonet
  |   Description: po-2-0.gw1.nycrnybb - MCI OC3 nyc-i234127  o2-crb-7td-0001 (working)
  |   MTU 4470 bytes, BW 155000 Kbit, DLY 100 usec, 
  |      reliability 255/255, txload 1/255, rxload 1/255
  |   Encapsulation FRAME-RELAY IETF, crc 16, loopback not set
  |   Scramble disabled
 >|   LMI enq sent  45, LMI stat recvd 45, LMI upd recvd 0, DTE LMI up
 >|   LMI enq recvd 46, LMI stat sent  46, LMI upd sent  0, DCE LMI up
  |   LMI DLCI 0  LMI type is ANSI Annex D  frame relay NNI
  |   FR SVC disabled, LAPF state down
  |   Broadcast queue 0/256, broadcasts sent/dropped 0/0, interface broadcasts 0
  |   Last input 00:00:02, output 00:00:13, output hang never
  |   Last clearing of "show interface" counters 00:08:00
  |   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  |   Queueing strategy: fifo
  |   Output queue: 0/40 (size/max)
  |   5 minute input rate 0 bits/sec, 0 packets/sec
  |   5 minute output rate 0 bits/sec, 0 packets/sec
  |      91 packets input, 1374 bytes, 0 no buffer
  |      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
  |               0 parity
  |      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
  |      91 packets output, 1364 bytes, 0 underruns
  |      0 output errors, 0 applique, 1 interface resets
  |      0 output buffer failures, 0 output buffers swapped out
  |      0 carrier transitions
  | gw1.nycmnycz#

I'm most confused about the three flagged lines:
 >| POS2/0 is up, line protocol is down  (APS working - active)
 >|   LMI enq sent  45, LMI stat recvd 45, LMI upd recvd 0, DTE LMI up
 >|   LMI enq recvd 46, LMI stat sent  46, LMI upd sent  0, DCE LMI up

What would make the "line protocol down" when both LMI protocols are up?

This is the interface config:

  | gw1.nycmnycz#sho run int po2/0
  | Building configuration...
  | 
  | Current configuration : 270 bytes
  | !
  | interface POS2/0
  |  description po-2-0.gw1.nycrnybb - MCI OC3 nyc-i234127  o2-crb-7td-0001 (working)
  |  no ip address
  |  encapsulation frame-relay IETF
  |  pos ais-shut
  |  aps group 1
  |  aps working 1
  |  no clns route-cache
  |  frame-relay lmi-type ansi
  |  frame-relay intf-type nni
  | end

This is what I see when turning on "debug frame-relay lmi":

  | Jan  3 12:38:04.444: POS2/0(out): StEnq, myseq 120, yourseen 119, DTE up
  | Jan  3 12:38:04.444: datagramstart = 0xC003554, datagramsize = 14
  | Jan  3 12:38:04.444: FR encap = 0x00010308
  | Jan  3 12:38:04.444: 00 75 95 01 01 01 03 02 78 77 
  | Jan  3 12:38:04.444: 
  | Jan  3 12:38:04.444: POS2/0(in): Status, myseq 120, pak size 14
  | Jan  3 12:38:04.444: RT IE 1, length 1, type 1
  | Jan  3 12:38:04.444: KA IE 3, length 2, yourseq 120, myseq 120
  | Jan  3 12:38:05.420: POS2/0(in): StEnq, myseq 120
  | Jan  3 12:38:05.420: RT IE 1, length 1, type 1
  | Jan  3 12:38:05.420: KA IE 3, length 2, yourseq 121, myseq 120
  | Jan  3 12:38:05.420: POS2/0(out): Status, myseq 121, yourseen 121, DCE up


My next step is probably to drive to the site and perform various hardware
and cable swaps, but I thought I'd first see if anyone might point out a
place where I was being blind.
--
Bob Tinkelman <bob at tink.com>
ISPnet, Inc.    718.464.4747