Hi Hean, You still need to create route on L3 SW that will point /64 VM
On 2021/07/15 10:39:13, Hean Seng <heans...@gmail.com> wrote: > Or explain like this : > > 1) Cloudstack generate list of /64 subnet from /48 that Network admin > assigned to Cloudstack > 2) Cloudsack allocated the subnet (that generated from step1) to Virtual > Router, one Virtual Router have one subniet /64 > 3) Virtual Router allocate single IPv6 (within the range of /64 allocated > to VR) to VM > > > > > > > On Thu, Jul 15, 2021 at 6:25 PM Hean Seng <heans...@gmail.com> wrote: > > > Hi Wido, > > > > I think the /48 is at physical router as gateway , and subnet of /64 at VR > > of Cloudstack. Cloudstack only keep which /48 prefix and vlan information > > of this /48 to be later split the /64. to VR. > > > > And the instances is getting singe IPv6 of /64 IP. The VR is getting > > /64. The default gateway shall goes to /48 of physical router ip . In > > this case ,does not need any BGP router . > > > > > > Similar concept as IPv4 : > > > > /48 subnet of IPv6 is equivalent to current /24 subnet of IPv4 that > > created in Network. > > and /64 of IPv6 is equivalent to single IP of IPv4 assign to VM. > > > > > > > > > > On Thu, Jul 15, 2021 at 5:31 PM Wido den Hollander <w...@widodh.nl> wrote: > > > >> > >> > >> Op 14-07-2021 om 16:44 schreef Hean Seng: > >> > Hi > >> > > >> > I replied in another thread, i think do not need implement BGP or OSPF, > >> > that would be complicated . > >> > > >> > We only need assign IPv6 's /64 prefix to Virtual Router (VR) in NAT > >> > zone, and the VR responsible to deliver single IPv6 to VM via DHCP6. > >> > > >> > In VR, you need to have Default IPv6 route to Physical Router's /48. > >> IP > >> > as IPv6 Gateway. Thens should be done . > >> > > >> > Example : > >> > Physical Router Interface > >> > IPv6 IP : 2000:aaaa::1/48 > >> > > >> > Cloudstack virtual router : 2000:aaaa:200:201::1/64 with default ipv6 > >> > route to router ip 2000:aaaa::1 > >> > and Clodustack Virtual router dhcp allocate IP to VM , and VM will > >> have > >> > default route to VR. IPv6 2000:aaaa:200:201::1 > >> > > >> > So in cloudstack need to allow user to enter , IPv6 gwateway , and > >> > the /48 Ipv6 prefix , then it will self allocate the /64 ip to the VR > >> , > >> > and maintain make sure not ovelap allocation > >> > > >> > > >> > >> But NAT is truly not the solution with IPv6. IPv6 is supposed to be > >> routable. In addition you should avoid DHCPv6 as much as possible as > >> that's not really the intended use-case for address allocation with IPv6. > >> > >> In order to route an /48 IPv6 subnet to the VR you have a few > >> possibilities: > >> > >> - Static route from the upperlying routers which are outside of CloudStack > >> - BGP > >> - OSPFv3 (broken in most cases!) > >> - DHCPv6 Prefix Delegation > >> > >> BGP and/or Static routes are still the best bet here. > >> > >> So what you do is that you tell CloudStack that you will route > >> 2001:db8::/48 to the VR, the VR can then use that to split it up into > >> multiple /64 subnets going towards the instances: > >> > >> - 2001:db8::/64 > >> - 2001:db8:1::/64 > >> - 2001:db8:2::/64 > >> ... > >> - 2001:db8:f::/64 > >> > >> And go on. > >> > >> In case of BGP you indeed have to tell the VR a few things: > >> > >> - It's own AS number > >> - The peer's address(es) > >> > >> With FRR you can simply say: > >> > >> neighbor 2001:db8:4fa::179 remote-as external > >> > >> The /48 you need to have at the VR anyway in case of either a static > >> route or BGP. > >> > >> We just need to add a NullRoute on the VR for that /48 so that traffic > >> will not be routed to the upper gateway in case of the VR can't find a > >> route. > >> > >> Wido > >> > >> > > >> > > >> > > >> > > >> > > >> > On Wed, Jul 14, 2021 at 8:55 PM Alex Mattioli > >> > <alex.matti...@shapeblue.com <mailto:alex.matti...@shapeblue.com>> > >> wrote: > >> > > >> > Hi Wido, > >> > That's pretty much in line with our thoughts, thanks for the input. > >> > I believe we agree on the following points then: > >> > > >> > - FRR with BGP (no OSPF) > >> > - Route /48 (or/56) down to the VR > >> > - /64 per network > >> > - SLACC for IP addressing > >> > > >> > I believe the next big question is then "on which level of ACS do we > >> > manage AS numbers?". I see two options: > >> > 1) Private AS number on a per-zone basis > >> > 2) Root Admin assigned AS number on a domain/account basis > >> > 3) End-user driven AS number on a per network basis (for bring your > >> > own AS and IP scenario) > >> > > >> > Thoughts? > >> > > >> > Cheers > >> > Alex > >> > > >> > > >> > > >> > > >> > -----Original Message----- > >> > From: Wido den Hollander <w...@widodh.nl <mailto:w...@widodh.nl>> > >> > Sent: 13 July 2021 15:08 > >> > To: dev@cloudstack.apache.org <mailto:dev@cloudstack.apache.org>; > >> > Alex Mattioli <alex.matti...@shapeblue.com > >> > <mailto:alex.matti...@shapeblue.com>> > >> > Cc: Wei Zhou <wei.z...@shapeblue.com > >> > <mailto:wei.z...@shapeblue.com>>; Rohit Yadav > >> > <rohit.ya...@shapeblue.com <mailto:rohit.ya...@shapeblue.com>>; > >> > Gabriel Beims Bräscher <gabr...@pcextreme.nl > >> > <mailto:gabr...@pcextreme.nl>> > >> > Subject: Re: IPV6 in Isolated/VPC networks > >> > > >> > > >> > > >> > On 7/7/21 1:16 PM, Alex Mattioli wrote: > >> > > Hi all, > >> > > @Wei Zhou<mailto:wei.z...@shapeblue.com > >> > <mailto:wei.z...@shapeblue.com>> @Rohit > >> > Yadav<mailto:rohit.ya...@shapeblue.com > >> > <mailto:rohit.ya...@shapeblue.com>> and myself are investigating > >> how > >> > to enable IPV6 support on Isolated and VPC networks and would like > >> > your input on it. > >> > > At the moment we are looking at implementing FRR with BGP (and > >> > possibly OSPF) on the ACS VR. > >> > > > >> > > We are looking for requirements, recommendations, ideas, rants, > >> > etc...etc... > >> > > > >> > > >> > Ok! Here we go. > >> > > >> > I think that you mean that the VR will actually route the IPv6 > >> > traffic and for that you need to have a way of getting a subnet > >> > routed to the VR. > >> > > >> > BGP is probably you best bet here. Although OSPFv3 technically > >> > supports this it is very badly implemented in Frr for example. > >> > > >> > Now FRR is a very good router and one of the fancy features it > >> > supports is BGP Unnumered. This allows for auto configuration of BGP > >> > over a L2 network when both sides are sending Router Advertisements. > >> > This is very easy for flexible BGP configurations where both sides > >> > have dynamic IPs. > >> > > >> > What you want to do is that you get a /56, /48 or something which is > >> > >/64 bits routed to the VR. > >> > > >> > Now you can sub-segment this into separate /64 subnets. You don't > >> > want to go smaller then a /64 is that prevents you from using SLAAC > >> > for IPv6 address configuration. This is how it works for Shared > >> > Networks now in Basic and Advanced Zones. > >> > > >> > FRR can now also send out the Router Advertisements on the downlinks > >> > sending out: > >> > > >> > - DNS servers > >> > - DNS domain > >> > - Prefix (/64) to be used > >> > > >> > There is no need for DHCPv6. You can calculate the IPv6 address the > >> > VM will obtain by using the MAC and the prefix. > >> > > >> > So in short: > >> > > >> > - Using BGP you routed a /48 to the VR > >> > - Now you split this into /64 subnets towards the isolated networks > >> > > >> > Wido > >> > > >> > > Alex Mattioli > >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > -- > >> > Regards, > >> > Hean Seng > >> > > > > > > -- > > Regards, > > Hean Seng > > > > > -- > Regards, > Hean Seng >
