A little help in understanding routed mode

[pcbona]

I am trying to install this application on a ubuntu server LTS (20.04) VM. We dont want to use vlans, so we are looking into running this thing in routed mode. So my understanding is like this:

The server has only 1 interface (apart from the loopback). There is an IP address on this interface but this is just for management purposes. Then, we configure a different IP for the ipsla appliaction. It then, should handle the ARP responses and so on. Because the IP the responder uses is in the same network as the interface IP, we dont have to do any routing. Here is our configuration:

root@srvmwips01:/tmp/ip-sla-responder-master# ifconfig
ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet **172.16.222.188**  netmask 255.255.255.0  broadcast 172.16.222.255
        inet6 fe80::250:56ff:fe98:ac82  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:98:ac:82  txqueuelen 1000  (Ethernet)
        RX packets 1639398  bytes 247823058 (247.8 MB)
        RX errors 0  dropped 252  overruns 0  frame 0
        TX packets 20853  bytes 2449751 (2.4 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 152  bytes 12778 (12.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 152  bytes 12778 (12.7 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


root@srvmwips01:/tmp/ip-sla-responder-master# more /etc/responder.conf
# set to 0 if you do not wish to support dot1q vlans
vlansupport=0

# set for ipv4 support
ipaddress=**172.16.222.248**

# set for ipv6 support
#ip6address=2001:6e8:280::1:342d

# interface to listen on (defaults to first non-loopback)
iface=ens160

# debug level (0 = nothing, 1 = something, 2 = with packet dumps)
debuglevel=1

# mac address (defaults to interface if nothing given)
mac=de:ad:be:ef:00:01

# cisco ip sla port range (defaults to 50505)
#ciscoport=50505
ciscoport=50000:60000

Although i cant ping this IP from the switch (dunno if the ip sla responder is supposed to answer to icmp) i can see that the arp gets resolved to the defined MAC address:

swRZ201#ping 172.16.222.248 repeat 2 
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 172.16.222.248, timeout is 2 seconds:
..
Success rate is 0 percent (0/2)
swRZ201#show ip arp | include 222.248
Internet  172.16.222.248          0   dead.beef.0001  ARPA   Vlan222

If i check the mac address table on the switch, i can see that both MACs (ens160 & responder application) are pointing to the same interface:

swRZ201#show mac address-table | include dead.beef.0001|0050.5698.ac82
 222    0050.5698.ac82    DYNAMIC     Te4/0/2
 222    dead.beef.0001    DYNAMIC     Te4/0/2

If i start an IP sla from a remote device, it always fails:

swINF02#show running-config | section ip sla
ip sla 20
 udp-jitter 172.16.222.248 50001
 history enhanced interval 900 buckets 100
ip sla schedule 20 life forever start-time now
swINF02#show ip sla statistics | include ^Number
Number of successes: 0
Number of failures: 13

I can see that the packets are coming into the VM, but the responder application does not answer it seems. I thought this could be a default gateway missing issue. But it doesnt respond to a IP SLA probe that is sent from within the same 222 network. Am i missing something in my setup? What is the best practice?

By the way, i know that this application is no longer maintained and i dont have the right to demand support whatsoever. Just hoping that the dev maybe is still subscribed to this project and has a few minutes to shed some light to this one. I am so desperate to get this software going. We want to deploy lots of IP SLA probes, but dont have the firepower on the networking infrastructure to handle this high amount.

[pcbona]

Just as i was done submitting this question, a new idea poppt into my mind. I overruled the default distribute port policy in VMware vCenter called promiscuous mode. I changed it from reject to accept. Now all the sensors are working great. This default setting filters out any traffic to and from a VM that is not supposed to come from or go to this VM. As VMware does not have any idea that another IP resides on this host, it filters traffic to this IP address. Now, it does not filter anything anymore which is what we want. Hopefully, this helps someone else that has the same issue in the future.

[pcbona]

We just found out, that the IP SLA responder service only answers, when the NIC has other traffic coming in. We went so deep as to install ip sla responder on a physical machine.

swTST01#ping 172.16.220.50 repeat 50 Type escape sequence to abort. Sending 50, 100-byte ICMP Echos to 172.16.220.50, timeout is 2 seconds: ..........!..!!!!!!!...!..........................
You can see, that we initially dont get a response from the IP of the IP SLA responder application. In a seperate session, we start a ping to the physiscal IP of the interface:
swTST01#ping 172.16.220.6 repeat 500 Type escape sequence to abort. Sending 500, 100-byte ICMP Echos to 172.16.220.6, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!
So as this ping, who always replies, progresses, we can get replies from the ip sla ip as well. as soon as the ping to the IP .6 finished, we cannot get a response from the .50 anymore. We tested this with IP SLA configuration from switches as well. So the
The promiscuous mode just facilitates this as there is constant traffic from other VMs coming in, therefore encouragin a reply.