The routes should use eth3 not eth1. Can you share the `/var/cache/cloud/cmdline` file in SSVM, and filter management-server.log by keyword `SecStorageSetupCommand` ?
-Wei On Tue, 28 Feb 2023 at 10:42, Granwille Strauss <granwi...@namhost.com.invalid> wrote: > I recently had a similar issue and now that I look at my routing tables, > storage goes via eth1 and not eth3. Full details on this here: > https://github.com/apache/cloudstack/issues/7244#issuecomment-1434755523 > This, therefore, also explains why I randomly got this error with my SSVM. > On 2/28/23 11:35, Daan Hoogland wrote: > > 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 <antoi...@haltondc.com> > <antoi...@haltondc.com> > 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 eth210.0.0.0/8 via 10.101.0.1 dev > eth110.91.0.0/23 via 10.101.0.1 dev eth110.91.6.0/24 via 10.101.0.1 dev > eth110.101.0.0/22 dev eth1 proto kernel scope link src > 10.101.3.25310.101.6.0/23 via 10.101.0.1 dev eth1148.59.36.48/28 dev eth2 > proto kernel scope link src 148.59.36.61169.254.0.0/16 dev eth0 proto kernel > scope link src 169.254.232.208172.16.0.0/12 via 10.101.0.1 dev > eth1192.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 > > > -- > Regards / Groete > > <https://www.namhost.com> Granwille Strauss // Senior Systems Admin > > *e:* granwi...@namhost.com > *m:* +264 81 323 1260 <+264813231260> > *w:* www.namhost.com > > <https://www.facebook.com/namhost> <https://twitter.com/namhost> > <https://www.instagram.com/namhostinternetservices/> > <https://www.linkedin.com/company/namhos> > <https://www.youtube.com/channel/UCTd5v-kVPaic_dguGur15AA> > > > <https://www.adsigner.com/v1/l/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818/banner> > > Namhost Internet Services (Pty) Ltd, > > 24 Black Eagle Rd, Hermanus, 7210, RSA > > > > The content of this message is confidential. If you have received it by > mistake, please inform us by email reply and then delete the message. It is > forbidden to copy, forward, or in any way reveal the contents of this > message to anyone without our explicit consent. The integrity and security > of this email cannot be guaranteed over the Internet. Therefore, the sender > will not be held liable for any damage caused by the message. For our full > privacy policy and disclaimers, please go to > https://www.namhost.com/privacy-policy > > [image: Powered by AdSigner] > <https://www.adsigner.com/v1/c/631091998d4670001fe43ec2/621c9b76c140bb001ed0f818> >
