This article describes the cause behind why switches are not able to communicate with remote host / syslog server.

Below are the log messages seen during the issue time:

Mar 22 18:39:23.171 root eventd: %SYSLOG-3: Trying bind to default address: Can't assign requested address
Mar 22 18:39:23.172 root eventd: %SYSLOG-3: bind: Invalid argument
Mar 22 18:39:28.182 root eventd: %SYSLOG-3: could not bind to address XX.XX.XX.XX: Can't assign requested address

Syslog bind failure logs are seen if the devices are upgraded to releases from 21 or beyond. This is not a bug issue, it is configuration issue.

Triggers:
 

• On all EX and QFX platforms.

• The config must contain source IP configured under syslog hierarchy and management routing instance configured globally. Below is the config:

#set system syslog source-address <IP-address>
#set system management-instance

• This issue seems to be present on releases even before the 22/21 junos OS versions, but because of the recent enhancement that was made on the newer versions to resolve the issue reported on another PR, led to the logging of the messages "failed to bind" on the switch.

• The messages are obviously harmless, and indicate that syslog server communication cannot happen with the source-address configured due to the reasons being as source address configured is not the part of mgmt_junos (management-instance). Only when source-address is part of routing-instance configured [edit system management-instance] is enabled, communication happens and syslogs are transferred to remote host with configured source-address.

• Whenever the management-instance is enabled, traffic goes via non default routing instance, which is known as "mgmt_junos". Meaning, all the routes will get switched from default routing-instance to Mgmt_instance. Syslog will make use of Mgmt_junos routing instance, unless its configured source address is part of mgmt_junos, syslog won’t be transferred to the Remote host.

• Now if the source address for the syslog is configured using the IP address which is part of the default routing instances inet.0, bind will eventually fail because it will choose the inet.0 instance over the mgmt_junos routing instances and thus the below log messages will be seen on "failed to bind address"
   

Mar 22 18:39:23.171 root eventd: %SYSLOG-3: Trying bind to default address: Can't assign requested address
Mar 22 18:39:23.172 root eventd: %SYSLOG-3: bind: Invalid argument
Mar 22 18:39:28.182 root eventd: %SYSLOG-3: could not bind to address XX.XX.XX.XX: Can't assign requested address
 

Workaround to solve this issue is below:
 

1. If you want management_instance configured at the system level, in that case you can make use the fxp0 IP / em0 (management address) address as source-address as it uses the mgmt_junos routing instances to forward the syslog to remote-host under syslog hierarchy.

2. If you have already used lo0 address as source address, in that case, you can delete management-instance configured at system level, so the customer can use the same lo0 address as the source address, syslog uses the default routing-instance inet.0 to forward to the remote host.

About management routing instance:
https://www.juniper.net/documentation/us/en/software/junos/junos-getting-started/topics/topic-map/management-interface-in-non-default-instance.html