LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 11-16-2018, 11:59 AM   #1
matsamuel
LQ Newbie
 
Registered: Dec 2006
Posts: 3

Rep: Reputation: 0
Unhappy Packets appear not to be respecting routing table some times


Iím running 3 Raspberry Pi (running Stretch) VMs with VirtualBox and I have configured them all to be on one internal network with nothing else but these 3 VMs. They have the following IP addresses: 172.25.1.12, 172.25.1.13, 172.25.1.14. Iím trying to configure them so that when 172.25.1.12 sends packets to 172.25.1.14 the packets are routed through 172.25.1.13. And likewise when 172.25.1.14 sends packets to 172.25.1.12 the packets are also routed through 172.25.1.13.

First this is what I have done on 172.25.1.12:
sudo ip route add 172.25.1.14/32 via 172.25.1.13 dev eth0

Therefore doing an "ip route show" will show the following:
pi@raspberry:~ $ ip route show
172.25.1.0/24 dev eth0 proto kernel scope link src 172.25.1.12 metric 202
172.25.1.14 via 172.25.1.13 dev eth0


I did something similar on 172.25.1.14:
sudo ip route add 172.25.1.12/32 via 172.25.1.13 dev eth0

pi@raspberry:~ $ ip route show
172.25.1.0/24 dev eth0 proto kernel scope link src 172.25.1.14 metric 202
172.25.1.12 via 172.25.1.13 dev eth0


Also I needed to enable forwarding on the middle node i.e. 172.25.1.13:
In /etc/sysctl.conf ensure this line exists:
net.ipv4.ip_forward=1

And the run this:
sudo sysctl -p

I had a packet sniffer running on the middle node (i.e. 172.25.1.13) just to see if traffic was being passed through and sure enough pings and iperf traffic was routing through 172.25.1.13. However then it wouldnít route through 172.25.1.13 any more and instead route it directly by skipping 172.25.1.13. And I donít know why. I run traceroute and sometimes it will show the path through 172.25.1.13 and sometimes it will skip 172.25.1.13 only to go back through routing through 172.25.1.13. And Iím not really doing anything to the devices in that only time is passing.

Sometimes itíll be good:
pi@raspberry:~ $ !trace
traceroute 172.25.1.12
traceroute to 172.25.1.12 (172.25.1.12), 30 hops max, 60 byte packets
1 172.25.1.13 (172.25.1.13) 0.340 ms 0.189 ms 0.185 ms
2 172.25.1.12 (172.25.1.12) 0.446 ms 0.447 ms 0.330 ms


pi@raspberry:~ $ !trace
traceroute 172.25.1.14
traceroute to 172.25.1.14 (172.25.1.14), 30 hops max, 60 byte packets
1 172.25.1.13 (172.25.1.13) 0.330 ms 0.193 ms 0.189 ms
2 172.25.1.14 (172.25.1.14) 0.514 ms 0.415 ms 0.292 ms


And sometimes it wonít be good seemingly arbitrarily:
pi@raspberry:~ $ traceroute 172.25.1.12
traceroute to 172.25.1.12 (172.25.1.12), 30 hops max, 60 byte packets
1 172.25.1.12 (172.25.1.12) 0.333 ms 0.190 ms 0.197 ms


pi@raspberry:~ $ traceroute 172.25.1.14
traceroute to 172.25.1.14 (172.25.1.14), 30 hops max, 60 byte packets
1 172.25.1.14 (172.25.1.14) 0.348 ms 0.198 ms 0.198 ms


Ultimately I would like the packets routed through 172.25.1.13 all the time so if you have any ideas as to why that is not happening consistently that would be helpful.
 
Old 11-17-2018, 10:58 AM   #2
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 3,303

Rep: Reputation: Disabled
When a router receives a packet from host A that is to be delivered via gateway B, and it determines that host A and gateway B are in fact in the same IP network, it will inform the sender by means of an ICMP Redirect message that the packet could/should be sent via an alternate path.

The same happens if the recipient is in the same network as the incoming interface of the gateway, which is the case in your scenario. The ICMP Redirect message will tell the sender that the packet can be delivered directly to the recipient.

The standard does not dictate that an IP host has to process incoming ICMP Redirect messages, and likewise it's not mandatory for IP routers to generate them. These are the relevant files in /proc that control this behaviour:
Code:
/proc/sys/net/ipv4/conf/all/accept_redirects
/proc/sys/net/ipv4/conf/default/accept_redirects
/proc/sys/net/ipv4/conf/<interface name>/accept_redirects

/proc/sys/net/ipv4/conf/all/send_redirects
/proc/sys/net/ipv4/conf/default/send_redirects
/proc/sys/net/ipv4/conf/<interface name>/send_redirects
 
1 members found this post helpful.
Old 11-18-2018, 09:01 AM   #3
matsamuel
LQ Newbie
 
Registered: Dec 2006
Posts: 3

Original Poster
Rep: Reputation: 0
Smile

Hey thank you for your response! Following your suggestion I changed the /proc/sys/net/ipv4/conf/eth0/send_redirects file to "0" and it seems as if the packet path that I want to have used is consistently used now. Thanks for that!
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Grrr! vfat not respecting all uppercase filenames wonkocz Linux - Newbie 15 11-11-2010 12:37 PM
GTK apps not respecting Compose Key josiah Slackware 0 02-12-2010 08:33 PM
Debian NIS not respecting /etc/defaultdomain scavswm Debian 2 08-18-2008 10:15 AM
Ubuntu not respecting /etc/fstab options? mcd Linux - Hardware 2 10-18-2007 10:19 PM
GTK Applications Not Respecting Subpixel Settings tvynr Linux - Desktop 1 09-06-2006 06:42 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 10:00 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration