Score:0

Secondary network interface can't be pinged with Amazon Linux 2 AMI

ru flag
Cal

Short story: both private IP addresses on primary network interface can be pinged, but both private IP addresses on secondary network interface cannot be pinged.

Long story:

Based on this aws documentation, using Amazon Linux 2 AMI, it will automatically configure additional network interfaces and IP addresses.

With a micro ec2 instance, theoretically it can have 4 private IP addresses (2 network interfaces, 2 IP addresses on each network interface)

My steps:

  1. Create an ec2 instance from Amazon Linux 2 AMI, set two private IP addresses during creation
  2. Associate an elastic IP address
  3. After creation, attach a secondary network interface with 2 private IP addresses (same subnet and same security group as primary NIC).
  4. Login the instance, restart network interface using the command from the documentation: sudo service network restart

ip a output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 0e:31:86:22:95:b4 brd ff:ff:ff:ff:ff:ff
    inet 172.31.1.101/20 brd 172.31.15.255 scope global dynamic eth0
       valid_lft 2509sec preferred_lft 2509sec
    inet 172.31.1.102/20 brd 172.31.15.255 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::c31:86ff:fe22:95b4/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 0e:ff:4a:aa:cb:66 brd ff:ff:ff:ff:ff:ff
    inet 172.31.2.201/20 brd 172.31.15.255 scope global dynamic eth1
       valid_lft 2325sec preferred_lft 2325sec
    inet 172.31.2.202/20 brd 172.31.15.255 scope global secondary eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::cff:4aff:feaa:cb66/64 scope link
       valid_lft forever preferred_lft forever

ip r output:

default via 172.31.0.1 dev eth0
default via 172.31.0.1 dev eth1 metric 10001
169.254.169.254 dev eth0
172.31.0.0/20 dev eth0 proto kernel scope link src 172.31.1.101
172.31.0.0/20 dev eth1 proto kernel scope link src 172.31.2.201

ip rule output:

0:      from all lookup local
32764:  from 172.31.2.202 lookup 10001
32765:  from 172.31.2.201 lookup 10001
32766:  from all lookup main
32767:  from all lookup default

ip route show table 10001 output:

default via 172.31.0.1 dev eth1
172.31.0.0/20 dev eth1 proto kernel scope link src 172.31.2.201

sysctl -ar 'conf.eth.\.arp_' output:

net.ipv4.conf.eth0.arp_accept = 0
net.ipv4.conf.eth0.arp_announce = 0
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth0.arp_ignore = 0
net.ipv4.conf.eth0.arp_notify = 0
net.ipv4.conf.eth1.arp_accept = 0
net.ipv4.conf.eth1.arp_announce = 0
net.ipv4.conf.eth1.arp_filter = 0
net.ipv4.conf.eth1.arp_ignore = 0
net.ipv4.conf.eth1.arp_notify = 0

With all above configuration, both private IP addresses on primary network interface can be pinged (from another ec2 instance). But both IP on secondary network interface CANNOT be pinged (Destination Host Unreachable).

Also, setting the security group to open to all traffic, all sources, does not help.

A.B avatar
cl flag
A.B
To be complete you have to add `ip route show table 10001`. Anyway the full picture of the network layout isn't clear (to someone not knowing well AWS). I'd also check arp settings for such case: `sysctl -ar 'conf.eth.\.arp_'`.
ru flag
Cal
@A.B I have added these two pieces information, please let me know if you need anything else. Thanks!
A.B avatar
cl flag
A.B
I'm sorry, knowledge on how is AWS's network done would help. I can only offer some tests. When you try a connection, run a tcpdump on the client host and two on the this target host: one on each interface. look both for intended traffic (eg: ICMP for ping) and also for ARP traffic (you can reset ARP table on a Linux client with `ip neigh flush all`). Normally you should see the same ARP broadcast on both interfaces, or the network setup isn't what I would expect. I don't really know how to go further
ru flag
Cal
@A.B Thank you very much, let me try that.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.