- frog - lists.frrouting.org

ipv6 nd managed-config-flag ignored?
by Thomas Pircher 17 Nov '20

17 Nov '20

Hi, I'm using frr version 4.0+cl3u17 on a Cumulus router. I'm having troubles setting the managed-config-flag for RA packets. I have this in my configuration file for the VLAN interface I'd like to configure with the managed-config-flag on: | interface vlan124 | vrrp 3 | vrrp 3 ipv6 fd00:4d56:414c:6000::1 | vrrp 3 priority 150 | ipv6 nd managed-config-flag But when I sniff the outgoing packets on the interface, I get "Flags [none]" in tcpdump: | # tcpdump -lnn -i vlan124 -vvvv -ttt icmp6 and 'ip6[40] = 134' | tcpdump: listening on vlan124, link-type EN10MB (Ethernet), capture size 262144 bytes | 00:00:00.000000 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::c981:f4f7:7f26:a79b > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 24 | hop limit 64, Flags [none], pref medium, router lifetime 48s, reachable time 0ms, retrans timer 0ms | source link-address option (1), length 8 (1): 00:00:5e:00:02:03 | 0x0000: 0000 5e00 0203 Is there something I'm doing wrong? Any help is appreciated. Thanks, Thomas

1 0

Announcing the 7.5 release of FRR
by Donald Sharp 16 Nov '20

16 Nov '20

All - I'd like to announce the 7.5 release of FRR! Debian Packaging - https://deb.frrouting.org/ Snap Packaging - https://snapcraft.io/frr RPM Packaging - https://rpm.frrouting.org/ Github Release - FreeBSd Packaging - Are built and available in FreeBSD packages/port BFD Profile support Minimum ttl support BGP rpki VRF support GR fixes Add wide option to display of routes Add `maximum-prefix <num> force` Add `bestpath-routes` to neighbor command Add `bgp shutdown message MSG...` command Add v6 Flowspec support Add `neighbor <neigh> shutdown rtt` command Allow update-delay to be applied globaly EVPN Beginning of MultiHoming Support ISIS Segment Routing Support VRF Support Guard against adj timer display overflow Add support for Anycast-SIDs OSPF Segment Routing support for ECMP Various LSA fixes Prevent crash if transferring config amongst instances PBR Adding json support to commands DSCP/ECN based PBR Matching PIM Add more json support to commands Fix missing mesh-group commands MSDP SA forwarding Clear (s,g,rpt) ifchannel on (*, G) prune received Fix igmp querier election and IP address mapping Crash fix when RP is removed STATIC Northbound Support YANG Filter and route-map Support OSPF model definition BGP model definition VTYSH Fix build-time errors for some --enable flags Speed up output of configuration across daemons ZEBRA nexthop group support for FPM northbound support for rib model Backup nexthop support netlink batching support Allow upper level protocols to request ARP Add json output for zebra ES, ES-EVI and access vlan dumps Upgrade to using libyang1.0.184 RPM Moved RPKI to subpackage Added SNMP subpackage Centos 6 and Debian Jessie have been deprecated As always there are too many bugfixes to list individually. This release compromises just over 1k of commits by the community, with contributors from 70 people. thanks! Donald

2 2

What causes a prefix received from a downstream to be "invalid"?
by Michael Hohl 09 Nov '20

09 Nov '20

Hello FRRouting community, I've tried to add an IPv6-only downstream to my dual-stack FRRouting-powered BGP setup, but for some reason the prefix of that downstream wasn't distributed to my upstream ISP. So, I consulted `show bgp summary` and spotted that this is the only route which isn't marked as `valid` indicated by a `*`. RPKI isn't enabled, otherwise I would have immediately suspected that to cause some prefix to be invalid. The only thing that makes this downstream different is that it is IPv6-only. What does it mean that a (received) prefix is considered "invalid"? Here is the output for `show bgp 2001:XX:YY::`: ``` BGP routing table entry for 2001:XX:YY::/48 Paths: (1 available, no best path) Not advertised to any peer ZZZZZZ 2a0d:f300:0:VVVV::1 (inaccessible) from 2a0d:f300:0:VVVV::1 (193.219.VV.VV) Origin IGP, invalid, external Last update: Mon Nov 9 09:00:00 2020 ``` ZZZZZZ ... is the downstreams ASN 2001:XX:YY:: ... is the IPv6 prefix the downstream wants to announce 2a0d:f300:0:VVVV::1 ... is the IPv6 address used to run the BGP router of the downstream 193.219.VV.VV ... is the IPv4 address assigned by me to the downstream, but he doesn't really use that one In case the FRRouting version is relevant for this issue, I'm running 7.3.1. Thanks in advance for any help, Michael

3 2

OSPF and not redistributing ptp subnets
by Chriztoffer Hansen 31 Oct '20

31 Oct '20

On 31 Oct 2020 18:17, Philip Prindeville wrote: > Again, I see routing announcements for the /30 subnets in 10.0.0.0/24 going out As far as I see it, access lists are doing literal matching. docs.frrouting.org/en/stable-7.0/filter.html E.g. 10.0.0.0/30 != 10.0.0.0/24 Using access-list not-ptp deny 10.0.0.0/24 access-list not-ptp permit any Only 10.0.0.0/24 would be denied. Any prefixes larger or smaller will be permitted, matching the permit any statement coming after. > Is there a really good book (that’s recent!) about routing with Quagga/FRR, say version 7.0 or later? The current documentation is your best option. Including the examples. docs.frrouting.org (The official documentation is in no way all glorious 110 % perfect. But is your best starting point) Otherwise you are down to blog posts, mailing list threads, forum posts, GitHub issue threads, etc. (i.e. whatever else you can find) -- Best regards, Chriztoffer

2 1

OSPF and not redistributing ptp subnets
by Philip Prindeville 31 Oct '20

31 Oct '20

Hi. I’m wracking my brain trying to figure this one out. I’ve tried several examples online but none of them work. I’m using FRR 7.0 on CentOS 8 Stream. My box looks like this: hostname redfish1 GRE tunnel interface “tun-lakeland2” 10.0.0.30/30 (peer is .29, “lakeland2”) Bridge interface “br0” is 10.5.29.1/24. The subnet 10.0.0.28/30 is not meaningful to anyone other than my peer who is already directly connected to it, and hence doesn’t need to learn of it via OSPF. What I *do* want it learning is that I’m connected to 10.5.29.0/24 (and all packets sent to any 10.0.0.0/8 networks should be sourced with 10.5.29.1). This is a remote site in a spoke-and-hub topology (actually, there’s 2 hubs, but we won’t worry about that for now). My config first looks like: log file /var/log/ospfd.log debugging ! interface br0 ip ospf area 0.0.0.0 ! interface tun-lakeland2 ip ospf network point-to-point ! router ospf ospf router-id 10.5.29.1 passive-interface default no passive-interface tun-lakeland2 ! route-map set-source permit 10 set src 10.5.29.1 ! ip protocol ospf route-map set-source ! end Should be simple, but doesn’t work. Doesn’t even send announcements on tun-lakeland2. Or see its neighbor. So here’s my 2nd config: ! router ospf ospf router-id 10.5.29.1 redistribute connected redistribute kernel network 10.0.0.0/8 area 0.0.0.0 passive-interface default no passive-interface tun-lakeland2 area 0.0.0.0 range 10.0.0.0/24 not-advertise ! route-map set-source permit 10 set src 10.5.29.1 ! ip protocol ospf route-map set-source ! end Which also doesn’t work. It does peer, but it also announces the /30 networks inside of 10.0.0.0/24. Third config looks like: ! router ospf ospf router-id 10.5.29.1 network 10.0.0.0/8 area 0.0.0.0 passive-interface default no passive-interface tun-lakeland2 ! distribute-list not-ptp out connected distribute-list not-ptp out kernel ! access-list not-ptp deny 10.0.0.0/24 access-list not-ptp permit any ! end Again, I see routing announcements for the /30 subnets in 10.0.0.0/24 going out: 17:13:39.408645 IP (tos 0xc0, ttl 1, id 39681, offset 0, flags [none], proto OSPF (89), length 120) 10.0.0.30 > 224.0.0.5: OSPFv2, LS-Update, length 100 Router-ID 10.5.29.1, Backbone Area, Authentication Type: none (0), 1 LSA LSA #1 Advertising Router 10.5.29.1, seq 0x8000000d, age 1s, length 52 Router LSA (1), LSA-ID: 10.5.29.1 Options: [External] Router LSA Options: [none] Stub Network: 10.5.29.0, Mask: 255.255.255.0 topology default (0), metric 10 Stub Network: 10.0.0.24, Mask: 255.255.255.252 topology default (0), metric 10 Neighbor Router-ID: 10.5.2.1, Interface Address: 10.0.0.30 topology default (0), metric 10 Stub Network: 10.0.0.28, Mask: 255.255.255.252 topology default (0), metric 10 Which resembles what was happening with config #2 as well. Also, my peer (10.5.2.1/24 aka 10.0.0.29/30) is advertising a route that’s not in the 10.0.0.0/8 space, despite also having a similar “network” statement… How do I turn off distributing “external” routes into my area (it’s a routable address, indeed it’s to the subnet that his public interface is on, which ends up trying to draw my VPN [GRE] traffic to be routed over the 10.0.0.0/8 network with disastrous results). It’s a trivial setup, right? But I’ve been debugging it for hours. Is there a really good book (that’s recent!) about routing with Quagga/FRR, say version 7.0 or later? I’d really like to figure this out and move on to other stuff. Thanks, -Philip

1 0

Help about OSPF ECMP between quagga (CentOS7) and frr (CentOS8)
by Sun Guonian 29 Oct '20

29 Oct '20

Hello, After I upgraded one of server's OS from CentOS7 to CentOS8, the default routingsoftware changed to frr from quagga. I found that the OSPF ECMP didn't work againbetween the my two servers, one is CentOS7 with quagga, another is CentOS8 with frr. How to configure frr to make the "TOS 0 Metric" become value 10 ? Thanks in advanced ! Best Regards,SUN Guonian +-------------+ | router | +---+-----+---+192.168.8.158/28 | | 192.168.8.174/28 | |192.168.8.149/28 | | 192.168.8.166/28 +------------+--+ +---------------+ |xxx.xxx.xxx.xx1| |xxx.xxx.xxx.xx2| +---------------+ +---------------+ ===== ospfd# sh ip ospf database router adv-router 192.168.8.166 OSPF Router with ID (192.168.8.166) Router Link States (Area 0.0.0.0) LS age: 758 Options: 0x2 : *|-|-|-|-|-|E|- LS Flags: 0x3 Flags: 0x0 LS Type: router-LSA Link State ID: 192.168.8.166 Advertising Router: 192.168.8.166 LS Seq Number: 8000655c Checksum: 0xefc3 Length: 48 Number of Links: 2 Link connected to: a Transit Network (Link ID) Designated Router address: 192.168.8.174 (Link Data) Router Interface address: 192.168.8.166 Number of TOS metrics: 0 TOS 0 Metric: 100 Link connected to: Stub Network (Link ID) Net: xxx.xxx.xxx.xx1 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 0 router ospf ospf router-id 192.168.8.166 network 192.168.8.160/28 area 0.0.0.0 network xxx.xxx.xxx.xx1/32 area 0.0.0.0! ===== ospfd# sh ip ospf database router adv-router 192.168.8.149 OSPF Router with ID (192.168.8.148) Router Link States (Area 0.0.0.0) LS age: 302 Options: 0x2 : *|-|-|-|-|-|E|- LS Flags: 0x6 Flags: 0x0 LS Type: router-LSA Link State ID: 192.168.8.149 Advertising Router: 192.168.8.149 LS Seq Number: 8000178d Checksum: 0x4472 Length: 96 Number of Links: 6 Link connected to: a Transit Network (Link ID) Designated Router address: 192.168.8.158 (Link Data) Router Interface address: 192.168.8.149 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: Stub Network (Link ID) Net: xxx.xxx.xxx.xx2 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 10 router ospf ospf router-id 192.168.8.149 network 192.168.8.144/28 area 0.0.0.0 network xxx.xxx.xxx.xx2/32 area 0.0.0.0!

1 0

FRR Debian Packages
by Jafar Al-Gharaibeh 28 Oct '20

28 Oct '20

Dear All, Recently we have made changes to how we create and publish FRR deb packages. We have also moved the repository to new servers. We have had some issues with DNS and site certs during the transition in the last couple of days. We also introduced a new signing key which means you have to re-sync your keys following the instructions on [1]. Sorry for any inconvenience this may have caused. All of the issues related to this transition reported so far have been resolved. Please let me know if you still have issues. Regards, Jafar Al-Gharaibeh [1] https://deb.frrouting.org/

1 0

difference quagga/frr multiple IPv6 default routes
by Frank Kardel 22 Oct '20

22 Oct '20

I am just moving from Quagga 1.2.4 to FRR 7.4. I noticed that FRR differs in behavior in case of multiple IPv6 default routes with the interface line protocol being down. The quagga static route configuration is: ipv6 route ::/0 carp3 100 ipv6 route ::/0 <IPv6-PREFIX>::1 carp3 100 ipv6 route ::/0 <IPv6-PREFIX>:2::192 200 And with carp3 line protocol being down following route is selected and installed: S>* ::/0 [200/0] via <IPv6-PREFIX>:2::192, wm0 <=== quagga uses alternate route S ::/0 [100/0] is directly connected, carp3 inactive via <IPv6-PREFIX>::1, carp3 inactive <=== quagga detects inactive This is what I am expecting from the aboe configuration. Now FRR looks different in this regard. The FRR staticd configuration is: ip route 0.0.0.0/0 carp3 100 ip route 0.0.0.0/0 <IPv4-NET>.65 100 ip route 0.0.0.0/0 10.0.2.192 200 ipv6 route ::/0 carp3 100 ipv6 route ::/0 <IPv6-PREFIX>::1 carp3 100 ipv6 route ::/0 <IPv6-PREFIX>:2::192 200 And FRR slect following route: S ::/0 [200/0] via <IPv6-PREFIX>:2::192, wm0, weight 1, 00:01:01 <== frr does not use alternate route S>* ::/0 [100/0] is directly connected, carp3 inactive, weight 1, 00:01:01<=== here frr knows thet carp3 is inactive * via <IPv6-PREFIX>::1, carp3, weight 1, 00:01:01 <=== frr does not document/notice line protocol down. === also a route to <IPv6-PREFIX>::1 is installed === via the wm0 interface, not carp3 FRR on IPv4 the mechanism does seem to work like in quagga: S 0.0.0.0/0 [100/0] is directly connected, carp3 inactive, weight 1, 00:00:48 via <IPv4-NET>.65, carp3 inactive, weight 1, 00:00:48 <== inactive is noticed here S>* 0.0.0.0/0 [200/0] via 10.0.2.192, wm0, weight 1, 00:23:23 <== alternate route is selected This violates for me the principle of least astonishment. Multiple variants of the statics route configuration did not cause FRR to select the route with distance 200. Is this a bug or a feature? If it is a feature how would I have to configure staticd then? Best regards, Frank Kardel

1 1

Re: [FROG] Yocto Recipe for FRR
by Quang Anh Trần Đỗ 22 Oct '20

22 Oct '20

1 0

A study on community-triggered updates in BGP
by Thomas Krenc 21 Oct '20

21 Oct '20

Dear FRRouting users and developers, As a team of researchers from NPS and TU Berlin, we are investigating the impact of BGP community attributes on the update behavior between ASes. We find that when a route is associated with multiple distinct community attributes it does not only lead to multiple announcement at the tagging AS, but also at neighboring ASes, if communities are not filtered properly. This behavior is wide-spread. In order to better understand our observations, we have performed a series of laboratory experiments using Cisco IOS, Junos OS, as well as the routing daemons BIRD and FRRouting. We find that - by default - all routers generate announcements with changing community attributes, even when other attributes do not change. In addition, when communities are filtered at egress, Cisco, BIRD and FRRouting send duplicate announcements (Juniper does not). Is this side-effect known to the FRRouting community and would you consider it a bug or a feature? Since our findings are limited to observations in public data as well as few router implementations, we would like to share our research and kindly ask you to have a look at: https://www.cmand.org/communityexploration/ There, we provide some resources documenting our research, as well as open questions. We greatly appreciate any feedback and insights you can offer. Also, please don't hesitate to contact us directly: communityexploration AT cmand DOT org best regards Thomas Krenc Postdoctoral Researcher Naval Postgraduate School

2 2