Route command output - linux

Route command output:
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.10 0.0.0.0 UG 0 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
$
From the above output the following are the doubts I have:
What is 0.0.0.0 means in destination and gateway column
If the packet is sent from 192.168.2.36 ip, what is the gateway for that. It use 192.168.2.10 or 0.0.0.0
Lets consider I have one more network with ip 192.168.1.0. If the packet is sent from any of the host from this network, what is the
gateway for that ip.
What is default gateway.

On the first line, 0.0.0.0 in Genmask means there is no mask, i.e. in combination with a destination of 0.0.0.0, it means all destinations (the default gateway definition). On the second line, 0.0.0.0 in the gateway column means no gateway (directly connected the local subnet).
When routing, it does not matter where you are sending from, but where you are sending to.
Packets sent to network 192.168.1.0 will be routed using gateway 192.168.2.10, since the first line is the only one that matches destination 192.169.1.0.
192.168.2.10 (see answer 1).

Related

Does routing affect a socket with a bound source address?

Let's say I have two network interfaces:
eth0 with address 10.0.0.1
eth1 with address 192.168.0.1
Using route or ip route add I have set it to route:
All addresses to eth0
1.2.3.4 only to eth1
So packets to 1.2.3.4 should be routed to eth1, and everything else to eth0.
I then create a UDP socket and use bind() to set its local address to 192.168.0.1. Then I send a packet to 1.2.3.4.
Will it be be sent over eth1 per the routing table or eth0 because it is bound to that IP address? I tried, and it seems to be sent on eth1.
Is there a way I can force a socket to use eth0, which has a valid route to the destination, but not the most specific rule? I know about SO_BINDTODEVICE, but prefer to avoid using interface names in C code.
For sockets if you want the the Kernel and its routing table to pick the best interface for you using any available port you don't have to call bind() before sending datagram socket.
If you do bind a socket, it will be bound to a network device with that specific IP address. But does it make sense if packet can't reach destination address from that network device?

Use ip route add to add multicast routes to multiple devices

TLDR: Is there a way to use "ip route" to add multicast routes for multiple NICs?
We have software that joins two sockets bound to different ip addresses on separate NICS to two separate multicast groups, eg socket 1 is bound to 192.168.0.2 and joined to multicast group 233.255.10.1 while socket 2 is bound to 10.57.31.2 and joined to multicast group 239.255.100.1.
We are currently using a bash script (Linux kernel 3.14.39) to set multicast routes on the two network interfaces using route, eg
route add -net 224.0.0.0 netmask 240.0.0.0 eth0
route add -net 224.0.0.0 netmask 240.0.0.0 eth1
and verified via route -n
Destination Gateway Genmask Flags Metric Ref Use Iface
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth0
224.0.0.0 0.0.0.0 240.0.0.0 U 0 0 0 eth1
I recently read that route was deprecated/obsolete and that we should be using ip route instead, eg
ip route add 224.0.0.0/4 dev eth0
ip route add 224.0.0.0/4 dev eth1
Unfortunately, the second call fails with "RTNETLINK answers: File exists" and of course the second route doesn't show up after these calls.
Is there a way to use ip route to add multicast routes to multiple NICs?
I can use /8 as a netmask? eg
ip route add 233.0.0.0/8 dev eth0
and
ip route add 239.0.0.0/8 dev eth1
but this is problematic as the script that does this is not aware of what multicast address is associated with which device and its not always guaranteed to be the same depending on system configuration. Using my first example of route add makes this a non issue.

Two gateway routing issue

I have two NICs.
On eth1 IP is 10.135.28.86/16.
On eth IP is 135.251.8.43/24.
My routing table is like below:
135.251.8.0/24 dev eth1 proto kernel scope link src 135.251.8.43
10.135.0.0/16 dev eth0 proto kernel scope link src 10.135.28.86
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth1 scope link metric 1003
10.0.0.0/8 via 10.135.0.1 dev eth0
default via 135.251.8.1 dev eth1
Now if I ping 10.135.28.86 from 10.34.7.103, it's OK, while if I ping 135.251.8.43 from 10.34.7.10, it fails.
And if I ping my public IP 135.251.8.43 from 135.252.11.7, it's OK, if I ping 10.135.28.86, it fails.
However, on my other machines which have exactly the same subnet and gateway configured, I can ping both IP either from 10.34.7.103 or 135.252.11.7.
Any ideas on this?
I used tcpdump to capture icmp packet on other machines and found that echo request come in eth0 and echo reply out from eth1.
but on this machine no echo reply were captured.
When you ping from your other machines with IP's in both networks the machine uses the interface on the same network to send the packet (so private-to-private and public-to-public, since they are on directly connected subnets). That is why it reaches, they are on the same subnet.
I see 2 scenarios.
1.
The machine which only has IP on your private network (10.34.7.10) probobly sends its ping to dgw (IP?) which then forwards it to 135.251.8.43 (eth0).
But since the source adress (10.34.7.10) is on a network directly connected to it's other interface (eth1) the answer will be sent back there. I would say you have a flawed network architecture.
The machine 10.34.7.10 has a static route for 135.251.8.43 to 10.135.28.86, but your machine has not bridged the 2 networks.

ip routing table basics [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
Could you please explain the following basic ip routing table:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.80.0.0 192.176.20.1 255.255.255.0 UG 0 0 0 eth0
192.176.100.0 * 255.255.255.0 U 0 0 0 int1
10.1.1.0 192.176.20.1 255.255.255.0 UG 0 0 0 eth0
10.13.1.0 192.176.100.1 255.255.255.0 UG 0 0 0 int1
192.176.0.0 * 255.255.0.0 U 1 0 0 eth0
default 192.176.20.2 0.0.0.0 UG 0 0 0 eth0
Well you have 2 local interfaces on the router; eth0 and int1. I guess it's easiest to go through line by line of the routing table.
Destination Gateway Genmask Flags Metric Ref Use Iface
10.80.0.0 192.176.20.1 255.255.255.0 UG 0 0 0 eth0
This states that any packet with a destination of 10.80.0.0/24 will be sent out eth0 using a gateway of 192.176.20.1.
Destination Gateway Genmask Flags Metric Ref Use Iface
192.176.100.0 * 255.255.255.0 U 0 0 0 int1
This states that any packet with a destination of 192.176.100.0/24 will be sent out int1 without using a gateway.
Destination Gateway Genmask Flags Metric Ref Use Iface
10.1.1.0 192.176.20.1 255.255.255.0 UG 0 0 0 eth0
This states that any packet with a destination of 10.1.1.0/24 will be sent out eth0 using a gateway of 192.176.20.1.
Destination Gateway Genmask Flags Metric Ref Use Iface
10.13.1.0 192.176.100.1 255.255.255.0 UG 0 0 0 int1
This states that any packet with a destination of 10.13.1.0/24 will be sent out int1 using a gateway of 192.176.100.1.
Destination Gateway Genmask Flags Metric Ref Use Iface
192.176.0.0 * 255.255.0.0 U 1 0 0 eth0
This states that any packet with a destination of 192.176.0.0/16 will be sent out eth0 without using a gateway.
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.176.20.2 0.0.0.0 UG 0 0 0 eth0
This states that any packet that doesn't match any of the above routes will be forwarded out eth0 with a gateway of 192.176.20.2. Most likely a route to the internet (also called Gateway of Last Resort, if I'm not mistaken).
If you need more information, don't hesitate to ask.
Extra info on the specifics: http://www.cyberciti.biz/faq/what-is-a-routing-table/
Destination = the address of the network that the packet is headed to
The "default" means that if the destination is not found in any of the other rules, than use this rule.
Genmask = The subnet mask
If there is more than one address in the routing table that works for the outgoing packet, the rule with the higher subnet mask will be used. If those are tied, then metric comes into play but that will be different based on what protocol is being used.
Interface = On-board connection
For example, the laptop I am on currently has three interfaces:
Ethernet card
Wireless card
Bluetooth
Routers generally have at least 2 interfaces for each side, 1 for each network they are a part of. For most home routers, 1 interface is part of your home network and the other is part of the external network (usually the internet) headed toward your ISP.
Gateway = Next hop
This is where the packet will be sent if the destination is not on the same network as the sender.
If the value is "*" or "On-link" or the address of the current device... these all mean the same thing. It means that the packet is addressed to a device that is directly reachable by the current host. In other words, they're on the same network so the gateway won't actually be used because the host will know the data link layer (MAC) address of the destination and be able to send it directly there. These values are just used for human readability in this case.
As for the process of sending a packet:
Destination and Genmask are used to figure out which rules are a
match for the destination address of the outgoing packet.
Interface is used to decide what communication device on the machine
to send it through.
Gateway is the address of the device on the same network that it will
send the packet to.

ffmpeg with double ethernet interfaces works wrong

A server with double interfaces.
One(eht0) is used for WAN which provides http/ssh services for internet users.
The other(eth1) is used to receive multicast data from intranet.
218.108.132.177 is public network gateway.
125.210.198.1 is private network gateway.
233.49.3.*/24 is multicast address.
10.0.11.*/24 is the source of multicast data.
When the route table is like below, ffmpeg can't read the udp data from eth1, ffmpeg hung up:
rrca#rcasnap02:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
218.108.132.176 * 255.255.255.252 U 0 0 0 eth0
125.210.198.0 * 255.255.255.240 U 0 0 0 eth1
default 218.108.132.177 0.0.0.0 UG 100 0 0 eth0
default 125.210.198.1 0.0.0.0 UG 100 0 0 eth1
or
rrca#rcasnap02:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
218.108.132.176 * 255.255.255.252 U 0 0 0 eth0
125.210.198.0 * 255.255.255.240 U 0 0 0 eth1
default 218.108.132.177 0.0.0.0 UG 100 0 0 eth0
10.0.11.0 125.210.198.1 0.0.0.0 UG 100 0 0 eth1
or
rrca#rcasnap02:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
218.108.132.176 * 255.255.255.252 U 0 0 0 eth0
125.210.198.0 * 255.255.255.240 U 0 0 0 eth1
default 218.108.132.177 0.0.0.0 UG 100 0 0 eth0
233.49.3.0 125.210.198.1 255.255.255.0 UG 100 0 0 eth1
I want to the ffmpeg work right,but now I think the two default route in route table disturb eachother, and I take a try, when the public gateway route is deleted, or the private gateway route is at the head of public default gateway route, ffmpeg works well, I think it read multicast from eth1.But the route table is not thus, ffmpeg can't read data from eth1, I think it read data on eth0(which is not private network interface).
How to do ffmpeg works well with two interfaces at the same time?
You need to configure the correct route for multicast traffic. The kernel does an origin check on all incoming multicast traffic: if it arrives on a different interface from the one it would use to send such traffic it's dropped.
Just set a route for multicast on your eth1 interface:
# route add -net 224.0.0.0/8 dev eth1
Alternatively, disable the origin checking:
# echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
While the answer is correct in that a route is required, I had to route 224.0.0.0/4 (which includes up to 239.255.255.255) as my device was sending the video stream to 239.255.42.42

Resources