- frog - lists.frrouting.org

OSPF Interface Poll Interval
by Amol Lad 12 Feb '19

12 Feb '19

Hi, RFC4750 defines "ospfIfPollInterval" as "The larger time interval, in seconds, between the Hello packets sent to an inactive non-broadcast multi-access neighbor." Does FRR supports this? If yes, then please advise how to configure it? Thanks Amol ________________________________ The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).

1 0

FRRouting (6.0.2) now available in Debian buster/testing
by David Lamparter 11 Feb '19

11 Feb '19

Hi all, I'm pleased to announce FRRouting 6.0.2(-2) is now available in Debian testing (buster)! Please note that if you have an earlier version installed (e.g. from CI auto-packages), you will be auto-updated to 6.0.2 unless you mark the package for hold. It may be necessary to do this as the official Debian packages have been considerably cleaned up and reworked compared to 6.0 and older; there are some visible changes particularly in init scripts and startup behaviour. (These changes were merged in 6.0.1. If you already are at that or newer, the update should be smooth sailing.) Ubuntu has also auto-copied the package to their 19.04 / disco branch. This means that unless something unexpected happens, FRRouting will be available in the following upcoming distribution releases: - Debian 10 / buster (expected to become "stable" in 2~3 months) - Ubuntu 19.04 (expected to release end of April) If you have installed pre-release versions of either of these distributions, installing FRRouting is now a matter of doing a plain "apt install frr". FRRouting will very likely remain at the 6.0.x release train for both of these distributions. If you want to receive updates to newer major versions, manual intervention will still be needed (there might be a PPA/repo at some point.) Cheers, -David

3 3

Need help with bootstrap.sh
by muhammed ibrahim 03 Feb '19

03 Feb '19

Hello I am trying to configure FRR on CentOS 7 and I cloned the source code from github. The next step was to run ./bootstrap.sh but I can't seem to run the script. Whenever I run the script an error listed below shows up. ./bootstrap.sh: line 7: autoreconf: command not found What do I need to do? Here is the instruction below http://docs.frrouting.org/en/latest/installation.html#configuration FRR has an excellent configure script which automatically detects most host configurations. There are several additional configure options to customize the build to include or exclude specific features and dependencies. First, update the build system. Change into your FRR source directory and issue: ./bootstap.sh This will install any missing build scripts and update the Autotools configuration. Once this is done you can move on to choosing your configuration options from the list below. PS: I have also posted this on stackover flow but I haven't gotten a response yet. Sincerely, *Muhammed Ibrahim * *muhe31(a)gmail.com* <muhe31(a)gmail.com>

3 2

Daemons start error
by Amol Lad 01 Feb '19

01 Feb '19

Hi, First thanks to Tobias Jungel. With his help in providing Yocto recipe for FRR, I'm now running FRR on Solidrun's Clearfog platform. I'm running release 5.0.1 and get below error at startup. However, daemons do run even after the error. It seems I need to enable some more kernel config options. Please advise. root@clearfog:~# /usr/lib/frr/frr start Loading capability module if not yet done. Starting Frr daemons (prio:10):.1024 zebra2019/01/19 07:09:55 errors: ZEBRA: NS initialization failure 2(No such file or directory) 2019/01/19 07:09:56 warnings: ZEBRA: Disabling MPLS support (no kernel support) .1024 ospfd2019/01/19 07:09:56 errors: OSPF: NS initialization failure 2(No such file or directory) . Starting Frr monitor daemon:1024 watchfrr. Exiting from the script root@clearfog:~# ps 1410 frr 8308 S /usr/lib/frr/zebra --daemon -A 127.0.0.1 1417 frr 8916 S /usr/lib/frr/ospfd --daemon -A 127.0.0.1 1423 root 5628 S /usr/lib/frr/watchfrr -d -r /usr/sbin/servicebBfrrbBrestartbB%s -s /usr/sbin/servicebBfrrbBstartbB%s -k /usr/sbin/servicebBfrrbBstopbB%s -b bB zebra ospfd root@clearfog:~# ls -l /proc/self/ns/ lrwxrwxrwx 1 root root 0 Jan 19 07:11 cgroup -> cgroup:[4026531835] lrwxrwxrwx 1 root root 0 Jan 19 07:11 mnt -> mnt:[4026531840] root@clearfog:~# Thanks Amol ________________________________ The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).

2 1

Babeld COnfiguration
by Oguzhan Kayhan 31 Jan '19

31 Jan '19

Hello Testing babeld config with 6.0.2 FRR on CentOS 7 The problem is I dont see any neighbor on sh babel neighbor command, I can see the traffic with tcpdump on eth1..adn also i can ping the opposite server without a problem. I have two virtual servers having 4 interfaces.. eth0 is access port tesing babeld with eth1 and eth3 interfaces. Am I missing anything? *********************************** First server frr config; interface eth1 babel hello-interval 300 babel update-interval 100 babel wired ip address 192.168.100.1/24 ! router babel network eth1 redistribute ipv4 kernel redistribute ipv4 static redistribute ipv4 connected ! ----------- Second server: interface eth1 babel hello-interval 300 babel update-interval 100 babel wired ip address 192.168.100.2/24 ! interface eth3 ip address 192.168.254.2/24 ! router babel network eth1 network eth3 redistribute ipv4 kernel redistribute ipv4 static redistribute ipv4 connected My ip route outputs; 1st server: C>* 10.1.1.0/24 is directly connected, eth0, 00:11:59 C>* 192.168.100.0/24 is directly connected, eth1, 00:11:59 C>* 192.168.200.0/24 is directly connected, eth2, 00:11:59 Second Server: K>* 0.0.0.0/0 [0/100] via 10.1.1.1, eth0, 00:16:35 C>* 10.1.1.0/24 is directly connected, eth0, 00:16:35 C>* 192.168.100.0/24 is directly connected, eth1, 00:16:35 C>* 192.168.200.0/24 is directly connected, eth2, 00:16:35 C>* 192.168.254.0/24 is directly connected, eth3, 00:16:35 and centos1# *sh babel route * 0.0.0.0/0 metric 0 (exported) 10.1.1.0/24 metric 0 (exported) 192.168.100.0/24 metric 0 (exported) 192.168.200.0/24 metric 0 (exported) centos1# centos1# centos1# centos1# centos1# centos1# sh babel route 0.0.0.0/0 metric 0 (exported) 10.1.1.0/24 metric 0 (exported) 192.168.100.0/24 metric 0 (exported) 192.168.200.0/24 metric 0 (exported) centos1# *sh babel neighbor* centos1#* sh babel parameters * -- Babel running configuration -- state file = /var/run/frr/babel-state configuration file = /etc/frr/babeld.conf protocol information: multicast address = ff02::1:6 port = 6696 vty address = None vty port = 2609 id = 3e:13:48:ff:fe:39:a2:d3 kernel_metric = 0 -- distribution lists -- Outgoing update filter list for all interface is not set Incoming update filter list for all interface is not set

1 0

FRR - Route-Server / IPv6 error
by Duchet Rémy 30 Jan '19

30 Jan '19

Hello all, We have setup successfully FRR as route server (IPv4) with multiple PEER (Cisco ASR), and we are happy with the first part of the configuration. When we try to configure the same with IPv6, we have multiple problem, and the BGP session is always reset. Our setup : - CISCO ASR IOS-XE 16.1 and IOS-XE 15.4 - Physical server with Bond interface (2 x 10Gbps SFP+) and 1 UTP (for management purpose). - Private AS for the route-server - Public AS for all other router Purpose of this setup : - All router will announce his own learned BGP route to the RS - The RS will redistribute one FULL table to all router. Configuration on FRR (IP add and router-ID was changed: router bgp 65129 view rs bgp router-id 192.168.1.16 bgp log-neighbor-changes neighbor 2001:db8::2 remote-as 60129 neighbor 2001:db8::2 interface br0 neighbor 2001:db8::2 update-source br0 ! address-family ipv6 unicast neighbor 2001:db8::2 activate neighbor 2001:db8::2 as-override neighbor 2001:db8::2 soft-reconfiguration inbound neighbor 2001:db8::2 route-server-client exit-address-family Configuration on PEER (IP add and router-ID was changed: router bgp 60129 bgp router-id 192.168.0.2 no bgp enforce-first-as bgp log-neighbor-changes neighbor 2001:db8::16 remote-as 65129 neighbor 2001:db8::16 update-source Port-channel5.210 ! address-family ipv6 neighbor 2001:db8::16 activate neighbor 2001:db8::16 next-hop-self neighbor 2001:db8::16 allowas-in neighbor 2001:db8::16 soft-reconfiguration inbound exit-address-family ! Debug Log of FRR (real IPv6 was changed ): 2019/01/30 08:31:50 BGP: u7:s5 add peer 2001:db8::2 2019/01/30 08:31:50 BGP: 2001:db8::2: Interface not set appropriately to handle this some attributes 2019/01/30 08:31:50 BGP: 2001:db8::2: Attribute MP_REACH_NLRI, parse error - treating as withdrawal 2019/01/30 08:31:50 BGP: 2001:db8::2 rcvd UPDATE with errors in attr(s)!! Withdrawing route. 2019/01/30 08:31:50 BGP: 2001:db8::2 [Error] Update packet error (wrong prefix length 64 for afi 1) 2019/01/30 08:31:50 BGP: 2001:db8::2 [Error] Error parsing NLRI 2019/01/30 08:31:50 BGP: %NOTIFICATION: sent to neighbor 2001:db8::2 3/10 (UPDATE Message Error/Invalid Network Field) 0 bytes 2019/01/30 08:31:50 BGP: bgp_process_packet: BGP UPDATE receipt failed for peer: 2001:db8::2 2019/01/30 08:31:50 BGP: %ADJCHANGE: neighbor 2001:db8::2(Unknown) in vrf Down BGP Notification send 2019/01/30 08:31:50 BGP: 2001:db8::2 remove from all update group 2019/01/30 08:32:02 BGP: bind to interface br0 failed, errno=1 2019/01/30 08:32:02 BGP: 2001:db8::2 unrecognized capability code: 70 - ignored 2019/01/30 08:32:02 BGP: %ADJCHANGE: neighbor 2001:db8::2(Unknown) in vrf Up 2019/01/30 08:32:02 BGP: u7:s5 add peer 2001:db8::2 2019/01/30 08:32:02 BGP: 2001:db8::2: Interface not set appropriately to handle this some attributes 2019/01/30 08:32:02 BGP: 2001:db8::2: Attribute MP_REACH_NLRI, parse error - treating as withdrawal 2019/01/30 08:32:02 BGP: 2001:db8::2 rcvd UPDATE with errors in attr(s)!! Withdrawing route. 2019/01/30 08:32:02 BGP: 2001:db8::2 [Error] Update packet error (wrong prefix length 64 for afi 1) 2019/01/30 08:32:02 BGP: 2001:db8::2 [Error] Error parsing NLRI 2019/01/30 08:32:02 BGP: %NOTIFICATION: sent to neighbor 2001:db8::2 3/10 (UPDATE Message Error/Invalid Network Field) 0 bytes 2019/01/30 08:32:02 BGP: bgp_process_packet: BGP UPDATE receipt failed for peer: 2001:db8::2 2019/01/30 08:32:02 BGP: %ADJCHANGE: neighbor 2001:db8::2(Unknown) in vrf Down BGP Notification send 2019/01/30 08:32:02 BGP: 2001:db8::2 remove from all update group 2019/01/30 08:32:09 BGP: bind to interface br0 failed, errno=1 2019/01/30 08:32:09 BGP: 2001:db8::2 unrecognized capability code: 70 - ignored 2019/01/30 08:32:09 BGP: %ADJCHANGE: neighbor 2001:db8::2(Unknown) in vrf Up 2019/01/30 08:32:09 BGP: u7:s5 add peer 2001:db8::2 2019/01/30 08:32:09 BGP: 2001:db8::2: Interface not set appropriately to handle this some attributes 2019/01/30 08:32:09 BGP: 2001:db8::2: Attribute MP_REACH_NLRI, parse error - treating as withdrawal 2019/01/30 08:32:09 BGP: 2001:db8::2 rcvd UPDATE with errors in attr(s)!! Withdrawing route. 2019/01/30 08:32:09 BGP: 2001:db8::2 [Error] Update packet error (wrong prefix length 64 for afi 1) 2019/01/30 08:32:09 BGP: 2001:db8::2 [Error] Error parsing NLRI 2019/01/30 08:32:09 BGP: %NOTIFICATION: sent to neighbor 2001:db8::2 3/10 (UPDATE Message Error/Invalid Network Field) 0 bytes 2019/01/30 08:32:09 BGP: bgp_process_packet: BGP UPDATE receipt failed for peer: 2001:db8::2 2019/01/30 08:32:09 BGP: %ADJCHANGE: neighbor 2001:db8::2(Unknown) in vrf Down BGP Notification send 2019/01/30 08:32:09 BGP: 2001:db8::2 remove from all update group Debug log from 1 PEER : Jan 30 08:34:08.582: BGP: nbr global 2001:db8::16 Open active delayed 9216ms (35000ms max, 60% jitter) Jan 30 08:34:08.583: BGP: nbr global 2001:db8::16 Active open failed - open timer running Jan 30 08:34:17.773: BGP: 2001:db8::16 active went from Idle to Active Jan 30 08:34:17.773: BGP: 2001:db8::16 open active, local address 2A02:4FE0::2 Jan 30 08:34:17.774: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:0) act Adding topology IPv6 Unicast:base Jan 30 08:34:17.774: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:0) act Send OPEN Jan 30 08:34:17.774: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:0) act Building Enhanced Refresh capability Jan 30 08:34:17.774: BGP: 2001:db8::16 active went from Active to OpenSent Jan 30 08:34:17.774: BGP: 2001:db8::16 active sending OPEN, version 4, my as: 60129, holdtime 180 seconds, ID B9381902 Jan 30 08:34:17.774: BGP: 2001:db8::16 active rcv message type 1, length (excl. header) 70 Jan 30 08:34:17.774: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:0) act Receive OPEN Jan 30 08:34:17.774: BGP: 2001:db8::16 active rcv OPEN, version 4, holdtime 180 seconds Jan 30 08:34:17.774: BGP: 2001:db8::16 active rcv OPEN w/ OPTION parameter len: 60 Jan 30 08:34:17.774: BGP: 2001:db8::16 active rcvd OPEN w/ optional parameter type 2 (Capability) len 6 Jan 30 08:34:17.774: BGP: 2001:db8::16 active OPEN has CAPABILITY code: 1, length 4 Jan 30 08:34:17.774: BGP: 2001:db8::16 active OPEN has MP_EXT CAP for afi/safi: 1/1 Jan 30 08:34:17.774: BGP: 2001:db8::16 active rcvd OPEN w/ optional parameter type 2 (Capability) len 6 Jan 30 08:34:17.774: BGP: 2001:db8::16 active OPEN has CAPABILITY code: 1, length 4 Jan 30 08:34:17.774: BGP: 2001:db8::16 active OPEN has MP_EXT CAP for afi/safi: 2/1 Jan 30 08:34:17.774: BGP: 2001:db8::16 active rcvd OPEN w/ optional parameter type 2 (Capability) len 2 Jan 30 08:34:17.774: BGP: 2001:db8::16 active OPEN has CAPABILITY code: 128, length 0 Jan 30 08:34:17.774: BGP: 2001:db8::16 active OPEN has ROUTE-REFRESH capability(old) for all address-families Jan 30 08:34:17.774: BGP: 2001:db8::16 active rcvd OPEN w/ optional parameter type 2 (Capability) len 2 Jan 30 08:34:17.774: BGP: 2001:db8::16 active OPEN has CAPABILITY code: 2, length 0 Jan 30 08:34:17.774: BGP: 2001:db8::16 active OPEN has ROUTE-REFRESH capability(new) for all address-families Jan 30 08:34:17.774: BGP: 2001:db8::16 active rcvd OPEN w/ optional parameter type 2 (Capability) len 6 Jan 30 08:34:17.774: BGP: 2001:db8::16 active OPEN has CAPABILITY code: 65, length 4 Jan 30 08:34:17.774: BGP: 2001:db8::16 active OPEN has 4-byte ASN CAP for: 65129 Jan 30 08:34:17.774: BGP: 2001:db8::16 active rcvd OPEN w/ optional parameter type 2 (Capability) len 10 Jan 30 08:34:17.774: BGP: 2001:db8::16 active OPEN has CAPABILITY code: 69, length 8 Jan 30 08:34:17.774: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:0) act Add Path not supported for EBGP nbr 2001:db8::16. Jan 30 08:34:17.774: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:0) act Add Path not supported for EBGP nbr 2001:db8::16. Jan 30 08:34:17.774: BGP: 2001:db8::16 active rcvd OPEN w/ optional parameter type 2 (Capability) len 8 Jan 30 08:34:17.774: BGP: 2001:db8::16 active OPEN has CAPABILITY code: 73, length 6 Jan 30 08:34:17.774: BGP: 2001:db8::16 active unrecognized capability code: 73 - ingored Jan 30 08:34:17.774: BGP: 2001:db8::16 active rcvd OPEN w/ optional parameter type 2 (Capability) len 4 Jan 30 08:34:17.774: BGP: 2001:db8::16 active OPEN has CAPABILITY code: 64, length 2 Jan 30 08:34:17.774: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:0) act NSF OPEN has GR cap Jan 30 08:34:17.774: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:0) act NSF Peer has not restarted. Restart Time: 120 Jan 30 08:34:17.774: BGP: nbr global 2001:db8::16 neighbor does not have IPv4 MDT topology activated Jan 30 08:34:17.774: BGP: 2001:db8::16 active rcvd OPEN w/ remote AS 65129, 4-byte remote AS 65129 Jan 30 08:34:17.774: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:0) act Peer sent not matching OPEN AFCAP 0 Jan 30 08:34:17.774: BGP: 2001:db8::16 active went from OpenSent to OpenConfirm Jan 30 08:34:17.775: BGP: 2001:db8::16 active went from OpenConfirm to Established Jan 30 08:34:17.775: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:1) act Assigned ID Jan 30 08:34:17.775: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:1) Up Jan 30 08:34:17.775: %BGP-5-ADJCHANGE: neighbor 2001:db8::16 Up Jan 30 08:34:17.801: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:1) Remote close. Jan 30 08:34:17.801: BGP: nbr_topo global 2001:db8::16 IPv6 Unicast:base (0x7F2DB7BC45C8:1) Not scheduling for GR processing [Peer did not advertise GR cap] Jan 30 08:34:17.801: %BGP-5-NBR_RESET: Neighbor 2001:db8::16 reset (Peer closed the session) Jan 30 08:34:17.801: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:1) Reset (Peer closed the session). Jan 30 08:34:17.801: BGP: nbr_topo global 2001:db8::16 IPv6 Unicast:base (0x7F2DB7BC45C8:1) NSF delete stale NSF not active Jan 30 08:34:17.801: BGP: nbr_topo global 2001:db8::16 IPv6 Unicast:base (0x7F2DB7BC45C8:1) NSF no stale paths state is NSF not active Jan 30 08:34:17.802: BGP: nbr_topo global 2001:db8::16 IPv6 Unicast:base (0x7F2DB7BC45C8:1) Resetting ALL counters. Jan 30 08:34:17.802: BGP: 2001:db8::16 rcv message type 3, length (excl. header) 2 Jan 30 08:34:17.802: %BGP-3-NOTIFICATION: received from neighbor 2001:db8::16 3/10 (illegal network) 0 bytes Jan 30 08:34:17.802: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:1) Receive NOTIFICATION 3/10 (illegal network) 0 bytes Jan 30 08:34:17.802: BGP: 2001:db8::16 went from Established to Closing Jan 30 08:34:17.802: %BGP_SESSION-5-ADJCHANGE: neighbor 2001:db8::16 IPv6 Unicast topology base removed from session Peer closed the session Jan 30 08:34:17.802: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:1) Removed topology IPv6 Unicast:base Jan 30 08:34:17.802: BGP: ses global 2001:db8::16 (0x7F2DB7BC45C8:1) Removed last topology Jan 30 08:34:17.802: BGP: 2001:db8::16 closing Jan 30 08:34:17.802: BGP: 2001:db8::16 went from Closing to Idle Jan 30 08:34:17.802: %BGP-5-ADJCHANGE: neighbor 2001:db8::16 Down Peer closed the session Any help or comment will be very appreciated. Thanks in advance, Rémy

2 2

No NSSA areas on OSPFv3?
by Rodolfo Broco Manin 30 Jan '19

30 Jan '19

Hi there! Please excuse me if this is a silly question, but... Is it me or FRR does not support NSSA areas on OSPFv3 (via ospf6d)? Thank you! -- Rodolfo

1 0

Access to slack workspace
by Denys Myrhorodskyi 29 Jan '19

29 Jan '19

Hello, can you provide access to FRR workspace?

1 0

New Releases of FRR
by Donald Sharp 23 Jan '19

23 Jan '19

All - On Monday a research group installed into the global BGP routing table a prefix with a attribute type of 0xFF, which is designated as experimental by BGP RFC's. FRR had a developmental escape that read this attribute incorrectly and caused the bgp peering session to flap. If you have compiled FRR with the `--enable-bgp-vnc` option and run BGP as a peer on the global routing table you are vulnerable to this issue. This issue has been fixed in FRR with this commit: https://github.com/FRRouting/frr/commit/943d595a018e69b550db08cccba1d0778a8… We have applied this fix to the stable/3.0(3.0.4), stable/4.0(4.0.1), stable/5.0(5.0.2) and stable/6.0(6.0.2) branches. New releases can be found here: https://github.com/FRRouting/frr/releases/tag/frr-3.0.4 https://github.com/FRRouting/frr/releases/tag/frr-4.0.1 https://github.com/FRRouting/frr/releases/tag/frr-5.0.2 https://github.com/FRRouting/frr/releases/tag/frr-6.0.2 Snap packaging and the FreeBSD ports have been updated as well. We recommend you update your installation of FRR immediately. At this point we are applying for a CVE and will announce that information when we have it. In the near future we plan to implement RFC-7606 to handle this situation better in BGP, if you have any questions please feel free to email me, or to open up discussions on the frog alias. thanks! donald

6 11

[LDP] status Bad PDU Length (fatal error)
by Alessio Leonarduzzi 23 Jan '19

23 Jan '19

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

3 7