Re: SSVM routing issue on /23 storage network

Granwille Strauss Tue, 28 Feb 2023 01:42:20 -0800

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>
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

--
Regards / Groete

<https://www.namhost.com>         Granwille Strauss  // Senior Systems Admin

*e:* granwi...@namhost.com
*m:* +264 81 323 1260 <tel:+264813231260>
*w:* www.namhost.com <https://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

smime.p7s
Description: S/MIME Cryptographic Signature

Re: SSVM routing issue on /23 storage network

Reply via email to