Beruflich Dokumente
Kultur Dokumente
In CoreXL, the firewall instances do not synchronize any data, thus it is crucial to maintain
full stickiness for the connections. Every packet of a specific session should always be
directed by the Dispatcher to the same instance that started handling the first packet of the
session.
You should check all the connections that have been opened on a specific instance. You can
then verify that the control and data connection were directed to the same instance.
To verify that control and data connections of a session are redirected to the same
instance:
1. Run the command: fw –i <instance_number> tab –t connections –u.
All the connections that have been opened on the instance are displayed.
3. Verify that the control connection and data connection were directed to the same
instance.
• ftp • realaudio
• h323 • rsh
• iiop • rtsp
• netshow • sqlnet
• pptp
To confirm that the local sync mechanism is working, you should verify that the table has the
same data on all the instances. For example, you can run fw –i <instance_num> tab
–t <table_with_local_sync> -u on all instances and verify that the output is the
same for all instances.
Here is a list of tables that have that use the local sync mechanism:
• dynobj_cache • exchange_notifies
• userc_users • rpc_serv
• DAG_IP_to_ID • rpc_serv_hosts
• dcerpc_maps • pmap_not_responding
• dcerpc_rmaps • freetel_connections
• dcerpc_udp_maps • p2p_logged
• dcerpc_udp_rmaps • sip_dynamic_port
• dcerpc_udp_hpov_maps • mgcp_dynamic_port
• dcom_objects • domain_cache
• dcom_high_port • arp_table
• dcom_remote_activations
2. If the problem does not reproduce, then there is most likely a problem with CoreXL.
3. If the problem reproduces – try to reproduce the same problem on R65. It is likely
that there is a problem with R65 and not with CoreXL.