Thank you for your reply, that clears up some things. As I was looking
at one of the links you provided I realized I had read that before, I
probably passed over it because I didn't have the question at the time.
You mentioned that the links were old but you felt they still applied,
would that be the case for how a packet traverses the routing and
netfilter components of the networking part of the kernel? I have found
some older references but wondered if they were still applicable.
On 06/01/2015 10:26 AM, Martin A. Brown wrote:
Greetings Leroy,
I have slightly rearranged your questions.
Can someone elaborate on the use of src? The statements I have seen
("the source address to prefer when sending to the destinations
covered by the route prefix.") seem vague. When should 'src' be used
and why?
The 'src' parameter offers a hint. Frankly, this hint is probably not
used very often, but here are the circumstances under which it may be
useful. You may have a machine with many IPs, connected to many local
networks. Let's suppose that you want all connections to destinations
in network A (192.0.2.0/24) to use the local address 192.0.2.17. If
so, then you could:
ip route add 192.0.2.0/24 dev eth0 scope link src 192.0.2.17
If an application just asks the kernel for a socket (and does not
explicitly specify the source address), then the 'src' parameter is
the hint to suggest that the originating IP for the connection will be
192.0.2.17. That's all.
Here are some descriptions of how source address selection works under
Linux. (Yes, this is a bit old, but, as far as I know, it remains
correct.)
http://linux-ip.net/gl/ip-cref/node155.html
http://linux-ip.net/html/linux-ip.html#routing-saddr-selection
I'm getting the impression that 'via' is only used when the IP
address is not local to the device, is this correct or is there more
to it?
The 'via' parameter is always 'via ADDRESS'. The address should be
directly reachable on some layer 2 by the system. So, in the case of
the above example, let's assume that your routing table looks like this:
default via 192.0.2.1 dev eth0 proto static
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.17
The second route tells the Linux system that it is directly connected
to 192.0.2.0/24 with the layer 2 device/interface known as 'eth0'.
The default route says to send any other packets through 192.0.2.1,
which (of course) must itself be reachable--it is because of the
direct connection to 192.0.2.0/24 on device/interface eth0.
It seems that 'nexthop' is used for load balancing and possibly
redundancy, are there any other situations or reasons?
As you surmised, 'nexthop' is used when you have multiple routers
offering different routing paths out of a network. You can create a
route with only a single 'nexthop' entry, but this will devolve to the
simplest case. Here's an example of what I mean:
# ip route add 198.51.100.0/24 nexthop via 192.0.2.1 weight 1
# ip route show
default via 192.0.2.1 dev eth0 proto static
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.17
198.51.100.0/24 via 192.0.2.1 dev eth0
OK, so let's remove that route with only one 'nexthop' phrase and add
a route with two 'nexthop' phrases:
# ip route del 198.51.100.0/24 nexthop via 192.0.2.1 weight 1
# ip route add 198.51.100.0/24 nexthop via 192.0.2.1 weight 1
nexthop via 192.0.2.2 weight 1
# ip route show
default via 192.0.2.1 dev eth0 proto static
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.17
198.51.100.0/24
nexthop via 192.0.2.1 dev eth0 weight 1
nexthop via 192.0.2.2 dev eth0 weight 1
I am, personally, unfamiliar with the kernel's decisions on balancing
flows using multipath routes. I have seen admonitions to be wary of
the possible packet reordering (which may or may not be a big deal to
any individual application).
Good luck!
-Martin
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
