- 最新
- 投票最多
- 评论最多
Alright, that clarified a lot. Since you can access the instance over SSH when it's a t3.medium, I think what you could check quickly is which network interfaces are available and which IPs they're configured with. ifconfig -a, ip link show, and ip addr would probably tell us if there's a new interface either with default settings or with a DHCP-assigned IP and not the set of addresses you've manually configured.
I would guess the primary interface might be present on the new instance type, but with a different interface name/number from before. That's why it wouldn't have the configuration it used to have. If that's so, you could try copying the IP address and other interface-specific configuration (iptables etc.) in Debian from the old interface to the new one.
Whether or not this fixes the issue, I'd suggest simplifying the setup by switching to DHCP-assigned IPs for both interfaces. The public IPs shouldn't need to be configured on the instance. When traffic sent to the Elastic IP arrives at AWS, the destination address should get translated to the primary private IP address of the network interface with which the EIP is associated. Linux would only see traffic arriving to its private IPs. With the two ENIs you already have, you should only need one private IP on each, which DHCP could assign for you. That would keep working even when the operating system renumbers the devices/interfaces.
The normal way to assign IP addresses to EC2 instances is to allocate them via the VPC's built-in DHCP service. One network interface will only obtain one IP via DHCP, so if you have multiple IPs on a single interface, you've probably configured them manually in the operating system, rather than them being obtained via DHCP. The operating system may be confused about what to do with the old configuration, when it finds itself running on a dissimilar virtual hardware platform.
I suggest you simplify the setup by attaching a secondary network interface (ENI) to the instance before switching the instance type. Move the second IP address to the new ENI, so that each ENI only has one IP. Finally, set the operating system to obtain IP addresses via DHCP.
It's also advisable to ensure you're running the latest versions of the ENA (Elastic Network Adapter) and NVMe drivers. It may be particularly relevant when switching from the Xen hypervisor still used by the old t2 family to the modern Nitro hypervisor used for the t3 and t3a families. With outdated drivers, I've occasionally seen behaviour that otherwise makes no sense.
Hi Leo,
Thanks very much for your prompt reply. I need to tell you more about my installation. I am running Debian 12 and I believe that I have previously already done much of what you have advised. When the instance was originally provisioned with Debian 12 it already had one working Public IP Address, one working Private IP Address and one working Network Interface. I then added a Secondary Network Interface, Secondary Private IP Address and Public IP Address and had everything working perfectly on the t2.medium instance so that it now has two (2) Public IP Addresses (Primary & Secondary), two (2) Private IP Addresses (Primary & Secondary) and two (2) Network Interfaces (Primary & Secondary). I then attempted the migration to the t3.medium instance after which the Primary IP addresses no longer worked but the Secondary IP addresses did work. So, after I migrated to the t3.medium instance I only had ssh access over the Secondary Public IP Address and the Primary Public IP address does not work.
It seems that, with the migration to the t3.medium instance, the instance may have been assigned a different IP address for the Primary interface but the EC2 web interface shows that the IP addresses have not changed. So, any ideas on how to trouble shoot this?
Thanks,
Gordon
相关内容
- 已提问 7 个月前
