Hi, One example why loosely implemented BGP on VR could lead to tsunami of problems. Why I’m proposing to do IPv6 without using BGP.
Zebra/Quagga/FRR over BGP will advertise all local routing table to peer. All content of ip route. Usually there are some BGP filters in place to protect from common human errors. No one will prohibit me creating interfaces with 1.1.1.1/1.0.0.1/.8.8.8.8/8.4.4.4/and ipv6 counterparts. They will go to local routing table and then will be advertised over bgp to peer. If there will be no filters/protection in place metric at least for DC where VR is located will be better and all DNS/NTP/etc.... traffic will start flowing into my VR direction. Networking departments will come up with even more proficient ways of exploiting loose BGP implementations. On Thu, 15 Jul 2021 at 09:39, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Hi Kristaps, > > I think the public list may not allow you larger email and > doc/attachments. If there are any documents you want to share, can you say > put them on Google docs and share the link with dev list? Thanks. > > > Regards. > > ________________________________ > From: Kristaps Cudars <kristaps.cud...@gmail.com> > Sent: Wednesday, July 14, 2021 21:09 > To: dev@cloudstack.apache.org <dev@cloudstack.apache.org> > Subject: Re: RE: IPV6 in Isolated/VPC networks > > Pony Mail is blocking me :( > > Hi, > > Elaborating on my previous email. > > In my opinion SLAAC (StateLess Address Auto Configuration) is not good > candidate for VR as it was created for situations of connecting million > devices with less amount of effort and no micromanagement needed. > > One example that coms in mind is- I want to reassign IPv6 from one instance > to another with SLAAC I will need to change mac address on instance. This > will introduce new workflows in ACS. > > Suggestion would be to use same IPv4 services for IPv6 and have feature > parity between both protocols in dual-stack configuration as much as > possible. IPv4 will stay with NAT and IPv6 will be routable. Form ACS > interface and workflow perspective everything will stay same for both > protocols with excursion that IPv6 will not have source and destination > NAT. > > In Primate it can be handled with protocols selection dropdown, checkboxes, > additional fields in same isolated/vpc workflow. > > Vision from user/admin perspective could look as following: > > For Zones > Traffic Types > Public for existing or new add/edit IPv6 > > When isolated/vpc network is created you are presented with option to > enable or disable both protocols. (One of them should be enabled) > > For IPv6 there must be predefined list of /64 networks that can be > automatically assigned. > In VR creation menu IPv6 is prefilled and not changeable by user. > It could be in Zones > Traffic Types > Internal > > In case of isolated network public IP must be assigned in case of vpc its > already assigned. > > At this point ACS should do api call/or something to insert route in L3 > element. > You have two variables internal IPv6 network and public IPv6 address that > will form route entry. > > In our case we are using Cisco NX-OS and it has NX-API. I stand for choice > and there are many more grate L3 devices. Inserting those variables in to > ansible that can play route add/remove against many vendors is better. List > can be git repository. > It also could be ACS api where you can get list public and internal ip > relations and how you form/create routing entries is up to you. > This can be something else proposed by others. > > Or do it manually is also option for beginning/ small deployments/ lab. > Nothing bad happens if you do not create route instantly. It simply will > not work until route is created. > > Probably it would be smart to have global option that enables/disable IPv6. > > I’m accepting questions, something must be explained in more detail, rant… > that this is not good. > > >
