RE: Port Forwarding in Network

[Bryan Tiang]

Hey Alex,

It’s exiting to hear this new features coming about, and that the VR 
performance will be improved as a result of pure routing.

We have a pain point right now where our VR is at 75% CPU when handling 200Mbps 
Internet Traffic. Probably because we have 50 Autoscale Groups within that 1 
VR… (VR is 4Core,4GB).

We have plans support 1Gb-5Gbps Internet Bandwidth within a single VR one day, 
but if it’s already at 75%… kinda worrying for us. So this is exciting.

I went through the design document and have few questions. Is this going to be 
a new network? Or can existing VPC networks upgrade to Routed Mode?

Since every VM will get to have its own Public IP, does it mean every VM can 
have its own firewall rules now?

Will this feature be available for Autoscale Groups? We are heavy users of it.

Regards,
Bryan
On 29 Aug 2024 at 4:22 AM +0800, Alex Mattioli , 
wrote:
> Hi Marty,
>
>
>
> Here's the documentation for Routed Mode and Simple Dynamic Routing, I did 
> the original design and my colleague @Wei Zhou 
> refined and implemented it.
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=306153967
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=315492858
>
> Cheers,
>
> Alex
>
>
>
>
>
>
>
> -Original Message-
> From: Marty Godsey 
> Sent: Wednesday, August 28, 2024 11:07 AM
> To: us...@cloudstack.apache.org
> Subject: Re: Port Forwarding in Network
>
>
>
> Thank you, Alex. I am excited about that addition. Even having the ability to 
> not have to NAT is very useful.
>
>
>
> Regards,
>
> Marty Godsey
>
> Rudio, LLC
>
>
>
> Book Time: https://calendly.com/rudio-martyg
>
> Support: 
> supp...@rudio.net>
>
> Ph: 859-328-1100
>
> The content of this email is intended for the person or entity to which it is 
> addressed only. This email may contain confidential information. If you are 
> not the person to whom this message is addressed, be aware that any use, 
> reproduction, or distribution of this message is strictly prohibited. If you 
> received this in error, please contact the sender and immediately delete this 
> email and any attachments.
>
>
>
>
>
> From: Alex Mattioli 
> mailto:alex.matti...@shapeblue.com>>
>
> Date: Tuesday, August 27, 2024 at 11:56 AM
>
> To: us...@cloudstack.apache.org 
> mailto:us...@cloudstack.apache.org>>
>
> Subject: RE: Port Forwarding in Network
>
> WARNING: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
>
>
>
>
>
> Hi Marty,
>
>
>
> There are two PRs in progress, one for Routed Mode for IPv4 in Isolated 
> Networks and VPCs and another for Simple Dynamic Route with BGP.
>
>
>
> With Routed Mode you'll be able to assign public IPs directly to VMs, this 
> should be ready for ACS 4.20, which will be routed via the ACS VR.
>
> This has been possible for IPv6 since ACS 4.17 and will work in a similar way 
> (with some differences) for IPv4. Here's a video explaining how it works for 
> IPv6: https://www.youtube.com/watch?v=UvCSmU1TjRY&t=1583s
>
>
>
> As mentioned before, if you want to skip the VR completely then you need to 
> use Shared Networks, but then end users can't deploy the networks themselves 
> without operator intervention.
>
>
>
> Cheers
>
> Alex
>
>
>
>
>
>
>
>
>
>
>
> -Original Message-
>
> From: Jayanth Babu A 
> mailto:jayanth.b...@nxtgen.com.INVALID>>
>
> Sent: Tuesday, August 27, 2024 10:27 AM
>
> To: us...@cloudstack.apache.org
>
> Subject: Re: Port Forwarding in Network
>
>
>
> Hi Marty,
>
> Please use Shared Networks [1].
>
>
>
> [1] 
> https://atpscan.global.hornetsecurity.com/?d=xMOwK4fYoexeGDaCItpovxDkoPdExpSMKaLuotztWEw&f=1X9ll9UDNTAUv9XEhAoS-oCZLIFMKLOf3SQZgHrZSZlrXbexUH8NtKLJCqQbeAYB&i=&k=bm7B&m=x1rGyep2ImM3kF-8P6y1JWh7yEkoCGNNgU8oyJkxPaALdf4b2xt3n4PE01uT1okjgB6Kw5tM2yIKoLpa6cjYlK58irpRbdjWYflteXydz9OVb4jJgpLPFwQzFkj2QYTn&n=qT4mJ0BYBeh6jAxOCD1hayLTVyupmjmzwzzkOhAmOF4z7wMla_tk04lc9D939Rfl&r=IVbx63cjnjXzXq_Sv0qS0mvAEousFhnYo0ONd_j_NKawfjzf9DWkEB-VcJALkcaL&s=40bdd3dc1b6d4512eb8828b1f28bd4d08a871934dab0ba463a647f6e5f009a36&u=https%3A%2F%2Fdocs.cloudstack.apache.org%2Fen%2Flatest%2Fadminguide%2Fnetworking.html%23shared-networks
>
>
>
> Thanks,
>
> Jayanth
>
>
>
> 
>
> From: Marty Godsey mailto:mar...@rudio.net>>
>
> Sent: Tuesday, August 27, 2024 6:38:12 pm
>
> To: us...@cloudstack.apache.org 
> mailto:us...@cloudstack.apache.org>>
>
> Subject: Re: Port Forwarding in Network
>
>
>
> This is what I went ahead and used.
>
>
>
> Has there been a feature request to create a way to directly provide a public 
> IP to an instance instead of using a VR?
>
>
>
> Regards,
>
> Marty Godsey
>
>
>

RE: Port Forwarding in Network

[Bryan Tiang]

Hi Alex and Wei Zhou,

Thanks for the input, so it seems this new feature is more beneficial for those 
who are currently using Shared Networks.

We have 50 AutoscaleGroups in a single VR because our company mainly 
distributes/broadcasts stock prices from multiple exchanges to public users, so 
lots of micro services that need to autoscale instantaneously when the markets 
suddenly spike/rally which can result in 1 - 10x traffic bursts.

However, most of our Autoscale Groups consists of API Gateways to route traffic 
to different network tiers and micro services. This is what takes up lots of 
Autoscale Groups.

We had to duplicate lots of API Gateway into multiple Autoscale Groups because 
the current feature only allows load balancing to 1 single port.

So this is more of a workaround for us to overcome the current Autoscale 
feature limitation.

I think something worth mentioning is that our Autoscale Group, load balances 
traffic to other Autoscale Groups.

For example:

Internet -> ASG LB (API GW) -> ASG LB (Microservice 1) -> Database

And in some cases, we have this as well:

Internet -> ASG LB (API GW) -> ASG LB (Microservice 1) -> ASG LB (Microservice 
2)-> Database

I guess makes the VR very busy.

Happy to share more, sounds like our use is bit extreme… but it works so far 
though. Its only the CPU Utilisation that’s concerning… (memory is always 
around 40% so not a bottleneck there)

Regards,
Bryan
On 29 Aug 2024 at 11:27 PM +0800, Alex Mattioli , 
wrote:
> Hi Bryan,
>
> What's your use case for 50 autoscale groups in 1 VR? When designing the 
> feature we never envisioned more than 2 or 3.
>
> In NAT mode you should be able to get some 3gpbs through the VR, in ROUTED 
> mode then some 6-7gbps. Those numbers do go down (considerably sometimes) 
> with the number of firewall rules, load balancing, etc... you have setup in 
> the network.
>
> You'll need to create new networks in ROUTED mode, there's no migration path 
> from NATTED mode to ROUTED mode.
>
> You definitely can allow all traffic in the firewall and setup firewall rules 
> in each individual VM.
>
> In this initial implementation there's no load balancer in ROUTED mode, so no 
> Autoscale groups. But it is definitely a possible improvement for future 
> versions.
>
> Cheers
> Alex
>
>
>
>
> -Original Message-
> From: Bryan Tiang 
> Sent: Thursday, August 29, 2024 11:11 AM
> To: us...@cloudstack.apache.org; us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: RE: Port Forwarding in Network
>
> Hey Alex,
>
> It’s exiting to hear this new features coming about, and that the VR 
> performance will be improved as a result of pure routing.
>
> We have a pain point right now where our VR is at 75% CPU when handling 
> 200Mbps Internet Traffic. Probably because we have 50 Autoscale Groups within 
> that 1 VR… (VR is 4Core,4GB).
>
> We have plans support 1Gb-5Gbps Internet Bandwidth within a single VR one 
> day, but if it’s already at 75%… kinda worrying for us. So this is exciting.
>
> I went through the design document and have few questions. Is this going to 
> be a new network? Or can existing VPC networks upgrade to Routed Mode?
>
> Since every VM will get to have its own Public IP, does it mean every VM can 
> have its own firewall rules now?
>
> Will this feature be available for Autoscale Groups? We are heavy users of it.
>
> Regards,
> Bryan
> On 29 Aug 2024 at 4:22 AM +0800, Alex Mattioli , 
> wrote:
> > Hi Marty,
> >
> >
> >
> > Here's the documentation for Routed Mode and Simple Dynamic Routing, I did 
> > the original design and my colleague @Wei 
> > Zhou refined and implemented it.
> >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=306153967
> >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=315492858
> >
> > Cheers,
> >
> > Alex
> >
> >
> >
> >
> >
> >
> >
> > -Original Message-
> > From: Marty Godsey 
> > Sent: Wednesday, August 28, 2024 11:07 AM
> > To: us...@cloudstack.apache.org
> > Subject: Re: Port Forwarding in Network
> >
> >
> >
> > Thank you, Alex. I am excited about that addition. Even having the ability 
> > to not have to NAT is very useful.
> >
> >
> >
> > Regards,
> >
> > Marty Godsey
> >
> > Rudio, LLC
> >
> >
> >
> > Book Time: https://calendly.com/rudio-martyg
> >
> > Support: 
> > supp...@rudio.net>
> >
> > Ph: 859-328-1100
> >
> > The content of this email is intended for the person or entity to which it 
> > is addressed only. This email may contain confidential information. If you 
> > are not the person to whom this message is addressed, be aware that any 
> > use, reproduction, or distribution of this message is strictly prohibited. 
> > If you received this in error, please contact the sender and immediately 
> > delete this email and any attachments.
> >
> >
> >
> >

Re: Port Forwarding in Network

[Bryan Tiang]

We update the VR offering to be 4 Core, 4GB. Its a single router setup atm but 
we’re going to make it redundant soon.

Also, we have a 3rd case which i forgot to mention.

Internet/Leased Line -> ASG LB (API GW) -> Private Gateway to another VPC 
within same zone -> ASG LB (Microservice 3) -> DB

This scenario is meant to route traffic from VPC A (API GW only) to many other 
customer VPCs.

Regards,
Bryan
On 30 Aug 2024 at 1:48 AM +0800, Wei ZHOU , wrote:
> Thanks for sharing. Interesting
>
> How many cpu and memory does you VR have ?
>
>
> -Wei
> On Thursday, August 29, 2024, Bryan Tiang  wrote:
>
> > Hi Alex and Wei Zhou,
> >
> > Thanks for the input, so it seems this new feature is more beneficial for
> > those who are currently using Shared Networks.
> >
> > We have 50 AutoscaleGroups in a single VR because our company mainly
> > distributes/broadcasts stock prices from multiple exchanges to public
> > users, so lots of micro services that need to autoscale instantaneously
> > when the markets suddenly spike/rally which can result in 1 - 10x traffic
> > bursts.
> >
> > However, most of our Autoscale Groups consists of API Gateways to route
> > traffic to different network tiers and micro services. This is what takes
> > up lots of Autoscale Groups.
> >
> > We had to duplicate lots of API Gateway into multiple Autoscale Groups
> > because the current feature only allows load balancing to 1 single port.
> >
> > So this is more of a workaround for us to overcome the current Autoscale
> > feature limitation.
> >
> > I think something worth mentioning is that our Autoscale Group, load
> > balances traffic to other Autoscale Groups.
> >
> > For example:
> >
> > Internet -> ASG LB (API GW) -> ASG LB (Microservice 1) -> Database
> >
> > And in some cases, we have this as well:
> >
> > Internet -> ASG LB (API GW) -> ASG LB (Microservice 1) -> ASG LB
> > (Microservice 2)-> Database
> >
> > I guess makes the VR very busy.
> >
> > Happy to share more, sounds like our use is bit extreme… but it works so
> > far though. Its only the CPU Utilisation that’s concerning… (memory is
> > always around 40% so not a bottleneck there)
> >
> > Regards,
> > Bryan
> > On 29 Aug 2024 at 11:27 PM +0800, Alex Mattioli <
> > alex.matti...@shapeblue.com>, wrote:
> > > Hi Bryan,
> > >
> > > What's your use case for 50 autoscale groups in 1 VR? When designing the
> > feature we never envisioned more than 2 or 3.
> > >
> > > In NAT mode you should be able to get some 3gpbs through the VR, in
> > ROUTED mode then some 6-7gbps. Those numbers do go down (considerably
> > sometimes) with the number of firewall rules, load balancing, etc... you
> > have setup in the network.
> > >
> > > You'll need to create new networks in ROUTED mode, there's no migration
> > path from NATTED mode to ROUTED mode.
> > >
> > > You definitely can allow all traffic in the firewall and setup firewall
> > rules in each individual VM.
> > >
> > > In this initial implementation there's no load balancer in ROUTED mode,
> > so no Autoscale groups. But it is definitely a possible improvement for
> > future versions.
> > >
> > > Cheers
> > > Alex
> > >
> > >
> > >
> > >
> > > -Original Message-
> > > From: Bryan Tiang 
> > > Sent: Thursday, August 29, 2024 11:11 AM
> > > To: us...@cloudstack.apache.org; us...@cloudstack.apache.org
> > > Cc: dev@cloudstack.apache.org
> > > Subject: RE: Port Forwarding in Network
> > >
> > > Hey Alex,
> > >
> > > It’s exiting to hear this new features coming about, and that the VR
> > performance will be improved as a result of pure routing.
> > >
> > > We have a pain point right now where our VR is at 75% CPU when handling
> > 200Mbps Internet Traffic. Probably because we have 50 Autoscale Groups
> > within that 1 VR… (VR is 4Core,4GB).
> > >
> > > We have plans support 1Gb-5Gbps Internet Bandwidth within a single VR
> > one day, but if it’s already at 75%… kinda worrying for us. So this is
> > exciting.
> > >
> > > I went through the design document and have few questions. Is this going
> > to be a new network? Or can existing VPC networks upgrade to Routed Mode?
> > >
> > > Since every VM will get to have its own Public IP, does it mean every VM
> > can have its own firewall rules now?
> > >
> > > Will this feature be available for Autoscale Groups? We are heavy users
> > of it.
> > >
> > > Regards,
> > > Bryan
> > > On 29 Aug 2024 at 4:22 AM +0800, Alex Mattioli <
> > alex.matti...@shapeblue.com>, wrote:
> > > > Hi Marty,
> > > >
> > > >
> > > >
> > > > Here's the documentation for Routed Mode and Simple Dynamic Routing, I
> > did the original design and my colleague @Wei Zhou > shapeblue.com> refined and implemented it.
> > > >
> > > > https://cwiki.apache.org/confluence/pages/viewpage.
> > action?pageId=306153967
> > > >
> > > > https://cwiki.apache.org/confluence/pages/viewpage.
> > action?pageId=315492858
> > > >
> > > > Cheers,
> > > >
> > > > Alex
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >

RE: Port Forwarding in Network

[Bryan Tiang]

Hey Alex

Noted on this, will look into it.

Whats the most expensive task in the VR? Load Balancing? Routing? NAT? ACL?

Regards,
Bryan
On 30 Aug 2024 at 7:27 PM +0800, Alex Mattioli , 
wrote:
> Hi Bryan,
>
> Indeed, your use case is extreme, I'd highly recommend using more networks 
> with less autoscale groups.
>
> On making the VRs redundant, that will take even more resources than 
> standalone routers and won't really give you much extra uptime.
>
> Regards,
> Alex
>
>
>
>
> -Original Message-
> From: Bryan Tiang 
> Sent: Thursday, August 29, 2024 9:09 PM
> To: us...@cloudstack.apache.org; us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: Port Forwarding in Network
>
> We update the VR offering to be 4 Core, 4GB. Its a single router setup atm 
> but we’re going to make it redundant soon.
>
> Also, we have a 3rd case which i forgot to mention.
>
> Internet/Leased Line -> ASG LB (API GW) -> Private Gateway to another VPC 
> within same zone -> ASG LB (Microservice 3) -> DB
>
> This scenario is meant to route traffic from VPC A (API GW only) to many 
> other customer VPCs.
>
> Regards,
> Bryan
> On 30 Aug 2024 at 1:48 AM +0800, Wei ZHOU , wrote:
> > Thanks for sharing. Interesting
> >
> > How many cpu and memory does you VR have ?
> >
> >
> > -Wei
> > On Thursday, August 29, 2024, Bryan Tiang  wrote:
> >
> > > Hi Alex and Wei Zhou,
> > >
> > > Thanks for the input, so it seems this new feature is more
> > > beneficial for those who are currently using Shared Networks.
> > >
> > > We have 50 AutoscaleGroups in a single VR because our company mainly
> > > distributes/broadcasts stock prices from multiple exchanges to
> > > public users, so lots of micro services that need to autoscale
> > > instantaneously when the markets suddenly spike/rally which can
> > > result in 1 - 10x traffic bursts.
> > >
> > > However, most of our Autoscale Groups consists of API Gateways to
> > > route traffic to different network tiers and micro services. This is
> > > what takes up lots of Autoscale Groups.
> > >
> > > We had to duplicate lots of API Gateway into multiple Autoscale
> > > Groups because the current feature only allows load balancing to 1 single 
> > > port.
> > >
> > > So this is more of a workaround for us to overcome the current
> > > Autoscale feature limitation.
> > >
> > > I think something worth mentioning is that our Autoscale Group, load
> > > balances traffic to other Autoscale Groups.
> > >
> > > For example:
> > >
> > > Internet -> ASG LB (API GW) -> ASG LB (Microservice 1) -> Database
> > >
> > > And in some cases, we have this as well:
> > >
> > > Internet -> ASG LB (API GW) -> ASG LB (Microservice 1) -> ASG LB
> > > (Microservice 2)-> Database
> > >
> > > I guess makes the VR very busy.
> > >
> > > Happy to share more, sounds like our use is bit extreme… but it
> > > works so far though. Its only the CPU Utilisation that’s concerning…
> > > (memory is always around 40% so not a bottleneck there)
> > >
> > > Regards,
> > > Bryan
> > > On 29 Aug 2024 at 11:27 PM +0800, Alex Mattioli <
> > > alex.matti...@shapeblue.com>, wrote:
> > > > Hi Bryan,
> > > >
> > > > What's your use case for 50 autoscale groups in 1 VR? When
> > > > designing the
> > > feature we never envisioned more than 2 or 3.
> > > >
> > > > In NAT mode you should be able to get some 3gpbs through the VR,
> > > > in
> > > ROUTED mode then some 6-7gbps. Those numbers do go down
> > > (considerably
> > > sometimes) with the number of firewall rules, load balancing, etc...
> > > you have setup in the network.
> > > >
> > > > You'll need to create new networks in ROUTED mode, there's no
> > > > migration
> > > path from NATTED mode to ROUTED mode.
> > > >
> > > > You definitely can allow all traffic in the firewall and setup
> > > > firewall
> > > rules in each individual VM.
> > > >
> > > > In this initial implementation there's no load balancer in ROUTED
> > > > mode,
> > > so no Autoscale groups. But it is definitely a possible improvement
> > > for future versions.
> > > >
> > > > Cheers
> > > > Alex
> > > >
> > > >
> > > >
> > > >
> > > > -Original Message-
> > > > From: Bryan Tiang 
> > > > Sent: Thursday, August 29, 2024 11:11 AM
> > > > To: us...@cloudstack.apache.org; us...@cloudstack.apache.org
> > > > Cc: dev@cloudstack.apache.org
> > > > Subject: RE: Port Forwarding in Network
> > > >
> > > > Hey Alex,
> > > >
> > > > It’s exiting to hear this new features coming about, and that the
> > > > VR
> > > performance will be improved as a result of pure routing.
> > > >
> > > > We have a pain point right now where our VR is at 75% CPU when
> > > > handling
> > > 200Mbps Internet Traffic. Probably because we have 50 Autoscale
> > > Groups within that 1 VR… (VR is 4Core,4GB).
> > > >
> > > > We have plans support 1Gb-5Gbps Internet Bandwidth within a single
> > > > VR
> > > one day, but if it’s already at 75%… kinda worrying for us. So this
> > > is exciting.
> > > >
> > > > I went through th

RE: Port Forwarding in Network

[Alex Mattioli]

I can't say for sure, but based on my experience with the VR and other 
networking devices I'd say it is (in order):

- NAT, (sNAT, dNAT, 1:1 NAT), by a fair margin
- Load Balancing
- Firewall/ACL
- Routing
- DHCP, DNS, UserData (those are very low cost)

VPN is also demanding, but is not used nearly as often as the rest.

Cheers
Alex


 


-Original Message-
From: Bryan Tiang  
Sent: 01 September 2024 21:48
To: us...@cloudstack.apache.org; us...@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: RE: Port Forwarding in Network

Hey Alex

Noted on this, will look into it.

Whats the most expensive task in the VR? Load Balancing? Routing? NAT? ACL?

Regards,
Bryan
On 30 Aug 2024 at 7:27 PM +0800, Alex Mattioli , 
wrote:
> Hi Bryan,
>
> Indeed, your use case is extreme, I'd highly recommend using more networks 
> with less autoscale groups.
>
> On making the VRs redundant, that will take even more resources than 
> standalone routers and won't really give you much extra uptime.
>
> Regards,
> Alex
>
>
>
>
> -Original Message-
> From: Bryan Tiang 
> Sent: Thursday, August 29, 2024 9:09 PM
> To: us...@cloudstack.apache.org; us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: Port Forwarding in Network
>
> We update the VR offering to be 4 Core, 4GB. Its a single router setup atm 
> but we’re going to make it redundant soon.
>
> Also, we have a 3rd case which i forgot to mention.
>
> Internet/Leased Line -> ASG LB (API GW) -> Private Gateway to another 
> VPC within same zone -> ASG LB (Microservice 3) -> DB
>
> This scenario is meant to route traffic from VPC A (API GW only) to many 
> other customer VPCs.
>
> Regards,
> Bryan
> On 30 Aug 2024 at 1:48 AM +0800, Wei ZHOU , wrote:
> > Thanks for sharing. Interesting
> >
> > How many cpu and memory does you VR have ?
> >
> >
> > -Wei
> > On Thursday, August 29, 2024, Bryan Tiang  wrote:
> >
> > > Hi Alex and Wei Zhou,
> > >
> > > Thanks for the input, so it seems this new feature is more 
> > > beneficial for those who are currently using Shared Networks.
> > >
> > > We have 50 AutoscaleGroups in a single VR because our company 
> > > mainly distributes/broadcasts stock prices from multiple exchanges 
> > > to public users, so lots of micro services that need to autoscale 
> > > instantaneously when the markets suddenly spike/rally which can 
> > > result in 1 - 10x traffic bursts.
> > >
> > > However, most of our Autoscale Groups consists of API Gateways to 
> > > route traffic to different network tiers and micro services. This 
> > > is what takes up lots of Autoscale Groups.
> > >
> > > We had to duplicate lots of API Gateway into multiple Autoscale 
> > > Groups because the current feature only allows load balancing to 1 single 
> > > port.
> > >
> > > So this is more of a workaround for us to overcome the current 
> > > Autoscale feature limitation.
> > >
> > > I think something worth mentioning is that our Autoscale Group, 
> > > load balances traffic to other Autoscale Groups.
> > >
> > > For example:
> > >
> > > Internet -> ASG LB (API GW) -> ASG LB (Microservice 1) -> Database
> > >
> > > And in some cases, we have this as well:
> > >
> > > Internet -> ASG LB (API GW) -> ASG LB (Microservice 1) -> ASG LB 
> > > (Microservice 2)-> Database
> > >
> > > I guess makes the VR very busy.
> > >
> > > Happy to share more, sounds like our use is bit extreme… but it 
> > > works so far though. Its only the CPU Utilisation that’s 
> > > concerning… (memory is always around 40% so not a bottleneck 
> > > there)
> > >
> > > Regards,
> > > Bryan
> > > On 29 Aug 2024 at 11:27 PM +0800, Alex Mattioli < 
> > > alex.matti...@shapeblue.com>, wrote:
> > > > Hi Bryan,
> > > >
> > > > What's your use case for 50 autoscale groups in 1 VR? When 
> > > > designing the
> > > feature we never envisioned more than 2 or 3.
> > > >
> > > > In NAT mode you should be able to get some 3gpbs through the VR, 
> > > > in
> > > ROUTED mode then some 6-7gbps. Those numbers do go down 
> > > (considerably
> > > sometimes) with the number of firewall rules, load balancing, etc...
> > > you have setup in the network.
> > > >
> > > > You'll need to create new networks in ROUTED mode, there's no 
> > > > migration
> > > path from NATTED mode to ROUTED mode.
> > > >
> > > > You definitely can allow all traffic in the firewall and setup 
> > > > firewall
> > > rules in each individual VM.
> > > >
> > > > In this initial implementation there's no load balancer in 
> > > > ROUTED mode,
> > > so no Autoscale groups. But it is definitely a possible 
> > > improvement for future versions.
> > > >
> > > > Cheers
> > > > Alex
> > > >
> > > >
> > > >
> > > >
> > > > -Original Message-
> > > > From: Bryan Tiang 
> > > > Sent: Thursday, August 29, 2024 11:11 AM
> > > > To: us...@cloudstack.apache.org; us...@cloudstack.apache.org
> > > > Cc: dev@cloudstack.apache.org
> > > > Subject: RE: Port Forwarding in Network
> > > >
> > > > Hey Alex,
> > > >
> > >