Configurable source address

[Svedrin]

Enhance targets so we can ping them from different source addresses?

[liquid-metal]

liboping and the oping wrapper do have the option to set a source (address or hostname), and source device (which I'd propose to add at the same time as the source address option).

From the exact wording in the description above, I think there are two ways to read it

• a simple implementation would just add an optional source address and source device to the Target class and corresponding table. This would only allow one source (both address and device) per target, as the target address is UNIQue
• a more elaborate implementation would allow multiple combinations of source address and source device per target. That would need either extension of the uniqueness constraint in the target table, or a separate table containing source combinations for targets

Is the second option actually a sensible use-case?

[Svedrin]

Hm, this has a lot more unobvious complexity to it than I initially thought. The first option is helpful if you need to ping a target from a specific spurce address for firewall reasons. The second one is a lot more interesting though if you have a dual-WAN setup, so that you can ping the same target from both links and compare their histograms. That way you can compare the results a lot better because you don't have to pick two separate-but-hopefully-similar-in-performance targets to ping.

That said, you're right in that it would take a database migration to achieve, which I'm kinda hesitant about because Meshping really doesn't have anything going on in terms of database migrations. So we're somewhat stuck with the schema, or we choose to add another dependency to fix that.

I'm wondering if it would be acceptable to configure the source address and/or device for the whole Meshping instance as an env var. That way you could have two instances, one per WAN link, and have one of them send its targets to the other. Maybe that plus Option 1 for when you really only need it on one target for firewall policy reasons.

Implementing Option 1 would be relatively easy using the meta table, so it'd "only" require UI and code changes, but not a db schema change. Seems a lot simpler.

Curious to hear your thoughts, I'm not sure at the moment how I'd proceed. Maybe I need to sleep on it 😄

[liquid-metal]

As a user, I'd dislike the idea of multiple meshping instances on my probe. I'd have distinct user interfaces, multiple containers with different configuration, and no easy way to combine statistics etc. at one place other than a prometheus(-compatible) instance, which would in turn need to be configured for multiple endpoints.

For the database, though I see the point of avoiding a dependency, I think on the long run the current approach makes implementing features less approachable, and from user perspective does not really allow software updates. IMHO the introduction of any kind of (simple) db migrations is worth the effort, given it would directly benefit a number of open issues:

• Clustering #40
• Integration with an IPAM such as NetBox or phpipam, or a generic source plugin API #47
• Support dyndns targets #50
• Track and show changes in routing #56
• Ping with larger packet sizes #70

and obviously this one as well

that aside, for the specific question about implementation of the source feature: given from your text and from what i can imagine this tool to be used for, I can see usecases for multiple distinct source combinations per target (so option (2) from my previous comment)

[Svedrin]

You're making a perfectly valid point. Also I'm convinced it's only a matter of time until we'll add migrations, so perhaps this is the feature for which it'll happen. I'll open a separate issue for it.