- frog - lists.frrouting.org

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

VRRP Object Tracking / Routes dependent on VRRP state
by Alasdair Muckart 28 Jun '24

28 Jun '24

Is there any way in FRR to make routes depend on the state of a VRRP instance? I have an issue where I can't bind static routes to the VRRP interface, because they get jammed in 'inactive' state, but I have a pair of routers acting as the gateway to a network (where I can't run a dynamic routing protocol or BFD). That other network has a static route to me pointing at the VIP, but I have no way to influence the OSPF routes I send to the rest of my network based on the VRRP state. If I leave everything ECMP then half the time I'll get to the router that's the VRRP backup and the traffic blackholes because it's asymmetrical and the firewalls chuck it away. If I weight things so that the path through the VRRP primary is preferred, everything breaks if the VRRP fails over, which defeats the purpose. On appliance routers (Cisco, Junper, whatever) it's standard to be able to use object tracking to withdraw routes if the VRRP is in backup state. Is there any way to do this with FRR? Thanks -- Alasdair Muckart (he/him) Network Infrastructure Architect Catalyst.Net Limited - Expert Open Source Solutions Catalyst.Net Ltd - a Catalyst IT group company DDI: +64 4 897 7794 | Mobile: +64 22 638 5141 | Tel: +64 4 499 2267 | www.catalyst.net.nz CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267.

1 0

bgp yang model
by Feng Lei 21 Jun '24

21 Jun '24

hello, mailto. I am working retrofite the bgp command to northbound api. I meet a issue and i did'nt know about libyang well. I use yang/frr-bgp.yang generate skeleton code. i execute in vtysh > localhost.localdomain(config)# router bgp 200 % Failed to edit configuration. YANG error(s): Error: YANG version 1.1 expects all includes in main module, includes in submodules (frr-bgp-common-structure) are not necessary. Error: YANG version 1.1 expects all includes in main module, includes in submodules (frr-bgp-neighbor) are not necessary. Error: YANG version 1.1 expects all includes in main module, includes in submodules (frr-bgp-neighbor) are not necessary. Error: YANG version 1.1 expects all includes in main module, includes in submodules (frr-bgp-peer-group) are not necessary. Error: YANG version 1.1 expects all includes in main module, includes in submodules (frr-bgp-peer-group) are not necessary. Error: YANG version 1.1 expects all includes in main module, includes in submodules (frr-bgp-bmp) are not necessary. Path: Schema location "/frr-routing:routing/control-plane-protocols/control-plane-protocol". Error: Predicate missing for list "control-plane-protocol" in path "/frr-routing:routing/control-plane-protocols/control-plane-protocol/frr-bgp:bgp". this means if i should write bgpd yang model in myself and refer to isisd. hope your reply! 综合接入冯磊深圳震有科技股份有限公司座机：0755-86099888-1198 电话：13045884882 网址：http://www.genew.com 地址：深圳市南山区高新南区科苑南路3176号彩讯科技大厦6层邮箱：fenglei(a)genew.com

1 0

messages as attachement
by Erwan David 13 Jun '24

13 Jun '24

Hello, I receive almost all messages of the lists as only the footer, wtith the message as an attachment. That makes reading the list complicated, maybe something to configure in the mailing list software For recent messages : <mailman.35.1718217587.840.frog(a)lists.frrouting.org> is such, but <CAP3NpQufftUKGBcB84yD0TOJRGh=8+TPZhJvBT=8vYM6Yq8uew(a)mail.gmail.com> is not. -- Erwan David

1 0