rfc5997.Use of Status-Server Packets in the radius
Internet Engineering Task Force (IETF) A. DeKok Request for Comments: 5997 FreeRADIUS Updates: 2866 August 2010 Category: Informational
ISSN: 2070-1721
Use of Status-Server Packets in the
Remote Authentication Dial In User Service (RADIUS) Protocol Abstract
This document describes a deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, enabling
clients to query the status of a RADIUS server. This extension
utilizes the Status-Server (12) Code, which was reserved for
experimental use in RFC 2865.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.wendangku.net/doc/375778419.html,/info/rfc5997.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust’s Legal
Provisions Relating to IETF Documents
(https://www.wendangku.net/doc/375778419.html,/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
DeKok Informational [Page 1]
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other than English.
Table of Contents
1. Introduction (3)
1.1. Applicability (3)
1.2. Terminology (4)
1.3. Requirements Language (4)
2. Overview (4)
2.1. Why Access-Request is Inappropriate (6)
2.1.1. Recommendation against Access-Request (7)
2.2. Why Accounting-Request is Inappropriate (7)
2.2.1. Recommendation against Accounting-Request (7)
3. Packet Format (8)
3.1. Single Definition for Status-Server (10)
4. Implementation Notes (10)
4.1. Client Requirements (11)
4.2. Server Requirements (12)
4.3. Failover with Status-Server (14)
4.4. Proxy Server Handling of Status-Server (14)
4.5. Limitations of Status-Server (15)
4.6. Management Information Base (MIB) Considerations (17)
4.6.1. Interaction with RADIUS Server MIB Modules (17)
4.6.2. Interaction with RADIUS Client MIB Modules (17)
5. Table of Attributes (18)
6. Examples (19)
6.1. Minimal Query to Authentication Port (19)
6.2. Minimal Query to Accounting Port (20)
6.3. Verbose Query and Response (21)
7. Security Considerations (21)
8. References (23)
8.1. Normative References (23)
8.2. Informative References (23)
Acknowledgments (24)
DeKok Informational [Page 2]
1. Introduction
This document specifies a deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, enabling
clients to query the status of a RADIUS server. While the Status-
Server (12) Code was defined as experimental in [RFC2865], Section 3, details of the operation and potential uses of the Code were not
provided.
As with the core RADIUS protocol, the Status-Server extension is
stateless, and queries do not otherwise affect the normal operation
of a server, nor do they result in any side effects, other than
perhaps incrementing an internal packet counter. Most of the
implementations of this extension have utilized it alongside
implementations of RADIUS as defined in [RFC2865], so that this
document focuses solely on the use of this extension with UDP
transport.
The rest of this document is laid out as follows. Section 2 contains the problem statement, and explanations as to why some possible
solutions can have unwanted side effects. Section 3 defines the
Status-Server packet format. Section 4 contains client and server
requirements, along with some implementation notes. Section 5
contains a RADIUS table of attributes. The remaining text discusses security considerations not covered elsewhere in the document.
1.1. Applicability
This protocol is being recommended for publication as an
Informational RFC rather than as a Standards-Track RFC because of
problems with deployed implementations. This includes security
vulnerabilities. The fixes recommended here are compatible with
existing servers that receive Status-Server packets, but impose new
security requirements on clients that send Status-Server packets.
Some existing implementations of this protocol do not support the
Message-Authenticator attribute ([RFC3579]). This enables an
unauthorized client to spoof Status-Server packets, potentially
leading to incorrect Access-Accepts. In order to remedy this
problem, this specification requires the use of the Message-
Authenticator attribute to provide per-packet authentication and
integrity protection.
With existing implementations of this protocol, the potential exists for Status-Server requests to be in conflict with Access-Request or
Accounting-Request packets using the same Identifier. This
specification recommends techniques to avoid this problem.
DeKok Informational [Page 3]
These limitations are discussed in more detail below.
1.2. Terminology
This document uses the following terms:
"Network Access Server (NAS)"
The device providing access to the network. Also known as the
Authenticator (in IEEE 802.1X terminology) or RADIUS client.
"RADIUS Proxy"
In order to provide for the routing of RADIUS authentication and
accounting requests, a RADIUS proxy can be employed. To the NAS, the RADIUS proxy appears to act as a RADIUS server, and to the
RADIUS server, the proxy appears to act as a RADIUS client.
"silently discard"
This means the implementation discards the packet without further processing. The implementation MAY provide the capability of
logging the error, including the contents of the silently
discarded packet, and SHOULD record the event in a statistics
counter.
1.3. Requirements Language
In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
2. Overview
Status-Server packets are sent by a RADIUS client to a RADIUS server in order to test the status of that server. The destination of a
Status-Server packet is set to the IP address and port of the server that is being tested. A single Status-Server packet MUST be included within a UDP datagram. A Message-Authenticator attribute MUST be
included so as to provide per-packet authentication and integrity
protection.
RADIUS proxies or servers MUST NOT forward Status-Server packets. A RADIUS server or proxy implementing this specification SHOULD respond to a Status-Server packet with an Access-Accept (authentication port) or Accounting-Response (accounting port). An Access-Challenge
DeKok Informational [Page 4]
response is NOT RECOMMENDED. An Access-Reject response MAY be used. The list of attributes that are permitted in Status-Server packets,
and in Access-Accept or Accounting-Response packets responding to
Status-Server packets, is provided in Section 5. Section 6 provides several examples.
Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy or server, the client is provided with an indication of the status of that server only, since no RADIUS proxies are on the path between the RADIUS client and server. As servers respond to a Status-Server
packet without examining the User-Name attribute, the response to a
Status-Server packet cannot be used to infer any information about
the reachability of specific realms.
The "hop-by-hop" functionality of Status-Server packets is useful to RADIUS clients attempting to determine the status of the first
element on the path between the client and a server. Since the
Status-Server packet is non-forwardable, the lack of a response may
only be due to packet loss or the failure of the server at the
destination IP address, and not due to faults in downstream links,
proxies, or servers. It therefore provides an unambiguous indication of the status of a server.
This information may be useful in situations in which the RADIUS
client does not receive a response to an Access-Request. A client
may have multiple proxies configured, with one proxy marked as
primary and another marked as secondary. If the client does not
receive a response to a request sent to the primary proxy, it can
"failover" to the secondary, and send requests to the secondary proxy instead.
However, it is possible that the lack of a response to requests sent to the primary proxy was due not to a failure within the primary, but to alternative causes such as a failed link along the path to the
destination server or the failure of the destination server itself.
In such a situation, it may be useful for the client to be able to
distinguish between failure causes so that it does not trigger
failover inappropriately. For example, if the primary proxy is down, then a quick failover to the secondary proxy would be prudent;
whereas, if a downstream failure is the cause, then the value of
failover to a secondary proxy will depend on whether packets
forwarded by the secondary will utilize independent links,
intermediaries, or destination servers.
DeKok Informational [Page 5]
The Status-Server packet is not a "Keep-Alive" as discussed in
[RFC2865], Section 2.6. "Keep-Alives" are Access-Request packets
sent to determine whether a downstream server is responsive. These
packets are typically sent only when a server is suspected to be
down, and they are no longer sent as soon as the server is available again.
2.1. Why Access-Request is Inappropriate
One possible solution to the problem of querying server status is for a NAS to send specially formed Access-Request packets to a RADIUS
server’s authentication port. The NAS can then look for a response
and use this information to determine if the server is active or
unresponsive.
However, the server may see the request as a normal login request for a user and conclude that a real user has logged onto that NAS. The
server may then perform actions that are undesirable for a simple
status query. The server may alternatively respond with an Access-
Challenge, indicating that it believes an extended authentication
conversation is necessary.
Another possibility is that the server responds with an Access-
Reject, indicating that the user is not authorized to gain access to the network. As above, the server may also perform local-site
actions, such as warning an administrator of failed login attempts.
The server may also delay the Access-Reject response, in the
traditional manner of rate-limiting failed authentication attempts.
This delay in response means that the querying administrator is
unsure as to whether or not the server is down, slow to respond, or
intentionally delaying its response to the query.
In addition, using Access-Request queries may mean that the server
may have local users configured whose sole reason for existence is to enable these query requests. Unless the server policy is designed
carefully, it may be possible for an attacker to use those
credentials to gain unauthorized network access.
We note that some NAS implementations currently use Access-Request
packets as described above, with a fixed (and non-configurable) user name and password. Implementation issues with that equipment mean
that if a RADIUS server does not respond to those queries, it may be marked as unresponsive by the NAS. This marking may happen even if
the server is actively responding to other Access-Requests from that same NAS. This behavior is confusing to administrators who then need to determine why an active server has been marked as "unresponsive". DeKok Informational [Page 6]
2.1.1. Recommendation against Access-Request
For the reasons outlined above, NAS implementors SHOULD NOT generate Access-Request packets solely to see if a server is alive.
Similarly, site administrators SHOULD NOT configure test users whose sole reason for existence is to enable such queries via Access-
Request packets.
Note that it still may be useful to configure test users for the
purpose of performing end-to-end or in-depth testing of a server
policy. While this practice is widespread, we caution administrators to use it with care.
2.2. Why Accounting-Request is Inappropriate
A similar solution for the problem of querying server status may be
for a NAS to send specially formed Accounting-Request packets to a
RADIUS server’s accounting port. The NAS can then look for a
response and use this information to determine if the server is
active or unresponsive.
As seen above with Access-Request, the server may then conclude that a real user has logged onto a NAS, and perform local-site actions
that are undesirable for a simple status query.
Another consideration is that some attributes are mandatory to
include in an Accounting-Request. This requirement forces the
administrator to query an accounting server with fake values for
those attributes in a test packet. These fake values increase the
work required to perform a simple query, and they may pollute the
server’s accounting database with incorrect data.
2.2.1. Recommendation against Accounting-Request
For the reasons outlined above, NAS implementors SHOULD NOT generate Accounting-Request packets solely to see if a server is alive.
Similarly, site administrators SHOULD NOT configure accounting
policies whose sole reason for existence is to enable such queries
via Accounting-Request packets.
Note that it still may be useful to configure test users for the
purpose of performing end-to-end or in-depth testing of a server’s
policy. While this practice is widespread, we caution administrators to use it with care.
DeKok Informational [Page 7]
3. Packet Format
Status-Server packets reuse the RADIUS packet format, with the fields and values for those fields as defined in [RFC2865], Section 3. We
do not include all of the text or diagrams of that section here, but instead explain the differences required to implement Status-Server. The Authenticator field of Status-Server packets MUST be generated
using the same method as that used for the Request Authenticator
field of Access-Request packets, as given below.
The role of the Identifier field is the same for Status-Server as for other packets. However, as Status-Server is taking the role of
Access-Request or Accounting-Request packets, there is the potential for Status-Server requests to be in conflict with Access-Request or
Accounting-Request packets with the same Identifier. In Section 4.2 below, we describe a method for avoiding these problems. This method MUST be used to avoid conflicts between Status-Server and other
packet types.
Request Authenticator
In Status-Server packets, the Authenticator value is a 16-octet random number called the Request Authenticator. The value
SHOULD be unpredictable and unique over the lifetime of a
secret (the password shared between the client and the RADIUS
server), since repetition of a request value in conjunction
with the same secret would permit an attacker to reply with a
previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in
disparate geographic regions, the Request Authenticator field
SHOULD exhibit global and temporal uniqueness. See [RFC4086]
for suggestions as to how random numbers may be generated.
The Request Authenticator value in a Status-Server packet
SHOULD also be unpredictable, lest an attacker trick a server
into responding to a predicted future request, and then use the response to masquerade as that server to a future Status-Server request from a client.
Similarly, the Response Authenticator field of an Access-Accept
packet sent in response to Status-Server queries MUST be generated
using the same method as used for calculating the Response
Authenticator of the Access-Accept sent in response to an Access-
Request, with the Status-Server Request Authenticator taking the
place of the Access-Request Request Authenticator.
DeKok Informational [Page 8]
The Response Authenticator field of an Accounting-Response packet
sent in response to Status-Server queries MUST be generated using the same method as used for calculating the Response Authenticator of the Accounting-Response sent in response to an Accounting-Request, with
the Status-Server Request Authenticator taking the place of the
Accounting-Request Request Authenticator.
Note that when a server responds to a Status-Server request, it MUST NOT send more than one Response packet.
Response Authenticator
The value of the Authenticator field in Access-Accept or
Accounting-Response packets is called the Response
Authenticator, and contains a one-way MD5 hash calculated over a stream of octets consisting of: the RADIUS packet, beginning with the Code field, including the Identifier, the Length, the Request Authenticator field from the Status-Server packet, and the response Attributes (if any), followed by the shared
secret. That is,
ResponseAuth =
MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
where + denotes concatenation.
In addition to the above requirements, all Status-Server packets MUST include a Message-Authenticator attribute. Failure to do so would
mean that the packets could be trivially spoofed.
Status-Server packets MAY include NAS-Identifier, and one of
NAS-IP-Address or NAS-IPv6-Address. These attributes are not
necessary for the operation of Status-Server, but may be useful
information to a server that receives those packets.
Other attributes SHOULD NOT be included in a Status-Server packet,
and MUST be ignored if they are included. User authentication
credentials such as User-Name, User-Password, CHAP-Password,
EAP-Message MUST NOT appear in a Status-Server packet sent to a
RADIUS authentication port. User or NAS accounting attributes such
as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets MUST NOT
appear in a Status-Server packet sent to a RADIUS accounting port.
The Access-Accept MAY contain a Reply-Message or Message-
Authenticator attribute. It SHOULD NOT contain other attributes.
The Accounting-Response packets sent in response to a Status-Server
query SHOULD NOT contain any attributes. As the intent is to
DeKok Informational [Page 9]
implement a simple query instead of user authentication or
accounting, there is little reason to include other attributes in
either the query or the corresponding response.
Examples of Status-Server packet flows are given below in Section 6.
3.1. Single Definition for Status-Server
When sent to a RADIUS accounting port, the contents of the Status-
Server packets are calculated as described above. That is, even
though the packets are being sent to an accounting port, they are not created using the same method as is used for Accounting-Requests.
This difference has a number of benefits.
Having a single definition for Status-Server packets is simpler than having different definitions for different destination ports. In
addition, if we were to define Status-Server as being similar to
Accounting-Request but containing no attributes, then those packets
could be trivially forged.
We therefore define Status-Server consistently, and vary the response packets depending on the port to which the request is sent. When
sent to an authentication port, the response to a Status-Server query is an Access-Accept packet. When sent to an accounting port, the
response to a Status-Server query is an Accounting-Response packet. 4. Implementation Notes
There are a number of considerations to take into account when
implementing support for Status-Server. This section describes
implementation details and requirements for RADIUS clients and
servers that support Status-Server.
The following text applies to the authentication and accounting
ports. We use the generic terms below to simplify the discussion:
* Request packet
An Access-Request packet sent to an authentication port or an
Accounting-Request packet sent to an accounting port.
* Response packet
An Access-Accept, Access-Challenge, or Access-Reject packet
sent from an authentication port or an Accounting-Response
packet sent from an accounting port.
DeKok Informational [Page 10]
We also refer to "client" as the originator of the Status-Server
packet, and "server" as the receiver of that packet and the
originator of the Response packet.
Using generic terms to describe the Status-Server conversations is
simpler than duplicating the text for authentication and accounting
packets.
4.1. Client Requirements
Clients SHOULD permit administrators to globally enable or disable
the generation of Status-Server packets. The default SHOULD be that it is disabled. As it is undesirable to send queries to servers that do not support Status-Server, clients SHOULD also have a per-server
configuration indicating whether or not to enable Status-Server for a particular destination. The default SHOULD be that it is disabled.
The client SHOULD use a watchdog timer, such as is defined in Section 2.2.1 of [RFC5080], to determine when to send Status-Server packets. When Status-Server packets are sent from a client, they MUST NOT be
retransmitted. Instead, the Identity field MUST be changed every
time a packet is transmitted. The old packet should be discarded,
and a new Status-Server packet should be generated and sent, with new Identity and Authenticator fields.
Clients MUST include the Message-Authenticator attribute in all
Status-Server packets. Failure to do so would mean that the packets could be trivially spoofed, leading to potential denial-of-service
(DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server packet, except as outlined below in Section 5. As the intent of the packet is a simple status query, there is little reason for any
additional attributes to appear in Status-Server packets.
The client MAY increment packet counters as a result of sending a
Status-Server request or of receiving a Response packet. The client MUST NOT perform any other action that is normally performed when it receives a Response packet, such as permitting a user to have login
access to a port.
Clients MAY send Status-Server requests to the RADIUS destination
ports from the same source port used to send normal Request packets. Other clients MAY choose to send Status-Server requests from a unique source port that is not used to send Request packets.
The above suggestion for a unique source port for Status-Server
packets aids in matching responses to requests. Since the response
to a Status-Server packet is an Access-Accept or Accounting-Response DeKok Informational [Page 11]
packet, those responses are indistinguishable from other packets sent in response to a Request packet. Therefore, the best way to
distinguish them from other traffic is to have a unique port.
A client MAY send a Status-Server packet from a source port also used to send Request packets. In that case, the Identifier field MUST be unique across all outstanding Request packets for that source port,
independent of the value of the RADIUS Code field for those
outstanding requests. Once the client has either received a response to the Status-Server packet or determined that the Status-Server
packet has timed out, it may reuse that Identifier in another packet. Robust implementations SHOULD accept any Response packet as a valid
response to a Status-Server packet, subject to the validation
requirements defined above for the Response Authenticator. The Code field of the packet matters less than the fact that a valid, signed
response has been received.
That is, prior to accepting the response as valid, the client should check that the Response packet Code field is either Access-Accept (2) or Accounting-Response (5). If the Code does not match any of these values, the packet MUST be silently discarded. The client MUST then validate the Response Authenticator via the algorithm given above in Section 3. If the Response Authenticator is not valid, the packet
MUST be silently discarded. If the Response Authenticator is valid, then the packet MUST be deemed to be a valid response from the
server.
If the client instead discarded the response because the packet Code did not match what it expected, then it could erroneously discard
valid responses from a server, and mark that server as unresponsive. This behavior would affect the stability of a RADIUS network, as
responsive servers would erroneously be marked as unresponsive. We
therefore recommend that clients should be liberal in what they
accept as responses to Status-Server queries.
4.2. Server Requirements
Servers SHOULD permit administrators to globally enable or disable
the acceptance of Status-Server packets. The default SHOULD be that acceptance is enabled. Servers SHOULD also permit administrators to enable or disable acceptance of Status-Server packets on a per-client basis. The default SHOULD be that acceptance is enabled.
Status-Server packets originating from clients that are not permitted to send the server Request packets MUST be silently discarded. If a server does not support Status-Server packets, or is configured not
to respond to them, then it MUST silently discard the packet.
DeKok Informational [Page 12]
We note that [RFC2865], Section 3, defines a number of RADIUS Codes, but does not make statements about which Codes are valid for
port 1812. In contrast, [RFC2866], Section 3, specifies that only
RADIUS Accounting packets are to be sent to port 1813. This
specification is compatible with [RFC2865], as it uses a known Code
for packets to port 1812. This specification is not compatible with [RFC2866], as it adds a new Code (Status-Server) that is valid for
port 1812. However, as the category of [RFC2866] is Informational,
this conflict is acceptable.
Servers SHOULD silently discard Status-Server packets if they
determine that a client is sending too many Status-Server requests in a particular time period. The method used by a server to make this
determination is implementation specific and out of scope for this
specification.
If a server supports Status-Server packets, and is configured to
respond to them, and receives a packet from a known client, it MUST
validate the Message-Authenticator attribute as defined in [RFC3579], Section 3.2. Packets failing that validation MUST be silently
discarded.
Servers SHOULD NOT otherwise discard Status-Server packets if they
have recently sent the client a Response packet. The query may have originated from an administrator who does not have access to the
Response packet stream or one who is interested in obtaining
additional information about the server.
The server MAY prioritize the handling of Status-Server packets over the handling of other requests, subject to the rate limiting
described above.
The server MAY decide not to respond to a Status-Server, depending on local-site policy. For example, a server that is running but is
unable to perform its normal activities MAY silently discard Status- Server packets. This situation can happen, for example, when a
server requires access to a database for normal operation, but the
connection to that database is down. Or, it may happen when the
accepted load on the server is lower than the offered load.
Some server implementations require that Access-Request packets be
accepted only on "authentication" ports (e.g., 1812/udp), and that
Accounting-Request packets be accepted only on "accounting" ports
(e.g., 1813/udp). Those implementations SHOULD reply to Status-
Server packets sent to an "authentication" port with an Access-Accept packet and SHOULD reply to Status-Server packets sent to an
"accounting" port with an Accounting-Response packet.
DeKok Informational [Page 13]
Some server implementations accept both Access-Request and
Accounting-Request packets on the same port, and they do not
distinguish between "authentication only" ports and "accounting only" ports. Those implementations SHOULD reply to Status-Server packets
with an Access-Accept packet.
The server MAY increment packet counters as a result of receiving a
Status-Server packet or sending a Response packet. The server SHOULD NOT perform any other action that is normally performed when it
receives a Request packet, other than sending a Response packet.
4.3. Failover with Status-Server
A client may wish to "failover" from one proxy to another in the
event that it does not receive a response to an Access-Request or
Accounting-Request. In order to determine whether the lack of
response is due to a problem with the proxy or a downstream server,
the client can send periodic Status-Server packets to a proxy after
the lack of a response.
These packets will help the client determine if the failure was due
to an issue on the path between the client and proxy or the proxy
itself, or whether the issue is occurring downstream.
If no response is received to Status-Server packets, the RADIUS
client can initiate failover to another proxy. By continuing to send Status-Server packets to the original proxy, the RADIUS client can
determine when it becomes responsive again.
Once the server has been deemed responsive, normal RADIUS requests
may be sent to it again. This determination should be made
separately for each server with which the client has a relationship. The same algorithm SHOULD be used for both authentication and
accounting ports. The client MUST treat each destination (IP, port) combination as a unique server for the purposes of this
determination.
Clients SHOULD use a retransmission mechanism similar to that given
in Section 2.2.1 of [RFC5080]. If a reliable transport is used for
RADIUS, then the watchdog timer algorithm specified in [RFC3539] MUST be used.
4.4. Proxy Server Handling of Status-Server
Many RADIUS servers can act as proxy servers, and can forward
requests to another RADIUS server. Such servers MUST NOT proxy
Status-Server packets. The purpose of Status-Server as specified
here is to permit the client to query the responsiveness of a server DeKok Informational [Page 14]
with which it has a direct relationship. Proxying Status-Server
queries would negate any usefulness that may be gained by
implementing support for them.
Proxy servers MAY be configured to respond to Status-Server queries
from clients, and they MAY act as clients sending Status-Server
queries to other servers. However, those activities MUST be
independent of one another.
4.5. Limitations of Status-Server
RADIUS servers are commonly used in an environment where Network
Access Identifiers (NAIs) are used as routing identifiers [RFC4282]. In this practice, the User-Name attribute is decorated with realm-
routing information, commonly in the format of "user@realm". Since a particular RADIUS server may act as a proxy for more than one realm, we need to explain how the behavior defined above in Section 4.3
affects realm routing.
The schematic below demonstrates this scenario.
/-> RADIUS Proxy P -----> RADIUS Server for Realm A
/ \ /
NAS X
\ / \
\-> RADIUS Proxy S -----> RADIUS Server for Realm B
That is, the NAS has relationships with two RADIUS Proxies, P and S. Each RADIUS proxy has relationships with RADIUS servers for both
Realm A and Realm B.
In this scenario, the RADIUS proxies can determine if one or both of the RADIUS servers are dead or unreachable. The NAS can determine if one or both of the RADIUS proxies are dead or unreachable. There is an additional case to consider, however.
If RADIUS Proxy P cannot reach the RADIUS server for Realm A, but
RADIUS Proxy S can reach that RADIUS server, then the NAS cannot
discover this information using the Status-Server queries as outlined above. It would therefore be useful for the NAS to know that Realm A is reachable from RADIUS Proxy S, as it can then route all requests
for Realm A to that RADIUS proxy. Without this knowledge, the client may route requests to RADIUS Proxy P, where they may be discarded or rejected.
To complicate matters, the behavior of RADIUS Proxies P and S in this situation is not well defined. Some implementations simply fail to
respond to the request, and other implementations respond with an DeKok Informational [Page 15]
Access-Reject. If the implementation fails to respond, then the NAS cannot distinguish between the RADIUS proxy being down and the next
server along the proxy chain being unreachable.
In the worst case, failures in routing for Realm A may affect users
of Realm B. For example, if RADIUS Proxy P can reach Realm B but not Realm A, and RADIUS Proxy S can reach Realm A but not Realm B, then
active paths exist to handle all RADIUS requests. However, depending on the NAS and RADIUS proxy implementation choices, the NAS may not
be able to determine to which server requests may be sent in order to maintain network stability.
Unfortunately, this problem cannot be solved by using Status-Server
requests. A robust solution would involve either a RADIUS routing
table for the NAI realms or a RADIUS "destination unreachable"
response to authentication requests. Either solution would not fit
into the traditional RADIUS model, and both are therefore outside of the scope of this specification.
The problem is discussed here in order to define how best to use
Status-Server in this situation, rather than to define a new
solution.
When a server has responded recently to a request from a client, that client MUST mark the server as "responsive". In the above case, a
RADIUS proxy may be responding to requests destined for Realm A, but not responding to requests destined for Realm B. The client
therefore considers the server to be responsive, as it is receiving
responses from the server.
The client will then continue to send requests to the RADIUS proxy
for destination Realm B, even though the RADIUS proxy cannot route
the requests to that destination. This failure is a known limitation of RADIUS, and can be partially addressed through the use of failover in the RADIUS proxies.
A more realistic situation than the one outlined above is one in
which each RADIUS proxy also has multiple choices of RADIUS servers
for a realm, as outlined below.
/-> RADIUS Proxy P -----> RADIUS Server P
/ \ /
NAS X
\ / \
\-> RADIUS Proxy S -----> RADIUS Server S
DeKok Informational [Page 16]
In this situation, if all participants implement Status-Server as
defined herein, any one link may be broken, and all requests from the NAS will still reach a RADIUS server. If two links are broken at
different places (i.e., not both links from the NAS), then all
requests from the NAS will still reach a RADIUS server. In many
situations where three or more links are broken, requests from the
NAS may still reach a RADIUS server.
It is RECOMMENDED, therefore, that implementations desiring the most benefit from Status-Server also implement server failover. The
combination of these two practices will maximize network reliability and stability.
4.6. Management Information Base (MIB) Considerations
4.6.1. Interaction with RADIUS Server MIB Modules
Since Status-Server packets are sent to the defined RADIUS ports,
they can affect the [RFC4669] and [RFC4671] RADIUS server MIB
modules. [RFC4669] defines a counter named
radiusAuthServTotalUnknownTypes that counts "The number of RADIUS
packets of unknown type that were received". [RFC4671] defines a
similar counter named radiusAccServTotalUnknownTypes.
Implementations not supporting Status-Server or implementations that are configured not to respond to Status-Server packets MUST use these counters to track received Status-Server packets.
If, however, Status-Server is supported and the server is configured to respond as described above, then the counters defined in [RFC4669] and [RFC4671] MUST NOT be used to track Status-Server requests or
responses to those requests. That is, when a server fully implements Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST
be unaffected by the transmission or reception of packets relating to Status-Server.
If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB modules, then it SHOULD also support vendor-specific MIB extensions
dedicated solely to tracking Status-Server requests and responses.
Any definition of the server MIB modules for Status-Server is outside of the scope of this document.
4.6.2. Interaction with RADIUS Client MIB Modules
Clients implementing Status-Server MUST NOT increment [RFC4668] or
[RFC4670] counters upon reception of Response packets to Status-
Server queries. That is, when a server fully implements Status-DeKok Informational [Page 17]
Server, the counters defined in [RFC4668] and [RFC4670] MUST be
unaffected by the transmission or reception of packets relating to
Status-Server.
If an implementation supports Status-Server and the [RFC4668] or
[RFC4670] MIB modules, then it SHOULD also support vendor-specific
MIB extensions dedicated solely to tracking Status-Server requests
and responses. Any definition of the client MIB modules for Status- Server is outside of the scope of this document.
5. Table of Attributes
The following table provides a guide to which attributes may be found in Status-Server packets, and in what quantity. Attributes other
than the ones listed below SHOULD NOT be found in a Status-Server
packet.
Status- Access- Accounting-
Server Accept Response # Attribute
0 0 0 1 User-Name
0 0 0 2 User-Password
0 0 0 3 CHAP-Password
0-1 0 0 4 NAS-IP-Address (Note 1)
0 0+ 0 18 Reply-Message
0+ 0+ 0+ 26 Vendor-Specific
0-1 0 0 32 NAS-Identifier (Note 1)
0 0 0 79 EAP-Message
1 0-1 0-1 80 Message-Authenticator
0-1 0 0 95 NAS-IPv6-Address (Note 1)
0 0 0 103-121 Digest-*
Note 1: A Status-Server packet SHOULD contain one of
(NAS-IP-Address or NAS-IPv6-Address), or NAS-Identifier, or both
NAS-Identifier and one of (NAS-IP-Address or NAS-IPv6-Address).
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in
packet.
0-1 Zero or one instance of this attribute MAY be present in
packet.
1 Exactly one instance of this attribute MUST be present in
packet.
DeKok Informational [Page 18]
6. Examples
A few examples are presented to illustrate the flow of packets to
both the authentication and accounting ports. These examples are not intended to be exhaustive; many others are possible. Hexadecimal
dumps of the example packets are given in network byte order, using
the shared secret "xyzzy5461".
6.1. Minimal Query to Authentication Port
The NAS sends a Status-Server UDP packet with minimal content to a
RADIUS server on port 1812.
The Request Authenticator is a 16-octet random number generated by
the NAS. Message-Authenticator is included in order to authenticate that the request came from a known client.
0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02
18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43
82 20 97 c8 4f a3
1 Code = Status-Server (12)
1 ID = 218
2 Length = 38
16 Request Authenticator
Attributes:
18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3
The Response Authenticator is a 16-octet MD5 checksum of the Code
(2), ID (218), Length (20), the Request Authenticator from above, and the shared secret.
02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8
b5 41 1d 66
1 Code = Access-Accept (2)
1 ID = 218
2 Length = 20
16 Request Authenticator
Attributes:
None.
DeKok Informational [Page 19]
6.2. Minimal Query to Accounting Port
The NAS sends a Status-Server UDP packet with minimal content to a
RADIUS server on port 1813.
The Request Authenticator is a 16-octet random number generated by
the NAS. Message-Authenticator is included in order to authenticate that the request came from a known client.
0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f
da de 26 36 78 58
1 Code = Status-Server (12)
1 ID = 179
2 Length = 38
16 Request Authenticator
Attributes:
18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858
The Response Authenticator is a 16-octet MD5 checksum of the Code
(5), ID (179), Length (20), the Request Authenticator from above, and the shared secret.
02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
48 60 66 9c
1 Code = Accounting-Response (5)
1 ID = 179
2 Length = 20
16 Request Authenticator
Attributes:
None.
DeKok Informational [Page 20]
基于PacketTracer5.0构建虚拟校园网的基本功能
基于Packet Tracer5.0构建虚拟校园网的基本功能 摘要本文利用packet tracer 模拟器模拟校园网内局域网的建设，而且配置了校园网的常用功能，如三层交换机VLAN划分、交换机IP地址设置及远程登录功能、Web和DNS 服务器功能的实现。 关键词packet tracer 校园网功能 随着互联网的发展，各高校都有了自己的校园网，校园网基本功能的配置就成为网络管理人员的一项重要任务，本人利用packet tracer 软件模拟校园网的基本构架，详细介绍了校园网内如何配置VLAN和交换机的远程管理的配置,并对校园网内服务器做了一个简单的配置.希望本实验能给校园网络管理员带来一些帮助,而且本实验也可做为高职高等院校网络技术课的实训案例. 1：packet tracer 介绍 Packet Tracer 是由Cisco公司发布的一个辅助学习工具，为学习思科网络课程的初学者去设计、配置、排除网络故障提供了网络模拟环境。用户可以在软件的图形用户界面上直接使用拖曳方法建立网络拓扑，并可提供数据包在网络中行进的详细处理过程，观察网络实时运行情况。可以学习IOS的配置、锻炼故障排查能力。软件还附带4个学期的多个已经建立好的演示环境、任务挑战，该软件仿真度很高，受到业内的极高评价。 2：校园网拓扑图及Vlan 划分 本实验有一个三层交换机（校园网核心交换机），四个接入层交换机（每栋楼两个,一个做为楼栋主交换机,另外一个继连在主交换机上），四台主机，两台服务器（一台WEB服务器，一台DNS服务器），vlan10划分给A楼，取名为:Adonglou,IP段为222.17.193.0/26;Vlan20划分给B楼, 取名为:Bdonglou,IP段为：222.17.193.64/26;vlan30划分给服务器群，取名为:Fuwu,IP段为：222.17.192.0/26;vlan40划分给校园网内的交换机，取名为:SheBei,IP段为：222.17.199.0/26.
基于packettracer智能校园网组建实验指导书
基于Packet tracer 组建校园网 -------实验指导书 一、IP地址划分 根据学校的部门数量划分，将学校分为以下几个VLAN: 二、拓扑图
三、配置 1. 交换机配置 核心交换机为Cisco 3560，将其配置为vtp Server, vtp domain 为senya。将图书馆、教学楼和实验楼等交换机配置为vtp Client，vtp domain为senya。这里以“中心交换机”和“服务器汇聚”交换机为例，讲解交换机的配置，其他交换机的配置可以参考“服务器汇聚”交换机。 第一步：中心交换机配置VTP Server Switch>en Switch# Switch#vlan database Switch(vlan)#vtp domain senya Switch(vlan)#vtp server Switch(vlan)#exit Switch#conf t Switch(config)#int fa 0/1 Switch(config-if)#switchport trunk encapsulation dot1q Switch(config-if)#switchport mode trunk Switch(config-if)#int fa 0/2 Switch(config-if)#switchport trunk encapsulation dot1q Switch(config-if)#switchport mode trunk Switch(config-if)#int fa 0/3 Switch(config-if)#switchport trunk encapsulation dot1q Switch(config-if)#switchport mode trunk Switch(config-if)#int fa 0/4 Switch(config-if)#switchport trunk encapsulation dot1q Switch(config-if)#switchport mode trunk Switch(config-if)#int fa 0/5 Switch(config-if)#switchport trunk encapsulation dot1q Switch(config-if)#switchport mode trunk Switch(config-if)#int fa 0/6 Switch(config-if)#switchport trunk encapsulation dot1q Switch(config-if)#switchport mode trunk Switch(config-if)#int fa 0/7 Switch(config-if)#switchport trunk encapsulation dot1q Switch(config-if)#switchport mode trunk Switch(config-if)#int fa 0/8 Switch(config-if)#switchport trunk encapsulation dot1q Switch(config-if)#switchport mode trunk Switch(config-if)# 注意：此处端口要处于开启状态 第二步：配置“服务器汇聚”交换机trunk链路，允许vlan标记的以太网帧通过该链
CiscoPacketTracer教程
Cisco Packet Tracer实验讲义 实验1 模拟器的初步了解 1 模拟器界面 (1)设备选择区的网络设备：路由器、交换机、集线器、无线设备、线缆、终端设备、仿真广域网、自定义设备 （2）线缆： 自动选择：通用，不建议使用 控制线：用来连接计算机的COM 口和网络设备的Console口 直通线：使用双绞线两端采用同一种线序标准制作的网线，一般用来连接计算机和交换机、交换机与交换机、交换机与路由器 交叉线：使用双绞线两端采用不同线序标准制作的网线，一般用来连接计算机与计算机，计算机与路由器、路由器与路由器 光纤：连接光纤设备 电话线：连接调制解调器或者路由器的RJ-11端口的模块 同轴电缆 DCE/DTE串口线：用于路由器的广域网接入。需要把DCE串口线与一台路由器相连，DTE 串口线与另一台设备相连，但是Cisco Packet Tracer中，之需要选一根就可以了，选了DCE这一根线，则和这根线先连的路由器为DCE端，需要配置该路由器的时钟 （3）设备编辑工具箱 选择，更改布局，笔记，删除，查看，添加简单协议数据单元，增加复杂协议数据单元 2 PC配置方法 添加PC，单击，点击“配置”，可添加IP地址等 桌面菜单提供若干功能 3 路由器的配置模式 用户模式 enable:进入特权模式 configure terminal:进入全局配置模式 interface fastEthernet 0/1 进入端口查看模式
4 连接设备 设备添加好以后，选择相应的线缆，然后在要进行连线的网络设备上单击，会弹出如下图所示的端口选择界面，选中要进行连接的端口，再移动到另外一台设备，选中适当的端口就完成设备的连接了。 实验2 交换机的Vlan配置 1 交换机的基本配置 为设备命名:选中一个交换机加入图中，单击，进入CLI：
2、使用网络模拟器Packettracer
一、实验名称 使用网络模拟器Packettracer 二、实验目的 （1）掌握安装和配置网络模拟器软件Packettracer的方法 （2）掌握使用PacketTracer模拟网络场景的基本方法，加深对网络环境、网络设备和网络协议交互过程的理解。 三、实验内容和要求 （1）安装和配置网络模拟器； （2）熟悉PacketTracer模拟器； （3）观察与IP网络接口的各种网络硬件； （4）进行ping和tracerroute实验 （5）四、实验环境 四、操作方法与实验步骤 五、1）、安装网络模拟器：安装CISCO网络模拟器Packettracer，双击Packettracer 安装程序图标，进行安装，根据提示进行选择确认，可以顺利安装系统。步骤截图就不给出了，因为在实验之前就已经安装过了。 2）、使用Packettracer模拟器：对于其使用的掌握可以去阅读老师给的资料“Packettracer5.0全攻略上、下“。 3）、观察与IP网络接口的各种网络硬件进行 （1）、从Packettracer中打开路由器2620XM的物理设备视图，界面如下
太网接口，而且是要用光纤连接才能使用的接口（不知道翻译的对不对） 将其拖入设备，可以观察到面板硬件接口的情况如下： 自行测试该模块的适用使用场合：对于两台路由器我用除光纤以外的先连接添加的两个端口 会出现下面的错误提示
然后我再用光纤连接它们，发现可以连通，这就验证了NM-1FE-FXde适用的场合： 点击对NM-1FE-TX界面左下角出现对其的描述（备注：拖入设备的过程都和NM-1FE-FX 一样之后的模块就都省去拖入那个步骤了）：应该是提供了一个10/100Mbps的以太网接口，而且是要用交叉铜线才能使用的接口（不知道翻译的对不对） 自行测试该模块的适用使用场合：对于两台路由器我用除交叉铜线可以连通其他都不能连通，可以看出NM-1FE-TX的适用场合。 点击对NM-2FE2W界面左下角出现对其的描述：应该是提供了两个10/100Mbps的以太网接口，而且是要用交叉铜线连接才能使用的接口（不知道翻译的对不对） 自行测试该模块的适用使用场合：对于两台路由器由于使用NM-2FE2W给它们都添加了两个两个要用交叉铜线连接才能使用的10/100Mbps的以太网接口，我把一对接口用交叉铜线连接发现连接通了，而另一对则使用直连铜线连接发现连接不同，因此们我可以看出
利用packet tracer设计校园网 毕业设计
利用packet tracer设计校园网 专业：通信工程 学生：指导老师： 摘要 随着网络技术和计算机多媒体的不断发展与普及，很大程度的加快了校园网建设和应用的步伐，网络技术人才的需求量也在不断增加，如今在校园网中，由于网络应用的大幅度增加，网络变得越来越的拥挤造成了冲突不断产生，网络受到的威胁性也随之增大，管理难度日益加增大，学校对于校园网的要求越来越高，校园网的基本功能的配置成为了网络管理人员的一项重要任务，得到各个学校的重视。 校园网的核心设备是带有路由功能的三层交换机，同时核心设备连接着路由器和汇聚交换机，汇聚交换机下面是接入层交换机。本文利用Cisco packet tracer 软件模拟一个完整的校园网络的基本构架，详细介绍了校园网内如何利用三层交换机实现VLAN的互通。并对当今校园网的形式、情况以及不足做分析。本文给出了较详细的网络设备功能实现的配置命令，实现了具有基本功能的校园网。同时也展示了Packet Tracer 软件的高度仿真性，将Packet Tracer 引入到教学中，脱离了以前全理论知识的抽象难懂，激发学生学习的兴趣和积极性。 关键词：校园网 VLAN 三层交换技术
Using packet tracer design of campus network Major: Communication Engineering Student: Supervisor: Abstract With the continuous development of network technology and computer multimedia and popularization, greatly accelerated the pace of the construction of campus network and application. In the campus network, network application is growing, the network becomes more and more crowded, conflicts arise, the threat of the network is increasing, the management difficulty is increased, the school is more and more high requirements for the campus network, the basic function of campus network configuration has become an important task for the network management personnel, each school's attention. The core equipment of the campus net is the three layer switch with routing function, at the same time, the core equipment connected to the router and the aggregation switch, aggregation switches the access layer switch. The basic framework of this paper by using Cisco Packet Tracer software to simulate a complete campus network, introduces in detail how to use the three layer switchto achieve interoperability of VLAN campus network. And on the campus network,and do not form analysis. This paper gives the detailed implementation ofnetwork equipment configuration commands, has realized the basic function ofcampus network. At the same time also showed a high level simulation of PacketTracer software, Packet Tracer will be introduced into the teaching, from the previous full theoretical knowledge to understand the abstract, arouse students' learning interest and enthusiasm. Key words：Campus network VLAN The three layer switching technology
基于cisco packet tracer企业网络规划与设计
泰州师范高等专科学校 TaiZhou Teachers College 10 届毕业设计（论文） 课题：基于cisco packet tracer 企业网络规划与设计 学生姓名：佟浩 学号： 10533002 系部：数理信息学院 专业：计算机应用企业信息管理 指导教师：朱晔
目录 摘要-----------------------------------------------------------------------------------------------------------------3 关键词--------------------------------------------------------------------------------------------------------------3 绪论-----------------------------------------------------------------------------------------------------------------4 课题背景-----------------------------------------------------------------------------------------------------------4 cisco packet tracer（思科软件）-------------------------------------------------------------------------4相关理论知识------------------------------------------------------------------------------------------------------5企业网的规划与设计---------------------------------------------------------------------------------------------5核心三层交换机(Core SW)配置VLAN-------------------------------------------------------------------------5启用DHCP服务 路由器(Router)实现NAT(网络地址转换)和端口映射功能---------------------------------------------6配置静态路由,使路由器和三层交换机互相连同----------------------------------------------------------6配置应用服务器---------------------------------------------------------------------------------------------------6实现无线上网------------------------------------------------------------------------------------------------------6配置实现------------------------------------------------------------------------------------------------------------6 Core SW交换机实现基于端口的VLAN划分------------------------------------------------------------------6配置Core SW交换机各VLAN接口IP地址并启用路由功能------------------------------------------------7配置路由器Router端口地址----------------------------------------------------------------------------------7静态路由配置------------------------------------------------------------------------------------------------------7配置Router启用NAT及端口映射-----------------------------------------------------------------------------8 结束语---------------------------------------------------------------------------------------------------------------8
网络互联packettracer模拟实验报告
学院：计算机与电子信息学院 班级：网络071 姓名：黄华山学号：0707100304 实验题目：熟悉配置复杂的多级网络。 实验环境(用到的软件或设备)：Packet Tracer模拟软件。 实验内容（附网络拓扑图）：多个路由器，多个三层交换机和两层交换机等构成的大规模网络结构。其中各个vlan的划分如下图： 实验步骤（包括命令的简要说明）： 一：如上图，按照上图连接好网络。在配置路由器和交换机之前，规划好的IP地址。全局规划，以免IP地址的混淆。 核心网络中的路由器之间用22位掩码，外延的三层交换机用24位掩码。其网络结构在上图显示中，可以一目了然。 二：各个主机的ip地址分布，所有主机的掩码都是：255.255.255.0
三：配置路由器。 （1）Router0 Router>EN Router#conf t Router(config)#int fa0/0 Router(config-if)#ip add 4.3.20.100 255.255.252.0 Router(config-if)#no shut Router(config-if)#ex Router(config)#int ser 0/0/0 Router(config-if)#ip add 4.3.4.100 255.255.252.0 Router(config-if)#clock rate 128000 Router(config-if)#no shut Router(config-if)#ex Router(config)#int ser 0/0/1 Router(config-if)#ip add 4.3.12.100 255.255.252.0 Router(config-if)#no shut Router(config-if)#ex (2)Router 1 Router>en Router#conf t Router(config)#int fa0/0 Router(config-if)#ip add 4.3.28.100 255.255.252.0 Router(config-if)#no shut Router(config-if)#ex Router(config)#int ser 0/0/0 Router(config-if)#ip add 4.3.5.100 255.255.252.0 Router(config-if)#no shut Router(config-if)#ex Router(config)#int ser 0/0/1 Router(config-if)#ip add 4.3.8.100 255.255.252.0 Router(config-if)#clock rate 128000
packetTracer SNMP实验指南
随着网络的规模的逐渐增大，网络设备的数量成级增加，网络管理员很难及时监控所有设备的状态，发现并修复故障；网络设备也可能来自不同的厂商，有的厂商配置设备是命令行，有的是Web的，有的是客户端的等等，这些将是网络管理变得更加复杂。在这种情况下，SNMP的功能就发挥了。 网管软件是如何通过SNMP来实现监控和配置网络设备呢？用网络管理软件来获得、配置、监控网络设备，其实就对网络设备的数据库的获取、配置、监控。这种数据库就是MIB（管理信息数据库）。在网络管理软件中也有和网络设备相对的MIB，可能不同厂商的对标准的MIB数据库做了一定“私有化”，只要弄到这些私有MIB导入到网络管理软件，我们就能配置管理网络设备。 MIB是以树状结构进行存储的，树的节点表示就是被管理的对象（如：网络设备的接口信息等），也就说我们要对MIB进行操作就必须在这个树状的数据存贮结构中找到所要管理信息的位置，在MIB中从根开始到节点的唯一路径，我们成为OID（对象标识符）。如下图简单说明下： 如果我们要获得网络设备的系统信息，那么在操作MIB时，它查找的数节点路劲是1.3.6.1.2.1.1（或者用https://www.wendangku.net/doc/375778419.html,.dod.internet.mgmt.mib-2.system），只要对这个节点信息进行操作就可了。 网络拓扑图如下：
IP规划： 路由器：fa0/0 192.168.1.1/24 交换机管理地址：VLAN 1 192.168.1.2/24 PC:192.168.1.10/24 网络设备配置 路由器： hostname R1 interface FastEthernet0/0 ip address 192.168.1.1 255.255.255.0 no shut snmp-server community xiaoro RO（开启SNMP，community是一中简单的身份认真，ro是只读文件，rw是可读可写文件） snmp-server community xiaorw RW 交换机： interface Vlan1 ip address 192.168.1.2 255.255.255.0 snmp-server community xiaoso RO snmp-server community xiaosw RW
PacketTracer网络地址转换NAT配置实验
网络地址转换NAT配置 一、实验目标 ?理解NAT网络地址转换的原理及功能； ?掌握静态NAT的配置，实现局域网访问互联网； 二、实验背景 公司欲发布WWW服务，现要求将内网Web服务器IP地址映射为全局IP地址，实现外部网络可访问公司内部Web服务器。 三、技术原理 ?网络地址转换NAT（Network Address Translation），被广泛应用于各种类型Internet接入方式和各种类型的网络中。原因很简单，NAT不仅完美解决了IP地址不足的问题，而且还能够有效地避免来自网络外部的攻击，隐藏并保护网络内部 的计算机。 ?默认情况下，内部IP地址是无法被路由到外网的，内部主机10.1.1.1要与外部internet通信，IP包到达NAT路由器时，IP包头的源地址10.1.1.1被替换成一 个合法的外网IP，并在NAT转换表中保存这条记录。当外部主机发送一个应答到内网时，NAT路由器收到后，查看当前NAT转换表，用10.1.1.1替换掉这个外网地址。 ?NAT将网络划分为内部网络和外部网络两部分，局域网主机利用NAT访问网络时，是将局域网内部的本地地址转换为全局地址（互联网合法的IP地址）后转发数据包。 ?NAT分为两种类型：NAT（网络地址转换）和NAPT（网络端口地址转换IP地址对应一个全局地址）。 ?静态NAT：实现内部地址与外部地址一对一的映射。现实中，一般都用于服务器； ?动态NAT：定义一个地址池，自动映射，也是一对一的。现实中，用得比较少； ?NAPT：使用不同的端口来映射多个内网IP地址到一个指定的外网IP地址，多对一。 四、实验步骤 实验拓扑
Packettracer的使用及路由器的基本命令
路由器的基本配置 实验环境 本实验可使用PacketTracer软件来模拟环境。实验目的 掌握路由器的常见配置命令。 实验过程 1.在PC0上的配置。
2.在Router 0上的配置。 Router>? // 输入？，可以看到所有在该提示符下可用的命令 Exec commands: <1-99> Session number to resume connect Open a terminal connection disconnect Disconnect an existing network connection enable Turn on privileged commands exit Exit from the EXEC ipv6 ipv6 logout Exit from the EXEC ping Send echo messages resume Resume an active network connection show Show running system information ssh Open a secure shell client connection telnet Open a telnet connection terminal Set terminal line parameters traceroute Trace route to destination Router>
Router>e? //输入命令的一部分，再输入？可以看到可用的命令enable exit Router>en //输入en 按tab键自动补全命令 Router>enable Router>enable //进入特权模式 Router#show interfaces ? //使用？查看命令后面可用参数
思科PacketTracer-7.3.0模拟器完整安装配置汉化
2020-5-19 思科最模拟器Cisco Packet Tracer 7.3.0安装配置 蝌蚪成长记
目录 一、简介 (2) 1.1 概述 (2) 1.2 Cisco Packet Tracer 模拟器简介 (2) 1.3 Cisco Packet Tracer版本 (3) 1.4 准备工具 (4) 1.5 Cisco Packet Tracer模拟器下载 (4) 二、Packet Tracer模拟器安装 (5) 2.1 模拟器安装 (5) 2.2 汉化模拟器 (10)
一、简介 1.1 概述 现阶段学习经常使用的路由交换设备主要来自于思科、华为和华三三家厂商，当然还有中兴、锐捷、神州数码等厂商，这三家的设备操作配置大致类似，却又不尽相同。因为实体设备通常都非常昂贵，购买设备学习也是不现实的。所以我们通常会使用各厂商提供的模拟器来学习。华为的模拟器是eNSP，华三的则是H3C Cloud Lib，思科则是大名鼎鼎的GNS3、Cisco Packet Tracer、WEB-IOU、EVE-NG。 1.2 Cisco Packet Tracer 模拟器简介 Cisco Packet Tracer 是由Cisco公司发布的一个辅助学习工具，为学习思科网络课程的初学者去设计、配置、排除网络故障提供了网络模拟环境。用户可以在软件的图形用户界面上直接使用拖曳方法建立网络拓扑，并可提供数据包在网络中行进的详细处理过程，观察网络实时运行情况。可以学习IOS的配置、锻炼故障排查能力。 Packet Tracer是一个功能强大的网络仿真程序，允许学生实验与网络行为，问“如果”的问题。随着网络技术学院的全面的学习经验的一个组成部分，包示踪提供的仿真，可视化，编辑，评估，和协作能力，有利于教学和复杂的技术概念的学习。 Packet Tracer补充物理设备在课堂上允许学生用的设备，一个几乎无限数量的创建网络鼓励实践，发现，和故障排除。基于仿真的学习环境，帮助学生发展如决策第二十一世纪技能，创造性和批判性思维，解决问题。Packet Tracer补充的网络学院的课程，使教师易教，表现出复杂的技术概念和网络系统的设计。
PacketTracer+IPsec实验
PacketTracer IPsec实验 拓扑图： 子网1，子网2：需要用VPN连接的两个私有网 R0，R1：两个私有网的边界路由，需要进行IPsec配置 子网3，子网4：模拟的Interne R2：Internet路由，使用ACL限制两个私有网地址的包通过 实验步骤： 1. 配置设备地址，开启rip。 第x个子网的网段为：192.168.x.0。 2. 测试各设备连通性 3. R2上配置ACL，将子网3,4模拟成Internet环境 Router2(config)#acc 1 permit 192.168.3.0 0.0.0.255 Router2(config)#acc 1 deny any Router2(config)#acc 2 permit 192.168.4.0 0.0.0.255 Router2(config)#acc 2 deny any Router2(config)#int f0/0 Router2(config-if)#ip acc 1 in Router2(config-if)#exit Router2(config)#int f0/1 Router2(config-if)#ip acc 2 in Router2(config-if)#exit 4. 测试PC0和PC1不可达性。 但是子网3和4之间的各接口都可以相互ping通。
5. 5.1 认证策略，预共享的密钥： R0 crypto isakmp policy 1 //配置IKE策略，1是策略号 authentication pre-share //使用预共享密码 group 2 //设置为1024位的Diffie-Hellman，加密算法默认为DES 5.2 配置密钥： crypto isakmp key mykey address 192.168.4.1 //设置远程对等体共享密码
利用PacketTracer完成无线局域网配置实验
利用PacketTracer完成无线局域网配置实验 一、实验目的 1）掌握无线局域网的基本组成和设备连接关系 2）学习使用无线路由器配置无线局域网的基本技能 二、实验环境: 1）运行Windows 2008 Server/XP/7操作系统的PC一台。 2）每台PC运行程序CISCO公司提供的PacketTracer版本5.3.0。 三、实验内容 1）构建虚拟Internet路由器及互联网Web服务器 2）部署实验网络并对网络设备进行配置 3）验证无线连接并对实验网络进行分析 4）学习使用无线路由器配置无线局域网的基本技能 四、实验步骤 通过PacketTracer搭建无线接入实验网络，网络拓扑如图1。 图1 1. 构建虚拟Internet路由器及互联网Web服务器 在PacketTracer主界面中，添加2811路由器Router0和通用服务器Server0。用自动选择端口方式连接Router0和Server0。 配置Router0： 激活FastEthernet0/0，并配置静态IP地址12.0.0.254/24，如图2所示 图2
类似的，继续配置ROUTER0的端口FastEthernet0/1，并配置静态IP地址11.0.0.254/24,并激活端口。 配置服务器Server0。 在FastEthernet配置页，设置静态IP地址12.0.0.1/24。在全局设置页面(Global→Settings)配置默认网关为12.0.0.254。 检查服务器的HTTP服务是否已开启（默认开启）。 此时可在服务器桌面标签下，打开命令行窗口并使用ping命令，测试服务器到路由器Router0的可达性。 配置无线路由器Wireless Router0 在PacketTracer主界面中，添加型号为Linksys-WRT300N的无线路由器Wireless Router0。此外，添加两台普通台式机PC0、PC1和普通笔记本电脑Laptop0。在这里，我们的目标是，把位于本地网络的三台电脑(PC0、PC1和Laptop0)，通过无线路由器Wireless Router0联入Internet。 首先给PC0、Laptop0换上无线网卡：关闭电源→拖出原网卡→拖入无线网卡→打开电源。如图3所示。 图3 用自动选择端口方式连接Router0和Wireless Router0、Wireless Router0和PC1。 配置互联网(Internet)接口： 在网络接口(Interface)配置中，首先配置互联网(Internet)接口。这里我们使用静态IP地址方式，需要配置默认网关(11.0.0.254)、本地互联网接口IP地址(11.0.0.1/24)，如图4所示。 图4 配置无线路由器LAN口：包括有线连接和无线连接两种方式，通过两种方式的任何一种接入的主机都在一个以太网下。检查Interface下的LAN配置，使用默认的设置：192.168.0.1/24。配置无线路由器的无线接入端口： 首先修改SSID为：wulixi。SSID为无线路由器对外提供服务的名称。所有无线网卡要接入此无线接入点，都需要和SSID名称以及所指定的认证方式进行匹配并通过认证，方可接入。选择认证方式WPA2-PSK，输入密码12345678。如图5所示。
PacketTracer.使用说明
附录B PacketTracer 5.2 使用说明 5.2增加的功能主要有： 1、AAA 2、加密功能 2.1 点到点VPN 2.2 远端VPN 3、Qos （MQC的使用） 4、NTP （网络时间协议） 5、SNMP 6、ipv6 7、ips 8、路由协议也更加完善，可以实现的功能更加全面 9、PC上也增加了几个新的功能是和路由器做配合。 下面讲解一下PacketTracer 5.2的基本用法： 一、设备的选择与连接 在界面的左下角一块区域，这里有许多种类的硬件设备，从左至右，从上到下依次为路由器、交换机、集线器、无线设备、设备之间的连线（Connections）、终端设备、仿真广域网、Custom Made Devices（自定义设备）下面着重讲一下“Connections”，用鼠标点一下它之后，在右边你会看到各种类型的线，依次为Automatically Choose Connection Type（自动选线，万能的，一般不建议使用，除非你真的不知道设备之间该用什么线）、控制线、直通线、交叉线、光纤、电话线、同轴电缆、DCE、DTE。其中DCE和DTE是用于路由器之间的连线，实际当中，你需要把DCE和一台路由器相连，DTE和另一台设备相连。而在这里，你只需选一根就是了，若你选了DCE这一根线，则和这根线先连的路由器为DCE，配置该路由器时需配置时钟哦。交叉线只在路由器和电脑直接相连，或交换机和交换机之间相连时才会用到。 注释：那么Custom Made Devices设备是做什么的呢？通过实验发现当我们用鼠标单击不放开左键把位于第一行的第一个设备也就是Router中的任意一个拖到工作区，然后再拖一个然后我们尝试用串行线Serial DTE连接两个路由器时发现，他们之间是不会正常连接的，原因是这两个设备初始化对然虽然都是模块化的，但是没有添加，比如多个串口等等。那
PacketTracer使用方法
这么说，我用过有许多好的网络模拟软件，其中不乏有特别优秀的！比如Boson的Boson NetSim for CCNA 就很优秀。但是自从我用了Packet Tracer这个思科官方模拟软件后，我发现竟有更优秀的。他的最新版本是Packet Tracer ，直到现在我使用这个工具仍然是爱不释手，好了闲话不多说，工作！网络上有相关Packet Tracer的所谓“教程”，但是都只是皮毛，今天我从以下三个方面入手介绍Packet Tracer 这个软件。力求做到“深入、详解”。另外我不反对大家转载这篇文章，但是我希望朋友转载后请注明链接： 本文用到的Packet Tracer有最新版本PT ,下载地址： cisco的Packet Tracer 现已推出。 在原有的基础上，增加了很多的安全特性。 现在可以满足CCNA 安全课程的学习。 增加的功能主要有： 1、AAA 2、加密功能 点到点VPN 远端VPN 3、Qos （MQC的使用） 4、NTP （网络时间协议） 5、SNMP 6、ipv6 7、ips 8、路由协议也更加完善，可以实现的功能更加全面 9、PC上也增加了几个新的功能是和路由器做配合。 第一篇、熟悉界面 一、设备的选择与连接 在界面的左下角一块区域，这里有许多种类的硬件设备，从左至右，从上到下依次为路由器、交换机、集线器、无线设备、设备之间的连线（Connections）、终端设备、仿真广域网、Custom Made Devices（自定义设备）下面着重讲一下“Connections”，用鼠标点一下它之后，在右边你会看到各种类型的线，依次为Automatically Choose Connection Type（自动选线，万能的，一般不建议使用，除非你真的不知道设备之间该用什么线）、控制线、直通线、交叉线、光纤、电话线、同轴电缆、DCE、DTE。其中DCE和DTE是用于路由器之间的连线，实际当中，你需要把DCE和一台路由器相连，DTE 和另一台设备相连。而在这里，你只需选一根就是了，若你选了DCE这一根线，则和这根线先连的路由器为DCE，配置该路由器时需配置时钟哦。交叉线只在路由器和电脑直接相连，或交换机和交换机之间相连时才会用到。 注释：那么Custom Made Devices设备是做什么的呢通过实验发现当我们用鼠标单击不放开左键把位于第一行的第一个设备也就是Router中的任意一个拖到工作区，然后再拖一个然后我们尝试用串行线Serial DTE连接两个路由器时发现，他们之间是不会正常连接的，原因是这两个设备初始化对然虽然都是模块化的，但是没有添加，比如多个串口等等。那么，这个Custom Made Devices设备就比较好了，他会自动添加一些“必
- PacketTracer使用介绍 PPT
- PacketTracer使用方法
- 基于packettracer智能校园网组建实验指导书
- 网络互联packettracer模拟实验报告
- 初学者用packettracer配置思科设备非常实用
- (完整版)实验二、认识PacketTracer
- 实验二 网络仿真软件PacketTracer的使用
- PacketTracer基本命令
- Packettracer的使用及路由器的基本命令
- PacketTracer.使用说明
- 基于PacketTracer5.0构建虚拟校园网的基本功能
- 基于cisco packet tracer企业网络规划与设计
- 实验二、认识PacketTracer
- 思科PacketTracer-7.3.0模拟器完整安装配置汉化
- 2、使用网络模拟器Packettracer
- packetTracer SNMP实验指南
- PacketTracer实验全集
- 利用PacketTracer完成无线局域网配置实验
- PacketTracer使用介绍
- 利用packet tracer设计校园网 毕业设计