[147223] in North American Network Operators' Group
RE: Flapping POS Interface on Frame-relay between a Juniper and Cisco
daemon@ATHENA.MIT.EDU (Jeff Saxe)
Mon Dec 5 20:21:59 2011
From: Jeff Saxe <jsaxe@briworks.com>
To: Righa Shake <righa.shake@gmail.com>
Date: Tue, 6 Dec 2011 01:20:56 +0000
In-Reply-To: <CAJO3VzzLSSbWbr57dAjaMr0-ZyHNEmhA2xMVQypxMOZpWStnMw@mail.gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Ah, memories are flooding back from my Voice over Frame Relay days on a Cis=
co MC3810. We would crush compressed G.729a voice and barely-enough data fo=
r 24 remote call center employees into, I believe, two quarter-T1 frame DLC=
I's to keep costs down. Anyway, I believe this is the explanation for your =
flapping: a PPP link is intended to go between two routers over, for instan=
ce, a private leased line, so both of the devices are peers, neither one pa=
rticularly special. Frame-relay, by contrast, was originally designed so th=
at your router was an "end user" device and its directly-connected partner =
device was not your other router, which you control, but the frame carrier'=
s frame-relay switch. Your router was a DTE device, and their switch, which=
was in a more "important" position in control of the frame-relay NBMA clou=
d, was the DCE device. Your router then slaved to the frame switch via LMI =
signaling, so that the upstream switch instructed you which DLCIs existed a=
nd were up at the moment.=0A=
=0A=
So if you connect up two routers with frame-relay encap and each thinks it =
is the DTE, and neither one is taking the role of the frame switch, then wh=
en you bring them up, they will initially optimistically think their DLCIs =
are up and working, and the routing protocol and traffic will come up... bu=
t both of them will be waiting for the frame switch to send them LMI indica=
ting that their idea of the DLCI up/down status is correct. When a couple m=
inutes go by and they don't hear the responses to their LMI enquiries, they=
will bring all the DLCI's down. I thought they would then stay down foreve=
r, i.e., not flap, but maybe you are shutting / no shutting the POS circuit=
to try again. Anyway, I believe the very simple fix is=0A=
=0A=
interface POS0/0/0=0A=
frame-relay intf-type dce=0A=
=0A=
So this will turn your Cisco side of the circuit into "DCE" mode, and if th=
e Juniper side stays in "DTE" mode (the default, so probably not listed in =
the config), then the LMI should start behaving between the two. And yes, a=
s Jay Hennigan suggested, you might need to use "encap frame-relay ietf" to=
be compatible with non-Cisco gear, or you might need to adjust the frame-r=
elay lmi-type -- one type sends the LMI on DLCI number 0, one of them on DL=
CI 1023, whatever. I think you'll need to adjust the two ends until you see=
LMI enquiries both sent and received; right now the "show interface" from =
the Cisco side shows it has not received any LMI enq yet.=0A=
=0A=
=0A=
Good luck, and I hope it's that simple. :-)=0A=
=0A=
=0A=
Jeff Saxe=0A=
blue ridge internetworks=0A=
=0A=
321 east main st =95 suite 200=0A=
charlottesville va 22902=0A=
434.817.0707 x 2024=0A=
www.briworks.com=0A=
=0A=
Central Virginia=92s technology authority since 2000.=0A=
=0A=
________________________________________=0A=
From: Righa Shake [righa.shake@gmail.com]=0A=
Sent: Saturday, November 19, 2011 11:11 AM=0A=
To: afnog@afnog.org=0A=
Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco=
=0A=
=0A=
Hi,=0A=
=0A=
Am having a problem that is buffling.=0A=
=0A=
I recently changed a POS link encapsulation from PPP to Frame-relay.=0A=
Since that time the POS interface keeps resetting from time to time.=0A=
=0A=
On my BGP session am receiving cease notifications from my upstream=0A=
provider.=0A=
=0A=
The setup is such that we have a cisco on one end and a Juniper on the=0A=
other.=0A=
=0A=
interface POS0/0/0=0A=
mtu 4474=0A=
no ip address=0A=
no ip unreachables=0A=
encapsulation frame-relay=0A=
logging event link-status=0A=
crc 32=0A=
pos scramble-atm=0A=
frame-relay lmi-type ansi=0A=
end=0A=
=0A=
ROUTERshow run int pos0/0/0.101=0A=
Building configuration...=0A=
=0A=
=0A=
!=0A=
interface POS0/0/0.101 point-to-point=0A=
ip address X.X.X.X 255.255.255.252=0A=
frame-relay interface-dlci 101=0A=
end=0A=
=0A=
ROUTER#show int pos0/0/0=0A=
POS0/0/0 is up, line protocol is up=0A=
Hardware is SPA-2XOC12-POS=0A=
MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec,=0A=
reliability 255/255, txload 6/255, rxload 38/255=0A=
Encapsulation FRAME-RELAY, crc 32, loopback not set=0A=
Keepalive set (10 sec)=0A=
Scramble enabled=0A=
LMI enq sent 81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up=0A=
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0=0A=
LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE segmentation=0A=
inactive=0A=
FR SVC disabled, LAPF state down=0A=
Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface broadcasts=
=0A=
0=0A=
Last input 00:00:00, output 00:00:00, output hang never=0A=
Last clearing of "show interface" counters 1w2d=0A=
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0=0A=
Queueing strategy: fifo=0A=
Output queue: 0/40 (size/max)=0A=
5 minute input rate 94336000 bits/sec, 13151 packets/sec=0A=
5 minute output rate 16470000 bits/sec, 7049 packets/sec=0A=
12211574207 packets input, 10967607038364 bytes, 0 no buffer=0A=
Received 0 broadcasts (0 IP multicasts)=0A=
6970870 runts, 2179 giants, 0 throttles=0A=
0 parity=0A=
892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored,=
=0A=
3335463 abort=0A=
6379191154 packets output, 1614018181446 bytes, 0 underruns=0A=
0 output errors, 0 applique, 4 interface resets=0A=
0 unknown protocol drops=0A=
0 output buffer failures, 0 output buffers swapped out=0A=
0 carrier transitions=0A=
=0A=
=0A=
Any assistance on this will be greatly appreciated.=0A=
=0A=
=0A=
Regards,=0A=
Righa Shake=0A=
