FreeBSD 13.0-RELEASE-p4 I haven't been able to recreate this on anything other than a system with the Chelsio T6225-CR, but an IPv4 alias only (IPv6 aliases work fine) with a /32 netmask such as, 129.174.130.141/32, doesn't work, cc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000 options=6e80723<RXCSUM,TXCSUM,JUMBO_MTU,TSO4,TSO6,LRO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6,HWRXTSTMP,NOMAP> inet 129.174.130.140 netmask 0xffffffe0 broadcast 129.174.130.159 inet 129.174.130.141 netmask 0xffffffff broadcast 129.174.130.141 PING 129.174.130.141 (129.174.130.141): 56 data bytes ping: sendto: No route to host But change the netmask to /31 and the ping will work. ifconfig_cc0="inet 129.174.130.140/27 mtu 9000" ifconfig_cc0_alias0="inet 129.174.130.141/32" Internet: Destination Gateway Flags Netif Expire 129.174.130.128/27 link#1 U cc0 129.174.130.140 link#1 UHS lo0 129.174.130.141 link#1 UH cc0 On FreeBSD 11.2 with an Intel interface it would have looked like, 129.174.130.128/27 link#1 U ix0 129.174.130.140 link#1 UHS lo0 129.174.130.141 link#1 UHS lo0 129.174.130.141/32 link#1 U ix0 t6nex0: <Chelsio T6225-CR> mem 0xdb200000-0xdb27ffff,0xda000000-0xdaffffff,0xdb684000-0xdb685fff irq 120 at device 0.4 on pci12 cc0: <port 0> on t6nex0 cc1: <port 1> on t6nex0 t6nex0: PCIe gen3 x8, 2 ports, 22 MSI-X interrupts, 70 eq, 21 iq
https://reviews.freebsd.org/D30811 was trying to restore the previous behavior of adding loopback route for aliases as same as stable/12 and previous releases, but @Lutz Donnerhacke mentioned that the current behavior is intended. > I'm surprised. There was a discussion about not redirecting /32 on interfaces to loopback. So we see the consequence. So we should check weather the hardware/logical interface correctly forward those packets destined for local.
IPv6 alias works differently then, Internet6: Destination Gateway Flags Netif Expire 2620:10e:6024:f004::/64 link#1 U cc0 2620:10e:6024:f004::140 link#1 UHS lo0 2620:10e:6024:f004::141 link#1 UHS lo0 because it is on the loopback.
(In reply to Jason Mader from comment #2) Can you please have a try to remove loopback route for IPv6 aliases? The aliases should be reachable.
(In reply to Zhenlei Huang from comment #3) I'm not sure what you mean, but I did this, and after removing a loopback route for IPv6 alias, Internet6: Destination Gateway Flags Netif Expire 2002::/16 ::1 UGRS lo0 2620:10e:6024:f004::/64 link#1 U ix0 2620:10e:6024:f004::140 link#1 UHS lo0 2620:10e:6024:f004::141 link#1 UHS lo0 # ping6 -c 1 2620:10e:6024:f004::141 PING6(56=40+8+8 bytes) 2620:10e:6024:f004::141 --> 2620:10e:6024:f004::141 16 bytes from 2620:10e:6024:f004::141, icmp_seq=0 hlim=64 time=0.041 ms --- 2620:10e:6024:f004::141 ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.041/0.041/0.041/0.000 ms # route -6 delete 2620:10e:6024:f004::141 delete host 2620:10e:6024:f004::141 # ping6 -c 1 2620:10e:6024:f004::141 ping6: UDP connect: No route to host
(In reply to Jason Mader from comment #4) Thanks for your report. That is exactly what I mean.
(In reply to Zhenlei Huang from comment #5) On FreeBSD 13.0 there is the sysctl, net.inet6.icmp6.nd6_useloopback: 1 but there is no IPv4 useloopback sysctl.
(In reply to Jason Mader from comment #6) Indeed there is sysctl `net.link.ether.inet.useloopback` since 4.4, but it was removed since stable/11. See https://cgit.freebsd.org/src/commit/sys?h=stable/11&id=b1b9dcae46803ae79255a9994584cb03d2a77048
@zlei So this seems like expected behavior? 13.0-R is no longer supported and I'm tentatively closing this as not a bug. Please reopen if you think there is a still a problem and it affects recent FreeBSD.
(In reply to Navdeep Parhar from comment #8) >@zlei So this seems like expected behavior? Yes currently. I have an immature idea that we completely remove the dependency on loopback interface (lo0), and use the flag `RTF_LOCAL` to indicate the route is for local. I'll post the draft to Phabricator after basic test.