Cost of IPv6 for IT operations team
matija at serverflow.com
Fri Mar 27 13:27:45 CET 2015
It really depends on how automated you are at running things. It took me
a few hours to brainstorm and document an addressing scheme which lets
us look at the 64 bit suffix and be able to tell in which DC the host is
located and what is it's function.
The setup for our CDN hosts is completely automated, and it took our
ansible guy a couple of hours to write an implementation that checks if
a given DC has IPv6 or not and does the right thing in either case.
Even if you are looking at this in the time-frame of a month, that is
far less than 20%, and in the time-frame of a year, it is negligible.
Testing the in-house software that runs the CDN was more work, but that
came under developer testing, not under IT operations.
If we had been managing all our servers by hand, it would have taken far
more time, but then again, the number of servers we run makes ANY change
which assumes manual intervention unmanageable.
On 03/27/2015 12:59 PM, Phil Mayers wrote:
> On 26/03/15 09:04, BERENGUER Christophe wrote:
>> Hello everybody,
>> I work for a consulting firm.
>> For a client, I would like to estimate the work overload for IT
>> operations team to deploy IPv6 dual stack and for day to day operations.
>> On the internet, I have found an estimation around 20% of work overload
>> for the run phase. But if you have operational feedback it would be the
> I agree with others that this is a very hard thing to estimate.
> I will say that we run our dual-stack network (fully deployed since
> ca. 2012) with exactly the same staffing levels, and actually a slight
> reduction in our recurrent budget, as our older IPv4-only network.
> I don't think our network is any less reliable, or suffers a higher
> level of incidents. This suggests to me that, in our case, IPv6 has
> added a very low operational cost. Our incidence of IPv6-related
> problems, particularly rogue RA from machines configured for
> connection sharing, has actually *decreased* substantially since we
> deployed native IPv6.
> I don't believe the rollout cost was high. We used refresh cycles to
> upgrade to v6-capable gear, and rolled out slowly to grow our team
> knowledge. But we don't have detailed cost breakdowns.
More information about the ipv6-ops