- frog - lists.frrouting.org

Re: [FROG] Source specific Multicast Support on FRR PIM implementation
by Jonas Dibbie 20 Sep '18

20 Sep '18

Hi Donald, > on colo2: > int eth0 > no ip pim sm > ip pim sm I did these changes on colo2. Now i can see the mroute, but I'm still not receiving the MC Data. Are you using non-integrated configs? This sure looks like a bug I fixed the other day https://github.com/FRRouting/frr/commit/59752d4ea5fc500db2f659f85f2e8c68045… Yes, we have sperated configs per Daemon. Colo1 has been migrated from Quagga to FRR 5.0.1 Colo2 has been migrated from FRR 2.x to 5.0.1 greetings, Jonas

2 2

Source specific Multicast Support on FRR PIM implementation
by Jonas Dibbie 20 Sep '18

20 Sep '18

2 1

OpenFabric now included in FRR
by Christian Franke 17 Sep '18

17 Sep '18

All - I'm glad to announce the merging of OpenFabric (PR #2875 https://github.com/FRRouting/frr/pull/2875) into master. OpenFabric (https://tools.ietf.org/html/draft-white-openfabric-06) is one of the solutions provided for the currently ongoing effort in the IETF to develop routing protocols which cope well with densely connected topologies like spine-leaf and clos. For those topologies, established routing protocols often run into scaling issues because of large fan-out and the high degree of interconnection. OpenFabric is based on IS-IS. To improve the scaling properties, it uses a more optimized flooding algorithm which reduces the number of LSPs exchanged in the network to the minimum required to update all nodes. To to test FRR's implementation of OpenFabric, just build and run fabricd with a configuration as following: > ! > interface lo > ip address 100.0.1.1/32 > ip router openfabric 1 > ipv6 address 2001:db8:64::1:1/128 > ipv6 router openfabric 1 > openfabric passive > ! > interface eth0 > ip router openfabric 1 > ipv6 router openfabric 1 > ! > [...] > ! > interface ethX > ip router openfabric 1 > ipv6 router openfabric 1 > ! > router openfabric 1 > net 49.0001.0001.0001.00 > ! All Best, Chris

1 0

question from a noob at networking and routing
by o1bigtenor 04 Sep '18

04 Sep '18

Greetings I had occasion to experiment with canonical's lxd which forced me to use snapd. In the process of this education I found that canonical forced dialy upgrades/updates (not sure which is the correct term). In trying to tame this insistence of ET's on calling home I got to a solution, suggested on the snapd forum which seemed to work. The result was that every month (the new updating frequency) my system would shut itself down because I had refused to let it connect to the snapd and lxd mother ships. Your FRRouting, that I have just found, looks like quite interesting stuff but I'm seeing where installing from snapcraft is considered an option. As I have had quite some pain from snapcraft/snapd I am curious as to why something that forced daily upgrades/updates is being used to install software that 'just needs to work'? If this kind of question is considered 'not nice' I will apologize in advance but I still would like to understand the logic behind choosing this method of installation. Regards Dee

4 3

received-routes.. doesn't work?
by Mark Kamichoff 02 Sep '18

02 Sep '18

Hi - I'm running various 3.1-dev versions of FRR and noticed that the "show ip bgp nei <peer> received-routes" doesn't seem to work as expected on any of them. Here's an example of the relevant parts of the configuration: ! router bgp 395460 neighbor 169.254.169.254 remote-as 64515 neighbor 169.254.169.254 password <snip> neighbor 169.254.169.254 ebgp-multihop 2 address-family ipv4 unicast neighbor 169.254.169.254 soft-reconfiguration inbound neighbor 169.254.169.254 route-map DENY_ALL in neighbor 169.254.169.254 route-map DENY_ALL out exit-address-family ! route-map DENY_ALL deny 65535 ! orca# show ip bgp neighbors 169.254.169.254 routes orca# show ip bgp neighbors 169.254.169.254 received-routes BGP table version is 0, local router ID is 10.3.4.36 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path orca# >From tcpdump and other t-shooting I know that there is an IPv4 DFZ being received, but received-routes doesn't show any of the routes that should be in the adj-rib-in. Oddly, if I remove the inbound route-map I see expected prefixes using the "routes" /and/ "received-routes" command. If I put it back, the "received-routes" shows nothing once again. It would almost seem like soft-reconfiguration isn't really enabled, but received-routes should give me an error if it wasn't and the neighbor information confirms that it is: orca# show ip bgp neighbors 169.254.169.254 <snip> For address family: IPv4 Unicast Update group 5, subgroup 5 Packet Queue length 0 Inbound soft reconfiguration allowed <----- <snip> This isn't limited to the IPv4 AF, either. I've got IPv6 peers that echibit the same behavior. Have I found a bug or am I doing something wrong? I'm happy to file a bug report. More info., if it helps: orca# show version FRRouting 3.1-dev (). Copyright 1996-2005 Kunihiro Ishiguro, et al. configured with: '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libexecdir=${prefix}/lib/frr' '--disable-maintainer-mode' '--disable-dependency-tracking' '--enable-exampledir=/usr/share/doc/frr/examples/' '--localstatedir=/var/run/frr' '--sbindir=/usr/lib/frr' '--sysconfdir=/etc/frr' '--enable-ospfapi=yes' '--enable-vtysh=yes' '--enable-isisd=yes' '--enable-multipath=256' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' '--enable-werror' '--enable-gcc-rdynamic' '--with-libpam' '--enable-systemd=yes' '--enable-poll=yes' '--enable-cumulus=yes' '--enable-pimd=yes' '--enable-dependency-tracking' '--enable-bgp-vnc=no' 'build_alias=x86_64-linux-gnu' orca# (orca:20:08:PDT)% uname -a Linux orca 4.9.0-3-amd64 #1 SMP Debian 4.9.25-1 (2017-05-02) x86_64 GNU/Linux (the build is from August 26th) Thanks! - Mark -- Mark Kamichoff prox(a)prolixium.com https://www.prolixium.com/

1 1

A route-map scaling improvement that has just gone in.
by Donald Sharp 23 Aug '18

23 Aug '18

All - This morning, PR #2818 (https://github.com/FRRouting/frr/pulls/2818) was merged into the FRR master code base. This fixes Issue #2493(https://github.com/FRRouting/frr/issues/2493), where zebra was causing significant processing for route-map changes being made to the system in both BGP and Zebra. Here are some timings: Pre-route-map #2818 improvements for ZEBRA: ZEBRA: Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 12 22568.749 121924 185 160855 162 414190 RWTEX TOTAL BGP: Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 10 31159.647 121679 256 117558 220 117713 RWTEX TOTAL Create a Unused route-map: robot# conf t robot(config)# route-map BLAR permit 10 robot(config-route-map)# end ZEBRA: Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 12 40671.587 136545 297 214461 226 414190 RWTEX TOTAL BGP: Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 10 32043.610 122392 261 117558 227 117713 RWTEX TOTAL This is aproximately 19 cpu seconds split between BGP and zebra to handle a full BGP feed for a route-map change that no-process is currently using. After-route-map (#2818) improvements for ZEBRA: ZEBRA: Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 11 11592.894 1216075 9 152939 5 120621 RWTEX TOTAL BGP: Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 9 8306.451 40216 206 116589 193 116801 RWTEX TOTAL Create a Unused route-map: robot# conf t robot(config)# route-map BLAR permit 10 robot(config-route-map)# end Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 11 11596.799 1216183 9 152939 5 120621 RWTEX TOTAL Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 9 8320.976 40365 206 116589 193 116801 RWTEX TOTAL This adds up to negligible amounts of cpu time. This is a wonderful improvement in processing of route-map changes for zebra( and consequentially for bgp ). I'd like to thank Soman for doing this work. thanks! donald

1 0

OSPF Fast Convergence (RFC6976)?
by Timo Schöler 15 Aug '18

15 Aug '18

Hi all, I came across ``Framework for Loop-Free Convergence – Using the Ordered Forwarding Information Base (oFIB) Approach'' [0] which may be a phantastic remedy to a problem that occurs from time to time in a network I maintain: Even restarting a single OSPF process (on a group of about 20 routers in that area) causes trouble in forwarding/routing of 60.000+ TCP streams that traverse that area. (EIGRP is said to be immune against that because of explicit termination of the diffusing computations.) AFAICS it's not implemented yet in any free routing suite – are there any plans of doing so (in FRR)? Best regards, Timo [0] – https://tools.ietf.org/html/rfc6976

3 3

BFD daemon is now part of master
by Rafael Zalamena 14 Aug '18

14 Aug '18

Hi all, Today the BFD daemon (`bfdd`) got merged into master. It implements the Bidirectional Forwarding Detection protocol and its main purpose is to detect link failures to notify services. The daemon is automatically built on standard distribution on all platforms. Currently the following FRR daemons support BFD: * bgpd; * ospfd; * ospf6d; * pimd; --- Background: The BFD daemon was implemented re-using some Cumulus implementation, but it was extracted from another service ( https://github.com/CumulusNetworks/ptm/blob/master/src/ptm_bfd.c ). The code went through the following changes: * it became a stand alone daemon; * added new configuration interfaces: vtysh and control socket (using JSON); * replaced uthash.h with FRR's hash implementation; * added compatibility code to run on *BSDs; * changed event manager with FRR's; * minor code/protocol fixes; Related RFCs: * RFC 5880 (protocol description); * RFC 5881 (single hop IPv4/IPv6 implementation); * RFC 5883 (multi hop implementation); --- For those who want to try out, here is the BFD manual: http://docs.frrouting.org/en/latest/bfd.html Thanks to everyone that helped reviewing and testing the code! Rafael

1 0

FRR not starting at boot - Debian testing (10)
by Brandon Applegate 11 Aug '18

11 Aug '18

So yes - I know I’ve done this to myself to some extent by running a “testing” OS. But hear me out… I’m cloning these boxes in vmware and configuring with ansible. So they are very consistent. FRR is 5.0.1. On one configuration - FRR starts as expected. On another box - FRR will not start automatically. There’s nothing in logs - it doesn’t even seem like it tries. But if I log in and manually “sudo systemctl restart frr” it comes right up. I don’t claim to be a systemd expert - but I did play around a bit in the unit file trying to add an ExecStartPre with a sleep - no dice. I also thought it might similar to: https://github.com/FRRouting/frr/issues/1340 However, I see that watchfrr gets ran anyway (I don’t have this in the daemons file). That’s fine, but it doesn’t jive with the issue 1340 above. So I don’t think that’s my issue at play here. I can tell you the main difference in the two boxes (working vs. not) is the frr config itself (daemons are the same) and IP addresses/interfaces. On the working box I have about 30 lines of frr.conf. I have maybe ~10 total ips, split between ipv4/6. frr.conf is ospf and ospfv6. On the boxes where it won’t start at boot - I have about 60 lines of FRR conf. I have about 20 total ips, split between ip4/6. About 20 BGP peers (again split between ipv4/ipv6 - so 10 each). Anyone have any idea what I can look at next ? I can put some ansible in to log back into the problem boxes and manually start frr - but that’s a hacky and cheap method. I’d rather understand what’s going on and fix it properly. Thanks. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible."

2 1

Issues with EVPN Type-5 Routes
by Mohan Singamsetty 11 Aug '18

11 Aug '18

Hi all, I have simple two node setup with below configuration on each node. I am trying to verify functionality related to EVPN Type-5 routes and observing few issues as listed below. Node A ------------------ Node B Most of the configuration is from source: https://docs.cumulusnetworks.com/display/DOCS/Ethernet+Virtual+Private+Netw… Node A router bgp 65000 bgp router-id 203.0.113.1 no bgp default ipv4-unicast neighbor fabric peer-group neighbor fabric remote-as 65001 neighbor fabric capability extended-nexthop neighbor 203.0.113.2 peer-group fabric ! address-family ipv4 unicast network 44.44.44.0/24 exit-address-family ! address-family l2vpn evpn neighbor fabric activate advertise-all-vni advertise ipv4 unicast exit-address-family ! router bgp 65000 vrf Sri bgp router-id 203.0.113.1 ! address-family ipv4 unicast network 45.45.45.0/24 exit-address-family ! address-family l2vpn evpn advertise-all-vni advertise ipv4 unicast exit-address-family ! line vty ! Node B router bgp 65001 bgp router-id 203.0.113.2 no bgp default ipv4-unicast neighbor fabric peer-group neighbor fabric remote-as 65000 neighbor fabric capability extended-nexthop neighbor 203.0.113.1 peer-group fabric ! address-family ipv4 unicast network 54.54.54.0/24 exit-address-family ! address-family l2vpn evpn neighbor fabric activate advertise-all-vni advertise ipv4 unicast exit-address-family ! router bgp 65001 vrf Sri bgp router-id 203.0.113.2 ! address-family ipv4 unicast network 55.55.55.0/24 exit-address-family ! address-family l2vpn evpn advertise-all-vni advertise ipv4 unicast exit-address-family ! line vty ! * When I had this configuration in frr.conf and rebooted both the nodes, no Type-5 routes were advertised and the only routes I see are Type-3 and Type-2 routes and the output is as below. Node_A# show bgp evpn route BGP table version is 2, local router ID is 203.0.113.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 203.0.113.1:3 *> [2]:[0]:[48]:[00:50:56:b5:b4:53] 203.0.113.1 32768 i *> [3]:[0]:[32]:[203.0.113.1] 203.0.113.1 32768 i Route Distinguisher: 203.0.113.1:4 *> [3]:[0]:[32]:[203.0.113.1] 203.0.113.1 32768 i Route Distinguisher: 203.0.113.2:3 *> [3]:[0]:[32]:[203.0.113.2] 203.0.113.2 0 65001 i Route Distinguisher: 203.0.113.2:4 *> [3]:[0]:[32]:[203.0.113.2] 203.0.113.2 0 65001 i Displayed 5 prefixes (5 paths) dev# I remember about an issue that was discussed by Donald and others earlier, where VRF configuration sequence does matter for Type-5 Routes. The mail thread that talks about this issue is @ https://lists.frrouting.org/pipermail/frog/2018-July/000205.html * So I removed the bgp configuration from both the nodes as below Node_A# conf t Node_A (config)# no router bgp 65000 Node_A (config)# no router bgp 65000 vrf Sri Node_A (config)# Node_B# conf t Node_B (config)# no router bgp 65001 Node_B (config)# no router bgp 65001 vrf Sri Node_B (config)# * Configured bgp and associated VRF again on the two nodes (vrf Sri configuration was not removed so honoring the sequence requirements from the above thread). After this the bgp evpn routes on each node are as below. Node A Node_A# show bgp evpn route BGP table version is 1, local router ID is 203.0.113.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 203.0.113.1:5 *> [5]:[0]:[24]:[45.45.45.0] 0.0.0.0 0 32768 i Displayed 1 prefixes (1 paths) Node B Node_B# show bgp evpn route BGP table version is 1, local router ID is 203.0.113.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 203.0.113.1:5 *> [5]:[0]:[24]:[45.45.45.0] 203.0.113.1 0 0 65000 i Displayed 1 prefixes (1 paths) EdgeRouter-2# Some of the observations: 1. When the two nodes were brought for the first time, no Type-5 routes were advertised initially. Only Type-3 and Type-2. 2. Once I unconfigure BGP and configure again, neither Type-3 nor Type-2 routes were showing up. 3. After this, It looks like Node-A is advertising Type-5 route for one of the prefix that was added through network command and this indeed received by Node-B. But this is not happening from Node B to Node A. 4. IP-Prefix from VRF Sri was advertised by Node A, but this is not happening for the IP-Prefix that was available at global level. I am trying to understand the reason for above behavior. Can you help me to identify if I am missing anything in configuration ? If not what am I missing here ? Unfortunately, not many log messages were available in this part of the code and I am trying to add more and debug, but any quick help on this would be really useful. This is latest FRR (may be a month old). I do have the log files for both the nodes with all necessary BGP debugs enabled. Let me know if you need any more details on this. Thanks, Mohan

1 0