[FROG] [LDP] status Bad PDU Length (fatal error)
Alessio Leonarduzzi
alessio.leonarduzzi at gmail.com
Wed Jan 23 05:37:25 EST 2019
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 a 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 a 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 a 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 a 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 a 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 a 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 a lists.frrouting.org
> >> >> > https://lists.frrouting.org/listinfo/frog
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Renato Westphal
> >>
> >>
> >>
> >> --
> >> Renato Westphal
>
>
>
> --
> Renato Westphal
>
-------------- parte successiva --------------
Un allegato HTML รจ stato rimosso...
URL: <http://lists.frrouting.org/pipermail/frog/attachments/20190123/620184c6/attachment-0001.html>
More information about the frog
mailing list