- frog - lists.frrouting.org

Static Route and VPN Routes
by pmoreno＠bajaopensolutions.com 01 Nov '21

01 Nov '21

Hello. I have a situation that would like to know if FRR can help me. We have a PTP between 2 locations, but we would like to have a backup failover solution in case our main link in this case our PTP goes down. We are thinking to add a VPN with OpenVPN and with FRR manage the FO beetween both locations. -----------------------------PTP ------------------------------ Location 1 Location 2 ------------------------------Ovpn----------------------------- Can FRR help me ? Regards!!!

1 0

No Path to RP address specified
by owen s 01 Nov '21

01 Nov '21

I am getting the above error when trying to add my rp address (config)# ip pim rp 69.x.x.x No Path to RP address specified: 69.x.x.x but that's not correct. I have 3 interfaces, my configuration file below. ip pim rp 69.x.x.x 224.0.0.0/4 service integrated-vtysh-config ! interface ens4 ip igmp ip igmp version 2 ip pim ! interface ipsec9 ip igmp ip igmp version 2 ip pim ! interface t0 ip igmp ip igmp version 2 ip pim ! line vty ! I am able to ssh to the rp-address no problem, but frr cannot connect to the routing path. telnet 69.x.x.x 22 Trying 69.x.x.x ... Connected to 69.x.x.x. Escape character is '^]'. SSH-2.0-Cisco-1.25 I created an ikev1 ipsec tunnel from my local machine to the remote network, the interface shows the default 0.0.0.0 as the gateway and that might be causing frr to show the error about no path to rp address. Is there a way to allow frr to properly route through the 0.0.0.0 gateway?

1 0

pim-sm on linux router
by owen s 31 Oct '21

31 Oct '21

I learned how to work with frr using configure terminal -> interface to configure interfaces. I need to setup a router that creates an ipsec tunnel, then creates a gre tunnel to route multicast packets using ipsec over gre. I have three interfaces; my local /26 subnet a static loopback ip I need to use pim-sm Here's my current configuration ======================= write terminal Building configuration... Current configuration: ! frr version 8.0.1 frr defaults traditional hostname bb no ipv6 forwarding service integrated-vtysh-config ! debug igmp events debug igmp packets debug igmp trace debug mroute debug mtrace ! interface ens4 ip igmp ip igmp version 2 ip pim ! interface t0 ip igmp ip igmp version 2 ip pim ! line vty ! end ======================= interface ens4 is my /26 subnet interface t0 the gre tunnel, source is from my loopback address to a remote address. ip tun show t0: gre/ip remote x.x.x.x local [local loobpack ip] ttl 255 show interface Interface ens4 is up, line protocol is up Link ups: 0 last: (never) Link downs: 0 last: (never) vrf: default index 2 metric 0 mtu 1460 speed 4294967295 flags: <UP,BROADCAST,RUNNING,MULTICAST> Type: Ethernet HWaddr: 42:01:0a:f7:2f:42 inet x.x.x.x/32 unnumbered inet x.x.x.x/32 unnumbered Interface Type Other Interface Slave Type None protodown: off Interface ens5 is up, line protocol is up Link ups: 0 last: (never) Link downs: 0 last: (never) vrf: default index 3 metric 0 mtu 1460 speed 4294967295 flags: <UP,BROADCAST,RUNNING,MULTICAST> Type: Ethernet HWaddr: 42:01:dc:8c:05:4a inet x.x.x.x/32 unnumbered Interface Type Other Interface Slave Type None protodown: off Interface erspan0 is down Link ups: 0 last: (never) Link downs: 0 last: (never) vrf: default index 15 metric 0 mtu 1464 speed 0 flags: <BROADCAST,MULTICAST> Type: Ethernet Interface Type Other Interface Slave Type None protodown: off Interface gre0 is down Link ups: 0 last: (never) Link downs: 0 last: (never) vrf: default index 13 metric 0 mtu 1476 speed 0 flags: <NOARP> Type: GRE over IP Interface Type GRE Interface Slave Type None protodown: off Interface gretap0 is down Link ups: 0 last: (never) Link downs: 0 last: (never) vrf: default index 14 metric 0 mtu 1476 speed 0 flags: <BROADCAST,MULTICAST> Type: Ethernet Interface Type Other Interface Slave Type None protodown: off Interface ip_vti0 is down Link ups: 0 last: (never) Link downs: 0 last: (never) vrf: default index 7 metric 0 mtu 1480 speed 0 flags: <NOARP> Type: IPIP Tunnel Interface Type Other Interface Slave Type None protodown: off Interface lo is up, line protocol is up Link ups: 0 last: (never) Link downs: 0 last: (never) vrf: default index 1 metric 0 mtu 65536 speed 0 flags: <UP,LOOPBACK,RUNNING,MULTICAST> Type: Loopback inet x.x.x.x/32 Interface Type Other Interface Slave Type None protodown: off Interface pimreg is up, line protocol is up Link ups: 1 last: 2021/10/30 19:29:44.16 Link downs: 0 last: (never) vrf: default index 23 metric 0 mtu 1472 speed 0 flags: <UP,RUNNING,NOARP> Type: Unknown Interface Type Other Interface Slave Type None protodown: off Interface t0 is up, line protocol is up Link ups: 0 last: (never) Link downs: 0 last: (never) vrf: default index 16 metric 0 mtu 1436 speed 0 flags: <UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> Type: GRE over IP HWaddr: 0a:f7:00:3c inet x.x.x.x/30 Interface Type GRE Interface Slave Type None VTEP IP: x.x.x.x , remote y.y.y.y protodown: off show 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, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup t - trapped, o - offload failure K>* 0.0.0.0/0 [0/0] via x.x.x.x, ens4, 11:28:19 C>* x.x.0.60/32 is directly connected, lo, 11:28:19 C>* x.x.4.232/30 is directly connected, t0, 11:28:19 K>* x.x.x.x/26 [0/0] via x.x.x.x, ens4, 11:28:19 K * x.x.x.x/32 [0/0] is directly connected, ens4, 11:28:19 C>* x.x.x.x/32 is directly connected, ens4, 11:28:19 C>* x.x.x.x/32 is directly connected, ens4, 00:11:53 K>* y.y.y.72/29 [0/0] via y.y.y.73, ens5, 11:28:19 K>* y.y.y.73/32 [0/0] is directly connected, ens5, 11:28:19 C>* y.y.y.74/32 is directly connected, ens5, 00:05:45 show ip mroute IP Multicast Routing Table Flags: S - Sparse, C - Connected, P - Pruned R - SGRpt Pruned, F - Register flag, T - SPT-bit set Source Group Flags Proto Input Output TTL Uptime show ip pim neighbor Interface Neighbor Uptime Holdtime DR Pri The route should get picked up through the gre tunnel. Are there any steps that I can take to get the router properly configured to join the proper pim group and detect neighbor?

2 1

setting up frr for pim-sm
by owen s 30 Oct '21

30 Oct '21

Hello everyone I have read the basic setup of FRR and I would like to setup pim-sm I edited daemons to enable pimd, here's a list of running processes root 3541 0.0 0.0 12644 4012 ? S<s Oct28 0:03 /usr/lib/frr/watchfrr -d -F traditional zebra pimd staticd frr 3558 0.0 0.2 395068 10136 ? S<sl Oct28 0:02 /usr/lib/frr/zebra -d -F traditional -A 127.0.0.1 -s 90000000 frr 3563 0.0 0.1 15744 6084 ? S<s Oct28 0:00 /usr/lib/frr/pimd -d -F traditional -A 127.0.0.1 frr 3571 0.0 0.1 13524 4548 ? S<s Oct28 0:00 /usr/lib/frr/staticd -d -F traditional -A 127.0.0.1 I am trying to set up pim through the vtysh command but I am not sure that I understand properly using vtysh. I launch vtysh, then I run configure terminal command, then when I try to run any of the commands from this page: http://docs.frrouting.org/en/latest/pim.html I keep getting either incomplete command, for example ip pim rp 10.10.64.1 No Path to RP address specified: 10.10.64.1 I have two interfaces, interface eth0 ip address 10.10.60.65/26, it needs to have pim sparse-mode enable on that interface. How can I configure that using vtysh? Best, Owen

2 1

Next-Hop/Route Installation Issues with IPv6 on Route Server
by Michael H Lambert 25 Oct '21

25 Oct '21

I’m trying to debug a rather strange issue I’m seeing with bgpd from FRR 7.5.1 (latest from FreeBSD 13.0 packages) used as a route server. The single peer for this test case is a VRF on a Cisco 6509 (although the problem also exists with Brocade and a couple of flavors of Junos). Peering is over a tagged (VLAN) subnet, ie, a subinterface on a physical Ethernet. The motivation is a smooth (only some minor syntactic changes needed) migration from the Euro-IX fork of quagga to FRR. The alternatives (BIRD or OpenBGPD) would probably require semantic changes in addition. [Note: IP addresses and ASNs have been obfuscated so our security folks won’t yell] The test configuration is straightforward: ========== Current configuration: ! frr version 7.5.1 frr defaults traditional ! hostname rs-dev-bgpd password password enable password password log syslog ! debug bgp updates in debug bgp updates out ! ! ! router bgp 64512 view TESTING bgp router-id 198.51.100.247 bgp log-neighbor-changes no bgp ebgp-requires-policy no bgp default ipv4-unicast no bgp network import-check neighbor 198.51.100.248 remote-as 64536 neighbor 198.51.100.248 description Peering with TESTING (VRF) neighbor 2001:db8:0:fe1f::18 remote-as 64536 neighbor 2001:db8:0:fe1f::18 description Peering with TESTING (VRF) ! address-family ipv4 unicast neighbor 198.51.100.248 activate neighbor 198.51.100.248 soft-reconfiguration inbound neighbor 198.51.100.248 route-server-client neighbor 198.51.100.248 route-map PERMIT_ANY in neighbor 198.51.100.248 route-map DENY_ANY out neighbor 198.51.100.248 attribute-unchanged next-hop exit-address-family ! address-family ipv6 unicast neighbor 2001:db8:0:fe1f::18 activate neighbor 2001:db8:0:fe1f::18 soft-reconfiguration inbound neighbor 2001:db8:0:fe1f::18 route-server-client neighbor 2001:db8:0:fe1f::18 route-map PERMIT_ANY in neighbor 2001:db8:0:fe1f::18 route-map DENY_ANY out neighbor 2001:db8:0:fe1f::18 attribute-unchanged next-hop exit-address-family ! ! ! route-map DENY_ANY deny 100 ! route-map PERMIT_ANY permit 100 ! ! line vty exec-timeout 60 0 ! end ========== I’m checking IPv4 first. The Cisco thinks its announcements are cisco#show bgp vrf TESTING vpnv4 unicast neighbors 198.51.100.247 advertised-routes BGP table version is 1867871, local router ID is 198.51.100.249 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 64536:1 (default for vrf TESTING) VRF Router ID 198.51.100.249 *> 192.0.2.0/24 0.0.0.0 0 32768 ? *> 198.51.100.224/27 0.0.0.0 0 32768 ? Total number of prefixes 2 ========== The BGP summary on FRR/bgpd shows the expected two routes: ========== rs-dev-bgpd# show bgp view TESTING ipv4 unicast summary BGP router identifier 198.51.100.247, local AS number 64512 vrf-id 1 BGP table version 2 RIB entries 3, using 576 bytes of memory Peers 1, using 14 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt 198.51.100.248 4 64536 16 12 0 0 0 00:10:05 2 0 Total number of neighbors 1 ========== And they are also the expected routes, matching what the Cisco thinks it is sending. ========== rs-dev-bgpd# show bgp view TESTING ipv4 unicast BGP table version is 2, local router ID is 198.51.100.247, vrf id 1 Default local pref 100, local AS 64512 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 *> 192.0.2.0/24 198.51.100.248 0 0 64536 ? *> 198.51.100.224/27 198.51.100.248 0 0 64536 ? Displayed 2 routes and 2 total paths ========== From more extensive testing, IPv4 seems to be behaving as I think it should. Now I turn my attention to IPv6. Again, the Cisco seems happy: ========== cisco#show bgp vrf TESTING vpnv6 unicast neighbors 2001:DB8:0:FE1F::17 advertised-routes BGP table version is 1642349, local router ID is 198.51.100.249 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 64536:1 (default for vrf TESTING) VRF Router ID 198.51.100.249 *> 2001:DB8:0:FE1F::/64 :: 0 32768 ? *> 2001:DB8:FFFF:9F::/64 :: 0 32768 ? Total number of prefixes 2 ========== Two prefixes are being announced over the established BGP session. Indeed, bgpd sees the session as established, but it’s not receiving prefixes: rs-dev-bgpd# show bgp view TESTING ipv6 unicast summary BGP router identifier 198.51.100.247, local AS number 64512 vrf-id 1 BGP table version 0 RIB entries 0, using 0 bytes of memory Peers 1, using 14 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt 2001:db8:0:fe1f::18 4 64536 16 12 0 0 0 00:10:16 0 0 Total number of neighbors 1 rs-dev-bgpd# show bgp view TESTING ipv6 unicast No BGP prefixes displayed, 0 exist ========== So what’s going on here? In syslog (daemon.log), I see a few lines, two of which seem pretty strange: ========== Oct 25 14:29:50 rs-dev bgpd[59414]: [EC 33554503] 2001:db8:0:fe1f::18 unrecognized capability code: 70 - ignored Oct 25 14:29:50 rs-dev bgpd[59414]: %ADJCHANGE: neighbor 2001:db8:0:fe1f::18(Unknown) in vrf Up Oct 25 14:29:50 rs-dev bgpd[59414]: 2001:db8:0:fe1f::18 sent a v6 LL next-hop and there's no peer interface information. Hence, withdrawing Oct 25 14:29:50 rs-dev bgpd[59414]: [EC 33554487] 2001:db8:0:fe1f::18: Attribute MP_REACH_NLRI, parse error - treating as withdrawal Oct 25 14:29:50 rs-dev bgpd[59414]: [EC 33554454] 2001:db8:0:fe1f::18 rcvd UPDATE with errors in attr(s)!! Withdrawing route. Oct 25 14:29:50 rs-dev bgpd[59414]: 2001:db8:0:fe1f::18 [Info] UPDATE for non-enabled AFI/SAFI 1/1 Oct 25 14:29:50 rs-dev bgpd[59414]: bgp_update_receive: rcvd End-of-RIB for IPv6 Unicast from 2001:db8:0:fe1f::18 in vrf default ========== Several comments/observations: 1) The link-local next-hop and AFI/SAFI messages are present whether the peer is the Cisco or a Juniper or Brocade/Extreme. These are particularly befuddling, since they have no trouble talking to quagga or to each other. 2) I tried assigning a different MAC address to the subinterface than that which was on the physical interface with the same results. I thought this might take care of link-local addresses and neighbor discovery issues. 3) On Friday, I built the code from the head of the git master and tested it, again with the same results. 4) If I mock this up on VMs under VirtualBox, using (emulated) physical interfaces (not tagged subinterfaces) and OpenBSD/OpenBGPD speakers instead of vendor routers, IPv4 and IPv6 both work as expected. I will note that I’m using ULAs and not global unicast addresses. In this case, it’s the same version of FreeBSD and FRR as in the physical test. At this point, my best guess is that I’m running into an interaction issue between FRR/bgpd and tagged subinterfaces. If that is the case, is it across all platforms? Restricted to FreeBSD? Specific to FreeBSD 13? Am I just missing another knob on bgpd for running as a route server? Do I need to run vtysh to have the interfaces handled properly? Do I need to do something with zebra even though there is no forwarding involved, just routing? Any insights would be most appreciated. 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 1

Problem in FRR with ldpd
by shruti mathure 15 Oct '21

15 Oct '21

Respected Sir, I am Shruti Mathure. I am working on one of the projects related to FRR. I am trying to implement MPLS LDP with FRR in Core emulator. The FRR seems to run but I am having issue with ldpd, It is not running also the staticcd does not seems to run which should automatically start with FRR. I am not able to find the correct solution for it. can you let me know any solution for this if there is any changes or latest updated bugs you have fix. I am not able to find any solution on github. I am using ubuntu 18.04. Thank you, Regards, Shruti Mathure

2 1

P2P and vpn tunnel paths
by Pedro Moreno 09 Oct '21

09 Oct '21

Hello. I have a firewall and 2 vpns(openvpn) to connect 2 locations, is working, now the company bring a 3rd connection( P2P )which I would like to add to the link between both locations. The idea is to setup frr-ospf to manage the paths this way: P2P first option VPN1 2nd option VPN2 3rd option Like a failover. Can FRR help me with this plan? Thanks for your time. ⁣Get BlueMail for Android

1 0

ACCESS-LIST FRR Query
by S.M Tanjeen 23 Sep '21

23 Sep '21

Hi, Is there any option to implement/ distribute an access-list in an interface like Cisco. And also is there any option access lists in global domain? -- Regards, S. M. Tanjeen

1 0

Any way to force a local route weight to 0 ?
by Thomas Martin 22 Sep '21

22 Sep '21

Hello, I'm looking for a way to be able to force local routes to a weight of 0 (apart from modifying the source code). To be honest I don't think there is but maybe I missed something. My goal is to use a local route as a backup solution (if BGP is down for example), but to use it only if not sent through BGP. Thanks. Regards, Thomas

2 2

Frrouting log files are kept open after logrotate?
by Cloud Operations 21 Sep '21

21 Sep '21

Hi, I've just noticed an issue on our production servers whilst investigating a BGP problem that FRR doesn't close the (previous) log file when logrotate happens apparently? # lsof -n | grep bgpd ... bgpd_ka 83886 83889 frr 317w REG 8,2 6820199 2490648 /var/log/frr/bgpd.log-20210829 (deleted) bgpd_ka 83886 83889 frr 318w REG 8,2 4972381 2490637 /var/log/frr/bgpd.log-20210830 (deleted) bgpd_ka 83886 83889 frr 319w REG 8,2 5836081 2490654 /var/log/frr/bgpd.log-20210908 (deleted) bgpd_ka 83886 83889 frr 320w REG 8,2 4705731 2490650 /var/log/frr/bgpd.log-20210831 (deleted) bgpd_ka 83886 83889 frr 321w REG 8,2 4873053 2490640 /var/log/frr/bgpd.log-20210901 (deleted) bgpd_ka 83886 83889 frr 322w REG 8,2 3415500 2490625 /var/log/frr/bgpd.log-20210918 (deleted) bgpd_ka 83886 83889 frr 323w REG 8,2 5120763 2490603 /var/log/frr/bgpd.log-20210903 (deleted) bgpd_ka 83886 83889 frr 324w REG 8,2 4928209 2490677 /var/log/frr/bgpd.log-20210904 (deleted) bgpd_ka 83886 83889 frr 325w REG 8,2 6398055 2490614 /var/log/frr/bgpd.log-20210914 (deleted) bgpd_ka 83886 83889 frr 326w REG 8,2 4632644 2490643 /var/log/frr/bgpd.log-20210906 (deleted) bgpd_ka 83886 83889 frr 327w REG 8,2 6893498 2490683 /var/log/frr/bgpd.log-20210910 (deleted) ... Sending a USR1 signal had no effect. This is FRR 7.5.1 on CentOS 7. Can someone else please check and confirm this issue? Thank you! -- Natterbox Limited Registered address: No 1 Croydon, 12-16 Addiscombe Road, Croydon CR0 0XT, UK Company number: 06968249 VAT number: 293 7488 48 This email and any files transmitted with it are confidential, intended solely for the use of the addressee and are not to be used, disseminated, forwarded, printed or copied by any other person. Any views or opinions are solely those of the author and do not necessarily represent those of Natterbox Limited unless specifically stated. If you have received this communication in error, please accept our apologies and promptly inform the sender by email or by telephoning the above number. Please also immediately delete this message and any attachments from your systems. Thank you. The files attached and/or any website linked to this email may contain viruses which could damage your computer, Natterbox Limited cannot accept liability for such damage.

1 0