[FROG] [LDP] status Bad PDU Length (fatal error)

Tue Jan 22 09:37:10 EST 2019

Hi Alessio,

Interesting problem. Could you provide a pcap (showing TCP port 646
only) so that I can analyze which LDP speaker is behaving badly?

Your config looks fine to me. Using "mpls traffic-eng tunnels" or not
on the Cisco side shouldn't matter since this is one of the commands
used to enable RSVP-TE, which is a different protocol.

Regards,
Renato.

On Tue, Jan 22, 2019 at 7:32 AM Alessio Leonarduzzi
<alessio.leonarduzzi at gmail.com> wrote:
>
> Hi all,
>
> I have a problem with MPLS and LDP neighbor between FRR 6.0.2. and Cisco IOS 12.2 advk9.
>
> the log FRR side is:
> [CUT]
> 2019/01/22 01:03:12 LDP: discovery[recv]: iface enp2s0f0 lsr-id 2.2.2.2 transport-address 2.2.2.2 holdtime 15
> 2019/01/22 01:03:12 LDP: discovery[send]: iface enp2s0f0 (ipv4) holdtime 180
> 2019/01/22 01:03:12 LDP: nbr_fsm: event CONNECTION UP resulted in action SETUP NEIGHBOR CONNECTION and changing state for lsr-id 2.2.2.2 from PRESENT to INITIALIZED
> 2019/01/22 01:03:12 LDP: msg[out]: initialization: lsr-id 2.2.2.2
> 2019/01/22 01:03:12 LDP: nbr_fsm: event INIT SENT resulted in action NOTHING and changing state for lsr-id 2.2.2.2 from INITIALIZED to OPENSENT
> 2019/01/22 01:03:12 LDP: discovery[recv]: iface enp2s0f0 lsr-id 2.2.2.2 transport-address 2.2.2.2 holdtime 15
> 2019/01/22 01:03:12 LDP: msg[in]: initialization: lsr-id 2.2.2.2
> 2019/01/22 01:03:12 LDP: recv_init: lsr-id 2.2.2.2 announced the Dynamic Capability Announcement capability
> 2019/01/22 01:03:12 LDP: recv_init: lsr-id 2.2.2.2 announced the Typed Wildcard FEC capability
> 2019/01/22 01:03:12 LDP: nbr_fsm: event INIT RECEIVED resulted in action SEND KEEPALIVE and changing state for lsr-id 2.2.2.2 from OPENSENT to OPENREC
> 2019/01/22 01:03:12 LDP: nbr_fsm: event KEEPALIVE RECEIVED resulted in action START NEIGHBOR SESSION and changing state for lsr-id 2.2.2.2 from OPENREC to OPERATIONAL
> ...
> 2019/01/22 01:03:12 LDP: msg[in]: label mapping: lsr-id 2.2.2.2, fec 1.1.1.1/32, label 250
> 2019/01/22 01:03:12 LDP: msg[in]: notification: lsr-id 2.2.2.2, status Bad PDU Length (fatal error)
> 2019/01/22 01:03:12 LDP: nbr_fsm: event SESSION CLOSE resulted in action CLOSE SESSION and changing state for lsr-id 2.2.2.2 from OPERATIONAL to PRESENT
> 2019/01/22 01:03:12 LDP: session_close: closing session with lsr-id 2.2.2.2
> 2019/01/22 01:03:12 LDP: zebra[out]: prefix 10.226.135.0/30 nexthop 10.224.1.21 ifindex 2 labels 497/166 (add)
> [/CUT]
>
> Cisco side:
> [CUT]
> Jan 22 00:51:51.049 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (2) is UP
> Jan 22 00:51:51.053 CET: %LDP-4-PTCL: peer 1.1.1.1:0, bad PDU hdr
> Jan 22 00:51:51.053 CET:   PDU HDR:
> Jan 22 00:51:51.053 CET:   0x00 0x01 0x0F 0xFE 0x5D 0xBD 0xBF 0xFC 0x00 0x00 0x00 0x00
> Jan 22 00:51:51.053 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (2) is DOWN (Received bad message)
> Jan 22 00:51:53.241 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.12:0 (7) is UP
> Jan 22 00:51:53.245 CET: %LDP-4-PTCL: peer 1.1.1.1:0, bad PDU hdr
> Jan 22 00:51:53.245 CET:   PDU HDR:
> Jan 22 00:51:53.245 CET:   0x00 0x01 0x0F 0xFE 0x5D 0xBD 0xBF 0xFC 0x00 0x00 0x00 0x00
> Jan 22 00:51:53.245 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (7) is DOWN (Received bad message)
> Jan 22 00:52:13.065 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (2) is UP
> Jan 22 00:52:13.069 CET: %LDP-4-PTCL: peer 1.1.1.1:0, bad PDU hdr
> Jan 22 00:52:13.069 CET:   PDU HDR:
> Jan 22 00:52:13.069 CET:   0x00 0x01 0x0F 0xFE 0x5D 0xBD 0xBF 0xFC 0x00 0x00 0x00 0x00
> Jan 22 00:52:13.069 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (2) is DOWN (Received bad message)
> Jan 22 00:52:15.953 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (7) is UP
> Jan 22 00:52:15.957 CET: %LDP-4-PTCL: peer 1.1.1.1:0, bad PDU hdr
> Jan 22 00:52:15.957 CET:   PDU HDR:
> Jan 22 00:52:15.957 CET:   0x00 0x01 0x0F 0xFE 0x5D 0xBD 0xBF 0xFC 0x00 0x00 0x00 0x00
> Jan 22 00:52:15.957 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (7) is DOWN (Received bad message)
> [/CUT]
>
>
> FRR configuration:
>
> interface dummy0
>  ip address 1.1.1.1/32
> !
> interface enp2s0f0
>  description CORE-1
>  ip address 10.224.1.22/30
>  ip ospf network point-to-point
> !
> interface enp2s0f1
>  description CORE-2
>  ip address 10.224.1.26/30
>  ip ospf network point-to-point
> !
> mpls ldp
>  router-id 1.1.1.1
>  dual-stack cisco-interop
>  !
>  address-family ipv4
>   discovery hello holdtime 180
>   discovery hello interval 15
>   discovery transport-address 1.1.1.1
>   label local advertise explicit-null
>   !
>   interface enp2s0f0
>   !
>   interface enp2s0f1
>   !
>  exit-address-family
>  !
> !
>
> Cisco configuration:
>
> mpls traffic-eng tunnels
> mpls ip default-route
> mpls label protocol ldp
> interface Loopback0
>  ip address 2.2.2.2 255.255.255.255
> !
> interface TenGigabitEthernet1/1
>  description ASBR-FRR-TEST
>  mtu 1600
>  ip address 10.224.1.21 255.255.255.252
>  ip ospf network point-to-point
>  mpls traffic-eng tunnels
>  mpls ip
> !
>
> The OSPF is up and Loopback are in both routing tables. I try with/with-out "mpls traffic-eng tunnels" with same result. Timers/MTU are corrects.
>
> The result is that the devices don't share the labels becouse neighbors are down
>
> This is a bug? or wrong configuration?
>
> regards
>
> Alessio
> _______________________________________________
> frog mailing list
> frog at lists.frrouting.org
> https://lists.frrouting.org/listinfo/frog

-- 
Renato Westphal