May 2024 - frog - lists.frrouting.org

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

MAC Flapping With VRRP on Linux
by Alasdair Muckart 19 May '24

19 May '24

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.

1 0

/etc vs /usr/local/etc
by Randy Bush 16 May '24

16 May '24

frr n00b here setting up frr as a debian12 amd64 kvm image. and it was working from the packaged binary. cool beans. except i run is-is, which means i had to build from source (which jammed on `rtrlib` needing a version of `libssh` i still need to find. but i disabled rpki <blush>), and completed the build and install on branch `stable/10.0`. it blows chunks on start cannot run start: /usr/local/etc/frr/daemons does not exist the binary package for deb12 put configs in `/etc/frr`, not `/usr/local/etc/frr`, and that's kinda the debian way. (yes, i used to love freebsd, but ...) a bit of poking finds that it installed and expects `/usr/local/...` for everything. and i see no `./configure` option to set `PREFIX`. so i hack `./configure` - ac_default_prefix=/usr/local + ac_default_prefix= it builds and installs, but then i find myself at the top of what looks like a much deeper rabbit hole. frr.service: Failed to locate executable /usr/local/sbin/frrinit.sh: No such file or directory clue bat appreciated. randy

2 5

FRR support for "IPv6 over SRv6 Core"
by Balazs Varga 16 May '24

16 May '24

Hi, FRR seems to support only “Transposition Scheme” of RFC9252. Sure, that is enough for L3VPN, but not an option for “vrf default” i.e., the global routing table. Does FRR support RFC9252, Section 5.4. Global IPv6 over SRv6 Core? Many thanks Bala'zs

1 0

IS-IS unnumbered support for IPv4?
by Hendrik Visage 15 May '24

15 May '24

Trying to use (similar to OpenFabric) IS-IS with unnumbered interfaces. The problem is that the IPv6 loopbacks are propagated, but the IPv4 loopbacks aren't, contrary to Openfabric, without IPs on the interfaces see below I've searched high and low, and couldn't find any setting I've missed, and the source code haven't been too help full to see/understand if I'm missing something or if the needed haven't been coded into IS-IS yet. ``` Current configuration: ! frr version 10.0 frr defaults datacenter hostname margherita log syslog informational service integrated-vtysh-config ! interface enp67s0f1 ip router isis 1 ipv6 router isis 1 isis csnp-interval 2 isis hello-interval 1 isis hello-multiplier 2 isis network point-to-point exit ! interface enp67s0f2 ip router isis 1 ipv6 router isis 1 isis csnp-interval 2 isis hello-interval 1 isis hello-multiplier 2 isis network point-to-point exit ! interface enp67s0f3 ip router isis 1 ipv6 router isis 1 isis csnp-interval 2 isis hello-interval 1 isis hello-multiplier 2 isis network point-to-point exit ! interface lo ip address 10.4.127.1/32 ip router isis 1 ipv6 address 2c0f:dead:beef:feed:2:0:4:1/128 ipv6 router isis 1 isis passive exit ! router isis 1 is-type level-1 net 49.1004.feed.feed.0004.0001.00 lsp-timers gen-interval 1 refresh-interval 180 max-lifetime 600 redistribute ipv4 connected level-1 redistribute ipv6 connected level-1 topology ipv4-multicast topology ipv4-mgmt topology ipv6-unicast topology ipv6-multicast topology ipv6-mgmt topology ipv6-dstsrc log-adjacency-changes exit ! end ``` ``` root@margherita:~# vtysh -c "show isis route" Area 1: IS-IS paths to level-1 routers that speak IP Vertex Type Metric Next-Hop Interface Parent margherita 10.4.127.1/32 IP internal 0 margherita(4) pu.bl.ic1.0/24 IP internal 0 margherita(4) IS-IS L1 IPv4 routing table: Prefix Metric Interface Nexthop Label(s) ------------------------------------------------------- 10.4.127.1/32 0 - - - pu.bl.ic1.0/24 0 - - - IS-IS paths to level-1 routers that speak IPv6 Vertex Type Metric Next-Hop Interface Parent margherita 2c0f:dead:beef:feed:2:0:4:1/128 IP6 internal 0 margherita(4) quesadilla TE-IS 10 quesadilla enp67s0f1 margherita(4) guacamole TE-IS 10 guacamole enp67s0f2 margherita(4) tequila TE-IS 10 tequila enp67s0f3 margherita(4) 2c0f:dead:beef:feed:2:0:4:2/128 IP6 internal 10 quesadilla enp67s0f1 quesadilla(4) 2c0f:dead:beef:feed:2:0:4:3/128 IP6 internal 10 guacamole enp67s0f2 guacamole(4) 2c0f:dead:beef:feed:2:0:4:4/128 IP6 internal 10 tequila enp67s0f3 tequila(4) IS-IS L1 IPv6 routing table: Prefix Metric Interface Nexthop Label(s) ---------------------------------------------------------------------------------------- 2c0f:dead:beef:feed:2:0:4:1/128 0 - - - 2c0f:dead:beef:feed:2:0:4:2/128 10 enp67s0f1 fe80::7777:55ff:fe31:6648 - 2c0f:dead:beef:feed:2:0:4:3/128 10 enp67s0f2 fe80::7777:55ff:fe31:6664 - 2c0f:dead:beef:feed:2:0:4:4/128 10 enp67s0f3 fe80::7777:55ff:fe31:663c - IS-IS paths to level-1 routers that support IPv6 dst-src routing Vertex Type Metric Next-Hop Interface Parent margherita quesadilla TE-IS 10 quesadilla enp67s0f1 margherita(4) guacamole TE-IS 10 guacamole enp67s0f2 margherita(4) tequila TE-IS 10 tequila enp67s0f3 margherita(4) IS-IS L1 IPv6 (dst-src routing) routing table: ``` adding the "loopback" IP to all connected interfaces: ``` root@margherita:~# for i in 0 1 2 3; do ip a add dev enp67s0f$i 10.4.127.1 ;done root@margherita:~# vtysh -c "show isis route" Area 1: IS-IS paths to level-1 routers that speak IP Vertex Type Metric Next-Hop Interface Parent margherita 10.4.127.1/32 IP internal 0 margherita(4) pu.bli.c1.0/24 IP internal 0 margherita(4) quesadilla TE-IS 10 quesadilla enp67s0f1 margherita(4) guacamole TE-IS 10 guacamole enp67s0f2 margherita(4) tequila TE-IS 10 tequila enp67s0f3 margherita(4) 10.4.127.2/32 IP TE 10 quesadilla enp67s0f1 quesadilla(4) pu.bli.c1.0/24 IP TE 10 quesadilla enp67s0f1 quesadilla(4) guacamole enp67s0f2 guacamole(4) tequila enp67s0f3 tequila(4) 10.4.127.3/32 IP TE 10 guacamole enp67s0f2 guacamole(4) 10.4.127.4/32 IP TE 10 tequila enp67s0f3 tequila(4) IS-IS L1 IPv4 routing table: Prefix Metric Interface Nexthop Label(s) ---------------------------------------------------------- 10.4.127.1/32 0 - - - 10.4.127.2/32 10 enp67s0f1 10.4.127.2 - 10.4.127.3/32 10 enp67s0f2 10.4.127.3 - 10.4.127.4/32 10 enp67s0f3 10.4.127.4 - pu.bli.c1.0/24 10 enp67s0f1 10.4.127.2 - enp67s0f2 10.4.127.3 - enp67s0f3 10.4.127.4 - IS-IS paths to level-1 routers that speak IPv6 Vertex Type Metric Next-Hop Interface Parent margherita 2c0f:dead:beef:feed:2:0:4:1/128 IP6 internal 0 margherita(4) quesadilla TE-IS 10 quesadilla enp67s0f1 margherita(4) guacamole TE-IS 10 guacamole enp67s0f2 margherita(4) tequila TE-IS 10 tequila enp67s0f3 margherita(4) 2c0f:dead:beef:feed:2:0:4:2/128 IP6 internal 10 quesadilla enp67s0f1 quesadilla(4) 2c0f:dead:beef:feed:2:0:4:3/128 IP6 internal 10 guacamole enp67s0f2 guacamole(4) 2c0f:dead:beef:feed:2:0:4:4/128 IP6 internal 10 tequila enp67s0f3 tequila(4) IS-IS L1 IPv6 routing table: Prefix Metric Interface Nexthop Label(s) ---------------------------------------------------------------------------------------- 2c0f:dead:beef:feed:2:0:4:1/128 0 - - - 2c0f:dead:beef:feed:2:0:4:2/128 10 enp67s0f1 fe80::7777:55ff:fe31:6648 - 2c0f:dead:beef:feed:2:0:4:3/128 10 enp67s0f2 fe80::7777:55ff:fe31:6664 - 2c0f:dead:beef:feed:2:0:4:4/128 10 enp67s0f3 fe80::7777:55ff:fe31:663c - IS-IS paths to level-1 routers that support IPv6 dst-src routing Vertex Type Metric Next-Hop Interface Parent margherita quesadilla TE-IS 10 quesadilla enp67s0f1 margherita(4) guacamole TE-IS 10 guacamole enp67s0f2 margherita(4) tequila TE-IS 10 tequila enp67s0f3 margherita(4) IS-IS L1 IPv6 (dst-src routing) routing table: root@margherita:~# ```

1 0

Isn't ospf ban an ABR to flood lsa3 to a non-backbone area?
by chan alfie 09 May '24

09 May '24

hi community, I got some confused of ospf lsa3. topology: h1 -- r1 --a12-- r2 --a0-- r3 --a34-- r4 -- h4 | | +---a23 ---+ I am using mininet to emulate the above environment. Here are the topo desc: area 12: r1(intf:r1r2) and r2(intf:r2r1) , connected network: 10.0.12.0/30 area 0: r2(intf:r20r30) and r3(intf:r30r20), connected network: 10.0.23.0/30 area 23: r2(intf:r2r3) and r3(intf:r3r2), connected network: 10.0.23.4/30 area 34: r3(intf:r3r4) and r4(intf:r4r3), connected network: 10.0.34.0/30 r1 has a stub net: 10.0.1.0/254, connected to a host, h1 r4 has a stub net: 10.0.4.0/254, connected to a host, h4 my question is: why r2/r3 generated lsa3 and advertise on area 23, isn't it prohibited ABR to flood lsa3 to non-backbone area? r2 ``` # show ip ospf database Summary Link States (Area 0.0.0.23) Link ID ADV Router Age Seq# CkSum Route 10.0.0.1 10.0.0.2 448 0x80000001 0xdc5f 10.0.0.1/32 10.0.0.1 10.0.0.3 449 0x80000001 0x3bf5 10.0.0.1/32 10.0.0.2 10.0.0.2 498 0x80000001 0x6ed6 10.0.0.2/32 10.0.0.2 10.0.0.3 449 0x80000001 0xcc6d 10.0.0.2/32 10.0.0.3 10.0.0.2 448 0x80000001 0xc871 10.0.0.3/32 10.0.0.3 10.0.0.3 498 0x80000001 0x5ee4 10.0.0.3/32 10.0.0.4 10.0.0.2 128 0x80000001 0x230c 10.0.0.4/32 10.0.0.4 10.0.0.3 129 0x80000001 0xb87f 10.0.0.4/32 10.0.1.0 10.0.0.2 448 0x80000001 0x40f1 10.0.1.0/24 10.0.1.0 10.0.0.3 449 0x80000001 0x9e88 10.0.1.0/24 10.0.4.0 10.0.0.2 128 0x80000001 0x83a1 10.0.4.0/24 10.0.4.0 10.0.0.3 129 0x80000001 0x1915 10.0.4.0/24 10.0.12.0 10.0.0.2 498 0x80000001 0x50e3 10.0.12.0/30 10.0.12.0 10.0.0.3 449 0x80000001 0xae7a 10.0.12.0/30 10.0.23.0 10.0.0.2 498 0x80000001 0xd652 10.0.23.0/30 10.0.23.0 10.0.0.3 498 0x80000001 0xd057 10.0.23.0/30 10.0.34.0 10.0.0.2 448 0x80000001 0xc152 10.0.34.0/30 10.0.34.0 10.0.0.3 498 0x80000001 0x57c5 10.0.34.0/30 ``` any idea?

2 2

Slack invites?
by Hendrik Visage 07 May '24

07 May '24

Good day, The invite system seems to be limiting access only to a set of domains, and requesting access, seems to have a continuous loop only allowing certain domains and telling to contact the slack admin?

5 5