📄 tyt13fi.htm
字号:
<HTML><HEAD><TITLE>tyt13fi.htm</TITLE><LINK REL=ToC HREF=index-1.htm><LINK REL=Index HREF=tppmsgs/msgs0.htm#37><LINK REL=Next HREF=tyt14fi.htm><LINK REL=Previous HREF=tyt12fi.htm></HEAD><BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#0000FF VLINK=#800080><A ID=I0 NAME=I0></A><P><P ALIGN=CENTER><A HREF=tyt12fi.htm TARGET=_self><IMG SRC=blanprev.gif WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="Previous Page"></A><A HREF=index-1.htm TARGET=_self><IMG SRC=blantoc.gif WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT=TOC></A><A HREF=tyt14fi.htm TARGET=_self><IMG SRC=blannext.gif WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="Next Page"></A><HR ALIGN=CENTER><P><UL><UL><UL><LI><A HREF=#E68E117>Network Management Standards</A></LI><LI><A HREF=#E68E118>What Is SNMP?</A></LI><UL><LI><A HREF=#E69E170>Management Information Base (MIB)</A></LI><LI><A HREF=#E69E171>Simple Network Management Protocol</A></LI><LI><A HREF=#E69E172>Setting Up SNMP Under UNIX</A></LI><LI><A HREF=#E69E173>SNMP Commands</A></LI></UL><LI><A HREF=#E68E119>Network Topologies</A></LI><LI><A HREF=#E68E120>Configuring a Network</A></LI><LI><A HREF=#E68E121>Monitoring and Basic Troubleshooting Utilities</A></LI><UL><LI><A HREF=#E69E174>Troubleshooting the Network Interface</A></LI><LI><A HREF=#E69E175>Troubleshooting the Network (IP) Layer</A></LI><LI><A HREF=#E69E176>Troubleshooting TCP and UDP</A></LI><LI><A HREF=#E69E177>Troubleshooting the Application Layer</A></LI></UL><LI><A HREF=#E68E122>Security</A></LI><LI><A HREF=#E68E123>Summary</A></LI><LI><A HREF=#E68E124>Q&A</A></LI><LI><A HREF=#E68E125>Quiz</A></LI></UL></UL></UL><HR ALIGN=CENTER><A ID=E66E13 NAME=E66E13></A><H1 ALIGN=CENTER><CENTER><FONT SIZE=6 COLOR=#FF0000><B>— 13 —</B><BR><B>Managing and Troubleshooting TCP/IP</B></FONT></CENTER></H1><BR><P>Today you will not learn how to configure and manage a network. The reason is simple: network management and configuration is a very complex issue that can be only briefly examined in a single chapter. If you are assigned the task of network administrator, there are a few good books available that help a little, but the only real teacher of network administration and troubleshooting is experience. The more you work with networks, the more you learn. Today's text presents an overview of network topologies and configuration issues and examines the basic steps in troubleshooting faulty TCP/IP systems. Remember that this is an overview only, intended to provide you with the background to the administration process.<BR><P>Traditionally, network management means two different tasks: monitoring and controlling the network. <I>Monitoring </I>means watching the network's behavior to ensure that it is functioning smoothly and watching for potential troublespots. <I>Controlling </I>means changing the network while it is running, altering the configuration in some manner to improve performance or affect parts that are not functioning correctly.<BR><P>On Day 1, "Open Systems, Standards, and Protocols," I looked at the ISO standards; ISO addresses networks, as well. ISO goes further than just two aspects of network administration, however, dividing network management into five parts defined within the Open Systems Interconnection Reference Model (OSI-RM). These five parts are called Specific Management Functional Areas (SMFAs) in the standard. The five aspects are as follows:<BR><UL><LI><B>Accounting management:</B> Providing information on costs and account usage.<BR></LI><BR><LI><B>Configuration management:</B> Managing the actual configuration of the network.<BR></LI><BR><LI><B>Fault management:</B> Detecting, isolating, and correcting faults, including maintaining error logs and diagnostics.<BR></LI><BR><LI><B>Performance management:</B> Maintaining maximum efficiency and performance, including gathering statistics and maintaining logs.<BR></LI><BR><LI><B>Security management:</B> Maintaining a secure system and managing access.<BR></LI><BR></UL><P>The five groups have some overlap, especially between performance and fault management. However, the division of the network management tasks can help account for all the necessary aspects. In some cases, large organizations have dedicated people for each group. For many smaller LANs, the role of handling all the problems usually falls to one person, who seldom worries about whether their actions are ISO-compliant.<BR><BR><A ID=E68E117 NAME=E68E117></A><H3 ALIGN=CENTER><CENTER><FONT SIZE=5 COLOR=#FF0000><B>Network Management Standards</B></FONT></CENTER></H3><BR><P>The Internet Advisory Board (IAB) has developed or adopted several standards for network management. These have been, for the most part, specifically designed to fit TCP/IP requirements, although they do whenever possible meet the OSI architecture. An Internet working group responsible for the network management standards adopted a two-stage approach to provide for current and future needs.<BR><P>The first step involves the use of the Simple Network Management Protocol (SNMP), which was designed and implemented by the working group. SNMP is currently used on many Internet networks, and it is integrated into many commercially available products. As technology has improved, SNMP has evolved and become more encompassing.<BR><P>The second step involves OSI network management standards, called the Common Management Information Services (CMIS) and Common Management Information Protocol (CMIP), both to be used in future implementations of TCP/IP. The IAB has published <I>Common Management Information Services and </I><I>Protocol over TCP/IP</I> (<I>CMOT</I>) as a standard for TCP/IP and OSI management.<BR><P>Both SNMP and CMOT use the concept of network managers exchanging information with processes within network devices such as workstations, bridges, routers, and multiplexers. The primary management station communicates with the different management processes, building information about the status of the network. The architecture of both SNMP and CMOT is such that the information that is collected is stored in a manner that enables other protocols to read it.<BR><P>The SNMP manager handles the overall software and communications between the devices using the SNMP communications protocol. Support software provides a user interface, enabling a network manager to observe the condition of the overall system and individual components and monitor any specific network device.<BR><P>SNMP-managed devices all contain the SNMP agent software and a database called the Management Information Base (MIB). I look at the SNMP protocol and MIB layout later today, but for now a quick overview should help you understand how SNMP is used for network management. The MIB has 126 fields of information about the device status, performance of the device, its connections to different devices, and its configuration. The SNMP manager queries the MIB through the agent software and can specify changes to the configuration. Most SNMP managers query agents at a regular interval, such as fifteen minutes, unless instructed otherwise by the user.<BR><P>The SNMP agent software is usually quite small (typically less than 64KB) because the SNMP protocol is simple. SNMP is designed to be a polling protocol, meaning that the manager issues messages to the agent. For efficiency and small size of executable programs, SNMP messages are enclosed within a UDP datagram and routed via IP (although many other protocols could be used). There are five message types available in SNMP:<BR><UL><LI><B>Get request:</B> Used to query an MIB.<BR></LI><BR><LI><B>Get next request:</B> Used to read sequentially through an MIB.<BR></LI><BR><LI><B>Get response:</B> Used for a response to a get request message.<BR></LI><BR><LI><B>Set request:</B> Used to set a value in the MIB.<BR></LI><BR><LI><B>Trap:</B> Used to report events.<BR></LI><BR></UL><P>UDP port 161 is used for all messages except traps, which arrive on UDP port 162. Agents receive their messages from the manager through the agent's UDP port 161.<BR><P>Despite its widespread use, SNMP has some disadvantages. The most important might also be an advantage, depending on your point of view: the reliance on UDP. Because UDP is connectionless, there is no reliability inherent in the message sending. Another problem is that SNMP provides only a simple messaging protocol, so filtering messages cannot be performed. This increases the load on the receiving software. Finally, SNMP uses polling, which consumes a considerable amount of bandwidth. The trade-offs between SNMP and its more recent successor, CMIP, will make decisions regarding a management protocol more difficult in the future.<BR><P>SNMP enables proxy management, which means that a device with an SNMP agent and MIB can communicate with other devices that do not have the full SNMP agent software. This proxy management lets other devices be controlled through a connected machine by placing the device's MIB in the agent's memory. For example, a printer can be controlled through proxy management from a workstation acting as an SNMP agent, which also runs the proxy agent and MIB for the printer.<BR><P>Proxy management can be useful to off-load some devices that are under heavy load. For example, it is common under SNMP to use proxy to handle authentication processes, which can consume considerable resources, by passing this function to a less heavily used machine. Proxy systems can also affect the processing that needs to be performed at a bridge, for example, by having a proxy reformat the datagrams arriving, again to off-load the bridge from that time-consuming task.<BR><P>After providing a quick overview, I can now look at SNMP in more detail. If you are satisfied with the overview, you can skip the next section, because most users never need to know about the make-up and layout of SNMP and MIB. If you want to know what's going on in a network, though, this information is invaluable.<BR><BR><A ID=E68E118 NAME=E68E118></A><H3 ALIGN=CENTER><CENTER><FONT SIZE=5 COLOR=#FF0000><B>What Is SNMP?</B></FONT></CENTER></H3><BR><P>The Simple Network Management Protocol (SNMP) was originally designed to provide a means of handling routers on a network. SNMP, although part of the TCP/IP family of protocols, is not dependent on IP. SNMP was designed to be protocol-independent (so it could run under IPX from Novell's SPX/IPX just as easily, for example), although the majority of SNMP installations use IP on TCP/IP networks.<BR><P>SNMP is not a single protocol but three protocols that together make up a family, all designed to work toward administration goals. The protocols that make up the SNMP family and their roles follow:<BR><UL><LI><B>Management Information Base (MIB):</B> A database containing status information<BR></LI><BR><LI><B>Structure and Identification of Management Information (SMI):</B> A specification that defines the entries in an MIB<BR></LI><BR><LI><B>Simple Network Management Protocol (SNMP):</B> The method of communicating between managed devices and servers<BR></LI><BR></UL><P>Peripherals that have SNMP capabilities built-in run a management agent software package, either loaded as part of a boot cycle or embedded in firmware in the device. These devices with SNMP agents are called by a variety of terms depending on the vendor, but they are known as SNMP-manageable or SNMP-managed devices. SNMP-compliant devices also have the code for SNMP incorporated into their software or firmware. When SNMP exists on a device, it is called a managed device.<BR><P>SNMP-managed devices communicate with SNMP server software located somewhere on the network. The device talks to the server in two ways: polled and interrupt. A polled device has the server communicate with the device, asking for its current condition or statistics. The polling is often done at regular intervals, with the server connecting with all the managed devices on the network. The problem with polling is that information is not always current, and network traffic rises with the number of managed devices and frequency of polling.<BR><P>An interrupt-based SNMP system has the managed device send messages to the server when some conditions warrant. This way, the server knows of any problems immediately (unless the device crashes, in which case notification must be from another device that tried to connect to the crashed device). Interrupt-based devices have their own problems. Primary among the problems is the need to assemble a message to the server, which can require a lot of CPU cycles, all of which are taken away from the device's normal task. This can cause bottlenecks and other problems on that device. If the message to be sent is large, as it is if it contains a lot of statistics, the network can suffer a noticeable degradation while the message is assembled and transmitted.<BR><P>If there is a major failure somewhere on the network, such as a power grid going down and uninterruptible power supplies kicking in, each SNMP-managed device might try to send interrupt-driven messages to the server at the same time to report the problem. This can swamp the network and result in incorrect information at the server.<BR><P>A combination of polling and interruption is often used to get by all these problems. The combination is called trap-directed polling, and it involves the server polling for statistics at intervals or when directed by the system administrator. In addition, each SNMP-managed device can generate an interrupt message when certain conditions occur, but these tend to be more rigorously defined than in a pure interrupt-driven system. For example, if you use interrupt-only SNMP, a router might report load increases every 10 percent. If you use trap-directed polling, you know the load from the regular polling and can instruct the router to send an interrupt only when a significant increase in load is experienced. After receiving an interrupt message with trap-directed polling, the server can further query the device for more details, if necessary.<BR><P>An SNMP server software package can communicate with the SNMP agents and transfer or request several types of information. Usually, the server requests statistics from the agent, including number of packets handled, status of the device, special conditions associated with the device type (such as out-of-paper indications or loss of connection from a modem), and processor load.<BR><P>The server can also send instructions to the agent to modify entries in its database (the Management Information Base). The server can also send threshold or conditions under which the SNMP agent should generate an interrupt message to the server, such as when CPU load reaches 90 percent.<BR><P>Communications between the server and agent occur in a fairly straightforward manner, although they tend to use abstract notation for message contents. For example, the server might send a What is your current load message and receive back a 75% message. The agent never sends data to the server unless an interrupt is generated or a poll request is made. This means that some long-standing problems can exist without the SNMP server knowing about them, simply because a poll wasn't conducted or an interrupt generated.<BR><BR><A ID=E69E170 NAME=E69E170></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Management Information Base (MIB)</B></FONT></CENTER></H4><BR><P>Every SNMP-managed device maintains a database that contains statistics and other data. These databases are called a Management Information Base, or MIB. The MIB entries have four pieces of information in them: an object type, a syntax, an access field, and a status field. MIB entries are usually standardized by the protocols and follow strict formatting rules defined by Abstract Syntax Notation One (ASN.1).<BR><P>The object type is the name of the particular entry, usually as a simple name. The syntax is the value type, such as a string or integer. Not all entries in an MIB have a value. The access field is used to define the level of access to the entry, normally defined by the values read-only, read-write, write-only, and not accessible. The status field contains an indication of whether the entry in the MIB is mandatory (which means the managed device must implement the entry), optional (the managed device can implement the entry), or obsolete (not used).<BR><P>There are two types of MIB in use, called MIB-1 and MIB-2. The structures are different. MIB-1 was used starting in 1988 and has 114 entries in the table, divided into groups. For a managed device to claim to be MIB-1 compatible, it must handle all the groups that are applicable to it. For example, a managed printer doesn't have to implement all the entries that deal with the Exterior Gateway Protocol (EGP), which is usually implemented only by routers and similar devices.<BR><P>MIB-2 is a 1990 enhancement of MIB-1, made up of 171 entries in ten groups. The additions expand on some of the basic group entries in MIB-1 and add three new groups. As with MIB-1, an SNMP device that claims to be MIB-2 compliant must implement all those groups that are applicable to that type of device. You will find many devices that are MIB-1 compliant but not MIB-2.<BR><P>In addition to MIB-1 and MIB-2, several experimental MIBs in use add different groups and entries to the database. None of these have been widely adopted, although some show promise. Some MIBs have also been developed by individual corporations for their own use, and some vendors offer compatibility with these MIBs. For example, Hewlett-Packard developed an MIB for their own use that some SNMP-managed devices and software server packages support.<BR><BR><A ID=E69E171 NAME=E69E171></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Simple Network Management Protocol</B></FONT></CENTER></H4><BR><P>The Simple Network Management Protocol (SNMP) has been through several iterations. The most commonly used version is called SNMP v1. Usually SNMP is used as an asynchronous client/server application, meaning that either the managed device or the SNMP server software can generate a message to the other and wait for a reply, if one is expected. These are packaged and handled by the network software (such as IP) as any other packet would be. SNMP uses UDP as a message transport protocol. UDP port 161 is used for all messages except traps, which arrive on UDP port 162. Agents receive their messages from the manager through the agent's UDP port 161.<BR><UL><LI>The first major release of SNMP, SNMP v1, was designed for relatively simple operations, relatively easy implementation by device manufacturers, and good portability to operating systems.<BR></LI><BR></UL><P>When a request is sent, some of the fields in the SNMP entry are left blank. These are filled in by the client and returned. This is an efficient method of transferring the question and answer in one block, eliminating complex look-up algorithms to find out what query a received answer applies to.<BR><P>The get command, for example, is sent with the Type and Value fields in the message set to NULL. The client sends back a similar message with these two fields filled in (unless they don't apply, in which case a different error message is returned).<BR><P>SNMP v2 adds some new capabilities to the older SNMP version, the most handy of which for servers is the get-bulk operation. This lets a large number of MIB entries be sent in one message, instead of requiring multiple get-next queries with SNMP v1. In addition, SNMP v2 has much better security than SNMP v1, preventing unwanted intruders from monitoring the state or condition of managed devices. Both encryption and authentication are supported by SNMP v2. SNMP v2 is a more complex protocol and is not as widely used as SNMP v1.<BR><P>Despite its widespread use, SNMP has a few disadvantages. The most important is its reliance on UDP. Because UDP is connectionless, there is no reliability inherent in messaging between server and agent. Another problem is that SNMP provides only a simple messaging protocol, so filtering messages cannot be performed. This increases the load on the receiving software. Finally, SNMP almost always uses polling to some degree, which consumes a considerable amount of bandwidth.<BR><BR><A ID=E69E172 NAME=E69E172></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>Setting Up SNMP Under UNIX</B></FONT></CENTER></H4><BR><P>Although many operating systems support SNMP and enable you to configure its use, SNMP remains a very UNIX-oriented protocol. Chances are, if there's a UNIX box on your network, SNMP is based on the UNIX machine. Other operating systems such as Windows NT support SNMP client and server software—and they are usually very easy to set up and manage— but for this section I bow to the majority and look only at UNIX.<BR><P>Most UNIX versions include both the client and server software as part of the operating system. The client software is executed through the snmpd daemon, which usually runs all the time when SNMP is used on the network. Normally, the snmpd daemon is started automatically when the system boots; it is controlled through the rc startup files. When SNMP starts, the daemon reads several configuration files. On most SNMP agents, the files that snmpd reads are as follows:<BR><UL><UL><P>/etc/inet/snmpd.conf<BR></UL></UL><UL><UL><P>/etc/inet/snmpd.comm<BR></UL></UL><BLOCKQUOTE><BLOCKQUOTE><P>/etc/inet/snmpd.trap<BR></BLOCKQUOTE></BLOCKQUOTE><P>The directories these files are under might be different for each UNIX version, so you should check the filesystem for their proper location.<BR><P>The snmpd.conf file contains four system MIB objects. Most of the time these objects are set during installation, but you might want to verify their contents. A sample snmpd.conf file is shown here:<BR><PRE><FONT COLOR=#000080># @(#)snmpd.conf 6.3 8/21/93 - STREAMware TCP/IP source## Copyrighted as an unpublished work.# Copyright 1987-1993 Lachman Technology, Inc.# All rights reserved.descr=SCO TCP/IP Runtime Release 2.0.0objid=SCO.1.2.0.0contact=Tim Parker tparker@tpci.comlocation=TPCI Int'l HQ, Ottawa</FONT></PRE><P>In many snmpd.conf files you have to fill out the contact and location fields yourself (which define the contact user and physical location of the system), but the descr and objid fields should be left as they are. The variables defined in the snmpd.conf file correspond to MIB variables as shown in Table 13.1.<BR><BR><P ALIGN=CENTER><CENTER><FONT COLOR=#000080><B>Table 13.1. </B><B>snmpd.comf</B><B> and MIB variables.</B></FONT></CENTER><BR><CENTER><TABLE BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 CELLPADDING=3><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>snmpd.comf</I></B><B><I> Variables</I></B></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>MIB Variables</I></B></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>descr<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>sysDescr<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>objid<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>sysObjectID<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>contact<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>sysContact<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>location<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>sysLocation</FONT></TABLE></CENTER><BR><P>The snmpd.comm (community) file is used to provide authentication information and a list of hosts that have access to the local database. Access by a remote machine to the local SNMP data is provided by including the remote machine's name in the snmpd.comm file. A sample snmpd.comm file looks like this:<BR><PRE><FONT COLOR=#000080># @(#)snmpd.comm 6.5 9/9/93 - STREAMware TCP/IP sourceaccnting 0.0.0.0 READr_n_d 147.120.0.1 WRITEpublic 0.0.0.0 READinterop 0.0.0.0 READ</FONT></PRE><P>Each line in the snmpd.comm file has three fields: the community name, the IP address of the remote machine, and the privileges the community has. If the IP address is set to 0.0.0.0, any machine can communicate with that community name. The privileges can be READ for read-only, WRITE for read and write, and NONE to prevent access by that community. Read and write access are references to capabilities to change MIB data, not filesystems.<BR><P>The snmpd.trap file specifies the name of hosts to whom a trap message must be sent when a critical event is noticed. A sample snmpd.trap file looks like this:<BR><PRE><FONT COLOR=#000080># @(#)snmpd.trap 6.4 9/9/93 - STREAMware TCP/IP sourcesuperduck 147.120.0.23 162</FONT></PRE><P>Each line in the snmpd.trap file has three fields: the name of the community, its IP address, and the UDP port to use to send traps.<BR><BR><A ID=E69E173 NAME=E69E173></A><H4 ALIGN=CENTER><CENTER><FONT SIZE=4 COLOR=#FF0000><B>SNMP Commands</B></FONT></CENTER></H4><BR><P>UNIX offers several SNMP-based commands for network administrators to obtain information from an MIB or an SNMP-compliant device. The exact commands vary a little depending on the implementation, but most SNMP systems support the commands shown in Table 13.2.<BR><BR><P ALIGN=CENTER><CENTER><FONT COLOR=#000080><B>Table 13.2. SNMP commands.</B></FONT></CENTER><BR><CENTER><TABLE BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 CELLPADDING=3><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Command</I></B></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P><B><I>Description</I></B></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>getone<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Uses the SNMP get command to retrieve a variable value<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>getnext<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Uses the SNMP getnext command to retrieve the next variable value<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>getid<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Retrieves the values for sysDescr, sysObjectID, and sysUpTime<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>getmany<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Retrieves an entire group of MIB variables<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>snmpstat<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Retrieves the contents of SNMP data structures<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>getroute<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Retrieves routing information<BR></FONT><TR><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>setany<BR></FONT><TD BGCOLOR=#80FFFF><FONT COLOR=#000080><P>Uses the SNMP set command to set a variable value</FONT></TABLE></CENTER><BR><P>Most of the SNMP commands require an argument that specifies the information to be set or retrieved. The output from some of the commands given in Table 13.2 is shown in the following extract from an SNMP machine on a small local area network:<BR><PRE><FONT COLOR=#000080>$ getone merlin udpInDatagrams.0Name: udpInDatagrams.0Value: 6$ getid merlin publicName: sysDescr.0Value: UNIX System V Release 4.3⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -