<div dir="ltr"><div dir="ltr">Hi Renato,<div><br></div><div>thank you for the troubleshooting. I'm trying with labels only for hosts and the LDP neighbours are UP and the bindings are correct.</div><div><br></div><div>But in our network we need also the P2P /30 networks... so I should compile from GIT or wait next release. </div><div><br></div><div>I hope the next release is soon...</div><div><br></div><div>regards</div><div><br></div><div>Alessio</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 22 gen 2019 alle ore 21:08 Renato Westphal <<a href="mailto:renato@opensourcerouting.org">renato@opensourcerouting.org</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So, ldpd was sending a PDU with 4098 bytes, when the negotiated<br>
maximum PDU Length was 4096. This led the other box to reject the<br>
message as expected.<br>
<br>
This small patch should fix the problem, I'll open a PR for it in a bit:<br>
--- a/ldpd/labelmapping.c<br>
+++ b/ldpd/labelmapping.c<br>
@@ -37,7 +37,7 @@ enqueue_pdu(struct nbr *nbr, uint16_t type, struct<br>
ibuf *buf, uint16_t size)<br>
struct ldp_hdr *ldp_hdr;<br>
<br>
ldp_hdr = ibuf_seek(buf, 0, sizeof(struct ldp_hdr));<br>
- ldp_hdr->length = htons(size);<br>
+ ldp_hdr->length = htons(size - LDP_HDR_DEAD_LEN);<br>
evbuf_enqueue(&nbr->tcp->wbuf, buf);<br>
}<br>
<br>
@@ -65,7 +65,7 @@ send_labelmessage(struct nbr *nbr, uint16_t type,<br>
struct mapping_head *mh)<br>
/* real size will be set up later */<br>
err |= gen_ldp_hdr(buf, 0);<br>
<br>
- size = LDP_HDR_PDU_LEN;<br>
+ size = LDP_HDR_SIZE;<br>
first = 0;<br>
}<br>
<br>
As a workaround, you can use the "label local allocate host-routes"<br>
command on ldpd to allocate labels for host prefixes only, and not for<br>
all IGP prefixes (usually you need LSPs for the loopbacks only). This<br>
should limit the number of label mappings that are sent, thus reducing<br>
the likelihood of this problem from happening.<br>
<br>
Thanks for reporting this problem!<br>
<br>
Regards,<br>
Renato.<br>
<br>
On Tue, Jan 22, 2019 at 1:38 PM Alessio Leonarduzzi<br>
<<a href="mailto:alessio.leonarduzzi@gmail.com" target="_blank">alessio.leonarduzzi@gmail.com</a>> wrote:<br>
><br>
> Hi Renato,<br>
><br>
> in attachment all the tcpdump capture.<br>
> 93.189.191.242 FRR loopback<br>
> 93.189.191.242 Cisco Loopback<br>
> <a href="http://10.224.1.24/30" rel="noreferrer" target="_blank">10.224.1.24/30</a> P2P FRR-Cisco<br>
><br>
> thank you<br>
><br>
> regards<br>
><br>
> Alessio<br>
><br>
><br>
> Il giorno mar 22 gen 2019 alle ore 16:27 Renato Westphal <<a href="mailto:renato@opensourcerouting.org" target="_blank">renato@opensourcerouting.org</a>> ha scritto:<br>
>><br>
>> Hi Alessio,<br>
>><br>
>> This pcap shows LDP Hello packages only, I need to see the full<br>
>> package exchange that happens during the LDP session initialization<br>
>> (Initialization messages, KeepAlive messages, etc).<br>
>><br>
>> Regards,<br>
>> Renato.<br>
>><br>
>> On Tue, Jan 22, 2019 at 1:01 PM Alessio Leonarduzzi<br>
>> <<a href="mailto:alessio.leonarduzzi@gmail.com" target="_blank">alessio.leonarduzzi@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hi Renato,<br>
>> ><br>
>> > in attachment the pcap capture. For this capture I have disabled all traffic-eng on FRR and removed from interface on Cisco.<br>
>> ><br>
>> > regards<br>
>> ><br>
>> > Alessio<br>
>> ><br>
>> ><br>
>> ><br>
>> > Il giorno mar 22 gen 2019 alle ore 15:37 Renato Westphal <<a href="mailto:renato@opensourcerouting.org" target="_blank">renato@opensourcerouting.org</a>> ha scritto:<br>
>> >><br>
>> >> Hi Alessio,<br>
>> >><br>
>> >> Interesting problem. Could you provide a pcap (showing TCP port 646<br>
>> >> only) so that I can analyze which LDP speaker is behaving badly?<br>
>> >><br>
>> >> Your config looks fine to me. Using "mpls traffic-eng tunnels" or not<br>
>> >> on the Cisco side shouldn't matter since this is one of the commands<br>
>> >> used to enable RSVP-TE, which is a different protocol.<br>
>> >><br>
>> >> Regards,<br>
>> >> Renato.<br>
>> >><br>
>> >> On Tue, Jan 22, 2019 at 7:32 AM Alessio Leonarduzzi<br>
>> >> <<a href="mailto:alessio.leonarduzzi@gmail.com" target="_blank">alessio.leonarduzzi@gmail.com</a>> wrote:<br>
>> >> ><br>
>> >> > Hi all,<br>
>> >> ><br>
>> >> > I have a problem with MPLS and LDP neighbor between FRR 6.0.2. and Cisco IOS 12.2 advk9.<br>
>> >> ><br>
>> >> > the log FRR side is:<br>
>> >> > [CUT]<br>
>> >> > 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<br>
>> >> > 2019/01/22 01:03:12 LDP: discovery[send]: iface enp2s0f0 (ipv4) holdtime 180<br>
>> >> > 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<br>
>> >> > 2019/01/22 01:03:12 LDP: msg[out]: initialization: lsr-id 2.2.2.2<br>
>> >> > 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<br>
>> >> > 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<br>
>> >> > 2019/01/22 01:03:12 LDP: msg[in]: initialization: lsr-id 2.2.2.2<br>
>> >> > 2019/01/22 01:03:12 LDP: recv_init: lsr-id 2.2.2.2 announced the Dynamic Capability Announcement capability<br>
>> >> > 2019/01/22 01:03:12 LDP: recv_init: lsr-id 2.2.2.2 announced the Typed Wildcard FEC capability<br>
>> >> > 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<br>
>> >> > 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<br>
>> >> > ...<br>
>> >> > 2019/01/22 01:03:12 LDP: msg[in]: label mapping: lsr-id 2.2.2.2, fec <a href="http://1.1.1.1/32" rel="noreferrer" target="_blank">1.1.1.1/32</a>, label 250<br>
>> >> > 2019/01/22 01:03:12 LDP: msg[in]: notification: lsr-id 2.2.2.2, status Bad PDU Length (fatal error)<br>
>> >> > 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<br>
>> >> > 2019/01/22 01:03:12 LDP: session_close: closing session with lsr-id 2.2.2.2<br>
>> >> > 2019/01/22 01:03:12 LDP: zebra[out]: prefix <a href="http://10.226.135.0/30" rel="noreferrer" target="_blank">10.226.135.0/30</a> nexthop 10.224.1.21 ifindex 2 labels 497/166 (add)<br>
>> >> > [/CUT]<br>
>> >> ><br>
>> >> > Cisco side:<br>
>> >> > [CUT]<br>
>> >> > Jan 22 00:51:51.049 CET: %LDP-5-NBRCHG: LDP Neighbor <a href="http://1.1.1.1:0" rel="noreferrer" target="_blank">1.1.1.1:0</a> (2) is UP<br>
>> >> > Jan 22 00:51:51.053 CET: %LDP-4-PTCL: peer <a href="http://1.1.1.1:0" rel="noreferrer" target="_blank">1.1.1.1:0</a>, bad PDU hdr<br>
>> >> > Jan 22 00:51:51.053 CET: PDU HDR:<br>
>> >> > Jan 22 00:51:51.053 CET: 0x00 0x01 0x0F 0xFE 0x5D 0xBD 0xBF 0xFC 0x00 0x00 0x00 0x00<br>
>> >> > Jan 22 00:51:51.053 CET: %LDP-5-NBRCHG: LDP Neighbor <a href="http://1.1.1.1:0" rel="noreferrer" target="_blank">1.1.1.1:0</a> (2) is DOWN (Received bad message)<br>
>> >> > Jan 22 00:51:53.241 CET: %LDP-5-NBRCHG: LDP Neighbor <a href="http://1.1.1.12:0" rel="noreferrer" target="_blank">1.1.1.12:0</a> (7) is UP<br>
>> >> > Jan 22 00:51:53.245 CET: %LDP-4-PTCL: peer <a href="http://1.1.1.1:0" rel="noreferrer" target="_blank">1.1.1.1:0</a>, bad PDU hdr<br>
>> >> > Jan 22 00:51:53.245 CET: PDU HDR:<br>
>> >> > Jan 22 00:51:53.245 CET: 0x00 0x01 0x0F 0xFE 0x5D 0xBD 0xBF 0xFC 0x00 0x00 0x00 0x00<br>
>> >> > Jan 22 00:51:53.245 CET: %LDP-5-NBRCHG: LDP Neighbor <a href="http://1.1.1.1:0" rel="noreferrer" target="_blank">1.1.1.1:0</a> (7) is DOWN (Received bad message)<br>
>> >> > Jan 22 00:52:13.065 CET: %LDP-5-NBRCHG: LDP Neighbor <a href="http://1.1.1.1:0" rel="noreferrer" target="_blank">1.1.1.1:0</a> (2) is UP<br>
>> >> > Jan 22 00:52:13.069 CET: %LDP-4-PTCL: peer <a href="http://1.1.1.1:0" rel="noreferrer" target="_blank">1.1.1.1:0</a>, bad PDU hdr<br>
>> >> > Jan 22 00:52:13.069 CET: PDU HDR:<br>
>> >> > Jan 22 00:52:13.069 CET: 0x00 0x01 0x0F 0xFE 0x5D 0xBD 0xBF 0xFC 0x00 0x00 0x00 0x00<br>
>> >> > Jan 22 00:52:13.069 CET: %LDP-5-NBRCHG: LDP Neighbor <a href="http://1.1.1.1:0" rel="noreferrer" target="_blank">1.1.1.1:0</a> (2) is DOWN (Received bad message)<br>
>> >> > Jan 22 00:52:15.953 CET: %LDP-5-NBRCHG: LDP Neighbor <a href="http://1.1.1.1:0" rel="noreferrer" target="_blank">1.1.1.1:0</a> (7) is UP<br>
>> >> > Jan 22 00:52:15.957 CET: %LDP-4-PTCL: peer <a href="http://1.1.1.1:0" rel="noreferrer" target="_blank">1.1.1.1:0</a>, bad PDU hdr<br>
>> >> > Jan 22 00:52:15.957 CET: PDU HDR:<br>
>> >> > Jan 22 00:52:15.957 CET: 0x00 0x01 0x0F 0xFE 0x5D 0xBD 0xBF 0xFC 0x00 0x00 0x00 0x00<br>
>> >> > Jan 22 00:52:15.957 CET: %LDP-5-NBRCHG: LDP Neighbor <a href="http://1.1.1.1:0" rel="noreferrer" target="_blank">1.1.1.1:0</a> (7) is DOWN (Received bad message)<br>
>> >> > [/CUT]<br>
>> >> ><br>
>> >> ><br>
>> >> > FRR configuration:<br>
>> >> ><br>
>> >> > interface dummy0<br>
>> >> > ip address <a href="http://1.1.1.1/32" rel="noreferrer" target="_blank">1.1.1.1/32</a><br>
>> >> > !<br>
>> >> > interface enp2s0f0<br>
>> >> > description CORE-1<br>
>> >> > ip address <a href="http://10.224.1.22/30" rel="noreferrer" target="_blank">10.224.1.22/30</a><br>
>> >> > ip ospf network point-to-point<br>
>> >> > !<br>
>> >> > interface enp2s0f1<br>
>> >> > description CORE-2<br>
>> >> > ip address <a href="http://10.224.1.26/30" rel="noreferrer" target="_blank">10.224.1.26/30</a><br>
>> >> > ip ospf network point-to-point<br>
>> >> > !<br>
>> >> > mpls ldp<br>
>> >> > router-id 1.1.1.1<br>
>> >> > dual-stack cisco-interop<br>
>> >> > !<br>
>> >> > address-family ipv4<br>
>> >> > discovery hello holdtime 180<br>
>> >> > discovery hello interval 15<br>
>> >> > discovery transport-address 1.1.1.1<br>
>> >> > label local advertise explicit-null<br>
>> >> > !<br>
>> >> > interface enp2s0f0<br>
>> >> > !<br>
>> >> > interface enp2s0f1<br>
>> >> > !<br>
>> >> > exit-address-family<br>
>> >> > !<br>
>> >> > !<br>
>> >> ><br>
>> >> > Cisco configuration:<br>
>> >> ><br>
>> >> > mpls traffic-eng tunnels<br>
>> >> > mpls ip default-route<br>
>> >> > mpls label protocol ldp<br>
>> >> > interface Loopback0<br>
>> >> > ip address 2.2.2.2 255.255.255.255<br>
>> >> > !<br>
>> >> > interface TenGigabitEthernet1/1<br>
>> >> > description ASBR-FRR-TEST<br>
>> >> > mtu 1600<br>
>> >> > ip address 10.224.1.21 255.255.255.252<br>
>> >> > ip ospf network point-to-point<br>
>> >> > mpls traffic-eng tunnels<br>
>> >> > mpls ip<br>
>> >> > !<br>
>> >> ><br>
>> >> > 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.<br>
>> >> ><br>
>> >> > The result is that the devices don't share the labels becouse neighbors are down<br>
>> >> ><br>
>> >> > This is a bug? or wrong configuration?<br>
>> >> ><br>
>> >> > regards<br>
>> >> ><br>
>> >> > Alessio<br>
>> >> > _______________________________________________<br>
>> >> > frog mailing list<br>
>> >> > <a href="mailto:frog@lists.frrouting.org" target="_blank">frog@lists.frrouting.org</a><br>
>> >> > <a href="https://lists.frrouting.org/listinfo/frog" rel="noreferrer" target="_blank">https://lists.frrouting.org/listinfo/frog</a><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Renato Westphal<br>
>><br>
>><br>
>><br>
>> --<br>
>> Renato Westphal<br>
<br>
<br>
<br>
-- <br>
Renato Westphal<br>
</blockquote></div>