Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC networks

[Wido den Hollander]

Op 20/05/2024 om 14:45 schreef Alex Mattioli:

Hi Alex,

In this scenario:


I think adding the ability to add network specific peers as mentioned in one of 
>your prior replies would still allow the level of control some operators (myself 
>included) may desire.


How do you propose network specific peers to be implemented?



I do agree with Alex (Dietrich) that I think BGP peers should be 
configured per network. There is no guarantee that every VLAN/VNI 
(VXLAN) ends up at the same pair of routers. Technically there is also 
no need to do so.


Let's say I have two VNI (VXLAN):

VNI 500:
Router 1: 192.168.153.1 / 2001:db8::153:1
Router 2: 192.168.153.2 / 2001:db8::153:2

VNI 600:
Router 1: 192.168.155.1 / 2001:db8::155:1
Router 2: 192.168.155.2 / 2001:db8::155:2

In these case you would say that the upstream BGP peers are .153.1/2, 
.155.1/2 (and their IPv6 addresses). No need for BGP multihop.


Talking about multihop, I would make that optional, people might want to 
have two central BGP routers where each VR peers with (multihop) and 
those routers distribute the routes into the network again.


Per network you create you also provide the ASN range, but even better 
would be to refer to a pool. You can use one pool for your zone by 
referencing every network to the same pool are simply use multiple pools 
if your network requires so.


That said, you could also opt that you can specify BGP peers are peer 
level and override them at network level if one prefers. Nothing 
specified at the network? The zone-level peers are used. If you do 
specify them at the network level those are used. Again, think about 
multihop.


Wido


Regards
Alex


  



-Original Message-
From: Dietrich, Alex 
Sent: Monday, May 20, 2024 2:21 PM
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hi Alex,

This may be a difference in perspective in implementation of BGP at the tenant 
level. I see the ability this would provide to seamlessly establishing those 
peering relationships with minimal intervention (helping scalability).

I think adding the ability to add network specific peers as mentioned in one of 
your prior replies would still allow the level of control some operators 
(myself included) may desire.

Thanks,
Alex

[photo]

Alex Dietrich
Senior Network Engineer, US Signal

616-233-5094  |  www.ussignal.com  |  
adietr...@ussignal.com

201 Ionia Ave SW, Grand Rapids, MI 
49503

[linkedin]

[facebook]

[youtube]

IMPORTANT: The contents of this email are confidential. Information is intended 
for the named recipient(s) only. If you have received this email by mistake, 
please notify the sender immediately and do not disclose the contents to anyone 
or make copies thereof.

[__tpx__]
From: Alex Mattioli 
Date: Monday, May 20, 2024 at 7:51 AM
To: us...@cloudstack.apache.org , 
dev@cloudstack.apache.org 
Subject: RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks EXTERNAL

Hi Alex,


I am not convinced that specifying BGP peers at the zone level is a good idea 
given the impacts BGP can have on a given network. I would much rather see both 
peer and AS specification handled at the >network configuration, or another 
more specific level.


I don't see how else end users would be able to automatically create routed 
networks without intervention from the operator.


Cheers
Alex




-Original Message-
From: Dietrich, Alex 
Sent: Thursday, May 16, 2024 2:23 PM
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hello Alex,

I appreciate this back and forth as I am excited about the potential this 
feature would hold.


   *   This is a very valid point.  We could add network specific BGP peers as 
well, which would override the automatic AS allocation, in the same way that we 
now allocate DNS servers in the zone level but can override that by manually 
selecting different DNS servers at network creation time.  Would that address 
your point?

Why does the network specific BGP peers need to override automatic AS 
allocation? In my mind there isn’t a dependency that needs to exist to those 
two as they are somewhat independent of one another.

I am not convinced that specifying BGP peers at the zone level is a good idea 
given the impacts BGP can have on a given network. I would much rather see both 
peer and AS specification handled at the network configuration, or another more 
specific level.

Thanks,
Alex

From: Alex Mattioli 
Date: Wednesday, May 15, 2024 at 10:15 AM
To: 

RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC networks

[Alex Mattioli]

Hi Alex,

In this scenario:

>I think adding the ability to add network specific peers as mentioned in one 
>of >your prior replies would still allow the level of control some operators 
>(myself >included) may desire.

How do you propose network specific peers to be implemented?

Regards
Alex


 


-Original Message-
From: Dietrich, Alex  
Sent: Monday, May 20, 2024 2:21 PM
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hi Alex,

This may be a difference in perspective in implementation of BGP at the tenant 
level. I see the ability this would provide to seamlessly establishing those 
peering relationships with minimal intervention (helping scalability).

I think adding the ability to add network specific peers as mentioned in one of 
your prior replies would still allow the level of control some operators 
(myself included) may desire.

Thanks,
Alex

[photo]

Alex Dietrich
Senior Network Engineer, US Signal

616-233-5094  |  www.ussignal.com  
|  adietr...@ussignal.com

201 Ionia Ave SW, Grand Rapids, MI 
49503

[linkedin]

[facebook]

[youtube]

IMPORTANT: The contents of this email are confidential. Information is intended 
for the named recipient(s) only. If you have received this email by mistake, 
please notify the sender immediately and do not disclose the contents to anyone 
or make copies thereof.

[__tpx__]
From: Alex Mattioli 
Date: Monday, May 20, 2024 at 7:51 AM
To: us...@cloudstack.apache.org , 
dev@cloudstack.apache.org 
Subject: RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks EXTERNAL

Hi Alex,

> I am not convinced that specifying BGP peers at the zone level is a good idea 
> given the impacts BGP can have on a given network. I would much rather see 
> both peer and AS specification handled at the >network configuration, or 
> another more specific level.

I don't see how else end users would be able to automatically create routed 
networks without intervention from the operator.


Cheers
Alex




-Original Message-
From: Dietrich, Alex 
Sent: Thursday, May 16, 2024 2:23 PM
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hello Alex,

I appreciate this back and forth as I am excited about the potential this 
feature would hold.


  *   This is a very valid point.  We could add network specific BGP peers as 
well, which would override the automatic AS allocation, in the same way that we 
now allocate DNS servers in the zone level but can override that by manually 
selecting different DNS servers at network creation time.  Would that address 
your point?

Why does the network specific BGP peers need to override automatic AS 
allocation? In my mind there isn’t a dependency that needs to exist to those 
two as they are somewhat independent of one another.

I am not convinced that specifying BGP peers at the zone level is a good idea 
given the impacts BGP can have on a given network. I would much rather see both 
peer and AS specification handled at the network configuration, or another more 
specific level.

Thanks,
Alex

From: Alex Mattioli 
Date: Wednesday, May 15, 2024 at 10:15 AM
To: us...@cloudstack.apache.org , 
dev@cloudstack.apache.org 
Subject: RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks EXTERNAL

Hi Alex,

> Would zone-level BGP peers be those used by default for establishing new BGP 
> peers in networks where dynamic routing is enabled?

Correct, so far we plan to allow for up to 4 BGP peers for a zone, with the 
possibility to setup different metrics to each peer.

> This could affect a multi-tenant model where there may be different BGP peers 
> presented based on what the upstream network provides. An example of >this 
> would be where the VLANs associated to a given account are associated to 
> distinct VRFs and may have different peering IP addresses.
> I would like to see the peering IP addresses specific to the networks where 
> dynamic routing is enabled instead of specifying defaults at the zone level.


This is a very valid point.  We could add network specific BGP peers as well, 
which would override the automatic AS allocation, in the same way that we now 
allocate DNS servers in the zone level but can override that by manually 
selecting different DNS servers at network creation time.  Would that address 
your point?

Cheers,
Alex




-Original Message-
From: Dietrich, Alex 
Sent: Wednesday, May 15, 2024 2:34 PM
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Re: 

RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC networks

[Alex Mattioli]

Hi Alex,

> I am not convinced that specifying BGP peers at the zone level is a good idea 
> given the impacts BGP can have on a given network. I would much rather see 
> both peer and AS specification handled at the >network configuration, or 
> another more specific level.

I don't see how else end users would be able to automatically create routed 
networks without intervention from the operator.


Cheers
Alex

 


-Original Message-
From: Dietrich, Alex  
Sent: Thursday, May 16, 2024 2:23 PM
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hello Alex,

I appreciate this back and forth as I am excited about the potential this 
feature would hold.


  *   This is a very valid point.  We could add network specific BGP peers as 
well, which would override the automatic AS allocation, in the same way that we 
now allocate DNS servers in the zone level but can override that by manually 
selecting different DNS servers at network creation time.  Would that address 
your point?

Why does the network specific BGP peers need to override automatic AS 
allocation? In my mind there isn’t a dependency that needs to exist to those 
two as they are somewhat independent of one another.

I am not convinced that specifying BGP peers at the zone level is a good idea 
given the impacts BGP can have on a given network. I would much rather see both 
peer and AS specification handled at the network configuration, or another more 
specific level.

Thanks,
Alex

From: Alex Mattioli 
Date: Wednesday, May 15, 2024 at 10:15 AM
To: us...@cloudstack.apache.org , 
dev@cloudstack.apache.org 
Subject: RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks EXTERNAL

Hi Alex,

> Would zone-level BGP peers be those used by default for establishing new BGP 
> peers in networks where dynamic routing is enabled?

Correct, so far we plan to allow for up to 4 BGP peers for a zone, with the 
possibility to setup different metrics to each peer.

> This could affect a multi-tenant model where there may be different BGP peers 
> presented based on what the upstream network provides. An example of >this 
> would be where the VLANs associated to a given account are associated to 
> distinct VRFs and may have different peering IP addresses.
> I would like to see the peering IP addresses specific to the networks where 
> dynamic routing is enabled instead of specifying defaults at the zone level.


This is a very valid point.  We could add network specific BGP peers as well, 
which would override the automatic AS allocation, in the same way that we now 
allocate DNS servers in the zone level but can override that by manually 
selecting different DNS servers at network creation time.  Would that address 
your point?

Cheers,
Alex




-Original Message-
From: Dietrich, Alex 
Sent: Wednesday, May 15, 2024 2:34 PM
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hi Alex,

I appreciate the clarity!

Excuse my ignorance if I am misunderstanding the intention of specifying BGP 
peers at the zone level.

Would zone-level BGP peers be those used by default for establishing new BGP 
peers in networks where dynamic routing is enabled?

This could affect a multi-tenant model where there may be different BGP peers 
presented based on what the upstream network provides. An example of this would 
be where the VLANs associated to a given account are associated to distinct 
VRFs and may have different peering IP addresses.

I would like to see the peering IP addresses specific to the networks where 
dynamic routing is enabled instead of specifying defaults at the zone level.


  *   Alex

[__tpx__]
From: Alex Mattioli 
Date: Wednesday, May 15, 2024 at 9:27 AM
To: us...@cloudstack.apache.org , 
dev@cloudstack.apache.org 
Subject: RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks EXTERNAL

Hi Alex,

Answers inline below with >

Cheers




-Original Message-
From: Dietrich, Alex 
Sent: Wednesday, May 15, 2024 3:12 PM
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hello Alex,

I appreciate you taking on this initiative as I’d like to see similar 
functionality made available in CloudStack.

I do have some feedback on your implementation approach:

1 - Operator configures one or more BGP peers for a given Zone (with different 
metrics)

What is the intention behind specifying BGP peers at the zone level? I would 
think this would need to be specific to the network that you want to enable BGP 
on and does not need to concern the entire zone.

>The goal is for the process to be drive by the end user without operator 
>intervention. In the current design we'd enable the VR to share routes with 
>upstream routers 

RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC networks

[Alex Mattioli]

Hi Wido,

Thanks for the feedback,  comments below:

> I would suggest that the upstream router (Juniper, Frr, etc) should then use 
> Dynamic BGP neihbors.

That's the plan.

> I do suggest we add BGP passwords/encryption from the start for safety 
> reasons.

That's very likely to be there from day one.

> On the VR you just need to make sure you properly configure the BGP daemon 
> and it points to the right upstream routers.
Indeed, and we plan to use FRR for that.


Thanks for the link to the doc, I'll review it.

Cheers
Alex

 


-Original Message-
From: Wido den Hollander  
Sent: Friday, May 17, 2024 5:24 PM
To: dev@cloudstack.apache.org; Alex Mattioli ; 
us...@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

My apologies! I totally missed this one. Commments inline.

Op 15/05/2024 om 14:55 schreef Alex Mattioli:
> Hi all,
> 
> Does anyone have an opinion on the implementation of dynamic routing in 
> Isolated networks and VPCs?
> 
> So far the design is:
> 
> 1 - Operator configures one or more BGP peers for a given Zone (with 
> different metrics)
> 2 - Operator presents a pool of Private AS numbers to the Zone (just 
> like we do for VLANs)
> 3 - When a network is created with an offering which has dynamic 
> routing enabled an AS number is allocated to the network
> 4 - ACS configures the BGP session on the VR (using FRR), advertising 
> all its connected networks
> 

I would suggest that the upstream router (Juniper, Frr, etc) should then use 
Dynamic BGP neihbors.

On JunOS this is the "allow" statement [0]. The VR would indeed get an AS 
assigned by ACS and the network should know the 1, 2 or X upstream routers it 
can peer with. I do suggest we add BGP passwords/encryption from the start for 
safety reasons.

"allow 192.168.1.0/24"

On JunOS this allows any router within that subnet to establish a BGP sessions 
(and when the BGP password matches).

On the VR you just need to make sure you properly configure the BGP daemon and 
it points to the right upstream routers.

[0]: 
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/allow-edit-protocols-bgp.html

> Any and all input will be very welcome.
> 
> Cheers,
> Alex
> 
> 
>   
> 
> From: Alex Mattioli
> Sent: Wednesday, April 17, 2024 3:25 AM
> To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
> Subject: Dynamic routing for routed mode IPv6 and IPv4 Isolated and 
> VPC networks
> 
> Hi all,
> 
> I'd like to brainstorm dynamic routing in ACS (yes, again... for the 
> newcomers to this mailing list - this has been discussed multiple 
> times in the past 10+ years)
> 
> ACS 4.17 has introduced routed mode for IPv6 in Isolated networks and VPCs, 
> we are currently working on extending that to IPv4 as well, which will 
> support the current NAT'ed mode and also a routed mode (inspired by the NSX 
> integration https://www.youtube.com/watch?v=f7ao-vv7Ahk).
> 
> With stock ACS (i.e. without NSX or OpenSDN) this routing is purely static, 
> with the operator being responsible to add static routes to the Isolated 
> network or VPC tiers via the "public" (outside) IP of the virtual router.
> 
> The next step on this journey is to add some kind of dynamic routing. One way 
> that I have in mind is using dynamic BGP:
> 
> 1 - Operator configures one or more BGP peers for a given Zone (with 
> different metrics)
> 2 - Operator presents a pool of Private AS numbers to the Zone (just 
> like we do for VLANs)
> 3 - When a network is created with an offering which has dynamic 
> routing enabled an AS number is allocated
> 4 - ACS configures the BGP session on the VR, advertising all its 
> connected networks
> 
> This way there's no need to reconfigure the upstream router for each 
> new ACS network (it just needs to allow dynamic BGP peering from the 
> pool of AS numbers presented to the zone)
> 
> This implementation could also be used for Shared Networks, in which case the 
> destination advertised via BGP is to the gateway of the shared network.
> 
> There could also be an offering where we allow for end users to setup the BGP 
> parameters for their Isolated or VPC networks, which can then peer with 
> upstream VNF(s).
> 
> Any and all input is very welcome...
> 
> Taking the liberty to tag some of you: @Wei 
> Zhou @Wido den 
> Hollander @Kristaps 
> Čudars
> 
> Cheers,
> Alex
> 

Re: [I] 6.4.0 add host -> authentication error [cloudstack-cloudmonkey]

[via GitHub]

rohityadavcloud commented on issue #151:
URL: 
https://github.com/apache/cloudstack-cloudmonkey/issues/151#issuecomment-2120145537

   Fixed by https://github.com/apache/cloudstack-cloudmonkey/pull/150


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [I] 6.4.0 add host -> authentication error [cloudstack-cloudmonkey]

[via GitHub]

rohityadavcloud closed issue #151: 6.4.0 add host -> authentication error
URL: https://github.com/apache/cloudstack-cloudmonkey/issues/151


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [PR] network: when using API key & secret key drop params [cloudstack-cloudmonkey]

[via GitHub]

rohityadavcloud merged PR #150:
URL: https://github.com/apache/cloudstack-cloudmonkey/pull/150


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [PR] List virtual machines with details=min,nics [cloudstack-kubernetes-provider]

[via GitHub]

rohityadavcloud merged PR #60:
URL: https://github.com/apache/cloudstack-kubernetes-provider/pull/60


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org