July 2024 - frog - lists.frrouting.org

Re: [FROG] Migration scripts for FRR from Quagga
by Doug Tucker 13 Mar '25

13 Mar '25

I am under a time crunch now and have to get things going. So with one of my routers, I copied the full bgpd.conf into frr.conf. I am receiving all routes from the remote peer, however, the only outgoing route they are getting from this config is the /24 subnet that the frr router lives in. The other 3 subnets that I have defined are not being propogated. Any ideas what would cause this and how to resolve would be appriciated. I've been searching for a frr.conf sample file on google I could use to compare to mine but coming up empty. Doug Tucker Sr. Director of Networking and Linux Operations o: 817.975.5832 e: doug.tucker(a)navigaglobal.com Newscycle Solutions is now Naviga. Learn more. CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibite ________________________________ From: frog <frog-bounces+doug.tucker=navigaglobal.com(a)lists.frrouting.org> on behalf of Doug Tucker via frog <frog(a)lists.frrouting.org> Sent: Wednesday, June 12, 2024 12:39 PM To: Donald Sharp <donaldsharp72(a)gmail.com> Cc: frog(a)lists.frrouting.org <frog(a)lists.frrouting.org> Subject: Re: [FROG] Migration scripts for FRR from Quagga Naviga WARNING: External email. Please verify sender before opening attachments or clicking on links. _______________________________________________ frog mailing list frog(a)lists.frrouting.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.frr…<https://lists.frrouting.org/listinfo/frog>

3 9

setcommunity clue
by Randy Bush 31 Jul '24

31 Jul '24

it's late and i am correspondingly stupid bgp community-list standard comm-cust4 permit 3970:384 bgp community-list standard comm-cust6 permit 3970:386 bgp community-list standard comm-trans4 permit 3970:394 bgp community-list standard comm-trans6 permit 3970:396 bgp community-list standard comm-bbte permit 3970:174 ! ... ! route-map transit-in4 permit 10 set community comm-trans4 ! route-map transit-in6 permit 10 set community comm-trans6 ! route-map cust-in4 permit 10 set community comm-cust4 ! route-map cust-in6 permit 10 set community comm-cust6 results in % Malformed communities attribute 'comm-trans4' line 56: Failure to communicate[13] to bgpd, line: set community comm-trans4 % Malformed communities attribute 'comm-trans6' line 59: Failure to communicate[13] to bgpd, line: set community comm-trans6 % Malformed communities attribute 'comm-cust4' line 62: Failure to communicate[13] to bgpd, line: set community comm-cust4 % Malformed communities attribute 'comm-cust6' line 65: Failure to communicate[13] to bgpd, line: set community comm-cust6 those diagnstics are on the route-map set stanzas clue bat please randy

4 5

Re: [FROG] Migration scripts for FRR from Quagga
by Erwan David 26 Jul '24

26 Jul '24

On Fri, Jul 26, 2024 at 12:47:33AM CEST, Doug Tucker via frog <frog(a)lists.frrouting.org> said: > From: Doug Tucker <doug.tucker(a)navigaglobal.com> > To: Leonardo <leonardo.porto(a)iw.net.br>, Donald Sharp > <donaldsharp72(a)gmail.com> > CC: "frog(a)lists.frrouting.org" <frog(a)lists.frrouting.org> > Subject: Re: [FROG] Migration scripts for FRR from Quagga > Date: Thu, 25 Jul 2024 22:47:33 +0000 > > ip route help doesn't show that syntax as correct...any chance you have where you set that so it wasn't lost on a reboot and what it looks like? > > Usage: ip route { list | flush } SELECTOR > ip route save SELECTOR > ip route restore > ip route showdump > ip route get [ ROUTE_GET_FLAGS ] ADDRESS > [ from ADDRESS iif STRING ] > [ oif STRING ] [ tos TOS ] > [ mark NUMBER ] [ vrf NAME ] > [ uid NUMBER ] [ ipproto PROTOCOL ] > [ sport NUMBER ] [ dport NUMBER ] > ip route { add | del | change | append | replace } ROUTE > > Assuming "add" is needed, it doesn't like the Null0 at the end. > > ip route add 10.223.0.0/22 Null0 > Error: either "to" is duplicate, or "Null0" is a garbage. You are looking at the ip linux command, I think Leonardo spoke of the ip route configuration command in FRR -- Erwan

2 1

query with evpn import
by Senthilkumar Naidu 09 Jul '24

09 Jul '24

Hi, i have two host with frr connect to spine doing ebgp underlay and evpn overlay, both the hosts have a vtep with same vni-id connected to bridge and this bridge also has a veth interface those pair is connected to namespace. the namespace on both the host is part of same subnet and are able to ping each other via evpn. my query is both the hosts frr are using different asn so their RT is shown as ASN:vni in the evpn routes , how are they able to ping each other if the the RT values are different and i have not given any explicit import statement in bgp evpn configuration. Regards senthilkumar

1 0

Absent du bureau: BUM traffic to a multicast group without using PIM (shared VNI VXLAN interface)
by ctorgues＠lasotel.fr 07 Jul '24

07 Jul '24

Je suis actuellement absent du bureau.

1 0

BUM traffic to a multicast group without using PIM (shared VNI VXLAN interface)
by Pieter Krul 07 Jul '24

07 Jul '24

Greetings, We have configured two VTEP endpoints, mux and stub, both in a pure L2 only EVPN network, to send all BUM traffic to multicast group 239.0.0.1 These two configured VTEP endpoints are using shared VNI VXLAN interfaces. There is no PIM involved. All traffic sent to 239.0.0.1 is then ingress- replicated by an underlying network. Both hosts are on AlmaLinux 8.10, kernel 4.18.0-553.8.1.el8_10.x86_64, with FRR version 10.0.1 What we observed using tcpdump on the VXLAN interfaces of mux and stub, is that the two VTEP endpoints advertise a type 3 EVPN route for VNI 2063, and do not send traffic to the multicast group, but rather use ingress replication. Since this is not what we expected; Is it possible to send BUM traffic to a multicast group without using PIM, while using shared VNI VXLAN interfaces? Configuration: #### FRR configuration (stub) frr version 10.0 frr defaults traditional hostname stub log syslog no ip forwarding no ipv6 forwarding ! router bgp 65101 bgp router-id 10.11.0.20 bgp log-neighbor-changes no bgp default ipv4-unicast bgp disable-ebgp-connected-route-check neighbor rrs peer-group neighbor rrs remote-as internal neighbor rrs update-source 10.11.0.20 neighbor rrs capability extended-nexthop neighbor 10.11.0.19 peer-group rrs neighbor 10.11.0.19 disable-connected-check ! address-family l2vpn evpn neighbor rrs activate neighbor rrs route-map dataplane out advertise-all-vni exit-address-family exit ! route-map dataplane permit 10 set ipv4 vpn next-hop 10.111.111.2 exit ! #### FRR configuration (mux) frr version 10.0 frr defaults traditional hostname mux log syslog no ip forwarding no ipv6 forwarding ! router bgp 65101 bgp router-id 10.11.0.30 bgp log-neighbor-changes no bgp default ipv4-unicast bgp disable-ebgp-connected-route-check neighbor rrs peer-group neighbor rrs remote-as internal neighbor rrs update-source 10.11.0.30 neighbor rrs capability extended-nexthop neighbor 10.11.0.19 peer-group rrs neighbor 10.11.0.19 disable-connected-check ! address-family l2vpn evpn neighbor rrs activate neighbor rrs route-map dataplane out advertise-all-vni exit-address-family exit ! route-map dataplane permit 10 set ipv4 vpn next-hop 10.111.111.6 exit ! #### Linux device configuration: # ip link add dev br0 type bridge vlan_filtering 1 vlan_default_pvid 1 vlan_protocol 0x8100 vlan_stats_enabled 1 mcast_stats_enabled 1 vlan_stats_per_port 1 on stub: # ip link add vxlan0 type vxlan external dstport 8472 dev vlan0 local 10.111.111.2 group 239.0.0.1 nolearning vnifilter on mux: # ip link add vxlan0 type vxlan external dstport 8472 dev vlan0 local 10.111.111.6 group 239.0.0.1 nolearning vnifilter # ip link set dev vxlan0 master br0 # ip link set dev vxlan0 type bridge_slave vlan_tunnel on # bridge vlan add dev vxlan0 vid 2063 # bridge vlan add dev vxlan0 vid 2063 tunnel_info id 2063 #### on stub: vtysh -c "show bgp l2vpn evpn route type 3 self-originate json" | jq . "10.11.0.20:17": { "rd": "10.11.0.20:17", "[3]:[0]:[32]:[10.111.111.2]": { "prefix": "[3]:[0]:[32]:[10.111.111.2]", "prefixLen": 352, "paths": [ [ { "valid": true, "bestpath": true, "selectionReason": "First path received", "pathFrom": "external", "routeType": 3, "ethTag": 0, "ipLen": 32, "ip": "10.111.111.2", "weight": 32768, "peerId": "(unspec)", "path": "", "origin": "IGP", "extendedCommunity": { "string": "ET:8 RT:65101:2063" }, "nexthops": [ { "ip": "10.111.111.2", "hostname": "stub", "afi": "ipv4", "used": true } ] } ] ] } } #### on mux: # vtysh -c "show bgp l2vpn evpn route type 3 self-originate json" | jq . "10.11.0.30:19": { "rd": "10.11.0.30:19", "[3]:[0]:[32]:[10.111.111.6]": { "prefix": "[3]:[0]:[32]:[10.111.111.6]", "prefixLen": 352, "paths": [ [ { "valid": true, "bestpath": true, "selectionReason": "First path received", "pathFrom": "external", "routeType": 3, "ethTag": 0, "ipLen": 32, "ip": "10.111.111.6", "weight": 32768, "peerId": "(unspec)", "path": "", "origin": "IGP", "extendedCommunity": { "string": "ET:8 RT:65101:2063" }, "nexthops": [ { "ip": "10.111.111.6", "hostname": "mux", "afi": "ipv4", "used": true } ] } ] ] } } #### on stub: # show evpn vni 2063 VNI: 2063 Type: L2 Vlan: 0 Bridge: br0 Tenant VRF: default VxLAN interface: vxlan0 VxLAN ifIndex: 25 SVI interface: SVI ifIndex: 0 Local VTEP IP: 10.111.111.2 Mcast group: 0.0.0.0 <----------- Remote VTEPs for this VNI: 10.111.111.6 flood: HER Number of MACs (local and remote) known for this VNI: 2 Number of ARPs (IPv4 and IPv6, local and remote) known for this VNI: 0 Advertise-gw-macip: No Advertise-svi-macip: No #### on mux: # vtysh -c "show evpn vni 2063" VNI: 2063 Type: L2 Vlan: 0 Bridge: br0 Tenant VRF: default VxLAN interface: vxlan0 VxLAN ifIndex: 8 SVI interface: SVI ifIndex: 0 Local VTEP IP: 10.111.111.6 Mcast group: 0.0.0.0 <----------- Remote VTEPs for this VNI: 10.111.111.2 flood: HER Number of MACs (local and remote) known for this VNI: 2 Number of ARPs (IPv4 and IPv6, local and remote) known for this VNI: 0 Advertise-gw-macip: No Advertise-svi-macip: No With kind regards, Pieter

1 0

looking for expert opinion on whether this is normal
by Ian Veach 05 Jul '24

05 Jul '24

We're tracking down something that might be an issue - we're not sure. We don't normally run frr with all debug logging turned on, and don't know if this behavior is normal or not (we don't have much to compare it to). Every 30 seconds, with logging on, we see this in the logs (for each interface with route): 2024 Jul 5 11:31:41 hostredacted [daemon.debug] ospfd[960266]: [JZFS1-TNQFD] Zebra: interface services address delete 10.10.205.4/32 2024 Jul 5 11:31:41 hostredacted [daemon.debug] ospfd[960266]: [PH9HB-NQMHW] Zebra: interface services address add 10.10.205.4/32 vrf default id 0 It seems like this is flapping the interface to us, but maybe it's a normal part of frr internals to do so? Is this normal for frr to delete and add the interface every 30 seconds? Functionally, OSPF and our anycast DNS seems to be running ok. But our monitoring has missed some pings (which could be explained with the interface delete/add). (this is on rhel9, frr-8.5.3-4, although I also get the same behavior when I downgrade to frr-8.3.1-11) Thank you for any input! PUBLIC RECORDS NOTICE: In accordance with NRS Chapter 239, this email and responses, unless otherwise made confidential by law, may be subject to the Nevada Public Records laws and may be disclosed to the public upon request.

2 2

Re: [FROG] VRRP Object Tracking / Routes dependent on VRRP state
by Quentin Young 04 Jul '24

04 Jul '24

Hi, Unfortunately, there is no way I know of to do this at present. FRR supports calling arbitrary Lua scripts at predetermined points in protocol logic, and introducing such a point into vrrpd at an appropriate spot would allow a user script to implement object tracking. Indeed that was one of the motivating use cases for the Lua feature. However, the right combination of interested parties and programmers to make it happen ultimately never occurred. In short, the necessary components are in place, but the wiring and 20% needs to be done. It would be a fantastic summer project for someone interested in contributing to vrrpd. Quentin On Fri, Jun 28, 2024, at 5:02 AM, Alasdair Muckart via frog wrote: > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog > > > *Attachments:* > • Email.eml

2 2

FRR 10.0 Release
by Jafar Al-Gharaibeh 01 Jul '24

01 Jul '24

Dear FRR Community, We are pleased to announce FRR 10.0 major release. For release notes please visit: https://frrouting.org/release/10.0/ https://github.com/FRRouting/frr/releases/tag/frr-10.0 In this release, we are deprecating a couple of features. Make sure to go over "Breaking Changes" in the release notes. Cheers, The FRR Development Team!

1 1