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

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)

Полная конфигурация объединенного сетевого плана:

сеть:
    визуализатор: сетевой
    версия: 2
    Ethernet:
        ens5:
            адреса:
                - 172.31.1.102/20
            DHCP4: правда
            DHCP6: ложь
            соответствовать:
                MAC-адрес: 0e:dc:a1:64:a6:88
            имя набора: ens5
        ens6:
          адреса:
            - 172.31.2.201/20
            - 172.31.2.202/20
          DHCP4: нет
          маршруты:
            - до: 0.0.0.0/0
              через: 172.31.0.1 # Шлюз по умолчанию
              стол: 1000
            - на: 172.31.2.201
              через: 0.0.0.0
              область применения: ссылка
              стол: 1000
            - на: 172.31.2.202
              через: 0.0.0.0
              область применения: ссылка
              стол: 1000
          политика маршрутизации:
            - от: 172.31.2.201
              стол: 1000
            - от: 172.31.2.202
              стол: 1000

Следует отметить, что вы явно определяете маршруты к 172.31.2.201 и 172.31.2.202 в своей политике маршрутизации. В этом нет необходимости, так как это локальные адреса.

Полученная таблица маршрутизации показывает:

172.31.0.0/20 dev ens5 ссылка на область ядра proto src 172.31.1.102
172.31.0.1 dev ens5 proto dhcp scope link src 172.31.1.101 метрика 100

Конечно, вы не настроили эти маршруты как часть своей политики маршрутизации. Я не уверен, является ли это ожидаемым поведением из-за того, что это локальные маршруты на устройстве. Тем не менее, эти маршруты являются основной причиной того, что вы не можете пропинговать адреса 172.31.2.x, потому что есть два конфликтующих маршрута для 172.31.0.0/20 с одинаковой метрикой маршрута (приоритет), и есть маршрут хоста, объявляющий что ваш шлюз должен маршрутизироваться через ens5, что означает, что остальная часть вашей политики маршрутизации не имеет никакого эффекта, потому что все нелокальный трафик отправляется через ens5.

Вам нужно будет выяснить источник этих маршрутов - поскольку они не исходят из показанной вами конфигурации сетевого плана - и удалить их, чтобы решить проблему с пингом.