Hi Wido, What is benefit of using Route Advertisement on internal VR networks?
In drawing VR is in VPC mode how it will work for isolated network where external link/ip is not assigned initially? On 2021/07/15 14:47:24, Wido den Hollander <w...@widodh.nl> wrote: > But you still need routing. See the attached PNG (and draw.io XML). > > You need to route the /48 subnet TO the VR which can then route it to > the Virtual Networks behind the VR. > > There is no other way then routing with either BGP or a Static route. > > Wido > > Op 15-07-2021 om 12:39 schreef Hean Seng: > > 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 > > <mailto: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 > > <mailto: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> > > <mailto: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> <mailto:w...@widodh.nl > > <mailto:w...@widodh.nl>>> > > > Sent: 13 July 2021 15:08 > > > To: dev@cloudstack.apache.org > > <mailto:dev@cloudstack.apache.org> > > <mailto:dev@cloudstack.apache.org > > <mailto:dev@cloudstack.apache.org>>; > > > Alex Mattioli <alex.matti...@shapeblue.com > > <mailto:alex.matti...@shapeblue.com> > > > <mailto:alex.matti...@shapeblue.com > > <mailto:alex.matti...@shapeblue.com>>> > > > Cc: Wei Zhou <wei.z...@shapeblue.com > > <mailto:wei.z...@shapeblue.com> > > > <mailto:wei.z...@shapeblue.com > > <mailto:wei.z...@shapeblue.com>>>; Rohit Yadav > > > <rohit.ya...@shapeblue.com > > <mailto:rohit.ya...@shapeblue.com> > > <mailto:rohit.ya...@shapeblue.com > > <mailto:rohit.ya...@shapeblue.com>>>; > > > Gabriel Beims Bräscher <gabr...@pcextreme.nl > > <mailto:gabr...@pcextreme.nl> > > > <mailto: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> > > > <mailto:wei.z...@shapeblue.com > > <mailto:wei.z...@shapeblue.com>>> @Rohit > > > Yadav<mailto:rohit.ya...@shapeblue.com > > <mailto:rohit.ya...@shapeblue.com> > > > <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
