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

Donald Sharp sharpd at cumulusnetworks.com
Wed Jan 23 07:35:32 EST 2019


This code has been pushed into the code base.  You can grab a build
artifact or wait a few weeks until the 7.0 release is released( Early
Feb ).

Donald

On Wed, Jan 23, 2019 at 5:38 AM Alessio Leonarduzzi
<alessio.leonarduzzi at gmail.com> wrote:
>
> Hi Renato,
>
> thank you for the troubleshooting. I'm trying with labels only for hosts and the LDP neighbours are UP and the bindings are correct.
>
> But in our network we need also the P2P /30 networks... so I should compile from GIT or wait next release.
>
> I hope the next release is soon...
>
> regards
>
> Alessio
>
>
> Il giorno mar 22 gen 2019 alle ore 21:08 Renato Westphal <renato at opensourcerouting.org> ha scritto:
>>
>> So, ldpd was sending a PDU with 4098 bytes, when the negotiated
>> maximum PDU Length was 4096. This led the other box to reject the
>> message as expected.
>>
>> This small patch should fix the problem, I'll open a PR for it in a bit:
>> --- a/ldpd/labelmapping.c
>> +++ b/ldpd/labelmapping.c
>> @@ -37,7 +37,7 @@ enqueue_pdu(struct nbr *nbr, uint16_t type, struct
>> ibuf *buf, uint16_t size)
>>         struct ldp_hdr          *ldp_hdr;
>>
>>         ldp_hdr = ibuf_seek(buf, 0, sizeof(struct ldp_hdr));
>> -       ldp_hdr->length = htons(size);
>> +       ldp_hdr->length = htons(size - LDP_HDR_DEAD_LEN);
>>         evbuf_enqueue(&nbr->tcp->wbuf, buf);
>>  }
>>
>> @@ -65,7 +65,7 @@ send_labelmessage(struct nbr *nbr, uint16_t type,
>> struct mapping_head *mh)
>>                         /* real size will be set up later */
>>                         err |= gen_ldp_hdr(buf, 0);
>>
>> -                       size = LDP_HDR_PDU_LEN;
>> +                       size = LDP_HDR_SIZE;
>>                         first = 0;
>>                 }
>>
>> As a workaround, you can use the "label local allocate host-routes"
>> command on ldpd to allocate labels for host prefixes only, and not for
>> all IGP prefixes (usually you need LSPs for the loopbacks only). This
>> should limit the number of label mappings that are sent, thus reducing
>> the likelihood of this problem from happening.
>>
>> Thanks for reporting this problem!
>>
>> Regards,
>> Renato.
>>
>> On Tue, Jan 22, 2019 at 1:38 PM Alessio Leonarduzzi
>> <alessio.leonarduzzi at gmail.com> wrote:
>> >
>> > Hi Renato,
>> >
>> > in attachment all the tcpdump capture.
>> > 93.189.191.242 FRR loopback
>> > 93.189.191.242 Cisco Loopback
>> > 10.224.1.24/30 P2P FRR-Cisco
>> >
>> > thank you
>> >
>> > regards
>> >
>> > Alessio
>> >
>> >
>> > Il giorno mar 22 gen 2019 alle ore 16:27 Renato Westphal <renato at opensourcerouting.org> ha scritto:
>> >>
>> >> Hi Alessio,
>> >>
>> >> This pcap shows LDP Hello packages only, I need to see the full
>> >> package exchange that happens during the LDP session initialization
>> >> (Initialization messages, KeepAlive messages, etc).
>> >>
>> >> Regards,
>> >> Renato.
>> >>
>> >> On Tue, Jan 22, 2019 at 1:01 PM Alessio Leonarduzzi
>> >> <alessio.leonarduzzi at gmail.com> wrote:
>> >> >
>> >> > Hi Renato,
>> >> >
>> >> > in attachment the pcap capture. For this capture I have disabled all traffic-eng  on FRR and removed from interface on Cisco.
>> >> >
>> >> > regards
>> >> >
>> >> > Alessio
>> >> >
>> >> >
>> >> >
>> >> > Il giorno mar 22 gen 2019 alle ore 15:37 Renato Westphal <renato at opensourcerouting.org> ha scritto:
>> >> >>
>> >> >> 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
>> >>
>> >>
>> >>
>> >> --
>> >> Renato Westphal
>>
>>
>>
>> --
>> Renato Westphal
>
> _______________________________________________
> frog mailing list
> frog at lists.frrouting.org
> https://lists.frrouting.org/listinfo/frog



More information about the frog mailing list