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

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

[Leroy Tennison]

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?

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?

It seems that 'nexthop' is used for load balancing and possibly 
redundancy, are there any other situations or reasons?

Thanks for the help.

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

[Martin A. Brown]

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

-- 
Martin A. Brown
http://linux-ip.net/

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

[Leroy Tennison]

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
>