Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a network that has to be configured as a loop. It consists on 3 nodes each of which has two interfaces. The diagram below explains it.

+--->(eth0) Node 1 (eth1)--->(eth0) Node 2 (eth1)--->(eth0) Node 3 (eth1)--->+
|    10.0.3.1     10.0.1.1  10.0.1.2     10.0.2.2  10.0.2.3      10.0.3.3    |
+--<----------------------------<--------------------------------------------+

I want to make a ping from Node 1 to Node 3 so the request goes through Node2 and the reply goes directly to Node 1 from Node 3.

node1$ ping 10.0.2.3

I have configured the nodes as:

node1# route add -net 10.0.2.0/24 gw 10.0.1.2

node2# route add -net 10.0.3.0/24 gw 10.0.2.3

node3# route add -net 10.0.1.0/24 gw 10.0.3.1

When running the ping, the request from Node 1 arrives at Node 3. However Node 3 doesn't reply, it does not generate even the reply (at least that I can capture with wireshark).

Could you please give me some hint?

TA

share|improve this question
add comment

3 Answers

When a node picks the source IP address for a packet it's originating, unless otherwise constrained, it typically picks the IP address "closest" to the next hop on the route to the packet's destination.

From Node 1's point of view, the next hop to Node 3 is 10.0.1.2. The Node 1 IP address closest to 10.0.1.2 is 10.0.1.1, not 10.0.3.1. (An IP address on the same subnet as the destination is considered "closer" to the destination than an IP address not on the same subnet.)

Check the source IP address of the ping. Most likely, it's 10.0.1.1, not 10.0.3.1. If Node 3 has no route to 10.0.1.1, it can't reply.

share|improve this answer
    
I have managed to make the loop. I have to include net.ipv4.conf.all.rp_filter=0 in order to get the reply generated. However when the package arrives at the destination node on the other interface, the ping doesn't considered the packet as good and therefore the ping doesn't succeed, but the packet got there. The destination and source address of the reply doesn't match the ones on the request. I guess this is the reason. –  jlanza Jan 11 '13 at 18:12
    
That's bizarre. If you're not doing any NAT, there's no reason the addresses wouldn't match. –  David Schwartz Jan 11 '13 at 18:49
    
the packet received if I recall (not in front of the system right now) has the same addresses (sorry) the issue is that as the packet is received through a different interface it seems that is not acknowledging it. I have to further test if time let me do so. –  jlanza Jan 13 '13 at 10:06
add comment

The nodes are correctly failing to repeat to prevent runaway bridge broadcasting. I recommend you run Spanning Tree Protocol. This will allow you to put fully functioning routes between all the nodes. I cannot think of another way to do this unless you are willing to limit connectivity between certain links at layer 2 or layer 3.

share|improve this answer
    
He's routing, not bridging. His nodes aren't ever repeating anything. –  David Schwartz Jan 10 '13 at 17:18
    
I was thinking on using a bridge, but as @David Schwatz says I need to have different flows for each interface. Besides, on of the interfaces is a wlan one, so I cannot include it in a bridge. –  jlanza Jan 11 '13 at 18:14
add comment

(/sbin/route is deprecated, use ip route instead).

If you want your packets to only travel in one direction, that mean every node need to use the next node as their gateway, whatever the destination is.

node1# ip route add 10.0.0.0/22 via 10.0.1.2
node2# ip route add 10.0.0.0/22 via 10.0.2.3
node3# ip route add 10.0.0.0/22 via 10.0.3.1

However, on most distributions, reverse path filtering is often enabled by default. Reverse path filtering is a filter for incoming packet which tries to check that an answer to this packet would go to the same interface the packet is received. This is a good thing on common network where routing is symetric, but in your case, you need asymetric routing, so you might just disable reverse path filtering on the interface where you receive packets, or at least reduce it so it does just check if the source IP is routable :

node1# sysctl -w net.ipv4.conf.eth0.rp_filter=2
node2# sysctl -w net.ipv4.conf.eth0.rp_filter=2
node3# sysctl -w net.ipv4.conf.eth0.rp_filter=2

Documentation about reverse path filtering and other knobs are available in the kernel documentation, at Documentation/networking/ip-sysctl.txt. Where to find that depends on your distribution (or just browse the web for ip-sysctl.txt).

Happy looping!

share|improve this answer
    
what is the meaning of net.ipv4.conf.eth0=2??? where can I find more information? –  jlanza Jan 11 '13 at 18:10
    
@jlanza: Oops, these line where wrong (rp_filter was missing). Fixed that, and updated the answer with documentation pointers. –  BatchyX Jan 11 '13 at 19:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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