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@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@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@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@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@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@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
-- Renato Westphal
-- Renato Westphal
-- Renato Westphal