How to Configure Channel Access - Revision history

AndrewJohnson: Refer to epics-controls.org website

2021-06-01T20:54:15Z

Refer to epics-controls.org website

← Older revision		Revision as of 20:54, 1 June 2021
Line 1:		Line 1:
	= How to Configure Channel Access =		= How to Configure Channel Access =

			'''This page is old and out of date''', please go to our [https://epics-controls.org/resources-and-support/documents/howto-documents/ new How To documents page] for the latest version.

RalphLange: Add pointer to iptables trick.

2014-04-01T09:38:38Z

Add pointer to iptables trick.

← Older revision		Revision as of 09:38, 1 April 2014
Line 23:		Line 23:
	When starting a second IOC on the same computer, it will also listen to name searches on UDP port 5064.		When starting a second IOC on the same computer, it will also listen to name searches on UDP port 5064.
	Due to limitations in most network kernels, however, only the IOC started ''last'' will actually receive UDP search requests that are sent to that computer, port 5064. As a workaround, you need to configure the EPICS_CA_ADDR_LIST to use the broadcast address of the respective subnet.		Due to limitations in most network kernels, however, only the IOC started ''last'' will actually receive UDP search requests that are sent to that computer, port 5064. As a workaround, you need to configure the EPICS_CA_ADDR_LIST to use the broadcast address of the respective subnet.

			Alternatively, you can automatically set up iptables rules that will circumvent the problem. (See [[How to Make Channel Access Reach Multiple Soft IOCs on a Linux Host]].)

	== Multiple IOCs on the same computer but on a different subnet ==		== Multiple IOCs on the same computer but on a different subnet ==

AndrewJohnson: Brazilians are using the relay for CA, it works.

2013-10-17T21:45:02Z

Brazilians are using the relay for CA, it works.

← Older revision		Revision as of 21:45, 17 October 2013
Line 27:		Line 27:
	Combining the last two points results in a problem:		Combining the last two points results in a problem:
	To reach multiple IOCs on the same computer, EPICS_CA_ADDR_LIST must be set to the broadcast address of that computer's subnet.		To reach multiple IOCs on the same computer, EPICS_CA_ADDR_LIST must be set to the broadcast address of that computer's subnet.
	If ~~that~~ subnet~~, however,~~ is different from the CA client's subnet, routers ~~tend to not allow such broadcast traffic~~.		If the IOCs' subnet is different from the CA client's subnet however, the broadcast search packets will not usually be forwarded by the intermediate network routers.

	There are several options to solve this:		There are several options to solve this:

	=== Channel Access Gateway ===		=== Channel Access Gateway ===
	The gateway, running on the subnet that has the desired IOCs, will use the broadcast address of that subnet in its EPICS_CA_ADDR_LIST, so it can reach all IOCs, including multiple IOCs running on the same computer, throughout that subnet.		The PV gateway, running on the subnet that has the desired IOCs, will use the broadcast address of that subnet in its EPICS_CA_ADDR_LIST, so it can reach all IOCs, including multiple IOCs running on the same computer, throughout that subnet.
	~~The~~ CA client on a different subnet uses only EPICS_CA_ADDR_LIST=ip-of-the-gateway to directly reach the gateway, which is possible via routers.		A CA client on a different subnet uses only EPICS_CA_ADDR_LIST=ip-of-the-gateway to directly reach the gateway, which is possible via routers.

	In addition to establishing the basic connectivity, the gateway also offers IOC load reduction and it can add access security, for example limit write access.		In addition to establishing the basic connectivity, the gateway also offers IOC load reduction and it can add access security, for example limit write access.

	=== CA Nameserver ===		=== CA Nameserver ===
	You can run a CA Name Server in the GUI subnet which knows about the IOCs and responds to search requests; in this case you would not set the EPICS_CA_ADDR_LIST variables. This is almost equivalent to running a CA Gateway, but is slightly more robust ~~in that~~ if the Nameserver process dies it wouldn't kill any existing connections.		You can run a CA Name Server in the GUI subnet which knows about the IOCs and responds to search requests; in this case you would ''not'' set the EPICS_CA_ADDR_LIST variables. This is almost equivalent to running a CA Gateway, but is slightly more robust because if the Nameserver process dies it wouldn't kill any existing connections.

	=== UDP Broadcast Packet Relay ===		=== UDP Broadcast Packet Relay ===
	If you have access to a machine with a network interface on both subnets you ~~could also try using~~ a program on it called [https://www.joachim-breitner.de/udp-broadcast-relay/ UDP Broadcast Packet Relay] to forward UDP broadcast packets between the subnets. ~~You will have to~~ run it twice, once for port 5064 and again for 5065~~; the~~ first one will forward CA search requests between the subnets, ~~and~~ the second ~~sends the~~ CA beacons~~. This program is used at the APS for forwarding timing UDP packets but~~ has ~~not~~ been ~~proven~~ for ~~CA yet~~.		If you have access to a machine with a network interface on both subnets you can run a program on it called [https://www.joachim-breitner.de/udp-broadcast-relay/ UDP Broadcast Packet Relay] to forward UDP broadcast packets between the subnets. For best performance you should run it twice, once for port 5064 and again for 5065. The first one will forward CA search requests between the subnets, while the second redistributes CA beacons which help channels reconnect faster after an IOC has been turned off for some time.

AndrewJohnson: Formatting

2013-10-16T22:24:31Z

Formatting

KayKasemir: Initial attempt

2013-10-16T21:52:31Z

Initial attempt

New page

= How to Configure Channel Access =

= Basic Operation, One IOC on same subnet =
Assume an IOC has a record "fred", and you want to use "caget fred" or a similar CA client to read it.

When starting out with one IOC on the network, things are simple:

CA clients will by default broadcast name search requests to UDP port 5064 on the subnet.
As long as the IOC is on any computer on the subnet, it should eventually receive those search requests. Server and client then establish a TCP connection, and data is exchanged.

= Multiple IOCs on different computers, but same subnet =
If running multiple IOCs, each on their own computer, on the same subnet, the basic broadcast name search will still succeed, no change necessary.

= IOCs on different subnets =
The default broadcast name search is limited to the subnet of the computer running the CA client.
To reach IOCs on one or more additional subnets, the environment variable EPICS_CA_ADDR_LIST needs to be configured.
It can list either the specific IP addresses of each IOC, or the broadcast address of their subnet.
Note, however, that routers will often not forward broadcast requests, which suggests using specific IP addresses.

= Multiple IOCs on the same computer =
When starting the first IOC on a computer, it will listen to name searches on UDP port 5064.
When starting a second IOC on the same computer, it will also listen to name searches on UDP port 5064.
Due to limitations in most network kernels, however, only the IOC started ''last'' will actually receive UDP search requests that are sent to that computer, port 5064. As a workaround, you need to configure the EPICS_CA_ADDR_LIST to use the broadcast address of the respective subnet.

= Multiple IOCs on the same computer but on a different subnet =
Combining the last two points results in a problem:
To reach multiple IOCs on the same computer, EPICS_CA_ADDR_LIST must be set to the broadcast address of that computer's subnet.
If that subnet, however, is different from the CA client's subnet, routers tend to not allow such broadcast traffic.

There are several options to solve this:

== Channel Access Gateway ==
The gateway, running on the subnet that has the desired IOCs, will use the broadcast address of that subnet in its EPICS_CA_ADDR_LIST, so it can reach all IOCs, including multiple IOCs running on the same computer, throughout that subnet.
The CA client on a different subnet uses only EPICS_CA_ADDR_LIST=ip-of-the-gateway to directly reach the gateway, which is possible via routers.

In addition to establishing the basic connectivity, the gateway also offers IOC load reduction and it can add access security, for example limit write access.

== CA Nameserver ==
You can run a CA Name Server in the GUI subnet which knows about the IOCs and responds to search requests; in this case you would *not* set the EPICS_CA_ADDR_LIST variables. This is almost equivalent to running a CA Gateway, but is slightly more robust in that if the Nameserver process dies it wouldn't kill any existing connections.

== UDP Broadcast Packet Relay ==
If you have access to a machine with a network interface on both subnets you could also try running a program on it called UDP Broadcast Packet Relay https://www.joachim-breitner.de/udp-broadcast-relay/ which forwards broadcast packets between subnets. You would probably have to run it twice, once on port 5064 and once on 5065; the first one will forward CA search requests between the subnets, and the second sends the CA beacons. If you do have success with this please let us know, we use it here at the APS for forwarding timing UDP packets but not for CA.

= Firewalls =
Firewalls may need to be configured to pass the UDP and TCP 5064 traffic.

The channel access reference manual,
http://www.aps.anl.gov/epics/base/R3-14/8-docs/CAref.html
provides a lot more detail.

← Older revision		Revision as of 22:24, 16 October 2013
Line 2:		Line 2:


	= Basic Operation, One IOC on same subnet =		== Basic Operation, One IOC on same subnet ==
	Assume an IOC has a record "fred", and you want to use "caget fred" or a similar CA client to read it.		Assume an IOC has a record "fred", and you want to use "caget fred" or a similar CA client to read it.

Line 8:		Line 8:

	CA clients will by default broadcast name search requests to UDP port 5064 on the subnet.		CA clients will by default broadcast name search requests to UDP port 5064 on the subnet.
	As long as the IOC is on any computer on ~~the~~ subnet, it should ~~eventually~~ receive those search requests. Server and client then establish a TCP connection, and data is exchanged.		As long as the IOC is running on on any computer on that subnet, it should receive those search requests. Server and client will then establish a TCP connection, and data is exchanged.

	= Multiple IOCs on different computers, but same subnet =		== Multiple IOCs on different computers, but same subnet ==
	If running multiple IOCs, each on their own computer, on the same subnet, the basic broadcast name search will still succeed, no change necessary.		If running multiple IOCs, each on their own computer, on the same subnet, the basic broadcast name search will still succeed, no change necessary.

	= IOCs on different subnets =		== IOCs on different subnets ==
	The default broadcast name search is limited to the subnet of the computer running the CA client.		The default broadcast name search is limited to the subnet of the computer running the CA client.
	To reach IOCs on one or more additional subnets, the environment variable EPICS_CA_ADDR_LIST needs to be configured.		To reach IOCs on one or more additional subnets, the environment variable EPICS_CA_ADDR_LIST needs to be configured.
Line 19:		Line 19:
	Note, however, that routers will often not forward broadcast requests, which suggests using specific IP addresses.		Note, however, that routers will often not forward broadcast requests, which suggests using specific IP addresses.

	= Multiple IOCs on the same computer =		== Multiple IOCs on the same computer ==
	When starting the first IOC on a computer, it will listen to name searches on UDP port 5064.		When starting the first IOC on a computer, it will listen to name searches on UDP port 5064.
	When starting a second IOC on the same computer, it will also listen to name searches on UDP port 5064.		When starting a second IOC on the same computer, it will also listen to name searches on UDP port 5064.
	Due to limitations in most network kernels, however, only the IOC started ''last'' will actually receive UDP search requests that are sent to that computer, port 5064. As a workaround, you need to configure the EPICS_CA_ADDR_LIST to use the broadcast address of the respective subnet.		Due to limitations in most network kernels, however, only the IOC started ''last'' will actually receive UDP search requests that are sent to that computer, port 5064. As a workaround, you need to configure the EPICS_CA_ADDR_LIST to use the broadcast address of the respective subnet.

	= Multiple IOCs on the same computer but on a different subnet =		== Multiple IOCs on the same computer but on a different subnet ==
	Combining the last two points results in a problem:		Combining the last two points results in a problem:
	To reach multiple IOCs on the same computer, EPICS_CA_ADDR_LIST must be set to the broadcast address of that computer's subnet.		To reach multiple IOCs on the same computer, EPICS_CA_ADDR_LIST must be set to the broadcast address of that computer's subnet.
Line 31:		Line 31:
	There are several options to solve this:		There are several options to solve this:

	== Channel Access Gateway ==		=== Channel Access Gateway ===
	The gateway, running on the subnet that has the desired IOCs, will use the broadcast address of that subnet in its EPICS_CA_ADDR_LIST, so it can reach all IOCs, including multiple IOCs running on the same computer, throughout that subnet.		The gateway, running on the subnet that has the desired IOCs, will use the broadcast address of that subnet in its EPICS_CA_ADDR_LIST, so it can reach all IOCs, including multiple IOCs running on the same computer, throughout that subnet.
	The CA client on a different subnet uses only EPICS_CA_ADDR_LIST=ip-of-the-gateway to directly reach the gateway, which is possible via routers.		The CA client on a different subnet uses only EPICS_CA_ADDR_LIST=ip-of-the-gateway to directly reach the gateway, which is possible via routers.
Line 37:		Line 37:
	In addition to establishing the basic connectivity, the gateway also offers IOC load reduction and it can add access security, for example limit write access.		In addition to establishing the basic connectivity, the gateway also offers IOC load reduction and it can add access security, for example limit write access.

	== CA Nameserver ==		=== CA Nameserver ===
	You can run a CA Name Server in the GUI subnet which knows about the IOCs and responds to search requests; in this case you would not set the EPICS_CA_ADDR_LIST variables. This is almost equivalent to running a CA Gateway, but is slightly more robust in that if the Nameserver process dies it wouldn't kill any existing connections.		You can run a CA Name Server in the GUI subnet which knows about the IOCs and responds to search requests; in this case you would not set the EPICS_CA_ADDR_LIST variables. This is almost equivalent to running a CA Gateway, but is slightly more robust in that if the Nameserver process dies it wouldn't kill any existing connections.

	== UDP Broadcast Packet Relay ==		=== UDP Broadcast Packet Relay ===
	If you have access to a machine with a network interface on both subnets you could also try ~~running~~ a program on it called ~~UDP Broadcast Packet Relay~~ https://www.joachim-breitner.de/udp-broadcast-relay/ ~~which forwards~~ broadcast packets between subnets. You ~~would probably~~ have to run it twice, once on port 5064 and ~~once on~~ 5065; the first one will forward CA search requests between the subnets, and the second sends the CA beacons. ~~If you do have success with this please let us know, we use it here~~ at the APS for forwarding timing UDP packets but not for CA.		If you have access to a machine with a network interface on both subnets you could also try using a program on it called [https://www.joachim-breitner.de/udp-broadcast-relay/ UDP Broadcast Packet Relay] to forward UDP broadcast packets between the subnets. You will have to run it twice, once for port 5064 and again for 5065; the first one will forward CA search requests between the subnets, and the second sends the CA beacons. This program is used at the APS for forwarding timing UDP packets but has not been proven for CA yet.


	= Firewalls =		== Firewalls ==
	Firewalls may need to be configured to pass ~~the~~ UDP and TCP 5064 ~~traffic~~.		Firewalls may need to be configured to pass UDP and TCP traffic on both ports 5064 and 5065.


			The [http://www.aps.anl.gov/epics/base/R3-14/12-docs/CAref.html Channel Access Reference Manual] provides a lot more detail.

	The ~~channel access reference manual,~~
	http://www.aps.anl.gov/epics/base/R3-14/8-docs/CAref.html
	provides a lot more detail.