dhcpcd-discuss

> You maybe interested in a recent discussion about multi-homed uplinks
> and source address routing, archived here:
> http://roy.marples.name/archives/dhcpcd-discuss/2015/0960.html
> And the final patch for testing (but as yet no replies!) here:
> http://roy.marples.name/archives/dhcpcd-discuss/2015/0982.html

Oh, that is interesting, but it only seems pertinent in a IPv6 context, 
unless I've misread/misunderstood the patch.

In reading the thread, it seems like there's a potential 
misunderstanding of how many of us apply multihoming.  The thread 
implies a local network service needs to "bind" to a given interface 
address to use it, but under Linux at least, you can apply outbound 
routing decisions based around arbitrary criteria without the underlying 
router (or any of the client hosts behind it) being aware of the 
multi-uplink topology.  It's trivial to handle the case of inbound 
connections to one of the public-facing IP#s - ingress route "bonding", 
or whatever it's called.

For instance, I apply some destination port specific routing decisions 
to go out through a certain interface, as well as source (local LAN) IP# 
ones.  The "default" goes through a determination of which outbound link 
has lower utilisation at the time the connection is created.  The router 
runs squid and proxies all of the web traffic, and I allow it to make 
"round-robin" decisions so it can keep things from breaking.

> This is true.
> If dhcpcd is instructed to set a gateway, then set a gateway it shall.
> However, on Linux at least, each gateway is set to a metric which allows >1.

Actually, the lack of an advertised gateway was caused by a different 
problem which seems to have been "sorted" by the ISP.  dhcpcd -U 
displays the requisite information, even if I supply -G on its 
invocation.  I'm afraid I wasted the list's time, never mind my own on a 
little goose chase!

It did give me an excuse to revisit my multi-homing setup, though, and 
I've now make a run-hook module to "update" the iproute2 aspects of the 
link when it's brought up/down.

> If you add your own static gateway, dhcpcd should preserve it.
> Actually that may not be entirely true in some dhcpcd versions (you
> neglected to say which version you are using). Certainly in the fossil
> trunk there is improved code for this.

I started with the stock one provided by Slackware (6.0.5), but after 
checking the distro-supplied patches against 6.0.5, I could see no 
reason to avoid upgrading the package manually to the current version.

> should provide the IPv4 dhcp lease.
> You want to look for either classless_static_routes= and find the
> 0.0.0.0/0 entry (router IP after it) or look at the routers=
> If classless_static_routes is set, then routers is ignored.

This sounds like a potential "gotcha" in the face of upstream changes. 
Is there a field/entry in that lease dump that conveys the actual 
gateway(s) that would apply subject to these policy-related decisions 
vis-a-vis classless_static_routes overriding the routers one?  I'm happy 
to code in the logic, but I worry that my understanding of all of the 
rules of when to apply which field in which situation is incomplete.

Thanks for your reply and all of the hard work you've put into dhcpcd.

Malcolm
=R=