Re: Question about 'via', 'src' and 'nexthop'

[Leroy Tennison <leroy.tennison@verizon.net>]

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
>