Setting TCP/IP Protocol Properties

Use the ipadm command to configure protocol properties, also known as tunables. The ipadm replaces the ndd command, which was commonly used in previous releases to set tunables.

TCP/IP properties can be either interface based or global. Properties can be applied to a specific interface or globally to all interfaces in a zone. Global properties can have different values in different non-global zones. For a list of supported protocol properties, refer to the ipadm(1M) man page.

Typically, the default values of the TCP/IP internet protocol suffice for the network to function. However, if the default values are insufficient for your network topology, then you can customize these properties as needed.

Three ipadm subcommands are used to set TCP/IP interface properties:

• The ipadm show-prop -p property protocol command displays the properties of a protocol and their current values. If you do not use the -p property option, then all the properties of the protocol are listed. If you do not specify a protocol, then all the properties of all protocols are listed.

• The ipadm set-prop -p property=value protocol subcommand assigns a value to the IP interface's property.

• The ipadm reset-prop -p property protocol subcommand resets the specific protocol property to its default values.

Enabling Packet Forwarding Globally

Enabling Packet Forwarding shows how to enable packet forwarding on the interface. Setting packet forwarding on the IP interface property enables you to implement this feature selectively. You can enable this property only on specific interfaces on the system.

If you want to enable packet forwarding on the entire system regardless of the number of IP interfaces, then you use the protocol property: In protocols, the property name is the same as in IP interfaces, which is forwarding. You must issue the command separately to enable packet forwarding on IPv4 and IPv6 protocols.

The following example shows how to enable packet forwarding for all IPv4 and IPv6 traffic on the system:

# ipadm show-prop -p forwarding ip
PROTO   PROPERTY     PERM   CURRENT   PERSISTENT   DEFAULT   POSSIBLE
ipv4    forwarding   rw     off       --           off       on,off
ipv6    forwarding   rw     off       --           off       on,off
#
# ipadm set-prop -p forwarding=on ipv4
# ipadm set-prop -p forwarding=on ipv6
#
# ipadm show-prop ip
PROTO   PROPERTY     PERM   CURRENT   PERSISTENT   DEFAULT   POSSIBLE
ipv4    forwarding   rw     on        on           off       on,off
ipv4    ttl          rw     255       --           255       1-255
ipv6    forwarding   rw     on        on           off       on,off
ipv6    hoplimit     rw     255       --           255       1-255#

Setting Up a Privileged Port

On transport protocols such as TCP, UDP, and SCTP, ports 1–1023 are default privileged ports where only processes that run with root permissions can bind to these ports. By using the ipadm command, you can reserve a port beyond this given default range such that it becomes a privileged port. Thus, only root processes can bind to that port. To set up a privileged port, you customize the following transport protocol properties:

• smallest_nonpriv_port - The property whose value indicates the range of port numbers to which regular users can bind. If your designated port is within this range, then you can set it as a privileged port. Use the ipadm show-prop command to display the property's values.

• extra_priv_ports - The property that specifies which ports are privileged. Use the ipadm set-prop subcommand to specify ports you want to restrict. This property can be assigned multiple values.

As an example, suppose you want to set TCP ports 3001 and 3050 as privileged ports with access restricted only to the root user. The smallest_nonpriv_port property indicates that 1024 is the lowest port number for a non privileged port. Therefore, the designated ports 3001 and 3050 can be changed to become privileged ports. You would proceed by issuing commands similar to the following:

# ipadm show-prop -p smallest_nonpriv_port tcp
PROTO PROPERTY                PERM   CURRENT   PERSISTENT   DEFAULT   POSSIBLE
tcp   smallest_nonpriv_port   rw     1024      --           1024      1024-32768

# ipadm show-prop -p extra_priv_ports tcp
PROTO   PROPERTY           PERM   CURRENT     PERSISTENT   DEFAULT     POSSIBLE
tcp     extra_priv_ports   rw     2049,4045   --           2049,4045   1-65535

# ipadm set-prop -p extra_priv_ports+=3001 tcp        
# ipadm set-prop -p extra_priv_ports+=3050 tcp
# ipadm show-prop -p extra_priv_ports tcp
PROTO   PROPERTY           PERM   CURRENT     PERSISTENT   DEFAULT     POSSIBLE
tcp     extra_priv_ports   rw     2049,4045   3001,3050    2049,4045   1-65535
                                  3001,3050

To remove one of the ports, for example, 4045, from being a privileged port, you would type the following commands:

# ipadm set-prop -p extra_priv_ports-=4045 tcp
# ipadm show-prop -p extra_priv_ports tcp
PROTO   PROPERTY           PERM   CURRENT     PERSISTENT   DEFAULT     POSSIBLE
tcp     extra_priv_ports   rw     2049,3001   3001,3050    2049,4045   1-65535
                                  3050

Implementing Symmetric Routing on Multihomed Hosts

By default, a system with multiple interfaces, also called a multihomed host, routes its network traffic based on the longest matching route to the traffic's destination in the routing table. When multiple routes of equal length to the destination exist, Oracle Solaris applies Equal-Cost Multi-Path (ECMP) algorithms to spread the traffic across those routes.

Spreading the traffic in this manner is not ideal in certain cases. An IP packet might be sent through an interface on a multihomed host that is not on the same subnet as the IP source address in the packet. Further, if the outgoing packet is a response to a certain incoming request, such as an ICMP echo request, the request and the response might not traverse the same interface. Such a traffic routing configuration is called asymmetric routing. If your Internet service provider is implementing ingress filtering as described in RFC 3704 (http://rfc-editor.org/rfc/bcp/bcp84.txt), an asymmetric routing configuration might cause an outgoing packet to be dropped by the provider.

RFC 3704 intends to limit denial-of-service attacks across the Internet. To comply with this intent, your network must be configured for symmetric routing. In Oracle Solaris, the IP hostmodel property enables you to meet this requirement. This property controls the behavior of IP packets that are received or transmitted through a multihomed host.

The hostmodel property can have one of three possible values:

strong

Corresponds to the strong end system (ES) model as defined in RFC 1122. This value implements symmetric routing.

weak

Corresponds to the weak ES model as defined in RFC 1122. With this value, a multihomed host uses asymmetric routing.

src-priority

Configures packet routing by using preferred routes. If multiple destination routes exist in the routing table, then the preferred routes are those that use interfaces on which the IP source address of an outgoing packet is configured. If no such routes exist, then the outgoing packet will use the longest matching route to the packet's IP destination.

The following example shows how to implement symmetric routing of IP packets on a multihomed host.

# ipadm set-prop -p hostmodel=strong ip
# ipadm show-prop -p hostmodel ip
PROTO  PROPERTY   PERM  CURRENT  PERSISTENT  DEFAULT   POSSIBLE
ipv6   hostmodel  rw    strong   --          weak      strong,
                                                       src-priority,
                                                       weak
ipv4   hostmodel  rw    strong   --          weak      strong,
                                                       src-priority,
                                                       weak

Implementing Traffic Congestion Control

Network congestion typically occurs in the form of router buffer overflows, when nodes send more packets than the network can accommodate. Various algorithms prevent traffic congestion through establishing controls on the sending systems. These algorithms are supported in Oracle Solaris and can be easily added or directly plugged in to the operating system.

The following table lists and describes the supported algorithms.

Congestion control is enabled by setting the following control-related TCP properties. Although these properties are listed for TCP, the control mechanism that is enabled by these properties also applies to SCTP traffic.

• cong_enabled – contains a list of algorithms, separated by commas, that are currently operational in the system. You can add or remove algorithms to enable only those algorithms you want to use. This property can have multiple values. Therefore you must use either the += qualifier or the -= qualifier, depending on the change you want to effect.

• cong_default – the algorithm that is used by default when applications do not specify the algorithms explicitly in socket options. Currently, the value of the cong_default property applies to both global and non-global zones.

To add an algorithm for congestion control to the protocol, issue the following command:

# ipadm set-prop -p cong_enabled+=algorithm tcp

To remove an algorithm, issue the following command:

# ipadm set-prop -p cong_enabled-=algorithm tcp

To replace the default algorithm, issue the following command:

# ipadm set-prop -p cong_default=algorithm tcp

The following example shows steps that you might take to implement congestion control. In the example, the default algorithm for the TCP protocol is changed from newreno to cubic. Then, the vegas algorithm is removed from the list of enabled algorithms.

# ipadm show-prop -p cong_default,cong_enabled tcp
PROTO  PROPERTY      PERM  CURRENT          PERSISTENT   DEFAULT   POSSIBLE
tcp    cong_default  rw    newreno          --           newreno   -
tcp    cong_enabled  rw    newreno,cubic,   --           newreno   newreno,cubic,
                           highspeed,                              highspeed,vegas
                           vegas

# ipadm set-prop -p cong_enabled-=vegas tcp
# ipadm set-prop -p cong_default=cubic tcp

# ipadm show-prop -p cong_default,confg_enabled tcp
PROTO  PROPERTY      PERM  CURRENT          PERSISTENT   DEFAULT   POSSIBLE
tcp    cong_default  rw    cubic            --           newreno   -
tcp    cong_enabled  rw    newreno,cubic,   --           newreno   newreno,cubic,
                           highspeed                               highspeed,vegas

Changing the TCP Receive Buffer Size

The size of the TCP receive buffer is set by using the TCP property recv_buf which, by default, is 128 KB. However, applications do not use available bandwidths uniformly. Thus connection latency might require you to change the default size. For example, using the Secure Shell feature of Oracle Solaris causes overhead on bandwidth use because of the additional checksum and encryption processes that are performed on the data stream. Thus, the buffer size might need to be increased. Likewise, for applications that perform bulk transfer holds to use bandwidth efficiently, the same buffer size adjustment is also required.

You can calculate the correct receive buffer size to use by estimating the bandwidth delay product (BDP) as follows:

BDP = available_bandwidth * connection-latency

Use ping -s host to obtain the value of connection latency. Use the uperf and iperf tools to estimate the use of bandwidth.

The appropriate receive buffer size approximates the value of the BDP. Note, however, that the use of bandwidth also depends on a variety of conditions. A shared infrastructure or the number of applications and users that compete for the use of bandwidth can change that estimate.

To change the value of the buffer size, use the following syntax:

# ipdadm set-prop -p recv_buf=value tcp

The following example shows how to increase the buffer size to 164 KB

# ipadm show-prop -p recv_buf tcp
PROTO PROPERTY   PERM CURRENT   PERSISTENT   DEFAULT  POSSIBLE
tcp   recv_buf   rw   128000       --        128000   2048-1048576

# ipadm set-prop -p recv_buf=164000 tcp

# ipadm show-prop -p recv_buf tcp
PROTO PROPERTY   PERM CURRENT   PERSISTENT   DEFAULT  POSSIBLE
tcp   recv_buf   rw   164000       --        164000   2048-1048576

No set value of the buffer size is preferred because the preferred size varies in different circumstances. Consider the following cases that show different values for the BDP for each network with its own specific conditions:

Typical 1 Gbps LAN where 128 KB is the default value of the buffer size:

BDP = 128 MBps * 0.001 s = 128 kB

Theoretical 1Gbps WAN with 100 ms latency:

BDP = 128 MBps * 0.1 s = 12.8 MB

Europe-to-U.S. link (bandwidth measured by uperf)

BDP = 2.6 MBps * 0.175 = 470 kB

If you cannot compute the BDP, use the following observations as guidelines:

• For bulk transfers over a LAN, the default value of the buffer size, 128 KB, is sufficient.

• For most WAN deployments, the receive buffer size should be in the 2 MB range.

---

Caution - Increasing the TCP receive buffer size increases the memory footprint of many network applications.

---