The two devices sit in two different logical /32 networks and there is no route or routing table hinting at the manner by which to contact each host.
If you execute # ip netns exec red ip route get 192.168.15.2
it will answer with RTNETLINK answers: Network is unreachable
. Because the routing table has no answer for how to send a packet to the 192.168.15.2/32 network.
If you add the routes in both directions however, this should act as hint that the two hosts are neighbours (more like directly connected peers technically) and the packets should send.
ip netns exec red ip route add 192.168.15.2/32 dev v-red
ip netns exec blue ip route add 192.168.15.1/32 dev v-blue
You can then print the routing table of one see how now a route is instructed.
ip netns exec blue ip route list
192.168.15.1 dev v-blue scope link
Be aware, its entirely valid to actually use a default route here instead (ip netns exec red ip route add default dev v-red
) since that covers all hosts, not just the one you know exists on the other side, but for the sake of understanding what the problem is here I've added the specific hosts you were seeking to communicate with.
At this point, (firewalls permitting) pinging should work as expected.