[ZBX-15802] Sending configuration data from zabbix server to a passive proxy via site-2-site vpn with datalen above ~67.000 failed Created: 2019 Mar 12 Updated: 2019 Mar 14 Resolved: 2019 Mar 14 |
|
| Status: | Closed |
| Project: | ZABBIX BUGS AND ISSUES |
| Component/s: | Proxy (P), Server (S) |
| Affects Version/s: | 4.0.5 |
| Fix Version/s: | None |
| Type: | Problem report | Priority: | Major |
| Reporter: | Stephan Wimmer | Assignee: | Zabbix Support Team |
| Resolution: | Won't fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
CentOS Linux release 7.6.1810 (Core), 3.10.0-957.5.1.el7.x86_64; Zabbix 4.0.5 (server and proxy), mariadb-5.5.60-1.el7_5.x86_64 |
||
| Description |
|
Zabbix Server connected via a site-2-site vpn (including port nat) to a passive (remote zabbix-proxy. Everything works fine...
...until we increase the number of items collected. If we reach a limit of about 64k datalen the configuration couldn't be send and the proxy heartbeat stop working. Summary of logfile (time is not exactly syncronised between zabbix-server and proxy!) Zabbix-Server: 5120:20190311:151441.642 sending configuration data to proxy "PROXY_NAME" at "127.0.0.1", datalen 67363 Zabbix-Proxy: 6497:20190311:151717.886 received configuration data from server at "X.X.X.X", datalen 67363
After increasing the items: Zabbix-Server: 5120:20190311:151541.650 sending configuration data to proxy "PROXY_NAME" at "127.0.0.1", datalen 92069 Zabbix-Server: 5120:20190311:152041.650 cannot send configuration data to proxy "PROXY_NAME" at "127.0.0.1": ZBX_TCP_READ() timed out Zabbix-Proxy: 6501:20190311:152357.648 cannot send proxy data to server at "X.X.X.X": ZBX_TCP_READ() timed out -> no transfer possible.
It looks similar to bug
|
| Comments |
| Comment by Arturs Lontons [ 2019 Mar 13 ] |
|
Hi, The root cause in this situation might be quite difficult to pin-point. First off, we have to make sure that this is not a networking issues. Incorrect configuration parameters on the networking side such as MTU can be the cause of such behavior. Please check the networking hardware configuration on your side first. Additionally, you should perform a tcpdump and check the traffic between server and proxy to further troubleshoot the issue. |
| Comment by Stephan Wimmer [ 2019 Mar 13 ] |
|
Hi, after hard network analysis (we have some port nat's and firewalls between server and proxy connection) the target firewall (palo alto) caused the problem. The solution was, that we captured the denied packets and create a new allowed application within the rule set.
Very sorry for any inconvenience! The issue can be closed.
stephan |