- frog - lists.frrouting.org

OSPF Hello Inteval on dead links
by Susanne Will 29 May '24

29 May '24

2 3

Re: [FROG] Migration scripts for FRR from Quagga
by Leonardo 24 May '24

24 May '24

I usually set up the hostname in vtysh.conf and it overrides the hostnames in frr.conf. ------------------------------------------------------------------------ Em 22/05/2024 20:33, Doug Tucker via frog escreveu: > The interesting thing is it did seem to read my zebra.conf, but > completely skipped the bgpd.conf. So I tried copying the contents of > the bgpd.conf into frr.conf and the daemon starts, and doing a show > run it looks pretty identical to quagga system side by side with a few > caveates (hostname for instance shows up twice with 2 different values).

1 0

OSPF Hello Interval on dead Links
by Susanne Will 24 May '24

24 May '24

3 2

Re: [FROG] MAC Flapping With VRRP on Linux
by Quentin Young 23 May '24

23 May '24

I'm glad you found a solution for your problem. If you would humor me, I'm still interested in your configuration, because the documentation doesn't mention any arp_ignore settings and if they are necessary I would like to document them. I find your setup interesting because I have a vague memory of similar deployments using VRRP on bonds and I don't recall needing to set those options. I am wondering if a kernel change happened, my memory is wrong, or if this really just is undocumented. If possible, could you send the results of: ip -d link showvrrp4-1-1@bond0 Thanks, Quentin On 5/19/24 8:03 PM, Alasdair Muckart via frog wrote: > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog

2 1

Re: [FROG] Configuring OSPF routing with not propagating docker routes
by Taavi Ansper 22 May '24

22 May '24

After my colleague added this line: network 192.168.2.48/32 area 0.0.0.0 The VM did not propagate the routes to others. My intention is not for any of the VM-s to become routers, but just for them to learn the routes for multiple gateways as I specified before. ---- Taavi Ansper taavi.ansper(a)cyber.ee On 22.05.24 14:40, Taavi Ansper via frog wrote: > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog

1 0

Re: [FROG] Configuring OSPF routing with not propagating docker routes
by Acee Lindem 22 May '24

22 May '24

Hi Taavi, I’m not sure what you are asking. If you want to form OSPF adjacencies on a network. the connecting interface cannot be passive as this solely advertises interface prefix in the Router-LSA - OSPF isn’t active on the interface. You can override the “default passive-interface” on an individual interface with the “no ip ospf passive” command on that interface. For example: interface r3-eth0 ip address 10.1.5.3/24 ip ospf dead-interval 30 ip ospf hello-interval 1 no ip ospf passive exit ! interface r3-eth1 ip address 10.1.6.3/24 ip ospf dead-interval 30 ip ospf hello-interval 1 no ip ospf passive exit ! interface r1-eth0 no ip ospf passive exit ! router ospf ospf router-id 3.3.3.3 passive-interface default network 10.1.5.0/24 area 0 network 10.1.6.0/24 area 1 distance 20 exit r3# show ip ospf neighbor Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL 2.2.2.2 1 Full/Backup 3m34s 29.414s 10.1.5.2 r3-eth0:10.1.5.3 0 0 0 2.2.2.2 1 Full/Backup 3m26s 29.414s 10.1.6.2 r3-eth1:10.1.6.3 0 0 0 Hope this helps, Acee > On May 22, 2024, at 04:18, Taavi Ansper via frog <frog(a)lists.frrouting.org> wrote: > > > From: Taavi Ansper <taavi.ansper(a)cyber.ee> > Subject: Configuring OSPF routing with not propagating docker routes > Date: May 22, 2024 at 04:18:15 EDT > To: frog(a)lists.frrouting.org > > > Hi > > (I also posted in the slack channel, sorry for cross-posting, don't know which one would be more active...) > > I am having a problem, where I have a core network, where I have a bunch of servers, but this network has two gateways, one for outbound connections on the same site and the second for an ipsec tunnel to another site, so if the local connection fails, it will route through the ipsec tunnel via the remote site.I have a problem with docker networks in this routing. As some of the hosts propagate these routes to other hosts and so If there is communication between a docker container and the host networking it tries to route through the network. This is the |frr.conf| file that is injected to the hosts. The RIP is legacy conf, as we moved from RIP to OSPF. As you can see we only have a single area, as we have a router on a stick topology, so we don't really need many areas. Currently the gitlab-test host cannot connect to the ospf network, because of the |passive-interface default| option, if I remove it, then it connects to the ospf area and now the docker routing also comes from other hosts. > > # Ansible managed # default to using syslog. /etc/rsyslog.d/45-frr.conf places the log in # /var/log/frr/frr.log # # Note: # FRR's configuration shell, vtysh, dynamically edits the live, in-memory # configuration while FRR is running. When instructed, vtysh will persist the # live configuration to this file, overwriting its contents. If you want to # avoid this, you can edit this file manually before starting FRR, or instruct # vtysh to write configuration to a different file. log syslog informational hostname gitlab-test password REDACTED enable password REDACTED # Router RIP configuration router rip distance 66 network 0.0.0.0/0 passive-interface default ! # Router OSPF configuration router ospf network 0.0.0.0/0 area 0.0.0.0 passive-interface default ospf router-id 10.0.8.43 ! # Network where this configuration is used. network enX0 ! # Interface options for interface found by ansible. interface enX0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 REDACTED ip ospf priority 0 ! > > > Can the host actually join the OSPF area if the passive-interface default is enabled? > > For example these routings are present that I do not want if I remove the passive-interface default and restart the frr.service: > > O 172.17.0.0/16 [110/10] is directly connected, docker0, weight 1, 00:01:06 O 172.18.0.0/16 [110/10] is directly connected, br-236817c46761, weight 1, 00:01:06 O>* 172.18.0.0/24 [110/20] via 192.168.2.25, enX0, weight 1, 00:00:46 O>* 172.19.0.0/16 [110/20] via 192.168.2.17, enX0, weight 1, 00:00:46 * via 192.168.2.44, enX0, weight 1, 00:00:46 Best regards > > -- > ---- > Taavi Ansper > taavi.ansper(a)cyber.ee > > > > > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog

2 1

Re: [FROG] Configuring OSPF routing with not propagating docker routes
by Taavi Ansper 22 May '24

22 May '24

Tested both adding not-advertise and distribute-list and these options did not help. router ospf network 0.0.0.0/0 area 0.0.0.0 ospf router-id A.B.C.D area 0.0.0.0 range 172.16.0.0/12 not-advertise distribute-list docker-filter out ! access-list docker-filter deny 172.16.0.0/12 ---- Taavi Ansper taavi.ansper(a)cyber.ee On 22.05.24 11:18, Taavi Ansper via frog wrote: > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog

1 0

Configuring OSPF routing with not propagating docker routes
by Taavi Ansper 22 May '24

22 May '24

Hi (I also posted in the slack channel, sorry for cross-posting, don't know which one would be more active...) I am having a problem, where I have a core network, where I have a bunch of servers, but this network has two gateways, one for outbound connections on the same site and the second for an ipsec tunnel to another site, so if the local connection fails, it will route through the ipsec tunnel via the remote site.I have a problem with docker networks in this routing. As some of the hosts propagate these routes to other hosts and so If there is communication between a docker container and the host networking it tries to route through the network. This is the |frr.conf| file that is injected to the hosts. The RIP is legacy conf, as we moved from RIP to OSPF. As you can see we only have a single area, as we have a router on a stick topology, so we don't really need many areas. Currently the gitlab-test host cannot connect to the ospf network, because of the |passive-interface default| option, if I remove it, then it connects to the ospf area and now the docker routing also comes from other hosts. # Ansible managed # default to using syslog. /etc/rsyslog.d/45-frr.conf places the log in # /var/log/frr/frr.log # # Note: # FRR's configuration shell, vtysh, dynamically edits the live, in-memory # configuration while FRR is running. When instructed, vtysh will persist the # live configuration to this file, overwriting its contents. If you want to # avoid this, you can edit this file manually before starting FRR, or instruct # vtysh to write configuration to a different file. log syslog informational hostname gitlab-test password REDACTED enable password REDACTED # Router RIP configuration router rip distance 66 network 0.0.0.0/0 passive-interface default ! # Router OSPF configuration router ospf network 0.0.0.0/0 area 0.0.0.0 passive-interface default ospf router-id 10.0.8.43 ! # Network where this configuration is used. network enX0 ! # Interface options for interface found by ansible. interface enX0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 REDACTED ip ospf priority 0 ! Can the host actually join the OSPF area if the passive-interface default is enabled? For example these routings are present that I do not want if I remove the passive-interface default and restart the frr.service: O 172.17.0.0/16 [110/10] is directly connected, docker0, weight 1, 00:01:06 O 172.18.0.0/16 [110/10] is directly connected, br-236817c46761, weight 1, 00:01:06 O>* 172.18.0.0/24 [110/20] via 192.168.2.25, enX0, weight 1, 00:00:46 O>* 172.19.0.0/16 [110/20] via 192.168.2.17, enX0, weight 1, 00:00:46 * via 192.168.2.44, enX0, weight 1, 00:00:46 Best regards -- ---- Taavi Ansper taavi.ansper(a)cyber.ee

1 0

Re: [FROG] MAC Flapping With VRRP on Linux
by Quentin Young 20 May '24

20 May '24

Can you share the output of `ip link show` on the device (just one of them is fine) exhibiting the arp behavior? I am especially interested in the macvlan devices. Quentin PS If you care to join our Slack, the higher bandwidth might prove more efficient for debugging. Whatever results of that conversation will be posted back to this list for posterity. On Sun, May 19, 2024, at 4:50 PM, Alasdair Muckart via frog wrote: > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog > > > *Attachments:* > • Email.eml

2 1

Re: [FROG] MAC Flapping With VRRP on Linux
by Alasdair Muckart 19 May '24

19 May '24

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 VRRP is configured in FRR, as per the manual. Interface addressing is applied by systemd-networkd. Except for priority, the configuration is the same on both routers. VRRP itself works fine and fails over as expected. interface bond0 description Bond to core switches vrrp 1 vrrp 1 priority 110 vrrp 1 ip 192.168.1.1 exit The problem is Linux's behaviour replying to ARP who-has. Given that FRR's VRRP implementation only works on Linux I'm assuming the correct combination of sysctls to make ARP behave is known, but it's not in the manual that I can see (yes, I checked the sysctl section too). Keepalived doesn't use the same virtual MAC mechanism as FRR, and I want to avoid it if at all possible. It does avoid this specific ARP problem but it's a lot harder to inspect the state of than running "show vrrp" in vtysh and I explicitly want an RFC compliant VRRP that uses a VRRP MAC. I also want to keep all of the configuration in one place, which FRR does. Hendrik Visage <hvjunk(a)gmail.com> writes: > What are you using for doing VRRP, and the configurations you've setup? > > I've been using keepalived to provide VRRP VIPs without this issue > before, so need more information on the configs etc. > > On Sun, May 19, 2024 at 12:33 PM Alasdair Muckart via frog > <frog(a)lists.frrouting.org> wrote: >> >> >> >> >> ---------- Forwarded message ---------- >> From: Alasdair Muckart <alasdairmuckart(a)catalyst.net.nz> >> To: frog(a)lists.frrouting.org >> Cc: >> Bcc: >> Date: Sun, 19 May 2024 21:36:22 +1200 >> Subject: MAC Flapping With VRRP on Linux >> Hello FRR folk, >> >> I'm having difficulty with traffic to linux (Ubuntu 22.04, kernel 5.15) >> routers running VRRP. The problem is MAC flapping between the VRRP MAC >> and the underlying interface MAC. It's so bad traffic from the LAN to >> the VIP is basically unusable. Every who-has for the VIP or the VRRP >> primary's underlying interface IP gets multiple responses, and the mac >> table on the switches is flailing. >> >> I've tried all the combinations of the various arp sysctl I can think of >> and I can't get one that will only respond to requests for the VIP with >> the VRRP MAC. Either I get duelling replies with both the VIP MAC and >> the underlying interface MAC, or I get nothing at all. >> >> Can anyone tell me what I need to do to get the routers to only reply >> with the VIP MAC when there's an arp who-has for the VIP? I couldn't >> see anything in the manual about this. >> >> TIA. >> >> >> In case it's relevant, the topology as follows: >> >> A pair of core switches connected by an ERPS ring. >> >> Two routers, each connected to both switches with an active/passive bond >> interface. >> >> VRRP running on the bond interface. The bond interfaces are .2 and .3, >> the VIP is .1. >> >> The eth0 and eth1 interfaces are unnumbered children of the bond0. >> >> 192.168.1.2/24 >> >> >> eth0 eth1 >> +-----------+bond0+-X----------+ >> | | | | >> | +--+-----+--+ | >> | | vrrp4-1-1 | | >> | +-----------+ | >> | 192.168.1.1/24 | >> | | >> +------+-----+ +------+-----+ >> | +-----------------+ | >> | SWITCH 1 | ERPS | SWITCH 2 | >> | +---------------X-+ | >> +------+-----+ +------+-----+ >> | | >> | | >> | +-----------+ | >> | | vrrp4-1-1 | | >> | +--+-----+--+ | >> | | | | >> +-----------+bond0+-X----------+ >> eth0 eth1 >> >> 192.168.1.3/24 >> >> I've got the bond0 interfaces because FRR doesn't seem to cope at all >> with having two interfaces in the same VRRP on the same router, one of >> them is permanently stuck 'initializing', but the MAC flapping is the >> same with just one interface and no bond. >> >> >> >> -- >> 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. >> >> >> >> >> ---------- Forwarded message ---------- >> From: Alasdair Muckart via frog <frog(a)lists.frrouting.org> >> To: frog(a)lists.frrouting.org >> Cc: >> Bcc: >> Date: Sun, 19 May 2024 21:36:22 +1200 >> Subject: [FROG] MAC Flapping With VRRP on Linux >> _______________________________________________ >> frog mailing list >> frog(a)lists.frrouting.org >> https://lists.frrouting.org/listinfo/frog - -- 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. -----BEGIN PGP SIGNATURE----- iQJUBAEBCgA+FiEEu4g3jwJ68cPCdgH9iBAgH4ERwwMFAmZKaJEgHGFsYXNkYWly bXVja2FydEBjYXRhbHlzdC5uZXQubnoACgkQiBAgH4ERwwN4yBAAlUN+S3wogjAV gTm69b4T3VLbEV1Fo+lHk0HFD+zhXgw2Ypb2yZigOkQfDkQFX7VPG8v7LsKljg5P 1ssb3kjie8VeoZ1yri3JSAvCxrov5CgtBeiI8vtftPnubhAzsh6IeiTu8IlqP72X O7UWVZY+PF6pY7h8hxoahZa2BBitevr9cLHpI7EhLX8TJedY6/UCS6Xn/IO1mpHG bqqjQnsanqBQKUq43GUHvdZylhVlHhrGqVyWuYeagoSqaDw5H7EtotQbfptyoVYu 8jeWwfg6Tfk5N+DViGSQ3qrxFKQFh8MtUksN2xU3oUaV99fmzR7HljYMJ8zhRS7O Dkwd3ZcCSM2hasEJBLPGOPfRwPLgS+lB+iHQ6yFTRt6GCOzt+axloo4vDZHf3p8X ysXOwO7Tq4L7zq5YqUoWevNcJZJ2qSXfbLzzZ/MB/+mfUgX5TqOsSgP5Be8rpoSq cpdmY//Ygow4x5HJ+k6LskJfQH/84x4q6E4Tlc8BwfEOXIk1R4IpwV1CNs2zZ1TN JelmHvlNfyxHz2PS/Cti8+L2mclr9Oj5kNCJVytJuIFqKLzRS7Cq+qEgKkI24+en ufH0o55n9n3lRGWZdisvDS/dqKzXJEEEWasTr2rv+b0okXXRgqGP6uYOoKcXZajj Ke6eg1BrEFTauPoOrv8MJN1x4ppfOjM= =+dwk -----END PGP SIGNATURE-----

1 0