本文主要是介绍EPICS CA请求能否成功的影响因素，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1. 子网和广播域
子网掩码和广播域互为互补的网段。
例如：10.0.2.235的掩码为255.255.0.0，则它所在的子网为10.0.0.0，广播域为10.0.255.255；
192.168.206.235的掩码为255.255.255.0，则它所在的子网为192.168.206.0，广播域为192.168.206.255.
单播、广播都是在数据帧层面，即MAC层；多播（组播）既涉及到MAC层，又涉及到IP层。
所谓广播，就是让当前局域网中所有主机都收到MAC数据帧（DMAC=ff-ff-ff- ff-ff-ff）。
数据帧的广播范围不需考虑IP，只需考虑数据链路层和物理层是否可达。
计算机自己能发广播包吗？能
2. 四种IP广播地址
2.1 受限的广播
受限的广播地址是255.255.255.255。
它不被路由但会被送到相同物理网络段上的所有主机.
2.2 指向网络的广播
指向网络的广播地址是主机号为全1的地址。A类网络广播地址为netid.255.255.255，其中netid为A类网络的网络号。一个路由器必须转发指向网络的广播，但它也必须有一个不进行转发的选择。
2.3 指向子网的广播
指向子网的广播地址为主机号为全1且有特定子网号的地址。
例如，如果路由器收到发往128.1.2.255的数据报，当B类网络128.1的子网掩码为255.255.255.0时，该地址就是指向子网的广播地址；但如果该子网的掩码为255.255.254.0，该地址就不是指向子网的广播地址。
2.4 指向所有子网的广播
指向所有子网的广播地址的子网号及主机号为全1。
例如，如果目的子网掩码为255.255.255.0，那么IP地址128.1.255.255是一个指向所有子网的广播地址。然而，如果网络没有划分子网，这就是一个指向网络的广播。
网络中的广播地址
四种IP广播地址
3. 网络是否可达
3.1 MAC层是否可达
测试：点对点连接，各自arp缓存表中都有对方的IP和MAC地址映射（REACHABLE状态）
10.0.3.235/16 ping不通 10.0.2.200/24； （子网分别为10.0.0.0和10.0.2.0）
由于二者点对点连接，且10.0.3.235/16知道10.0.2.200/24的MAC地址，所以10.0.2.200/24可以收到数据帧，
但是由于网络层的IP不在同一子网内，而ping是基于网络层的ICMP协议，所以ping不会返回响应。
10.0.3.235/16 ping得通 10.0.2.200/16； （子网都为10.0.0.0）
10.0.2.235/16 ping得通 10.0.2.200/24。 （子网分别为10.0.0.0和10.0.2.0）
发出对某IP的请求时，若当前主机的ARP缓存表中没有该IP，会先广播ARP请求，获取该IP的MAC地址。因此，物理上网络连接起来、但不属于同一子网的主机可以互相收到ARP请求，并获得彼此的MAC地址。
相同的子网才能互相ping通。
若有时候发现本不应ping通的两个子网之间ping通了，可能是发出ping请求的主机的ARP缓存(IP地址和MAC地址映射表)还存着之前能ping通目的IP时的MAC地址。过二三十分钟缓存清空更新或arp -d 删除该条ARP缓存后就无法ping通了。
3.2 防火墙的影响
当一个CA客户端向CA服务端（也就是IOC）发出请求时，通信过程如下：
CA客户端 CA服务端发起CA请求 <client IP>:<port1> ---------- UDP ---------- > <server IP>:5064<client IP>:<port1> < -------- UDP ------------ <server IP>:5064 CA应答（需CA客户端的<port1>允许被访问）建立CA连接 <client IP>:<port2> ---------- TCP ---------- > <server IP>:5064<client IP>:<port2> < -------- TCP ------------ <server IP>:5064......
由于涉及到端口（TCP和UDP）通信，无论是CA服务端还是CA客户端，防火墙的存在都会影响CA连接是否成功。
当防火墙未开启相关端口时，会导致CA服务端或CA客户端相应端口无法收到上述过程中的数据报文，所以CA连接不成功。
由于CA客户端的< port1 >和< port2 >一般是随机端口，并不能精确控制防火墙开启相应端口。因此，CA客户端和CA服务端的防火墙最好都关闭。
例：CA客户端（192.168.188.131）向 CA服务端（192.168.206.235）发送 camonitor dongxw:aSubExample 请求：
CA客户端（192.168.188.131）开启了防火墙，CA服务端（192.168.206.235）未开启防火墙。
当CA客户端通过 49024 UDP端口 发出CA请求后，无法接收到CA服务端返回给 49024 UDP端口的UDP数据报文。
在CA客户端防火墙中开启该UDP端口，
则可以收到报文，并进入下一步，通过 49768 TCP端口 发出TCP连接（由于是主动发出的TCP连接，因此该 TCP端口 可以被访问并连接到），之后CA客户端即可收到PV数据。
4. 目的IP列表的正确设置
4.1 EPICS_CA_AUTO_ADDR_LIST 和 EPICS_CA_ADDR_LIST
CA客户端发出CA请求时，其目的IP列表由EPICS_CA_AUTO_ADDR_LIST和EPICS_CA_ADDR_LIST共同决定。
https://epics.anl.gov/base/R3-14/12-docs/CAref.html#Environmen
【 EPICS_CA_AUTO_ADDR_LIST 】 初始化目的IP列表。
During initialization CA builds the list of server destination addresses used when sending CA client name resolution (search) requests. This table is initialized by introspecting the network interfaces attached to the host. For each interface found that is attached to a broadcast capable IP subnet, the broadcast address of that subnet is added to the list. For each point to point interface found, the destination address of that link is added to the list. This automatic server address list initialization can be disabled if the EPICS environment variable EPICS_CA_AUTO_ADDR_LIST exists and its value is either “no” or “NO”. The typical default is to enable network interface introspection driven initialization with EPICS_CA_AUTO_ADDR_LIST set to “YES” or “yes”.
EPICS_CA_AUTO_ADDR_LIST=YES时，会在主机所有网卡所接入的可广播子网内、所有点对点连接的IP中查找相应PV。
【 EPICS_CA_ADDR_LIST 】 在目的IP列表中添加特定IP。
Following network interface introspection, any IP addresses specified in the EPICS environment variable EPICS_CA_ADDR_LIST are added to the list of destination addresses for CA client name resolution requests. In an EPICS system crossing multiple subnets the EPICS_CA_ADDR_LIST must be set so that CA name resolution (search requests) frames pass from CA clients to the targeted CA servers unless a CA proxy (gateway) is installed. The addresses in EPICS_CA_ADDR_LIST may be dotted IP addresses or host names if the local OS has support for host name to IP address translation. When multiple names are added to EPICS_CA_ADDR_LIST they must be separated by white space. There is no requirement that the addresses specified in the EPICS_CA_ADDR_LIST be broadcast addresses, but this will often be the most convenient choice.
4.2 CA服务端：单机单IOC
此时该IOC启动时，
默认监听 5064 UDP 端口，以响应CA请求；
默认监听 5064 TCP 端口，用于和CA客户端建立CA连接，传输PV数据。
因此，此时CA客户端的 EPICS_CA_ADDR_LIST 设为单播地址或广播地址，均可访问到CA服务端的 IOC。
4.3 CA服务端：单机多IOC
单机运行多IOC时，
第一个启动的 IOC 默认监听 5064 UDP 端口，以响应CA请求；
默认监听 5064 TCP 端口，用于和CA客户端建立CA连接，传输PV数据。
而之后启动的 IOC 还会默认监听 5064 UDP 端口，以响应CA请求；
但监听的 TCP 端口号随机生成，用于和CA客户端建立CA连接，传输PV数据。
此时CA客户端的 EPICS_CA_ADDR_LIST 若设为广播地址，则可访问到CA服务端的所有 IOC。
但若设成单播地址，则不能访问到CA服务端的所有 IOC，往往只能访问到最后启动的那个 IOC，
因此，需要在IOC主机上用 iptables 对UDP的5064端口设置单播转广播。
例：CA客户端（192.168.188.131）向 CA服务端（192.168.206.235）发送 CA 请求：
在 CA服务端（192.168.206.235）设置：
iptables -t nat -A PREROUTING -d 192.168.206.235 -p udp --dport 5064 -j DNAT --to-destination 192.168.206.255
此时在CA服务端启动3个IOC。CA客户端的 EPICS_CA_ADDR_LIST=192.168.206.235， 设为单播地址。
# CA服务端第 2 个 IOC 输出信息
as warning: Configured TCP port was unavailable.
cas warning: Using dynamically assigned TCP port 38279,
cas warning: but now two or more servers share the same UDP port.
cas warning: Depending on your IP kernel this server may not be
cas warning: reachable with UDP unicast (a host's IP in EPICS_CA_ADDR_LIST)
iocRun: All initialization complete
2023-04-04T21:32:07.932 Using dynamically assigned TCP port 44921.
# CA服务端第 3 个 IOC 输出信息
cas warning: Configured TCP port was unavailable.
cas warning: Using dynamically assigned TCP port 45774,
cas warning: but now two or more servers share the same UDP port.
cas warning: Depending on your IP kernel this server may not be
cas warning: reachable with UDP unicast (a host's IP in EPICS_CA_ADDR_LIST)
iocRun: All initialization complete
2023-04-04T21:33:31.507 Using dynamically assigned TCP port 53823.
Several soft IOCs on one host
How to Make Channel Access Reach Multiple Soft IOCs on a Linux Host
5. 不同场景的实验测试
5.1 相同子网下的CA请求
5.1.1 206.235访问206.234上的PV
| EPICS_CA_ADDR_LIST | 127.255.255.255 | 192.168.206.255 | 192.168.255.255 | 192.255.255.255 | 255.255.255.255 |
|---|---|---|---|---|---|
| EPICS_CA_AUTO_ADDR_LIST=NO | × | √ | × | × | √ |
| EPICS_CA_AUTO_ADDR_LIST=YES | √ | √ | √ | √ | √ |
5.1.2 10.0.2.235/24 访问 10.0.2.200/24 （二者点对点连接）上的PV
当10.0.2.235/24（CA客户端）的EPICS_CA_ADDR_LIST=127.255.255.255、EPICS_CA_AUTO_ADDR_LIST=YES 时，CA请求的目的IP自动初始化为10.0.2.255（当前CA客户端所在子网的广播地址）。
执行caget dxw:ai3命令，与10.0.2.200/24之间的数据帧通信过程如下：
CA客户端先UDP广播询问该PV在哪，该PV所在主机UDP单播回答自己的IP地址。随后，CA客户端主动发起TCP连接，caget到PV值后，CA客户端主动关闭了该TCP连接。
当10.0.2.235/24（CA客户端）的EPICS_CA_ADDR_LIST=10.0.2.200、EPICS_CA_AUTO_ADDR_LIST=NO 时，CA请求的目的IP仅限于10.0.2.200（单播地址）。
执行caget dxw:ai3命令，与10.0.2.200/24之间的数据帧通信过程最开始是UDP单播询问该PV在哪，之后的过程与上述过程相同：
5.2 不同子网下的CA请求
5.2.1 206.235/24 访问 213.141/24 上的PV
| EPICS_CA_ADDR_LIST | 127.255.255.255 | 192.168.213.255 | 192.168.255.255 | 192.255.255.255 | 192.168.213.141 |
|---|---|---|---|---|---|
| EPICS_CA_AUTO_ADDR_LIST=NO | × | × | × | × | √ |
| EPICS_CA_AUTO_ADDR_LIST=YES | × | × | × | × | √ |
192.168.206.0和192.168.213.0是两个子网，需要网关转发：
$ traceroute 192.168.213.141
traceroute to 192.168.213.141 (192.168.213.141), 30 hops max, 60 byte packets1 gateway (192.168.206.1) 8.164 ms 8.524 ms 8.790 ms2 192.168.254.1 (192.168.254.1) 0.676 ms 0.643 ms 0.607 ms3 192.168.254.87 (192.168.254.87) 3.123 ms 3.460 ms 3.771 ms4 192.168.213.141 (192.168.213.141) 0.414 ms 0.388 ms 0.352 ms
IHEP校园网网关限制了跨网段转发广播类型包，在路由的最末端禁止了广播包：
$ traceroute 192.168.213.255
traceroute to 192.168.213.255 (192.168.213.255), 30 hops max, 60 byte packets1 gateway (192.168.206.1) 2.696 ms 3.024 ms 3.298 ms2 192.168.254.1 (192.168.254.1) 0.691 ms 0.655 ms 0.858 ms3 192.168.254.87 (192.168.254.87) 8.230 ms 8.707 ms 8.930 ms4 * * *5 * * *6 * * *
所以路由器也不会把192.168.213.255转发出去。
5.2.2 206.235/24 访问 19.31/24 上的PV
由于两个机器之间也跨网段，需要在中间的网关上进行设置（这里请计算中心的老师进行配合设置）。在206.235/24上进行设置，并caget：
$ EPICS_CA_ADDR_LIST=192.168.19.255
$ EPICS_CA_AUTO_ADDR_LIST=no$ caget aaa
在206.235/24上抓包结果为：
$ sudo tcpdump -nn -i eno1|grep 192.168.19.255.5064
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:16:04.306329 IP 192.168.206.235.53922 > 192.168.19.255.5064: UDP, length 40
11:16:04.338373 IP 192.168.206.235.53922 > 192.168.19.255.5064: UDP, length 40
11:16:04.402205 IP 192.168.206.235.53922 > 192.168.19.255.5064: UDP, length 40
11:16:04.530383 IP 192.168.206.235.53922 > 192.168.19.255.5064: UDP, length 40
11:16:04.786288 IP 192.168.206.235.53922 > 192.168.19.255.5064: UDP, length 40
在19.31/24上抓包结果为：
$ sudo tcpdump -nn -i eno1|grep 255.5064
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:16:04.306329 IP 192.168.206.235.53922 > 255.255.255.255.5064: UDP, length 40
11:16:04.338373 IP 192.168.206.235.53922 > 255.255.255.255.5064: UDP, length 40
11:16:04.402205 IP 192.168.206.235.53922 > 255.255.255.255.5064: UDP, length 40
11:16:04.530383 IP 192.168.206.235.53922 > 255.255.255.255.5064: UDP, length 40
11:16:04.786288 IP 192.168.206.235.53922 > 255.255.255.255.5064: UDP, length 40
由于19.31/24上实际并未运行IOC，所以不具备名为aaa的PV，因此206.235/24发了5个为了查找PV的UDP广播包。若19.31/24上具备名为aaa的PV，则caget是可以成功的。
从以上实验结果可以看出，跨网段发UDP广播包查找PV是可行的。
206.235/24发送广播包出来时，目的IP是直接广播192.168.19.255；到了接收端，目的IP被转变成了有限广播255.255.255.255。对此的解释：“交换机作转发的时候，在vlan内部改的这个目标地址，属于正常操作。vlan内部没必要有网段标记了，因此是全网广播。同时，交换机不会把这个全255广播转发给其他非19.xxx的子网。”
5.2.3 10.0.2.235/16 访问 10.0.2.200/24 上的PV（10.0.2.235/16 与 10.0.2.200/24 点对点连接，实际上网络根本ping不通）
| EPICS_CA_ADDR_LIST | 127.255.255.255 | 10.0.2.255 | 10.0.255.255 | 10.255.255.255 | 10.0.2.200 |
|---|---|---|---|---|---|
| EPICS_CA_AUTO_ADDR_LIST=NO | × | × | × | × | × |
| EPICS_CA_AUTO_ADDR_LIST=YES | × | × | × | × | × |
对以上各个情况的解释：
（1）EPICS_CA_ADDR_LIST=127.255.255.255、EPICS_CA_AUTO_ADDR_LIST=YES 时，目的IP=10.0.255.255，目的MAC= ff-ff-ff- ff-ff-ff，10.0.2.200/24收到了数据帧，但是不响应该CA请求。
（2）此时10.0.2.255对于10.0.2.235/16 来说只是一个普通IP，并不是广播地址。发出CA请求之前会先发送ARP请求获得10.0.2.255的MAC地址，然而得不到响应。因此，EPICS_CA_ADDR_LIST=10.0.2.255时，不知道将CA请求的数据帧发给谁。
（3）此时10.255.255.255对于10.0.2.235/16 来说，已经不属于当前子网范围，所以CA请求的UDP广播帧根本就不会发出去。
（4）EPICS_CA_ADDR_LIST=10.0.2.200时，发出单播数据帧到10.0.2.200/24，可以收到响应。
5.3 同时请求多个主机上的多个IOC的PV
在连接PV时，发出的UDP查询报文中，同一报文内可能会夹杂来自多个主机的多个IOC的PV请求，而单个IOC可能会出现无权限对这种报文进行响应的情况，于是这种UDP查询作废或查询结果不完全，CA客户端继续发出UDP查询报文；当报文中对某一主机仅包含同一IOC的PV请求时，才会被该IOC响应。这一过程可能造成PV连接过程较久。
例：CA客户端（192.168.188.131）向 CA服务端（192.168.206.235）发送 CA 请求：
EPICS_CA_ADDR_LIST="192.168.206.235"
camonitor 234_ioc1:circle:x 235_ioc2:circle:x 235_ioc4:circle:x
其中，234_ioc1:circle:x 是 192.168.206.234 上的PV，235_ioc2:circle:x、235_ioc4:circle:x 是 192.168.206.235 上的PV。
235_ioc4 输出信息：
epics> CAS: UDP send to 192.168.188.131:58159 failed: Operation not permitted
6. 最终结论
EPICS CA请求是否可达，取决于两个因素：
- 目的IP列表的正确设置
- 网络连接上是否可达1（客户端可以发出请求并收到服务端返回的数据包、服务端可以收到请求）
当发出CA请求的客户端与IOC主机之间跨网段，会经过网关/路由器2，需要考虑目的IP列表中的IP是否可达的问题。
两种方案：
网关/路由器禁止广播
EPICS_CA_ADDR_LIST=IP1 IP2 … Ipn（所有IOC主机的IP）
单机运行多IOC时，需要在IOC主机上用iptables对UDP的5064端口设置单播转广播。
Several soft IOCs on one host
How to Make Channel Access Reach Multiple Soft IOCs on a Linux Host
网关/路由器不禁止广播
EPICS_CA_ADDR_LIST=subnet1_bcast subnet2_bcast …（所有IOC主机所在子网的广播地址）
7. 待解决问题
测试过程中发现，Windows操作系统无法接收UDP广播，原因待查；Linux接收正常，其他操作系统待测试。
附录
1. 查看本机ARP缓存表的命令
arp -a 或 ip neigh
删除某条ARP缓存：arp -d <IP>
2. 查看本机路由表
netstat -rn 或 ip route 或 route -n
仅限于IP，不含MAC
3. 查看本机到某IP的路由
traceroute <IP>
4. 对本机某网卡抓包
IP层（IP数据报）：tcpdump -nn -i <interface>
MAC层（数据帧）：tshark、wireshark
Linux网络抓包分析工具（tcpdump、wireshark）
Wireshark基础使用和表达式语法
5. 防火墙和iptables
防火墙技术原理
Linux查看防火墙状态及开启关闭命令
Linux firewall防火墙详解（一）——firewall基础知识简介
Linux firewall防火墙详解（二）——firewall配置
firewall-cmd 使用总结
iptables系列教程（一）| iptables入门篇
iptables系列教程（二）| iptables语法规则
每一次IP请求发出时，IP报文中的目的IP就是当前请求的IP地址。而进一步封装成数据帧时，首先查询本机ARP缓存表中有无该IP的MAC映射，没有则ARP广播获得该映射，然后将目的MAC置为该IP所对应的MAC地址；若该IP的主机并不在当前局域网内，ARP广播无法获得该IP到MAC的映射，只能将目的MAC置为网关的MAC地址，交给路由器去查找该IP的路由。能查到该路由则数据链路层连接成功，否则连接失败。
数据链路层连接成功后，还要考察网络层的源IP是否在目的IP的相同子网下，这可能会影响目的IP所在主机是否会返回响应。
192.168.206.146 ping 192.168.213.141 成功；
192.168.206.146 ping 192.168.255.255 失败。 ↩︎网关与路由器区别
交换机转发广播属于常规功能。
路由器一般不转发广播包（https://blog.csdn.net/zxh2075/article/details/53817754），
但也可以设置能够转发广播包。 ↩︎
这篇关于EPICS CA请求能否成功的影响因素的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
