cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hean Seng <heans...@gmail.com>
Subject Re: IPV6 in Isolated/VPC networks
Date Thu, 15 Jul 2021 10:39:13 GMT
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 <heanseng@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 <wido@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.Mattioli@shapeblue.com <mailto:Alex.Mattioli@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 <wido@widodh.nl <mailto:wido@widodh.nl>>
>> >     Sent: 13 July 2021 15:08
>> >     To: dev@cloudstack.apache.org <mailto:dev@cloudstack.apache.org>;
>> >     Alex Mattioli <Alex.Mattioli@shapeblue.com
>> >     <mailto:Alex.Mattioli@shapeblue.com>>
>> >     Cc: Wei Zhou <Wei.Zhou@shapeblue.com
>> >     <mailto:Wei.Zhou@shapeblue.com>>; Rohit Yadav
>> >     <rohit.yadav@shapeblue.com <mailto:rohit.yadav@shapeblue.com>>;
>> >     Gabriel Beims Bräscher <gabriel@pcextreme.nl
>> >     <mailto:gabriel@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.Zhou@shapeblue.com
>> >     <mailto:Wei.Zhou@shapeblue.com>> @Rohit
>> >     Yadav<mailto:rohit.yadav@shapeblue.com
>> >     <mailto:rohit.yadav@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message