Hi Issa,
I'm guessing you are seeing the results detailed below;
Automatic Change of Server Status Initiated by Server with Secondary Status
1. 
The Connection Server Role Manager service on the server with Secondary status does not receive contact from the Connection Server Role Manager service on the server with Primary status.
2. The Connection Server Role Manager service on the server with Secondary status confirms its network connection by pinging the local host and other known remote servers.
3. If the network connection is confirmed, the Connection Server Role Manager service on the server with Secondary status posts an alarm that it is initiating a change of status.
If the network connection is not available, the status does not change and the remaining events do not occur.
4. The Connection Server Role Manager service on the server with Secondary status sets its status in the database to Primary.
5. The Connection Server Role Manager service on the server that now has Primary status starts the critical services on that server.
6. The data connector detects the changed status and sets the connections to use the database on the server that now has Primary status.
7. If possible, database and message store replication continues between the servers.
8. The Connection Server Role Manager service on the server that now has Primary status posts an alarm that the change of status is complete.
Now, the second question is how your Cluster has been configured. In the CUC "Best Practice" the Sub would
be taking the bulk of the calls so you wouldn't see a hit here.
You may also want to have a look at the HA section of this excellent design Guide
(attached) which speaks to the "Best practice" for Port distribution between Pub and Sub;
Cheers!
Rob
