This article describes the issue of kernel crashes on Juniper routers, when MLFR (FRF.16) is wrongly configured between Cisco and Juniper routers.

JUNOS supports MLFR (FRF.16) interface connections with the Cisco CE; however, JUNOS does not support L2 frame fragmentation when using FRF.16. When a Cisco CE uses the frame-relay fragment 1498 end-to-end CLI command under the MLFR interface and sends a ping packet with a size larger than 1498 bytes towards the M320 PE, the ping packet’s encapsulation is sent from the Cisco CE as FRF.12.

The M320 MLFR interface does not handle this fragmented packet, as it does not support fragmentation over MLFR. As a result, the PIC would send to the RE cookie with improper L2/L3 encapsulation under FRF.16 hot-standby conditions, which causes a vmcore (kernel crash).

Sample configurations :

Juniper router :

rlsq0:1 {
     dce;
     encapsulation multilink-frame-relay-uni-nni;
     mlfr-uni-nni-bundle-options {
         mrru 1508;
         lmi-type ansi;
         minimum-links 1;
}
redundancy-options {
     primary lsq-3/0/0:1;
     secondary lsq-2/0/0:1;
     hot-standby;
}
unit 115 {
    dlci 115;
    family inet {
        mtu 1500;
        address 192.168.1.1/30;
   }
}

interface Serial6/0/3:3
no ip address
encapsulation frame-relay
encapsulation frame-relay MFR1

interface MFR1
no ip address
encapsulation frame-relay IETF
load-interval 30
frame-relay lmi-type ansi
frame-relay fragment 1498 end-to-end <<<======
!
interface MFR1.115 point-to-point
ip address 192.168.1.2 255.255.255.252
frame-relay interface-dlci 115
ping command on Cisco router
ping 192.168.1.1 size 1500

Apart from a Junos code upgrade, there are two workarounds:

• Remove the frame-relay fragment 1498 end-to-end command on the Cisco router.
• Change the rlsq mode from hot-standby to warm-standby.