- frog - lists.frrouting.org

How to test ipv6 anycast address with frr routing?
by yanhc519＠aliyun.com 27 Feb '21

27 Feb '21

Hi, all. I want to test ipv6 anycast address with frr routing with several linux PC host. However, I cannot find a way to setup ipv6 address on my linux host which is Ubuntu 12.04. I also cannot find a way to config ipv6 address on frr routing suite. So does linux support ipv6 anycast address? Or does frr routing support ipv6 anycast address configuration? How could I test ipv6 anycast address with frr routing? Is there a tutorial about this? Thanks. York

1 0

No RIP packets, rejecting distribute-list and redistribute
by jimc 26 Feb '21

26 Feb '21

Version: frr-7.5-3.3.x86_64 from OpenSuSE Tubleweed. This is probably a near duplicate of bug 1279 (2017-10-02) https://github.com/FRRouting/frr/issues/1279 except the OP omidit was trying to use BGP while I have RIP[ng]. I'm pointing the finger of blame at a documentation issue; in other words, almost certainly my frr.conf file (appended with comments) lacks some prerequisite which would resurrect the redistribute and distribute-list commands. Presenting symptoms: ripd and ripngd never emit any RIP[ng] packets, even though the sub-router has a route to the subnet that I want the local LAN to be able to reach. Plus: when I specify "redistribute" and "distribute-list", frr -C complains: ``` line 56: % Unknown command[4]: distribute-list xenanet in line 57: % Unknown command[4]: distribute-list xenanet out line 61: % Unknown command[4]: redistribute kernel line 63: % Unknown command[4]: redistribute static line 65: % Unknown command[4]: redistribute connected ``` Back in 1987 I could just start rpc.ripd on SunOS-3 (no authentication in RIPv1), but 34 years later, Quagga looked like it gave a lot of people a lot of trouble to configure it, so I thought to reinvent the wheel. But for political and national security reasons I think it would be a real good idea to have open source routing used more widely, and so I decided to give Quagga my best try. It succumbed to the same issue complained about here, attributed to an unfixed bug by many OP's, and I dug through the source code but was not able to find the "bug". But I also hit references to FRR and tried it in the hope of a fix. No such luck. Currently I'm guessing that the problem is not in the code but in the documentation, so I've missed some important setup aspect. I'm planning to write up my experiences and of course it will include the conf file. In the appended instance I've retained comments, and if you spot any misconceptions among them I would appreciate corrections, so errors don't propagate. ``` # /etc/frr/frr.conf # This file contains plaintext passwords and needs permission 640 frr:frr # Revision history: # 2021-02-17 jimc Becomes FRR (Free Range Routing) unified config file. # 2021-02-04 jimc Initial setup for Quagga / rip[ng]d, abandoned. # hostname itsname # Default is the system's 1-component name per uname -n. # Without a password, vtysh will not connect; the enable password enables # interactive reconfiguration. But it uses PAM; password not needed for root. # Warning, security is not robust; turn this off in production. password redacted#1 enable password redacted#2 # Log file for all daemons log file /var/log/frr/frr.log # /etc/frr/daemons controls which protocol daemons to start, but you also have # to enable them. Not needed for staticd or zebra. router rip #rejected: version 2 # Do not receive v1 (which can't do authentication) router ripng # "vtysh -C [-f other_file.conf]" will check the configuration file; default # is /etc/frr/frr.conf. It would appear that if no protocol is enabled (e.g. # by "router rip") for which a particular command (e.g. "network") is relevant, # the command is reported as "Unknown command[4]: network 192.9.200.0/24", not # considering the parameters (e.g. with "router ripng", the IPv4 version is # not unknown). # Interfaces with an IP address in this range may send and receive protocol # packets. You can also enable named interfaces e.g. en0. network 192.9.200.0/24 network 2600:3c01:e000:306::/64 # We're only going to include these subnet(s) in incoming + outgoing packets. # In Quagga you could also use an access-list. ip prefix-list xenanet permit 192.9.200.176/29 ip prefix-list xenanet deny any # Syntax: 'route-map' its_name permit|deny line_number; matches etc. follow. # A number is a valid identifier and you confusingly see this in tutorials. route-map cnmap permit 1 match ip address prefix-list xenanet route-map cnmap deny 2 # Zebra can filter incoming routes per protocol or for any protocol. It just # ignores non-permitted routes. Looks like the default is to deny everything. ip protocol any route-map cnmap # In incoming and outgoing packets, only the specified subnets are included. distribute-list xenanet in distribute-list xenanet out # Daemons send routes that they learned from these sources. # kernel = set in system routing table by non-FRR, e.g. "ip route add..." redistribute kernel # static = configured in a FRR conf file. (CouchNet has none.) redistribute static # connected = seen in protocol packets from neighboring routers. redistribute connected # Turn on authentication (RIP v2 only). Mode md5 (hiss, boo!) makes a HMAC # over the packet with a pre-shared key prepended; the sender and receiver must # use the same key. It's OK to turn on auth for interfaces that don't exist. key chain CouchNet key 1 key-string redacted#3 interface en0 ip rip authentication mode md5 ip rip authentication key-chain CouchNet interface br0 ip rip authentication mode md5 ip rip authentication key-chain CouchNet interface rad0 ip rip authentication mode md5 ip rip authentication key-chain CouchNet interface tun0 ip rip authentication mode md5 ip rip authentication key-chain CouchNet interface tun1 ip rip authentication mode md5 ip rip authentication key-chain CouchNet interface tun9 ip rip authentication mode md5 ip rip authentication key-chain CouchNet # Default timer values are used. # update 30sec, send a gratuitous RIP packet this often. # timeout 180sec, a route absent from "learn from" sources (e.g. # neighbors) for this long is redistributed as expired. # garbage 120sec, after this long, expired routes are no longer announced. ``` -- James F. Carter Email: jimc(a)jfcarter.net Web: http://www.math.ucla.edu/~jimc (q.v. for PGP key)

2 1

[dev] Regarding ospfv3 authentication
by jagadeesh N 18 Feb '21

18 Feb '21

Hi, <<Reposting this question again, there was conversation happened regarding this 2=3 years back, but i still see the change log showing support for RFC 4552 https://lists.frrouting.org/pipermail/dev/2017-September/000899.html >> Does FRR 3.0 support OSPFv3 authentication? Though OSPFv3 doesn't have an authentication header on its own similar to OSPFv2, it should use IPSec for authentication. Though github claims that it supports RFC 4552. Reference Link:https://github.com/FRRouting/frr/wiki/FRR-2.0-%E2%86%92-FRR-3.0-Change… But I couldn't see commands like "ipv6 ospf authentication .." etc., Do I miss something?Regards, Jagadeesh N

1 0

RFC: resolution over default route - should it be enabled by default?
by Quentin Young 10 Feb '21

10 Feb '21

Hi froggers, FRR developers would like operator feedback on this question. By default, Zebra will not resolve nexthops via a default route. To allow this, you have to put the following line in your configuration: ip nht resolve-via-default (https://docs.frrouting.org/en/latest/zebra.html#clicmd-ipnhtresolve-via-def…) This has various implications, but the one we see most often is that BGP won't peer over a default route. This has been at the root of quite a few issues filed over the years, enough that it might be worthwhile flipping the default. We want to hear from operators whether you think this is a good idea. Has the current behavior helped you? Hurt you? We want your feedback. Quentin

1 0

readline 8.1 and bracketed pasting in vtysh
by Mark Kamichoff 08 Feb '21

08 Feb '21

tl;dr readline 8.1 turns on bracketed paste and appears to break multi-line pasting in vtysh Hi - I noticed that on a few of my boxes I can no longer paste a set of commands into vtysh using either FRR 6.x or 7.x. The result was that the lines were treated as a single line and therefore rejected. For example, if I want to create a simple route-map like so: route-map foo permit 5 set as-path prepend 1 2 3 4 end Here's what happened when I first pasted the 3x lines: ====snip==== excalibur(config)# route-map foo permit 5 set as-path prepend 1 2 3 4 end ====snip==== (the pasted text is highlighted in the terminal) After hitting enter vtysh rejects the command because it sees it as a single line (I think): ====snip==== % Unknown command: route-map foo permit 5 set as-path prepend 1 2 3 4 end excalibur(config)# ====snip==== The expected result should look something like this (I manually typed it in): ====snip==== excalibur(config)# route-map foo permit 5 excalibur(config-route-map)# set as-path prepend 1 2 3 4 excalibur(config-route-map)# end excalibur# ====snip==== I dug a little deeper and it looks like this is a result of bracketed paste[0] that has been enabled in the 8.1 release of GNU readline released in Dec of 2020[1]. I confirmed that an older system I have still running readline 8.0 does not have this issue. I think vtysh rejects the command because of the escape characters that are used with bracketed paste. I couldn't find any option to disable bracketed paste in readline itself or vtysh. Shells like Zsh and Bash have options for it in their config files. Does anyone know how to disable bracketed paste in vtysh? Or, is there something else funky going on here? I'm using rxvt-unicode on Linux/X11. I tested this with Terminal.app on Big Sur as well and got the same result. Thanks! - Mark [0] https://cirw.in/blog/bracketed-paste [1] https://lwn.net/Articles/839213/ (see h. in the CHANGES list) -- Mark Kamichoff prox(a)prolixium.com https://www.prolixium.com/

3 6

GRE support in FRR
by Amjad Ali 01 Feb '21

01 Feb '21

Hi, I am trying to test GRE and FRR and was looking for pointers on some use cases or documentation. I haven't found much in the documentation though. How much support is there for GRE and if someone could kindly provide a basic topo/test scenario to this effect? Thanks, Ali

2 1

NHRP multiple issues
by Volodymyr Litovka 29 Jan '21

29 Jan '21

Hi colleagues, I tried to implement NHRP using FRR 7.5 (Ubuntu 20) and facing so much issues, that I'm in doubts that NHRP is production-ready. Is it? My test topology is the following: + NHRP: 10.0.0.254 | +-----------+ | +------------+ | | | | | | HUB +-----+ | Spoke (S1) | | 10.9.8.53 | | | 10.9.8.241 | | | +------+ | +--+--------+ | +------------+ | | NHRP: 10.0.0.1 | + LAN: 10.2.1.241/24 | +---+-+ | | +-----+ | Routed | +---- network | | +-----+ +---+--+ | | +------+-----+ | | | Spoke (S2) | | 10.1.2.242 | | | +------------+ NHRP: 10.0.0.2 LAN: 10.2.2.242/24 At the moment, I'm trying to play without IPSec encryption (so no 'tunnel protection' on the gre interfaces) and configurations of nodes (HUB, S1; S2 is similar to S1) are: HUB (NBMA 10.9.8.53): nhrp nflog-group 1 ! ip route 10.0.0.0/24 Null0 ! interface gre1 description DMVPN Tunnel Interface ip address 10.0.0.254/32 ip nhrp map 10.0.0.1 10.9.8.241 ip nhrp map 10.0.0.2 10.1.2.242 ip nhrp network-id 1 ip nhrp redirect ip nhrp registration no-unique ip nhrp shortcut tunnel source eth1 ! router bgp 65000 bgp router-id 10.0.0.254 neighbor 10.0.0.1 remote-as 65000 neighbor 10.0.0.1 disable-connected-check neighbor 10.0.0.1 update-source 10.0.0.254 neighbor 10.0.0.2 remote-as 65000 neighbor 10.0.0.2 disable-connected-check neighbor 10.0.0.2 update-source 10.0.0.254 ! address-family ipv4 unicast network 10.0.0.0/24 redistribute nhrp neighbor 10.0.0.1 route-reflector-client neighbor 10.0.0.2 route-reflector-client exit-address-family S1 (NBMA 10.9.8.241): ip route 10.2.1.0/24 Null0 ! interface gre1 description DMVPN Tunnel Interface ip address 10.0.0.1/32 ip nhrp network-id 1 ip nhrp map 10.0.0.254 10.9.8.53 ip nhrp redirect ip nhrp registration no-unique ip nhrp shortcut tunnel source eth0 ! router bgp 65000 bgp router-id 10.0.0.1 no bgp ebgp-requires-policy neighbor 10.0.0.254 remote-as 65000 neighbor 10.0.0.254 disable-connected-check neighbor 10.0.0.254 update-source 10.0.0.1 ! address-family ipv4 unicast network 10.2.1.0/24 exit-address-family S2 is same as S1 except is has nbma address 10.1.2.242 and NHRP address is 10.0.0.2 On all hosts configuration of GRE intfs is same (except IP address): ip tunnel add gre1 mode gre key 42 ttl 64 ip addr add 10.0.0.xxx/32 dev gre1 ip link set gre1 up The issues are: - unlike all examples (incl. official), NHRP neighborhood is not established until I specify explicit mapping on Hub, using 'ip nhrp map ...' - though, if I do 'ip link set gre1 down' and then 'up', FRR loses 'ip nhrp map ...' config and, thus, loses connectivity - if, on spoke, I use instead 'ip nhrp nhs dynamic nbma 10.9.8.53' - it persists between interfaces down/up events, but, in fact, it never finds nhrp hub, keeping forever in the following state: s1# sh ip nhrp Iface Type Protocol NBMA Flags Identity gre1 local 10.0.0.1 - - - nevertheless, while using 'ip nhrp map' everywhere (incl. S2) and see established neighborship and BGP and, thus, LAN prefixes announces, I try to ping S1's LAN from S2: * before ping S2's RT shows the route: root@s2:~# ip route 10.2.1.0/24 nhid 32 via 10.0.0.254 dev gre1 proto bgp metric 20 onlink first two ping go through hub and then, after it signals to build the direct tunnel, connectivity passes away: root@s2:~# ping 10.2.1.241 PING 10.2.1.241 (10.2.1.241) 56(84) bytes of data. 64 bytes from 10.2.1.241: icmp_seq=1 ttl=64 time=2.31 ms 64 bytes from 10.2.1.241: icmp_seq=2 ttl=64 time=1.10 ms From 10.0.0.2 icmp_seq=3 Destination Host Unreachable From 10.0.0.2 icmp_seq=4 Destination Host Unreachable ^C but S2's RT is expanded with new entry (10.2.1.241): root@s2:~# ip route 10.2.1.0/24 nhid 38 via 10.0.0.1 dev gre1 proto bgp metric 20 onlink 10.2.1.241 nhid 29 dev gre1 proto nhrp metric 20 Questions are: 1) whether it's possible to keep as less as possible configuration on the Hub, avoiding direct mapping for every spoke? (here in tests I used BGP, but want to move to OSPF and get rid of any pre-spoke configuration on hubs) 2) disappearing of 'ip nhrp map' during interface up/down - whether it is bug or feature? If latter - what is rationale behind this? 3) 'ip nhrp nhs dynamic' do not establish NHRP neighborhood - what I'm doing wrong? 4) peer unreachability after NHRP redirect - is it case for 'tunnel protection' or another issue? Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

2 1

ospfd: duplicate configuration shown when multiple instances of ospf running
by Amol Lad 25 Jan '21

25 Jan '21

Hi, 1. I'm testing this in FRR master. 2. /etc/frr/frr.conf is deleted so per daemon configuration file can be used 3. enabled ospfd_instances=2,3,4,5 in /etc/frr/daemons ospfd=yes ospfd_instances=2,3,4,5 Now, do "no router instance-id" for all instances and then "router ospf" and add below statements: ospf router-id 1.1.1.1 network 20.20.20.0/24 area 0 Please notice that configuration is "replicated" and if I save the configuration then above conf is written to all conf files. Please advise === amol@amol-Virtual-Machine:~/frr$ sudo vtysh % Can't open configuration file /etc/frr/vtysh.conf due to 'No such file or directory'. Hello, this is FRRouting (version 7.6-dev-MyOwnFRRVersion-g82b844d8d). Copyright 1996-2005 Kunihiro Ishiguro, et al. This is a git build of frr-7.4-dev-1400-g82b844d8d Associated branch(es): local:master github/FRRouting/frr.git/master amol-Virtual-Machine# sh run Building configuration... Current configuration: ! frr version 7.6-dev-MyOwnFRRVersion frr defaults traditional hostname amol-Virtual-Machine no ip forwarding no ipv6 forwarding ! router ospf 2 ! router ospf 3 ! router ospf 4 ! router ospf 5 ! line vty ! end amol-Virtual-Machine# conf term amol-Virtual-Machine(config)# no router ospf 2 amol-Virtual-Machine(config)# no router ospf 3 amol-Virtual-Machine(config)# no router ospf 4 amol-Virtual-Machine(config)# no router ospf 5 amol-Virtual-Machine(config)# router ospf amol-Virtual-Machine(config-router)# ospf router-id 1.1.1.1 amol-Virtual-Machine(config-router)# network 20.20.20.0/24 area 0 amol-Virtual-Machine(config-router)# do sh run Building configuration... Current configuration: ! frr version 7.6-dev-MyOwnFRRVersion frr defaults traditional hostname amol-Virtual-Machine no ip forwarding no ipv6 forwarding ! router ospf ospf router-id 1.1.1.1 network 20.20.20.0/24 area 0 ospf router-id 1.1.1.1 network 20.20.20.0/24 area 0 ospf router-id 1.1.1.1 network 20.20.20.0/24 area 0 ospf router-id 1.1.1.1 network 20.20.20.0/24 area 0 ! line vty ! end ====

1 0

IPV6 RA, RS, NS
by Amjad Ali 18 Jan '21

18 Jan '21

Hi All, So I'm looking at FRR for testing some IPV6 features, in the code I see the router advertisement part implemented but was wondering where is the NS and NA part implemented. If anyone can shed some light, thanks in advance. Ali

2 1

migration issues frr6 to frr7 on FreeBSD11
by mike tancsa 16 Jan '21

16 Jan '21

Ran into a strange issue when I upgraded frr6 to frr7 on a FreeBSD 11 box. We have a LOT of bgp peers terminated (650 -- not all established) with a routing table less than 500 prefixes. Everything was working just fine on 6, but upgrading to 7, bgp would sig6 a few min after startup. Not much in the logs. Jan 16 12:25:33 kit-b zebra[88629]: [EC 4043309122] Client 'bgp' encountered an error and is shutting down. Jan 16 12:25:33 kit-b zebra[88629]: [EC 4043309122] Client 'vnc' encountered an error and is shutting down. Jan 16 12:25:33 kit-b zebra[88629]: release_daemon_table_chunks: Released 0 table chunks Jan 16 12:25:33 kit-b zebra[88629]: zebra/zebra_ptm.c:1348 failed to find process pid registration Jan 16 12:25:33 kit-b zebra[88629]: client 11 disconnected 66 bgp routes removed from the rib Jan 16 12:25:33 kit-b zebra[88629]: release_daemon_table_chunks: Released 0 table chunks Jan 16 12:25:33 kit-b zebra[88629]: client 24 disconnected 0 vnc routes removed from the rib Jan 16 12:25:33 kit-b zebra[88629]: [EC 100663303] kernel_rtm: 0.0.0.0/0: rtm_write() unexpectedly returned -4 for command RTM_DELETE It would also generate a lot of kernel messages while the daemon was running such as Jan 16 16:00:59 kit-b kernel: sonewconn: pcb 0xfffff801e65123a0: Listen queue overflow: 193 already in queue awaiting acceptance (622 occurrences) Jan 16 16:01:59 kit-b kernel: sonewconn: pcb 0xfffff801e65123a0: Listen queue overflow: 193 already in queue awaiting acceptance (557 occurrences) Jan 16 16:02:59 kit-b kernel: sonewconn: pcb 0xfffff801e65123a0: Listen queue overflow: 193 already in queue awaiting acceptance (622 occurrences) Jan 16 16:03:59 kit-b kernel: sonewconn: pcb 0xfffff801e65123a0: Listen queue overflow: 193 already in queue awaiting acceptance (556 occurrences) that are not generated when running frr6. The problem version was built from the ports. 7.5_1. The only I option I used was build vtysh. In case it was some memory issue, I tried a version with tcmalloc, however it was failing as well. We use frr7 elsewhere with a lot less peers and all works just fine, but those are on RELENG_12. As this is a production box, I cant do much experimenting on it. Not sure how to recreate in the lab easily. Do these problems ring a bell with anyone ? the box is pretty quiet. There are no memory nor CPU pressures on it. It doesnt seem to be a "thundering herd" problem as I tried shutting half the peers at startup to no avail. ---Mike

1 0