DMIT LAX 维护后IPv4网络不通原因及修复方案

RT，本帖记录了 DMIT LAX 区域维护后IPv4网络不通原因及修复方案

#DMIT维护通知
Scheduled Maintenance
Facility: Los Angeles Data Center
Scope: All Virtual Machines
Maximum Simultaneous Impact: One Hypervisor at a time
Maximum Impact Duration: 1 hour per client VM
Time: 3:00 PM – 5:00 PM UTC (Correct, Eastern Standard Time)
Dates: April 8 – April 16
Details: Resolving anomalies caused by suboptimal kernel configurations; a system reboot is required.
Note: Only one Hypervisor will be processed at a time; therefore, the overall maintenance period will be extended.

DMIT最近在修BUG，我所有的LAX地域的机器都已经维护完成并开机了，但是发现有一台用于组网的机器开机后，IPv4出现了不通的问题。这台组网机使用ifupdown-ng来代替原本的ifupdown，怀疑是之前配置了dhcp导致的（之前使用dhcp可正常获取v4地址与网关，现在可以正常获取地址，但获取不到v4网关）。

如果你没有DD过系统，没有禁用过cloud-init，那DMIT会主动通过cloud-init下发新的网络配置，维护完成之后，IPv4会自动回来。
如果你DD过其他系统，或者已经禁用了cloud-init，那需要手动修改配置文件，以我的组网机为例，我使用ifupdown-ng管理所有网络接口，我已经禁用了cloud-init自动下发网络配置，那我需要做以下修改。

ifupdown-ng修改方法

#这是ifupdown-ng的配置，一定要搞清楚你当前用的是什么网络管理工具，再去做相应的修改
#这是ifupdown-ng的配置，一定要搞清楚你当前用的是什么网络管理工具，再去做相应的修改
#这是ifupdown-ng的配置，一定要搞清楚你当前用的是什么网络管理工具，再去做相应的修改

#原始配置文件
auto eth0
iface eth0
    use dhcp
#修复后配置文件
auto eth0
iface eth0
    address 你的IPv4/32
    gateway 193.41.250.250
    ipv6-autoconf 2
    dns-nameservers 1.1.1.1 8.8.8.8

如果你使用的是旧版本的ifupdown-ng，那做完上述修改还不够，因为DMIT早在2023年就使用了onlink网关，VM的IPv4地址是/32地址，和网关不在同一个网段，这样可以解决二层广播流量问题，而旧版的ifupdown-ng还不支持onlink网络，所以需要对ifupdown-ng的脚本做一些修改。

#DMIT-NOC 2023 Nov 29发的推送
Content: Deploy DMIT Full Layer 3 network enhancements. Block ARP, multicast, broadcast, etc. in the customer's network; and provide additional IP address delivery methods: RADVD (IPv6), DHCP (IPv4).

#修改/usr/libexec/ifupdown-ng/static的configure_gateway()函数
${MOCK} ip "${addrfam}" route add default via "${gw}" ${VRF_TABLE} ${METRIC} dev "${IFACE}"
修改为
${MOCK} ip "${addrfam}" route add default via "${gw}" ${VRF_TABLE} ${METRIC} dev "${IFACE}" onlink
即可解决问题
#修改完成后，重启接口
#命令需要在同一条执行，不要分开执行
ifdown eth0 && ifup eth0

ifupdown修改方法

使用IPv6 SSH连到机器，或者使用VNC连接机器(VNC密码可以在控制台重置)，修改"/etc/network/interfaces.d/"目录下的配置文件(具体文件名看你dd的系统)，我这边是"/etc/network/interfaces.d/50-cloud-init"。

#这是ifupdown的配置，一定要搞清楚你当前用的是什么网络管理工具，再去做相应的修改
#这是ifupdown的配置，一定要搞清楚你当前用的是什么网络管理工具，再去做相应的修改
#这是ifupdown的配置，一定要搞清楚你当前用的是什么网络管理工具，再去做相应的修改
#我使用的系统是Debian12

#修复后配置文件
auto lo
iface lo inet loopback
    dns-nameservers 1.1.1.1 1.0.0.1

auto eth0
iface eth0 inet static
    address 你的IPv4/32
    gateway 193.41.250.250

# control-alias eth0
iface eth0 inet6 auto

如果你操作之后，发现IPv6不通了，同时你又开启了内核的IP转发，则需要修改以下文件

#开启net.ipv6.conf.all.forwarding=1后，系统会认为自己是一台路由器，从而拒绝接受其他人发来的RA
#修改/etc/sysctl.conf
#在末尾添加
net.ipv6.conf.eth0.accept_ra = 2

建议各位非必要不DD，你没办法保证你DD的系统是否干净，最近已经刷到非常多因为DD导致Abuse被服务商封禁的帖子了。

同时，也建议各位非必要情况下，不要禁用cloud-init和卸载QEMU Guest Agent，这会带来很多麻烦。

最后，吐槽一下，这么大体量的服务商，业务中断时间居然这么久，实在是不太应该，不能先把VM迁移至其他宿主机、再重启宿主机、再迁回吗？

这次真的是最后了，我没有DD过的机器，只能从表面现象分析原因，如果有大佬愿意提供故障机器的话，也许可以找出根本原因。