On Tue, 7 Jun 2022 at 07:36, Peter Robinson <pbrobinson@xxxxxxxxx> wrote:
Hey Kevin,
Not particularly venturing an opinion here, personally would like it
to stay, but then I've had native v6 at home for 10+ years
> So, we are moving more and more things over to our ocp4 cluster
> (which is great!). However, I noticed this weekend, it's going to mean
> some of our applications that are reachable via ipv6 will no longer be.
> ;(
>
> The ocp3 cluster is on our vpn and can be reached by all our proxy
> network. Many of our proxies have ipv6 connectivity.
>
> The ocp4 cluster is not on our vpn and can only be reached by the 2 iad2
> proxies. iad2 has currently no ipv6 support.
Do we have any data from the proxies as to how much of the traffic is
over IPv6 vs IPv4? What services that are on the cluster will be
affected by the move?
Doing a bone stupid
```
awk 'BEGIN{ip4=0; ip6=0} $1!~/[g-z]/{if ($1~/\./){ip4=ip4+1}; if ($1~/:/){ip6=ip6+1};} END{total=ip4+ip6; print "ip4:",ip4,((ip4*100)/total)"%","ip6:",ip6, ((ip6*100)/total)"%"}'
```
on a bunch of the httpd logs that are external services for 2022-05-22 gave me
ip4: 49528865 88.1798% ip6: 6639163 11.8202%
Going over other days gives me around an 85% ipv4 and 15% ipv6. That is large enough that I think it would be good to get IAD2 onto ipv6.
> I'm asking networking folks about ipv6 support in iad2, but last I heard
> it was waiting for some hardware upgrades, so I don't know that we can
> count on it anytime soon.
That was the excuse they used to give in PHX from memory "we will
deploy IPv6 in the new DC and the equipment doesn't support it" and
support for v6 in equipment has been a requirement to sell to US govt
since the late 2000s so by now all their equipment should support it.
There are different levels of support. The various vendors have been selling an ipv6 stack for years but various parts don't work under load unless you just want port 80 and port 443 and nothing too fancy on them. (NFS seems to be one protocol which seems to overload various stacks a lot). Most of the problems tend to be the amount of memory needed to map the stateful firewall and it blowing up regularly.
We had ipv6 twice in the IAD2 location but found that various Fedora utilities broke horribly during that time. We didn't have time to deal with those and get the move complete so we asked ipv6 to be turned off. The current problem is we were already in the red for ipv4 traffic on the firewall which was purchased. This one was much bigger than the one we had in PHX2 and was thought to be enough for our needs. However, we basically have filled that pipe. We could turn on the ipv6 stack but would probably see a degradation of services overall. The firewall to replace it has been purchased but is on a long wait queue to be put into replacement as other needs have been deemed higher urgency than that.
At this point, it is a matter of getting on the Change Control schedule for Red Hat IT to have our networks turn the process on. It would also help to have a general plan of action of how this would be done like:
1. Set up internal ipv6 for IAD2 networks.
2. Set up and test ipv6 firewalls and dualstacks on systems in IAD2.
3. Set up limited firewall traffic of ipv6 to public network
4. Roll out new firewall hardware to IAD2
5. Test infrastructure and add ipv6 advertisements to public network
6. ...
7. profit
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
