RE: Flapping POS Interface on Frame-relay between a Juniper and Cisco
Did Jeff's suggestion work? : interface POS0/0/0 : frame-relay intf-type dce If so, please let the list know, so when someone comes across this thread while searching for the fix they can figure it out without having to email the list. If it didn't help contact me off-line and I will be happy to troubleshoot it with you. scott ________________________________________ From: Righa Shake [righa.shake@gmail.com] Sent: Saturday, November 19, 2011 11:11 AM To: afnog@afnog.org Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco Hi, Am having a problem that is buffling. I recently changed a POS link encapsulation from PPP to Frame-relay. Since that time the POS interface keeps resetting from time to time. On my BGP session am receiving cease notifications from my upstream provider. The setup is such that we have a cisco on one end and a Juniper on the other. interface POS0/0/0 mtu 4474 no ip address no ip unreachables encapsulation frame-relay logging event link-status crc 32 pos scramble-atm frame-relay lmi-type ansi end ROUTERshow run int pos0/0/0.101 Building configuration... ! interface POS0/0/0.101 point-to-point ip address X.X.X.X 255.255.255.252 frame-relay interface-dlci 101 end ROUTER#show int pos0/0/0 POS0/0/0 is up, line protocol is up Hardware is SPA-2XOC12-POS MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 6/255, rxload 38/255 Encapsulation FRAME-RELAY, crc 32, loopback not set Keepalive set (10 sec) Scramble enabled LMI enq sent 81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE segmentation inactive FR SVC disabled, LAPF state down Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface broadcasts 0 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 1w2d Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 94336000 bits/sec, 13151 packets/sec 5 minute output rate 16470000 bits/sec, 7049 packets/sec 12211574207 packets input, 10967607038364 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 6970870 runts, 2179 giants, 0 throttles 0 parity 892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored, 3335463 abort 6379191154 packets output, 1614018181446 bytes, 0 underruns 0 output errors, 0 applique, 4 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions Any assistance on this will be greatly appreciated. --- jsaxe@briworks.com wrote: From: Jeff Saxe <jsaxe@briworks.com> I believe this is the explanation for your flapping: a PPP link is intended to go between two routers over, for instance, a private leased line, so both of the devices are peers, neither one particularly special. Frame-relay, by contrast, was originally designed so that 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 cloud, 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 and were up at the moment. 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 when you bring them up, they will initially optimistically think their DLCIs are up and working, and the routing protocol and traffic will come up... but both of them will be waiting for the frame switch to send them LMI indicating that their idea of the DLCI up/down status is correct. When a couple minutes 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 forever, 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 interface POS0/0/0 frame-relay intf-type dce So this will turn your Cisco side of the circuit into "DCE" mode, and if the 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, as 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-relay lmi-type -- one type sends the LMI on DLCI number 0, one of them on DLCI 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. Good luck, and I hope it's that simple. :-)
The mismatch problem of DCE/DTE should definitely indicate that your PVCs aren't up. But that shouldn't result in the high quantity of CRC errors in the interface counters. That should just result in your LMI enquiry count increasing with LMI response sitting at zero. I have to say I've never tried running frame-relay on a SONET interface. And if you're only using a single PVC there, I'd certainly love to know WHY you're doing that! :) But setting one side to DCE so that it'll respond to LMI will certainly make the frame-relay (L2) portion of things operate properly. But if you have something else occurring causing the CRCs along the way, then that's not really going to help at all! Did anything else coincide with you changing the encapsulation? Scott On 12/6/11 4:05 PM, Scott Weeks wrote:
Did Jeff's suggestion work?
: interface POS0/0/0 : frame-relay intf-type dce
If so, please let the list know, so when someone comes across this thread while searching for the fix they can figure it out without having to email the list. If it didn't help contact me off-line and I will be happy to troubleshoot it with you.
scott
________________________________________ From: Righa Shake [righa.shake@gmail.com] Sent: Saturday, November 19, 2011 11:11 AM To: afnog@afnog.org Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco
Hi,
Am having a problem that is buffling.
I recently changed a POS link encapsulation from PPP to Frame-relay. Since that time the POS interface keeps resetting from time to time.
On my BGP session am receiving cease notifications from my upstream provider.
The setup is such that we have a cisco on one end and a Juniper on the other.
interface POS0/0/0 mtu 4474 no ip address no ip unreachables encapsulation frame-relay logging event link-status crc 32 pos scramble-atm frame-relay lmi-type ansi end
ROUTERshow run int pos0/0/0.101 Building configuration...
! interface POS0/0/0.101 point-to-point ip address X.X.X.X 255.255.255.252 frame-relay interface-dlci 101 end
ROUTER#show int pos0/0/0 POS0/0/0 is up, line protocol is up Hardware is SPA-2XOC12-POS MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 6/255, rxload 38/255 Encapsulation FRAME-RELAY, crc 32, loopback not set Keepalive set (10 sec) Scramble enabled LMI enq sent 81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE segmentation inactive FR SVC disabled, LAPF state down Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface broadcasts 0 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 1w2d Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 94336000 bits/sec, 13151 packets/sec 5 minute output rate 16470000 bits/sec, 7049 packets/sec 12211574207 packets input, 10967607038364 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 6970870 runts, 2179 giants, 0 throttles 0 parity 892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored, 3335463 abort 6379191154 packets output, 1614018181446 bytes, 0 underruns 0 output errors, 0 applique, 4 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions
Any assistance on this will be greatly appreciated.
--- jsaxe@briworks.com wrote:
From: Jeff Saxe <jsaxe@briworks.com>
I believe this is the explanation for your flapping: a PPP link is intended to go between two routers over, for instance, a private leased line, so both of the devices are peers, neither one particularly special. Frame-relay, by contrast, was originally designed so that 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 cloud, 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 and were up at the moment.
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 when you bring them up, they will initially optimistically think their DLCIs are up and working, and the routing protocol and traffic will come up... but both of them will be waiting for the frame switch to send them LMI indicating that their idea of the DLCI up/down status is correct. When a couple minutes 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 forever, 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
interface POS0/0/0 frame-relay intf-type dce
So this will turn your Cisco side of the circuit into "DCE" mode, and if the 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, as 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-relay lmi-type -- one type sends the LMI on DLCI number 0, one of them on DLCI 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.
Good luck, and I hope it's that simple. :-)
The interface finally stabalised. This after performing segment by segment loop tests at SDH level. We found errors which were sorted after which the service has been better the random flaps have since disappeared. Now dealing with random BGP cease notifications I receive from my upstream. Thank you all for your assistance in helping solve this. Regards, Righa Shake On Wed, Dec 7, 2011 at 12:17 AM, Scott Morris <swm@emanon.com> wrote:
The mismatch problem of DCE/DTE should definitely indicate that your PVCs aren't up. But that shouldn't result in the high quantity of CRC errors in the interface counters. That should just result in your LMI enquiry count increasing with LMI response sitting at zero.
I have to say I've never tried running frame-relay on a SONET interface. And if you're only using a single PVC there, I'd certainly love to know WHY you're doing that! :)
But setting one side to DCE so that it'll respond to LMI will certainly make the frame-relay (L2) portion of things operate properly. But if you have something else occurring causing the CRCs along the way, then that's not really going to help at all!
Did anything else coincide with you changing the encapsulation?
Scott
Did Jeff's suggestion work?
: interface POS0/0/0 : frame-relay intf-type dce
If so, please let the list know, so when someone comes across this thread while searching for the fix they can figure it out without having to email the list. If it didn't help contact me off-line and I will be happy to troubleshoot it with you.
scott
________________________________________ From: Righa Shake [righa.shake@gmail.com] Sent: Saturday, November 19, 2011 11:11 AM To: afnog@afnog.org Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco
Hi,
Am having a problem that is buffling.
I recently changed a POS link encapsulation from PPP to Frame-relay. Since that time the POS interface keeps resetting from time to time.
On my BGP session am receiving cease notifications from my upstream provider.
The setup is such that we have a cisco on one end and a Juniper on the other.
interface POS0/0/0 mtu 4474 no ip address no ip unreachables encapsulation frame-relay logging event link-status crc 32 pos scramble-atm frame-relay lmi-type ansi end
ROUTERshow run int pos0/0/0.101 Building configuration...
! interface POS0/0/0.101 point-to-point ip address X.X.X.X 255.255.255.252 frame-relay interface-dlci 101 end
ROUTER#show int pos0/0/0 POS0/0/0 is up, line protocol is up Hardware is SPA-2XOC12-POS MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 6/255, rxload 38/255 Encapsulation FRAME-RELAY, crc 32, loopback not set Keepalive set (10 sec) Scramble enabled LMI enq sent 81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE segmentation inactive FR SVC disabled, LAPF state down Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface broadcasts 0 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 1w2d Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 94336000 bits/sec, 13151 packets/sec 5 minute output rate 16470000 bits/sec, 7049 packets/sec 12211574207 packets input, 10967607038364 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 6970870 runts, 2179 giants, 0 throttles 0 parity 892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored, 3335463 abort 6379191154 packets output, 1614018181446 bytes, 0 underruns 0 output errors, 0 applique, 4 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions
Any assistance on this will be greatly appreciated.
--- jsaxe@briworks.com wrote:
From: Jeff Saxe <jsaxe@briworks.com>
I believe this is the explanation for your flapping: a PPP link is intended to go between two routers over, for instance, a private leased
On 12/6/11 4:05 PM, Scott Weeks wrote: line, so both of the devices are peers, neither one particularly special. Frame-relay, by contrast, was originally designed so that 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 cloud, 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 and were up at the moment.
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 when you bring them up, they will initially optimistically think their DLCIs are up and working, and the routing protocol and traffic will come up... but both of them will be waiting for the frame switch to send them LMI indicating that their idea of the DLCI up/down status is correct. When a couple minutes 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 forever, 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
interface POS0/0/0 frame-relay intf-type dce
So this will turn your Cisco side of the circuit into "DCE" mode, and if
the 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, as 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-relay lmi-type -- one type sends the LMI on DLCI number 0, one of them on DLCI 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.
Good luck, and I hope it's that simple. :-)
participants (3)
-
Righa Shake -
Scott Morris -
Scott Weeks