0

An vmware VM is assigned two IPs. We can only ping one of the two IPs from VMs on the same network.

2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:50:56:98:87:db brd ff:ff:ff:ff:ff:ff
inet 10.233.0.2/16 brd 10.233.255.255 scope global ens160
   valid_lft forever preferred_lft forever
inet 10.233.0.3/16 brd 10.233.255.255 scope global secondary ens160
   valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe98:87db/64 scope link
   valid_lft forever preferred_lft forever

Source is 10.233.15.102 and the test shows 10.233.0.2 is pingable but 10.233.0.3 is not.

$ ping 10.233.0.3
PING 10.233.0.3 (10.233.0.3) 56(84) bytes of data.
From 10.233.0.3 icmp_seq=1 Destination Port Unreachable
From 10.233.0.3 icmp_seq=2 Destination Port Unreachable
From 10.233.0.3 icmp_seq=3 Destination Port Unreachable

$ ping 10.233.0.2
PING 10.233.0.2 (10.233.0.2) 56(84) bytes of data.
64 bytes from 10.233.0.2: icmp_seq=1 ttl=64 time=0.502 ms
64 bytes from 10.233.0.2: icmp_seq=2 ttl=64 time=0.155 ms
64 bytes from 10.233.0.2: icmp_seq=3 ttl=64 time=0.171 ms

When source is 10.233.14.102 the test shows that both 10.233.0.2 and 10.233.0.3 are pingable.

$ ping 10.233.0.2
PING 10.233.0.2 (10.233.0.2) 56(84) bytes of data.
64 bytes from 10.233.0.2: icmp_seq=1 ttl=64 time=0.223 ms
64 bytes from 10.233.0.2: icmp_seq=2 ttl=64 time=0.175 ms

$ ping 10.233.0.2
PING 10.233.0.2 (10.233.0.2) 56(84) bytes of data.
64 bytes from 10.233.0.2: icmp_seq=1 ttl=64 time=0.252 ms

What could be the reason for this?

Vladimir
  • 179
  • 1
  • 1
  • 6
  • I've extensively used multiple IP addresses per vNIC without problems. Are you sure neither the local firewall (iptables) nor the network (switch ACL) is filtering? Does the ARP table get populated? – Zac67 Jul 26 '23 at 11:50
  • @Zac67 Yes they did get populated with wrong MAC addresses. See my answer for more details. – Vladimir Jul 27 '23 at 09:06

1 Answers1

1

It turns out there was a kubernetes cluster that was using the same range 10.233.0.0/24 for its internal network. This caused the arp tables to get populated with their MAC addresses.

Vladimir
  • 179
  • 1
  • 1
  • 6