RE: EPICS CA and PVA across subnets

[Abdalla Ahmad via Tech-talk <tech-talk@aps.anl.gov>]

Hello Mark

 

If I understand your case, I think your best bet is directed broadcast. For example our archiver can reach all our IOCs, which reside on different subnets and each node serve multiple IOCs, by using EPICS_CA_ADDR_LIST and on each node we direct iptables to send all UDP broadcasts to all processes explained here: https://wiki-ext.aps.anl.gov/epics/index.php/How_to_Make_Channel_Access_Reach_Multiple_Soft_IOCs_on_a_Linux_Host . This does not have to be a NetworkManager dispatcher script, For example:

 

/sbin/iptables -t nat -A PREROUTING -d 192.168.0.6 -p udp -–dport 5064 -j DNAT –-to-destination 192.168.0.255

 

Will work instantly from your shell. You can add this to rc.local and it will work on reboot. Tested on Rocky Linux 8. Of course I assume the network allow traffic between specified subnets.

 

Another option you can consider but a little more complex is to setup an EPICS gateway between each two subnets, this how we pass specific PVs across subnets; for example between the machine and beamlines. This will allow you to talk between subnets using one IP address only.

 

Best Regards,

Abdalla Al-Dalleh

Control Engineer

SESAME

 

From: Tech-talk <tech-talk-bounces@aps.anl.gov> On Behalf Of Mark Rivers via Tech-talk
Sent: Sunday, September 28, 2025 12:24 AM
To: EPICS Tech Talk <tech-talk@aps.anl.gov>
Subject: EPICS CA and PVA across subnets

 

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