Re: IPV6 in Isolated/VPC networks
Op 19-07-2021 om 20:38 schreef Kristaps Cudars: Hi Wido, I assume that flouting ip will not work grate with ingress/egress acl on VR. From regular ACS user perspective: I have Instance with dualstack its running web app on 443. I want to swap instances for whatever reason. In case of IPv4 change d-nat rule. In case of IPv6 if flouting IP was not created upfront he will need to change dns entry that usually has 24h ttl. Inconvenience degradation in experience. Yes, but, keep in mind that the IP you are using can also be terminated on the VR where HAProxy proxies request to the backend VM (could even be v4!) I'm not against DHCPv6, but I have seen many issues with implementing it. Therefor I always stick to SLAAC. From ACS admin perspective: I don’t want to have these tickets in helpdesk. You needed to create another flouting IP that it would be seamless- will not work as answer. I understand that as well. Wido On 2021/07/19 09:05:54, Wido den Hollander wrote: Op 16-07-2021 om 21:46 schreef Kristaps Cudars: Hi Wido, Your proposal is to sacrifice ability to reassign IPv6 to instance, have internal domain prefix, and list/db in ACS what IPv6 has been assigned to what instance and go with RA and SLAAC. For route signaling to switch use BGP/OSPFv3 or manual pre-creation. You can still list the IPs which have been assigned. You'll know exactly what IPv6 address a VM has because of the prefix + MAC. Privacy Extensions need to be disabled in the VM. This already works in CloudStack in Shared Networks in this way. Using secondary IPs you can always have 'floating' IPv6 addressess. Wido Option with RA and managed flag that DHCPv6 is in use to support preset information and ability to create route information from ACS is not an option as DHCPv6 its failing? On 2021/07/16 15:17:42, Wido den Hollander wrote: Op 16-07-2021 om 16:42 schreef Hean Seng: Hi Wido, In current setup, each Cloudstack have own VR, so in this new IPv6 subnet allocation , each VR (which have Frr) will need to have peering with ISP router (and either BGP or Static Route) , and there is 1000 Acocunts, it will 1000 BGP session with ISP router , Am I right for this ? or I understand wrong . Yes, that is correct. A /56 would also be sufficient or a /60 which is enough to allocate a few /64 subnets. 1000 BGP connections isn't really a problem for a proper router at the ISP. OSPF(v3) would be better, but as I said that's poorly supported. The ISP could also install 1000 static routes, but that means that the ISP's router needs to have those configured. http://docs.frrouting.org/en/latest/ospf6d.html (While looking up this URL I see that Frr recently put in a lot of work in OSPFv3, seems better now) I understand IPv6 is different then IPv4, and in IPv6 it suppose each devices have own IP. It just how to realize in easy way. On Fri, Jul 16, 2021 at 8:17 PM Wido den Hollander wrote: Op 16-07-2021 om 05:54 schreef Hean Seng: Hi Wido, My initial thought is not like this, it is the /48 at ISP router, and /64 subnet assign to AdvanceZoneVR, AdvanceZoneVR responsible is distribule IPv6 ip (from the assigned /64 sunet) to VM, and not routing the traffic, in the VM that get the IPv6 IP will default route to ISP router as gw. It can may be a bridge over via Advancezone-VR. How would you bridge this? That sounds like NAT? IPv6 is meant to be routed. Not to be translated or bridged in any way. The way a made the drawing is exactly how IPv6 should work in a VPC environment. Traffic flows through the VR where it can do firewalling of the traffic. However, If do as the way described in the drawing, then i suppose will be another kind of virtual router going to introduce , to get hold the /48 in this virtual router right ? It can be the same VR. But keep in mind that IPv6 != IPv4. The VR will get Frr as a new daemon which can talk BGP with the upper network to route traffic. After this, The Advance Zone, NAT's VR will peer with this new IPv6 VR for getting the IPv6 /64 prefix ? IPv4 will be behind NAT, but IPv6 will not be behind NAT. If do in this way, then I guess you just only need Static route, with peering ip both end as one /48 can have a lot of /64 on it. And hardware budgeting for new IPv6-VR will become very important, as all traffic will need to pass over it . Routing or NAT is the same for the VR. You don't need a very beefy VR for this. It will be like ISP Router -- > (new IPV6-VR ) > AdvanceZone-VR > VM Relationship of (new IPv6 VR) and AdvanceZone-VR , may be considering on OSPF instead of BGP , otherwise few thousand of AdvanceZone-VR wil have few thousand of BGP session. on new-IPv6-VR Also, I suppose we cannot do ISP router. -->. Advancezone VR direct, , otherwise ISP router will be full of /64 prefix route either on BGP( Many BGP Session) , or Many Static route . If few thousand account, ti will be few t
[GitHub] [cloudstack-documentation] sureshanaparti commented on pull request #217: Added vmware disk provisioning types
sureshanaparti commented on pull request #217: URL: https://github.com/apache/cloudstack-documentation/pull/217#issuecomment-882373926 Code PR (apache/cloudstack#4640) merged, merging the doc changes -- 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
[GitHub] [cloudstack-documentation] wido commented on pull request #231: network: note on shared networks with IPv6
wido commented on pull request #231: URL: https://github.com/apache/cloudstack-documentation/pull/231#issuecomment-882406619 That is correct. IPv6-only networks are not yet supported with CloudStack. IPv4 is always needed at the moment. For example cloud-init requires it. -- 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
[GitHub] [cloudstack-documentation] shwstppr commented on a change in pull request #223: Host ha and multiple management server internal load balancing
shwstppr commented on a change in pull request #223: URL: https://github.com/apache/cloudstack-documentation/pull/223#discussion_r672205178 ## File path: source/adminguide/reliability.rst ## @@ -126,6 +183,107 @@ that you want to dedicate to HA-enabled VMs. a crash. +HA-Enabled Hosts + + +The user can specify a host as HA-enabled, In the event of a host +failure, attemps will be made to recover the failed host by first +issuing some OOBM commands. If the host recovery fails the host will be +fenced and placed into maintenance mode. To restore the host to normal +operation, manual intervention would then be required. + +Out of band management is a requirement of HA-Enabled hosts and has to be +confiured on all intended participating hosts. +(see `“Out of band management” `_). + +Host-HA has granular configuration on a host/cluster/zone level. In a large +environment, some hosts from a cluster can be HA-enabled and some not, + +Host-HA uses a state machine design to manage the operations of recovering +and fencing hosts. The current status of a host is reported when quering a +specific host. + +Timely health investigations are done on HA-Enabled hosts to monitor for +any failures. Specific thersholds can be set for failed investigations, Review comment: ```suggestion any failures. Specific thresholds can be set for failed investigations, ``` -- 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
[GitHub] [cloudstack-documentation] andrijapanicsb commented on pull request #223: Host ha and multiple management server internal load balancing
andrijapanicsb commented on pull request #223: URL: https://github.com/apache/cloudstack-documentation/pull/223#issuecomment-882492162 Will do after my vacation pls, yes. On my to-do list (among other doc update reviews) -- 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
[GitHub] [cloudstack-documentation] sureshanaparti merged pull request #217: Added vmware disk provisioning types
sureshanaparti merged pull request #217: URL: https://github.com/apache/cloudstack-documentation/pull/217 -- 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
[GitHub] [cloudstack-documentation] andrijapanicsb commented on pull request #223: Host ha and multiple management server internal load balancing
andrijapanicsb commented on pull request #223: URL: https://github.com/apache/cloudstack-documentation/pull/223#issuecomment-882492162 Will do after my vacation pls, yes. On my to-do list (among other doc update reviews) -- 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
