- frog - lists.frrouting.org

VPLS not working on Ubuntu 18 VM
by abdelmuhaimen.seaudi＠orange.com 19 Jan '22

19 Jan '22

Hello, I followed the tutorial, and configured 2 Ubuntu 18 VMs with frr OSPF + LDP + L2VPN VPLS. Routing table is OK on the VMs, pseudowires created OK and UP. I cannot see bridge br0 or interface mpw0, if I do “ifconfig” on the linux vm. I tried pinging over the VPLS, but the frames coming from the host are not encapsulated in MPLS. Is there a specific Linux setup necessary to enable the dataplane forwarding to work ? Thanks Abdel-Muhaimen Seaudi Orange Innovation Egypt Email: abdelmuhaimen.seaudi(a)orange.com Mobile: +2012 84644 733 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

3 5

EoMPLS with FRR
by abdelmuhaimen.seaudi＠orange.com 14 Jan '22

14 Jan '22

Hello I would like to know if I can setup an EoMPLS PseudoWire using FRR. And, if it is not fully supported, is there a workaround using FRR ? My linux: Linux sonic 5.10.0-8-2-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 GNU/Linux. Thanks for any information about the topic Abdel-Muhaimen Seaudi Orange Innovation Egypt Email: abdelmuhaimen.seaudi(a)orange.com Mobile: +2012 84644 733 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0

About eliminating duplicate BFD peer session
by 吴昌容 08 Jan '22

08 Jan '22

Dear FRR community members, I am a user of FRR and I am now using it to build a small-scale experiment network. I ran into a problem regarding the interaction between BFD and BGP in the recent days. My BGP configuration specifies BFD dependencies for BGP neighbors using "neighbor X.X.X.X bfd". And the FRR will create some BFD peer sessions (marked as dynamic in FRR) immediately when it reads the BGP configuration. Then after FRR reads the BFD configuration, it seems that FRR will deregister the previous "dynamic" peer sessions and register those peer sessions (marked as configured) specified in the BFD configuration. I learn this from the debugging log and such mechanisms work in most cases. But in some situations, it does not work. Specifically, the FRR will have two duplicate BFD peer sessions for the same peer at last. I found that restarting FRR can solve the problem. Yet, I wonder whether there is a more elegant solution. The example configuration of the problematic peer is as follows: router #1, with IP address 10.3.0.1 *router bgp 1 no bgp ebgp-requires-policy neighbor 10.0.0.2 remote-as 2 neighbor 10.0.0.2 bfd neighbor 10.1.0.2 remote-as 3 neighbor 10.1.0.2 bfd neighbor 10.4.0.1 remote-as 1 neighbor 10.4.0.1 bfd neighbor 10.4.0.1 update-source 10.3.0.1 neighbor 10.5.0.1 remote-as 1 neighbor 10.5.0.1 bfd neighbor 10.5.0.1 update-source 10.3.0.1 ! address-family ipv4 unicast network 10.0.0.0/24 <http://10.0.0.0/24> network 10.1.0.0/24 <http://10.1.0.0/24> network 10.3.0.0/24 <http://10.3.0.0/24> network 10.4.0.0/24 <http://10.4.0.0/24> network 10.5.0.0/24 <http://10.5.0.0/24> network 10.12.0.0/24 <http://10.12.0.0/24> network 10.13.0.0/24 <http://10.13.0.0/24> network 10.18.0.0/24 <http://10.18.0.0/24> exit-address-familyexitbfd peer 10.0.0.2 transmit-interval 100 receive-interval 100 exit ! peer 10.1.0.2 transmit-interval 100 receive-interval 100 exit ! peer 10.4.0.1 multihop local-address 10.3.0.1 transmit-interval 100 receive-interval 100 exit ! peer 10.5.0.1 multihop local-address 10.3.0.1 transmit-interval 100 receive-interval 100 exit !exit* router #2, with IP address 10.5.0.1 *router bgp 1 no bgp ebgp-requires-policy neighbor 10.3.0.1 remote-as 1 neighbor 10.3.0.1 bfd neighbor 10.3.0.1 update-source 10.5.0.1exitbfd peer 10.3.0.1 multihop local-address 10.5.0.1 transmit-interval 100 receive-interval 100 exit !exit* The router #1 get two duplicate BFD peer sessions as follows: (the interface s0-eth2 has the IP address 10.3.0.1) *peer 10.5.0.1 local-address 10.3.0.1 vrf default interface s0-eth2 ID: 2040029068 Remote ID: 0 Active mode Status: down Downtime: 11 minute(s), 51 second(s) Diagnostics: ok Remote diagnostics: ok Peer Type: dynamic Local timers: Detect-multiplier: 3 Receive interval: 300ms Transmission interval: 300ms Echo receive interval: 50ms Echo transmission interval: disabled Remote timers: Detect-multiplier: 3 Receive interval: 1000ms Transmission interval: 1000ms Echo receive interval: disabled* * peer 10.5.0.1 multihop local-address 10.3.0.1 vrf default ID: 1516906735 Remote ID: 2466577291 Active mode Minimum TTL: 254 Status: up Uptime: 11 minute(s), 51 second(s) Diagnostics: ok Remote diagnostics: ok Peer Type: configured Local timers: Detect-multiplier: 3 Receive interval: 100ms Transmission interval: 100ms Echo receive interval: 50ms Echo transmission interval: disabled Remote timers: Detect-multiplier: 3 Receive interval: 100ms Transmission interval: 100ms Echo receive interval: 50ms* Can anyone give me a hint of a clean solution? Thanks! Changrong Wu

1 0

kernel route redistribution via OSPF
by HOSTAK Peter 20 Dec '21

20 Dec '21

Hi all, I have a question regarding redistribution of kernel routes with specific metric via OSPF6. I have a very simple OSPF6 router definition: interface eth0 ipv6 ospf6 area 0 exit ! router ospf6 ospf6 router-id 8.8.8.81 redistribute kernel exit and I would like to redistribute the following sample kernel (static) routes: ATN-DC-FRR-01# show ipv6 route kernel K>* fca0:ffff::2/128 [0/50] via fc00::4, eth0, 3d23h32m K>* fca0:ffff::3/128 [0/100] via fc00::4, eth0, 00:00:03 The problem is not to redistribute them via OSPF6 to another OSPF6 neighbor but to either redistribute them with the same OSPF metric (e.g. 50 or 100 as in my example above) or somehow set it using route maps (I have finite number of metrics to set). Q1: Is it expected that the kernel route metric is ignored and default OSPF metric "20" is set instead? (it is a feature or a bug?) I've also tried to set the metrics using route maps. Yes, it is possible to set it but there is no way to match "original" kernel route metric ("match metric XY" matches everything) and set it as OSPF metric. Q2: What kind of metric "match metric" matches? In documentation I found only "matches the specified metric". Is it only an "IGP" metric (BGP, OSPF...) and kernel route metric is ignored? "match metric 100" matches routes with any metric so I guess it is ignored. In reality I have multiple kernel routes (static routes) which need to be assigned into pre-defined groups (finite number) and this assignment needs to be propagated somehow via OSPF to another OSPF neighbours (cisco boxes). Only usable parameter for such an assignment is a metric since there is no "tag" in "iproute" (I also tried "weight" which is not visible for FRR). So, the idea is the following: all the routes with metric e.g. 10 will be part of the group 1 and will get OSPF metric 10 and so on. Since it is group of kernel routes which have nothing in common (apart of group assignment), I can't use e.g. source IP or next-hop IP as matching criterion, but I need something more generic (like a tag) which I can use to label them. Do you guys have an idea how to achieve it? Thank you in advance. Best regards Peter

1 0

Dependencies unmet for current 'stable' frr-pythontools (on debian buster)
by Willy Manga 18 Nov '21

18 Nov '21

Hi, unless I'm using an outdated cache here is what I got on debian buster tonight: root@rs1:~# apt-cache policy frr frr: Installed: (none) Candidate: 8.0.1-0~deb11u1 Version table: 8.0.1-0~deb11u1 500 500 https://deb.frrouting.org/frr bullseye/frr-stable amd64 Packages 7.5.1-1.1 500 500 http://deb.debian.org/debian bullseye/main amd64 Packages root@rs1:~# apt-cache policy frr-pythontools frr-pythontools: Installed: (none) Candidate: 8.1-0~deb11u1 Version table: 8.1-0~deb11u1 500 500 https://deb.frrouting.org/frr bullseye/frr-stable amd64 Packages 7.5.1-1.1 500 500 http://deb.debian.org/debian bullseye/main amd64 Packages And you try to install frr and frr-pythontools The following packages have unmet dependencies: frr-pythontools : Depends: frr (>= 8.1-0~deb11u1~) but 8.0.1-0~deb11u1 is to be installed E: Unable to correct problems, you have held broken packages. -- Willy Manga @ongolaboy https://ongola.blogspot.com/

1 1

kernel default route inactive when installed after FRR 7.5 starts
by Andrew J. Schorr 14 Nov '21

14 Nov '21

Hi, I'm upgrading a bunch of Linux routers from CentOS 7 to Rocky 8, and as part of the upgrade, quagga seems to have been replaced by frr. For the most part, everything works fine, but I've encountered one problem. I've got a router that picks up a default route via DHCP from a cable modem. With quagga, this default route was accepted and redistributed via OSPF. But with FRR, it sometimes says that the route is "inactive", which horks my routing. I built the Fedora 34 quagga package and ran that and saw these results using quagga-1.2.4-17.el8.x86_64: Hello, this is Quagga (version 1.2.4). Copyright 1996-2005 Kunihiro Ishiguro, et al. ti14# show ip route 0.0.0.0/0 Routing entry for 0.0.0.0/0 Known via "ospf", distance 110, metric 103, tag 0, vrf 0 Last update 00:00:13 ago > 192.168.39.5, via lan0.9 Routing entry for 0.0.0.0/0 Known via "kernel", distance 0, metric 0, tag 0, vrf 0, best, fib >* 207.237.112.1, via lan1 But with the standard frr-7.5-4.el8.x86_64.rpm, it sometimes marks the kernel route as inactive when it starts, and uses the ospf route instead: Hello, this is FRRouting (version 7.5). Copyright 1996-2005 Kunihiro Ishiguro, et al. ti14# show ip route 0.0.0.0/0 Routing entry for 0.0.0.0/0 Known via "ospf", distance 110, metric 103, best Last update 00:04:42 ago * 192.168.39.5, via lan0.9, weight 1 Routing entry for 0.0.0.0/0 Known via "kernel", distance 0, metric 0 Last update 00:05:42 ago * 207.237.112.1, via lan1 inactive When it's working properly, typically after a restart, I see: Hello, this is FRRouting (version 7.5). Copyright 1996-2005 Kunihiro Ishiguro, et al. ti14# show ip route 0.0.0.0/0 Routing entry for 0.0.0.0/0 Known via "ospf", distance 110, metric 103 Last update 00:00:01 ago 192.168.39.5, via lan0.9, weight 1 Routing entry for 0.0.0.0/0 Known via "kernel", distance 0, metric 0, best Last update 00:00:08 ago * 207.237.112.1, via lan1 My best guess is that there's some kind of timing issue here. When the system boots up with FRR, the FRR daemons start before DHCP installs the default route. That seems to lead to its being marked inactive. If I then restart FRR, it accepts the kernel default route. Is this perhaps fixed in a newer version of FRR? Or am I doing something stupid? Is there a patch for this? If not, I'm going to need to revert to quagga. Thanks, Andy

2 2

Limitations on Bulk Addition of Static Routes in FRR?
by Tim Nelson 14 Nov '21

14 Nov '21

Greetings- I'm attempting to use FRR 7.5.1 running on Debian 11.1 in a lab environment to simulate an upstream BGP peer to other network devices. I wrote a quick shell script to generate all of the /24s in IPv4 address space and have tried loading these into FRR two different ways: a) Writing all static route config directives to a separate config file, then loading that config live using "vtysh -f /tmp/nets" b) Appending the static route config directives to my existing /etc/frr/frr.conf file and restarting the frr service Both options fail to load routes after the first few thousand or so ( 1.0.0.0/24 through 1.4.238.0/24, none further). The logs don't indicate any problems or cause for the failure to load additional routes. The system has plenty of resources so I don't expect this to be a memory problem. Thoughts on what I could be doing wrong and suggestions on how to accomplish this? Thanks! --Tim

2 1

OSPF: scaling routers in area or areas per se
by Muenz, Michael 12 Nov '21

12 Nov '21

Dear all, I'm currently designing a new network, it has 2 DC's with each having a VPN cluster. Each VPN cluster has a Firewall Cluster behind and it's set up in a circle, so VPN in DC1 has a DCI to VPN in DC2 and a dedicated link to FW in DC1. Same as in DC2 and FW in DC2 has a DCI to FW in DC1. In this circle I'm running area 0.0.0.0 and wherever I add a new interface it's known to the network. Now comes the fun part. We have 100 branches and we use OpenVPN to connect to one of the VPN concentrators with the second as backup. The challenge is, that it shouldn't matter where the branch currently is connected to, BUT, it's only allowed to be connected to one DC to prevent async routing. Technically this is also easy, but I'm not sure which one scales better: - Have only one area 0.0.0.0 also on the branches, so over 100 routers in one area - Have for each branch one area, so over 100 areas having only one router - Running external via BGP and having 100 neighbors with 100 private AS Anyone here experienced regarding scaling this size? Thx! Michael

2 1

LDP FEC question
by Emmanuel Chaput 12 Nov '21

12 Nov '21

Hi ! Is there any way to configure the FECs defined by LDP ? eg I have an OSPF routed network and LDP basically adds the same destinations in my routing tables. I think it's a bit useless for the core networks, while I would like LDP to build some LSPs between by border networks (that are not announced by OSPF). Any help welcome ;-) -- Manu

2 1

Announcing FRR Release 8.1
by Jafar Al-Gharaibeh 11 Nov '21

11 Nov '21

Hi all, We are pleased to announce the 8.1 release of FRRouting. This release brings a long list of enhancements and fixes with 1200 commits from 75 developers. Thanks to all contributors. Packages: Debian Packages - https://deb.frrouting.org/ RPM Packages - https://rpm.frrouting.org/ Snaps - https://snapcraft.io/frr Docker - frrouting/frr:v8.1.0 Some major highlights: * Lua hooks are now feature complete, with one hook available for use * Improvements to Prefix-SID (Type 5) * EVPN route type-5 gateway IP overlay Index * OSPFv3 NSSA and NSSA totally stub areas * OSPFv3 ASBR summarization * OSPFv3 Graceful Restart * OSPFv2 Graceful Restart (restarting mode added, helper was already implemented) Please see the release notes for the detailed changelog: * Github release: https://github.com/FRRouting/frr/releases/tag/frr-8.1 * FRRouting website: https://frrouting.org/release/8.1/ During this period we also hosted an FRRouting 2021 GSOC Project! FRRouting's GSOC student implemented the infrastructure needed to add the ability to call out to user provided Lua scripts from within FRR. Keep an eye out for developments in this area. You can read about the work at: - https://frrouting.github.io/frr-gsoc/year-2021/projects/lua-hook-points - https://dlqs.dev/frr-gsoc-2021.html - Presentation at Netdev 0x15: https://www.youtube.com/watch?v=_8R1MYP7M48&t=1051s Thank you @dlqs! Thanks again to all contributors! Cheers, -- Jafar

1 0