PGP Universal Server configuration with Multiple Interfaces on the same subnet: WARNING
|Article:TECH174335|||||Created: 2011-11-14|||||Updated: 2011-12-09|||||Article URL http://www.symantec.com/docs/TECH174335|
Although it is possible to create multiple interfaces on the same subnet, be it virtual, or physical, doing so can cause major problems with the PGP Universal Server and how it handles its own processes and connections. Some of these processes and connections include, but are not limited to:
*Clustering abnormalities or failure to replicate data to cluster members.
*Mail flow problems where there is high potential for mail looping, or incorrect processing of mail.
*Database abnormalities, including creation of duplicate data in a database causing problems.
*Connectivity issues, such as mail processing not responding properly, keyserver search requests failing to serve etc.
It is therefore highly discouraged to configure such environments as many issues have been traced back to this type of configuration.
An example of multiple interfaces on the same subnet is as follows:
Another example of this could be:
The last example is for virtual NICs where both interfaces actually use the same NIC.
These above examples are only to illustrate what is meant by multiple interfaces on the same subnet.
If a PGP Universal Server has multiple physical NICs, or if it is needed to have multiple IP addresses on the PGP Universal Server, please plan accordingly such that this configuration is avoided. Doing so will complicate supporting of the PGP Universal server and the likelihood of causing problems is high.
Support for multiple interfaces is intended to provide connectivity across subnets. For instance, you may have a private interface for most PGP Universal Server functions and a public interface for Web Messenger.
For a gateway placement, one adapter may be connected either directly to the Internet or placed in a DMZ while the other adapter provides connectivity to the local network.
NIC teaming is not currently supported.
Article URL http://www.symantec.com/docs/TECH174335