IP partnership requirements

When you create and manage IP partnerships, consider the following requirements and constraints:

A system can be part of up to three IP partnerships.
You can create IP partnerships between systems that are in the same layer. In other words, both systems in the partnership must be at the storage layer or both systems must be at the replication layer.
A secured IP partnership uses certificate-based authentication to create a secure communication channel between the partnered systems. You must ensure that the following requirements are met so that replicated data is encrypted and communication between partnered systems is secure. For more information, see Planning secured IP partnerships.
You cannot use link-local addressing.
If you use IPv4 addressing, the management IP addresses on both systems must be IPv4-compliant, and these addresses must have connectivity with each other.
If you use IPv6 addressing, the management IP addresses on both systems must be IPv6-compliant, and these addresses must have connectivity with each other.
You must configure all links between the production and recovery site with either IPv4 or IPv6 addresses.
A system can have simultaneous partnerships over Fibre Channel and IP but with separate systems.
Data compression is supported for IPv4 or IPv6 partnerships. To enable data compression, both systems in an IP partnership must be running a software level that supports IP partnership compression.
To fully enable compression in an IP partnership, each system must enable compression. When compression is enabled on the local system, by using the mkippartnership or chpartnership commands, data sent to the remote system is compressed. To send compressed data to the local system, the remote system in the IP partnership must also enable compression.
The use of WAN optimization devices such as Riverbed are not supported in native Ethernet IP partnership configurations.
Bandwidth limiting on IP partnerships between both sites is supported.
Review the appropriate hardware guide to understand which ports can be used for IP partnerships.
Using an Ethernet switch to convert a 25 Gbps to a 1 Gbps IP partnership, or a 10 Gbps to a 1 Gbps partnership is not supported.
The IP infrastructure on both partnership sites must match.
When an IP partnership is configured between two systems with one system on an older build and system management IP is configured on the port other than the default port in a newer build. The lssystemip command on the older build shows stale port_id value as 1 and 2 for remote system. Until the other system is upgraded with latest build, it continues to show stale port_ids. To get actual port_id, lsip can be used in the remote system.

Port configuration requirements

Specific ports are used by systems for IP partnerships (long-distance using TCP and short-distance using RDMA) communications. See the table TCP and UDP ports that are supported in section TCP and UDP ports for more information.
The maximum supported round-trip time between systems is 80 milliseconds (ms).
Portsets are groupings of logical addresses that are associated with the specific traffic types.
Each IP partnership can be mapped to two portsets, one for each link between systems. For a partnership with a single link, a single portset can be defined with the -link1 attribute in the mkippartnership command for partnerships with a single intersite link. For a partnership with dual links, a second portset must be defined with the -link2 attribute to specify the second portset for a dual link configuration. You can also use the management GUI to specify portset for each intersite link.

If your system supports Ethernet ports of several speeds, only one of those speeds can be used to configure all of the replication links between the local and remote site.
Note: You can use 25 Gbps Ethernet ports to establish an IP partnership between systems. However, 25 Gbps Ethernet ports do not provide an additional performance advantage over IP partnerships that are established using 10 Gbps Ethernet ports.
iSCSI hosts can access volumes over IP ports that are participating in an IP partnership; however, this access might result in an impact on performance.
VLAN tagging of the IP addresses configured for replication is supported.
IP partnerships do not support Network Address Translation (NAT) traversal. Most NAT implementations change the IP address and ports of the IP packets when the packets traverse the NAT or a network firewall. IP replication does not work with transport protocols that change the IP header source and destination IP addresses and their associated port numbers.
If you configure two intersite WAN links, you must assign each WAN link to separate portset, one for each link.
If you have one intersite link, you must configure one replication port group for that link.
No more than two intersite links are supported.
Only one port in a node can be configured in an IP partnership.
If you connect systems by directly attaching them without switches, you must have only two direct-attach links. Both direct-attach links must be on the same I/O group. You should use two port groups, where a port group contains only the two ports that are directly linked.

If you choose to use compression and IP partnership in the same system, certain hardware updates or configuration choices might help increase IP partnership performance:

Use a different port for IP partnership traffic, which is not used for iSCSI host, iSCSI virtualization, iSCSI backend, and RDMA clustering. Also, use a different VLAN ID for iSCSI host I/O and IP partnership traffic.

Requirements for short-distance partnerships using RDMA

When you create and manage short-distance partnerships using RDMA, consider the following requirements and constraints:

Up to two short-distance partnership using RDMA can be configured per system.
You can create short-distance partnership using RDMA between systems that are in the replication layer. In other words, systems in the short-distance partnership using RDMA must be at the storage layer or both systems must be at the replication layer.
The system supports a maximum of 6 highspeedreplication portsets.
You cannot use link-local addressing.
Configure all links between the production and recovery site with either IPv4 or IPv6 addresses.
A system can have simultaneous partnerships over native-IP and short-distance partnership using RDMA but with separate remote systems.
Systems that are configured in active short-distance partnership using RDMA must not be zoned with each other for Fibre Channel.
VLAN tagging of the IP addresses configured for highspeedreplication portsets is supported.
Short-distance partnership using RDMA do not support Network Address Translation (NAT) traversal. Most NAT implementations change the IP address and ports of the IP packets when the packets traverse the NAT or a network firewall. IP replication does not work with transport protocols that change the IP header source and destination IP addresses and their associated port numbers.
If you have one intersite link, you must assign one highspeedreplication portset for that link that is, all ports that belong to the portset must be connected by using that link.
If you configure two inter-site links, you can configure two highspeedreplication portset and assign one portset per link.
No more than two intersite links are supported.
If you have one highspeedreplication portset, then configure maximum of two ports from each node in one I/O group in that highspeedreplication portset.
If you have two highspeedreplication portsets and one I/O group, then on each system, configure maximum of two ports from one node in the first highspeedreplication portset. Then, configure maximum of two ports from the other node in the second highspeedreplication portset.
If you connect systems by directly attaching them without switches, you must have only two direct-attach links. Both direct-attach links must be on the same I/O group. Use two port groups, where a port group contains only the two ports that are directly linked.