Score:1

Can't ping after adding secondary network interface in aws ec2

ec flag
Cal

Ubuntu version 20.04.

First we created a 2nd private IP on the only (primary) network interface. Both private IP addresses could be pinged. Now the instance has 2 private IP addresses, 1 public IP address.

Then we attached a secondary network interface with two private IP addresses (no public IP address) and attached to the instance, then added .yaml configuration, following this article. Now the instance has 4 private IP addresses, 1 public IP address. All four private IP addresses could not be pinged.

                             First Private IP   Second Private IP
Primary Network Interface    172.31.1.101       172.31.1.102
Secondary Netwk Interface    172.31.2.201       172.31.2.202

Primary network interface's /etc/netplan/50-cloud-init.yaml :

network:
    ethernets:
        ens5:
            addresses:
                - 172.31.1.102/20
            dhcp4: true
            dhcp6: false
            match:
                macaddress: 0e:dc:a1:64:a6:88
            set-name: ens5
    version: 2

Secondary network interface's /etc/netplan/51-ens6.yaml :

network:
  version: 2
  renderer: networkd
  ethernets:
    ens6:
      addresses:
        - 172.31.2.201/20
        - 172.31.2.202/20
      dhcp4: no
      routes:
        - to: 0.0.0.0/0
          via: 172.31.0.1 # Default gateway
          table: 1000
        - to: 172.31.2.201
          via: 0.0.0.0
          scope: link
          table: 1000
        - to: 172.31.2.202
          via: 0.0.0.0
          scope: link
          table: 1000
      routing-policy:
        - from: 172.31.2.201
          table: 1000
        - from: 172.31.2.202
          table: 1000

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: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 0e:54:c0:50:88:04 brd ff:ff:ff:ff:ff:ff
    inet 172.31.1.102/20 brd 172.31.15.255 scope global ens5
       valid_lft forever preferred_lft forever
    inet 172.31.1.101/20 brd 172.31.15.255 scope global secondary dynamic ens5
       valid_lft 3574sec preferred_lft 3574sec
    inet6 fe80::c54:c0ff:fe50:8804/64 scope link
       valid_lft forever preferred_lft forever
3: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 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 ens6
       valid_lft forever preferred_lft forever
    inet 172.31.2.202/20 brd 172.31.15.255 scope global secondary ens6
       valid_lft forever preferred_lft forever
    inet6 fe80::cff:4aff:feaa:cb66/64 scope link
       valid_lft forever preferred_lft forever

ip r show table 1000 output:

default via 172.31.0.1 dev ens5 proto dhcp src 172.31.1.101 metric 100
172.31.0.0/20 dev ens6 proto kernel scope link src 172.31.2.201
172.31.0.0/20 dev ens5 proto kernel scope link src 172.31.1.102
172.31.0.1 dev ens5 proto dhcp scope link src 172.31.1.101 metric 100

ip rule output:

0:      from all lookup local
0:      from 172.31.2.201 lookup 1000
0:      from 172.31.2.202 lookup 1000
32766:  from all lookup main
32767:  from all lookup default

netplan --debug generate output:

DEBUG:command generate: running ['/lib/netplan/generate']
** (generate:2245): DEBUG: 00:33:01.254: Processing input file /etc/netplan/50-cloud-init.yaml..
** (generate:2245): DEBUG: 00:33:01.254: starting new processing pass
** (generate:2245): DEBUG: 00:33:01.255: Processing input file /etc/netplan/51-ens6.yaml..
** (generate:2245): DEBUG: 00:33:01.255: starting new processing pass
** (generate:2245): DEBUG: 00:33:01.255: We have some netdefs, pass them through a final round of validation
** (generate:2245): DEBUG: 00:33:01.255: ens5: setting default backend to 1
** (generate:2245): DEBUG: 00:33:01.255: Configuration is valid
** (generate:2245): DEBUG: 00:33:01.255: ens6: setting default backend to 1
** (generate:2245): DEBUG: 00:33:01.255: Configuration is valid
** (generate:2245): DEBUG: 00:33:01.255: Generating output files..
** (generate:2245): DEBUG: 00:33:01.255: NetworkManager: definition ens5 is not for us (backend 1)
** (generate:2245): DEBUG: 00:33:01.255: NetworkManager: definition ens6 is not for us (backend 1)
(generate:2245): GLib-DEBUG: 00:33:01.255: posix_spawn avoided (fd close requested)
Score:0
us flag

The full merged netplan config is:

network:
    renderer: networkd
    version: 2
    ethernets:
        ens5:
            addresses:
                - 172.31.1.102/20
            dhcp4: true
            dhcp6: false
            match:
                macaddress: 0e:dc:a1:64:a6:88
            set-name: ens5
        ens6:
          addresses:
            - 172.31.2.201/20
            - 172.31.2.202/20
          dhcp4: no
          routes:
            - to: 0.0.0.0/0
              via: 172.31.0.1 # Default gateway
              table: 1000
            - to: 172.31.2.201
              via: 0.0.0.0
              scope: link
              table: 1000
            - to: 172.31.2.202
              via: 0.0.0.0
              scope: link
              table: 1000
          routing-policy:
            - from: 172.31.2.201
              table: 1000
            - from: 172.31.2.202
              table: 1000

One thing of note here is that you are explicitly defining routes to 172.31.2.201 and 172.31.2.202 in your routing policy. This should be unnecessary as these are local addresses.

Your resulting routing table shows:

172.31.0.0/20 dev ens5 proto kernel scope link src 172.31.1.102
172.31.0.1 dev ens5 proto dhcp scope link src 172.31.1.101 metric 100

Of course, you have not configured these routes as part of your routing policy. I'm unsure if this is expected behavior as a result of these being link-local routes on the device. Nevertheless, these routes are the root cause of you being unable to ping the 172.31.2.x addresses, because there are two conflicting routes for 172.31.0.0/20 with the same route metric (priority), and there is a host route declaring that your gateway should be routed via ens5, which means the rest of your routing policy is to no effect because all non-local traffic is being sent out via ens5.

You will need to work out the source of these routes - since they don't come from the netplan config you've shown - and remove them, in order to fix your ping problem.

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.