This article addresses the following message seen in logs:
[email protected] as root: cmd='rcp -p -f /config/juniper.conf+.gz'
What does the log message ‘[email protected] as root: cmd=’rcp -p -f /config/juniper.conf+.gz’ mean? Is this a security issue?
When any operation requires one node to access files on another node, RCP messages to or from 129.x.0.1 and/or 130.x.0.1 may be seen.
This is expected behavior when one node must access files on another node. A common operation that triggers this is a commit command. When a commit is done on Node0, Node0 will have to get the configuration file from Node1. It does this by logging into Node1 over the HA control ports.
Here is an example of this portion of a commit operation:
<190>1 2010-03-03T11:23:08.134-05:00 srx mgd 37021 UI_COMMIT_PROGRESS [[email protected] message="filename /config/juniper.conf+.gz, size 8997"] Commit operation in progress: filename /config/juniper.conf+.gz, size 8997 <39>1 2010-03-03T11:23:08.166-05:00 srx rshd 37203 - - [email protected] as root: cmd='rcp -p -f /config/juniper.conf+.gz' <190>1 2010-03-03T11:23:08.188-05:00 srx mgd 37021 UI_COMMIT_PROGRESS [[email protected] message="pull-configuration success. URL: /var/tmp/juniper.conf+.gz"] Commit operation in progress: pull-configuration success. URL: /var/tmp/juniper.conf+.gz <190>1 2010-03-03T11:23:08.189-05:00 srx mgd 37021 UI_COMMIT_PROGRESS [[email protected] message="sending load-update rpc to node1"] Commit operation in progress: sending load-update rpc to node1 <190>1 2010-03-03T11:23:08.589-05:00 srx mgd 37021 UI_COMMIT_PROGRESS [[email protected] message="remote load-configuration success on node1"] Commit operation in progress: remote load-configuration success on node1 <190>1 2010-03-03T11:23:08.589-05:00 srx mgd 37021 UI_COMMIT_PROGRESS [[email protected] message="sending file-delete rpc to node1"] Commit operation in progress: sending file-delete rpc to node1 <190>1 2010-03-03T11:23:08.625-05:00 srx mgd 37021 UI_COMMIT_PROGRESS [[email protected] message="asking node1 to commit"] Commit operation in progress: asking node1 to commit
By default, the SRX uses 129.x.0.1/2 on the em0 and em1 control ports on Node0 and 130.x.0.1/2 on the control ports on Node1. The second octet is a multiple of 16 of the cluster id. ClusterID 3 = 129.48.0.1. For hardware that supports cluster IDs 16 and above, the same IPs are re-used and it is required that if other clusters are in the same L2 broadcast they must be separated by VLANn. However, the optimal configuration in all situations is for all HA ports, control and fabric, to be directly connected.
{primary:node0}
root@FW1> show interfaces terse | find em0
em0 up up
em0.0 up up inet 129.48.0.1/2
tnp 0x1300004
em1 up up
em1.0 up up inet 129.48.0.1/2
tnp 0x1300004
fab0 up up
fab0.0 up up inet 30.49.0.200/24
fab1 up up
fab1.0 up up inet 30.50.0.200/24
fxp0 up up
fxp0.0 up up inet 172.22.145.27/24
{secondary:node1}
root@FW2> show interfaces terse | find em0
em0 up up
em0.0 up up inet 130.48.0.1/2
tnp 0x2300004
em1 up up
em1.0 up up inet 130.48.0.1/2
tnp 0x2300004
fab0 up up
fab0.0 up up inet 30.49.0.200/24
fab1 up up
fab1.0 up up inet 30.50.0.200/24
fxp0 up up
fxp0.0 up up inet 172.22.145.39/24
Note: Although these addresses are not rfc1918 addressing, they are what the SRX uses for the HA links.
Additional security can be added by enabling HA port encryption.