15.11 Modifying Network Parameters with ndd Occasionally, we need to modify a network kernel parameter. When we mention kernel parameters, we think of the /stand/system file and commands like kmtune and mk_kernel . The parameters we are discussing here are not configured via those methods . The networking- related parameters we are discussing here will affect how various networking software components function as well as how they will react in certain situations (e.g., will IP packets be forwarded onto a distant network). The networking parameters we are discussing here are configured by the command ndd . In the dim and distant past, we would have to use adb to hack the kernel to change network-related parameters. In HP-UX 10.X, we had a command nettune . In HP-UX 11.X, we have the command ndd . We can run this command with the networking software up and running but beware, changes made will be immediate. This command can fundamentally change the behavior of our networking, as we will see shortly. There are no hard and fast rules as to when to change these network parameters. In fact, HP will suggest you do not change any of them unless you: -
Know, understand, and accept the consequences of your actions. -
Need to change a parameter for a specific purpose, e.g., security. -
Are directed to change a parameter by HP or a trusted third-party supplier. What we will look at are only a few of these parameters and how to effect a change that survives a reboot of the system. 15.11.1 Obtaining a list of network-related parameters Obtaining the list of network-related kernel parameters is relatively straightforward; we use the ndd “h command:
root@hpeos004[] ndd h SUPPORTED ndd tunable parameters on HP-UX: IP: ip_def_ttl - Controls the default TTL in the IP header ip_enable_udp_bcastrecv - Controls receiving of broadcast packets by UDP sockets ip_check_subnet_addr - Controls the subnet portion of a host address ip_forward_directed_broadcasts - Controls subnet broadcasts packets ip_forward_src_routed - Controls forwarding of source routed packets ip_forwarding - Controls how IP hosts forward packets ip_fragment_timeout - Controls how long IP fragments are kept ip_ire_gw_probe - Enable dead gateway probes ip_icmp_return_data_bytes - Maximum number of data bytes in ICMP ip_ill_status - Displays a report of all physical interfaces ip_ipif_status - Displays a report of all logical interfaces ip_ire_hash - Displays all routing table entries, in the order searched when resolving an address ip_ire_status - Displays all routing table entries ip_ire_cleanup_interval - Timeout interval for purging routing entries ip_ire_flush_interval - Routing entries deleted after this interval ip_ire_gw_probe_interval - Probe interval for Dead Gateway Detection ip_ire_pathmtu_interval - Controls the probe interval for PMTU ip_ire_redirect_interval - Controls 'Redirect' routing table entries ip_max_bcast_ttl - Controls the TTL for broadcast packets ip_pmtu_strategy - Controls the Path MTU Discovery strategy ip_reass_mem_limit - Maximum number of bytes for IP reassembly ip_send_redirects - Sends ICMP 'Redirect' packets ip_send_source_quench - Sends ICMP 'Source Quench' packets ip_strong_es_model - Controls support for 'Strong End-System Model' ip_udp_status - Reports IP level UDP fanout table TCP: tcp_conn_request_max - Max number of outstanding connection requests tcp_cwnd_initial - Initial size of the congestion window as a ... UDP: udp_debug - Enable UDP debug information logging udp_def_ttl - Default TTL inserted into IP header ... RAWIP: rawip_def_ttl - Default TTL inserted into IP header rawip_recv_hiwater_max - The maximum size of the RAWIP receive buffer ARP: arp_cache_report - Displays the ARP cache arp_cleanup_interval - Controls how long ARP entries stay in the ... IPSEC: ip_ipsec_integer_pads - Sets the type of pads used for block ciphers ip_ipsec_policy_interval - Sets the interval between attempts to remove unused Security Policy rules. ... SOCKET: socket_buf_max - Sets maximum socket buffer size for AF_UNIX sockets. socket_caching_tcp - Controls socket caching for TCP sockets. ... IPV6: ip6_def_hop_limit - Controls the default Hop Limit in the IPv6 header ip6_forwarding - Controls how IPv6 hosts forward packets ... IPV6 Neighbor Discovery (ND): ip6_ire_reachable_interval - Controls the ND REACHABLE_TIME ip6_max_random_factor - Controls the ND MAX_RANDOM_FACTOR ... RAWIP6: rawip6_def_hop_limit - Controls the default Hop Limit in the IPv6 header UNSUPPORTED ndd tunable parameters on HP-UX: This set of parameters are not supported by HP and modification of these tunable parameters are not suggested nor recommended. IP: ip_bogus_sap - Allow IP bind to a nonstandard/unused SAP ip_debug - Controls the level of IP module debugging ...
I have significantly shortened the output for two reasons: first, it ran to seven pages and I think that was a little bit too much and. second, as updates to the networking subsystem come along, there may be new kernel parameters that we can tune with ndd . Notice that there are supported and unsupported parameters. If you want to concern yourself only with the supported parameters, then use the command ndd “h supported . You can also get brief help on individual parameters themselves :
root@hpeos004[] ndd -h ip_forwarding ip_forwarding: Controls how IP hosts forward packets: Set to 0 to inhibit forwarding; set to 1 to always forward; set to 2 to forward only if the number of logical interfaces on the system is 2 or more. [0,2] Default: 2 root@hpeos004[]
15.11.2 Changing a network parameter with ndd The changes we are about to make will take effect immediately. In some cases, changing a parameter will have a profound effect on the way your network operates. Take the ip_forwarding parameter. When set to the default value on a multi- homed machine, that machine will quite happily pass packets between both networks to which it is connected, as you would expect it to. It's a router, and that's what routers do. If such a machine is operating as some form of security firewall, then this default behavior is less than desirable. In such a situation, we will want to disable ip_forwarding now and after every reboot. As it stands at present, both our multi-homed servers have ip_forwarding enabled. Here is an example of what happens when we disable it:
root@hpeos002[] # netstat -rn Routing tables Destination Gateway Flags Refs Interface Pmtu 127.0.0.1 127.0.0.1 UH 0 lo0 4136 192.168.0.34 192.168.0.34 UH 0 lan0 4136 192.168.0.32 192.168.0.34 U 2 lan0 1500 192.168.0.64 192.168.0.33 UG 0 lan0 0 127.0.0.0 127.0.0.1 U 0 lo0 0 root@hpeos002[] # ping hpeos001 64 3 PING hpeos001: 64 byte packets 64 bytes from 192.168.0.67: icmp_seq=0. time=2. ms 64 bytes from 192.168.0.67: icmp_seq=1. time=1. ms 64 bytes from 192.168.0.67: icmp_seq=2. time=1. ms ----hpeos001 PING Statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms) min/avg/max = 1/1/2 root@hpeos002[] # root@hpeos002[] # traceroute hpeos001 traceroute to hpeos001 (192.168.0.67), 30 hops max, 40 byte packets 1 hpeos003 (192.168.0.33) 1.303 ms 0.806 ms 0.748 ms 2 hpeos001 (192.168.0.67) 1.078 ms 1.019 ms 1.271 ms root@hpeos002[] #
Here we can see a client quite happily communicating with other machines on the network via its router 192.168.0.33. Let's now change the ip_forwarding parameter on that gateway:
root@hpeos003[] ndd -get /dev/ip ip_forwarding 2 root@hpeos003[] ndd -set /dev/ip ip_forwarding 0 root@hpeos003[] ndd -get /dev/ip ip_forwarding 0 root@hpeos003[]
This has the immediate effect of disabling the forwarding of packets between network interfaces.
root@hpeos002[] # ping hpeos001 64 3 PING hpeos001: 64 byte packets ----hpeos001 PING Statistics---- 3 packets transmitted, 0 packets received, 100% packet loss root@hpeos002[] #
In order to breach the firewall, we must gain legitimate access to the router. From there, we can communicate with nodes connected to each network. In this way, hpeos003 is acting as a simple firewall protecting the network resources behind it. This is far from being a complete firewall solution, but it demonstrates how changing a single kernel parameter can have a dramatic effect on how our network operates. Here, we can see that once logged in to our mini-firewall, we can access network resources behind it:
oot@hpeos003[] ping hpeos001 64 3 PING hpeos001: 64 byte packets 64 bytes from 192.168.0.67: icmp_seq=0. time=1. ms 64 bytes from 192.168.0.67: icmp_seq=1. time=0. ms 64 bytes from 192.168.0.67: icmp_seq=2. time=0. ms ----hpeos001 PING Statistics---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/1 root@hpeos003[]
15.11.3 Making an ndd change survive a reboot The changes effected by the ndd command are immediate, as we have just seen. However, they are not permanent; a reboot will put the kernel parameter back to its original value. To make a change survive a reboot, we must configure the startup script /etc/rc.config.d/nddconf . Here are some changes I am making. Note: These changes are for demonstration purposes only:
root@hpeos003[] vi /etc/rc.config.d/nddconf ... TRANSPORT_NAME[0]=ip NDD_NAME[0]=ip_forwarding NDD_VALUE[0]=0 TRANSPORT_NAME[1]=ip NDD_NAME[1]=ip_respond_to_echo_broadcast NDD_VALUE[1]=0 TRANSPORT_NAME[2]=ip NDD_NAME[2]=ip_send_source_quench NDD_VALUE[2]=0 TRANSPORT_NAME[3]=tcp NDD_NAME[3]=tcp_fin_wait_2_timeout NDD_VALUE[3]=600000 TRANSPORT_NAME[4]=arp NDD_NAME[4]=arp_cleanup_interval NDD_VALUE[4]=600000
Here's a quick rundown of the changes I have made: ip_forwarding : We have just seen the consequences of that change, so I hope I don't need to explain it again. ip_respond_to_echo_broadcast : When we ping using our broadcast address, we discover all HP-UX nodes on our network. With this parameter disabled, we will not respond to an ICMP echo broadcast. We will still respond to a directed ping , but not a broadcast. This can be useful when we want to remain undiscovered . ip_send_source_quench : When we are receiving data from another node too quickly, we will want to send an ICMP slow do wn message. This is the idea of ip_send_source_quench , to request that the source decrease its transmission rate. In the vast majority of situations, you will want to keep this parameter enabled (=1). tcp_fin_wait_2_timeout : When a socket connect is being stripped down, one end of the connection (usually the client) will send a TCP FIN packet indicating that it has no more data to send. The other end of the connection (the server) will acknowledge this by sending a TCP ACK packet. The socket connection goes into a FIN_WAIT_2 state that you may see when you use the netstat command. At this point, the remote (client) will send a second TCP FIN and the socket will be stripped do wn. However, while in FIN_WAIT_2 , the client can still transmit data if required; the initial FIN is like an intention to close down. Consequently, the socket will remain in FIN_WAIT_2 indefinitely , until the remote (client) sends the final FIN . I have seen a couple of applications where the remote (client) software would abort abnormally and leave FIN_WAIT_2 sockets on the server. There is no way to get rid of them without changing what we call the FIN_WAIT_2 timer: the fin_wait_2_timeout kernel parameter. When we set this to a value (in milliseconds ), the kernel will strip down any FIN_WAIT_2 sockets that remain in FIN_WAIT_2 for a time exceeding the timer. We must be careful when setting this value because we may prematurely strip down a socket connection that is in fact active . I have set this timer to be 600,000 milliseconds = 10 minutes. arp_cleanup_interval : Entries in our ARP cache remain there for up to 5 minutes by default. If we do not communicate with a node within 5 minutes, the entry in the ARP cache is cleaned up. By setting this value higher, we can increase the time an entry remains in the ARP cache and, hence, negate the requirement to repopulate the ARP cache with a MAC - IP address mapping. Setting this to 10 minutes (600,000 milliseconds) will have the effect of increasing the size of kernel tables for longer. This is not necessarily a good thing if the system is running out of memory. Once I have finished setting up the /etc/rc.config.d/nddconf file, I can use the ndd command itself to read the configuration file:
root@hpeos003[] ndd -c root@hpeos003[]
The fact that we did not get an error message means that there were no syntax errors in the configuration file. We should check that the parameters have been set appropriately by using ndd “get . We could also check the functionality of some of the parameters. Here, I will check the functionality of ip_respond_to_echo_broadcast :
root@hpeos003[] netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll lan1 1500 192.168.0.64 192.168.0.65 1280 0 1270 0 0 lan0 1500 192.168.0.32 192.168.0.33 2151 0 1475 0 0 lo0 4136 127.0.0.0 127.0.0.1 1235 0 1235 0 0 root@hpeos003[] ndd -get /dev/ip ip_respond_to_echo_broadcast 0 root@hpeos003[]
Here, we can see the result of our ndd “c ; we have disabled responding to a broadcast ping . On another node, we can check this:
root@hpeos004[] ifconfig lan1 lan1: flags=843<UP,BROADCAST,RUNNING,MULTICAST> inet 192.168.0.66 netmask ffffffe0 broadcast 192.168.0.95 root@hpeos004[] root@hpeos004[] ping 192.168.0.95 PING 192.168.0.95: 64 byte packets 64 bytes from 192.168.0.66: icmp_seq=0. time=0. ms 64 bytes from 192.168.0.67: icmp_seq=0. time=0. ms 64 bytes from 192.168.0.66: icmp_seq=1. time=0. ms 64 bytes from 192.168.0.67: icmp_seq=1. time=0. ms 64 bytes from 192.168.0.66: icmp_seq=2. time=0. ms 64 bytes from 192.168.0.67: icmp_seq=2. time=0. ms 64 bytes from 192.168.0.66: icmp_seq=3. time=0. ms 64 bytes from 192.168.0.67: icmp_seq=3. time=0. ms ^C ----192.168.0.95 PING Statistics---- 4 packets transmitted, 8 packets received, -100% packet loss round-trip (ms) min/avg/max = 0/0/0 root@hpeos004[]
As we can see, we are not getting a response from our original node. Just to be sure, let's reactivate the parameter and ensure that all works as expected:
root@hpeos003[] ndd -set /dev/ip ip_respond_to_echo_broadcast 1 root@hpeos003[] ndd -get /dev/ip ip_respond_to_echo_broadcast 1 root@hpeos003[]
And now we can try the ping again:
root@hpeos004[] ping 192.168.0.95 PING 192.168.0.95: 64 byte packets 64 bytes from 192.168.0.66: icmp_seq=0. time=0. ms 64 bytes from 192.168.0.67: icmp_seq=0. time=0. ms 64 bytes from 192.168.0.65: icmp_seq=0. time=0. ms 64 bytes from 192.168.0.66: icmp_seq=1. time=0. ms 64 bytes from 192.168.0.65: icmp_seq=1. time=0. ms 64 bytes from 192.168.0.67: icmp_seq=1. time=0. ms 64 bytes from 192.168.0.66: icmp_seq=2. time=0. ms 64 bytes from 192.168.0.65: icmp_seq=2. time=0. ms 64 bytes from 192.168.0.67: icmp_seq=2. time=0. ms ^C ----192.168.0.95 PING Statistics---- 3 packets transmitted, 9 packets received, -200% packet loss round-trip (ms) min/avg/max = 0/0/0 root@hpeos004[]
Our original node is now responding to the broadcast ping . Let's de-activate it as intended:
root@hpeos003[] ndd -set /dev/ip ip_respond_to_echo_broadcast 0 root@hpeos003[] ndd -get /dev/ip ip_respond_to_echo_broadcast 0 root@hpeos003[]
IMPORTANT I cannot reiterate enough the necessity to understand, appreciate, and accept that the changes you make with ndd can have a dramatic effect on how your machine responds in your networks. Change only the parameters that you fully understand or have been directed to change by HP or a trusted third-party supplier. |
| 