True; the CA Name-server and Gateway were also designed to be run on machines that have interfaces on each subnet their client-sides talk to.
This Message Is From an External Sender
This message came from outside your organization.
Hi Andrew,
- The simplest solution might be setting up a
UDP
broadcast relay between the different subnets. We use this software for distributing APS event system time synchronization packets into a protected subnet. I’ve never actually
tried it with CA name-search broadcasts, I would recommend configuring it to forward CA beacon packets as well
The documentation for that link says this:
- This program listens for packets on a specified UDP broadcast port. When a packet is received, it sends that packet to all specified
interfaces but the one it came from as though it originated from the original sender.
That sounds to me like is requires a multi-homed machine, i.e. a machine with interfaces to each subnet. That is not my use case, we don’t have any multi-homed machines. I think we need to have a link between a listener on the
client network and a re-broadcaster on the server network?
Thanks,
Mark
Some alternative approaches to consider:
The simplest solution might be setting up a
UDP
broadcast relay between the different subnets. We use this software for distributing APS event system time synchronization packets into a protected subnet. I’ve never actually tried it with
CA name-search broadcasts, I would recommend configuring it to forward CA beacon packets as well
The CA Name-server can be run without requiring a database of PV names; it can discover PV names being searched for on its server subnet(s) by broadcasting them to its client subnets. I wouldn’t characterize this as requiring a complex
setup, although I would recommend considering the possibility of loops before configuring multiple name-servers.
I believe both CA and PVXS support using multicast for name searches (not sure about pvAccessCPP), but we don’t have much if any documentation for Base explaining how to configure CA to use that, could someone from Fermilab comment
on that? I believe Fermi requested and possibly implemented this. It would require configuring all the clients and servers, which the previous 2 suggestions don’t.
- Andrew
--
Complexity comes for free, Simplicity you have to work for.
Hi,
Your table summarizes things well, although I would add another row: explicitly listing IOCs. If a client is only interested in a few IOCs, listing them all is less overhead than setting up other infrastructure, so this can be a good compromise for some people.
CA will use TCP to search for names, so this option is compatible with all sorts of networks. Including, for example, forwarding the CA port over SSH.
That said, I have recently tried using PVA across networks and didn't have much success in my specific situation. Even when you add the IOC to EPICS_PVA_ADDR_LIST, PVA doesn't seem to use TCP to do name searches. I didn't have time for a deeper look, though
I did skim over the protocol spec quickly. It looks to me that it can only use multicast for searches. Can someone confirm whether this is the case? If this is so, PVA name searches can't work over networks that aren't layer 2. Like, it won't work over most
VPNs.
Best,
Jure
On 9/27/25 23:24, Mark Rivers via Tech-talk wrote:
|
|
|
Caution: This email originated from outside of Cosylab.
|
Folks,
A persistent issue with EPICS CA and PVA is the difficulties that arise when clients and IOCs are on different subnets. The problem is particularly bad when a server hosts multiple IOCs, because then UDP unicast will find only
one of those IOCS. The following table shows my understanding of different solutions:
|
Solution
|
Pros
|
Cons
|
|
Directed broadcast
|
Simple setup
|
Requires IT to permit and configure switches to allow broadcasts from the client subnet to reach the server subnet.
|
|
Nameservers
|
Eliminates UDP broadcasts
|
Complex setup, requires database of all PVs
|
|
Gateway
|
Allows access control
|
Complex setup, overhead
|
|
iptables
|
Fairly simple
|
Linux only; iptables being discontinued on recent Linux versions
|
My use case is beamlines where each one typically has a few client and server subnets, but there are many beamlines. The complexity of gateways and nameservers is a barrier.
At the ICALEPCS meeting there was a poster on another solution called SnowSignal.
https://github.com/isisneutronmuon/snowsignal
SnowSignal was designed to allow PVA UDP broadcasts between nodes in a Docker swarm. It works using UDP relay. A SnowSignal process on the client subnet listens for UDP broadcasts containing PVA channel searches. It forwards
those packets via UDP unicast to a SnowSignal process on the server subnet. That SnowSignal process then converts them to broadcast messages on the server subnet.
SnowSignal is about 1500 lines of Python.
It seems to me that SnowSignal could be extended to also support CA, and should be usable in any network system, not just inside Docker swarms.
I think there might also be a way to optionally make it more efficient. The SnowServer on the client network currently forwards all EPICS channel searches because it listens for broadcasts. I would suggest that it could optionally
be configured to only listen for UDP unicast channel searches. The use case is when only a small number of clients need access to the remote subnet. In that case they can set EPICS_CA_ADDR_LIST to the IP address of the SnowServer process. It will then only
forward the searches for clients that specify that EPICS_CA_ADDR_LIST, and not for all clients. The optimization is something we currently do with Directed Broadcast. Only clients that need to access PVs on the remote subnet add the remote subnet broadcast
address to EPICS_CA_ADDR_LIST.
I’d be interested in hearing other’s thoughts about this.
Thanks,
Mark
