1

I have PCa and PCb.

PCa:

$> ip addr && ip route
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    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: eth6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:13:3b:0f:24:fc brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.150/24 brd 192.168.3.255 scope global eth6
       valid_lft forever preferred_lft forever
    inet6 fe80::213:3bff:fe0f:24fc/64 scope link 
       valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether f8:b1:56:ba:ae:ee brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.150/24 brd 192.168.10.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.1.150/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 172.18.0.150/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2a00:801:19:1:288f:db46:14ef:cca8/64 scope global temporary dynamic 
       valid_lft 546270sec preferred_lft 27270sec
    inet6 2a00:801:19:1:50c3:7b14:61bc:1bc0/64 scope global temporary deprecated dynamic 
       valid_lft 460473sec preferred_lft 0sec
    inet6 2a00:801:19:1:fab1:56ff:feba:aeee/64 scope global dynamic 
       valid_lft 2591993sec preferred_lft 604793sec
    inet6 fe80::fab1:56ff:feba:aeee/64 scope link 
       valid_lft forever preferred_lft forever
5: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default 
    link/gre 10.110.2.204 brd 10.110.0.115
6: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
7: netgw@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1256 qdisc noqueue state UNKNOWN group default 
    link/gre 10.110.1.222 peer 10.110.0.115
    inet 192.168.4.1/24 scope global netgw
       valid_lft forever preferred_lft forever
default via 172.18.0.1 dev eth0 
169.254.0.0/16 dev eth6  scope link  metric 1000 
172.18.0.0/24 dev eth0  proto kernel  scope link  src 172.18.0.150 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.150 
192.168.3.0/24 dev eth6  proto kernel  scope link  src 192.168.3.150 
192.168.5.0/24 dev netgw  scope link 
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.150

PCb:

bash# ip addr && ip route
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:05:68:02:68:dd brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.1/24 brd 192.168.3.255 scope global eth0
3: tunl0: <NOARP> mtu 1480 qdisc noop 
    link/ipip 0.0.0.0 brd 0.0.0.0
4: gre0: <NOARP> mtu 1476 qdisc noop 
    link/gre 0.0.0.0 brd 0.0.0.0
5: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:05:68:03:68:dd brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.2/24 brd 192.168.3.255 scope global eth1
7: netpc@NONE: <POINTOPOINT,NOARP,UP,10000> mtu 1476 qdisc noqueue 
    link/gre 10.110.0.115 peer 10.110.1.222
    inet 192.168.5.1/24 scope global netpc
19: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1280 qdisc pfifo_fast qlen 3
    link/ppp 
    inet 10.110.1.16 peer 192.168.111.111/32 scope global ppp0
192.168.111.111 dev ppp0  proto kernel  scope link  src 10.110.1.16 
10.99.196.40 dev ppp0  scope link 
8.8.8.8 dev ppp0  scope link 
192.168.4.0/24 dev netpc  scope link 
192.168.3.0/24 dev eth0  proto kernel  scope link  src 192.168.3.1 
172.18.0.0/24 dev eth0  scope link 
224.0.0.0/4 dev eth0  scope link

PCa, eth6 is connected to PCb, eth0 via Ethernet cable.

Now, ping 172.18.0.150 on PCb gives:

bash# ping 172.18.0.150
PING 172.18.0.150 (172.18.0.150) 56(84) bytes of data.
64 bytes from 172.18.0.150: icmp_seq=1 ttl=64 time=4.31 ms
64 bytes from 172.18.0.150: icmp_seq=2 ttl=64 time=0.848 ms

So the ping goes out on eth0 on PCb I assume, and comes in on eth6 on PCa. The thing is that it is eth0 on PCa that has the 172.18.0.150 IP address. How come I get a reply from eth0 on PCa, when eth0 on PCb is really connected to eth6 on PCa?

Isn't the IP only tied to the interface itself? Is this the expected behaviour? Never mind the tunnels and stuff...

3

Yes, it's the expected behavior. The ping reply is an IP packet in its own right and it isn't somehow specially connected to the packet it's a reply to. IP packets don't form "circuits" for replies to follow, each packet is routed independently.

Asymmetric routing is very common on the Internet. For example, with traffic that crosses a country, the destination network typically does the long hauling. So if I ping a server on the other side of the country, his provider carries the query across the country but my provider carries the reply across the country. So the two routes are very, very different. There's no special reason one path should look anything like the other.

| improve this answer | |
  • But it is the interface that has the IP address, not the computer itself, right? – JohnyTex May 21 '15 at 7:28
  • 1
    @JohnyTex That depends on the host model. Most commonly, the IP address belongs to the computer itself. – David Schwartz May 21 '15 at 9:10
  • 1
    @JohnyTex Mainly because that was how older systems did it and because it's sometimes easier to assign and manage them that way. But for people who deal regularly with asymmetric routing and more complex setups, it can be a source of irritation, requiring IP addresses be assigned to dummy interfaces and other such annoyances. Think of it like the it in "it's raining out". The language requires you to have an "it" in order to say there's rain, but there is no thing that's actually raining. – David Schwartz May 21 '15 at 9:29
  • 1
    @JohnyTex It makes no difference whether the routing is symmetric or asymmetric. They're treated exactly the same. My point in bringing up asymmetric routing is to make you stop thinking about the routing as symmetric as if that mattered. It happens to be true, but it also makes no difference. – David Schwartz May 21 '15 at 9:30
  • 1
    OK, I believe I understand now. Thx for your advice! – JohnyTex May 21 '15 at 9:31
1

I think this has more to do with default gateway if your using Linux. As all the interfaces are on the same host any outbound traffic will be via the default gateway and it's associated interface.

So what that means is that even though pinged a particular IP address the reply came through the default gateway which means it came from the interface associated with the default gateway.

Try the following to see the default route and the interfaces used for a given IP address.

ip route

Run as root or using sudo.

| improve this answer | |
0

Has this anything to do with scobe global/scope link etc?

It probably has to do with routing tables and metrics. Try

netstat -nr

in a command prompt on PCb

I expect PCb is convinced that it's Eth2 interface is "nearer" than Eth1 to PCa.

The metric shown in the output of netstat is a measure of desirability of a route. It used to be a hop-count but it's best to think of it as a priority value as different routing protocols measure the cost of routes in different ways.

You can temporarily manipulate routing tables using the route command (see route /?)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.