- frog - lists.frrouting.org

Failed to start frr.service: Unit frr.service not found
by ian.2.oakley＠bt.com 09 Dec '19

09 Dec '19

Hi, I installed FRR on my Ubuntu virtual machine from source, hoping to use it with CORE for multicast routing with PIM. However, I haven't been able to manage even that; when I attempt to start the FRR service (sudo service frr start) I am given the error message in the subject (Failed to start frr.service: Unit frr.service not found.) This is despite me running the command in my /frr/tools directory where frr.service is located. Am I missing something here? Best regards, Ian Oakley

3 2

Installing learned routes in the kernel routing table
by Daniel Corbe 09 Dec '19

09 Dec '19

I apologize for asking a question which in all probability has a really obvious answer. I have a freshly installed FRR 7.2 from sources on Alpine Linux. The 'zebra' process is running as id=frr and I have a working BGP session. The issue is, it's not installing routes into the kernel routing table. Being that zebra and bgpd are running as the 'frr' user, I made sure zebra had cap_net_admin: # getcap zebra zebra = cap_net_admin+p My Running config: # show run Building configuration... Current configuration: ! frr version 7.2 frr defaults datacenter hostname aagico-alpine-mia no ipv6 forwarding ! router bgp 64225 neighbor vultr peer-group neighbor vultr remote-as 64515 neighbor vultr password xxx neighbor vultr ebgp-multihop 2 neighbor 169.254.169.254 peer-group vultr neighbor 2001:19f0:ffff::1 peer-group vultr ! line vty ! end /etc/frr/daemons: # cat /etc/frr/daemons zebra=yes bgpd=yes ospfd=no ospf6d=no ripd=no ripngd=no isisd=no pimd=no ldpd=no nhrpd=no eigrpd=no babeld=no sharpd=no staticd=yes pbrd=no bfdd=yes fabricd=no # # If this option is set the /etc/init.d/frr script automatically loads # the config via "vtysh -b" when the servers are started. # Check /etc/pam.d/frr if you intend to use "vtysh"! # vtysh_enable=yes zebra_options=" -s 90000000 --daemon -A 127.0.0.1" bgpd_options=" --daemon -A 127.0.0.1" ospfd_options=" --daemon -A 127.0.0.1" ospf6d_options=" --daemon -A ::1" ripd_options=" --daemon -A 127.0.0.1" ripngd_options=" --daemon -A ::1" isisd_options=" --daemon -A 127.0.0.1" pimd_options=" --daemon -A 127.0.0.1" ldpd_options=" --daemon -A 127.0.0.1" nhrpd_options=" --daemon -A 127.0.0.1" eigrpd_options=" --daemon -A 127.0.0.1" babeld_options=" --daemon -A 127.0.0.1" sharpd_options=" --daemon -A 127.0.0.1" staticd_options=" --daemon -A 127.0.0.1" pbrd_options=" --daemon -A 127.0.0.1" bfdd_options=" --daemon -A 127.0.0.1" fabricd_options=" --daemon -A 127.0.0.1" #MAX_FDS=1024 # The list of daemons to watch is automatically generated by the init script. #watchfrr_options="" # for debugging purposes, you can specify a "wrap" command to start instead # of starting the daemon directly, e.g. to use valgrind on ospfd: # ospfd_wrap="/usr/bin/valgrind" # or you can use "all_wrap" for all daemons, e.g. to use perf record: # all_wrap="/usr/bin/perf record --call-graph -" # the normal daemon command is added to this at the end.

2 1

vtysh -f "Unknown command"
by Volodymyr Litovka 04 Dec '19

04 Dec '19

Dear friends, probably, I'm missing something, but I'm not able to use "vtysh -f <filename>", while "vtysh -c" works perfectly: # vtysh -c "show daemons" zebra bgpd watchfrr staticd # cat inp.txt show daemons # vtysh -f inp.txt line 1: % Unknown command[4]: show daemons # echo "show daemons" | vtysh -f /dev/stdin line 1: % Unknown command[4]: show daemons FRR v7.2 under Ubuntu 18.04 I will appreciate any ideas on how to configure FRR using pre-generated configuration. Thank you! -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

2 4

DMVPN(nhrpd) status question
by Антон Жаровцев 20 Nov '19

20 Nov '19

Hello. According to nhrpd docs (http://docs.frrouting.org/en/latest/nhrpd.html) need to patches strongswan to work together with frr/nhrpd but this document has date 2017. Is it still need to apply thous patches on strongswan or fresh versions of FRR and strongswan will work together out of the box now ? B.t.w. 1 month ago I tried to set up nhrp network without ipsec but all traffic went through hubs. I did not try to use strongswan due to need to apply this patch (I don't like patched software on docker containers, it is hard to support it then)

3 4

FRR as Route-Reflector & Scaling stats
by Rakesh M 19 Nov '19

19 Nov '19

Hi FRRTeam, We want to Deploy and use FRR for Route reflection on a Dell Edge. Any one has expereience with it and can give insight into number of routes and scale that you used FRR to do Route Reflection -- Rakesh Madupu 2xJNCIE - SP/DC / CCIE-SP#47613 https://r2079.wordpress.com

4 6

Opensource routing @ ietf meetup -- Monday Lunch
by Lou Berger 18 Nov '19

18 Nov '19

Hi, We're continuing with the informal Open Source routing @ ietf meetup. Anyone interested in joining a "bring your own lunch" gathering of folks using/building open source routing code, please drop in to "Bras Basah" on *Monday* during lunch (noon). There is no agenda or slides. Please feel free to bring a topic that you'd like to discuss or just come and listen. Cheers, Lou

3 2

import vrf <vrf_name> vs route-map match source-vrf <vrf_name>
by Bing.S＠dell.com 15 Nov '19

15 Nov '19

Hi, Is there any difference between "import vrf <vrf_name>" and "match source-vrf <vrf_name>" For example route-map myMap permit 1 match ip address prefix-list p1 option1: having "match source-vrf" in the same myMap route-map myMap permit 1 match ip address prefix-list p1 match source-vrf Vrf_red for vrf_blue: address-familiy ipv4 unicast route-map vpn import myMap rt vpn import 1111:11 import vpn option2: do not have "match source-vrf" in the myMap route-map myMap permit 1 match ip address prefix-list p1 for vrf_blue: address-family ipv4 unicast import vrf route-map myMap import vrf Vrf_red What is the difference in terms of routes filtering between the 2 options? Thanks, Bing

2 2

route distinguisher configuration on FRR bgp
by Bing.S＠dell.com 08 Nov '19

08 Nov '19

Hi, Looks like the same route distinguisher can be configured on multiple VRFs in FRR. Would this cause problem? Thanks.

3 2

FRR on Juniper switches
by Rudy Rucker 30 Oct '19

30 Oct '19

Is anyone running FRR on Juniper switches? I read this article, but it looks more like an R&D setup. https://forums.juniper.net/t5/Industry-Solutions-and-Trends/FRRouting-on-Ju… Rudy

1 0

Routes learned from iBGP are not maintaining Metrics when advertised to eBGP peers
by Lee Clements 23 Oct '19

23 Oct '19

Doing some testing on FRR here, and hoping for some assistance. Hopefully this is the right place to go. If not, please let me know! I've got 3 remote iBGP peers that are configured as standard iBGP peers. These two iBGP peers learn some routes locally and then re-advertise these prefixes over a full-mesh iBGP network to each other, with FRR being one of the four routers in the mesh. The other three iBGP peers are Cisco. FRR has one eBGP peer, to replicate re-advertising these routes out to iBGP. In our other three iBGP peers, we leverage route-maps to increment the received MED value of the route, so that we can prefer locally received eBGP routes - all else being equal - as opposed to those learned from our iBGP speakers in other locations. We also do this so locally originated prefixes from our AS have a higher metric when going out to eBGP speakers so they don't inadvertently get preferenced when there's a better path for the route to take. I am receiving the routes from our iBGP speakers fine, and see the incremented MED on receipt of the routes from the aforementioned speaker. When I configure a local (to FRR) iBGP speaker as a route-reflector-client within the same AS, these pre-incremented MED's are correctly advertised to the local iBGP speaker and work just fine. When advertising these same prefixes to an eBGP speaker with a different AS, the metric's are not readvertised, and only a locally originated prefix maintains any sort of metric at all. Route's received from one of our remote iBGP speakers: routert# sh bgp ipv4 unicast neighbors 1.1.1.1 received-routes BGP table version is 0, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 1234 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 1.1.1.1 100 100 0 i *> 1.2.3.0/20 1.1.1.1 100 100 0 i *> 2.3.4.0/21 1.1.1.1 100 100 0 5678 i *> 3.4.5.0/24 1.1.1.1 100 100 0 5678 i *> 5.6.7.0/22 1.1.1.1 102 100 0 5678 i *> 7.8.9.0/24 1.1.1.1 102 100 0 5678 i Total number of prefixes 6 Route's being correctly re-advertised and maintaining metric on re-advertisement to our local iBGP speaker (route-reflector-client): router# sh bgp ipv4 unicast neighbors 3.3.3.3 advertised-routes BGP table version is 4560509, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 1234 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 1.2.3.0/20 1.1.1.1 100 100 0 i *> 1.2.7.0/23 2.2.2.2 0 100 32768 i *> 2.3.4.0/21 1.1.1.1 100 100 0 5678i *> 3.4.5.0/24 1.1.1.1 100 100 0 5678 i *> 5.6.7.0/22 1.1.1.1 102 100 0 5678 i *> 7.8.9.0/24 1.1.1.1 102 100 0 5678 i Total number of prefixes 6 Route's not maintaining their metric on re-advertisement to our local (to FRR) eBGP speaker: router# sh bgp ipv4 unicast neighbors 8.8.8.8 advertised-routes BGP table version is 4562244, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 1234 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 1.2.3.0/20 0.0.0.0 100 0 i *> 1.2.7.0/23 0.0.0.0 0 32768 i *> 2.3.4.0/21 0.0.0.0 100 0 5678i *> 3.4.5.0/24 0.0.0.0 100 0 5678 i *> 5.6.7.0/22 0.0.0.0 100 0 5678 i *> 7.8.9.0/24 0.0.0.0 100 0 5678 i Total number of prefixes 6 Am I doing something wrong here? Otherwise a pretty straight forward BGP setup with some basic route-maps in and out, nothing too crazy. Is this expected behavior in FRR? Running latest available stable release, FRRouting 7.1RPKI. Thanks for any help.

2 1