does sound like a bug Antoine, I did the network calculation and it seems you are right. I wonder about the last two routes as well. did you do anything for those?
On Sun, Feb 26, 2023 at 9:47 PM Antoine Boucher <[email protected]> wrote: > Hello, > > I'm having a networking issue on SSVMs, I have the following networks > defined in “Zone 1”. > > Management: 10.101.0.0/22 > Storage: 10.101.6.0/23 > > All worked well until we decided to configure new storage devices on > 10.101.7.x, the hosts and management server have no issue but the SSVM is > not able to reach it. Here are the defined interfaces of the SSVM and the > routing table of the SSVM: > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group > default qlen 1000 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state > UP group default qlen 1000 > link/ether 0e:00:a9:fe:72:ec brd ff:ff:ff:ff:ff:ff > altname enp0s3 > altname ens3 > inet 169.254.114.236/16 brd 169.254.255.255 scope global eth0 > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state > UP group default qlen 1000 > link/ether 1e:00:a1:00:00:06 brd ff:ff:ff:ff:ff:ff > altname enp0s4 > altname ens4 > inet 10.101.3.205/22 brd 10.101.3.255 scope global eth1 > valid_lft forever preferred_lft forever > 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state > UP group default qlen 1000 > link/ether 1e:00:6b:00:00:3d brd ff:ff:ff:ff:ff:ff > altname enp0s5 > altname ens5 > inet 148.59.36.61/28 brd 148.59.36.63 scope global eth2 > valid_lft forever preferred_lft forever > 5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state > UP group default qlen 1000 > link/ether 1e:00:09:00:00:6b brd ff:ff:ff:ff:ff:ff > altname enp0s6 > altname ens6 > inet 10.101.7.226/23 brd 10.101.7.255 scope global eth3 > valid_lft forever preferred_lft forever > > default via 148.59.36.49 dev eth2 > 10.0.0.0/8 via 10.101.0.1 dev eth1 > 10.91.0.0/23 via 10.101.0.1 dev eth1 > 10.91.6.0/24 via 10.101.0.1 dev eth1 > 10.101.0.0/22 dev eth1 proto kernel scope link src 10.101.3.253 > 10.101.6.0/23 via 10.101.0.1 dev eth1 > 148.59.36.48/28 dev eth2 proto kernel scope link src 148.59.36.61 > 169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.232.208 > 172.16.0.0/12 via 10.101.0.1 dev eth1 > 192.168.0.0/16 via 10.101.0.1 dev eth1 > > Why is the routing for 10.101.6.0/23 routing via eth1, shoudn’nt it be > using eth3? The router seems to be bypassing the routing rules for > 10.101.6.x since I see no traffic going through the gateway but I see > traffic going through the gateway when the destination is 10.101.7.x > > If I modify the routing for 10.101.6.0/23 to eth3 all is well. > > Is this by design? > > Regards, > Antoine Boucher > -- Daan
