ipsec_VPN解决方案
Digi Support Quick Note 51 常见IPsec VPN隧道谈判错误解决方案说明
Quick Note 51 Common Passwords/ID errors in IPsec VPN negotiation for TransPort WR routersDigi Support1Introduction (4)1.1Outline (4)1.2Assumptions (4)1.3Corrections (4)1.4Version (4)2How to Troubleshoot an IKE/IPsec VPN negotiation (5)2.1Eventlog (5)2.2Analyser IKE Trace (6)3“No Password Available” error (7)3.1What Eventlog shows (7)3.2What to check & Solution (7)3.3Deep analysis: What in the IKE trace (10)4“Login failure by <responder ID>”/ “Bad Packet” Errors (11)4.1What Eventlog shows (11)4.2What to check & Solution (11)4.3Deep analysis: What in the IKE trace (13)5“Invalid ID Information,RX”/ “Login failure by <Initiator ID>” Errors (14)5.1What Eventlog shows (14)5.1.1Main Mode (14)5.1.2Aggressive Mode (14)5.2What to check & Solution (15)5.2.1Main Mode (15)5.2.2Aggressive Mode (16)5.3Deep analysis: What in the IKE trace (18)5.3.1Main Mode (18)5.3.2Aggressive Mode (21)6“Rx ID Failed”/ “Bad Packet” Errors (23)6.1.1Main Mode (23)6.1.2Aggressive Mode (23)6.2What to check & Solution (24)6.2.1Main Mode (24)6.2.2Aggressive Mode (26)6.3Deep analysis: What in the IKE trace (28)6.3.1Main Mode (28)6.3.2Aggressive Mode (29)1.1OutlineWhen configuring an IPsec VPN on a TransPort WR router, users can experiences issues in the negotiation phases related to Password/ID errors. This document provides a summary of the most common ones, with description, how to recognize them and what to check in order to solve them. 1.2AssumptionsThis guide has been written for use by technically competent personnel with a good understanding of the communications technologies used in the product, and of the requirements for their specific application.Preconditions: This guide assumes that the Digi TransPort has IPsec featuresModels shown: Digi TransPort WR44Other Compatible Models: All other Digi TransPort products with IPsec featuresFirmware versions: All VersionsConfiguration: This Quick Note assumes that the devices are configured with an IPsec VPN using the Preshared Key authentication Method1.3CorrectionsRequests for corrections or amendments to this application note are welcome and should be addressed to: *********************Requests for new application notes can be sent to the same address.1.4VersionPage | 4Page | 5In order to troubleshoot a VPN negotiation that is failing, two tools can be used on TransPort routers to see what is happening: Eventlog and Anlayser IKE trace.2.1 EventlogFirst of all, when a user sees that the configured VPN doesn’t go UP, the first thing to do is to look in the eventlog section of the TransPort, where are shown the main events occurring in the device, so also the main phases of the VPN negotiation.MANAGEMENT - EVENT LOG:Figure 2.1-1: Eventlog Section ExamplePage | 62.2 Analyser IKE TraceIf the messages found in the eventlog section are not enough to understand what is wrong in the setup, an IKE Trace needs to be configured, for this, please see instructions on: QN45 - How To Get IKE/IPsec trace on TransPort Routers .Following a screenshot of an example of what can be seen in the analyser trace when IKE debug is configured.MANAGEMENT - ANALYSER > TRACE:Figure 2.2-3: Analyser with IKE tracePlease note that each of the following sections is named as the errors that the user can easily see in the eventlog section. Anyway, it will be also explained what is shown in the Analyser IKE trace to better understand the issue in case of doubts.Page | 7This error appears on the Initiator when Main Mode is used and in the Initiator the “Remote peer’s IP” in the tunnel configuration has not a matching user in Security configuration.No logs will be showed at responder side in this case, because the VPN doesn’t start at all from the Initiator due to this error.3.1 What Eventlog showsThe error described in this section is shown in the eventlog section of a TransPort acting as Initiator of the VPN, and appear similar to the following:15:40:39, 18 Feb 2015,(7) IKE SA Removed. Peer: ,Negotiation Failure15:40:39, 18 Feb 2015,(7) IKE Negotiation Failed. Peer: ,No Password Available 15:40:39, 18 Feb 2015,IKE Request Received From Eroute 03.2 What to check & SolutionOn the Initiator:CONFIGURATION - NETWORK > VIRTUAL PRIVATE NETWORKING (VPN) > IPSEC > IPSEC TUNNELS > IPSEC NThe Remote Peer’s IP field is the IP address to which the Initiator connects in order to establish the VPN.Page | 8CONFIGURATION - SECURITY > USERS:The User configured with the Preshared Key to identify the remote peer has not the “Remote Peer’s IP“ as username.Solution:Basing on RFC 2409, Main Mode with pre-shared key authentication requires knowledge of the peer's pre-shared key prior to the knowledge of the peers’ identity. Therefore, Main Mode with pre-shared keys can only be used when the IP address of the peer is the identifier of the peer.This is the reason why, in this case, the Pre-shared key user must have the username as the “Remote Peer’s IP”.Change the configuration in order to have a user with the “Remote Peer’s IP” as username:Page | 9CONFIGURATION - SECURITY > USERS:Note: if the environment doesn’t allow using IP address to identify the peer, the only solution is to use Aggressive Mode:CONFIGURATION - NETWORK > VIRTUAL PRIVATE NETWORKING (VPN) > IPSEC > IKE > IKE 03.3Deep analysis: What in the IKE traceOn the Initiator (an extract of the whole trace is reported), the IKE trace shows that the Phase 1 negotiation cannot be started due to an error in retrieving password:----- 18-2-2015 15:40:39.110 ------IKE DEBUG: IKE received SA request from eroute 0--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG: New IKE request--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG: Start new IKE negotiation--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG: Locating PH1 SA with ID: initiator, and IP: 10.104.1.114--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG: No PH1 SA available--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG: Locating backup PH1 SA with ID: initiator, and IP: 10.104.1.114--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG: No backup negotiation in progress--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG: Phase 1 negotiation required--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG: Starting new phase 1 negotiation--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG: Preparing for new Phase 1 negotiation--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG (7): Encryption type: 2--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG (7): Key length: 128 bits--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG (7): HASH type: 1--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG (7): DH group: 2--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG (7): No password available--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG: Error starting new phase 1 negotiation--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG: Unable to process SA request--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG (7): Resetting IKE context 0--------------- 18-2-2015 15:40:39.110 ------IKE DEBUG (7): Removing IKE SAPage | 10Page | 11This error appears on the Initiator/Responder when Aggressive Mode is used and on the Initiator there is NO correspondence between “Remote ID” in the tunnel configuration and a User in Security configuration.4.1 What Eventlog showsThe eventlog on the Initiator will show:13:14:01, 24 Feb 2015,(40) IKE SA Removed. Peer: responder,Negotiation Failure 13:14:01, 24 Feb 2015,(40) IKE Negotiation Failed. Peer: ,Rx SA Failed 13:14:01, 24 Feb 2015,Login failure by responder: IKE,IKE13:14:01, 24 Feb 2015,(40) New Phase 1 IKE Session 10.104.1.124,Initiator 13:14:01, 24 Feb 2015,IKE Request Received From Eroute 0The eventlog on the Responder will show:22:23:22, 06 Jan 2000,(41) IKE Negotiation Failed. Peer: ,Bad Packet 22:23:22, 06 Jan 2000,(40) IKE Keys Negotiated. Peer: initiator22:23:22, 06 Jan 2000,(40) New Phase 1 IKE Session 10.104.34.110,Responder4.2 What to check & SolutionOn the Initiator & Responder:CONFIGURATION - NETWORK > VIRTUAL PRIVATE NETWORKING (VPN) > IPSEC > IPSEC TUNNELS > IPSEC NPage | 12On the Initiator:CONFIGURATION - SECURITY > USERSSolution: Configure on the Initiator a user matching the ID of the responder CONFIGURATION - SECURITY > USERS4.3Deep analysis: What in the IKE traceOn the Initiator (an extract of the whole trace is reported):IKE DEBUG (40):Processing ID payload--------------- 24-2-2015 13:14:01.760 ------IKE DEBUG (40):Decoding ID type 11 Key ID--------------- 24-2-2015 13:14:01.760 ------IKE DEBUG (40):Decoded ID is responder--------------- 24-2-2015 13:14:01.760 ------IKE DEBUG (40):Peer ID matches eroute--------------- 24-2-2015 13:14:01.760 ------IKE DEBUG (40):Retrieving password--------------- 24-2-2015 13:14:01.760 ------IKE DEBUG (40):Decoding ID type 11 Key ID--------------- 24-2-2015 13:14:01.760 ------IKE DEBUG (40):Decoded ID is responder--------------- 24-2-2015 13:14:01.760 ------IKE DEBUG (40):Unable to locate password for ID responder--------------- 24-2-2015 13:14:01.760 ------IKE DEBUG (40):Error processing aggressive mode SA message--------------- 24-2-2015 13:14:01.760 ------IKE DEBUG (40):IKE aggressive mode result 0IKE DEBUG (40):Processing ID payload----------This trace confirms that the received Responder ID is “responder” and on the Initiator is not possible to retrieve a password for it as there is no matching user configured.Page | 13This error appears on the Initiator/Responder when either Main Mode or Aggressive Mode is used, and on the Responder there is no User that matches with the ID sent by Initiator. Please note that in Main Mode case, <initiator ID> will be the IP address of the Initiator.5.1What Eventlog shows5.1.1Main ModeIn the eventlog section of the Initiator, when Main Mode is used, the eventlog will show lines as the following:10:35:32, 20 Feb 2015,(23) IKE Negotiation Failed. Peer: ,Bad Packet10:35:32, 20 Feb 2015,(21) IKE SA Removed. Peer: ,Successful Negotiation10:35:32, 20 Feb 2015,(21) IKE Notification: Invalid ID Information,RX10:35:32, 20 Feb 2015,(21) New Phase 1 IKE Session 10.104.1.124,Initiator10:35:32, 20 Feb 2015,IKE Request Received From Eroute 0On the responder:19:45:03, 02 Jan 2000,(9) IKE Negotiation Failed. Peer: ,Bad Packet19:45:03, 02 Jan 2000,(7) IKE SA Removed. Peer: ,Negotiation Failure19:45:03, 02 Jan 2000,(7) IKE Notification: Invalid ID Information,TX19:45:03, 02 Jan 2000,Login failure by 10.104.34.108: IKE,IKE19:45:03, 02 Jan 2000,(7) New Phase 1 IKE Session 10.104.34.108,Responder5.1.2Aggressive ModeIn the eventlog section of the Initiator, when Aggressive Mode is used, the eventlog will show lines as the following:15:25:47, 23 Feb 2015,(39) IKE Negotiation Failed. Peer: ,Bad Packet15:25:47, 23 Feb 2015,(37) IKE SA Removed. Peer: ,Successful Negotiation15:25:47, 23 Feb 2015,(37) IKE Notification: Invalid ID Information,RX15:25:47, 23 Feb 2015,(37) New Phase 1 IKE Session 10.104.1.124,Initiator15:25:47, 23 Feb 2015,IKE Request Received From Eroute 0On the responder:00:35:09, 06 Jan 2000,(39) IKE Negotiation Failed. Peer: ,Bad Packet00:35:09, 06 Jan 2000,(37) IKE SA Removed. Peer: initiator,Negotiation Failure 00:35:09, 06 Jan 2000,(37) IKE Notification: Invalid ID Information,TX00:35:09, 06 Jan 2000,Login failure by initiator: IKE,IKE00:35:09, 06 Jan 2000,(37) New Phase 1 IKE Session 10.104.34.110,ResponderPage | 14Page | 155.2 What to check & Solution5.2.1 Main ModeInitiator:Check the WAN address of the Initiator. How to check it depends on the WAN interface type. In this example, the WAN is ETH 1.MANAGEMENT - NETWORK STATUS > INTERFACES > ETHERNET > ETH 1If there are doubts on the address sent from the Initiator as ID for the VPN, this can be checked looking at the IKE trace (see section 5.3). Responder:CONFIGURATION - SECURITY > USERSSolution:RESPONDER: CONFIGURATION - SECURITY > USERSOn the Responder must be configured a user matching the Initiator IP address.Page | 165.2.2 Aggressive ModeInitiator:CONFIGURATION - NETWORK > VIRTUAL PRIVATE NETWORKING (VPN) > IPSEC > IPSEC TUNNELS > IPSEC NThe “Our ID field” configured in the Tunnel section, when Aggressive Mode is used, must match with a User in the Responder Security configuration. Responder:CONFIGURATION - SECURITY > USERSSolution:The “Our ID” field on the Initiator Tunnel configuration and the Pre-shared key User on the Responder must match:RESPONDER: CONFIGURATION - SECURITY > USERSPage | 175.3Deep analysis: What in the IKE trace5.3.1Main ModeOn the Initiator (an extract of the whole trace is reported), the IKE trace shows that the Responder has sent an Info Packet containing a notify payload with “Message type 18” that correspond to the “INVALID-ID-INFORMATION” error.----- 20-2-2015 10:35:32.720 ------IKE DEBUG (21):Changing IKE SA state from PH1 sent SA to PH1 sent KE--------------- 20-2-2015 10:35:32.720 ------IKE DEBUG: Handling IKE packet--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG: Locating IKE context--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG: Packet for existing negotiation--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):Located SA for existing phase 1 negotiation--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):IKE context located. Local session ID: 0x21--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):Checking packet--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):Got unencrypted INFO packet--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):Validating payloads--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):Checking payload (11) Notify--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):Packet payloads check out OK--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):Packet type (5) Informational--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):IKE role Initiator--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):Handling INFO packet--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):Got INFO exchange--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):1 notify payload----------Page | 18----- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):Handling NOTIFY payload with message type 18--------------- 20-2-2015 10:35:32.730 ------IKE DEBUG (21):Resetting IKE context 0On the Responder (an extract of the whole trace is reported), the IKE trace shows that the responder is not able to retrieve a password for the Remote IP that is used as ID, and so the “Invalid ID information” notification is sent to the Initiator:----- 2-1-2000 19:45:03.640 -------IKE DEBUG: Handling IKE packet--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG: Locating IKE context--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG: Packet for existing negotiation--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Located SA for existing phase 1 negotiation--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): IKE context located. Local session ID: 0x7--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Checking packet--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Validating payloads--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Checking payload (4) Key Ex--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Checking payload (10) Nonce--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Checking payload (20) NATD (RFC)--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Checking payload (20) NATD (RFC)--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Packet payloads check out OK--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Packet type (2) Main mode--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): IKE role Responder--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Handling main mode packet and SA state is (2) PH1 sent SAPage | 19--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Processing KE and NONCE payloads--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Processing RFC NATD payloads--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): HASH's same, we are not behind a NAT box--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Remote peer is not behind a NAT box--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): DH g_x length: 128--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Retrieving password--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Using remote IP (10.104.34.108) as ID--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Unable to locate password for ID 10.104.34.108--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Sending IKE phase 1 notification--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG (7): Notification type (18) Invalid ID Information--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG: Handling IKE packet--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG: Locating IKE context--------------- 2-1-2000 19:45:03.640 -------IKE DEBUG: Packet for existing negotiationPage | 205.3.2Aggressive ModeOn the Initiator (an extract of the whole trace is reported), the IKE trace shows that the Responder has sent an Info Packet containing a notify payload with “Message type 18” that correspond to the “INVALID-ID-INFORMATION” error.----- 23-2-2015 15:25:47.580 ------IKE DEBUG: Handling IKE packet--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG: Locating IKE context--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG: Packet for existing negotiation--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):Located SA for existing phase 1 negotiation--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):IKE context located. Local session ID: 0x37--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):Checking packet--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):Got unencrypted INFO packet--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):Validating payloads--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):Checking payload (11) Notify--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):Packet payloads check out OK--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):Packet type (5) Informational--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):IKE role Initiator--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):Handling INFO packet--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):Got INFO exchange--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):1 notify payload--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):Handling NOTIFY payload with message type 18--------------- 23-2-2015 15:25:47.580 ------IKE DEBUG (37):Resetting IKE context 0----------Page | 21On the responder (an extract of the whole trace is reported), the IKE trace shows that the responder is not able to retrieve a password for the ID sent by the Initiator, and so the “Invalid ID information” notification is sent to the Initiator:----- 6-1-2000 00:35:09.600 -------IKE DEBUG (37):Retrieving password--------------- 6-1-2000 00:35:09.600 -------IKE DEBUG (37):Decoding ID type 11 Key ID--------------- 6-1-2000 00:35:09.600 -------IKE DEBUG (37):Decoded ID is initiator--------------- 6-1-2000 00:35:09.600 -------IKE DEBUG (37):Unable to locate password for ID initiator--------------- 6-1-2000 00:35:09.600 -------IKE DEBUG (37):Sending IKE phase 1 notification--------------- 6-1-2000 00:35:09.600 -------IKE DEBUG (37):Notification type (18) Invalid ID Information--------------- 6-1-2000 00:35:09.600 -------IKE DEBUG (37):Transmit IKE packet--------------- 6-1-2000 00:35:09.600 -------IKE DEBUG (37):Transmit to peer 10.104.34.110--------------- 6-1-2000 00:35:09.600 -------IKE DEBUG (37):IKE notification sent Invalid ID Information--------------- 6-1-2000 00:35:09.600 -------IKE DEBUG (37):Error processing SA message--------------- 6-1-2000 00:35:09.600 -------IKE DEBUG (37):IKE aggressive mode result 0--------------- 6-1-2000 00:35:09.600 -------IKE DEBUG (37):Resetting IKE context 0Page | 22This error appears on the Initiator/Responder when Main Mode or Aggressive Mode is used and, on the Initiator, the “Remote ID” on Tunnel configuration, doesn’t match with the ID sent by the responder. Please note that in Main Mode case this sent ID is the responder IP address, instead in Aggressive Mode this will be the “our ID” field in responder’s Tunnel configuration.6.1.1Main ModeIn the eventlog section of the Initiator, when Main Mode is used, the eventlog will show lines as the following:15:54:42, 24 Feb 2015,(88) IKE SA Removed. Peer: 10.104.1.124,Negotiation Failure15:54:42, 24 Feb 2015,(88) IKE Notification: Invalid ID Information,TX15:54:42, 24 Feb 2015,(88) IKE Negotiation Failed. Peer: ,Rx ID Failed15:54:42, 24 Feb 2015,(88) IKE Keys Negotiated. Peer:15:54:42, 24 Feb 2015,(88) New Phase 1 IKE Session 10.104.1.124,Initiator15:54:42, 24 Feb 2015,IKE Request Received From Eroute 0On the responder:15:54:42, 24 Feb 2015,(90) IKE Negotiation Failed. Peer: ,Bad Packet15:54:42, 24 Feb 2015,(88) IKE Keys Negotiated. Peer:15:54:42, 24 Feb 2015,(88) New Phase 1 IKE Session 10.104.34.110,Responder6.1.2Aggressive ModeIn the eventlog section of the Initiator, when Aggressive Mode is used, the eventlog will show lines as the following:13:28:12, 24 Feb 2015,(79) IKE SA Removed. Peer: responder,Negotiation Failure13:28:12, 24 Feb 2015,(79) IKE Negotiation Failed. Peer: ,Rx SA Failed13:28:12, 24 Feb 2015,(79) IKE Negotiation Failed. Peer: ,Rx ID Failed13:28:12, 24 Feb 2015,(79) New Phase 1 IKE Session 10.104.1.124,Initiator13:28:12, 24 Feb 2015,IKE Request Received From Eroute 0On the responder:22:37:32, 06 Jan 2000,(80) IKE Negotiation Failed. Peer: ,Bad Packet22:37:32, 06 Jan 2000,(79) IKE Keys Negotiated. Peer: initiator22:37:32, 06 Jan 2000,(79) New Phase 1 IKE Session 10.104.34.110,ResponderPage | 23Page | 246.2 What to check & Solution6.2.1 Main ModeInitiator:CONFIGURATION - NETWORK > VIRTUAL PRIVATE NETWORKING (VPN) > IPSEC > IPSEC TUNNELS > IPSEC NResponder:Check the WAN address of the Responder. How to check it depends on the WAN interface type. In this example, the WAN is ETH 1:MANAGEMENT - NETWORK STATUS > INTERFACES > ETHERNET > ETH 1If there are doubts on the address used from the Initiator as ID for the VPN, this can be checked looking at the IKE trace (see section 6.3).Page | 25Solution:INITIATOR: CONFIGURATION - NETWORK > VIRTUAL PRIVATE NETWORKING (VPN) > IPSEC > IPSEC TUNNELS > IPSEC NOn the Initiator, in the Tunnel configuration, the Remote ID must be changed to match the Responder IP address.Page | 266.2.2 Aggressive ModeInitiator:CONFIGURATION - NETWORK > VIRTUAL PRIVATE NETWORKING (VPN) > IPSEC > IPSEC TUNNELS > IPSEC NResponder:CONFIGURATION - NETWORK > VIRTUAL PRIVATE NETWORKING (VPN) > IPSEC > IPSEC TUNNELS > IPSEC NPage | 27Solution:The “Remote ID” field on the Initiator Tunnel configuration and the “Our ID field” on the Responder configuration must match:INITIATOR: CONFIGURATION - NETWORK > VIRTUAL PRIVATE NETWORKING (VPN) > IPSEC > IPSEC TUNNELS > IPSEC NRESPONDER: CONFIGURATION - NETWORK > VIRTUAL PRIVATE NETWORKING (VPN) > IPSEC > IPSEC TUNNELS > IPSEC N6.3Deep analysis: What in the IKE trace6.3.1Main ModeOn the Initiator (an extract of the whole trace is reported), the IKE trace shows that the Responder IP doesn’t match with the configured eroute, this cause an error and the Initiator sent an “Invalid ID information” message:----- 24-2-2015 15:54:42.810 ------IKE DEBUG: Handling IKE packet--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG: Locating IKE context--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG: Packet for existing negotiation--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Located SA for existing phase 1 negotiation--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):IKE context located. Local session ID: 0x88--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Checking packet--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):IKE decrypting packet--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Validating payloads--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Checking payload (5) ID--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Checking payload (8) Hash--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Packet payloads check out OK--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Packet type (2) Main mode--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):IKE role Initiator--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Handling main mode packet and SA state is (4) PH1 sent hash--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Processing ID payload--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Decoding ID type 1 IP V4 address----------Page | 28----- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Decoded ID is 10.104.1.124--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Peer ID doesn't match eroute--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Error processing ID payload--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Sending IKE phase 1 notification--------------- 24-2-2015 15:54:42.810 ------IKE DEBUG (88):Notification type (18) Invalid ID Information----------6.3.2Aggressive ModeOn the Initiator (an extract of the whole trace is reported), the IKE trace shows:----- 24-2-2015 13:28:12.300 ------IKE DEBUG (79):Processing ID payload--------------- 24-2-2015 13:28:12.300 ------IKE DEBUG (79):Decoding ID type 11 Key ID--------------- 24-2-2015 13:28:12.300 ------IKE DEBUG (79):Decoded ID is responder--------------- 24-2-2015 13:28:12.300 ------IKE DEBUG (79):Peer ID doesn't match eroute--------------- 24-2-2015 13:28:12.300 ------IKE DEBUG (79):Error processing ID payload--------------- 24-2-2015 13:28:12.300 ------IKE DEBUG (79):Error processing aggressive mode SA message--------------- 24-2-2015 13:28:12.300 ------IKE DEBUG (79):IKE aggressive mode result 0So, also in this case, the responder ID doesn’t match with the configured eroute, this cause an error in processing the payload.Page | 29。
中石化vpn解决方案0612
IPSec VPN解决方案华为3com技术有限公司目录1. 概述 (3)1.1 VPN定义 (3)1.2 VPN的类型 (4)1.3 VPN的优点 (5)1.4 隧道技术 (5)1.5 加密技术 (8)1.6 身份认证技术 (9)2. 建设方案 (11)2.1 基本建设思路 (11)2.2 组网方案 (11)2.3 可靠性方案 (17)3. IPSec VPN管理系统 (21)3.1 轻松部署安全网络 (21)3.2 直观展示VPN拓扑 (22)3.3 全方位监控网络性能 (22)3.4 快速定位网络故障 (24)3.5 BIMS分支智能管理系统 (24)附件:iNode客户端软件介绍 (26)1. 概述随着网络，尤其是网络经济的发展，企业日益扩张，客户分布日益广泛，合作伙伴日益增多，这种情况促使了企业的效益日益增长，另一方面也越来越凸现传统企业网的功能缺陷：传统企业网基于固定物理地点的专线连接方式已难以适应现代企业的需求。
于是企业对于自身的网络建设提出了更高的需求，主要表现在网络的灵活性、安全性、经济性、扩展性等方面。
在这样的背景下，VPN以其独具特色的优势赢得了越来越多的企业的青睐，令企业可以较少地关注网络的运行与维护，而更多地致力于企业的商业目标的实现。
1.1VPN定义利用公共网络来构建的私人专用网络称为虚拟私有网络（VPN，Virtual Private Network），用于构建VPN的公共网络包括Internet、帧中继、ATM等。
在公共网络上组建的VPN象企业现有的私有网络一样提供安全性、可靠性和可管理性等。
“虚拟”的概念是相对传统私有网络的构建方式而言的。
对于广域网连接，传统的组网方式是通过远程拨号连接来实现的，而VPN是利用服务提供商所提供的公共网络来实现远程的广域连接。
通过VPN，企业可以以明显更低的成本连接它们的远地办事机构、出差工作人员以及业务合作伙伴，如图1所示。
图1 VPN应用示意图由图可知，企业内部资源享用者只需连入本地ISP的POP（Point Of Presence，接入服务提供点），即可相互通信；而利用传统的WAN组建技术，彼此之间要有专线相连才可以达到同样的目的。
基于IPSec-VPN解决跨地域公司内网互访网络的设计
1引言当今信息时代，企业往往会在全国各地设立分公司，企业内部信息传递尤为重要，包括内部资源共享，邮件往来和综合信息应用等都要求各站点之间能互通。
传统解决方法有以下两种：第一种是在每两个站点之间申请一条专线，两个站点之间的业务往来是通过专线传输。
但是这种方案有明显的缺点，一是专线费用较高，二是专线只适应站点较少的情况，当分公司站点偏多的情况下专线的数量几何增长，造价太高。
第二种解决方案是在每个站点之间使用VPN技术，在各站点之间建立逻辑的链路通道，通过动态路由协议把各内部网络和隧道链路互联。
该方案缺点是企业业务数据在互联网上直接封装IP包传输，信息在传递过程中可能会被窃取。
通过本方案设计，各站点出口部署隧道分离技术，保证内部网络和外网的分离，通过IPSec-VPN技术在数据前面加上一个加密的头部，这样数据在传递过程中即使被窃取，也无法还原真实数据，保证了网路安全[1]。
2总体设计2.1系统方案分析及方案逻辑拓扑使用GNS3网络模拟器进行模拟仿真。
规划所有设备的连接，配置IP地址，在各站点出口部署NAT技术，保证所有站点能访问互联网。
在各站点之间部署隧道技术，建立各分支站点的逻辑链路通道。
在全网部署OSPF路由协议，骨干区域部署在隧道链路上，其他分公司部署在非骨干区域。
利用IPsec-VPN技术和隧道分离技术，使内部网络回访流量通过隧道传输，访问外网资源通过NAT技术正常访问。
综合各种条件我们认为此方案可行。
2.2设计不足及解决方法在使用GNS3模拟路由器功能的时候，会出现一些无法解释的bug。
这与软件和模拟器设备使用的IOS版本有关。
可以使用现在最新的eve模拟器来尽量避免类似问题的出现。
在本项目中对数据使用了3DES进行加密，但随着新技术的不断涌现，此算法已经不能很好的保证数据安全，如果对数据加密有较高要求可以使用AES进行加密。
3相关技术功能及分析3.1模拟器介绍与选择网络模拟器的出现有着跨时代的意义，只需要通过简单地操作就可以设计出最优的网络架构，然后在真机上部署，大基于IPSec-VPN解决跨地域公司内网互访网络的设计The Design of Solving the Intranet Exchange Visits of Cross-Regional CorporateBased on the IPSec-VPN张焱，杨贵莲，徐柯，向梅梅，韦珊（大连民族大学，辽宁大连116600）ZHANG Yan,YANG Gui-lian,XU Ke,XIANG Mei-mei,WEI Shan（DalianNationalitiesUniversity,Dalian116600,China）【摘要】论文介绍了VPN及IPSec-VPN的定义和应用，并提出了一种基于IPSec-VPN技术解决跨地域公司内网互访网络的设计和解决方案。
VPN双线路解决方案
三盛宏业投资（集团）有限公司VPN解决方案客户背景XXXX客户需求随着Internet技术的发展，病毒与网络攻击影响越来越严重，各类网络攻击、网络病毒大量泛滥，网络安全面临新的挑战。
由于各分公司之间信息交互的频繁，重要的营业数据、财务数据等信息在网络中传输越来越多。
网络传输环境的不安全，导致机密信息被窃取，会给公司造成极大的损失。
因此各分公司机构信息的传输，需要安全稳定的内外部网络环境。
有鉴有此，本方案中提出了ipsec VPN的解决方案。
所谓的VPN，就是在各个分公司部署VPN的网关设备，通过VPN设备，在各个分公司和总公司之间建立虚拟隧道，他采用安全加密算法，各个分公司互相访问，先通过VPN在传输数据，这样具有绝对的安全性，目前为止，该方案中所使用的IPSEC VPN技术，没有被人破解过，而且他部署后使用很方便，各个公司相互访问，就跟在本地局域网访问一样。
无须很复杂的操作，解决方案网络拓扑方案说明如上图所示：建议在中心安装2根光纤线路，各地分公司申请一根线路（ADSL，光纤，有无固定IP均可），总部部署一台sonicwall nsa 系列的UTM防火墙，他带网关防病毒，入侵检测，反间谍软件功能这样功能可以过滤网络中的各种病毒，防止来之内外网的攻击，同时起用该设备的VPN功能，用来和各个分公司的VPN设备设备建立点对点的IPSEC VPN，例外，如果考虑稳定性，可以在中心选择2台防火墙做双机热备份，那样可以保证其中一台设备坏掉的时候，可以马上切换到例外一根线路。
各个分公司部署小型的sonicwall 防火墙，用来防护分公司的数据安全，同时用他和中心的VPN设备做点对点的VPN 该方案最大的优势在与，可以让电信的分公司优先和总部的电信线路建立VPN，当总部电信的线路断线的时候，他会自动切换到和联通的线路建立VPN，联通的分公司优先和总部的联通线路建立VPN，当总部联通的线路断线时，会自动切换到电信的线路，这种VPN双线路备份技术是目前很多产品无法解决的，他的好处是解决了电信和联通南北互通的问题，同时，起到VPN双线路的备份，产品选型根据贵公司分公司的人数多少，建议您根据如下型号选择合适您的产品：。
ipsec vpn 方案
IPSec VPN 方案简介IPSec（Internet Protocol Security）是一种网络层安全协议，用于实现在IP网络上的安全通信。
IPSec VPN（Virtual Private Network）是基于IPSec协议构建的一种加密通信技术，可实现跨公共网络的安全通信。
IPSec VPN 方案提供了一种安全、可靠、灵活的远程访问和分支互联的解决方案。
它通过加密和认证机制来保护通信数据的机密性和完整性，使得远程用户和分支机构可以安全地访问企业内部网络。
本文将介绍IPSec VPN的基本概念和工作原理，并提供一个示例IPSec VPN方案的配置案例。
工作原理IPSec VPN的工作原理可以简单分为以下几个步骤：1.建立安全关联（Security Association，SA）：在IPSec VPN的两个端点之间建立SA，SA定义了安全参数，如加密算法、认证方法等。
2.通信的初始阶段：在建立SA后，两个端点之间进行安全通信的初始阶段，对初始阶段的通信进行加密和认证。
3.数据传输：在初始阶段完成后，数据可以以安全的方式传输。
IPSec使用加密和认证机制来保护传输的数据。
4.数据完整性检查和认证：接收方对接收到的数据进行完整性检查和认证，以保证数据的完整性和真实性。
5.数据解密：接收方使用相应的密钥对加密的数据进行解密，以获取原始的明文数据。
配置案例下面是一个示例的IPSec VPN方案的配置案例。
假设有两个网络，A网络和B 网络，需要建立一个安全的VPN连接。
网络拓扑+--------------------------------------+| || A网络 B网络 || |+-------------------+------------------+|Internet|+-------------------+------------------+| || VPN Server || |+--------------------------------------+配置步骤1.配置VPN Server：- 安装并配置IPSec VPN Server软件，如StrongSwan。
H3C华为-IPsecVPN配置教程
H3C华为-IPsecVPN配置教程H3C&华为-IPsecVPN配置教程第⼀篇：⽹关对⽹关IPSec-VPN⼀、H3C路由1、型号：MER5200；软件版本： version 7.1.064, Release 0809P07；固定外⽹IP；2、添加静态路由添加⾄对端公⽹和对端私⽹路由两条，如下图：3、创建IPsecVPN3.1 “虚拟专⽹”---“IPsecVPN”---新建-如下图：3.2 名称----⾃⾏编辑；接⼝---选择外⽹出⼝，组⽹⽅式---分⽀节点；对端⽹关---对端外⽹IP；认证⽅式---预共享密钥；预共享密钥要与对端路由⼀致；3.3 保护流配置H3C路由器下有个内⽹段需要与对端通信，就添加⼏个。
本例172.16.10.0/24与10.10.11.0/24为本地内⽹，172.24.0.0/24为对端内⽹。
注：H3C设备不需要单独再做NAT配置。
4、显⽰⾼级配置4.1 ike配置：主模式、本地外⽹、对端外⽹，关闭对等体检测，算法组推荐。
如下图：4.2 IPsec配置：按照默认配置即可。
5、监控信息待对端华为路由配置完成且正确后，监控会显⽰如下信息。
6、命令⾏检查[H3C]dis acl allDis ike saDis ipsec sa⼆、华为路由1、型号：AR1220-S，软件版本：[V200R007C00SPC900]，固定外⽹IP。
2、添加静态路由添加⾄对端公⽹和对端私⽹路由两条，如下图：2、配置⾼级ACL2.1 新建“nonat”，添加⽬的地址10.10.11.0/24,172.16.10.0/24不做NAT转换两条，其他允许NAT转换；如下图2.2 新建“nj-g”,i添加本地内⽹172.24.0.0/24⾄⽬的内⽹10.10.11.0/24,172.16.10.0/24的acl，此路由⾛IPsec。
如下图2.3 创建“⽣效时间”3、NAT应⽤⾼级acl“ip业务”--“NAT”---“外⽹访问”---编辑----ACL名称选择“nonat”。
关于IPSEC-VPN-实验详解
关于IPSEC VPN 实验详解文章来源：不详作者：佚名该文章讲述了关于IPSEC VPN 实验详解.由于Internet宽带接入的普及，它的带宽与价格非常的便宜（相对于专线而言）.８Ｍ的ADSL价位不到两千元／年.越来越多的企业开始发掘基于宽带接入的增值应用.由于VPN技术的成熟，如对数据的加密技术与VPN Qos技术的发展，使得基于Internet接入的VPN应用日趋增多.VPN技术可用于远程用户的接入（用于取代传统拨号接入技术）访问，用于对主线路的备份作为备份链路，甚至可以取代传统的专线地位用于企业各分支机构的专有网络互联.用于取代专线或备份线路接入的Site-to-Site VPN接入技术，用于远程终端用户接入访问的Remote-VPN(也叫Easy VPN，取代传统拨号接入).基于WEB页面访问的WEB VPN技术.又叫SSL VPN.１．Site-to-site vpn(三种类型)站点间的VPN技术.IKE使用UDP端口500,Ipsec ESP和AH使用协议号50和51.因此如果要实现VPN穿越，必须在相应接口上配置访问列表以允许VPN流量通过。
Site-to-Site VPN的配置通常可分为四个步骤：1.传统路由及需互访的流量定义定义路由设置感兴趣的流量（即定义互访的内网主机流量以触发VPN参数协商）2.定义IKE参数（IKE第一阶段安全关联协商）定义ISAKMP策略定义ISAKMP对等体和验证密钥3.定义Ipsec参数（IKE第二阶段安全关联协商）定义Ipsec的转换集Transform定义Ipsec的加密映射（crypto map）。
4.将加密映射应用到相应接口。
当路由器收到一个数据包时，它将检查安全策略（即所定义的感兴趣的流量）以决定是否为此数据包提供保护。
如果匹配访问列表所定义的流量，则路由器决定采用何种安全服务，并决定IPSEC端点所使用的地址，并检查是否存在一个安全关联（security association）.如果没有安全关联，则路由器将与对等体协商建立。
ipsec和ssl vpn原理
IPSec（Internet Protocol Security）和SSL（Secure Socket Layer）VPN是两种常见的远程访问和网络安全协议，它们都用于保护数据在公共网络上的传输，并提供安全的远程访问解决方案。
本文将重点介绍IPSec和SSL VPN的原理，包括其工作原理、优缺点以及适用场景。
一、IPSec VPN原理1. IPSec VPN的工作原理IPSec VPN是一种在IP层实现的安全协议，它建立在IP层之上，可以保护整个网络层的通信。
IPSec VPN使用加密和认证机制来保护数据的机密性和完整性，确保数据在传输过程中不被篡改或窃取。
其工作原理主要包括以下几个步骤：1）通过IKE（Internet Key Exchange）协议建立安全关联（Security Association，SA），协商加密算法、认证算法、密钥长度等参数；2）建立隧道模式或传输模式的安全通道，将要传输的数据封装起来，并使用加密算法对数据进行加密；3）在通信双方的边界设备（如路由器、防火墙）上进行数据的解密和解封装，然后将数据传递给内部网络。
2. IPSec VPN的优缺点IPSec VPN具有以下优点：1）强大的安全性：IPSec VPN采用先进的加密和认证算法，可以有效保护数据的安全性；2）适用于网关到网关和终端到网关的部署：IPSec VPN可以实现网关到网关和终端到网关的安全连接，适用于企业内部网络到外部网络的连接需求。
然而，IPSec VPN也存在一些缺点：1）配置复杂：IPSec VPN的配置相对复杂，需要对网络设备进行详细的配置和管理；2）支持性差：由于IPSec VPN使用的协议和端口较多，导致有些网络环境可能无法通过IPSec VPN进行安全通信。
3. IPSec VPN的适用场景IPSec VPN适用于以下场景：1）企业远程办公：员工可以通过IPSec VPN安全地连接到公司内部网络，进行远程办公和资源访问；2）跨地域网络连接：不同地域的网络可以通过IPSec VPN建立安全连接，实现跨地域的网络互联；3）数据中心互联：多个数据中心之间可以通过IPSec VPN建立安全通道，实现数据的安全传输和共享。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
深信服科技
使用全球网络资源构建成局域网
统一的信息平台建立，实现总 部与分支之间资源共享
数据大集中实现资源的最佳化 配置
大专网内构建“小专网”，保 障敏感数据的安全
专线备份，全方位的稳定性保 证
您是否遇到过这些问题？
专网建设成本高昂
花重金构建起了统一信息平台需要在整个组织内部 推广使用，但分支遍布全省、全国甚至国际各地。若 是使用专线构建网络，长期成本直逼信息系统的花费！
国内某大型保险公司
！ 解决方案
公网“专有化”！ 组网便利，易于扩展 透明访问，使用方便
您是否担心过以下问题？
多组织多部门共用大专网
多个组织多个部门都在同一大专网内，只是公开的 互联网“专”了一点。重要的应用在专网内还是明文 传输，如此大专化存在风险问题！
节点安全短板问题
大专网内某些节点存在安全风险，易成为黑客等入 侵专网的入口，直接对专网内明文传输的数据造成威 胁。
稳定性
多线路主备实现线路的冗余备份 双机热备实现设备的冗余备份 与国际领先测试方案提供商思博伦（Sprient）合作，高压 高强度测试下全方面的保证设备的高稳定可靠性
SANGFOR IPSec VPN市场影响力
深信服VPN客户应用概况
市场占有率连续5年全国第一
目前已有34家省部级政府单位 23家省级电信运营商 37所国家重点大学 16家全国性保险公司 总共35家的世界500强的中国企业中,已有22家选择了深信服 每天，超过八千多家的知名客户都在使用IPSEC VPN大范围组 网保证自身业务的畅通运行
某大型集团
！ 解决方案
使用公网线路+IPSec VPN 进行专线备份，保证安全性的 同时大大降低成本
SANGFOR
更复杂的业务网络的构建
多层网络建设的问题
网络建设中往往存在着三级或多级关系 典型的如行政组织结构：省—市—县—乡—村 典型如企业组织多层结构：中心---大区域—小片区—更细化的单元 存在小型分支或移动用户
某省公安厅
！ 解决方案
IPSec VPN公网数据强加密， 在大专网中构建小专网！
您是否考虑过以下情况？
网络的冗余可靠性
现有的网络都是依靠单一运营商的专线，但频频发 生的运营商线路中断让人提心吊胆，网络线路的主备 机制越发重要
备份线路的高成本
备份线路使用频率低却是不可或缺的，使用专线进 行出口线路的主备成本太高，投资回报比让人堪忧。
网络改造频繁
分支的伸缩性强，扩张快，这个月刚搭好的专网下 个月又要改，网管人员一直在马不停蹄的改造网络架 构！
国内某大型保险公司
建设统一网络面临的布网问题：
地域性问题： 下属分支机构众多，遍布范 围广，传统网络连接成本过高； 业务布局的变动性问题： 业务布局伸缩性较强，网络 布局会随着业务布局有较大改变；
深信服统一管理设备VPN—SC
——专为大型网络管理而配置
为大规模网络客户管理部门提供 降低网络管理难度 降低网络管理成本 更稳定的业务网络 更快速的网络维护升级
典型客户：中国环境检测总站、中国人寿财险集团、安徽新华发行集团、 铁道部第二勘察设计院、泰康人寿保险有限公司
SANGFOR IPSec VPN解决方案技术特点 安全 速度 稳定
高安全性
基于国际标准的IPSec VPN 国家IPSec VPN标准的核心制定者之一，产品高安全保证 细化到端口
拥有专利多线路技术实现带宽叠加和负载均衡，最大化的 提高带宽利用率！
通过专利畅联技术优化传输线路，即使面对高丢包的环境 也能畅通无阻！
扩展性强，可升级为专业的广域网加速设备，让公网线路 搭建的VPN拥有局域网般飞一般的感觉！
深信服VPN部分客户名单
政府 运营商
金融 教育 企业集团
电力 ……
谢谢！
更贴近于单位架构的网络？——符合单位层次 性价比更高的网络？ ——符合合理投资 灵活性更好的网络？ ——灵活增删节点 大型的可维护性网络？ ——统一设备管理
中共某省委党校
三级及三级以上网络建网：
多层网络建设的管理问题
多层网络建设涉及到分散在多个地方的硬件设备； 统一的系统要求系统设置具备统一的策略 如何来进行有效的管理？