- frog - lists.frrouting.org

FRR Adding IPv6 Routes
by Tran (US), Katherine K 09 Apr '20

09 Apr '20

Hello, I am trying to switch from Quagga to FRR, but I am having issues adding distributed IPv6 routes. Although the IPv6 routes get added, they keep toggling between being added and removed. This did not occur while using Quagga. A difference between the added IPv6 routes of Quagga and FRR was that (1) the Quagga routes are by protocol zebra and (2) the FRR routes are by protocol 186, which I deduced to be bgpd. This can be seen by initiating the command "ip -6 ro sh". Quagga ---------- 2001:XXXX:X:X::/64 via fe80::1:2 dev eth0 proto zebra metric 1024 pref medium FRR ----- 2001:XXXX:X:X::/64 via fe80::1:2 dev eth0 proto 186 metric 20 pref medium I have a simple BGP configuration using Autonomous System Border Router (ASBR). I am running the daemons (zebra, staticd, bgpd) through the all-encompassing config file frr.conf, and I have also tried separating each daemon out to a separate config file and running them separately. I used the same commands from the Quagga confile files, and I added the additional staticd commands. I've looked at all the generated log files, and I can't seem to find anything substantial to investigation. Would anyone have an idea why these IPv6 routes keep toggling from being added and removed? Any additional suggestions on troubleshooting steps? Thank you, Katherine

5 13

IS-IS Complains When Loopback Interface is in Play
by Mark Tinka 09 Apr '20

09 Apr '20

Hi all. When I add my Loopback interface to isisd.conf and restart it, it throws the below: 2020/04/07 14:35:44 errors: ISIS: libyang: Missing required element "area-tag" in "isis". (/frr-interface:lib/interface[name='lo0'][vrf='default']/frr-isisd:isis) 2020/04/07 14:35:44 warnings: ISIS: [EC 100663337] nb_candidate_commit_prepare: failed to validate candidate configuration % Configuration failed: validation error. A bit of Googling indicated that "router isis 1" would need to come first in the configuration, since some previous versions of FRR processed the files line by line, and not atomically. But even after doing that, I still get the same error; but get this, ONLY when I add "interface lo0" to the configuration. Without that, and with just the physical interface in the configuration, IS-IS starts up fine. Any thoughts? System FRR 7.3 on FreeBSD-12.1. Thanks. Mark.

1 1

v6 Route Replace semantics
by Donald Sharp 08 Apr '20

08 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

IS-IS HMAC-MD5 Authentication Not Working
by Mark Tinka 08 Apr '20

08 Apr '20

Hi all. So I've been trying to get IS-IS to talk to a Cisco IOS XE box with HMAC-MD5 authentication, with no luck. I created an MD5 hash of the clear-text password, and also tried it with the clear-text password, and neither work. Cisco says the neighbor has the wrong password. There is an example for doing this with authentication at the bottom of http://docs.frrouting.org/en/latest/isisd.html , but the actual configuration example does not say anything about authentication. Thoughts? Mark.

4 6

Re: [FROG] IS-IS HMAC-MD5 Authentication Not Working
by Mark Tinka 08 Apr '20

08 Apr '20

On 8/Apr/20 00:21, Chriztoffer Hansen wrote: > Regarding documentation... Even the current FRR documentation is in > certain areas lacking (known issue). Any and all PR's for proving > improving the existing FRR documentation is welcomed by the developers > (to my knowledge of what I can remember) I am very happy to support the improvement in the documentation for IS-IS in FRR, as soon as I can get it to start working :-). At this stage, I am struggling to find out which combination of commands work, when, where and how. So having access to those who wrote the code might help, or anyone who's succeeded in doing this but is lurking somewhere. Mark.

1 0

Re: [FROG] Static route with BFD not supported?
by Soma Kelemen 02 Apr '20

02 Apr '20

Hi Tamas, As I see it is on the feature requests list https://github.com/FRRouting/frr/wiki/Feature-Requests and not implemented yet. Br, Soma On Fri, Apr 3, 2020 at 12:09 AM Tamás Kelemen via frog < frog(a)lists.frrouting.org> wrote: > > > > ---------- Forwarded message ---------- > From: "Tamás Kelemen" <tamas.kelemen(a)ericsson.com> > To: "frog(a)lists.frrouting.org" <frog(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 20 Mar 2020 12:31:53 +0000 > Subject: Static route with BFD not supported? > > Hi > > > > Is it possible to disable static routes if BFD session is down to the > gateway address? > > > > Thanks in advice > > > > BR, > > Tamas > > > > ---------- Forwarded message ---------- > From: "Tamás Kelemen via frog" <frog(a)lists.frrouting.org> > To: "frog(a)lists.frrouting.org" <frog(a)lists.frrouting.org> > Cc: > Bcc: > Date: Thu, 02 Apr 2020 15:09:09 -0700 (PDT) > Subject: [FROG] Static route with BFD not supported? > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog >

1 0

FRR BGP Route Server Issues/Questions
by Michael Lambert 28 Mar '20

28 Mar '20

We're running quagga (currently the Euro-IX fork, to be specific) as a route server. I was hoping to be able to use FRR as a more-or-less drop-in replacement. However, I've come up with some oddities which make me question whether route server functionality is still supported under FRR's bgpd. It appears that neighbor <...> route-map <...> (import | export) has disappeared from the CLI. I couldn't find anything obvious about this from either the git logs or the mailing list archive (but I have not done a bisection to figure out where they disappeared). Are import <=> in and export <=> out the new mapping? Or is it reversed? There was always something not quite intuitive about import/export. The documentation still refers to import/export, by the way. I've setup a (virtual) lab environment with FRR's bgpd running under FreeBSD 12.1 and three BGP speakers running OpenBGPd under OpenBSD 6.6. When configuring FRR's bgpd with neighbor <...> route-server-client the OpenBGPd speakers hear the expected routes from the route server, but with the route server itself as the next-hop. If I include neighbor <...> attribute-unchanged next-hop the next-hop is correctly propagated, but its presence would, on the surface, seem to make specifying "route-server-client" syntactic fluff. I also see that the show bgp [view <name>] (ipv4|ipv6) (unicast|multicast) rsclient <...> commands have disappeared, so the "obvious" way of checking route server functionality from within bgpd has, at best, changed. Assuming that the intent is to continue to support route server functionality within FRR, I have a couple of questions. Is my approach of specifying route-server-client/attribute-unchanged correct or am I missing something that makes FRR's bgpd work like quagga's bgpd? And are there plans to update the route server documentation to match the current implementation? We've been using bgpd for many years; I'd like to continue doing so with a non-orphaned version. Thanks, Michael -- Michael H Lambert, GigaPoP Manager Phone: +1 412 268-4960 Pittsburgh Supercomputing Center/3ROX FAX: +1 412 268-5832 300 S Craig St, Pittsburgh, PA 15213 USA lambert(a)psc.edu

2 3

How to import route and NOT withdraw existing route ?
by Simon Jones 24 Mar '20

24 Mar '20

Hi all, Now I need a feature, I have to import neighbor as vlink route into bgpd. So I use static route like this: > vtysh > ip route 1.1.1.1/32 Vlan100 > redistribute static route-map XXX But I encounter a problem: > before I add static route, there are B route like this: > B 2.2.2.100/32 [20/0] via 100.0.28.231, Ethernet52, src 1.1.1.230, > 3d03h18m > after I add static route, there are two route like this: > S>* 2.2.2.100/32 [1/0] is directly connected, Vlan100 > B 2.2.2.100/32 [20/0] via 100.0.28.231, Ethernet52, src 1.1.1.230, > 3d03h18m > after I redistribute, there are only one route like this: > S>* 2.2.2.100/32 [1/0] is directly connected, Vlan100 But what I need is to keep two route. Because if there is only one route, I have to relearn B route after I delete static route, which will cause package loss in long time(like 20 second). For some producer like huawei, thay have 'import route' command, which will combine redistributed route and learned route, like this: https://support.huawei.com/enterprise/en/doc/EDOC1000178171/cc777bfe/config… So will FRR support this feature ? How to import route and NOT withdraw existing route ? ---- Simon Jones

1 1

bgpd as0 rfc7607 compliance
by Joe Maimon 23 Mar '20

23 Mar '20

Seems to be finding plenty of these AGGREGATOR attribute is BGP_AS_ZERO(0) However, rfc7607 specifies error handling as per rfc7606 which suggests most frequently the withdrawn treatment bgpd appears to instead proceed for ebgp peers and notify for ibgp sessions, I am curious as to how either of these are correct and would appreciate any advice on the matter. Frustratingly, I haven't figured out any good way to log which prefix update are triggering this. Best, Joe

1 1

ospf on nhrp interface routes are inactive
by Joe Maimon 22 Mar '20

22 Mar '20

Hey All, Thanks to the event manager working properly, NHRP spokes are up and running. kernel neighbor routes are installed and pinging is working. I have gotten ospf neighbors to come up by configuring the interface as non-broadcast, as nhrp multicast does not appear to be supported at this time. (There seems to be some difficulty there, debug shows lots of duplicates and neighbors take quite a while to transition into Full/DR-whatever state) However, all ospf routes are marked inactive. I have found that this is the case for so long as the NHRP routes (individually as /32) are installed. The workaround is to prevent those routes from being installed (I do this by returning a result=reject from the event handler), but clearly that is not right. Running 7.4 git clone local debian 10 packaged. Any assistance would be greatly appreciated. For example: O>* 10.7.255.8/32 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 10.7.255.14/32 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 10.10.11.32/32 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 10.34.34.0/30 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 10.99.255.9/32 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 38.32.100.169/32 [110/20] via 192.168.241.130, t67, 16:48:28 .....more.... debian67# sh ip route nhrp debian67# Now, I send result=accept to evmgr debian67(config)# int t67 debian67(config-if)# shutdown debian67(config-if)# no shutdown debian67(config-if)# end debian67# sh ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued route, r - rejected route K>* 0.0.0.0/0 [0/0] via 45.77.146.1, ens3, 17:00:22 C>* 45.77.146.0/23 is directly connected, ens3, 17:00:22 K>* 169.254.169.254/32 [0/0] via 45.77.146.1, ens3, 17:00:22 O 192.168.241.128/27 [110/500] is directly connected, t67, 00:01:56 C>* 192.168.241.128/27 is directly connected, t67, 00:01:56 N>* 192.168.241.130/32 [10/0] is directly connected, t67, 00:00:12 N>* 192.168.241.131/32 [10/0] is directly connected, t67, 00:00:01 N>* 192.168.241.132/32 [10/0] is directly connected, t67, 00:00:01 debian67# sh ip os ne Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL 216.222.156.3 1 Full/DR 1m49s 192.168.241.130 t67:192.168.241.129 0 0 0 209.54.134.5 1 Full/DROther 1m54s 192.168.241.131 t67:192.168.241.129 0 0 0 209.54.140.100 1 Full/DROther 1m59s 192.168.241.132 t67:192.168.241.129 0 0 0 debian67# sh ip route ospf Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued route, r - rejected route O 0.0.0.0/0 [110/100] via 192.168.241.130, t67 inactive, 00:00:47 O 10.7.255.8/32 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 O 10.7.255.14/32 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 O 10.10.11.32/32 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 O 10.34.34.0/30 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 O 10.99.255.9/32 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 ----more----

1 1