- frog - lists.frrouting.org

bgp multipath duplicate kernel routes
by Leonardo Porto 28 Oct '22

28 Oct '22

Hi everyone, I have a new FRR instalation on Rocky Linux and realized I have duplicate kernel routes for same-cost received routes from two distint peers. It seems to be a default multipath behavior (the router shares the traffic indeed) but I would like to disable it and I could not find out how. Can you guys give me any tips? [router]# vtysh -c "show ip bgp X.Y.Z.0/22" BGP routing table entry for X.Y.Z.0/22, version 15072201 Paths: (2 available, best #2, table default) Not advertised to any peer Local A.B.144.30 from A.B.144.5 (A.B.144.30) Origin IGP, metric 0, localpref 100, valid, internal, multipath Originator: A.B.144.30, Cluster list: A.B.144.1 Last update: Fri Oct 28 03:16:08 2022 Local C.D.113.30 from C.D.113.5 (A.B.144.30) Origin IGP, metric 0, localpref 100, valid, internal, multipath, best (Neighbor IP) Originator: A.B.144.30, Cluster list: C.D.113.1 Last update: Fri Oct 28 03:16:01 2022 # [router]# ip route show X.Y.Z.0/22 X.Y.Z.0/22 proto bgp metric 20 nexthop via C.D.113.5 dev eth0.1001 weight 1 nexthop via A.B.144.5 dev eth0.1001 weight 1 The workaround is to apply local-pref. Rocky Linux release 8.6 4.18.0-372.26.1.el8_6.x86_64 FRRouting (version 8.3.1) Leonardo

1 0

VxLAN EVPN VTEP on Linux host with frr 8.3.1 no communication
by 0xbabaf00l 11 Oct '22

11 Oct '22

Hi list, I'm trying to run a VxLAN EVPN VTEP (multicast BUM) on a Linux host running frr 8.3.1. The interface is up, but there is no traffic going in or coming out the VTEP. I get these messages in frr.log: zebra[68]: [VB5HM-D56CP] remote es 03:44:38:39:fe:ed:01:00:00:01 vtep 10.224.4.1 add with unsupported df_alg 0 zebra[68]: [VB5HM-D56CP] remote es 03:44:38:39:fe:ed:01:00:00:01 vtep 10.224.4.2 add with unsupported df_alg 0 zebra[68]: [VB5HM-D56CP] remote es 03:44:38:39:be:ef:03:00:00:01 vtep 10.224.5.31 add with unsupported df_alg 0 zebra[68]: [VB5HM-D56CP] remote es 03:44:38:39:be:ef:03:00:00:01 vtep 10.224.5.32 add with unsupported df_alg 0 'ip mroute' doesn't show any entries at all. I tried to subscribe to a random multicast group using 'ip addr add 239.255.55.55/32 dev lo autojoin' to verify that multicast routing is working in general and it does create entries in 'ip mroute' output on the Linux host and the PIM routers connected to. So for me, multicast seems to be working. The other VTEPs are on Mellanox switches running Cumulus Linux 5.2.1. The other VTEPs can reach each other. Any idea whats wrong? The config files are mostly identical to the ones on the Cumulus switches. My setup: - Debian Linux 11 bullseye - Kernel 5.18.16-1~bpo11+1 - frr 8.3.1 running in privileged docker container - ifupdown2 3.1.0-1 - network interfaces (2) unnumbered via eBGP /etc/network/interfaces: auto lo iface lo inet loopback address 10.224.6.11/32 address xxxx:yyyy:zzzz:20ff:1:1:6:11/128 auto 100g-1 iface 100g-1 mtu 9200 auto 100g-1.11 iface 100g-1.11 mtu 9200 auto 100g-2 iface 100g-2 mtu 9200 auto 100g-2.11 iface 100g-2.11 mtu 9200 auto bridge iface bridge bridge-ports vxlan-3560 bridge-vlan-aware yes bridge-vids 3560 auto vxlan-3560 iface vxlan-3560 vxlan-id 3560 vxlan-mcastgrp 239.255.35.60 bridge-access 3560 bridge-learning off auto vlan-3560 iface vlan-3560 vlan-raw-device bridge vlan-id 3560 address 10.4.31.100/24 /etc/frr/frr.conf: service integrated-vtysh-config frr defaults datacenter log syslog debugging ip forwarding ipv6 forwarding ! interface lo vrf default ip pim ip igmp ! interface 100g-1.11 vrf default ipv6 nd ra-interval 5 no ipv6 nd suppress-ra ip pim ip pim bfd ! interface 100g-2.11 vrf default ipv6 nd ra-interval 5 no ipv6 nd suppress-ra ip pim ip pim bfd ! ip pim ecmp ip pim rp 10.224.255.1 239.255.0.0/16 ! router bgp 4242000601 vrf default bgp router-id 10.224.6.11 bgp bestpath as-path multipath-relax bgp bestpath compare-routerid neighbor firewall.underlay peer-group neighbor firewall.underlay remote-as external neighbor firewall.underlay capability extended-nexthop neighbor firewall.underlay bfd neighbor firewall.underlay password XXXXXXXXXXXX neighbor 100g-1.11 interface peer-group firewall.underlay neighbor 100g-2.11 interface peer-group firewall.underlay ! address-family ipv4 unicast network 10.224.6.11/32 exit-address-family ! address-family ipv6 unicast neighbor firewall.underlay activate network xxxx:yyyy:zzzz:20ff:1:1:6:11/128 exit-address-family ! address-family l2vpn evpn neighbor firewall.underlay activate advertise-all-vni exit-address-family vtysh# sh bgp l2vpn evpn summary BGP router identifier 10.224.6.11, local AS number 4242000601 vrf-id 0 BGP table version 0 RIB entries 1907, using 358 KiB of memory Peers 2, using 1447 KiB of memory Peer groups 1, using 64 bytes of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc 1-rtr-leaf-core-cit(100g-1.11) 4 4242000101 12114 12088 0 0 0 09:10:56 974 974 N/A 2-rtr-leaf-core-cit(100g-2.11) 4 4242000102 12131 12087 0 0 0 09:10:53 974 974 N/A Total number of neighbors 2 vtysh# sh evpn vni detail json 1a-fw-vnt-core-cit# sh evpn vni VNI Type VxLAN IF # MACs # ARPs # Remote VTEPs Tenant VRF 3560 L2 vxlan-3560 2 0 0 default vtysh# sh evpn l2-nh VTEP NH id #ES 10.224.5.31 268435461 1 10.224.4.2 268435459 1 10.224.5.32 268435462 1 10.224.4.1 268435458 1 vtysh# sh evpn es Type: B bypass, L local, R remote, N non-DF ESI Type ES-IF VTEPs 03:44:38:39:be:ef:03:00:00:01 R - 10.224.5.31,10.224.5.32 03:44:38:39:fe:ed:01:00:00:01 R - 10.224.4.1,10.224.4.2 vtysh# sh evpn next-hops vni all [nothing] Cheers, Sascha

1 1

Prefix pointing to itself as a NH
by Mark Kamichoff 28 Aug '22

28 Aug '22

Hi - I noticed that after upgrading a few of my boxes to FRR 8, link prefixes are no longer advertised in BGP. I tracked it down to this commit: https://github.com/FRRouting/frr/commit/654a5978f695087af062bfc9a382321fa2c… More info: I run EBGP w/ FRR over a few P-t-P OpenVPN tunnels that are configured similar to the following: (dax:23:35:EDT)% ifconfig tun0 tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1414 options=80000<LINKSTATE> inet 10.3.254.11 --> 10.3.254.12 netmask 0xffffffff inet6 2620:6:2000:1ff::1181 prefixlen 124 inet6 fe80::202:bcff:fe56:cb39%tun0 prefixlen 64 scopeid 0x11 groups: tun nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> Opened by PID 53497 Each side of the link is configured as a /32. I have network statements in FRR so that each side advertises its own /32 on the link, to allow applications that don't bind to the loopback to work properly. This has worked fine up until FRR 8 on both FreeBSD & Linux. For example, peer 10.3.254.83 is advertising 10.3.254.83/32 and it's being accepted: nox# show ip bgp nei 10.3.254.83 routes BGP table version is 70477, local router ID is 10.3.4.20, vrf id 0 Default local pref 100, local AS 65307 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.3.4.18/32 10.3.254.83 0 65306 i *> 10.3.254.36/32 10.3.254.83 0 65306 i *> 10.3.254.83/32 10.3.254.83 0 65306 i Displayed 3 routes and 1222 total paths nox# show ip bgp 10.3.254.83/32 BGP routing table entry for 10.3.254.83/32 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: 10.3.254.5 10.3.254.9 10.3.254.21 10.3.254.40 10.3.254.44 10.3.254.73 10.3.254.83 10.3.254.85 10.3.254.94 10.3.254.113 10.3.254.164 10.3.254.179 65304 65306 10.3.254.21 from 10.3.254.21 (10.3.4.6) Origin IGP, valid, external Last update: Sun Aug 28 22:17:11 2022 65306 10.3.254.83 from 10.3.254.83 (10.3.4.18) Origin IGP, valid, external, best (AS Path) Last update: Sun Aug 28 10:29:03 2022 However, in FRR 8, this no longer works due to the commit above. Example for 10.3.254.12 advertising 10.3.254.12/32: dax.prolixium.com# show ip bgp neighbors 10.3.254.12 routes BGP table version is 280, local router ID is 10.3.4.6, vrf id 0 Default local pref 100, local AS 65304 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 10.3.4.25/32 10.3.254.12 0 0 65307 i 10.3.254.12/32 10.3.254.12 0 0 65307 i Displayed 2 routes and 1212 total paths dax.prolixium.com# show ip bgp 10.3.254.12/32 BGP routing table entry for 10.3.254.12/32, version 278 Paths: (2 available, best #2, table default) Advertised to non peer-group peers: 10.3.4.35 10.3.7.238 10.3.254.4 10.3.254.12 10.3.254.14 10.3.254.20 10.3.254.23 10.3.254.36 10.3.254.67 10.3.254.81 10.3.254.115 10.3.254.122 10.3.254.161 65307 10.3.254.12 (inaccessible) from 10.3.254.12 (10.3.4.25) Origin IGP, metric 0, invalid, external Last update: Sun Aug 28 23:42:58 2022 Local 0.0.0.0 from 0.0.0.0 (10.3.4.6) Origin IGP, metric 0, weight 32768, valid, sourced, local, best (First path received) Last update: Sun Aug 28 23:23:21 2022 dax.prolixium.com# When turning up debugs, this is clearly seen in the logs: 2022/08/28 23:06:47 BGP: [T5AAP-5GA85] 10.3.254.12(trance_bgpd) rcvd UPDATE w/ attr: nexthop 10.3.254.12, origin i, metric 0, path 65307 2022/08/28 23:06:47 BGP: [PCFFM-WMARW] 10.3.254.12(trance_bgpd) rcvd UPDATE wlen 0 attrlen 28 alen 10 2022/08/28 23:06:47 BGP: [YCKEM-GB33T] 10.3.254.12(trance_bgpd) rcvd 10.3.4.25/32 IPv4 unicast 2022/08/28 23:06:47 BGP: [J47J0-K06GG] Found existing bnc 10.3.254.12/32(VRF default) flags 0xf ifindex 0 #paths 0 peer 0x82fb50740 2022/08/28 23:06:47 BGP: [YCKEM-GB33T] 10.3.254.12(trance_bgpd) rcvd 10.3.254.12/32 IPv4 unicast 2022/08/28 23:06:47 BGP: [N1KDM-HR02D] bgp_find_or_add_nexthop(10.3.254.12/32): prefix loops through itself 2022/08/28 23:06:47 BGP: [YT4EY-7V2YV] bgp_update(10.3.254.12): NH unresolved Are there workarounds for this or is this capability something that FRR has intentionally dropped permanently (and I should renumber my tunnels..)? Thanks! - Mark -- Mark Kamichoff prox(a)prolixium.com https://www.prolixium.com/

1 0

Re: [FROG] Change default zebra routing table
by Tito Sacchi 20 Aug '22

20 Aug '22

Hi, it looks like the problem is a /32 route directed to the gateway installed by the DHCP client (systemd-networkd). `show ip route` from vtysh shows: […] C>* 10.8.10.0/24 [0/1024] is directly connected, public, 02:27:44 K>* 10.8.10.1/32 [0/1024] is directly connected, public, 02:27:44 […] O 192.168.65.0/24 [110/200] via 10.8.10.1, public inactive, weight 1, 02:27:29 […] If I manually remove that /32 route from the routing table and restart FRR, the buggy route (192.168.65.0/24) get installed correctly and 'nexthop_active: Route Type ospf has not turned on recursion’ does not show up in the logs. I could manually remove that route (which is completely useful AFAICT) manually before starting FRR with a script, but I still wonder why FRR fails to use 10.8.10.1 as a valid nexthop, considering that from the above output it sees 10.8.10.1 as `directly connected` just like the route above. Why does one get a ‘C’ and the other gets a ‘K’? I think that’s the only difference and therefore the only thing that could be causing the problem. Thanks, Tito > On 19 Aug 2022, at 23:33, Tito Sacchi via frog <frog(a)lists.frrouting.org> wrote: > > > From: Tito Sacchi <tito+mailinglists(a)tilde.team> > Subject: Re: [FROG] Change default zebra routing table > Date: 19 August 2022 at 23:33:08 CEST > To: Donald Sharp <donaldsharp72(a)gmail.com> > Cc: FRRouting Operator Group - Users List <frog(a)lists.frrouting.org> > > > Hi Donald, thanks for your reply. > > I made Zebra dump diagnostics information and it produced a *lot* of debugging information in the logs. A relevant extract of the detailed log can be found at > https://bhh.sh/6gm (pastebin). > > I think the lines responsible for the 192.168.65.0/24 route not being installed are the following: > > 2022/08/19 15:49:55 ZEBRA: [ZJVZ4-XEGPF] default(0:254):192.168.65.0/24: Examine re 0x557c9e4eb100 (ospf) status: Changed flags: None dist 110 metric 200 > 2022/08/19 15:49:55 ZEBRA: [GG8QH-195KE] nexthop_active_update: re 0x557c9e4eb100 nhe 0x557c9e4eb240 (547), curr_nhe 0x557c9e4eb7d0 > 2022/08/19 15:49:55 ZEBRA: [T9JWA-N8HM5] nexthop_active_check: re 0x557c9e4eb100, nexthop 10.8.10.1, via public > 2022/08/19 15:49:55 ZEBRA: [M7EN1-55BTH] nexthop_active: Route Type ospf has not turned on recursion > 2022/08/19 15:49:55 ZEBRA: [HJ48M-MB610] nexthop_active_check: Unable to find active nexthop > 2022/08/19 15:49:55 ZEBRA: [ZG85Y-SBJH3] nexthop_active_update: re 0x557c9e4eb100 curr_active 0 > 2022/08/19 15:49:55 ZEBRA: [G6MN6-TB7HQ] zebra_nhg_free: nhe 0x557c9e4eb7d0 (0), refcnt 0, NH 10.8.10.1, via public > > However, 10.8.10.1 is a perfectly valid nexthop directly connected to the host via the ‘public’ interface. > `ip -4 neigh` yields: > > […] > id 541 via 10.8.10.1 dev public scope link proto zebra > […] > > `show nexthop-groups rip` from vtysh: > > [...] > ID: 597 (zebra) > RefCnt: 1 > Uptime: 00:14:31 > VRF: default > Interface Index: 9 > via 10.8.10.1, public (vrf default) inactive, weight 1 > [...] > ID: 541 (zebra) > RefCnt: 1 > Uptime: 00:14:40 > VRF: default > Valid, Installed > Interface Index: 9 > via 10.8.10.1, public (vrf default), src 10.8.10.198 > [...] > > So apparently Zebra keeps two differentt nexthops directed to 10.8.10.1 on interface ‘public’. Why is one of them kept inactive? I think the issue lies there. > The thing that I can’t really understand is why (as you can see from the above pastebin) other routes to other nexthops (such as 10.8.10.135) directly attached to the ‘public’ interface are correctly installed. Why doesn’t Zebra consider 10.8.10.1 a nexthop just like 10.8.10.135? > > Thanks for your time, > Tito > >> On 19 Aug 2022, at 13:37, Donald Sharp <donaldsharp72(a)gmail.com> wrote: >> >> table was removed from FRR because it was a broken command and as such no-one could be using it: >> >> commit c447ad08b2c880d5f3ef35af2e4055fcbc970961 (origin/pr/4256) >> Author: Donald Sharp <sharpd(a)cumulusnetworks.com> >> Date: Fri May 3 20:54:20 2019 -0400 >> >> doc, zebra: Remove "table X" command >> >> This command is broken and has been broken since the introduction >> of vrf's. Since no-one has complained it is safe to assume that >> there is no call for this specialized linux command. Remove >> from the system with extreme prejudice. >> >> >> >> An `inactive` route has failed to be installed for a different reason. Not for the reason you have stated. Can we see the output of `show ip route 10.8.10.1` ? Also turn on `debug zebra rib detail` and `debug zebra nexthop detail` and cause the ospf route to be reinstalled. Let's see what the logs spit out. >> >> Finally have you looked at FRR's version of PBR? Why wouldn't that work for you? >> >> donald >> >> >> On Fri, Aug 19, 2022 at 3:35 AM Tito Sacchi via frog <frog(a)lists.frrouting.org> wrote: >> >> >> >> ---------- Forwarded message ---------- >> From: Tito Sacchi <tito+mailinglists(a)tilde.team> >> To: frog(a)lists.frrouting.org >> Cc: >> Bcc: >> Date: Fri, 19 Aug 2022 08:25:49 +0200 >> Subject: Change default zebra routing table >> Hi everyone, >> >> Quagga has a command called ’table’ that can be used to specify which table Zebra should install dynamic routes in. >> Is there anything similar in FRR? >> By default, routes are installed in table 254 (‘main’). But I have a complex PBR setup and Zebra fails to install some routes >> because they are covered by a default route already present in table 254. But because of PBR, packets do not follow that default route and the subnet that comes >> from OSPF and that I expect Zebra to install is not reachable: >> >> K>* 0.0.0.0/0 [0/1024] via 10.8.10.1, eth0, src 10.8.10.135, 06:50:14 >> [...] >> O 192.168.65.0/24 [110/110] via 10.8.10.1, eth0 inactive, weight 1, 06:50:09 >> >> I think the last route is not installed (kept ‘inactive’) because it is covered by the default route at the top. >> >> How can I tell zebra to consider another routing table? I would like to avoid enslaving all my interfaces to a VRF device. >> If it cannot be done with a simple ’table’ command, should I use route maps? They support the `set table` action but according to the manual it has to do with BGP and it does not do what I want. >> >> Thanks, >> Tito >> >> — — — >> https://tilde.team/~tito/ >> >> PGP key: 0x6BED3002CF25C4D2 (4096R) >> (https://keys.openpgp.org/search?q=0x6BED3002CF25C4D2) >> >> Keybase: @tauroh >> (https://keybase.io/tauroh) >> >> >> >> >> >> ---------- Forwarded message ---------- >> From: Tito Sacchi via frog <frog(a)lists.frrouting.org> >> To: frog(a)lists.frrouting.org >> Cc: >> Bcc: >> Date: Fri, 19 Aug 2022 08:25:49 +0200 >> Subject: [FROG] Change default zebra routing table >> _______________________________________________ >> frog mailing list >> frog(a)lists.frrouting.org >> https://lists.frrouting.org/listinfo/frog > > > > > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog

1 0

Re: [FROG] Change default zebra routing table
by Donald Sharp 19 Aug '22

19 Aug '22

table was removed from FRR because it was a broken command and as such no-one could be using it: commit c447ad08b2c880d5f3ef35af2e4055fcbc970961 (origin/pr/4256) Author: Donald Sharp <sharpd(a)cumulusnetworks.com> Date: Fri May 3 20:54:20 2019 -0400 doc, zebra: Remove "table X" command This command is broken and has been broken since the introduction of vrf's. Since no-one has complained it is safe to assume that there is no call for this specialized linux command. Remove from the system with extreme prejudice. An `inactive` route has failed to be installed for a different reason. Not for the reason you have stated. Can we see the output of `show ip route 10.8.10.1` ? Also turn on `debug zebra rib detail` and `debug zebra nexthop detail` and cause the ospf route to be reinstalled. Let's see what the logs spit out. Finally have you looked at FRR's version of PBR? Why wouldn't that work for you? donald On Fri, Aug 19, 2022 at 3:35 AM Tito Sacchi via frog < frog(a)lists.frrouting.org> wrote: > > > > ---------- Forwarded message ---------- > From: Tito Sacchi <tito+mailinglists(a)tilde.team> > To: frog(a)lists.frrouting.org > Cc: > Bcc: > Date: Fri, 19 Aug 2022 08:25:49 +0200 > Subject: Change default zebra routing table > Hi everyone, > > Quagga has a command called ’table’ that can be used to specify which > table Zebra should install dynamic routes in. > Is there anything similar in FRR? > By default, routes are installed in table 254 (‘main’). But I have a > complex PBR setup and Zebra fails to install some routes > because they are covered by a default route already present in table 254. > But because of PBR, packets do not follow that default route and the subnet > that comes > from OSPF and that I expect Zebra to install is not reachable: > > K>* 0.0.0.0/0 [0/1024] via 10.8.10.1, eth0, src 10.8.10.135, 06:50:14 > [...] > O 192.168.65.0/24 [110/110] via 10.8.10.1, eth0 inactive, weight 1, > 06:50:09 > > I think the last route is not installed (kept ‘inactive’) because it is > covered by the default route at the top. > > How can I tell zebra to consider another routing table? I would like to > avoid enslaving all my interfaces to a VRF device. > If it cannot be done with a simple ’table’ command, should I use route > maps? They support the `set table` action but according to the manual it > has to do with BGP and it does not do what I want. > > Thanks, > Tito > > — — — > https://tilde.team/~tito/ > > PGP key: 0x6BED3002CF25C4D2 (4096R) > (https://keys.openpgp.org/search?q=0x6BED3002CF25C4D2) > > Keybase: @tauroh > (https://keybase.io/tauroh) > > > > > > ---------- Forwarded message ---------- > From: Tito Sacchi via frog <frog(a)lists.frrouting.org> > To: frog(a)lists.frrouting.org > Cc: > Bcc: > Date: Fri, 19 Aug 2022 08:25:49 +0200 > Subject: [FROG] Change default zebra routing table > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog >

2 1

Change default zebra routing table
by Tito Sacchi 18 Aug '22

18 Aug '22

Hi everyone, Quagga has a command called ’table’ that can be used to specify which table Zebra should install dynamic routes in. Is there anything similar in FRR? By default, routes are installed in table 254 (‘main’). But I have a complex PBR setup and Zebra fails to install some routes because they are covered by a default route already present in table 254. But because of PBR, packets do not follow that default route and the subnet that comes from OSPF and that I expect Zebra to install is not reachable: K>* 0.0.0.0/0 [0/1024] via 10.8.10.1, eth0, src 10.8.10.135, 06:50:14 [...] O 192.168.65.0/24 [110/110] via 10.8.10.1, eth0 inactive, weight 1, 06:50:09 I think the last route is not installed (kept ‘inactive’) because it is covered by the default route at the top. How can I tell zebra to consider another routing table? I would like to avoid enslaving all my interfaces to a VRF device. If it cannot be done with a simple ’table’ command, should I use route maps? They support the `set table` action but according to the manual it has to do with BGP and it does not do what I want. Thanks, Tito — — — https://tilde.team/~tito/ PGP key: 0x6BED3002CF25C4D2 (4096R) (https://keys.openpgp.org/search?q=0x6BED3002CF25C4D2) Keybase: @tauroh (https://keybase.io/tauroh)

1 0

CNTRL+Z change
by mike tancsa 17 Aug '22

17 Aug '22

Was just taking frr 8.3 for a spin and noticed it no longer acts the same way with respect to ctrl+z. From 7.x and before, when in config mode this took you out of config mode. Now it takes me right out of vtysh. Is this a something that can be configured ? Base OS is FreeBSD 13 e.g. on 7.x % sudo vtysh Hello, this is FRRouting (version 7.5.1). Copyright 1996-2005 Kunihiro Ishiguro, et al. frr-test# conf t frr-test(config)# ^Z frr-test# exit % on 8.3 if I hit ^Z in config mode, I just get punted back to the shell 0(test83)# vtysh Hello, this is FRRouting (version 8.3). Copyright 1996-2005 Kunihiro Ishiguro, et al. test83.sentex.ca# conf test83.sentex.ca(config)# test83.sentex.ca# 0(test83)# ---Mike

3 3

STARVATION: task vtysh_rl_read
by mike tancsa 17 Aug '22

17 Aug '22

Moving a server with a lot of bgp peers (600), doing a show ip bgp sum and paging output in less, I am getting these error or warning messages pop up. 2022/08/17 15:20:12 [PHJDC-499N2][EC 100663314] STARVATION: task vtysh_rl_read (2faff0) ran for 6664ms (cpu time 0ms) If I just page through all the peers quickly, its not an issue Using setenv VTYSH_PAGER '/usr/bin/less -EFX' or not, does not seem to make a difference. If I do a show ip bgp sum, and pause through the list for more than a few seconds, that error/warning comes up. Is it something that can be safely ignored ? ---Mike

2 1

'neighbor PEER send-community'
by Willy Manga 30 Jul '22

30 Jul '22

Hello, I don't know if I am doing something wrong ... In config mode, when I add 'neighbor X.X.X.X send-community' and I review the configuration, I do not see my statement. However I'm receiving community in the other side. So I'm confused. Is something sent by default or am I missing something? By the way, I have noticed 'neighbor PEER send-community' is not documented in FRR documentation[1]. 1. http://docs.frrouting.org/en/latest/bgp.html -- Willy Manga @ongolaboy https://ongola.blogspot.com/

2 1

FRR 8.3 Release
by Jafar Al-Gharaibeh 20 Jul '22

20 Jul '22

Dear FRR Community, We are pleased to announce FRR 8.3 release. This release brings a long list of enhancements and fixes with more than 1000 commits from 67 developers. Packages: * Debian Packages - https://deb.frrouting.org/ <https://deb.frrouting.org/> * RPM Packages - https://rpm.frrouting.org/ <https://rpm.frrouting.org/> * Snaps - https://snapcraft.io/frr <https://snapcraft.io/frr> * Docker - https://hub.docker.com/layers/frr/frrouting/frr/v8.3.0/images/sha256-4d1343… <https://hub.docker.com/layers/frr/frrouting/frr/v8.3.0/images/sha256-4d1343…> Major Highlights: * Notification Message support for BGP Graceful Restart (http://docs.frrouting.org/en/latest/bgp.html#clicmd-bgp-graceful-restart-no… <http://docs.frrouting.org/en/latest/bgp.html#clicmd-bgp-graceful-restart-no…>) * BGP Cease Notification Subcode For BFD * Send Hold Timer for BGP * RFC5424 syslog support (http://docs.frrouting.org/en/latest/extlog.html?#clicmd-destination-syslog-… <http://docs.frrouting.org/en/latest/extlog.html?#clicmd-destination-syslog-…>) * PIM passive command (http://docs.frrouting.org/en/latest/pim.html#clicmd-ip-pim-passive <http://docs.frrouting.org/en/latest/pim.html#clicmd-ip-pim-passive>) Breaking Change: * Require librtr >= 0.8.0 for BGP RPKI (available in FRR package repos above) Please see the release notes for the detailed changelog: * Github release: https://github.com/FRRouting/frr/releases/tag/frr-8.3 <https://github.com/FRRouting/frr/releases/tag/frr-8.3> * FRRouting website: https://frrouting.org/release/8.3 <https://frrouting.org/release/8.3> Thanks to all contributors! Cheers, The FRR Development Team!

1 0