[FROG] [LDP] status Bad PDU Length (fatal error)
Renato Westphal
renato at opensourcerouting.org
Tue Jan 22 15:08:40 EST 2019
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
More information about the frog
mailing list