Is anyone seeing any traffic over TCP7014 after patching to 8.4 P3?
This is not a port that is specified as needing to be open between any combination(s) of the primary and replica (that I can find) yet i am seeing dropped traffic from the primary to the replica from our enterprise firewalls. My reference doc is the rsa_authentication_manager_8.4_planning_guide.pdf and i checked both the port traffic and access through a firewall sections.
Interestingly, there were drops from the primary to all of the replicas when applying the patch, and to 1 of 4 replicas, the attempts continue since and are occurring about every 10-15 seconds. The process is Java (syn_sent). Also, the replica does not appear to be listening for this traffic.
Any help is greatly appreciated.
7014 TCP (java) Internal use only. Used by RSA server.
It is internal port for radiusoc.
This use of the netstat command can show what AM process is responsible for which port:
netstat -Tnlutp | egrep '^(tcp|udp)' | awk '{split($NF,p,"/");pscmd="ps --no-heading -fp " p[1] "|tr -s [:space:]";pscmd|getline psout;close(pscmd);split(psout,ps," ");x=index(psout,"-Dweblogic.Name=");if(x>0){split(substr(psout,x+16,20),pn," ");pname="AM: " pn[1];}else{x=index(psout,ps[8]);pname=substr(psout,x);}; printf("PID: %15s %3s | CONNECT: %-30s | %8s | PROCESS: %s\n",$NF,$1,$4,ps[1],pname); }'
In this example of the above command, port 7014 is radiusoc
<snip>
PID: 20437/java tcp | CONNECT: 127.0.0.1:7012 | rsaadmin | PROCESS: AM: biztier
PID: 20437/java tcp | CONNECT: ::1:7012 | rsaadmin | PROCESS: AM: biztier
PID: 20437/java tcp | CONNECT: 10.101.99.150:7012 | rsaadmin | PROCESS: AM: biztier
PID: 21482/java tcp | CONNECT: 127.0.0.1:7013 | rsaadmin | PROCESS: AM: console
PID: 21482/java tcp | CONNECT: ::1:7013 | rsaadmin | PROCESS: AM: console
PID: 21482/java tcp | CONNECT: 10.101.99.150:7013 | rsaadmin | PROCESS: AM: console
PID: 20027/java tcp | CONNECT: 127.0.0.1:7014 | rsaadmin | PROCESS: AM: radiusoc
PID: 20027/java tcp | CONNECT: ::1:7014 | rsaadmin | PROCESS: AM: radiusoc
PID: 20027/java tcp | CONNECT: 10.101.99.150:7014 | rsaadmin | PROCESS: AM: radiusoc
PID: 20027/java tcp | CONNECT: ::1:7082 | rsaadmin | PROCESS: AM: radiusoc
PID: 20027/java tcp | CONNECT: 127.0.0.1:7082 | rsaadmin | PROCESS: AM: radiusoc
PID: 20027/java tcp | CONNECT: 10.101.99.150:7082 | rsaadmin | PROCESS: AM: radiusoc
<snip>
There should be no reason for it to seek or receive traffic to/from another server, just to itself.
---
I am running a tcpdump -i any tcp port 7014 on my primary, and replica, watching. It only want to connect to itself,
primary is 10.101.99.150 to 10.101.99.150, replica is 10.101.99.151 to 10.101.99.151, in bursts of a few packets every
minute or so.
replica 10.101.99.151
edavis-vm151:~ # tcpdump -i any tcp port 7014 -nn
14:04:46.739665 IP 10.101.99.151.52310 > 10.101.99.151.7014:
14:04:46.739681 IP 10.101.99.151.7014 > 10.101.99.151.52310:
14:04:46.739691 IP 10.101.99.151.52310 > 10.101.99.151.7014:
14:04:46.782649 IP 10.101.99.151.7014 > 10.101.99.151.52310:
<snip>
14:05:46.811290 IP 10.101.99.151.52312 > 10.101.99.151.7014:
14:05:46.811352 IP 10.101.99.151.52312 > 10.101.99.151.7014:
14:05:46.811358 IP 10.101.99.151.7014 > 10.101.99.151.52312:
14:05:46.811374 IP 10.101.99.151.52312 > 10.101.99.151.7014:
14:05:46.812235 IP 10.101.99.151.7014 > 10.101.99.151.52312:
14:05:46.812252 IP 10.101.99.151.52312 > 10.101.99.151.7014:
primary 10.101.99.150
edavis-vm150:~ # tcpdump -i any tcp port 7014 -nn
14:01:33.620253 IP 10.101.99.150.32794 > 10.101.99.150.7014:
14:01:33.620277 IP 10.101.99.150.7014 > 10.101.99.150.32794:
14:01:33.620296 IP 10.101.99.150.32794 > 10.101.99.150.7014:
14:01:33.655011 IP 10.101.99.150.7014 > 10.101.99.150.32794:
<snip>
14:06:33.687978 IP 10.101.99.150.32846 > 10.101.99.150.7014:
14:06:33.692897 IP 10.101.99.150.7014 > 10.101.99.150.32846:
14:06:33.692924 IP 10.101.99.150.32846 > 10.101.99.150.7014: