January 2020 - 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

Display in wrong order for prefix-list
by Sébastien 65 24 Apr '20

24 Apr '20

Hi, I note that the display of a prefix-list AND bgp as-path access-list is not in the correct order, the sequences are mixed and this is not easily readable ... ip prefix-list LIST1 seq 10 deny X ip prefix-list LIST1 seq 100 deny X ip prefix-list LIST1 seq 105 deny X ip prefix-list LIST1 seq 15 deny X ip prefix-list LIST1 seq 20 deny X ip prefix-list LIST1 seq 200 permit X ip prefix-list LIST1 seq 25 deny X ip prefix-list LIST1 seq 30 deny X ip prefix-list LIST1 seq 35 deny X ip prefix-list LIST1 seq 40 deny X ip prefix-list LIST1 seq 45 deny X ip prefix-list LIST1 seq 5 deny X How to display the sequences in the right order (10,15,20,25,...,100,105,200,...)? Thank you !

4 6

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

Dual Core Design
by Travis Garrison 28 Jan '20

28 Jan '20

Trying to make sure I have the design down. We have 2 cores and 2 upstream connections. We also have a cross connect to an IX off 1 core. What would be the best way to configure iBGP between the cores so that we would gain the benefit of the IX from both cores and concurrent/failover usage from both upstream providers. Both upstream providers are the same speed and we advertise our networks to both in a multihomed scenario. We may be adding a 3rd core/upstream provider in the future. Core1 connects to ISP1 (full table) and IX Core2 connects to ISP2 (full table) All edge routers have an iBGP connection to both core routers and receive default routes only. Debian 10 FRR 7.2 Thanks Travis

1 0

(no subject)
by conneyh＠fnetlink.com 16 Jan '20

16 Jan '20

Dear frr 请问你们支持ipsec vpn吗？黄刚 Conney 技术工程师/ Technical Engineer Mobile: +86-13141707468 E-mail: conneyh(a)fnetlink.com 座机：0769-23158369-8672 - - - - - - - - - - - - - - - - - - - - 如果您在使用中遇到任何技术上问题，可拔打以下电话，我们将竭诚为您服务：全国服务热线：400-622-8986 香港服务热线：(+852) 2180 7378 台湾服务热线：(+886) 2 7728 7450 地址：东莞市旗峰路190号城市花园商贸中心13楼1302室 Add: Rm 1302, 13/F, Dongguan City Garden Business Center，No.190 Qifeng Road, Dongguan, Guangdong 深圳｜北京｜上海｜广州｜东莞｜香港｜澳门｜台湾

1 0

VTYSH and BGP options
by Simon Attwell 16 Jan '20

16 Jan '20

Hi All, New install of FRR on a Debian box, doing BGP on a couple of interfaces in a VRF (netns based). All is good except most of the bgp neighbour options are missing in VTYSH (neighbor <peer> <option>). In particular the options for weight or as-prepent or as-path filtering are missing. Is there something obvious I'm missing? * Simon

3 4

IPv6 bgp not working properly
by Patrick Boutilier 11 Jan '20

11 Jan '20

Having troubles with IPv6 and bgp. Traffic comes back on the interface (eth4.431) connected to the bgp peer but traffic won't pass through the kernel to the interface the ping is coming from. Also I can see 4 extra ping replies with tcpdump. Works fine on old Quagga bgpd. Any ideas what could be going on? FRR 7.3-dev: # tcpdump -nn ip6 and host 2620:8b:8000:0:7064:ee:ab4c:621 and icmp6 -i eth4.431 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth4.431, link-type EN10MB (Ethernet), capture size 262144 bytes 09:25:04.058721 IP6 2620:8b:8000:0:7064:ee:ab4c:621 > 2607:f8b0:4020:804::200e: ICMP6, echo request, seq 52, length 64 09:25:04.073358 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 52, length 64 09:25:04.103068 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 52, length 64 09:25:04.132735 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 52, length 64 09:25:04.162433 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 52, length 64 09:25:04.192130 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 52, length 64 09:25:05.058671 IP6 2620:8b:8000:0:7064:ee:ab4c:621 > 2607:f8b0:4020:804::200e: ICMP6, echo request, seq 53, length 64 09:25:05.073322 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 53, length 64 09:25:05.103023 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 53, length 64 09:25:05.132822 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 53, length 64 09:25:05.162499 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 53, length 64 09:25:05.192275 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 53, length 64 09:25:06.058736 IP6 2620:8b:8000:0:7064:ee:ab4c:621 > 2607:f8b0:4020:804::200e: ICMP6, echo request, seq 54, length 64 09:25:06.073396 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 54, length 64 09:25:06.103114 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 54, length 64 09:25:06.132879 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 54, length 64 09:25:06.162550 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 54, length 64 09:25:06.192316 IP6 2607:f8b0:4020:804::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 54, length 64 Quagga: tcpdump -nn ip6 and host 2620:8b:8000:0:7064:ee:ab4c:621 and icmp6 -i eth4.431 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth4.431, link-type EN10MB (Ethernet), capture size 262144 bytes 09:29:19.261904 IP6 2620:8b:8000:0:7064:ee:ab4c:621 > 2607:f8b0:4020:805::200e: ICMP6, echo request, seq 12, length 64 09:29:19.276527 IP6 2607:f8b0:4020:805::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 12, length 64 09:29:20.262978 IP6 2620:8b:8000:0:7064:ee:ab4c:621 > 2607:f8b0:4020:805::200e: ICMP6, echo request, seq 13, length 64 09:29:20.277640 IP6 2607:f8b0:4020:805::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 13, length 64 09:29:21.265010 IP6 2620:8b:8000:0:7064:ee:ab4c:621 > 2607:f8b0:4020:805::200e: ICMP6, echo request, seq 14, length 64 09:29:21.279670 IP6 2607:f8b0:4020:805::200e > 2620:8b:8000:0:7064:ee:ab4c:621: ICMP6, echo reply, seq 14, length 64

3 5

Fwd: [PDB Announce] Call for volunteers for PeeringDB
by Chriztoffer Hansen 08 Jan '20

08 Jan '20

Fwd to FROG list, because I thought mayhaps (individual_count >= 1) might be interested... Best Regards, Chriztoffer ---------- Forwarded message --------- From: Stephen McManus <smcmanus(a)peeringdb.com> Date: Mon, 6 Jan 2020 at 22:10 Subject: [PDB Announce] Call for volunteers for PeeringDB To: <pdb-announce(a)lists.peeringdb.com> Hi all, We are looking for volunteers to serve on the PeeringDB Admin and Product Committees. The ideal volunteers are industry professionals who are passionate about improving PeeringDB, and ensuring it meets the needs of the community it supports. We are most interested in people who have significant free time to dedicate to these efforts (as much as 4 or more hours a week). Please don’t volunteer if you can’t commit the time! Admin Committee: • Review requests from community members • Authorize users to organizations and networks • Generally keep PeeringDB’s data trustworthy and correct Product Committee: • Review and prioritize requests for improvements to PeeringDB • Work with developers and community members to specify how to solve problems and implement improvements • Set vision for how PeeringDB can help the community in the future If you are interested in either of these roles, and have time you can commit, please let us know at stefan(a)peeringdb.com for the Admin Committee or smcmanus(a)peeringdb.com for the Product Committee. Please include a sentence or two about yourself, why you want to volunteer and how you think you can help. Thanks! -Steve _______________________________________________ Pdb-announce mailing list Pdb-announce(a)lists.peeringdb.com https://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce

1 0

Re: [FROG] loopback interfaces
by Sébastien 65 04 Jan '20

04 Jan '20

I use local interfaces in the file /etc/network/interfaces # The loopback network interface auto lo iface lo inet loopback # Dummy's auto dummy0 iface dummy0 inet manual iface dummy0 inet6 manual pre-up ip link add dummy0 type dummy auto dummy1 iface dummy1 inet manual iface dummy1 inet6 manual pre-up ip link add dummy1 type dummy On FRR I configure the inferface dummy0 like this : ! interface dummy0 description *** loopback0 *** ip address W.X.Y.Z/32 ipv6 nd suppress-ra ! The loopback (here the dummy) interfaces are used to mount my internal BGP sessions and access to the router from the WAN (public ip).

1 0

loopback interfaces
by Sébastien 65 03 Jan '20

03 Jan '20

Hello, With CISCO I use several interfaces called loopback. On FRR (DEBIAN) what do you recommend to use to reproduce CISCO loopback? We must remember to load the dummy module and modify the number of dummy (options dummy numdummies=4). Lo or dummy interface ?

2 1