3

I am setting up a testbed for some VMs. These routes need to be static as this is an academic project. (I know that doing this manually is generally a bad idea. Trust me, I have a reason for this.)

I'm running into an issue where my hosts on the far ends cannot ping each other unless the route to and from go through all of the same hosts. Can someone help and explain why this is? Is there any way that I can set it up so that the return route is separate? For example, in the image below, can I make the ping out from n0 go through n1 -> n2 -> n4 -> n5 and return on n5 -> n4 -> n3 -> n1 -> n0?

Here is my network. Everything is a 10.1.y.x address. The links are shown with the last two octets.

              n2
            /     \
           / 2.x   \6.x
   5.x    /         \     4.x
n0 ---- n1           n4 ----- n5
          \         /
           \ 3.x   /1.x
            \     /
              n3 

Here are the routing tables for each, if that makes it clearer. All taken from "ip route":

n0

10.1.4.0/24 via 10.1.5.3 dev eth2 
10.1.5.0/24 dev eth2  proto kernel  scope link  src 10.1.5.2 
10.1.6.0/24 via 10.1.5.3 dev eth2 
10.1.1.0/24 via 10.1.5.3 dev eth2 
10.1.2.0/24 via 10.1.5.3 dev eth2 
10.1.3.0/24 via 10.1.5.3 dev eth2 

n1

10.1.4.0/24 via 10.1.3.3 dev eth3 
10.1.5.0/24 dev eth2  proto kernel  scope link  src 10.1.5.3 
10.1.6.0/24 via 10.1.2.3 dev eth4 
10.1.1.0/24 via 10.1.3.3 dev eth3 
10.1.2.0/24 dev eth4  proto kernel  scope link  src 10.1.2.2 
10.1.3.0/24 dev eth3  proto kernel  scope link  src 10.1.3.2

n2

10.1.4.0/24 via 10.1.6.3 dev eth2 
10.1.5.0/24 via 10.1.2.2 dev eth4 
10.1.6.0/24 dev eth2  proto kernel  scope link  src 10.1.6.2 
10.1.1.0/24 via 10.1.6.3 dev eth2 
10.1.2.0/24 dev eth4  proto kernel  scope link  src 10.1.2.3 
10.1.3.0/24 via 10.1.2.2 dev eth4 

n3

10.1.4.0/24 via 10.1.1.3 dev eth4 
10.1.5.0/24 via 10.1.3.2 dev eth3 
10.1.6.0/24 via 10.1.1.3 dev eth4 
10.1.1.0/24 dev eth4  proto kernel  scope link  src 10.1.1.2 
10.1.2.0/24 via 10.1.3.2 dev eth3 
10.1.3.0/24 dev eth3  proto kernel  scope link  src 10.1.3.3

n4

10.1.4.0/24 dev eth3  proto kernel  scope link  src 10.1.4.2 
10.1.5.0/24 via 10.1.6.2 dev eth2 
10.1.6.0/24 dev eth2  proto kernel  scope link  src 10.1.6.3 
10.1.1.0/24 dev eth4  proto kernel  scope link  src 10.1.1.3 
10.1.2.0/24 via 10.1.6.2 dev eth2 
10.1.3.0/24 via 10.1.1.2 dev eth4

n5

10.1.4.0/24 dev eth2  proto kernel  scope link  src 10.1.4.3 
10.1.5.0/24 via 10.1.4.2 dev eth2 
10.1.6.0/24 via 10.1.4.2 dev eth2 
10.1.2.0/24 via 10.1.4.2 dev eth2 
10.1.3.0/24 via 10.1.4.2 dev eth2
2
  • 1
    Are there any firewall features running on any of these?
    – YLearn
    Nov 25, 2015 at 3:08
  • to precise the reason for @YLearn insightful question : if you have a firewall along the way : if it only sees an "ack" in reply to a "syn" it didn't see pass through, it will likely drop the ack paquet, as it is for an unknown (to that fw) communication, one it didn't see open. Nov 25, 2015 at 12:15

3 Answers 3

4

You should remove reverse path filtering on your linux routers (n1 to n4). https://access.redhat.com/solutions/53031

1
  • This does the trick on the default Ubuntu machines I'm using. In case the link dies, here's the command to take them down: sudo sysctl -w net.ipv4.conf.all.rp_filter=2 sudo sysctl -w net.ipv4.conf.default.rp_filter=2
    – Maxthecat
    Nov 27, 2015 at 21:14
4

can I make the ping out from n0 go through n1 -> n2 -> n4 -> n5 and return on n5 -> n4 -> n3 -> n1 -> n0?

Yes, you can.

As per the information in your post, n0's IP address is 10.1.5.2. Therefore to alter the return path you will need to change the route for 10.1.5.0 on n4.

Currently it looks like this:

10.1.5.0/24 via 10.1.6.2 dev eth2 

What you will need to do is change it to this:

10.1.5.0/24 via 10.1.1.2 dev eth4

The reason being that your current route (10.1.5.0/24 via 10.1.6.2 dev eth2) points to n2, whereas "10.1.1.2 dev eth4" points to n3 as per your diagram.

Therefore my suggested change above says "traffic which hits n4 and has a destination IP address of 10.1.5.0/24 can reach its destination by going through eth4."

In other words, this will result in traffic flowing in the following manner: n5 - n4 - n3 - n1 - n0. In other words, traffic from n5 to n0 will go via n3.

In order for traffic in the opposite direction to take the other route (n0 - n1 - n2 - n4 - n5, in other words, traffic from n0 to n5 will go via n2) you will need to do the following:

Remove this from n1:

10.1.4.0/24 via 10.1.3.3 dev eth3

And add this on n1:

10.1.4.0/24 via 10.1.2.3 dev eth4
5
  • Right. That will put everything going through n0 - n1 - n3 - n4 - n5. So, if on n1 I add 10.1.4.0/24 via 10.1.2.2 (n2), that should work, right? Outbound traffic from n0 would go through the top path and return through the bottom? Whenever I tried that (asymmetric routing) I never got the pings back. I will give it another go.
    – Maxthecat
    Nov 25, 2015 at 5:41
  • I edited my answer to include more details. Hopefully that answers your question.
    – OzNetNerd
    Nov 25, 2015 at 5:51
  • @Maxthecat have you had a chance to see if the above solution resolved your issue?
    – OzNetNerd
    Dec 1, 2015 at 2:49
  • Thanks, your answer was incredibly insightful. The solution does work, but my primary error was in not removing the reverse path filtering in Linux, which Xavier suggested. Since I can only pick one answer, I went with that, but yours certainly gets an upvote for the insight.
    – Maxthecat
    Dec 1, 2015 at 13:52
  • No worries at all :) I'm glad you were able to resolve the issue.
    – OzNetNerd
    Dec 1, 2015 at 19:51
-1

For having bidirectional static route Configuration for N1->N2->N3 ,and from N3->N2-N1 is for both forward and reverse traffic from client -> server & server --> client

To ensure communication between Client and server before actually session start ,TCP handshake should be successful complete then only actually session establish between client and servers for exchanging data . For TCP handshake and for actuall data transfer both client--->server & server-client network path souce be through . Because of this reason bidirectional static routes are required .

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.