January 2019 - frog - lists.frrouting.org

Yocto Recipe for FRR
by Amol Lad 10 Aug '21

10 Aug '21

Hi, Please advise if there is any Yocto recipe for FRRouting? If not, how to go about creating one for FRR? Yocto Recipe for FRR will hugely simplify integrating FRR in Yocto based embedded linux distributions. So please advise if there are any plans to develop this recipe? 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).

4 10

v6 Route Replace semantics
by Donald Sharp 09 Apr '20

09 Apr '20

All - We recently introduced, into master, a new cli switch for zebra on linux `--v6-rr-semantics`. This was allow zebra to take advantage of the linux kernel getting v6 route replace semantics that is coming soon in the 4.18 linux kernel. So if you are on the bleeding edge of linux kernels and FRR you can start to take advantage of this new feature. What are Route Replace semantics you ask? Suppose we have a v6 route with 2 nexthops: S>* 4:6:7::/64 [1/0] via 1:2:3::4, enp0s3, 00:00:02 via 1:2:8::8, enp0s8, 00:00:02 Now suppose we remove a nexthop: robot# conf t robot(config)# no ipv6 route 5:7:9::/78 1:2:8::9 robot(config)# end robot# show ipv6 route [snip] S>* 5:7:9::/78 [1/0] via 1:2:3::4, enp0s3, 00:01:04 Let's look at the netlink notifications for this event: [ROUTE]5:7:9::/78 proto static metric 20 <----------- From creation of the 2x ecmp for 5:7:9::/78 nexthop via 1:2:3::4 dev enp0s3 weight 1 nexthop via 1:2:8::9 dev enp0s8 weight 1 [ROUTE]Deleted 5:7:9::/78 proto static metric 20 <---- We delete the route nexthop via 1:2:3::4 dev enp0s3 weight 1 nexthop via 1:2:8::9 dev enp0s8 weight 1 [ROUTE]5:7:9::/78 via 1:2:3::4 dev enp0s3 proto static metric 20 pref medium <----- We add it back in. In order to get the routes right in the kernel we had to delete the route first and then add it back in. Exposing a small window of packets being dropped while the route is fixed in the fib. Route Replace semantics tells the linux kernel to just replace the nexthops for the route. New packets coming in would immediately start using the new ecmp nexthop group path: [ROUTE]5:7:9::/78 proto static metric 20 nexthop via 1:2:3::4 dev enp0s3 weight 1 nexthop via 1:2:8::9 dev enp0s8 weight 1 [ROUTE]5:7:9::/78 via 1:2:3::4 dev enp0s3 proto static metric 20 pref medium thanks! donald

2 1

FRR on NRL CORE (fyi)
by Phil Wiggins 11 Apr '19

11 Apr '19

If anyone is interested in running FRR in the NRL CORE emulation environment, I have some build scripts for FRR on CORE that I posted at the first link below. Normally CORE runs Quagga, so this script was a hack to shoehorn FRR as a Quagga replacement. These scripts are not part of CORE yet, so are unsupported. People on this list may want to use CORE for FRR experimentation and testing, so you can customize these scripts to suit your own needs. It's best to run this stuff in a VM with no internet connection (after installation) since CORE runs lots of processes as root - a well-known security issue. https://github.com/coreemu/core/issues/170 ( install_frr_for_core.sh) FRR on NRL CORE build script - assumes Ubuntu 16.04.4 clean installation in a VM or physical host: https://gist.github.com/apwiggins/44f3592a61965783372aea5881ed9f7a (core_misc_frr.py ) used by the install script above to install at ./core/misc/frr.py https://gist.github.com/apwiggins/d610c2794c8c0a12a45bfc093fd2e949 (core_services_frr.py) used by the install script above to install at ./core/services/frr.py https://gist.github.com/apwiggins/747a9a14feff2ce3a3b8760406b825a7 https://www.nrl.navy.mil/itd/ncs/products/core The Common Open Research Emulator (CORE) is a tool for emulating networks on one or more machines. You can connect these emulated networks to live networks. CORE consists of a GUI for drawing topologies of lightweight virtual machines, and Python modules for scripting network emulation. Cheers, Phil

2 3

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 24 Jan '19

24 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

Re: [FROG] Difference between releases
by Martin Winter 21 Jan '19

21 Jan '19

On 19 Jan 2019, at 8:50, Antoine Joubert via frog wrote: > Hi, > > Sorry if this has been asked before, but I was wondering, what is the > difference between the > https://github.com/FRRouting/frr/releases/tag/frr-6.0.2 release and > the https://github.com/FRRouting/frr/releases/tag/debian%2Ffrr-6.0.2-1 > release ? > > The debian package provided for the first one seems to be the 6.0.2-0 > version. Is the second one newer ? If so, why are there no package > download available ? In general, approximately no difference. The frr-6.0.2 is the current latest official FRR release. The Debian one is part of the work to get FRR into the debian distribution and should follow the official release. In practice however, debian maintainers and debian packages are frequently with some changes/patches in comparison to official releases on any package. In the case of FRR, we try to avoid any changes as far as possible, but as part of the testing and getting FRR into debian, there is a good chance for a few changes in the near term (which would then be integrated into further FRR releases whenever possible). Not sure if this explains it, but in general: - Use our official releases (which has packages on GitHub) until the FRR release is part of the debian packages. - Once we have them in there (you’ll hear an announcement), then we may stop providing debian packages ourself and you would get packages from the debian package archives. - Ignore the differences. If there would be anything important, then we would make a new version anyway. Hope this explains it somehow Regards, Martin Winter

2 1