You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Rafael del Valle <rv...@privaz.io.INVALID> on 2021/03/24 09:33:17 UTC
Re: RE: Virutal Router MTU
Hi Alex,
In our particular use case the Public Network is an SD WAN and we have a requirement of slightly smaller MTU than the standard 1500.
I have assumed that our traffic will be encapsulated into something else before delivery, I guess that is the reason for the requirement.
What would be the easier way to add support for MTU tunning on VRs?
I would be to contribute and implement it.
Regards,
On Wed, 2021-03-24 09:39 AM, Alex Mattioli <Al...@shapeblue.com> wrote:
>
Hi R,
>
> There's no ACS setting for the VR's MTU size.
> Unless you are running storage traffic s in that network then jumbo frames aren't of much use. I've ran some tests at the request of some customers in my previous job, and with some very busy VRs and the performance gains for an MTU of 9000 were statistically insignificant.
> If your VRs are saturated your best option is to increase the resources for its offering (if you need guidance with that, am happy to provide it)
>
> Anyway, what's your use case for jumbo frames?
>
> Regards,
> Alex
>
> Alex.Mattioli@shapeblue.com
> http://www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> -----Original Message-----
> From: rvalle@privaz.io.INVALID " target="_blank"><rv...@privaz.io.INVALID>
> Sent: 24 March 2021 09:23
> To: users@cloudstack.apache.org
> Subject: Virutal Router MTU
>
> Hi!
>
> I can see in the Global Parameters that it is possible to specify the MTU for secondary storage VM.
>
> Is it possible to configure the MTU for a virtual router? how?
>
> Regards,
> R.
>
RE: RE: RE: Virutal Router MTU
Posted by Alex Mattioli <Al...@shapeblue.com>.
Hi Rafael,
I've had very similar issues in the past, with SSL and TLS so playing well with fragmentation.
It is the same use case indeed, in that case I needed jumbo frames for a certain network.
I believe this should be implemented per-network, as a setting applied when the network is created (but editable and applied when the network is restarted with clean-up).
I'll consult with my colleagues what's the best way forward and get back to you.
Cheers,
Alex
From: Rafael del Valle <rv...@privaz.io>
Sent: 25 March 2021 09:06
To: Alex Mattioli <Al...@shapeblue.com>
Cc: dev@cloudstack.apache.org
Subject: Re: RE: RE: Virutal Router MTU
Hi Alex,
I have now found all the detail of the 1400 MTU past incident that lead us to patch OpenNuebula VRs.
The problem was detected because startTLS sessions failed in our email, persistently and to peers such as hotmail:
2019-01-26 14:58:06 +0000 02 9a1d30b6d6d1 SMTP-OUT:00000001: SSL error remote 104.47.13.33:25, SSL_connect:failed in SSLv2/v3 read server hello A
We investigated the issue together with the email platform vendor, and the problem persisted until we patched the MTU1400 issue.
So this is a must implement for us. A workaround exists: patch VRs and use cloud-init to customize NICs in VMs.
I am very happy to accept your collaboration offer :)
Where should this patch implemented?
It is actually a requirement of this VLAN (vlanIpRange) and propagates to Virtual Routers and NICs of the involved VMs.
Is it the same in your use-case of Jumbo frames for storage oriented networks?
Perhaps we should treat this setting just like a netmask or gateway setting.
Shall we open an issue?
Rafael
Alex.Mattioli@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
On Wed, 2021-03-24 11:08 AM, Alex Mattioli <Al...@shapeblue.com>> wrote:
Hi Raf,
Can you share with us which SDWAN vendor it is? I've tried 4 different ones with ACS and they all worked fine, in all cases what I did was to set the MTU in the SDWAN appliance to be a bit lower than 1500 (in between 1422 and 1460, depending on SDWAN solution). In most network you'll end up with most of your traffic with an MTU of around 500-600 anyway, so larger MTU doesn't help that much, I'd highly recommend you run some traffic analysis to try to figure out what's the MTU distribution for your network traffic.
With that said, I also had to change the MTU in VRs for a proof of concept on iSCSI between datacenters, in that situation I just wrote a script that would login to each VR and change the MTU of the public and private interfaces, it worked OK. I would strongly advise you not to change the MTU of the management interface, when I did (by mistake) the VRs lost communication with the management server.
If you want to contribute by expanding cloudstack code to add a setting for VR MTU I'd be more than happy to collaborate with you on that.
Hope this helps.
Cheers,
Alex
Alex.Mattioli@shapeblue.com<ma...@shapeblue.com>
http://www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
-----Original Message-----
From: Rafael del Valle <rv...@privaz.io.INVALID><mailto:%3crvalle@privaz.io.INVALID%3e>
Sent: 24 March 2021 10:33
To: users@cloudstack.apache.org<ma...@cloudstack.apache.org>
Cc: users@cloudstack.apache.org<ma...@cloudstack.apache.org>; dev@cloudstack.apache.org<ma...@cloudstack.apache.org>
Subject: Re: RE: Virutal Router MTU
Hi Alex,
In our particular use case the Public Network is an SD WAN and we have a requirement of slightly smaller MTU than the standard 1500.
I have assumed that our traffic will be encapsulated into something else before delivery, I guess that is the reason for the requirement.
What would be the easier way to add support for MTU tunning on VRs?
I would be to contribute and implement it.
Regards,
On Wed, 2021-03-24 09:39 AM, Alex Mattioli <Al...@shapeblue.com><mailto:%3cAlex.Mattioli@shapeblue.com%3e> wrote:
>
Hi R,
>
> There's no ACS setting for the VR's MTU size.
> Unless you are running storage traffic s in that network then jumbo frames aren't of much use. I've ran some tests at the request of some customers in my previous job, and with some very busy VRs and the performance gains for an MTU of 9000 were statistically insignificant.
> If your VRs are saturated your best option is to increase the
> resources for its offering (if you need guidance with that, am happy
> to provide it)
>
> Anyway, what's your use case for jumbo frames?
>
> Regards,
> Alex
>
> Alex.Mattioli@shapeblue.com<ma...@shapeblue.com>
> http://www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> -----Original Message-----
> From: rvalle@privaz.io.INVALID<ma...@privaz.io.INVALID> "
> target="_blank"><rv...@privaz.io.INVALID><mailto:%3crvalle@privaz.io.INVALID%3e>
> Sent: 24 March 2021 09:23
> To: users@cloudstack.apache.org<ma...@cloudstack.apache.org>
> Subject: Virutal Router MTU
>
> Hi!
>
> I can see in the Global Parameters that it is possible to specify the MTU for secondary storage VM.
>
> Is it possible to configure the MTU for a virtual router? how?
>
> Regards,
> R.
>
RE: RE: RE: Virutal Router MTU
Posted by Alex Mattioli <Al...@shapeblue.com>.
Hi Rafael,
I've had very similar issues in the past, with SSL and TLS so playing well with fragmentation.
It is the same use case indeed, in that case I needed jumbo frames for a certain network.
I believe this should be implemented per-network, as a setting applied when the network is created (but editable and applied when the network is restarted with clean-up).
I'll consult with my colleagues what's the best way forward and get back to you.
Cheers,
Alex
From: Rafael del Valle <rv...@privaz.io>
Sent: 25 March 2021 09:06
To: Alex Mattioli <Al...@shapeblue.com>
Cc: dev@cloudstack.apache.org
Subject: Re: RE: RE: Virutal Router MTU
Hi Alex,
I have now found all the detail of the 1400 MTU past incident that lead us to patch OpenNuebula VRs.
The problem was detected because startTLS sessions failed in our email, persistently and to peers such as hotmail:
2019-01-26 14:58:06 +0000 02 9a1d30b6d6d1 SMTP-OUT:00000001: SSL error remote 104.47.13.33:25, SSL_connect:failed in SSLv2/v3 read server hello A
We investigated the issue together with the email platform vendor, and the problem persisted until we patched the MTU1400 issue.
So this is a must implement for us. A workaround exists: patch VRs and use cloud-init to customize NICs in VMs.
I am very happy to accept your collaboration offer :)
Where should this patch implemented?
It is actually a requirement of this VLAN (vlanIpRange) and propagates to Virtual Routers and NICs of the involved VMs.
Is it the same in your use-case of Jumbo frames for storage oriented networks?
Perhaps we should treat this setting just like a netmask or gateway setting.
Shall we open an issue?
Rafael
Alex.Mattioli@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
On Wed, 2021-03-24 11:08 AM, Alex Mattioli <Al...@shapeblue.com>> wrote:
Hi Raf,
Can you share with us which SDWAN vendor it is? I've tried 4 different ones with ACS and they all worked fine, in all cases what I did was to set the MTU in the SDWAN appliance to be a bit lower than 1500 (in between 1422 and 1460, depending on SDWAN solution). In most network you'll end up with most of your traffic with an MTU of around 500-600 anyway, so larger MTU doesn't help that much, I'd highly recommend you run some traffic analysis to try to figure out what's the MTU distribution for your network traffic.
With that said, I also had to change the MTU in VRs for a proof of concept on iSCSI between datacenters, in that situation I just wrote a script that would login to each VR and change the MTU of the public and private interfaces, it worked OK. I would strongly advise you not to change the MTU of the management interface, when I did (by mistake) the VRs lost communication with the management server.
If you want to contribute by expanding cloudstack code to add a setting for VR MTU I'd be more than happy to collaborate with you on that.
Hope this helps.
Cheers,
Alex
Alex.Mattioli@shapeblue.com<ma...@shapeblue.com>
http://www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
-----Original Message-----
From: Rafael del Valle <rv...@privaz.io.INVALID><mailto:%3crvalle@privaz.io.INVALID%3e>
Sent: 24 March 2021 10:33
To: users@cloudstack.apache.org<ma...@cloudstack.apache.org>
Cc: users@cloudstack.apache.org<ma...@cloudstack.apache.org>; dev@cloudstack.apache.org<ma...@cloudstack.apache.org>
Subject: Re: RE: Virutal Router MTU
Hi Alex,
In our particular use case the Public Network is an SD WAN and we have a requirement of slightly smaller MTU than the standard 1500.
I have assumed that our traffic will be encapsulated into something else before delivery, I guess that is the reason for the requirement.
What would be the easier way to add support for MTU tunning on VRs?
I would be to contribute and implement it.
Regards,
On Wed, 2021-03-24 09:39 AM, Alex Mattioli <Al...@shapeblue.com><mailto:%3cAlex.Mattioli@shapeblue.com%3e> wrote:
>
Hi R,
>
> There's no ACS setting for the VR's MTU size.
> Unless you are running storage traffic s in that network then jumbo frames aren't of much use. I've ran some tests at the request of some customers in my previous job, and with some very busy VRs and the performance gains for an MTU of 9000 were statistically insignificant.
> If your VRs are saturated your best option is to increase the
> resources for its offering (if you need guidance with that, am happy
> to provide it)
>
> Anyway, what's your use case for jumbo frames?
>
> Regards,
> Alex
>
> Alex.Mattioli@shapeblue.com<ma...@shapeblue.com>
> http://www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> -----Original Message-----
> From: rvalle@privaz.io.INVALID<ma...@privaz.io.INVALID> "
> target="_blank"><rv...@privaz.io.INVALID><mailto:%3crvalle@privaz.io.INVALID%3e>
> Sent: 24 March 2021 09:23
> To: users@cloudstack.apache.org<ma...@cloudstack.apache.org>
> Subject: Virutal Router MTU
>
> Hi!
>
> I can see in the Global Parameters that it is possible to specify the MTU for secondary storage VM.
>
> Is it possible to configure the MTU for a virtual router? how?
>
> Regards,
> R.
>
Re: RE: RE: Virutal Router MTU
Posted by Rafael del Valle <rv...@privaz.io.INVALID>.
Hi Alex,
I have now found all the detail of the 1400 MTU past incident that lead us to patch OpenNuebula VRs.
The problem was detected because startTLS sessions failed in our email, persistently and to peers such as hotmail:
2019-01-26
14:58:06 +0000 02 9a1d30b6d6d1 SMTP-OUT:00000001: SSL error remote
104.47.13.33:25, SSL_connect:failed in SSLv2/v3 read server hello A
We investigated the issue together with the email platform vendor, and the problem persisted until we patched the MTU1400 issue.
So this is a must implement for us. A workaround exists: patch VRs and use cloud-init to customize NICs in VMs.
I am very happy to accept your collaboration offer :)
Where should this patch implemented?
It is actually a requirement of this VLAN (vlanIpRange) and propagates to Virtual Routers and NICs of the involved VMs.
Is it the same in your use-case of Jumbo frames for storage oriented networks?
Perhaps we should treat this setting just like a netmask or gateway setting.
Shall we open an issue?
Rafael
On Wed, 2021-03-24 11:08 AM, Alex Mattioli <Al...@shapeblue.com> wrote:
>
Hi Raf,
>
> Can you share with us which SDWAN vendor it is? I've tried 4 different ones with ACS and they all worked fine, in all cases what I did was to set the MTU in the SDWAN appliance to be a bit lower than 1500 (in between 1422 and 1460, depending on SDWAN solution). In most network you'll end up with most of your traffic with an MTU of around 500-600 anyway, so larger MTU doesn't help that much, I'd highly recommend you run some traffic analysis to try to figure out what's the MTU distribution for your network traffic.
>
> With that said, I also had to change the MTU in VRs for a proof of concept on iSCSI between datacenters, in that situation I just wrote a script that would login to each VR and change the MTU of the public and private interfaces, it worked OK. I would strongly advise you not to change the MTU of the management interface, when I did (by mistake) the VRs lost communication with the management server.
>
> If you want to contribute by expanding cloudstack code to add a setting for VR MTU I'd be more than happy to collaborate with you on that.
>
> Hope this helps.
>
> Cheers,
> Alex
>
>
> Alex.Mattioli@shapeblue.com
> http://www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> -----Original Message-----
> From: Rafael del Valle " target="_blank"><rv...@privaz.io.INVALID>
> Sent: 24 March 2021 10:33
> To: users@cloudstack.apache.org
> Cc: users@cloudstack.apache.org; dev@cloudstack.apache.org
> Subject: Re: RE: Virutal Router MTU
>
> Hi Alex,
>
> In our particular use case the Public Network is an SD WAN and we have a requirement of slightly smaller MTU than the standard 1500.
>
> I have assumed that our traffic will be encapsulated into something else before delivery, I guess that is the reason for the requirement.
>
> What would be the easier way to add support for MTU tunning on VRs?
>
> I would be to contribute and implement it.
>
> Regards,
>
>
>
>
>
> On Wed, 2021-03-24 09:39 AM, Alex Mattioli " target="_blank"><Al...@shapeblue.com> wrote:
> >
> Hi R,
> >
> > There's no ACS setting for the VR's MTU size.
> > Unless you are running storage traffic s in that network then jumbo frames aren't of much use. I've ran some tests at the request of some customers in my previous job, and with some very busy VRs and the performance gains for an MTU of 9000 were statistically insignificant.
> > If your VRs are saturated your best option is to increase the
> > resources for its offering (if you need guidance with that, am happy
> > to provide it)
> >
> > Anyway, what's your use case for jumbo frames?
> >
> > Regards,
> > Alex
> >
> > Alex.Mattioli@shapeblue.com
> > http://www.shapeblue.com
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
> >
> > -----Original Message-----
> > From: rvalle@privaz.io.INVALID "
> > target="_blank">" target="_blank"><rv...@privaz.io.INVALID>
> > Sent: 24 March 2021 09:23
> > To: users@cloudstack.apache.org
> > Subject: Virutal Router MTU
> >
> > Hi!
> >
> > I can see in the Global Parameters that it is possible to specify the MTU for secondary storage VM.
> >
> > Is it possible to configure the MTU for a virtual router? how?
> >
> > Regards,
> > R.
> >
>
Re: RE: RE: Virutal Router MTU
Posted by Rafael del Valle <rv...@privaz.io.INVALID>.
Hi Alex,
We are asked to set MTU 1400. I don't really know the particular vendor behind the SDWAN solution. I will ask.
I see your point. I will run some analysis and let you know what I see.
The thing is that in the past we run OpenNebula in this environment, we managed to ignore the requirement successfully for some time until we realized that networking issues required the setting.
I have reviewed my notes and I can only find a commit on some scripts stating its need and setting it. (a workaround similar to yours, to patch the VRs). But now I don't remember exactly which use case triggered the networking issues. Would be very nice to have an issue to reproduce.
I will look into this a bit more and get back to you.
Regards,
Rafael
OK I will let you know how it goes.
On Wed, 2021-03-24 11:08 AM, Alex Mattioli <Al...@shapeblue.com> wrote:
>
Hi Raf,
>
> Can you share with us which SDWAN vendor it is? I've tried 4 different ones with ACS and they all worked fine, in all cases what I did was to set the MTU in the SDWAN appliance to be a bit lower than 1500 (in between 1422 and 1460, depending on SDWAN solution). In most network you'll end up with most of your traffic with an MTU of around 500-600 anyway, so larger MTU doesn't help that much, I'd highly recommend you run some traffic analysis to try to figure out what's the MTU distribution for your network traffic.
>
> With that said, I also had to change the MTU in VRs for a proof of concept on iSCSI between datacenters, in that situation I just wrote a script that would login to each VR and change the MTU of the public and private interfaces, it worked OK. I would strongly advise you not to change the MTU of the management interface, when I did (by mistake) the VRs lost communication with the management server.
>
> If you want to contribute by expanding cloudstack code to add a setting for VR MTU I'd be more than happy to collaborate with you on that.
>
> Hope this helps.
>
> Cheers,
> Alex
>
>
> Alex.Mattioli@shapeblue.com
> http://www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> -----Original Message-----
> From: Rafael del Valle " target="_blank"><rv...@privaz.io.INVALID>
> Sent: 24 March 2021 10:33
> To: users@cloudstack.apache.org
> Cc: users@cloudstack.apache.org; dev@cloudstack.apache.org
> Subject: Re: RE: Virutal Router MTU
>
> Hi Alex,
>
> In our particular use case the Public Network is an SD WAN and we have a requirement of slightly smaller MTU than the standard 1500.
>
> I have assumed that our traffic will be encapsulated into something else before delivery, I guess that is the reason for the requirement.
>
> What would be the easier way to add support for MTU tunning on VRs?
>
> I would be to contribute and implement it.
>
> Regards,
>
>
>
>
>
> On Wed, 2021-03-24 09:39 AM, Alex Mattioli " target="_blank"><Al...@shapeblue.com> wrote:
> >
> Hi R,
> >
> > There's no ACS setting for the VR's MTU size.
> > Unless you are running storage traffic s in that network then jumbo frames aren't of much use. I've ran some tests at the request of some customers in my previous job, and with some very busy VRs and the performance gains for an MTU of 9000 were statistically insignificant.
> > If your VRs are saturated your best option is to increase the
> > resources for its offering (if you need guidance with that, am happy
> > to provide it)
> >
> > Anyway, what's your use case for jumbo frames?
> >
> > Regards,
> > Alex
> >
> > Alex.Mattioli@shapeblue.com
> > http://www.shapeblue.com
> > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> > @shapeblue
> >
> >
> >
> >
> > -----Original Message-----
> > From: rvalle@privaz.io.INVALID "
> > target="_blank">" target="_blank"><rv...@privaz.io.INVALID>
> > Sent: 24 March 2021 09:23
> > To: users@cloudstack.apache.org
> > Subject: Virutal Router MTU
> >
> > Hi!
> >
> > I can see in the Global Parameters that it is possible to specify the MTU for secondary storage VM.
> >
> > Is it possible to configure the MTU for a virtual router? how?
> >
> > Regards,
> > R.
> >
>
RE: RE: Virutal Router MTU
Posted by Alex Mattioli <Al...@shapeblue.com>.
Hi Raf,
Can you share with us which SDWAN vendor it is? I've tried 4 different ones with ACS and they all worked fine, in all cases what I did was to set the MTU in the SDWAN appliance to be a bit lower than 1500 (in between 1422 and 1460, depending on SDWAN solution). In most network you'll end up with most of your traffic with an MTU of around 500-600 anyway, so larger MTU doesn't help that much, I'd highly recommend you run some traffic analysis to try to figure out what's the MTU distribution for your network traffic.
With that said, I also had to change the MTU in VRs for a proof of concept on iSCSI between datacenters, in that situation I just wrote a script that would login to each VR and change the MTU of the public and private interfaces, it worked OK. I would strongly advise you not to change the MTU of the management interface, when I did (by mistake) the VRs lost communication with the management server.
If you want to contribute by expanding cloudstack code to add a setting for VR MTU I'd be more than happy to collaborate with you on that.
Hope this helps.
Cheers,
Alex
Alex.Mattioli@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
-----Original Message-----
From: Rafael del Valle <rv...@privaz.io.INVALID>
Sent: 24 March 2021 10:33
To: users@cloudstack.apache.org
Cc: users@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Re: RE: Virutal Router MTU
Hi Alex,
In our particular use case the Public Network is an SD WAN and we have a requirement of slightly smaller MTU than the standard 1500.
I have assumed that our traffic will be encapsulated into something else before delivery, I guess that is the reason for the requirement.
What would be the easier way to add support for MTU tunning on VRs?
I would be to contribute and implement it.
Regards,
On Wed, 2021-03-24 09:39 AM, Alex Mattioli <Al...@shapeblue.com> wrote:
>
Hi R,
>
> There's no ACS setting for the VR's MTU size.
> Unless you are running storage traffic s in that network then jumbo frames aren't of much use. I've ran some tests at the request of some customers in my previous job, and with some very busy VRs and the performance gains for an MTU of 9000 were statistically insignificant.
> If your VRs are saturated your best option is to increase the
> resources for its offering (if you need guidance with that, am happy
> to provide it)
>
> Anyway, what's your use case for jumbo frames?
>
> Regards,
> Alex
>
> Alex.Mattioli@shapeblue.com
> http://www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> -----Original Message-----
> From: rvalle@privaz.io.INVALID "
> target="_blank"><rv...@privaz.io.INVALID>
> Sent: 24 March 2021 09:23
> To: users@cloudstack.apache.org
> Subject: Virutal Router MTU
>
> Hi!
>
> I can see in the Global Parameters that it is possible to specify the MTU for secondary storage VM.
>
> Is it possible to configure the MTU for a virtual router? how?
>
> Regards,
> R.
>
RE: RE: Virutal Router MTU
Posted by Alex Mattioli <Al...@shapeblue.com>.
Hi Raf,
Can you share with us which SDWAN vendor it is? I've tried 4 different ones with ACS and they all worked fine, in all cases what I did was to set the MTU in the SDWAN appliance to be a bit lower than 1500 (in between 1422 and 1460, depending on SDWAN solution). In most network you'll end up with most of your traffic with an MTU of around 500-600 anyway, so larger MTU doesn't help that much, I'd highly recommend you run some traffic analysis to try to figure out what's the MTU distribution for your network traffic.
With that said, I also had to change the MTU in VRs for a proof of concept on iSCSI between datacenters, in that situation I just wrote a script that would login to each VR and change the MTU of the public and private interfaces, it worked OK. I would strongly advise you not to change the MTU of the management interface, when I did (by mistake) the VRs lost communication with the management server.
If you want to contribute by expanding cloudstack code to add a setting for VR MTU I'd be more than happy to collaborate with you on that.
Hope this helps.
Cheers,
Alex
Alex.Mattioli@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
-----Original Message-----
From: Rafael del Valle <rv...@privaz.io.INVALID>
Sent: 24 March 2021 10:33
To: users@cloudstack.apache.org
Cc: users@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Re: RE: Virutal Router MTU
Hi Alex,
In our particular use case the Public Network is an SD WAN and we have a requirement of slightly smaller MTU than the standard 1500.
I have assumed that our traffic will be encapsulated into something else before delivery, I guess that is the reason for the requirement.
What would be the easier way to add support for MTU tunning on VRs?
I would be to contribute and implement it.
Regards,
On Wed, 2021-03-24 09:39 AM, Alex Mattioli <Al...@shapeblue.com> wrote:
>
Hi R,
>
> There's no ACS setting for the VR's MTU size.
> Unless you are running storage traffic s in that network then jumbo frames aren't of much use. I've ran some tests at the request of some customers in my previous job, and with some very busy VRs and the performance gains for an MTU of 9000 were statistically insignificant.
> If your VRs are saturated your best option is to increase the
> resources for its offering (if you need guidance with that, am happy
> to provide it)
>
> Anyway, what's your use case for jumbo frames?
>
> Regards,
> Alex
>
> Alex.Mattioli@shapeblue.com
> http://www.shapeblue.com
> 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
> @shapeblue
>
>
>
>
> -----Original Message-----
> From: rvalle@privaz.io.INVALID "
> target="_blank"><rv...@privaz.io.INVALID>
> Sent: 24 March 2021 09:23
> To: users@cloudstack.apache.org
> Subject: Virutal Router MTU
>
> Hi!
>
> I can see in the Global Parameters that it is possible to specify the MTU for secondary storage VM.
>
> Is it possible to configure the MTU for a virtual router? how?
>
> Regards,
> R.
>