0

I have such a topology made of network namespaces and veth pairs:

------                           ------                            ------
| a1 |                           | r1 |                            | r2 |
|    | a1-eth0-----------r1-eth0 |    |r1-eth1--------------r2-eth1|    |
-----(11.0.0.1/30)   (11.0.0.2/30)----(11.0.0.9/30)   (11.0.0.10/30)-----

For r1, net.ipv4.ip_forward is 1.

I can successfully ping r2 by a1 with the command:

ping -I a1-eth0 -c1 11.0.0.10

Also, I can successfully ping r2 by r1 using r1-eth1 interface with the command:

ping -I r1-eth1 -c1 11.0.0.10

But then, why can't I ping r2 by r1 using r1-eth0 interface? I get Destination Host Unreachable:

ping -I r1-eth0 -c1 11.0.0.10
PING 11.0.0.10 (11.0.0.10) from 11.0.0.2 r1-eth0: 56(84) bytes of data.
From 11.0.0.2 icmp_seq=1 Destination Host Unreachable

--- 11.0.0.10 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

The same way, I cannot ping one interface of router r1 by another interface of this very router:

# here I get Destination Host Unreachable again:
ping -I r1-eth0 -c1 11.0.0.9

# here I get Redirect Host(New nexthop: 11.0.0.9):
ping -I r1-eth1 -c1 11.0.0.2

Here is the main route table of r1:

ip route
default via 11.0.0.10 dev r1-eth1 
11.0.0.0/30 dev r1-eth0  proto kernel  scope link  src 11.0.0.2 
11.0.0.8/30 dev r1-eth1  proto kernel  scope link  src 11.0.0.9

So to me it looks like the problem is that interfaces of the router r1 cannot communicate between each other. However, r1 forwards traffic between a1 and r2 normally.

Thank you for attention!

UPDATE:

I needed to solve the problem discussed above to solve the problem Tc qdisc delay not seen in tcpdump recording. I have found the solution to that problem and I posted there by the link. So I do not need this question anymore and I close it. Thank you everybody for reading and participating!

JenyaKh
  • 304
  • 4
  • 14
  • Please edit the question and describe which network namespaces you have created, and how you are executing the `ping` inside a particular network namespace. (In the question as written, I don't see any network namespaces at all besides names for them. And in particular you shouldn't need `ping -I ...` if inside a network namespace). If you didn't create network namespaces, and did all of it from the main namespace, it won't work because the kernel considers it to be a routing error (though it can be made to work with a lot of effort). But creating the namespaces would be the proper fix. – dirkt Jun 28 '19 at 08:22

1 Answers1

2

Why do you want to send packets via the wrong interface, i.e. using an interface that has no connection to the network you want to reach? This is like jumping on a subway train on the wrong platform. Interfaces don't communicate with each other, hosts do. Hosts communicate with other hosts over networks. Interface selection is done based on routing table entries. As far as I can tell, your ping commands should work if you remove the -I options altogether.

Johan Myréen
  • 12,862
  • 1
  • 32
  • 33
  • Well, it's a long story. I try to solve this problem: https://unix.stackexchange.com/questions/523600/tc-qdisc-delay-not-seen-in-tcpdump-recording. On sender host I want to create dummy interface and send data intended for receiver host from the dummy interface via the main interface. This way I want to be able to see netem delay set up on the main interface in the tcpdump recording turned on the main interface. – JenyaKh Jun 27 '19 at 19:53