Quidway Eudemon 200E-B Firewall Feature Description (V100R002 - 01)

Quidway Eudemon 200E-B Firewall
V100R002
Feature Description
Issue 01
Date 2009-12-25
Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. For any
assistance, please contact our local office or company headquarters.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Copyright © Huawei Technologies Co., Ltd. 2009. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are the property of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but the statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Proprietary and Confidential

Quidway Eudemon 200E-B
Feature Description Contents
Contents
About This Document.....................................................................................................................1

1 Overview......................................................................................................................................1-1
1.1 Introduction to the Product..............................................................................................................................1-2
1.2 Introduction to Network Security....................................................................................................................1-3
1.2.1 Security Threats......................................................................................................................................1-3
1.2.2 Network Security Service Classification................................................................................................1-4
1.2.3 Implementation Methods........................................................................................................................1-4
1.3 Introduction to Firewall...................................................................................................................................1-6
1.3.1 First Safeguard.......................................................................................................................................1-7
1.3.2 Development of Firewalls......................................................................................................................1-7
1.4 Functions and Features....................................................................................................................................1-9
1.4.1 Security Defense....................................................................................................................................1-9
1.4.2 Network Interconnection......................................................................................................................1-11
1.4.3 Service Application..............................................................................................................................1-12
1.4.4 Unified Threat Management................................................................................................................1-12
1.4.5 Configuration Management..................................................................................................................1-13
1.4.6 Maintenance and Reliability.................................................................................................................1-14
1.4.7 System Log...........................................................................................................................................1-15
1.5 Location of the Eudemon..............................................................................................................................1-15
2 Introduction to the Eudemon...................................................................................................2-1

2.1 Working Mode................................................................................................................................................2-2
2.1.1 Working Mode Classification................................................................................................................2-2
2.1.2 Working Process in Route Mode...........................................................................................................2-4
2.1.3 Working Process in Transparent Mode..................................................................................................2-4
2.1.4 Working Process in Composite Mode..................................................................................................2-10
2.2 Security Zone................................................................................................................................................2-10
2.2.1 Introduction to Security Zone..............................................................................................................2-10
2.2.2 Security Zones on the Eudemon...........................................................................................................2-11
3 Security Features........................................................................................................................3-1
3.1 ACL.................................................................................................................................................................3-3
3.1.1 ACL Definition......................................................................................................................................3-3
3.1.2 ACL Application....................................................................................................................................3-3
Issue 01 (2009-12-25) Huawei Proprietary and Confidential i

Contents Feature Description
3.1.3 ACLs on the Eudemon...........................................................................................................................3-5

3.1.4 ACL Step................................................................................................................................................3-7
3.2 Security Policy................................................................................................................................................3-8
3.2.1 Packet Filtering......................................................................................................................................3-8
3.2.2 Attack Defense.......................................................................................................................................3-9
3.2.3 ASPF....................................................................................................................................................3-11
3.2.4 Blacklist................................................................................................................................................3-12
3.2.5 MAC and IP Address Binding.............................................................................................................3-13
3.2.6 Port Identification.................................................................................................................................3-13
3.3 NAT...............................................................................................................................................................3-13
3.3.1 Introduction to NAT.............................................................................................................................3-14
3.3.2 NAT on the Eudemon..........................................................................................................................3-15
3.4 Authentication and Authorization.................................................................................................................3-21
3.4.1 Introduction to Authentication and Authorization...............................................................................3-22
3.4.2 Introduction to RADIUS Protocol........................................................................................................3-23
3.4.3 Introduction to HWTACACS Protocol................................................................................................3-25
3.4.4 Introduction to Domain........................................................................................................................3-26
3.4.5 Introduction to Local User Management..............................................................................................3-26
3.5 P2P Traffic Limiting.....................................................................................................................................3-27
3.5.1 Introduction to P2P Traffic Limiting...................................................................................................3-27
3.5.2 P2P Traffic Detection and Limiting.....................................................................................................3-27
3.6 IP-CAR..........................................................................................................................................................3-28
3.7 TSM Cooperation..........................................................................................................................................3-28
3.7.1 Introduction to TSM Cooperation........................................................................................................3-29
3.7.2 Work Flow of TSM Cooperation.........................................................................................................3-30
3.7.3 Specifications of TSM Cooperation.....................................................................................................3-31
3.8 SLB................................................................................................................................................................3-31
3.8.1 Introduction to SLB..............................................................................................................................3-31
3.8.2 Virtual Service Technology.................................................................................................................3-32
3.8.3 Server Health Check.............................................................................................................................3-33
3.8.4 Traffic-based Forwarding.....................................................................................................................3-33
4 Internetworking..........................................................................................................................4-1
4.1 VLAN..............................................................................................................................................................4-2
4.1.1 Introduction............................................................................................................................................4-2
4.1.2 Advantages of VLAN.............................................................................................................................4-3
4.2 PPP..................................................................................................................................................................4-4
4.2.1 Introduction............................................................................................................................................4-4
4.2.2 PPP Authentication................................................................................................................................4-5
4.2.3 PPP Link Operation................................................................................................................................4-6
4.3 PPPoE..............................................................................................................................................................4-9
4.3.1 Introduction............................................................................................................................................4-9
4.3.2 PPPoE Discovery Period......................................................................................................................4-10
ii Huawei Proprietary and Confidential Issue 01 (2009-12-25)

4.3.3 PPPoE Session Period..........................................................................................................................4-12

4.4 DHCP............................................................................................................................................................4-12
4.4.1 DHCP Service......................................................................................................................................4-12
4.4.2 DHCP Relay.........................................................................................................................................4-13
4.4.3 DHCP client.........................................................................................................................................4-14
4.5 IP Static Route...............................................................................................................................................4-16
4.5.1 Static Route..........................................................................................................................................4-16
4.5.2 Default Route.......................................................................................................................................4-18
4.6 RIP.................................................................................................................................................................4-18
4.6.1 RIP Overview.......................................................................................................................................4-18
4.6.2 RIP Versions........................................................................................................................................4-19
4.6.3 RIP Startup and Operation...................................................................................................................4-19
4.7 OSPF.............................................................................................................................................................4-20
4.7.1 OSPF Overview....................................................................................................................................4-20
4.7.2 Process of OSPF Route Calculation.....................................................................................................4-20
4.7.3 Basic Concepts Related to OSPF.........................................................................................................4-21
4.7.4 OSPF Packets.......................................................................................................................................4-22
4.7.5 Types of OSPF LSAs...........................................................................................................................4-23
4.8 Introduction to Policy-Based Routing...........................................................................................................4-24
4.9 QoS................................................................................................................................................................4-24
4.9.1 QoS Overview......................................................................................................................................4-24
4.9.2 Traditional Packets Transmission Application....................................................................................4-24
4.9.3 New Application Requirements...........................................................................................................4-25
4.9.4 Congestion Causes, Impact and Countermeasures...............................................................................4-25
4.9.5 Traffic Control Techniques..................................................................................................................4-27
5 VPN...............................................................................................................................................5-1
5.1 Introduction.....................................................................................................................................................5-3
5.1.1 VPN Overview.......................................................................................................................................5-3
5.1.2 Basic VPN Technology..........................................................................................................................5-4
5.1.3 VPN Classification.................................................................................................................................5-7
5.2 L2TP................................................................................................................................................................5-8
5.2.1 VPDN Overview....................................................................................................................................5-8
5.2.2 L2TP Overview......................................................................................................................................5-9
5.3 IPSec..............................................................................................................................................................5-15
5.3.1 IPSec Overview....................................................................................................................................5-15
5.3.2 IKE Overview......................................................................................................................................5-16
5.3.3 IPSec Basic Concepts...........................................................................................................................5-19
5.3.4 NAT Traversal of IPSec.......................................................................................................................5-21
5.3.5 CA Authentication................................................................................................................................5-22
5.3.6 Realizing IPSec on the Eudemon.........................................................................................................5-25
5.4 GRE...............................................................................................................................................................5-27
5.4.1 GRE Overview.....................................................................................................................................5-27
Issue 01 (2009-12-25) Huawei Proprietary and Confidential iii

Contents Feature Description
5.4.2 Implementation of GRE.......................................................................................................................5-27

5.4.3 GRE Application..................................................................................................................................5-29
5.5 SSL VPN.......................................................................................................................................................5-30
5.5.1 Introduction to SSL..............................................................................................................................5-31
5.5.2 SSL VPN Service.................................................................................................................................5-32
5.6 BGP/MPLS IP VPN......................................................................................................................................5-33
5.6.1 BGP Overview.....................................................................................................................................5-33
5.6.2 MPLS Overview...................................................................................................................................5-37
5.6.3 LDP Overview......................................................................................................................................5-42
5.6.4 BGP /MPLS IP VPN Introduction.......................................................................................................5-45
6 Intrusion Detection....................................................................................................................6-1
6.1 Identification of Protocols Using Nonstandard Ports......................................................................................6-2
6.1.1 Overview................................................................................................................................................6-2
6.1.2 Supported Protocol Types......................................................................................................................6-2
6.1.3 Working Principles.................................................................................................................................6-3
6.2 Protocol Detection...........................................................................................................................................6-3
6.2.1 Overview................................................................................................................................................6-4
6.2.2 DNS Protocol Detection.........................................................................................................................6-5
6.2.3 HTTP Detection..................................................................................................................................... 6-5
6.2.4 FTP Detection........................................................................................................................................ 6-7
6.2.5 SMTP Detection.....................................................................................................................................6-9
6.2.6 IMAP/POP3 Detection.........................................................................................................................6-10
6.3 IPS Detection.................................................................................................................................................6-12
6.3.1 Overview..............................................................................................................................................6-12
6.3.2 Working Principles...............................................................................................................................6-13
6.3.3 IPS Rule................................................................................................................................................6-14
6.3.4 Upgrade of the IPS Rule.......................................................................................................................6-15
7 Surfing Behavior Management...............................................................................................7-1

7.1 Overview.........................................................................................................................................................7-2
7.2 Type.................................................................................................................................................................7-2
7.2.1 IM Management.....................................................................................................................................7-2
7.2.2 P2P Traffic Identification and Control...................................................................................................7-3
7.2.3 Game Identification and Control............................................................................................................7-4
7.2.4 Stock Identification and Control............................................................................................................7-4
7.3 Working Principles..........................................................................................................................................7-4
7.3.1 Working Principle of the IM Management............................................................................................7-4
7.3.2 Working Principle of the Management of P2P/Game/Stock................................................................. 7-5
8 Mail Filtering..............................................................................................................................8-1
8.1 Overview.........................................................................................................................................................8-2
8.2 Concept............................................................................................................................................................8-2
8.3 Working Principles..........................................................................................................................................8-3
iv Huawei Proprietary and Confidential Issue 01 (2009-12-25)

9 Reliability....................................................................................................................................9-1
9.1 VRRP Overview..............................................................................................................................................9-2
9.1.1 Introduction to the Traditional VRRP Protocol.....................................................................................9-2
9.1.2 Traditional VRRP on Eudemon Backup................................................................................................9-4
9.2 VGMP Overview.............................................................................................................................................9-6
9.2.1 VRRP Management Group Overview....................................................................................................9-6
9.2.2 Protocol Hierarchical Relation Between VRRP Management Groups and Backup Groups.................9-7
9.2.3 Functions of the VRRP Management Group.........................................................................................9-7
9.2.4 Relation Among a VRRP Management Group, Backup Group, and Interface......................................9-9
9.2.5 Backup Mode Classification................................................................................................................9-11
9.3 Introduction to Dual-System Hot Backup.....................................................................................................9-16
9.3.1 HRP Application..................................................................................................................................9-16
9.3.2 Master/Slave Configuration Device.....................................................................................................9-17
9.4 Hierarchical Protocol Relation Between VRRP Backup Group, Management Group, and HRP.................9-17
9.5 Checking the Configuration Consistency......................................................................................................9-18
9.6 IP-Link Auto-detection Overview.................................................................................................................9-19
A Glossary.....................................................................................................................................A-1
B Acronyms and Abbreviations.................................................................................................B-1
Issue 01 (2009-12-25) Huawei Proprietary and Confidential v

Feature Description Figures
Figures
Figure 2-1 Networking diagram in route mode....................................................................................................2-2

Figure 2-2 Networking diagram in transparent mode..........................................................................................2-3
Figure 2-3 Networking diagram in composite mode............................................................................................2-4
Figure 2-4 Broadcasting a data packet.................................................................................................................2-5
Figure 2-5 Reversely learning the relationship between the MAC address of workstation A and the interface
...............................................................................................................................................................................2-6
Figure 2-6 Reversely learning the relationship between the MAC address of workstation B and the interface
...............................................................................................................................................................................2-7
Figure 2-7 Forwarding the frame after successfully obtaining corresponding information from the address table
...............................................................................................................................................................................2-8
Figure 2-8 Filtering frames after successfully obtaining corresponding information from the address table
...............................................................................................................................................................................2-9
Figure 2-9 Forwarding the frame after failing to obtain corresponding information from the address table......2-9
Figure 2-10 Relationship between interfaces, networks, and security zones.....................................................2-12
Figure 3-1 Basic process of address translation.................................................................................................3-14
Figure 3-2 Basic principle of NAPT..................................................................................................................3-17
Figure 3-3 Networking diagram of configuring inbound NAT..........................................................................3-20
Figure 3-4 Networking diagram of NAT within the zone..................................................................................3-20
Figure 3-5 Networking diagram of destination NAT.........................................................................................3-21
Figure 3-6 Message flow between RADIUS client and server..........................................................................3-24
Figure 3-7 RADIUS message structure..............................................................................................................3-24
Figure 3-8 Networking diagram of TSM Cooperation.......................................................................................3-29
Figure 3-9 Schematic diagram of Virtual Service..............................................................................................3-32
Figure 4-1 Example of VLAN..............................................................................................................................4-3
Figure 4-2 Operation process of PPP...................................................................................................................4-7
Figure 4-3 Diagram of the host sending PADI packets in broadcast.................................................................4-10
Figure 4-4 Sending the PADO packet from the server.......................................................................................4-11
Figure 4-5 Diagram of the host choosing a server and sending a PADR packet...............................................4-11
Figure 4-6 Diagram of the server sending a PADS packet to the host...............................................................4-11
Figure 4-7 DHCP relay.......................................................................................................................................4-14
Figure 4-8 Area and route summary...................................................................................................................4-22
Figure 4-9 Schematic diagram of traffic congestion..........................................................................................4-26
Figure 5-1 Networking diagram of VPN applications.........................................................................................5-4
Figure 5-2 Networking diagram of a VPN access................................................................................................5-5
Issue 01 (2009-12-25) Huawei Proprietary and Confidential vii

Figures Feature Description
Figure 5-3 Networking diagram of VPDN application based on L2TP.............................................................5-10

Figure 5-4 L2TP protocol structure....................................................................................................................5-10
Figure 5-5 Two typical L2TP tunnel modes......................................................................................................5-12
Figure 5-6 Typical networking diagram of L2TP..............................................................................................5-12
Figure 5-7 Procedure for setting up an L2TP call..............................................................................................5-13
Figure 5-8 Relationship of IKE and IPSec.........................................................................................................5-17
Figure 5-9 Procedure for setting up an SA.........................................................................................................5-18
Figure 5-10 Data encapsulation format for security protocols...........................................................................5-20
Figure 5-11 Constitute of PKI system................................................................................................................5-23
Figure 5-12 IP network interconnection through the GRE tunnel.....................................................................5-28
Figure 5-13 Format of the encapsulated packet.................................................................................................5-28
Figure 5-14 IP packet transported in the tunnel.................................................................................................5-29
Figure 5-15 Network enlargement.....................................................................................................................5-29
Figure 5-16 Inconsistent subnet connection.......................................................................................................5-30
Figure 5-17 GRE-IPSec tunnel...........................................................................................................................5-30
Figure 5-18 Label encapsulation structure.........................................................................................................5-38
Figure 5-19 Encapsulation location of label in packet.......................................................................................5-38
Figure 5-20 MPLS Network Structure...............................................................................................................5-39
Figure 5-21 LSP tunnel......................................................................................................................................5-41
Figure 5-22 Label distribution process...............................................................................................................5-43
Figure 5-23 BGP/MPLS IP VPN model............................................................................................................5-46
Figure 5-24 Schematic diagram of a VPN-instance...........................................................................................5-48
Figure 5-25 VPN-IPv4 address structure...........................................................................................................5-48
Figure 5-26 BGP ASN substitute application....................................................................................................5-51
Figure 5-27 Diagram of forwarding VPN packets.............................................................................................5-52
Figure 5-28 Basic VPN networking scheme......................................................................................................5-53
Figure 5-29 Extranet networking scheme...........................................................................................................5-53
Figure 5-30 Application of OSPF in VPN.........................................................................................................5-54
Figure 5-31 DN bit in the LSA Options field.....................................................................................................5-55
Figure 5-32 Sham link application.....................................................................................................................5-56
Figure 6-1 Working principle of the HTTP detection..........................................................................................6-6
Figure 6-2 Working principle of the FTP detection.............................................................................................6-8
Figure 6-3 Working principle of the SMTP detection.........................................................................................6-9
Figure 6-4 Working principle of the IMAP/POP3 detection.............................................................................6-11
Figure 6-5 Working process of the application layer data detection..................................................................6-14
Figure 6-6 Automatic/manual upgrade diagram of the IPS rule........................................................................6-15
Figure 7-1 Working principle diagram of the IM management...........................................................................7-5
Figure 7-2 Working principle of the management of P2P/game/stock................................................................7-6
Figure 8-1 Principle diagram of mail filtering.....................................................................................................8-3
Figure 9-1 Networking diagram of adopting default route..................................................................................9-2
Figure 9-2 Networking diagram of adopting VRRP virtual router......................................................................9-3
Figure 9-3 Typical networking diagram of Eudemon backup..............................................................................9-4
viii Huawei Proprietary and Confidential Issue 01 (2009-12-25)

Feature Description Figures
Figure 9-4 Eudemon backup state........................................................................................................................9-5

Figure 9-5 Protocol hierarchical relation between VRRP management groups and backup groups................... 9-7
Figure 9-6 Data channel for transmitting VGMP packets....................................................................................9-9
Figure 9-7 Relation between a VRRP management group and a backup group................................................9-10
Figure 9-8 Networking diagram of Eudemons in master/backup mode.............................................................9-11
Figure 9-9 Networking diagram of simplified load balancing...........................................................................9-13
Figure 9-10 Networking diagram of complex load balancing............................................................................9-15
Figure 9-11 Data path in master/backup mode...................................................................................................9-16
Figure 9-12 Hierarchical protocol relation between VRRP backup group, management group, and HRP.......9-18
Issue 01 (2009-12-25) Huawei Proprietary and Confidential ix

Feature Description Tables
Tables
Table 3-1 Classification of the ACL.....................................................................................................................3-5

Table 3-2 Differences between HWTACACS and RADIUS.............................................................................3-25
Table 4-1 Values of the timers...........................................................................................................................4-16
Table 6-1 Response Policies.................................................................................................................................6-4
Table 6-2 Packet processing policies..................................................................................................................6-13
Table 7-1 Applications supported by the IM login control and audit.................................................................. 7-3
Table 8-1 Unknown-code processing policies......................................................................................................8-3
Table 8-2 Timeout processing policies.................................................................................................................8-3
Table 9-1 Device status in master/backup mode................................................................................................9-12
Table 9-2 Device status in simplified load balancing mode I............................................................................9-14
Table 9-3 Device states in simplified load balancing mode II...........................................................................9-14
Issue 01 (2009-12-25) Huawei Proprietary and Confidential xi

Feature Description About This Document
About This Document
Purpose
This document introduces the features of Quidway Eudemon 200E-B, including introduction,
introduction to the Eudemon, and the principles and applications of security features, network
interconnection features, VPN features, UTM features and reliability of the Eudemon.
This document describes the functions, principles, and features of the Eudemon.
Related Versions
The following table lists the product versions related to this document.
Product Name Version
Quidway Eudemon 200E-B V100R002
Intended Audience
This document is intended for:
l Technical support engineer
l Network engineers
l Network administrators
l Network maintenance engineers
Organization
This document is organized as follows.
Issue 01 (2009-12-25) Huawei Proprietary and Confidential 1

About This Document Feature Description
Chapter Description
1 Overview Describes network security, classification and implementation

methods of network security service, firewall system,
Eudemon product, location of the Eudemon in a network and the
functions of the Eudemon.
2 Introduction to the Describes the working modes, working process, and the security
Eudemon zones of the Eudemon.
3 Security Features Describes the security features of the Eudemon, including ACL,
packet filter, attack defense, ASPF, blacklist, MAC and IP
address binding, port identification, NAT, IP-CAR, P2P traffic
limiting, IM blocking, TSM cooperation, SLB, authentication
and authorization.
4 Internetworking This section describes the network interconnection features of

the Eudemon. including VLAN, PPP, PPPoE, DHCP, IP static
route, RIP, OSPF, policy-based routing and Qos.
5 VPN Describes the VPN features of the Eudemon, including L2TP,

IPSec, GRE, SSL VPN, and BGP/MPLS IP VPN.
6 Intrusion Detection Describes the intrusion detection features of the Eudemon.
7 Surfing Behavior Describes the surfing behavior management features of the

Management Eudemon.
8 Mail Filtering Describes the mail filtering features of the Eudemon.
9 Reliability Describes VRRP, VGMP, HRP, and the implementation of dual-

system hot backup on the Eudemon. In addition, describes the
principle and function of IP-Link auto detection.
A Glossary Lists the glossaries used in this document.
B Acronyms and Lists the acronyms and abbreviations used in this document.
Abbreviations
Conventions
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates a hazard with a high level of risk, which if not avoided,

will result in death or serious injury.
DANGER
2 Huawei Proprietary and Confidential Issue 01 (2009-12-25)

Symbol Description
Indicates a hazard with a medium or low level of risk, which if

not avoided, could result in minor or moderate injury.
WARNING
Indicates a potentially hazardous situation, which if not avoided,

could result in equipment damage, data loss, performance
CAUTION
degradation, or unexpected results.
TIP Indicates a tip that may help you solve a problem or save time.
NOTE Provides additional information to emphasize or supplement

important points of the main text.
General Conventions
The general conventions that may be found in this document are defined as follows.
Convention Description
Times New Roman Normal paragraphs are in Times New Roman.
Boldface Names of files, directories, folders, and users are in boldface.

For example, log in as user root.
Italic Book titles are in italics.

Courier New Examples of information displayed on the screen are in
Courier New.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by vertical

bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by vertical

bars. One item is selected or no item is selected.
{ x | y | ... } * Optional items are grouped in braces and separated by vertical

bars. A minimum of one item or a maximum of all items can be
selected.

About This Document Feature Description
[ x | y | ... ] * Optional items are grouped in brackets and separated by vertical

bars. Several items or no item can be selected.
GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
Boldface Buttons, menus, parameters, tabs, window, and dialog titles are
in boldface. For example, click OK.
> Multi-level menus are in boldface and separated by the ">" signs.
For example, choose File > Create > Folder.
Keyboard Operations
The keyboard operations that may be found in this document are defined as follows.
Format Description
Key Press the key. For example, press Enter and press Tab.
Key 1+Key 2 Press the keys concurrently. For example, pressing Ctrl+Alt
+A means the three keys should be pressed concurrently.
Key 1, Key 2 Press the keys in turn. For example, pressing Alt, A means the
two keys should be pressed in turn.
Mouse Operations
The mouse operations that may be found in this document are defined as follows.
Action Description
Click Select and release the primary mouse button without moving the
pointer.
Double-click Press the primary mouse button twice continuously and quickly
without moving the pointer.
Drag Press and hold the primary mouse button and move the pointer
to a certain position.
4 Huawei Proprietary and Confidential Issue 01 (2009-12-25)

Update History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Updates in Issue 01 (2009-12-25)

Initial commercial release.

Feature Description 1 Overview
1 Overview
About This Chapter
This describes network security threats, types and implementation methods of network security
services, and importance, development history, advantages, functions, and locations on networks
of firewalls.
1.1 Introduction to the Product
Quidway Eudemon 200E-B (hereinafter referred to as the Eudemon) is a cost-effective security
defense product developed mainly for small and medium-sized enterprises. The Eudemon
provides security services, such as defense against attacks, secure access, encryption,
authentication, access control, route management, traffic management, backup management and
so on, to construct secure IT platforms for enterprises.
1.2 Introduction to Network Security
Currently, more and more enterprises begin to speed up their development through network
services. Enterprises are increasingly concerned about how to safeguard their confidential data
and resources in an open network application environment. Network security already becomes
a factor that cannot be ignored in network construction.
1.3 Introduction to Firewall
Similar to a partition wall used to prevent fire from spreading in a building, a firewall is a system
that implements one or a group of access control policies. A firewall can monitor the access
channels between the Trust zone (an internal network) and the Untrust zone (an external
network), preventing external hazard from damaging the internal network.
1.4 Functions and Features
The Eudemon supports such features as security defense, internetworking, service applications,
configuration management, maintenance, reliability, and system logs.
1.5 Location of the Eudemon
Typically, the Eudemon is deployed at the ingress of a protected zone to protect the zone based
on access control policies.
Issue 01 (2009-12-25) Huawei Proprietary and Confidential 1-1

1 Overview Feature Description
1.1 Introduction to the Product

Quidway Eudemon 200E-B (hereinafter referred to as the Eudemon) is a cost-effective security
defense product developed mainly for small and medium-sized enterprises. The Eudemon
provides security services, such as defense against attacks, secure access, encryption,
authentication, access control, route management, traffic management, backup management and
so on, to construct secure IT platforms for enterprises.
Enhanced Security Features

Compared with general operating system-based software firewalls, the Eudemon is more
excellent in system security. That is because the Eudemon adopts a specially designed hardware
platform and owning the complete intellectual property rights of secure operating system. The
separation of packet process and operating system transaction greatly increases system security
feature.
With the ASPF state inspection technology, the Eudemon can:
l Monitor the connection process and application layer protocol information.
l Cooperate with ACLs to implement packet filtering.
l Provide a wide range of attack defense functions.
All these features help the Eudemon effectively protect networks.
High-speed Processing Capability

The Eudemon adopts high-speed algorithms and optimized software structure, which effectively
ensure the performance of the system.
High Reliability
Software design takes the details of each type of attack into consideration. Multiple measures
such as priority scheduling and flow control are taken to endure system robustness.
The Eudemon supports dual-system state hot backup, which ensures service continuity during
switchover. In addition, the Eudemon supports dual-system hot backup load balancing, which
helps automatically switch traffic in case of a fault.
Powerful Networking and Service Supporting Capability

With integrated high speed Ethernet interfaces, the Eudemon supports a wide range of protocols,
such as:
l H.323
l File Transfer Protocol (FTP)
l Simple Mail Transfer Protocol (SMTP)
In addition, the Eudemon has the following features:

l Detection on malicious Java Applets and ActiveX
l Network Address Translation (NAT) application
l Static and dynamic blacklist filtering
1-2 Huawei Proprietary and Confidential Issue 01 (2009-12-25)

l Proxy-based SYN Flood defense
Besides diversified security defense functions and effective protection capabilities, the
Eudemon is integrated with certain routing capabilities:
l Static routing
l Routing Information Protocol (RIP) dynamic routing
l Open Shortest Path First (OSPF) dynamic routing
The Eudemon supports three working modes:

l Route mode
l Transparent mode
l Composite mode
The transparent mode allows you to directly add a firewall without changing the original network
configuration. That simplifies the networking process.
Friendly Graphical Configuration and Management Capability

The Eudemon provides Web management interfaces, through which you can configure and
manage the Eudemon.
Powerful Log and Statistics Function

Based on powerful log and statistics function, the Eudemon effectively helps implement security
analysis and event tracing.
1.2 Introduction to Network Security

Currently, more and more enterprises begin to speed up their development through network
services. Enterprises are increasingly concerned about how to safeguard their confidential data
and resources in an open network application environment. Network security already becomes
a factor that cannot be ignored in network construction.
1.2.1 Security Threats
At present, common security threats on Internet can be categorized into the following types:
unauthorized access, Denial of Service (DoS), information sniffing and data juggle.
1.2.2 Network Security Service Classification
Network security services are a set of security measures taken against security threats, including
availability services, confidentiality services, integrity services, verification service, and
authorization service.
1.2.3 Implementation Methods
Common network security services are carried out through encryption, authentication, access
control, and security protocols.
1.2.1 Security Threats

At present, common security threats on Internet can be categorized into the following types:
unauthorized access, Denial of Service (DoS), information sniffing and data juggle.
These four types of security threats are represented as follows:

l Unauthorized access
Resources are accessed by unauthorized users (illegal users) or in unauthorized manner
(exploiting behavior).
For example, an intruder may attempt to access a system and exploit resources by guessing
an account and a password.
l Denial of Service
A server denies legal users' requests for accessing data or resources.
For example, attackers can overload a server with a large number of request packets, thus
preventing the server from processing legal tasks.
l Information sniffing
Attackers do not directly access a destination system. Instead, they obtain critical data and
information by sniffing networks.
l Data juggle
Attackers damage data integrity by purposely modifying, deleting, delaying, or reordering
system data or message stream, or inserting fraud messages.
1.2.2 Network Security Service Classification

Network security services are a set of security measures taken against security threats, including
availability services, confidentiality services, integrity services, verification service, and
authorization service.
Details of network security services are as follows:
l Availability service
Ensure that information or services are accessible when required.
l Confidentiality service
Ensure that sensitive data or information is not disclosed or exposed to an unauthorized
entity.
l Integrality service
Ensure that data can be modified or destroyed with permission.
l Verification service
Ensure the legality of an entity ID.
l Authorization service
Protect system resources by controlling access permissions.
1.2.3 Implementation Methods

Common network security services are carried out through encryption, authentication, access
control, and security protocols.
Encryption
Encryption is a process where a readable message is translated to an unreadable encrypted
message. Encryption not only ensures communication security, but also functions as the basis
of other security mechanisms.
Encryption can be applied in the following mechanisms:

l Authentication password design

l Security communication protocol design
l Digital signature design
There are three types of encryption methods:
l Symmetric password mechanism

For symmetric password mechanism, keys for encryption and decryption are identical. A
pair of users use the same password to exchange message. The keys must be private.
The typical encryption standards are Data Encryption Standard (DES) and Triple DES
(3DES).
l Public key password mechanism
Different from symmetric password mechanism, public key password mechanism uses
different security keys for encryption and decryption. One key acts as the private key, which
should be kept confidentially. The other acts as the public key, which can be distributed
publicly.
The typical encryption standards are Diffie-Hellman (DH) and Rivest, Shamir, Adleman
(RSA).
l Hash function
Hash function is used to compress a variable-length message into a fixed-length code, and
then the message becomes a hashing line or message abstract.
Hash functions include Message Digest 5 (MD5) and Secure Hash Algorithm (SHA).
Authentication
Authentication is used to verify the legality of user IDs when they attempt to access networks
or services.
Authentication can be implemented by each local device on the network or by a dedicated

authentication server. A dedicated authentication server provides more excellent authentication
process in terms of flexibility, controllability, and expandability.
For heterogeneous networks, the Remote Access Dial-In User Service (RADIUS), an open
standard, is widely used in authentication services.
Access Control
Access control is an enhanced authorization method. There are two types of access control:
l Operating system-based access control

When users attempt to access a system resource, an authorization transaction specifies
which resources are available up to their privileges. Access control policies can be set based
on user IDs, groups, or rules.
l Network-based access control
Network-based access control limits the access permission of access networks. Compared
with operating system-based access control, network-based access control mechanism is
much more complex. Typically, access control components (such as firewalls) are
configured on some intermediate points between a requester and a destination to implement
access control.

Security Protocol
Network security protocols are an important part of network security. Following describes
widely used security protocols based on the TCP/IP layered model:
l Application layer security protocols
They provide end-to-end protection for applications on hosts connected through networks.
Application layer security mechanism depends on specific applications. An application
layer security protocol is a supplement of an application protocol. Therefore, there is no
general application layer security protocol.
l Transport layer security protocols
They provide security services for processes of one host or several hosts. Transport layer
security mechanism functions based on the security of Inter-Process Communication (IPC)
interface and applications.
Providing security services at the transport layer is to strengthen the IPC interface, such as
Berkeley Software Distribution (BSD) socket. The following are specific process methods:
– Two-end entity authentication
– Exchange of data encrypted keys
Based on this idea, Secure Socket Layer (SSL) is developed on the basis of reliable
transmission service.
l Network layer security protocols
Even if no security mechanism is implemented at the upper layer, network layer security
protocols can still ensure the security of user information. IP security is the basis of the
whole TCP/IP security and the core of Internet security.
At present, the most important security protocol at the network layer is the IP Security
Protocol (IPSec). IPSec is a generic term for a series of network security protocols,
including security protocols and encryption protocols.
IPSec can provide communication parties with the following services:
– Access control
– Connectionless integrality
– Data source authentication
– Anti-replay
– Encryption
– Classified data stream encryption
l Data link layer security protocols
They provide point-to-point security services. Data link layer security mechanism is
implemented by a dedicated devices to perform encryption and decryption at each end of
a link.
1.3 Introduction to Firewall

Similar to a partition wall used to prevent fire from spreading in a building, a firewall is a system
that implements one or a group of access control policies. A firewall can monitor the access
channels between the Trust zone (an internal network) and the Untrust zone (an external
network), preventing external hazard from damaging the internal network.
1.3.1 First Safeguard

In a security defense system, firewalls are usually the first line of defense against most of the
external attacks.
1.3.2 Development of Firewalls
Up to now, there have been three generations of firewalls. The first generation firewalls are
packet-filtering firewalls, the second generation proxy firewalls, and the third generation stateful
firewalls.
1.3.1 First Safeguard

In a security defense system, firewalls are usually the first line of defense against most of the
external attacks.
In actual practice, a single security defense technology can hardly establish a secure network
system. The combined application of multiple technologies can effectively limit security hazard
to the least level. Typically, the first step to implement security defense is to construct a barrier,
namely a firewall, between an internal network and external networks to defend against most
external attacks.
A firewall is mainly used to:
l Prevent users or information from entering through a strictly controlled site.

l Prevent intruders from approaching other security defense facilities.
l Prevent users or information from exiting from a strictly controlled site.
1.3.2 Development of Firewalls

Up to now, there have been three generations of firewalls. The first generation firewalls are
packet-filtering firewalls, the second generation proxy firewalls, and the third generation stateful
firewalls.
First Generation Firewall—Packet-Filtering Firewall

Packet filtering is to check each packet at network layer, and then to forward or discard packets
based on the security policy.
The basic working principle of a packet filtering firewall is that it filters packets based on the
configured access control lists (ACLs). Be specific, a firewall matches information contained
in a packet such as the source and destination IP address, the source and destination port number,
IP identifier, and packet delivery direction with ACL entries.
The first generation of firewalls features simple design, easy implementation, and low price.
However, its disadvantages are also obvious:
l As the complexity and length of ACLs increase, its filtering performance degrades
exponentially.
l Static ACL rules can hardly meet dynamic security demands.
l The packet filtering mechanism neither checks session state nor analyzes data. Thus, it
cannot filter packets based on user levels. That may be exploited by hackers. For example,
attackers may spoof a firewall by disguising their IP addresses as supposedly legal ones,
which can easily pass through a filter.

Second Generation Firewall—Proxy Firewall

Proxy service functions at the application layer. In essence, a proxy takes over the services
between internal network users and external network users. The working principle is that the
proxy first checks the request from a user, if the authentication is passed, the proxy establishes
a connection with a genuine server and forwards the request, and then it sends the response to
the user.
A proxy firewall can provide more effective protection for networks and users because it can
completely control network information exchange and session process.
However, it has disadvantages in the following aspects:
l Low processing speed due to software restriction, and prone to DoS attacks
l Hard to implement upgrade because protocol-specific application layer proxy is required
Third Generation Firewall—Stateful Firewall

The stateful analysis technology is an extension of packet filtering technology. When checking
packets, packet filtering based on connection state not only treats each packet as an independent
unit, but also considers its history association.
The basic working principle of a stateful firewall is as follows:
l The stateful firewall uses various status tables to trace activated the Transmission Control
Protocol (TCP) sessions and the User Datagram Protocol (UDP) pseudo sessions. Then the
ACLs determine which sessions can be set up. Only those packets that are related to the
permitted sessions can be forwarded.
NOTE
A UDP pseudo-session is a session process during which a virtual connection is set up to process UDP-
based protocol packets and monitor the status of the UDP connection process.
l The stateful firewall can capture packets at the network layer. Then the firewall extracts
state information required by the security policies from the application layer, and keeps it
in the dynamic status tables. By analyzing the status tables and subsequent connection
requests related to the packets, the firewall determines whether to forward the packets or
not.
For external networks, a stateful firewall acts as a proxy system, and all outward service requests
seemingly come from the same host.
For internal networks, a stateful firewall acts as a packet-filtering system, all internal users
seemingly directly communicate with external networks.
A stateful firewall features:
l High speed
A stateful firewall can record packet connection state while performing ACL check on
packets. Therefore, when subsequent packets reach the firewall, it checks the connection
record according to the status table without performing ACL check. If these packets pass
through the check, the firewall refreshes the connection record. In this case, packets with
the same connection status are not checked. Different from the fixed arrangement of ACLs,
the records in the connection status table can be arranged randomly. The firewall can
quickly search the records using algorithms such as binary tree or hash, thus improving the
transmission efficiency of the system.

l Higher security
Connection status tables are managed dynamically. When a session is over, the temporary
return packet entry created on the firewall is closed immediately, thus ensuring the security
of internal networks in real time. In addition, with the real-time connection status
monitoring technology, a stateful firewall can identify the connection status elements in
the status table. That effectively enhances the system security.
1.4 Functions and Features

The Eudemon supports such features as security defense, internetworking, service applications,
configuration management, maintenance, reliability, and system logs.
1.4.1 Security Defense
This describes the working modes, packet filtering, and network address translation (NAT)
related to security defense.
1.4.2 Network Interconnection
This describes the link layer protocols, IP services, routing features, and some other functions
related to internetworking of the Eudemon.
1.4.3 Service Application
This describes service applications of authorization, authentication, and accounting (AAA),
virtual private network (VPN), and quality of service (QoS).
1.4.4 Unified Threat Management
The Eudemon provides powerful Unified Threat Management (UTM) capability.
1.4.5 Configuration Management
This configuration management function involves configurations of command line interfaces,
system management, and terminal services.
1.4.6 Maintenance and Reliability
The maintenance and reliability function involves reliability, system management, and alarm
management.
1.4.7 System Log
This describes the system log function.
1.4.1 Security Defense

This describes the working modes, packet filtering, and network address translation (NAT)
related to security defense.
Working Mode
The Eudemon supports the following working modes:
l Route mode
l Transparent mode
l Composite mode
Packet Filtering
The following describes the packet filtering of the Eudemon:

l Supports basic ACLs, advanced ACLs, and MAC-address-based ACLs.

l Supports time range-based ACLs.
l Supports the ACLs that quote the address set and port set.
l Supports blacklist.
l Supports MAC-IP addresses binding.
l Supports ASPF and state inspection.
l Provides port mapping mechanism.
NAT
The following describes the NAT of the Eudemon:
l Supports address translation (NAT and NAPT).

l Supports address translation based on address pool.
l Supports address translation control based on ACL.
l Supports address translation with the IP address of the interface.
l Supports the port-level NAT server.
l Supports address translation for packet fragmentation.
l Provides the internal server function.
l Supports security zone-based internal servers.
l Supports multiple NAT ALG (Application Level Gateway), including Domain Name
System (DNS), ESP, FTP, H.323, HWCC, Internet Control Message Protocol (ICMP), ILS,
MGCP, MMS, MSN, NetBIOS, Point-to-Point Tunneling Protocol (PPTP), QQ, RTSP,
SIP, SQL.NET, and user-defined.
Attack Defense
The Eudemon supports the following attack defense:
l Defends against multiple Denial of Service (DoS) attacks, such as SYN Flood, ICMP Flood,
UDP Flood, Fraggle, Smurf, WinNuke, IP Spoofing, ICMP redirection and unreachable
packet, and Land.
l Defends against scanning and snooping attacks, such as address sweeping, port scanning,
IP source routing option, IP routing record option, ICMP snooping packet, and time-stamp.
l Defends malformed packet attacks, such as TCP-flag attack, IP fragment attack, ping of
death attack, and teardrop attack.
l Defends ARP attacks, such as ARP spoofing attack, and ARP flood attack.
TSM Cooperation
The Eudemon can cooperate with TSM terminal security management systems to control users'
access to networks.
Traffic Monitoring
The following describes the traffic monitoring of the Eudemon:

l Supports the limit to connection rate and connection number based on the specific source
IP address, destination IP address, and inbound and outbound directions of the zone.
l Supports Committed Access Rate (CAR).
l Supports real time traffic statistics and attack packet statistics.
l Supports global statistics on IP packets and bandwidth management based on IP packet
types.
l Supports the P2P traffic limiting function.
l Supports the IM traffic blocking function.
1.4.2 Network Interconnection

This describes the link layer protocols, IP services, routing features, and some other functions
related to internetworking of the Eudemon.
Link Layer Protocol

The Eudemon supports the following link layer protocols:
l Ethernet
l Virtual Local Area Network (VLAN)
l Point-to-Point Protocol (PPP)
l Point-to-Point Protocol over Ethernet (PPPoE)
l High-level Data Link Control (HDLC)
IP Service
The Eudemon provides the following IP services:
l IP
l ICMP
l Tracert
l UDP
l TCP
l Socket
l Address Resolution Protocol (ARP)
l Ping
l Dynamic Host Configuration Protocol (DHCP) Relay, DHCP Client, DHCP Server
Routing Protocol
The Eudemon supports the following routing features:
l Static routing
l Dynamic routing such as RIP, OSPF
l Policy-based routing
l Route iteration, route policy, and route management

1.4.3 Service Application

This describes service applications of authorization, authentication, and accounting (AAA),
virtual private network (VPN), and quality of service (QoS).
AAA
The following describes the AAA service application of the Eudemon:
l Supports AAA, Remote Authentication Dial in User Service (RADIUS), and Huawei
Terminal Access Controller Access Control System (HWTACACS).
l Supports AAA domains.
l Supports local user management.
VPN
The following describes the VPN service application of the Eudemon:
l Supports L2TP VPN and GRE VPN.

l Supports IPSec/IKE, and provides encryption and authentication.
l Supports IPSec VPN.
l Supports SSL VPN.
l Supports BGP/MPLS IP VPN.
QoS
The following describes the QoS service application of the Eudemon:
l Supports congestion management.

l Supports FIFO, PQ, CQ, WFQ, CQC, CBWFQ, WRED, and CAR.
1.4.4 Unified Threat Management

The Eudemon provides powerful Unified Threat Management (UTM) capability.
The UTM of the Eudemon consists of the following:
IPS Function
With the Intrusion Prevention System (IPS) function, the Eudemon can detect both the quintuple
(source address, source port number, destination address, source port number, and protocol type)
and the payload of the application layer data. Thus, various vulnerability exploits can be
prevented, such as worm viruses, Trojan, Denial of Service (DoS) attacks, and code attacks.
The IPS rule file of the Eudemon saves the feature information on network attacks that are
identified. The Eudemon supports the intrusion defense through the IPS rule file to protect the
internal network. The IPS rule file is developed and maintained by Huawei. In addition, the IPS
rule file is periodically updated by Huawei. The latest version provides the latest feature
information.

Analysis and Abnormality Detection of Known Protocols

With the development of network applications, network security threats are not only from the
network layer, but also from the application layer, such as viruses, spam, and illegal contents on
Web pages. The Eudemon provides the protocol detection function, which can scan specified
sessions at the application layer. Thus, the key service system can be protected and application
layer attacks on the network can be prevented.
Protocol Identification of Nonstandard Ports

With the emergence of new network protocols and software, the limitation of the traditional
identification of packet protocol types based on ports becomes obvious. The Eudemon supports
the identification of both standard and nonstandard port protocols. For example, the Eudemon
automatically identifies the Hypertext Transfer Protocol (HTTP) service on port 8000. This
reduces false positive and false negative of application layer attacks.
Surfing Behavior Management

Currently, networks provide people with many entertainment functions, such as games, stock,
video, and instant messaging. The application of these entertainment functions, however,
reduces work efficiency during working hours. In addition, this also consumes a lot of the
enterprise network bandwidth, which may affect the operation of certain key services.
To diminish impacts of the entertainment functions, the Eudemon provides the surfing behavior
management function to control applications of QQ, MSN, Peer to Peer (P2P) traffic, stock, and
games by enterprise users.
Email Filtering
The email filtering function detects emails transferred through SMTP and identifies whether
they should be filtered or not. The Eudemon supports email filtering through the Real-time
Blackhole List (RBL).
1.4.5 Configuration Management

This configuration management function involves configurations of command line interfaces,
system management, and terminal services.
Command Line Interface

The following describes the command line interface of the Eudemon:
l Provides prompt and help information in both English and Chinese.

l Supports the hierarchical protection of command lines to prevent unauthorized users from
intruding the Eudemon.
l Provides detailed debugging information to help diagnose network faults.
l Provides network test tools, such as tracert and ping to quickly determine whether a
network is in a normal state.
System Management
The following describes the system management of the Eudemon:

l Uploads or downloads programs or configuration files through FTP.

l Uploads or downloads programs or configuration files through TFTP.
l Uploads programs through XModem.
Terminal Service
The following describes the terminal service of the Eudemon:
l Supports terminal services through the console interface.

l Supports terminal services through Telnet and Secure Shell (SSH).
l Supports the send function to facilitate communication between terminal users.
l Supports management and configuration through the Web browser. For example:
– Provides login user information, version information, status of the running system and
log information.
– Provides GUI for displaying user information, backup information, configuration files,
system statistics information, log information, packet statistics, and session aging time.
– Provides GUI for configuring services such as FTP, SSH, interfaces, routes, areas, ACL,
valid period of the ACL, AAA certification, IP address pool, packet filtering rules, VPN,
NAT, ASPF, attack defense, P2P Traffic Limiting, and IP-MAC binding.
1.4.6 Maintenance and Reliability

The maintenance and reliability function involves reliability, system management, and alarm
management.
Reliability
The following describes the reliability of the Eudemon:
l Supports the Virtual Router Redundancy Protocol (VRRP).

l Supports the VRRP Group Management Protocol (VGMP).
l Supports the Huawei Redundancy Protocol (HRP) and dual-system hot backup.
l Supports IP-Link.
System Management
The following describes the system management of the Eudemon:
l Supports the standard network management protocol (SNMP) v1, v2c, v3.
l Supports private data file management.
l Supports private MIB management.
Alarm Management
The following describes the alarm management of the Eudemon:
l The fans is faulty.

l The power supply is faulty.

l The main board is faulty.

l The chip is faulty.
l The interruption is incorrectly reported.
l The PCI bus is faulty.
l Flash is faulty.
l The environment temperature or board temperature is out of the normal range.
l The key clocks are faulty.
1.4.7 System Log

This describes the system log function.
The following describes system log of the Eudemon:
l Provides the log server for browsing and querying log information.
l Provides input and output IP packets statistic, such logs as NAT logs, ASPF logs, attack
defense logs, blacklist logs, P2P traffic logs and P2P traffic detection logs, IM traffic logs
and IM traffic detection logs, history traffic logs, and real-time traffic logs.
1.5 Location of the Eudemon

Typically, the Eudemon is deployed at the ingress of a protected zone to protect the zone based
on access control policies.
For example:
l In the scenario where you need to protect an internal network and data against malicious
attacks or illegal access, such as unauthorized or unauthenticated access, you can deploy
the Eudemon at the connection point between an internal and external networks.
l In the scenario where you need to deny internal users access to sensitive data, you can
deploy the Eudemon at the connection point where a relatively open segment meets a
relatively sensitive one (such as a segment that keeps sensitive or private data).

Feature Description 2 Introduction to the Eudemon
2 Introduction to the Eudemon
About This Chapter
Before introducing the specific features of the Eudemon, this describes the working modes and
security zones of the Eudemon.
2.1 Working Mode
This describes the working modes of the Eudemon and the working process in each working
mode.
2.2 Security Zone
This describes the concept and division of security zones, the relationships between security
zones and interfaces and between security zones and networks, and the definition of the inbound
and outbound directions of data streams between security zones.

2 Introduction to the Eudemon Feature Description
2.1 Working Mode

This describes the working modes of the Eudemon and the working process in each working
mode.
2.1.1 Working Mode Classification
At present, the Eudemon can work in three working modes: route mode, transparent mode, and
composite mode.
2.1.2 Working Process in Route Mode
When the Eudemon works in route mode, external users connected with different Layer 3
interfaces belong to different subnets.
2.1.3 Working Process in Transparent Mode
In transparent mode (or bridge mode), interfaces on the Eudemon cannot be configured with IP
addresses and they reside in the layer 2 network. Moreover, external users connected with the
interfaces in the layer 2 network reside in the same subnet.
2.1.4 Working Process in Composite Mode
When the Eudemon works in composite mode, some interfaces should be configured with IP
addresses and some not. The interfaces configured with IP addresses reside in the layer 3
network, with VRRP enabled for dual-system hot backup. The interfaces not configured with
IP addresses reside in the layer 2 network. External users connected with the interfaces in the
layer 2 network belong to the same subnet.
2.1.1 Working Mode Classification

At present, the Eudemon can work in three working modes: route mode, transparent mode, and
composite mode.
Route Mode
In the scenario where the Eudemon is connected to external networks through Network Layer
(the interface is configured with an IP address), the Eudemon works in route mode.
When the Eudemon is deployed between an internal network and an external network, you need
to configure the Eudemon interfaces connecting respectively with the internal network and
external network with IP addresses in different segments. In addition, you need to replan the
network topology. The Eudemon fulfills the routing function in internal networks and external
networks. It functions as a router.
As shown in Figure 2-1, the Eudemon is connected to the internal network through an interface
segmented to the Trust zone, and connected to the external network through an interface
segmented to the Untrust zone. The two interfaces respectively in the Trust zone and the Untrust
zone are segmented to different subnets.
Figure 2-1 Networking diagram in route mode

PC PC PC
10.110.1.254/24 202.10.0.1/24
Eudemon Router
Server
Trust Untrust
Internal network External network
Server

When working in route mode, the Eudemon can implement functions such as ACL packet
filtering, ASPF dynamic filtering, and NAT. When you configure a Eudemon to work in route
mode, you need to change the topology of the existing network. For example, internal network
users need to change their gateway settings and the route configuration of the router should be
changed as well. Reconstructing a network is time and resource consuming. It is recommended
that you weigh the advantages and disadvantages in selecting this mode.
Transparent Mode
In the scenario where the Eudemon is connected to external networks through Data Link layer
(the interface is not configured with an IP address), the Eudemon works in transparent mode.
Letting the Eudemon to work in transparent mode saves you from the trouble in changing
network topology.
To adopt the transparent mode, you only need to deploy the Eudemon on the network just like
placing a bridge. That saves you from the trouble in changing any current configuration. Similar
to the transaction in route mode, the Eudemon checks and filters IP packets, protecting internal
users against threats.
Figure 2-2 shows a typical networking in transparent mode.
Figure 2-2 Networking diagram in transparent mode

PC PC PC
202.10.0.2/24 202.10.0.1/24
Router Router
Eudemon
Server Trust Untrust
Internal network External network Server
In transparent mode, the Eudemon can perform packet forwarding only. The two connected
networks must be in the same network segment. The Eudemon is connected with the internal
network through an interface in the Trust zone, and connected with the external network through
an interface in the Untrust zone.
Note that the internal network and external network should be in the same subnet.
Composite Mode
In the scenario where some interfaces of the Eudemon are configured with IP addresses while
some not, the Eudemon works in composite mode.
Typically, the composite mode is applied when you require dual-system hot backup based on
the transparent mode. In this case, you need to configure an IP address for the interface on which
VRRP is enabled. It is not necessary to configure IP addresses for the other interfaces.
Figure 2-3 shows a typical networking in composite mode.

Figure 2-3 Networking diagram in composite mode

Eudemon (Master)
PC
PC PC
VRRP
External network
Internal network
202.10.0.0/24
202.10.0.0/24
Untrust
Trust
Server
Server
Eudemon (Backup)
The master and backup Eudemon are connected with the internal network through interfaces of
the Trust zone, and connected with the external network through interfaces of the Untrust zone.
In addition, the master and backup Eudemons perform hot standby through VRRP.
Note that the internal network and the external network must reside in the same subnet.
2.1.2 Working Process in Route Mode

When the Eudemon works in route mode, external users connected with different Layer 3
interfaces belong to different subnets.
When packets are forwarded between the Layer 3 interfaces, the Eudemon acts as a router,
searching for routing entries based on IP addresses of the packets. Different from a router, the
Eudemon delivers the forwarded IP packets to the upper layer for filtering. The Eudemon
determines whether to allow the packets pass through or not according to session entries and
ACL rules. In addition, the Eudemon is also responsible for some other attack defense checks.
2.1.3 Working Process in Transparent Mode

In transparent mode (or bridge mode), interfaces on the Eudemon cannot be configured with IP
addresses and they reside in the layer 2 network. Moreover, external users connected with the
interfaces in the layer 2 network reside in the same subnet.
When packets are forwarded between interfaces in the layer 2 network, the Eudemon acts as a
transparent bridge, searching for outbound interfaces based on MAC addresses of the packets.
Different from a bridge, the Eudemon delivers the forwarded IP packets to the upper layer for
filtering. The Eudemon determines whether to permit the packets to pass through or not
according to session entries and ACL rules. In addition, the Eudemon is also responsible for
some other attack defense checks.
In transparent mode, the Eudemon is connected to a LAN at Data Link Layer; therefore, end
users do not need to perform special configurations on devices for connecting the networks (like
LAN Switch connection).

The working process in transparent mode has several phases, which are described in the
following sections:
l Obtaining an Address Table
l Forwarding or Filtering a Frame
Obtaining an Address Table

In transparent mode, the Eudemon forwards packets based on the MAC address table, which
consists of MAC addresses and interfaces. To forward packets, the Eudemon must obtain
information about the relationship between MAC addresses and interfaces.
In transparent mode, the process that the Eudemon obtain address table is as follows:
1. Broadcast a data packet.
When connected with a physical network segment, the transparent Eudemon monitors all
Ethernet frames on the physical network segment. Once it detects an Ethernet frame from
a certain interface, it extracts the source MAC address from the frame, and then adds the
relationship between the MAC address and the interface to the MAC address table. Figure
2-4 shows the process.
Figure 2-4 Broadcasting a data packet

00e0.fcaa.aaaa 00e0.fcbb.bbbb
Workstation A Workstation B
Destination Source
address address
00e0.fcbb.bbbb 00e0.fcaa.aaaa
Interface 1 Ethernet Segment 1
Eudemon
00e0.fccc.cccc 00e0.fcdd.dddd
Interface 2
Workstation C Workstation D
Ethernet Segment 2
Workstations A, B, C, and D reside in two LANs. Ethernet segments 1 and 2 are respectively
connected with interfaces 1 and 2 on the Eudemon. For example, when workstation A sends
an Ethernet frame to workstation B, both the transparent Eudemon and workstation B
receive the frame.
2. Reversely learn the relationship between the MAC address of workstation A and the
interface.
After receiving the Ethernet frame, the transparent Eudemon knows that workstation A is
connected with interface 1 on the Eudemon because interface 1 receives the frame. Then
the Eudemon adds the relationship between the MAC address of workstation A and
interface 1 of workstation A to the MAC address table. Figure 2-5 shows the process.

Figure 2-5 Reversely learning the relationship between the MAC address of workstation
A and the interface
Workstation A Workstation B
Destination Source
address address
00e0.fcbb.bbbb 00e0.fcaa.aaaa
Address table Ethernet Segment 1

MAC address Interface Interface 1
00e0.fcaa.aaaa 1
Eudemon
Interface 2
00e0.fccc.cccc 00e0.fcdd.dddd
Ethernet Segment 2
3. Reversely learn the relationship between the MAC address of workstation B and the
interface.
After workstation B responds to the Ethernet frame from workstation A, the transparent
Eudemon can detect the response Ethernet frame of workstation B. The transparent
Eudemon knows that it is connected with workstation B through interface 1, because
interface 1 receives the frame. Then the Eudemon adds the relationship between the MAC
address of workstation B and interface 1 to the MAC address table. Figure 2-6 shows the
process.

Figure 2-6 Reversely learning the relationship between the MAC address of workstation
B and the interface
Workstation B
Workstation A
Destination Source
address address
Address table Ethernet segment 1

MAC address Interface
00e0.fcaa.aaaa 1 Interface 1
00e0.fcbb.bbbb 1 Eudemon
Interface 2 00e0.fcdd.dddd
00e0.fccc.cccc Ethernet segment 2
The reverse learning process continues until the transparent Eudemon obtains all
relationship between MAC addresses and interfaces.
Forwarding or Filtering a Frame

At Data Link Layer, the transparent Eudemon processes a frame in the following situations:
l When the transparent Eudemon successfully obtains corresponding information from the
address table, it forwards the frame.
After workstation A sends an Ethernet frame to workstation C, the transparent Eudemon
searches the address table for the interface corresponding with workstation C. Then the
Eudemon forwards the frame through interface 2 according to the searching result. Figure
2-7 shows the process.

Figure 2-7 Forwarding the frame after successfully obtaining corresponding information
from the address table
00e0.fcaa.aaaa
Workstation A 00e0.fcbb.bbbb
Source Destination Workstation B

address address
00e0.fcaa.aaaa 00e0.fccc.cccc
Ethernet Segment 1
Address table
00e0.fcaa.aaaa 1
Eudemon
00e0.fcbb.bbbb 1
00e0.fcdd.dddd
00e0.fccc.cccc 2
Interface 2
00e0.fcdd.dddd 2
Workstation C Forwarding Workstation D
00e0.fccc.cccc
Destination Source Ethernet Segment 2
address address
00e0.fccc.cccc 00e0.fcaa.aaaa
If the transparent Eudemon receives a broadcast frame or multicast frame from a interface,
it forwards the frame to other interfaces.
l When the transparent Eudemon successfully obtains corresponding information from the
address table, it does not forward the frame.
If workstation A sends an Ethernet frame to workstation B, the Eudemon does not forward
but filter the frame. That is because workstations B and A reside in the same physical
network segment. Figure 2-8 shows the process.

Figure 2-8 Filtering frames after successfully obtaining corresponding information from
the address table
00e0.fcaa.aaaa
Workstation A 00e0.fcbb.bbbb
Workstation B
Source Destination
address address
Address table Ethernet segment 1

00e0.fcaa.aaaa 1
Eudemon
00e0.fcbb.bbbb 1
00e0.fccc.cccc 2
Interface 2
00e0.fcdd.dddd 2
00e0.fccc.cccc Not forwarding 00e0.fcdd.dddd
Ethernet segment 2
l When the transparent Eudemon fails to obtain corresponding information from the address
table, it forwards the frame.
When workstation A sends an Ethernet frame to workstation C and the Eudemon does not
obtain the relationship between the MAC address of workstation C and the interface from
the address table, the Eudemon forwards this frame to all the other interfaces but the source
interface of the frame. In this case, the Eudemon acts as a hub, ensuring the continuous
transfer of the frame. Figure 2-9 shows the process.
Figure 2-9 Forwarding the frame after failing to obtain corresponding information from
the address table
Workstation A
Workstation B
Source Destination
address address
00e0.fcaa.aaaa 00e0.fcccc.cccc
Address table Interface 1 Ethernet segment 1

MAC address Interface
Eudemon
00e0.fcaa.aaaa 1
00e0.fcdd.dddd
00e0.fcbb.bbbb 1
Workstation D
Interface 2
Workstation C
00e0.fccc.cccc
Ethernet segment 2

2.1.4 Working Process in Composite Mode

When the Eudemon works in composite mode, some interfaces should be configured with IP
addresses and some not. The interfaces configured with IP addresses reside in the layer 3
network, with VRRP enabled for dual-system hot backup. The interfaces not configured with
IP addresses reside in the layer 2 network. External users connected with the interfaces in the
layer 2 network belong to the same subnet.
When packets are forwarded between interfaces in the layer 2 network, the forwarding process
is the same as that in transparent mode. For details, see section "2.1.3 Working Process in
Transparent Mode". When packets are forwarded between interfaces in the layer 3 network,
the forwarding process is similar to that in route mode. For details, see section "2.1.2 Working
Process in Route Mode".
2.2 Security Zone

This describes the concept and division of security zones, the relationships between security
zones and interfaces and between security zones and networks, and the definition of the inbound
and outbound directions of data streams between security zones.
2.2.1 Introduction to Security Zone
Zone is a concept introduced for the Eudemon. That is a major feature distinguishing a
Eudemon from a router. A security zone includes one or several interfaces. In addition, a security
zone is configured with a security level.
2.2.2 Security Zones on the Eudemon
The Eudemon supports several security zones. Besides the predefined Local zone, Trust zone,
Untrust zone, and demilitarized zone (DMZ), the Eudemon supports user-defined security zones.
2.2.1 Introduction to Security Zone

Zone is a concept introduced for the Eudemon. That is a major feature distinguishing a
Eudemon from a router. A security zone includes one or several interfaces. In addition, a security
zone is configured with a security level.
For a router, all networks connected with the router interfaces are equal in security. That is, there
is no obvious difference between internal networks and external networks for a router. Security
check is performed on interfaces. When a data stream passes through a router in one way, it may
be checked twice on both the inbound interface and the outbound interface to be defined
separately on each interface. This check mechanism does not work well for a Eudemon, because
a Eudemon is deployed between an internal network and an external network to protect the
internal network against malicious users from the external network. Therefore, for a Eudemon,
there are internal networks and external networks.
When a data stream passes through the Eudemon, the Eudemon processes it according to its
direction. Because of the difference in security level, security policy check on an interface does
not apply any more. To avoid confusion in user configuration, the concept of security zone is
introduced in Eudemon design.
A security zone includes one or several interfaces. In addition, a security zone is configured with
a security level.
A security zone has the following features:

l The security level is denoted by an integer in the range of 1 to 100. The greater the number,
the higher the security level.
l The security level of each zone is unique.
The security rule check function is triggered only when data is transmitted between zones
(including interfaces) of different security levels. When data flows between different interfaces
of the same security zone, no check is triggered.
2.2.2 Security Zones on the Eudemon

The Eudemon supports several security zones. Besides the predefined Local zone, Trust zone,
Untrust zone, and demilitarized zone (DMZ), the Eudemon supports user-defined security zones.
Security Zone Classification

There are four default security zones on the Eudemon:
l Untrust zone
It is a low-level security zone, whose priority is 5.
l Demilitarized zone (DMZ)
It is a medium-level security zone, whose priority is 50.
l Trust zone
It is a high-level security zone, whose priority is 85.
l Local zone
It is a highest-level security zone, whose priority is 100.
These four zones are factory default configuration, which cannot be deleted or reconfigured.
You can create security zones and specify security levels for them according to the practical
requirements of networking. The Eudemon can support up to 16 security zones, including four
default security zones.
NOTE
l DMZ refers to an intermediate zone between a severely controlled military zone and an open public
zone.
l For the Eudemon, DMZ indicates a zone that is isolated from internal networks and external networks
both logically and physically. Devices such as a WWW server and FTP server are usually deployed in
this zone to provide external services.
l If the preceding servers are deployed on external networks, the Eudemon can hardly ensure their
security; if they are deployed on the internal network, malicious users may exploit the vulnerability of
certain services to attack the internal network. The introduction of DMZ successfully solves this
dilemma.
Relations Between Interfaces, Networks, and Security Zones
CAUTION
The security level of a zone should be unique. Thus, one interface cannot be segmented into two
security zones.

Relations between interfaces, networks and security zones are as follows:

l Relation between interfaces and security zones
A security zone includes one or several interfaces, whose security levels are the same.
Before using a security zone (excluding the Local zone), you need to associate the security
zone with a specific interface of the Eudemon by adding the interface to the security zone.
l Relation between networks and security zones
The relation between a security zones and a network complies with the following principle:
– Protected networks should be segmented to a security zone with a higher security level,
such as the Trust zone.
– External networks should be located in a low-level security zone, such as the Untrust
zone.
– Networks offering conditional services for the external users should be located in a
medium-level DMZ, such as the DMZ.
In addition, the Local zone has no interface. The Eudemon itself is the Local zone.
l Relation between interfaces, networks, and security zones
Figure 2-10 shows the relationship between interfaces, networks, and security zones.
Figure 2-10 Relationship between interfaces, networks, and security zones

Inbound
Outbound
Trust Eudemon
Eth0/0/0 Local
Eth1/0/0 External
Internal network network
VT0 Untrust
Outbound
Outbound
Inbound
Inbound
Server
Server
DMZ
Inbound and Outbound

Data streams between two security zones, that is, in an interzone, can travel in two directions:
l Inbound
Data flows from a low-level security zone to a high-level security zone.
l Outbound
Data flows from a high-level security zone to a low-level security zone.
When data flows between security zones of different security levels, security policy check is
triggered on the Eudemon. You can set different security policies for the two directions of the

same interzone. The direction of the data stream determines which security check policy is
triggered.
For the Eudemon, the transmission direction of data is determined by the higher security zone.
The directions of data streams are as follows:
l From the Local zone to the Trust zone is outbound direction while from the Trust zone to
the Local zone is inbound direction.
l From the Local zone to the DMZ is outbound direction while from the DMZ to the Local
zone is inbound direction.
l From the Local zone to the Untrust zone is outbound direction while from the Untrust zone
to the Local is inbound direction.
l From the Trust zone to the DMZ zone is outbound direction while from the DMZ to the
Trust zone is inbound direction.
l From the Trust zone to the Untrust zone is outbound direction while from the Untrust zone
to the Trust zone is inbound direction.
l From the DMZ to the Untrust zone is outbound direction while from the Untrust zone to
the DMZ is inbound direction.
NOTE
l If you allow users in high security zone to access external networks, you can configure a default
interzone packet-filtering rule for the Eudemon, allowing packets to travel from a high-level security
zone to a low-level security zone.
l For a router, the transmission direction of data is determined by the interface. Data streams sent from
an interface is called outbound data stream while data streams received by an interface are called
inbound data streams. That is another important difference between a router and a firewall.

Feature Description 3 Security Features
3 Security Features
About This Chapter
The Eudemon supports security features such as ACL, security policies, NAT, authentication,
and authorization.
3.1 ACL
This describes the definition, applications, settings, and steps of ACLs on the Eudemon.
3.2 Security Policy
The Eudemon supports various security policies, including packet filtering, attack defense,
ASPF, and Blacklist.
3.3 NAT
NAT is mainly used to help internal network users (private IP addresses) to access external
networks (public IP addresses), and provides the internal server function.
3.4 Authentication and Authorization
The Eudemon delivers the authentication and authorization functions to enable centralized
management of network security. The Eudemon supports local authentication, standard Remote
Authentication Dial-In User Service (RADIUS) authentication, Huawei RADIUS+
authentication, Huawei Terminal Access Controller Access Control System (HWTACACS)
authentication, and local user management. It can authenticate users and grant authorities to
legal users to prevent access by illegal users.
3.5 P2P Traffic Limiting
Peer to Peer (P2P) protocols are widely used in downloading on the network. The constant
increase of P2P traffic affects normal operation of other network applications and increases the
costs of network operation, especially for enterprises and operators who are charged by traffic.
To address this problem, the Eudemon is designed with the P2P traffic limiting function.
3.6 IP-CAR
IP-CAR limits IP bandwidths and the number of IP connections.
3.7 TSM Cooperation
As a Security Access Control Gateway (SACG), the Eudemon cooperates with the TSM terminal
security management system to control terminal users' access to networks based on specific
classification of these users.
3.8 SLB

3 Security Features Feature Description
In the current network application, especially in Internet Data Center (IDC) and websites, the
processing capability of a single server has become the bottleneck of the network. The
Eudemon can solve the above problems through Server Load Balancing (SLB).

3.1 ACL
This describes the definition, applications, settings, and steps of ACLs on the Eudemon.
3.1.1 ACL Definition
An Access Control List (ACL) includes a series of ordered rules consisting of the permit or
deny statements. The rules are described mainly by source address, destination address, port
number, upper layer protocol, or other information.
3.1.2 ACL Application
ACLs can be used in other services or applications such as packet filtering, NAT, IP Security
(IPSec), QoS, and routing policy.
3.1.3 ACLs on the Eudemon
The Eudemon provides multiple types of ACLs and supports such ACL applications as time
range–based ACL applications.
3.1.4 ACL Step
Step is introduced to help users insert new rules between the sub-rules in the current ACL rule
group. Step means the difference between IDs automatically allocated to each sub-rule in the
ACL rule group.
3.1.1 ACL Definition

An Access Control List (ACL) includes a series of ordered rules consisting of the permit or
deny statements. The rules are described mainly by source address, destination address, port
number, upper layer protocol, or other information.
A Eudemon should be capable of controlling network data streams so as to meet:

l Network security requirements
l QoS requirements
l Policy establishment requirements.
ACL is one of the measures used to control data streams.
3.1.2 ACL Application

ACLs can be used in other services or applications such as packet filtering, NAT, IP Security
(IPSec), QoS, and routing policy.
Packet Filtering
Packet filtering, as a network protection mechanism, is used to control the inbound and outbound
data between networks of different security levels.
The Eudemon performs packet filtering as follows:
1. The Eudemon checks the packets received on the interfaces and extracts such information
as source/destination IP addresses, source/destination port numbers, and types of upper
layer protocols.

2. The Eudemon checks the extracted information against the filtering rules set for the
interface and then forwards or discards the corresponding packets based on the result of
the check.
To filter data packets, you need to configure a series of filtering rules. You can use ACLs to
define packet-filtering rules, and then apply ACLs to interzones of the Eudemon to filter packets
based on ACLs.
NAT
NAT translates an IP address contained in a packet header into another IP address. NAT is mainly
used to help internal networks (private IP addresses) to access external networks (public IP
addresses).
In actual practice, you may intend to allow only certain internal hosts (with private IP addresses)
to access Internet (external networks). In this case, you can associate ACLs with the NAT address
pool to realize access control. This association mechanism help only ACL-eligible packets to
translate IP addresses, thus effectively controlling the range of NAT use.
IPSec
The IPSec protocol suite is a series of protocols defined by Internet Engineering Task Force
(IETF). With encryption and data source authentication mechanism on the IP layer, IPSec
ensures the privacy, integrity, and authenticity of packets transmitted between the two
communicating nodes on Internet.
IPSec can provide different security protection measures for data streams. For example, IPSec
can adopt different security protocols, algorithms, and keys to protect different data streams. In
actual practice, a data stream is defined first by ACLs. Namely, traffic matching the same ACL
is logically regarded as one data stream. By referencing the ACL in the security policy, IPSec
confirms that the specified data streams is protected.
QoS
QoS is used to evaluate the collective effect of service performances which determine the degree
of satisfaction of a user of the service. An effective way to ensure QoS on Internet is to improve
traffic control and resource allocation on the IP layer so as to provide differentiated services.
Traffic classification is the premise and basis for providing differentiated services. In practice,
you need to do as follows:
1. Define traffic classification policies (rules).
Traffic classification rules are used to identify traffic with different priorities based on ToS
fields or define traffic classification policies based on ACLs. For example, you can classify
traffic based on the following information:
l Source address
l Destination address
l MAC address
l IP protocol
l Port number of application programs
2. Apply traffic classification policies or ACLs in traffic monitoring, traffic shaping,
congestion management, and congestion mitigation.

Routing Policy
A routing policy refers to a policy used during the process of sending and receiving routing
information. A routing policy filters routing information.
A routing policy has several ways to filter routes. ACLs, as an important filter, are widely used.
You can use ACLs to specify an IP address or subnet range as the destination address or the next
hop address of the matched route.
3.1.3 ACLs on the Eudemon

The Eudemon provides multiple types of ACLs and supports such ACL applications as time
range–based ACL applications.
ACL Classification
Table 3-1 shows the types of ACLs that theEudemon supports.
Table 3-1 Classification of the ACL
Type Value Range Description
Basic ACL 2000 to 2999 Basic ACLs use only a source

address to define a data
stream.
Advanced ACL 3000 to 3999 Advanced ACLs define rules

based on the source
addresses, destination
addresses, and protocols over
IP, such as the TCP source
port, destination port, ICMP
type, and message code.
MAC address-based ACL 4000 to 4099 MAC address-based ACLs

are mainly used when the
Eudemon works in
transparent mode. In this
mode, the Eudemon can
control Layer 2 frames by
matching the source MAC
addresses, destination MAC
addresses, and frame types
with the ACLs.
ACL Match Order

An ACL rule is composed of multiple permit or deny statements. Each statement describes
different rules, which may be repeated or inconsistent.
When matching a packet to the ACL rules, you need to set the ACL match order. The
Eudemon matches the ACL rules in the following orders:

l Rule configuration order

Earlier configured ACL rules are referenced first.
l Automatic sequence order
ACL rules are applied to match packets based on the depth-first principle.
Depending on the depth first principle, the rule with the smallest data stream range is
referenced first to match packets. The sequence of rules is determined by the wildcards of
addresses. The smaller the wildcard, the smaller the host range specified by the wildcard.
For example, 129.102.1.1 0.0.0.0 specifies one host only, that is, 129.102.1.1; 129.102.1.1
0.0.255.255 specifies a segment ranging from 129.102.1.1 to 129.102.255.255. The host
range specified by wildcard 0.0.0.0 is obviously smaller than that specified by wildcard
0.0.255.255. Therefore, the rule with 129.102.1.1 0.0.0.0 is preferred. The following lists
the specifications in detail:
– In the scenario where basic ACL rules are referenced, the wildcards of their source
address are compared directly. If they are identical, rules are referenced in the
configuration order to match packets.
– In the scenario where advanced ACL rules are referenced, source address wildcards are
compared first; if they are identical, destination address wildcards are compared; if their
destination address wildcards are still the same, port number ranges are compared. Rules
are ranged in host range order (the rule with the smallest host range first). If port number
ranges are the same, rules are ranged in configuration order.
Once a data stream matches with a rule, the matching attempt stops. The Eudemon performs
actions as specified by the ACL rule to deal with the data stream.
Source Address and Wildcard Mask

When a basic ACL is applied, you need to specify a source IP address. A source IP address can
represent a host, a group of hosts, or an entire subnet or network. The range of a source IP address
is determined by a wildcard mask field.
Different from a subnet mask, 0 in a wildcard mask field refers to a bit that must be matched
and 1 refers to a bit that is not necessarily matched. To obtain the range of a source IP address,
you need to get the negation of sour-wildcard and then perform or operation with sour-
wildcard.
For example:
source-address = 192.168.15.16 11000000.10101000.00001111.00010000
source-wildcard = 0.0.0.255 00000000.00000000.00000000.11111111
source-address range = 192.168.15.0 11000000.10101000.00001111.00000000
any means that all packets meet the match condition. Namely, any = 0.0.0.0 255.255.255.255.
Time Range-based ACL Rules

Today, network security policies require more flexibility in controlling resource access. For
example, if a system administrator intends to allow certain data streams to pass through the
firewall only during work time or allow users to access certain resources in some time ranges
only, you can adopt time range-based ACLs.
ACL Rules for Applying Address Book

To simplify the configuration and maintenance of ACL rules, the Eudemon supports the ACL
that quotes the address set and port set.

An ACL rule that is described through the address set and port set shows as a traditional set of
rules with the same priority in application. The formula in the new set is described as follows:
The number of the rule elements with the same priority = the number of the elements in address
set 1 x the number of elements in address set 2 x the number of elements in port set 1 x the
number of elements in port set 2.
For example, configure two address sets and one port set, and each set respectively contains two
elements and is applied in ACL 3000.
<Eudemon> system-view
[Eudemon] ip address-set a1
[Eudemon-address-set-a1] address 1 1.1.1.1 0
[Eudemon-address-set-a1] quit
[Eudemon] ip address-set a2
[Eudemon-address-set-a2] quit
[Eudemon] ip port-set p1 protocol tcp
[Eudemon-tcp-port-set-p1] port 1 eq 21
[Eudemon-tcp-port-set-p1] port 2 eq 22
[Eudemon-tcp-port-set-p1] quit
[Eudemon] acl 3000
[Eudemon-acl-adv-3000] rule permit tcp source address-set a1 destination address-
set a2 destination-port port-set p1
The configuration effects of the above commands are the same as the following ACL rules:
[Eudemon] acl 3000
[Eudemon-acl-adv-3000] rule permit tcp source 1.1.1.1 0 destination 3.3.3.1 0
destination-port eq 21
3.1.4 ACL Step

Step is introduced to help users insert new rules between the sub-rules in the current ACL rule
group. Step means the difference between IDs automatically allocated to each sub-rule in the
ACL rule group.
For example, suppose that the step is set to 2, then the IDs of rules should be multiples of 2
beginning with 2, namely, 2, 4, 6 and so on. By default, the step of the ACL rule group is 5.
The step for an ACL rule group is set before the subrules. After the subrules are set, to change
the step, delete all the subrules and then reset the step.
Setting step is helpful for inserting new rules between subrules. For example, there are four rules,
and their subrule numbers are 5, 10, 15, and 20. To insert a rule after the first rule, you can use
the rule 6 xxxx command to insert a subrule numbered 6 between 5 and 10.

NOTE
l The value of the step influences the maintenance of the subrules in the ACL rule group. If the value is
too small, the number of subrules to be inserted is limited. A subrule may not be inserted for no number
can be assigned. Thus you are recommended to use the default step or larger step. The range of the step
is from 1 to 20.
l If a step is set, you need to delete the existing rules before using the step command or the undo step
command to change the step setting or restore the default step setting.
3.2 Security Policy

The Eudemon supports various security policies, including packet filtering, attack defense,
ASPF, and Blacklist.
3.2.1 Packet Filtering
3.2.2 Attack Defense
The Eudemon provides a powerful attack defense mechanism to protect devices and prevent
illegal packets from damaging the intranet.
3.2.3 ASPF
The Eudemon delivers the application layer–based packet filtering function, namely, the
application specific packet filter (ASPF) function, such as TCP/UDP tunnel and state check.
3.2.4 Blacklist
Blacklist is one of the important security features of firewalls. The Eudemon can dynamically
add or delete blacklist entries.
3.2.5 MAC and IP Address Binding
For a Eudemon, MAC and IP address binding associates a specific IP address with a MAC
address according to your configuration. MAC and IP address binding is an effective measure
against IP spoofing attacks.
3.2.6 Port Identification
Port identification mechanism helps create and maintain a application protocol-specific system-
defined and user-defined port identification table.
3.2.1 Packet Filtering

1. The Eudemon checks the packets received on the interfaces and extracts such information
as source/destination IP addresses, source/destination port numbers, and types of upper
layer protocols.
2. The Eudemon checks the extracted information against the filtering rules set for the
interface and then forwards or discards the corresponding packets based on the result of
the check.
To filter data packets, you need to configure a series of filtering rules. You can use ACLs to
define packet-filtering rules, and then apply ACLs to interzones of the Eudemon to filter packets
based on ACLs.

3.2.2 Attack Defense

The Eudemon provides a powerful attack defense mechanism to protect devices and prevent
illegal packets from damaging the intranet.
Introduction to Attack Defense

Typically, network attacks intrude or destroy network servers (hosts) to steal the sensitive data
on servers or interrupt server services. Some network attacks aim to directly destroy network
devices, they are more damaging and usually result in networks service abnormality or even
service interruption.
The attack defense function of the Eudemon can detect various types of network attacks and
take appropriate measures to protect internal networks against malicious attacks. Therefore, the
Eudemon can ensure the normal operations of the internal networks and systems.
Network Attacks Classification

The main network attacks can be divided into three classes:
l Denial of Service attack
Denial of Service (DoS) attacks prevent systems from accepting normal requests or break
down hosts by overloading them with malicious, unsolicited packets.
The main DoS attacks include SYN Flood and Fraggle. Different from other types of
attacks, the attackers of a DoS attack does not search for an ingress of the target network.
Instead, they attempt to prevent legitimate users from accessing resources or firewalls.
l Scanning and snooping attack
Scanning and snooping attacks use ping sweeping to identify live systems on a network
and accurately specify the potential target. Using TCP and UDP port scanning, attackers
can detect potential services of the target operating system and understand the service types
provided by the target system as well as vulnerabilities on the services.
l Defective packet attack
During a defective packet attack, the attacker sends defective IP packets to the target system.
Processing the defective packets results in system breakdown. The main defective packet
attacks are Ping of Death and Teardrop attacks.
In addition to these three kinds of network attacks, there are routing protocol attacks and device
forwarding table attacks.
Typical Examples of Network Attacks

The attacks on networks fall into the following groups:
l IP spoofing attacks
To obtain access permission, an intruder creates a packet carrying a forged source IP
address. For IP address authentication-based applications, this type of attacks enable an
unauthorized user to access the desired target system, in some cases, even as the root
administrator. IP spoofing attacks damage the target system even though no response packet
is returned to the attacker.
l Land attacks
Land attacks change both the source IP address and the destination address of the TCP SYN
packet to the IP address of the attacked target. In this case, the attacked host sends SYN-

ACK messages to itself, which responds with ACK messages and then creates a null
connection. Each null connection is reserved until it times out. Different attacked targets
present different responses to Land attacks. UNIX hosts crash while Windows NT hosts
are seriously slowed down.
l Smurf attacks
Simple Smurf attacks intrude a network by sending ICMP requests to the broadcast address
of the target network. All the hosts on the network respond to requests, whose traffic can
amount to 10 or 100 times as large as the traffic of large ping packets. Network congestion
thus occurs.
Advanced Smurf attacks are mainly used to attack a target host by changing the source
address of the ICMP packet to the address of the target host. That results in the breakdown
of the target host. It takes certain traffic and time to send attack packets before these packets
finally form an attack. Theoretically, the larger the number of the hosts is, the more obvious
the effect will be. Another new form of the Smurf attack is Fraggle attack.
l WinNuke attack
WinNuke attacks cause a NetBIOS fragment overlap by sending Out-Of-Band (OOB) data
packets to the NetBIOS port (139) of the specified target installed with the Windows
system. IGMP fragments are also used to launch an attack. Typically, IGMP packets are
not fragmented. Thus some systems are not efficient enough in dealing with IGMP
fragments. In this case, one they receive IGMP fragments, the systems are under attacks.
l SYN Flood attacks
Since resources are limited, TCP/IP stacks only permit a certain number of TCP
connections. SYN Flood attacks exploit this defect by forging an SYN packet with forged
or nonexisting source IP address and sending connection requests to the server. When the
server receives the connection requests, it responds with SYN-ACK packets. When the
SYN-ACK packets are sent out, the server does not received ACK packets. That results in
semi-connections. A large number of semi-connections will exhaust the network resources.
Users cannot access these resources until the semi-connections time out. The SYN Flood
attack also takes effect in the application whose connection number is not limited to
consume the system resources such as memories.
l ICMP and UDP Flood attacks
ICMP and UDP Flood attacks overload the target system with a large number of ICMP
messages (such as ping) and UDP packets in a short time. Thus, the target system is unable
to transmit valid packets.
l Address or port scanning attacks
Address or port scanning attacks use scanning tools to detect destination IP addresses and
ports. If a target system responds, attackers understand that the system is live. Then
attackers attempt to connect with live systems.
l Ping of Death attacks
The length field of an IP packet is 16 bits, which indicates that the maximum length of an
IP packet is 65535. Therefore, if the length of an ICMP request packet is greater than 65507,
the entire length of the ICMP packet (ICMP data + IP header 20 + ICMP header 8) will be
larger than 65535, which may cause some routers or systems crash, die, or reboot.
l ARP attacks
Common ARP attacks include ARP spoofing attacks and ARP Flood attacks.
– ARP spoofing attacks: The attacker sends a large amount of spoofing ARP requests and
response packets to attack network devices. ARP spoofing attacks mainly include ARP
buffer overflow attacks and ARP DDoS attacks.

– ARP Flood attacks (ARP scanning attacks): When the attacker scans hosts in its own
network segment or across network segments, the firewall checks the ARP entry before
sending the response message. If the MAC address of the destination IP address does
not exist, the ARP module of the firewall sends the ARP Miss message to the upper
layer software, asking the upper layer software to send an ARP request message to obtain
the MAC address. Massive scanning packets induce massive ARP Miss messages. As
a result, the firewall uses a lot of its resources to handle the ARP Miss messages and
thus cannot process other services properly. In this way, scanning attacks are launched.
3.2.3 ASPF
The Eudemon delivers the application layer–based packet filtering function, namely, the
application specific packet filter (ASPF) function, such as TCP/UDP tunnel and state check.
Introduction to ASPF
Application Specific Packet Filter (ASPF) is a packet filtering mechanism based on the
application layer. ASPF is status-based packet filter. It can cooperate with a common static
firewall to implement the security policies of an internal network. ASPF can detect the
application layer protocol sessions attempting to passing through the firewall and prevent
disqualified packets from passing through the firewall.
For the sake of network security, ACL-based packet filtering mechanism can detect packets on
the network layer and transmission layer to prevent intrusion. ASPF can detect application layer
protocols and monitor application traffic.
In addition, ASPF provides the following functions:
l Java blocking can protect networks against damaging Java Applets.

l ActiveX blocking can protect networks against damaging ActiveX.
ASPF detects application layer protocols and defends against malicious attacks by maintaining
session status and checking session packet information such as protocols and port numbers.
The ASPF mechanism on the Eudemon can monitor the traffic of the following protocols:

l H.323
l Hyper Text Transport Protocol (HTTP)
l Huawei Conference Control protocol (HWCC)
l Internet Location Service (ILS)
l Media Gateway Control Protocol (MGCP)
l Microsoft Media Service (MMS)
l MSN Messenger Service (MSN)
l Point to Point Tunnel Protocol (PPTP)
l Tencent QQ (QQ)
l Real-Time Streaming Protocol (RTSP)
l Session initiation Protocol (SIP)

l SQL.NET
l user-define
QQ/MSN Chat Detection

At present, most networks deploy NAT devices to provide address translation services, thus
saving IP address resources.
For plain text chats, if QQ/MSN servers keep the address mapping information of chatting users,
their exchanging packets can successfully relayed through QQ/MSN servers.
For audio or video chats, if relaying this type of packets overly consumes the resources of QQ/
MSN servers, they cannot ensure the normally relay of plain text chatting packets. A solution
to solve this problem is that chatting users directly exchange high volumes of file/audio/video
information through network devices. However, this solution is hardly implemented because
common NAT devices need to translate the addresses of the chatting users.
To solve this problem, you can enable the interzone QQ/MSN detection when configuring the
NAT function on the Eudemon. Since the Eudemon creates address mapping relation upon the
start of a QQ/MSN chat, users on two private networks can directly transfer files and experience
audio/video chats.
Triplet ASPF
The Eudemon is equivalent to a quintuple NAT device. In other words, the setup of each session
on the Eudemon requires five elements:
l Source IP address
l Source port
l Destination IP address
l Destination port
l Protocol number
To adapt to such type of communication mechanisms, the Eudemon is designed to support also
triplet process. Therefore, packets of QQ and MSN can traverse the Eudemon successfully.
Besides QQ and MSN, to help other sessions like TFTP, which uses the source IP address, the
source port, and the protocol number to traverse a NAT device, you need also configure the
Eudemon with triplet ASFP.
3.2.4 Blacklist
Blacklist is one of the important security features of firewalls. The Eudemon can dynamically
add or delete blacklist entries.
Compared with ACL-based packet filter, blacklist filter features high speed and efficiency,
because a blacklist matches only IP addresses. Therefore, blacklist filter can quickly and
effectively shield users with specified IP addresses.
You can create blacklist entries in two ways:
l Through command lines
l Through attack defense modules, login authentication modules
When the Eudemon senses the attack attempt by checking the signature of packets from a
specific IP address, the Eudemon initiatively adds the IP address to the blacklist, thus

filtering packets sent from this IP address. This mechanism helps the Eudemon ensure
network security.
3.2.5 MAC and IP Address Binding

For a Eudemon, MAC and IP address binding associates a specific IP address with a MAC
address according to your configuration. MAC and IP address binding is an effective measure
against IP spoofing attacks.
For a packet with the supposed source IP address, if its MAC address is not the one as specified
in the binding relation, the Eudemon drops the packet. Packets with this destination IP address
are forcibly sent to the MAC address associated with IP address after passing through the
Eudemon. Thus this mechanism helps the Eudemon effectively protect users.
3.2.6 Port Identification

Port identification mechanism helps create and maintain a application protocol-specific system-
defined and user-defined port identification table.
Application layer protocols usually use common ports (standard ports) for communication. Port
identification allows you to define a group of application-specific new port numbers in addition
to the system-defined port numbers. Port identification provides certain mechanisms for
maintaining and applying user-defined port configurations.
The port identification function on the Eudemon supports two identification mechanisms:
l Common port identification

This identification mechanism associates a user-defined port number with an application
layer protocol. For example, port number 8080 is identified as HTTP. Thus, the TCP packets
with destination port number 8080 are considered as HTTP packets.
l Basic ACL-based host port identification
Host port identification mechanism associates a user-defined port number with an
application protocol for packets destined for certain hosts. For example, TCP packets
destined for segment 10.110.0.0 through port 8080 are considered as HTTP packets. The
host range can be specified by basic ACLs.
The ACLs identified by the port of the host and quoted by the packet filtering differ in the
following aspects:
– When configuring the interzone packet-filtering rule, the specified ACL should have
explicit directivity. The Eudemon only permits the packets that move from the source
address to the destination address to pass.
– When configuring port identification, the specified basic ACL is only used to define
the range of hosts without directivity.
3.3 NAT
NAT is mainly used to help internal network users (private IP addresses) to access external
networks (public IP addresses), and provides the internal server function.
3.3.1 Introduction to NAT
As defined by RFC 1631, Network Address Translation (NAT) is to translate the IP address
contained in an IP data packet header into another IP address. NAT is mainly used to help internal
network users (private IP addresses) to access external networks (public IP addresses).

3.3.2 NAT on the Eudemon

The Eudemon supports multiple modes of NAT, such as one-to-one NAT, many-to-many NAT,
and NAPT. In addition, it supports multiple NAT ALGs, bi-directional NAT, and destination
NAT.
3.3.1 Introduction to NAT

As defined by RFC 1631, Network Address Translation (NAT) is to translate the IP address
contained in an IP data packet header into another IP address. NAT is mainly used to help internal
network users (private IP addresses) to access external networks (public IP addresses).
In actual practice, private networks usually use private IP addresses. RFC 1918 defines three IP
address blocks for private and internal networks:
l Class A: 10.0.0.0 to 10.255.255.255 (10.0.0.0/8)

l Class B: 172.16.0.0 to 172.31.255.255 (172.16.0.0/12)
l Class C: 192.168.0.0 to 192.168.255.255 (192.168.0.0/16)
IP addresses of the three classes are not assigned on Internet. Therefore, they can be used in the
intranet of a company or enterprise without registering with the Internet Service Provider (ISP)
or register center.
NAT is mainly used to help private networks to access external networks. It helps slow down
the IP address space depletion by using several public IP addresses to represent multiple private
IP addresses.
Figure 3-1 shows a basic NAT application.
Figure 3-1 Basic process of address translation

Data packet 1 Data packet 1'
Source:192.168.1.3/24 Source:202.169.10.1/24
Destination:202.120.10.2/24 Destination:202.120.10.2/24
Server
PC 202.120.10.2/24
192.168.1.3/24 Eudemon
Untrust
Trust Eth0/0/0 Eth1/0/0
192.168.1.1/24 202.169.10.1/24
Server
192.168.1.2/24
PC
Data packet 2 Data packet 2' 202.130.10.3/24
Source:202.120.10.2/24 Source:202.120.10.2/24
Destination:192.168.1.3/24 Destination:02.169.10.1/24
A NAT server such as the Eudemon is deployed at the joint between a private network and a
public network. All interactive packets between an internal PC and an external server pass
through the NAT server.
Addresses are translated as follows:

1. When packet 1 sent by the internal PC at 192.168.1.3 to the external server at 202.120.10.2
reaches the NAT server, the server checks the head of packet 1, discovering that the packet
is destined for an external network.
2. The NAT server translates the source address 192.168.1.3 of the packet 1 into a valid public
address 202.169.10.1, which can select routes on Internet, and then forwards the packet to
the external server, recording address translation mapping in the NAT list.
3. After the external server receives packet 1', it sends a response packet to the internal PC,
that is, packet 2' with destination address 202.169.10.1.
4. After packet 2' reaches the NAT server, the NAT server checks its head and searches the
NAT list, replaces the destination address with 192.168.1.3, and then sends packet 2' to the
internal PC.
The preceding NAT transaction is transparent to PCs and external servers. The internal PC knows
of no transaction with the NAT server during the process of exchanging packets with an external
server. The external server determines that the IP address of the internal PC is 202.169.10.1 and
does not know the existence of 192.168.1.3.
3.3.2 NAT on the Eudemon

The Eudemon supports multiple modes of NAT, such as one-to-one NAT, many-to-many NAT,
and NAPT. In addition, it supports multiple NAT ALGs, bi-directional NAT, and destination
NAT.
NAT Mechanism on the Eudemon

NAT mechanism can be divided into two parts:
l Translating the IP address and port of an internal host into an extranet address and port
l Translating the extranet address and port into the IP address and port of an internal host
This process translates between <private address + port> and <public address + port>.
When a data stream moves from one security zone to another, the Eudemon checks the packet
to determine whether to perform NAT. If necessary, the Eudemon performs NAT based on the
following principles:
l At the egress of the IP layer, the Eudemon translates the source address (private address)
of a packet into a public address and then sends the packet to the external network.
l At the ingress of the IP layer, the Eudemon translates the destination address (public
address) of the packet into a private address and then sends the packet to the internal
network.
Many-to-Many NAT and NAT Control

As shown in Figure 3-1, the IP address on the egress of the NAT server is the post-translated
source IP address. All internal hosts use this public IP address to access an external network. In
the scenario where only one internal host is allowed to access the external network, NAT is one-
to-one address translation. In the scenario where multiple internal hosts simultaneously require
to access the external network, one-to-one address translation can help only one internal host to
access the external network.
Extended NAT allows one NAT server to have several public IP addresses, thus meeting the
demand of concurrent access requests. When one internal host requires to access the external
network, the NAT server assigns public address IP 1 to it. When another internal host requires

to access the external network, the NAT server assigns another public address, namely, IP 2 to
it. In this case, NAT realizes many-to-many address translation.
NOTE
l Since not all internal hosts require to access an extranet simultaneously, typically, the number of public
IP addresses on a NAT server is far less than that of hosts in an intranet.
l The number of public IP addresses is determined according to the maximum number of intranet hosts
accessing the external network at the rush hour.
In actual practice, you may need to grant Internet access permissions to only some internal hosts.
That is, you need to control address translation. For example, if the NAT process finds that an
source IP address is not allowed to access external networks, the NAT server does not perform
address translation.
The Eudemon realizes many-to-many NAT by defining an address pool. In addition, the
Eudemon can use ACLs to control address translation. The detail is as follows:
l Address pool
An address pool is a collection of public IP addresses used for NAT. You need to configure
an appropriate address pool by considering the following cases:
– The number of your valid IP addresses
– The number of your internal hosts
– Actual application requirements
The NAT server selects one IP address as the post-translated source IP address during the
process of address translation.
l ACL-based NAT
The Eudemon can use ACLs to control NAT.
The NAT server does not translate addresses unless the packets meet the requirements of
ACL rules. That can effectively control the use of address translation and enable only
specified hosts to access Internet.
Network Address Port Translation (NAPT)

Besides the many-to-many NAT, Network Address Port Translation (NAPT) is another way to
achieve the concurrent address translation. NAPT can map several internal addresses to a public
address. It is also called many-to-one address translation or address multiplexing.
NAPT maps an IP address to a port number. Packets with different internal addresses can be
mapped to different port numbers of the same public address. Therefore, different internal
addresses can share the same public address.
The fundamentals of NAPT are shown in Figure 3-2.

Figure 3-2 Basic principle of NAPT

Source: 192.168.1.3/24 Source: 202.169.10.1/24
Source port: 1357 Source port: 1357

Source: 192.168.1.3/24 Source: 202.169.10.1/24 202.120.10.2/24
Source port: 2468 Source port: 2468 PC
PC Eudemon Untrust
192.168.1.3/24
Trust Eth0/0/0 Eth1/0/0
192.168.1.1/24 202.169.10.1/24
Server
192.168.1.2/24
Source: 192.168.1.1/24 Source: 202.169.10.1/24 Server
Source port: 11111 Source port: 11111 202.130.10.3/24
Source: 192.168.1.2/24 Source: 202.169.10.1/24
Source port: 11111 Source port: 22222
As shown in Figure 3-2, four packets with internal addresses reach the NAT server. Where:
l Packet 1 and packet 2 have the same internal address but different source port numbers.
l Packet 3 and packet 4 have different internal addresses but the same source port number.
After NAT mapping, all the four packets have the same external address but different source
port numbers, so they still can be distinguished.
When the response packets reach the Eudemon, the NAT process can also differentiate them
based on their destination addresses and port numbers and then forward them to the desired
internal hosts.
Internal Server
NAT can shield internal hosts by hiding the architecture of the internal network. In actual
practice, however, you may need to allow external users to access internal hosts in some cases.
For example, you may provide a WWW server or FTP server to external users. NAT offers you
with more flexibility to add internal servers. The Eudemon provides two methods for you to
specify external addresses for internal servers.
For example:
l You can use 100.1.1.1 as the external address of the WWW server.
l You can use 100.1.1.3:8080 as the external address of the WWW server.
NAT on the Eudemon provides internal servers for external users to access. The Eudemon
performs as follows when external users access an internal server:

l The Eudemon translates the destination addresses contained in the request packets of
external users into private addresses of the internal server.
l The Eudemon translates the source addresses (private addresses) contained in the response
packets of internal servers into public addresses.
Moreover, the Eudemon can provide multiple servers of the same type to external users, such
as Web servers.
NOTE
The internal servers accessible for external users are usually deployed in the DMZ of the Eudemon.
Typically, devices in the DMZ are not allowed to initiatively initiate external connection requests.
Eudemon supports security zone-based internal servers. For example, you can configure multiple
public IP addresses for a security zone-based internal server. By correlating security zones of
different levels with different external network segments and configuring an internal server with
multiple public IP addresses respectively corresponding to the security zones of different levels,
you can enable a specific external network segment to access the internal server with its
corresponding public IP address pre-configured.
NAT ALG
CAUTION
l The Encapsulating Security Payload NAT (ESP NAT) function translates the addresses of
ESP packets. This function works only when there are ESP packets transmitted through a
tunnel.
l Different from the NAT of common packets, ESP NAT performs address translation based
on IP addresses and port numbers.
l ESP NAT is realized on a NAT device.
NAT and NAPT can translate the address contained in the IP packet header and the port number
in the TCP/UDP packet header only. However, for some special protocols like ICMP and FTP,
the data fields of their packets may include IP address or port information. Because the type of
information cannot be effectively translated by the NAT server, some problems may occur.
For example, an FTP server sends its internal IP address to an external host during the process
of establishing a session. Since address information is contained by the data part of an IP packet,
the NAT server cannot translate it. When the external host receives and uses the untranslated
private address, the FTP server is unreachable.
To solve the problem with NAT of special protocols, you can apply the Application Level
Gateway (ALG) during NAT implementation. The ALG is the translation proxy of certain
application protocols. It interacts with NAT to change certain data encapsulated in the IP packet
based on the NAT state information and helps the application protocols to function in various
ranges through other necessary processes.
For example, the data part of a destination unreachable ICMP packet contains the header of
packet A which causes the error. Note that since the IP address of packet A has been translated
before the NAT sends it, the current source address is not the real address of the internal host.
If the ICMP ALG function is enabled, the ICMP ALG interacts with the NAT server to open
the ICMP packet before the NAT server forwards the packet. After the ICMP packet is opened,
the NAT server translates the address contained in the header of packet A into the accurate format

of the internal host address and forwards the ICMP packet after other necessary processes are
complete.
The Eudemon provides a perfect NAT ALG mechanism with good scalability, which can support
various special application protocols without modifying the NAT platform.
The Eudemon can implement the ALG function of the following common application protocols:
l DNS
l ESP
l FTP
l H.323
l HWCC
l ICMP
l ILS
l MGCP
l MMS
l MSN
l NetBIOS
l PPTP
l QQ
l RTSP
l SIP
l SQL.NET
l user-define
Bi-directional NAT
The Eudemon supports outbound NAT that conceals private IP addresses of users in high-level
security zones or private IP addresses of accessed internal servers. Also, the Eudemon supports
NAT that conceals private IP addresses of users in low-level security zones and private IP
addresses of users when they access servers in the same security zone. The bi-directional NAT
can be used in the following two situations:
l To conceal IP addresses of users in low-level security zones when they access servers in
higher-level security zones, you need to configure inbound NAT.
l To conceal IP addresses of users when they access servers in the same security zone, you
need to configure NAT within a zone.
If the inbound NAT and the internal server function are both configured, or NAT within the zone
and the internal server function are both configured, the NAT is bi-directional.
As shown in Figure 3-3, when a user in the Untrust zone accesses the FTP server in the DMZ,
with the internal service configured, inbound NAT can also be configured to hide the actual IP
address of the user.

Figure 3-3 Networking diagram of configuring inbound NAT

FTP server PC
DMZ Untrust
Eudemon
When users in the Untrust zone access the FTP server in the DMZ zone, the Eudemon carries
out NAT as follows:
l The Eudemon converts the destination address of the request packet from the external users
to the private IP address of the internal server. The Eudemon converts the source IP address
to the address in the address pool (private IP address).
l The Eudemon converts the source address (private IP address) of the response packets from
the internal server to the public IP address. The Eudemon converts the destination IP address
(private IP address) to the public IP address.
As shown in Figure 3-4, the FTP server and the PC are both in the Trust zone. All interaction
packets between the PC and the FTP server are supposed to pass through the Eudemon so that
security checks such as attack detection can be performed on these packets. In this case, the
internal server and NAT (within one zone) both need be configured.
Figure 3-4 Networking diagram of NAT within the zone

Eudemon
PC FTP server
Trust
LAN switch
When users in the Trust zone access the server in the same zone, the Eudemon carries out NAT
as follows:
l The Eudemon converts the destination IP address of the request packet from the external
users to the private IP address of the internal server. The Eudemon converts the source IP
address to the public IP address in the address pool.
l The Eudemon converts the private source IP address of the response packet in the internal
server to the public IP address. The Eudemon converts the destination address (public IP
address) to the address of the public network.

Destination NAT
NOTE
You cannot configure the destination NAT function and the internal server function in the same security
zone.
At present, a large number of mobile terminal users use mobile phones that are purchased directly
abroad. The Wireless Application Protocol (WAP) gateway addresses set on these foreign
mobile phones are not in tune with local WAP gateway addresses. In addition, users cannot
modify these settings by themselves. As a result, some users cannot enjoy the mobile Internet
access services.
To meet Internet access requirements of these users, you can configure the destination NAT on
the Eudemon which is between the WAP gateway and the mobile phones. When packets whose
destination address is the address of the WAP gateway of these mobile phones arrive at the
Eudemon, the Eudemon translates this destination address into the real address of the WAP
gateway according to ACL rules. Therefore, users of these mobile phones can access the WAP
gateway normally.
Figure 3-5 shows the networking diagram of destination NAT.
Figure 3-5 Networking diagram of destination NAT
GGSN GSR Eudemon WAP gateway

GGSN Gateway GPRS Support Node
GSR Gigabit Switching Router
WAP gateway Wireless Application Protocol Gateway
3.4 Authentication and Authorization

The Eudemon delivers the authentication and authorization functions to enable centralized
management of network security. The Eudemon supports local authentication, standard Remote
Authentication Dial-In User Service (RADIUS) authentication, Huawei RADIUS+
authentication, Huawei Terminal Access Controller Access Control System (HWTACACS)
authentication, and local user management. It can authenticate users and grant authorities to
legal users to prevent access by illegal users.
3.4.1 Introduction to Authentication and Authorization
The Eudemon supports authentication and authorization functions. Authentication and
authorization usually adopts the client/server mode. The client runs on the resource side and the
server keeps user information. This structure has good extensibility and is convenient for
concentrated management of user information.
3.4.2 Introduction to RADIUS Protocol
Authentication and authorization can be implemented based on multiple types of protocols. The
most commonly used protocol is the RADIUS protocol. The RADIUS protocol was used to

manage a large number of dispersed users who use the serial ports and modems for network
access in the earlier years. Now, the RADIUS protocol is widely applied to the Network Access
Server (NAS) system.
3.4.3 Introduction to HWTACACS Protocol
The HWTACACS protocol is an enhanced security protocol developed based on TACACS (RFC
1492). Similar to the RADIUS protocol, HWTACACS adopts the client/server mode to realize
multiple authentication and authorization functions. HWTACACS can be used for
authenticating, authorizing, and accounting PPP user, Virtual Private Dial Network (VPDN)
access user, and login users.
3.4.4 Introduction to Domain
The Eudemon manages users by domains. In a domain, you can configure the default
authorization, RADIUS or HWTACACS templates, and authentication and accounting schemes.
3.4.5 Introduction to Local User Management
You can not only create a local user database on the Eudemon for user information maintenance
and user management, but also perform local authentication.
3.4.1 Introduction to Authentication and Authorization

The Eudemon supports authentication and authorization functions. Authentication and
authorization usually adopts the client/server mode. The client runs on the resource side and the
server keeps user information. This structure has good extensibility and is convenient for
concentrated management of user information.
Authentication
The Eudemon supports the following authentication modes:
l None authentication
The users are considered as reliable and no legality check is performed to them. For the
sake of security, this mode is not recommended.
l Local authentication
Users are authenticated according to the information kept locally on the Network Access
Server (NAS) when they access the network. The local information includes user name,
password, and other attributes.
l Remote authentication
This authentication mode supports authentication based on the Remote Authentication Dial
In User Service (RADIUS) protocol or the HWTACACS protocol. NAS, as the client,
communicates with the RADIUS server or the HWTACACS server. For remote
authentication, both the standard RADIUS protocol and the extended RADIUS protocol of
Huawei can work jointly with devices such as iTELLIN/CAMS to implement
authentication.
Authorization
The Eudemon supports the following authorization modes:
l Direct authorization
The users are considered as reliable and directly granted with access permissions.
l Local authorization

Users are authorized according to the local account-specific attributes configured on the
NAS.
l HWTACACS authorization
The HWTACACS server authorizes the users.
l If-authenticated authorization
If a user passes the local or remote authentication, the user is granted with certain access
permissions.
l Post-RADIUS authentication authorization
If a user passes the authentication performed by the RADIUS server, the user is granted
with certain access permissions. That is because the authentication and authorization of the
RADIUS protocol are bound together and the RADIUS protocol cannot be used for
authorization only.
3.4.2 Introduction to RADIUS Protocol

Authentication and authorization can be implemented based on multiple types of protocols. The
most commonly used protocol is the RADIUS protocol. The RADIUS protocol was used to
manage a large number of dispersed users who use the serial ports and modems for network
access in the earlier years. Now, the RADIUS protocol is widely applied to the Network Access
Server (NAS) system.
To ask for the permission to access other networks or access certain network resources, you need
to set up a connection with the NAS through a certain network (such as the telephone network).
In this case, the NAS provides two functions:
l Authenticating users
l Helping users to connect with the RADIUS server
The NAS is responsible for transmitting the authentication and authorization information of a
user to the RADIUS server. RADIUS defines how user information is transmitted between the
NAS and the RADIUS server. The RADIUS server is responsible for:
l Receiving user connection requests
l Completing authentication
l Transmitting required configuration information to the NAS
Transactions between the NAS and the RADIUS server are identified through keys that are never
transmitted on networks. Any passwords between the NAS and the RADIUS server are
transmitted after encryption to prevent theft of passwords on insecure networks.
RADIUS Message Flow

The RADIUS protocol defines the message flow and message structure for the message
interaction between the client and server.
The server that adopts the RADIUS protocol is called RADIUS server.
Figure 3-6 shows a simple message flow defined in the RADIUS protocol.

Figure 3-6 Message flow between RADIUS client and server
Username/Password Request
User RADIUS
Access server
server
Response
When a user logs in to a network device, such as the Eudemon or an access server, the message
exchanging procedure includes the following steps:
1. The user sends the username and password to the Eudemon or the access server.
2. The RADIUS client on the Eudemon or the access server sends an authentication request
to the RADIUS server after receiving the username and password.
3. The RADIUS server authenticates the username as well as password and sends the required
authentication information to the client.
The login user can be a Point-to-Point Protocol (PPP) user who access network resources or an
administrator who configures or maintains network devices.
RADIUS Message Structure

Figure 3-7 shows the RADIUS message structure.
Figure 3-7 RADIUS message structure

0-1-2-3-4-5-6-7-0-1-2-3-4-5-6-7-0-1-2-3-4-5-6-7-0-1-2-3-4-5-6-7
Code Identifier Length
1 2 3 4 5 6
Authenticator
Attribute
The following describes the structure of a RADIUS message:

l Code
It indicates the message type, such as an access request and access permission.
l Identifier
It is usually a group of ascending figures used for matching the request packets or response
packets.
l Length
It indicates the total length of fields.
l Authenticator
It indicates the check word used to authenticate the validity of the RADIUS.
l Attribute

It indicates the content body of the message, including username, password, NAS IP address
and various attributes relative to the user.
RADIUS Features
The RADIUS protocol presents the following features:
l Excellent real-time quality brought by using the User Datagram Protocol (UDP) as a
transport protocol
l Higher reliability brought by supporting both the retransmission mechanism and the backup
server mechanism
l Easy to implement and suitable for the multithreading structure on the server
These features promote the wide use of the RADIUS protocol.
As the RADIUS client, the NAS can implement:
l Standard RADIUS protocol and its extended attributes, including RFC 2865 and RFC 2866
l Extended RADIUS+1.1 protocol of Huawei
l Proactive detection of the RADIUS server status
If the current status of the RADIUS server is Down, the broadband access server starts the
detection process upon receiving an authentication message, converts the message into a
detection packet, and then sends the packet to the RADIUS server. If the RADIUS server
responds, the broadband access server regards the RADIUS server as available.
l Automatic switchover function of the RADIUS server
In the case that the waiting timer expires and the current server is in the Down state or the
number of the sending attempts exceeds the retransmission threshold, the system selects
another server from the configured server group for sending the packet.
3.4.3 Introduction to HWTACACS Protocol

The HWTACACS protocol is an enhanced security protocol developed based on TACACS (RFC
1492). Similar to the RADIUS protocol, HWTACACS adopts the client/server mode to realize
multiple authentication and authorization functions. HWTACACS can be used for
authenticating, authorizing, and accounting PPP user, Virtual Private Dial Network (VPDN)
access user, and login users.
Compared with the RADIUS protocol, HWTACACS features reliable transmission and
encryption; it, therefore, is more practical for security control.
Table 3-2 lists the differences between the HWTACACS and RADIUS protocols.
Table 3-2 Differences between HWTACACS and RADIUS
HWTACACS RADIUS
TCP-based transmission. Therefore, it is more UDP-based transmission.

reliable.
Encrypts the whole body of a packet besides a Encrypts only the password field of an
standard HWTACACS header. authentication packet.

HWTACACS RADIUS
Authentication and authorization are Authentication and authorization are

separated. processed together.
Practical for security control. Practical for accounting.
Supports authorization-based configuration Not support authorization-based

commands. configuration commands.
Since the authentication and authorization of HWTACAS are separated, you can use the
RADIUS protocol for authentication, and use HWTACACS for authorization.
3.4.4 Introduction to Domain

The Eudemon manages users by domains. In a domain, you can configure the default
authorization, RADIUS or HWTACACS templates, and authentication and accounting schemes.
The Eudemon manages users through the following two planes:
l Management through domains
l Management through user accounts
Each user belongs to a certain domain.

In a domain, you can configure settings such as:
l Default authorization
l RADIUS or HWTACACS template
l Authentication scheme
The authorization precedence configured within a domain is lower than that configured on an
authentication and authorization server, that is, the authorization attribute of the authentication
and authorization server is used preferentially. The domain authorization attribute is valid only
when the authentication and authorization server is not of this authorization or does not support
this authorization. This processing mechanism offers more flexibility in using domains to adding
services, thus eliminating the restriction of attributes provided by servers.
In the scenario where a domain and a user within the domain are configured with different
attributes, user-based configuration is used preferentially. Namely, the precedence of the user-
based configuration is higher than that of the domain-based configuration.
3.4.5 Introduction to Local User Management

You can not only create a local user database on the Eudemon for user information maintenance
and user management, but also perform local authentication.
So far, the Eudemon provides two ways to configure local users:
l Single user configuration
l Batch user configuration based on VLAN
NOTE
Users with information kept on the local user database are local users.

3.5 P2P Traffic Limiting

Peer to Peer (P2P) protocols are widely used in downloading on the network. The constant
increase of P2P traffic affects normal operation of other network applications and increases the
costs of network operation, especially for enterprises and operators who are charged by traffic.
To address this problem, the Eudemon is designed with the P2P traffic limiting function.
3.5.1 Introduction to P2P Traffic Limiting
The Eudemon can accurately identify P2P traffic on networks through in-depth detection and
behavior detection, and then limit the traffic according to the configured traffic limiting policies.
In addition, the Eudemon can produce detailed statistics on traffic of various P2P protocols to
facilitate monitoring of P2P traffic tendency.
3.5.2 P2P Traffic Detection and Limiting
The Eudemon detects P2P traffic and then limits it.
3.5.1 Introduction to P2P Traffic Limiting

The Eudemon can accurately identify P2P traffic on networks through in-depth detection and
behavior detection, and then limit the traffic according to the configured traffic limiting policies.
In addition, the Eudemon can produce detailed statistics on traffic of various P2P protocols to
facilitate monitoring of P2P traffic tendency.
The P2P traffic limiting function can control P2P traffic and guarantee normal running of other
services. The P2P traffic limiting function of the Eudemon can work jointly with ACL rules and
time segment-based rate control to restrict P2P traffic, thus satisfying customers' specific
requirements.
The P2P traffic limiting function can be widely applied to access networks carrying high volumes
of P2P traffic such as community network, campus network, and enterprise intranet.
The Eudemon can limit traffic of various P2P protocols, such as BT, PPLive, PPStream, and
QQLive.
When excessive packets of each type of protocols are detected, the performance is degraded.
Therefore, the Eudemon supports setting of the number of packets to be detected for each type
of P2P protocol to meet different identification requirements.
When the current Eudemon cannot identify certain P2P traffic, it obtains new mode files to limit
the traffic.
3.5.2 P2P Traffic Detection and Limiting

The Eudemon detects P2P traffic and then limits it.
P2P Traffic Detection

If P2P traffic limiting policies are configured or P2P detection is enabled, the Eudemon detects
the sessions to identify P2P traffic.
When a session is identified as P2P traffic, its source IP address, source port number, destination
IP address, and destination port number are recorded in the relation table. If the IP address and
port number of a new session match those in the relation table, the session is identified as P2P
traffic. This reduces the burden of in-depth detection.

The Eudemon supports two modes of detection, namely, in-depth detection and behavior
detection. At present, in-depth detection is mostly used. If in-depth detection is not satisfactory
enough, you can configure behavior detection. Behavior detection mainly detects encrypted data
traffic.
P2P Traffic Limiting

If P2P traffic Limiting policies are configured and a session is certainly that of P2P traffic, the
Eudemon limits the P2P traffic according to the policies.
The Eudemon supports flexible traffic limiting modes. It can limit traffic based on either the
default traffic rate or the traffic rate set for a specific time range.
The Eudemon also supports global traffic limiting and interzone traffic limiting. You can
associate ACL rules with traffic limiting policies for interzones and specify the users whose P2P
traffic are to be limited.
NOTE
If you are to detect or limit P2P traffic for a specific interzone, you can configure only related detection
and limiting policies for this interzone to improve the performance. Then, the Eudemon does not detect or
limit P2P traffic in other interzones.
3.6 IP-CAR
IP-CAR limits IP bandwidths and the number of IP connections.
The IP-CAR function includes the following aspects:
l IP connection number restriction: limits the number of connections initiated or agreed by
a specific IP address.
IP connection number restriction can help prevent users from launching attacks and protect
certain users against attacks.
l IP bandwidth restriction: limits the session bandwidth of a specific IP address.
Bandwidth restriction can help average network traffic, ensure normal access rate, and
defend network against attacks.
The bandwidth and connection number restrictions of the Eudemon both present eight levels.
You can set a proper level for connection number restriction or bandwidth restriction by
considering ACL restriction on connection number or on bandwidth.
3.7 TSM Cooperation

As a Security Access Control Gateway (SACG), the Eudemon cooperates with the TSM terminal
security management system to control terminal users' access to networks based on specific
classification of these users.
3.7.1 Introduction to TSM Cooperation
To clear hazards to network information security, the Eudemon cooperates with the TSM
terminal security management system to control network access and protect network resources.
3.7.2 Work Flow of TSM Cooperation
The Eudemon establishes connections with the TSM terminal security management system,
synchronizes the control polices on the TSM server, and then controls users' access according
to the policies returned from the TSM server.

3.7.3 Specifications of TSM Cooperation

This describes the specifications of the cooperation between the Eudemon and the TSM,
including the maximum number of online users, maximum number of roles, and so on.
3.7.1 Introduction to TSM Cooperation

To clear hazards to network information security, the Eudemon cooperates with the TSM
terminal security management system to control network access and protect network resources.
Networks have become an indispensable part for enterprises. However, they also expose
enterprises to various security threats, such as:
l Internal employees steal confidential information for their own interests.

l Internal employees access enterprise application systems to tamper with important data
without permission.
l Illegal accounts access the enterprise networks and insecure terminals access networks.
To solve these problems, the Eudemon cooperates with the TSM server to protect important
network resources. By working jointly with a TSM server, the Eudemon can classify internal
users and control their access to resources based on their permission classes. This mechanism
helps ensure that a user can access only authorized resources, thus preventing unauthorized
internal users from accessing confidential data or applications.
Figure 3-8 shows a specific networking.
Figure 3-8 Networking diagram of TSM Cooperation

Service server C Service server B
Agent 2
Service server A
TSM
manager
Eudemon(SACG)
Agent 1
TSM
SRS
controller
TSM security access control system
Security Recover Server (SRS) TSM Agent (Agent)
NOTE
For information about the functions of each part, refer to TSM server-related documents.

3.7.2 Work Flow of TSM Cooperation

The Eudemon establishes connections with the TSM terminal security management system,
synchronizes the control polices on the TSM server, and then controls users' access according
to the policies returned from the TSM server.
As shown in Figure 3-8, the Eudemon functions as the SACG and cooperates with the TSM to
control users' network access and provide terminal users with services through the service server.
NOTE
Terminal users can obtain the right to access network resources by means of either the TSM agent or Web. The
previous methods have the same operation procedure. The following describes the operation procedure of the
TSM agent.
To access network resources, a terminal user goes through the following steps:
1. The terminal user starts the TSM agent and enters the authentication information for the
TSM server to authenticate. The authentication modes are as follows:
l Domain authentication
l Username and password authentication
l MAC address authentication
l Other authentication modes
2. The TSM agent sends the information about the terminal user to the TSM server for
authentication and security checks.
l If the user is legitimate and the security policy meets the requirement of the enterprise,
the user can use the network.
l If the user is not legitimate or the security policy does not meet the requirement of the
enterprise, the TSM agent triggers an alarm to the user, and the Security Recover Server
(SRS) proposes corresponding recovery.
After recovery, the preceding process takes place again. The terminal user can obtain
certain network resources only when its security meets the requirement.
3. After the terminal user passes the authentication and security check, the TSM server asks
the Eudemon to grant the user certain access rights.
4. The Eudemon determines according to the access rights delivered by the TSM server
whether the terminal user can obtain specific network resources. If yes, the Eudemon allows
the user to obtain the resources; if not, the user cannot obtain the resources.
5. When the terminal user logs out, the TSM agent reports the logout to the TSM server. After
the user logs out, the TSM server asks the Eudemon to disable the user's access.
When the terminal user accesses the network resource again, it need be authenticated again.
In addition, a synchronization mechanism between the Eudemon and the TSM server ensures
that the Eudemon can synchronize the updates and changes of users' role information on the
TSM server.
NOTE
According to the rule of roles, the Eudemon determines whether a user has the authority to access the
service server. Terminal users can access network resources matching their authority.

3.7.3 Specifications of TSM Cooperation

This describes the specifications of the cooperation between the Eudemon and the TSM,
including the maximum number of online users, maximum number of roles, and so on.
Interworking with the TSM, the Eudemon supports a maximum of 2500 online users. The
Eudemon supports 900 common roles and 1 default role. One user can have multiple roles; one
role can corresponds to multiple users. One user can have a maximum of 16 roles.
NOTE
Based on its authority, the administrator can define different roles and grant access rights to roles. The
administrators with the same role enjoy the same operation rights. When creating an administrator account,
the administrator need only specify roles for the account, which automatically gain all the operation rights
of the roles. Granting rights in this way saves repeated operations and reduces the burden of account
management.
3.8 SLB
In the current network application, especially in Internet Data Center (IDC) and websites, the
processing capability of a single server has become the bottleneck of the network. The
Eudemon can solve the above problems through Server Load Balancing (SLB).
3.8.1 Introduction to SLB
Based on configured load balancing algorithm, the Eudemon can distribute traffic destined to
the same IP address to several servers.
3.8.2 Virtual Service Technology
The virtual service technology refers to sharing of one public IP address (the virtual IP address)
among multiple servers. By accessing the public IP address, users can access the contents on the
real server.
3.8.3 Server Health Check
Server health check is part of the SLB function. Through using server health check, the
Eudemon improves the availability of the system and ensures the effectiveness of each
connection. Thus, servers can offer services properly.
3.8.4 Traffic-based Forwarding
Through specifying the algorithm, the Eudemon sends data streams to each real server to process
them. So far, the Eudemon supports three SLB algorithms, that is, source address hash, round,
and weighted round.
3.8.1 Introduction to SLB

Based on configured load balancing algorithm, the Eudemon can distribute traffic destined to
the same IP address to several servers.
To the users, they are accessing the same server. In fact, the Eudemon distributes their requests
to several servers for processing. In this way, the processing capacity of each server is fully
exploited and load balancing is accomplished. In addition, the availability of the server is
guaranteed and the best network expansibility is achieved.
In the typical application of SLB, the Eudemon is located in the egress of the private network.
The load balancing mechanism distributes users' traffic to servers in the following ways:
l Virtual Service Technology

l Server Health Check

l Traffic-based Forwarding
3.8.2 Virtual Service Technology

The virtual service technology refers to sharing of one public IP address (the virtual IP address)
among multiple servers. By accessing the public IP address, users can access the contents on the
real server.
Every real server has a unique private IP address (real IP address). However, all the real servers
are represented by one public IP. The public IP maps a virtual server. The Eudemon distributes
the traffic accessing the virtual server to each real server by using the configured load balancing
algorithm.
For the sake of management, a group is used to connect the virtual server and the real server.
Group is a logic concept. The Eudemon uses a group to manage real servers and offers network
services.
The relationship between the virtual server, the group, and the real server is shown in Figure
3-9.
Figure 3-9 Schematic diagram of Virtual Service
Rserver1
Group1
Rserver2
Vserver1
Vserver2 Rserver3
PC
Group2
Rserver4
The advantages of the virtual service are as follows:

l Saving the IP address of the public network
l Improving the security of the system
l Improving the expandability of the system

3.8.3 Server Health Check

Server health check is part of the SLB function. Through using server health check, the
Eudemon improves the availability of the system and ensures the effectiveness of each
connection. Thus, servers can offer services properly.
The Eudemon completes health check through detecting real servers regularly. If the real server
is available, it returns response packets. If not, the Eudemon does not use this real server and
instead it assigns traffic to other real servers based on the configured policies.
3.8.4 Traffic-based Forwarding

Through specifying the algorithm, the Eudemon sends data streams to each real server to process
them. So far, the Eudemon supports three SLB algorithms, that is, source address hash, round,
and weighted round.

Feature Description 4 Internetworking
4 Internetworking
About This Chapter
This describes the configurations of the routing function of the Eudemon by focusing on the
internetworking capability of the Eudemon. Here, the Eudemon can be considered as a router.
Terms and identifiers in the router field are used to describe the Eudemon. That is, the router
mentioned in the following part can be replaced by the Eudemon.
4.1 VLAN
4.2 PPP
4.3 PPPoE
4.4 DHCP
4.5 IP Static Route
4.6 RIP
4.7 OSPF
4.8 Introduction to Policy-Based Routing
4.9 QoS

4 Internetworking Feature Description
4.1 VLAN
4.1.1 Introduction
4.1.2 Advantages of VLAN
4.1.1 Introduction
Potential Problems in LAN Interconnecting

The Ethernet is a kind of data network communication technology, which is based on the shared
communication medium of Carrier Sense Multiple Access with Collision Detection (CSMA/
CD). Under CSMA/CD, each node uses the shared medium to send frames in turn. Thus, in a
moment, only one host can send frames while other hosts can only receive frames.
When many hosts are connected to the hub (with star topology) through the twisted pairs, or
connected by the coaxial cables (with bus topology), all the hosts interconnected to the shared
physical media forms a physical collision domain. That is usually regarded as a LAN
segmentation.
l Severe collision
l Flooding broadcast
l Performance reduction
l Unavailability of network
The above problems can be solved by using the Transparent Bridge or LAN switch to
interconnect the LANs.
Although the switch has solved the problem of severe collision caused by using hub, it still
cannot separate the broadcast. In fact, all the hosts (perhaps including many switches)
interconnected by switches are in one broadcast domain. For the broadcast packets with
"f" (0xffffffffffff) as their destination MAC address, such as the ARP request packet, the switch
will forward them to all the ports. In this case, the broadcast storm will be caused and the
performance of the entire network will be degraded.
VLAN Principle and Division

The LAN interconnection by means of switches cannot restrict the broadcast. The technology
of Virtual Local Area Network (VLAN) comes into being to solve the problem.
In this way, one LAN is divided into several logical "LANs" (VLANs), with each VLAN as a
broadcast domain. In each VLAN, the hosts can communicate with each other just as they are
in a LAN, but the VLANs cannot interact with one another directly. Therefore, the broadcast
packets are restricted in one VLAN, as shown in Figure 4-1.

Figure 4-1 Example of VLAN
LAN Switch
VLAN 10
LAN Switch
VLAN 20
Router
The buildup of VLAN is not restricted by physical locations, that is, one VLAN can be within
one switch or across switches, or even across routers.
The VLAN can be classified based on the following aspects:
l Port
l MAC address
l Protocol type
l IP address mapping
l Multicast
l Policy
At present, the VLAN is usually classified based on the port. In this manual, the VLANs are all
classified based on the port except special declaration.
4.1.2 Advantages of VLAN
The advantages of using VLAN are listed as follows:
l It can restrict broadcast packets (broadcast storm), save the bandwidth and thus improve
the performance of the network.
The Broadcast domain is restricted in one VLAN and the switch cannot directly send frames
from one VLAN to another except that it is a layer 3 switch.
l It can enhance the security of LAN.
VLANs cannot directly communicate with one another, that is, the users in one VLAN
cannot directly access those in other VLANs. They need help of such layer 3 devices as
routers and Layer 3 switches to fulfill the access.
l It provides the virtual workgroup.
VLAN can be used to group users to different workgroups. When the workgroups change,
the users need not change their physical locations. In the application, users of the same

workgroup usually cooperate with each other at the same place, and there are few cases
that users are in different places.
On a switch, the common ports can only belong to one VLAN, that is, they can only identify
and send packets of the VLAN they belong to. However, when the VLAN is across switches, it
is necessary that the ports (links) among the switches can identify and send packets of several
VLANs at the same time. The same problem exists among the switches and routers that support
VLAN.
The link of this type is called Trunk, which has two meanings:
l Trunking
Namely, the VLAN packets are transparently transmitted to the interconnected switches or
routers to extend the VLAN.
l Super trunk
Namely, several VLANs run on such a link.
The common protocol used to implement Trunk is IEEE 802.1Q (dot1q) that is a standard
protocol of IEEE. It identifies the VLAN by adding a 4-byte VLAN tag to the end of the source
address field in the original Ethernet packet.
VLANs cannot directly interconnect with each other. So routers supporting VLAN must be used
to connect each VLAN to implement the interconnection among VLANs. Usually, this is a kind
of layer 3 (IP layer) interconnection.
4.2 PPP
4.2.1 Introduction
4.2.2 PPP Authentication
4.2.3 PPP Link Operation
4.2.1 Introduction
The Point-to-Point Protocol (PPP) is one of the link layer protocols that bear network layer
packets over the point-to-point link.
It has been widely used for the following reasons:
l Providing user authentication function

l Supporting the synchronous and asynchronous communication
l Being expanded easily
PPP is located on the data link layers of both Open Systems Interconnection (OSI) and the TCP/
IP protocol stack. PPP supports synchronous and asynchronous full-duplex links in transmitting
data in a P2P way.
PPP mainly consists of the following three protocols:
l The Link Control Protocol (LCP) suite: This protocol suite is responsible for establishing,
removing, and monitoring data links.

l The Network Control Protocol (NCP) suite: This protocol suite is responsible for
negotiating the format and type of packets transmitted over a data link.
l PPP extended protocol suite: This protocol suite such as PPPoE provides extended PPP
functions. With the development of network technologies, network bandwidth is no longer
a bottleneck. PPP extended protocol suite, therefore, is rarely used nowadays.
In addition, PPP provides the authentication protocols: Password Authentication Protocol (PAP)
and Challenge-Handshake Authentication Protocol (CHAP).
4.2.2 PPP Authentication
PAP Authentication Process

PAP is the authentication of two-way handshake. In PAP authentication, the password is in plain
text. The authentication process is performed in the Establish phase.
After the Establish phase finishes, the user name and password of the authenticated are repeatedly
sent to the authenticator until the authentication succeeds or the link is ended.
PAP authentication is the optimal option in the case that the plain password must be used in the
simulated login on a remote host.
l The authenticated sends the local user name and password to the authenticator.
l The authenticator checks the user list for the user name and whether the password is correct,
and then returns different responses:
PAP is an unsecured protocol. In PAP authentication, passwords are sent over links in plain text.
After a PPP link is established, the authenticated repeatedly sends the user name and password
until the authentication finishes. The malicious attack, therefore, cannot be avoided.
CHAP Authentication Process

The Challenge Handshake Authentication Protocol (CHAP) is a authentication protocol of three-
way handshake. In CHAP authentication, only the user name is transmitted in a network.
Compared with PAP, CHAP features higher security because passwords are not transmitted.
The CHAP negotiation is complete before a link is set up. After a link is set up, CHAP
authentication can be performed anytime through the CHAP negotiation packets.
After the Establish phase, the authenticator sends a Challenge packet to the authenticated. After
performing the "one-way Hash" algorithm, the authenticated returns a calculated value to the
authenticator.
The authenticator compares the value calculated by itself through the Hash algorithm with the
value returned by the authenticated. If the two values are matched, the authentication succeeds.
Otherwise, the authentication fails and the link is torn down.
CHAP authentication is divided into the following two modes:
l Unidirectional CHAP authentication: In this mode, one end acts as the authenticator, while
the other end acts as the authenticated.
l Bidirectional CHAP authentication: In this mode, two ends act as both the authenticator
and the authenticated.
The unidirectional CHAP authentication can be applied in two cases, namely, the authenticator
is configured with the user name and the authenticator is not configured with the user name. The

authentication with the authenticator being configured with the user name is recommended
because the user name of the authenticator can be confirmed.
l Process of the authentication with the authenticator being configured with the user name
The process of the authentication with the authenticator being configured with the user
name is as follows:
– The authenticator sends the authenticated the randomly generated Challenge packet and
the local host name.
– After receiving the Challenge packet, the authenticated searches the local user list for
the local password according to the user name of the authenticator. Based on the located
password and the Challenge packet, the authenticated obtains a value through the MD5
algorithm, and then sends the value and its own host name to the authenticator through
the Response packet.
– The authenticator receives the Response packet. According to the carried host name of
the authenticated, the authenticator searches the local user list for the password of the
authenticated. After locating the password, the authenticator uses the Challenge packet
and the password of the authenticated to obtain a value through the MD5 algorithm,
compares the value with that in the received Response packet, and then returns the
authentication result, that is, allow or deny.
l Process of the authentication with the authenticator being not configured with the user name
If the authenticator is not configured with the user name, the authenticator sends only the
Challenge packet to the authenticated. Based on the password set on the local interface and
the Challenge packet, the authenticated obtains a value through the MD5 algorithm, and
then sends the value and its own host name to the authenticator. The other procedures are
the same as those in the process of the authentication with the authenticator being
configured with the user name.
4.2.3 PPP Link Operation

PPP links can be set up only after a series of successful negotiations.
l LCP negotiation: Besides establishing, closing, and monitoring PPP data links, LCP
negotiates link layer parameters such as MRU and authentication mode.
l NCP negotiation: NCP negotiates formats and types of packets transmitted over the data
links. IP addresses are also negotiated in NCP negotiation.
To set up P2P connection through PPP, the devices on two ends must send LCP packets to set
up the P2P link.
After the LCP configuration parameters are determined through negotiation, the two
communicating devices choose the authentication mode according to the authentication
parameters in the Configure-Request packets.
By default, the devices on the two ends do not authenticate each other. After the negotiation of
the LCP configuration parameters, the devices negotiate NCP configuration parameters without
any authentication. After all the negotiations, the two devices on the P2P link can transmit
network-layer packets. At this time, the whole link is available.
If any end receives a packet that initiates an LCP or NCP close, if the carrier cannot be detected
at the physical layer, or if the maintenance personnel closes the link, the link is torn down and
the PPP session thus is terminated. Typically, NCP should not necessarily has the capability in
closing links. Therefore, the packet used to close a link is usually sent during the LCP negotiation
or application program session.

Figure 4-2 shows the setup process of a PPP session and the status transition in the whole process.
Figure 4-2 Operation process of PPP
UP OPENED
Dead Establish Authenticate
FAIL
FAIL
SUCCESS
DOWN CLOSED
Terminate Network
The PPP operation process is described as follows:
1. The Establish phase is the first phase to set up a PPP link.

2. During the Establish phase, the LCP negotiation is performed. The negotiation involves
the options such as the working mode, which is either Single-link PPP (SP) or Multilink
PPP (MP), MRU, authentication mode, magic number, and asynchronous character
mapping. After the LCP negotiation succeeds, the LCP status turns Opened, which indicates
the bottom layer is established.
3. If no authentication is configured, the communicating devices directly enter the NCP
negotiation phase. If authentication is configured, the communicating devices enter the
Authentication phase and perform CHAP authentication or PAP authentication.
4. If the authentication failed, the devices enter the Terminate phase, and then remove the
link. At this time, LCP status turns Down. If the authentication succeeds, the devices enter
the NCP negotiation phase. The LCP status remains Opened, while the NCP status turns
Starting from Initial.
5. The NCP negotiation includes IPCP, MPLSCP, and OSCICP negotiations. The IPCP
negotiation mainly involves the negotiation of the IP addresses of the two ends. A network
layer protocol is chosen and configured through the NCP negotiation. The network layer
protocol can send packets over the PPP link only after the negotiation of the network layer
protocol succeeds.
6. The PPP link remains in the normal state until an LCP or NCP frame aiming at closing the
link is generated or some forcible interruptions occur.
PPP undergoes the following phases during the configuration, maintenance, and termination of
a P2P link.
l Dead Phase
l Establish Phase
l Authenticate Phase
l Network Phase
l Terminate Phase

Dead Phase
The Dead phase is also called the unavailable phase of the physical layer. Setup of a PPP link
begins with and terminates at the Dead phase.
After the communicating devices on both ends detect a physical link is activated, generally, the
carrier signal is detected on the link, and the devices enter the Establish phase.
In the Establish phase, link parameters are set mainly by using LCP. The state machine of LCP
changes according to the events. If a link is in the Dead phase, the status of the LCP state machine
is Initial or Starting. After the link becomes available, the status of the LCP state machine
changes.
After a link is torn down, the link returns to the Dead phase. In actual process, this state lasts
quite short and detects only the existence of the peer device.
Establish Phase
The Establish phase is the key and most complicated phase of PPP.
In this phase, packets used to configure data links are transmitted. Those configuration
parameters do not include the parameters needed for the network layer protocol. After the packets
are exchanged, the link between the communicating devices enters the next phase.
According to user configuration, the next phase can be either the Authenticate phase or the
Network phase.
In the Establish phase, the LCP state machine changes twice.
l When the link status is unavailable, the status of the LCP state machine is Initial or Starting.
If the link is detected as available, the physical layer sends an Up event contained in a
packet to the link layer. After receiving the event, the link layer changes the status of the
LCP state machine to the Request-Sent state. Then LCP sends Configure-Request packets
to configure the data link.
l After one of the two ends receives the Configure-Ack packet, the status of the LCP state
machine changes to Opened. The link enters the next phase.
Note that the operation process of the link configuration on either end is mutually independent.
In the Establish phase, non-LCP packets are discarded after being received.
Authenticate Phase
Generally, authentication is performed before devices on both ends enter the Network phase.
By default, PPP does not involve authentication. If authentication is necessary, you must specify
the authentication protocol in the Establish phase.
PPP authentication is mainly used on the following two types of links:
l Links connected through the PPP server or dial-in access between hosts and routers in most
cases
l Private links occasionally
PPP provides the following two authentication modes:
l Password Authentication Protocol (PAP)

l Challenge-Handshake Authentication Protocol (CHAP)
The authentication mode is determined by the outcome of the negotiation in the Establish phase.
The link-quality detection is also performed in the Establish phase. According to the PPP
protocol, the detection does not unlimitedly delay the authentication process.
This phase supports only the link control protocol, authentication protocol, and quality-detection
packet. Packets of other types are discarded. If a device receives the Configure-Request packet
in this phase, the link restores the Establish state.
Network Phase
In the Network phase, network protocols such as IP, IPX, and AppleTalk are negotiated through
corresponding NCPs, which can be enabled and disabled during any phase. After a NCP state
machine turns Opened, PPP links can transmit network-layer packets.
If a device receives a Configure-Request packet in this phase, the communicating devices return
to the Establish phase.
Terminate Phase
PPP can terminate links at any time. Except that the network administrator manually closes the
links, carrier lost, authentication failure, or link-quality detection failure can lead to the end of
a link. In the Establish phase, after the exchange of LCP Terminate frames, a link is torn down
physically. NCP cannot, and does not need to close a PPP link.
4.3 PPPoE
4.3.1 Introduction
4.3.2 PPPoE Discovery Period
4.3.3 PPPoE Session Period
4.3.1 Introduction
Point-to-Point Protocol over Ethernet (PPPoE) describes the method to set up PPPoE sessions
and encapsulate PPP datagram over Ethernet. These functions require a point-to-point (P2P)
relation between the peers instead of the multi-point relationships that are available in Ethernet
and other multi-access environments. PPPoE uses Ethernets to connect a large number of hosts.
PPPoE uses a remote client to access the Internet, and implements the controlling and accounting
functions over the access hosts. With the cost-effective feature, PPPoE is widely applied in a
series of applications such as community networks.
With this model, each host uses its own PPP stack and the user is presented with a familiar user
interface. Access control, billing, and type of services can be based on each user, rather than
each site.
The access control, payment, and Type of Service (ToS) functions supported by PPPoE are based
on individual users.
PPPoE is divided into two stages: Discovery stage and PPPoE Session stage.

When a host wants to initiate a PPPoE session, it must first perform Discovery to identify the
Ethernet MAC address of the peer and set up a PPPoE Session_ID.
Although PPP defines a peer-to-peer relationship, Discovery is a client-server relationship. In

the Discovery process, a host (the client) discovers an Access Concentrator (AC) as the server.
Based on the network topology, the host may communicate with more than one AC. The
Discovery stage allows the host to discover all ACs and then select one.
When the Discovery stage is complete successfully, both the host and selected AC have the
information they use to set up P2P connection over Ethernet.
The Discovery stage remains stateless until a PPPoE session is set up. Once a PPPoE session is
set up, both the host and the AC that serves as an access server must allocate the resources for
a PPP virtual interface. After PPPoE sessions are set up successfully, the host and access server
can communicate.
Eudemon can only be PPPoE Client.
4.3.2 PPPoE Discovery Period
When the host accesses the server through PPPoE, it should identify the MAC address of the
peer before setting up the PPPoE Session_ID. This is the function of the Discovery stage.
The Discovery stage consists of four steps. When the Discovery stage completes, both peers
know the PPPoE Session_ID and the peer Ethernet address, which together define the unique
PPPoE session.
Discovery stage consists of the following four steps.
1. The host broadcasts a PPPoE Active Discovery Initial (PADI) packet within the local
Ethernet. This packet contains the service information that the host needs.
Figure 4-3 Diagram of the host sending PADI packets in broadcast
Server A
PADI
PADI PADI
Server B
PC
PADI
Server C
2. After receiving this PADI packet, all the servers on the Ethernet compare the requested
services with services they can provide. Then, the servers that can provide the requested
services send back PPPoE Active Discovery Offer (PADO) packets.
As shown in Figure 4-4, both Server A and Server B can provide services, and send back
PADO packets to the host.

Figure 4-4 Sending the PADO packet from the server
Server A
PADO-A
PADO-A PADO-B
Server B
PADO-B
PC
Server C
3. The host may receive more than one PADO packet from servers. The host looks through
the PADO packets and chooses a server. Then, the host sends a PPPoE Active Discovery
Request (PADR) packet to the server.
As shown in Figure 4-5, the host chooses Server A and sends a PADR packet to it.
Figure 4-5 Diagram of the host choosing a server and sending a PADR packet
Server A
PADR
PADR
Server B
PC
Server C
4. The server generates a unique session identifier to identify the PPPoE session with the host.
Then, the server sends this session identifier to the host through the PPPoE Active
Discovery Session-confirmation (PADS). If no error occurs, both the server and host enter
the PPPoE Session stage.
As shown in Figure 4-6, Server A sends a PADS packet to the host after receiving the
PADR packet.
Figure 4-6 Diagram of the server sending a PADS packet to the host
Server A
PADS
PADS
Server B
PC
Server C

After sending the PADS packet, the access server can enter the PPPoE Session stage. After
receiving this PADS packet, the host can enter the PPPoE Session stage.
4.3.3 PPPoE Session Period
Once a PPPoE session begins, PPP packets, as the PPPoE payload, are encapsulated in Ethernet
frames and sent to the peer. The session ID should be the ID determined in the Discovery stage.
The MAC address should be the MAC address of the peer. The PPP packets start with the protocol
ID. In the Session stage, either the host or the server can send a PPPoE Active Discovery
Terminate (PADT) packet to the peer to terminate the session.
All the Ethernet packets are unicast.
l The Ethernet_Type field is set to 0x8864.

l The PPPoE Code field must be set to 0x00.
l The Session_ID of a PPPoE session cannot be changed and must be the value specified in
the Discovery stage.
l The PPPoE payload contains a PPP frame that begins with the PPP Protocol-ID.
After entering the PPPoE Session stage, either the host or access server can send a PADT packet
to notify the peer to end the PPPoE session.
4.4 DHCP
4.4.1 DHCP Service

4.4.2 DHCP Relay
4.4.3 DHCP client
4.4.1 DHCP Service
With the rapid growth in network scale and complexity, network configuration has become more
difficult. Because the number of hosts has exceeded that of the available IP addresses, Dynamic
Host Configuration Protocol (DHCP) is created.
The DHCP works in client/server mode. With the DHCP, a client can dynamically request
configuration information from a DHCP server, including the assigned IP address, the subnet
mask, and the default gateway. The DHCP server returns the corresponding configuration
information based on a certain configuration policy to the DHCP client.
The DHCP has extended BOOTP in two aspects:
l DHCP can get all the configuration information that a host needs by sending only two
messages.
l DHCP helps the computer to get an IP address fast and dynamically, instead of specifying
an IP address for each host statically.

IP Address Assigned by DHCP

Different hosts need to occupy the IP addresses in different periods. For example:
l A server may need to occupy a fixed IP address for a long time.
l Some enterprise hosts may need to occupy a dynamically assigned IP address for a long
time.
l Some clients may need only a temporary IP address.
The DHCP server supports the following address assignation methods:

l Manual
The administrator assigns fixed IP addresses for specific hosts, such as the WWW server.
l Automatic
The server assigns long-term fixed IP addresses for some hosts when they are connected
to the network for the first time.
l Dynamic
The server assigns an IP address to a client in a leasing manner. The client needs to request
an IP address again when the service expires. This method is widely used.
Distribution Sequence of IP Addresses

The DHCP server selects IP addresses for clients in the following sequence:
l The IP address in the database of the DHCP sever is statically bound with the client's MAC
address.
l The IP address assigned to the client before. That is, the IP address in the Requested IP
Address Option that is in the DHCP Discover packet sent by the client.
l The IP address that is found first when the server searches for the available IP addresses in
the DHCP address pool.
If no IP addresses are available, the DHCP server searches the timeout IP addresses and the
collision IP addresses in turn and assigns the found IP address. Otherwise, it sends a fault report.
4.4.2 DHCP Relay

The DHCP client sends interactive messages through advertisement. Therefore, the DHCP
clients and servers can only take effect in the same sub-network rather than work in different
network segments. It is not economic.
Therefore, DHCP relay is introduced to solve the problem. That delivers relay service across
network segments between DHCP clients and servers, relaying a DHCP packet to its destination
DHCP server or client of a different network segment. In this way, multiple DHCP clients in a
network can share one DHCP server. That not only saves cost but also facilitate centralized
management. The schematic diagram of DHCP relay is as shown in Figure 4-7.

Figure 4-7 DHCP relay

DHCP client DHCP client
Ethernet
Ethernet
Eudemon
DHCP client
DHCP client DHCP server
The working principle of DHCP relay is as follows:
l After the DHCP client starts up and begins to initialize the DHCP, the configuration request
packet is broadcast in the local network.
l If there is a DHCP server in the local network, the DHCP can be configured without need
of the DHCP relay.
l If there is no DHCP server in the local network, the network device with the DHCP relay,
which is connected with the local network, will forward the packets to the specific DHCP
servers in the other networks after it receives and processes the broadcast packets properly.
l Based on information offered by the client, the server sends configuration information to
the client via DHCP relay. Thus, dynamic configuration of client finishes. Actually, several
such interactive processes are needed from the start to the end of the configuration.
In nature, DHCP relay fulfills the transparent transmission of DHCP broadcast packets; that is,
transparently send broadcast packets of the DHCP client (or the DHCP server) to the DHCP
server (or the DHCP client) on other network segments.
In actual practice, the DHCP relay function is usually implemented on the specific interface of
a Eudemon. To realize the DHCP function on an interface, you need to assign an IP relay address
to the interface for specifying the DHCP server.
4.4.3 DHCP client
A typical DHCP application usually requires one DHCP server and multiple clients. The DHCP
clients exchange different information with the server in different phases to obtain the valid and
dynamic IP addresses. The following describes the common application scenarios in actual
practice.
l DHCP Client Logging In to the Network for the First Time

l DHCP Client Logging In to the Network Again
l DHCP Client Prolongs the IP Address Lease Duration
DHCP Client Logging In to the Network for the First Time

When the DHCP client logs in to the network for the first time, it sets up a connection with the
DHCP server after four phases:

l DHCP discovery: In this phase, the DHCP client looks for the DHCP server. When the
client starts and changes to the initialization status, it sends a DHCPDISCOVER broadcast
message to the DHCP server.
l DHCP offers: In this phase, the DHCP server provides an IP address. After the DHCP
server receives the DHCPDISCOVER message from the client, it extends an IP lease offer.
The DHCP server selects an available IP address (not assigned) from the IP address pool
and assigns the IP address to the client by sending a DHCPOFFER message to the client.
The message contains the IP address leased and other settings.
l DHCP requests: In this phase, the DHCP client selects an IP address. If several DHCP
servers send the DHCPOFFER messages to the client, the client accepts only the first
DHCPOFFER message. The client then broadcasts a DHCPREQUEST message to each
DHCP server and changes to the request status. The DHCPREQUEST message contains
the IP address of the DHCP server that made the offer.
l DHCP acknowledgement: In this phase, the DHCP server confirms the IP address. After
the DHCP server receives the DHCPREQUEST message from the client, it sends a
DHCPACK message to the client. The message includes the IP address and other settings.
Then, the DHCP client binds the TCP/IP components to the network adapter and then
changes to the binding status.
Except the server selected by the DHCP client, the other DHCP servers with unassigned IP
addresses can still offer IP addresses for other clients.
DHCP Client Logging In to the Network Again

When the DHCP client logs in to the network again, it sets up a connection with the DHCP server
after the following phases:
l After the DHCP client correctly logged in to the network for the first time, when it tries to
log in to the network again, it changes to the restart and initialization status. Under this
status, the DHCP clients needs only to directly send the DHCPREQUEST broadcast
message, which contains the IP address obtained during last login. After the DHCP client
sends the DHCPREQUEST message, it waits for the response of the DHCP server.
l After the DHCP server receives the DHCPREQUEST message, if the IP address requested
by the client is not assigned, the DHCP server sends a DHCPACK message to the client,
telling the DHCP client to go on to use this IP address. After receiving the DHCPACK
message from the DHCP server, the client changes to the binding status.
l If this IP address cannot be assigned to the DHCP client any more (for example, it is
assigned to another client already), the DHCP server sends a DHCPNAK message to the
client. After receiving the DHCPNAK message, the client changes to the initialization
status. In this case, the client resends a DHCPDISCOVER message to request for a new IP
address. The following procedures are the same as those during the first login.
DHCP Client Prolongs the IP Address Lease Duration

The DHCP server specifies a lease duration when assigning a dynamic IP address to a client.
After the lease expires, the server retracts the IP address. If the DHCP client needs to keep this
IP address, it should renew the IP lease (for example, to prolong the IP address lease).
After the DHCP client obtains an IP address and changes to the binding status, it sets three timers
to control lease renewal, perform rebinding, and identify whether the lease expires. When the
DHCP server assigns an IP address to a client, it specifies specific values for the timers. If the
server does not set the values for the timers, the client uses the default settings. Table 4-1 shows
the default settings of the timers.

Table 4-1 Values of the timers

Timer Value
Lease renewal It should be half of the total lease duration.
Rebinding It should be 87.5% of the total lease duration.
Lease expiry Total lease duration
l When the Lease renewal timer expires, the DHCP client should renew the IP address. The
DHCP client automatically sends a DHCPREQUEST message to the DHCP server that
assigned the IP address, and then the client changes to the renewal status. If the IP address
is valid, the DHCP server responds to the client with a DHCPACK message, telling the
client that the new IP lease is granted. Then the client changes to the binding status again.
If the client receives a DHCPNAK message from the DHCP server, it changes to the
initialization status.
l After the client sends a DHCPREQUEST message for prolonging the lease duration, it
keeps in the renewal status, waiting for a response from the server. If the client does not
receive any response from the server till the Rebinding timer expires, the client assumes
that the original DHCP server is unaccessible and then sends a DHCPREQUEST broadcast
message.
Any DHCP server on the network can respond to the request of the client and send a
DHCPACK or DHCPNAK message to the client.
If the client receives a DHCPACK message, it changes to the binding status and re-sets the
Lease renewal and Rebinding timers.
If the messages received by the client are all DHCPNAK messages, it changes to the
initialization status. In this case, the client should stop using this IP address immediately
and change to the initialization status to apply for a new IP address.
l If the client does not receive any response before the Lease expiry timer expires, it should
stop using this IP address immediately and change to the initialization status to apply for
a new IP address.
4.5 IP Static Route
4.5.1 Static Route

4.5.2 Default Route
4.5.1 Static Route

In a simpler network, you only need to configure the static routes to make the router work
normally.
The proper configuration and usage of the static route can not only improve the network
performance but also ensure the bandwidth of the important applications.
The disadvantage of static route lies in that when a fault occurs on the network, the static route
cannot automatically change to keep itself away from the fault-causing node when the help of
administrator is unavailable.

Composition of a Static Route

You can use the ip route-static command to configure a static route. A static route includes the
following elements:
l Destination Address and Mask

In the ip route-static command, the destination IP address is in a dotted decimal format.
The subnet mask can be in a dotted decimal format or be represented by the mask length.
l Outbound Interface and Next Hop Address
When configuring a static route, you can specify interface-type interface-number or
nexthop-address according to actual situation.
Actually, each route entry must have a next hop address. When sending a packet, the router
searches for the corresponding route in the routing table according to the destination
address. The link layer can find the corresponding link layer address and forward the packet
only when the next hop address is specified.
When specifying the transmission interface, note the following:
l For point-to-point interfaces, the next hop address is specified implicitly in the specified
transmission interface. The address of the peer interface connected with this interface is
the next hop address. PPP, for example, the peer IP address is obtained through PPP
negotiation. In this case, you only need to specify the transmission interface without the
next hop address.
l For Non-Broadcast Multiple Access (NBMA) interfaces such as ATM interfaces, they
support point-to-multipoint networks. Therefore, in actual application, you need to not only
configure IP routing but also set up the secondary route at the link layer, that is, the mapping
between the IP address and the link layer address. In this case, you need to configure the
next hop IP address.
l In static route configuration, you should not specify the Ethernet interface as the
transmission interface. The Ethernet interface is a broadcast interface. As a result, many
next hops exist and a unique next hop cannot be determined. However if you have to specify
a broadcast interface (such as an Ethernet interface) as the transmission interface, the next
hop address should be specified at the same time.
Other Attributes
The static route has the following attributes:
l Reachable route
Normal routes belong to this case. IP packets are sent to the next hop according to the route
determined by the destination IP address. The static route is commonly used in this way.
l Unreachable route
When the static route of a certain destination IP address has the "reject" attribute, all IP
packets to the destination IP address are discarded and the source host is notified that the
destination IP address is unreachable.
l Blackhole route
When the static route of a certain destination IP address has the "blackhole" attribute, all
IP packets to the destination IP address are discarded and the source host is not notified.
The "reject" and "blackhole" attributes are used to control the range of the reachable
destination IP address of the router and to help analyze the network faults.

4.5.2 Default Route

In a word, a default route is a route used only when no routing table entry is matched. That is,
the default route is used only when no proper route is found.
In a routing table, the default route is the route to the network 0.0.0.0 (with the mask 0.0.0.0).
Using the display ip routing-table command, you can check whether the default route is
configured. If the destination address of a packet does not match any entry in the routing table,
the router selects the default route to forward this packet. If there is no default route, and the
destination address of the packet does not match any entry in the routing table, the packet is
discarded. An Internet Control Message Protocol (ICMP) packet is then sent to inform the source
host that the destination host or network is unreachable.
4.6 RIP
4.6.1 RIP Overview

4.6.2 RIP Versions
4.6.3 RIP Startup and Operation
4.6.1 RIP Overview

Routing Information Protocol (RIP) is a relatively simple dynamic routing protocol and is mainly
applied to small-sized networks such as campus networks.
RIP is a kind of Distance-Vector (D-V) algorithm-based protocol and exchanges the routing
information through the UDP packets. It employs the hop count to measure the distance to the
destination host, which is called routing cost.
In RIP, the hop count from a router to its directly connected network is 0, and that to a network
which can be accessed through another router is 1. To restrict the time to converge, RIP prescribes
that the cost is an integer in the range of 0 to 15. The hop count equal to or more than 16 is
defined as infinite, that is, the destination network or the host is inaccessible.
RIP sends route refreshment packets every 30 seconds. If the route cannot receive the route
refreshment packets from some network neighbor within 180 seconds, it marks all routes in this
network neighbor to be unreachable. If the route can still not receive route refreshment packets
within 300 seconds, it will clear all routes of this network neighbor from the routing table.
To improve performance and avoid the creation of routing loop, RIP supports split horizon.
Besides, RIP can also import routes from other routing protocols.
Each router running RIP manages a route database, which contains routing entries to all the
reachable destinations in the network.
l Destination address
Refer to the IP address of a host or a network.
l Next hop address
Refer to the address of the next router that a router will pass through for reaching the
destination.

l Interface
Refer to the interface through which the IP packet should be forwarded.
l Cost
Refer to the cost for the router to reach the destination, which should be an integer in the
range of 0 to 16.
l Timer
Refer to duration from the last time that the routing entry is modified till now. The timer
is reset to 0 whenever a routing entry is modified.
l Route flag
Refer to a label to distinguish routes of internal routing protocols from those of external
routing protocols.
4.6.2 RIP Versions
There are two RIP versions: RIP-1 and RIP-2.
l RIP-1 supports broadcasting protocol packets.

l RIP-2 transmits packets in two modes, the broadcast mode and the multicast mode. By
default, packets are transmitted in multicast mode using the multicast address 224.0.0.9.
The advantages of multicast message transmitting are:
– In the same network segment, those hosts that do not run RIP can avoid receive RIP
broadcasting message.
– Multicast message can prevent hosts running RIP-1 from falsely receiving and
processing subnet mask route in RIP-2.
4.6.3 RIP Startup and Operation
The whole process of RIP startup and running can be described as follows.
1. When RIP is just enabled on a router, request packet is forwarded to a neighbor router in
broadcast mode. After the neighbor router receives the packet, it responds to the request
and resends a response packet containing information in the local routing table.
2. When the router receives the response packet, it modifies its local routing table and
meanwhile sends a modification triggering packet to the neighbor router and broadcast the
route modification information. Upon receiving the modification triggering packet, the
neighbor router will send it to all its neighbor routers. After a series of modification
triggering broadcast, each router can get and keep the updated routing information.
3. At the same time, RIP broadcasts its routing table to the adjacent routers every 30 seconds.
The adjacent routers will maintain their own routing tables after receiving the packets and
will select an optimal route, and then advertise the modification information to their
adjacent networks so as to make the updated route globally known. Furthermore, RIP uses
the timeout mechanism to handle the timeout routes so as to ensure the real time and validity
of the routes.
RIP is adopted by most of IP router suppliers. It can be used in most of the campus networks
and the regional networks that are simple and extensive. For larger and more complex networks,
RIP is not recommended.

4.7 OSPF
4.7.1 OSPF Overview

4.7.2 Process of OSPF Route Calculation
4.7.3 Basic Concepts Related to OSPF
4.7.4 OSPF Packets
4.7.5 Types of OSPF LSAs
4.7.1 OSPF Overview

Open Shortest Path First (OSPF) is a link state-based internal gateway protocol developed by
IETF organization. OSPF is a dynamic routing protocol that runs within an Autonomous System
(AS). At present, OSPF version 2 (RFC 2328) is used widely, which has the following features:
l Applicable scope
It can support networks in various sizes and can support hundreds of routers at most.
l Fast convergence
It can send the update packets as soon as the network topology changed so that the change
is synchronized in the AS.
l Loop-free
Since the OSPF calculates routes with the shortest path tree algorithm based on the collected
link states, this algorithm itself ensures that no loop routes will be generated.
l Area partition
It allows the network of AS to be divided into areas for the sake of management. In this
way, the routing information transmitted between the areas is abstracted further, and as a
result less network bandwidth is consumed.
l Equal-cost route
OSPF allows multiple equal-cost routes to the same destination.
l Routing hierarchy
OSPF has four-class routes, which rank in the order of priority. They are intra-area, inter-
area, external type-1, and external type-2 routes.
l Authentication
It supports the interface-based packet authentication so as to guarantee the security of the
route calculation.
l Multicast transmission
It supports multicast address to receive and send packets.
4.7.2 Process of OSPF Route Calculation

The routing calculation process of the OSPF protocol is as follows
l Each router in support of OSPF maintains a Link State Database (LSDB) , which describes
the topology of the whole AS. According to the network topology around itself, each router

generates a Link State Advertisement (LSA) . The routers on the network send the LSAs
by sending the protocol packets to each other. Thus, each router receives the LSAs of other
routers and all these LSAs compose its LSDB.
l LSA describes the network topology around a router, while LSDB describes the topology
of the whole network. Routers can easily transform the LSDB to a weighted directed map,
which actually reflects the topology of the whole network. Obviously, all the routers get
the same map.
l Each router uses the SPF algorithm to calculate the shortest path tree with itself as the root.
The tree shows the routes to the nodes in AS. The external routing information is leaf node.
A router, which advertises the routes, also tags them and records the additional information
of the AS. Obviously, each router obtains different routing tables.
4.7.3 Basic Concepts Related to OSPF
Router ID
To run OSPF protocol, a router must have a Router ID. If not, the system will automatically
select one from the IP addresses on the current interfaces for the router.
DR and BDR
Basic concepts related to DR and BDR:
l Designated Router (DR)

In order for each router to broadcast its local state information to the whole AS, multiple
neighboring relations should be created between routers. However, the route changes on a
router will be transmitted time after time, which wastes the valuable bandwidth resource.
To solve the problem, OSPF defines DR. All the routers only need to send information to
the DR, which then broadcasts the network link states. Neither neighbor relation is
established nor route information is exchanged between routers except DRs and BDRs,
which are called as DR Others. You can configure the DR priority to affect the result of
DR election.
Which router will act as the DR are not specified, but selected by all the routers in the
network segment.
l Backup Designated Router (BDR)
If the DR becomes invalid due to some faults, it must be reelected and synchronized. It
takes long time and meanwhile the route calculation is incorrect. In order to speed up this
process, OSPF puts forward the concept of BDR. In fact, BDR is a backup for DR. DR and
BDR are elected in the mean time. The adjacencies are also established between the BDR
and all the routers on the local network segment, and routing information is also exchanged
between them. Once the DR becomes invalid, the BDR will turn into the DR instantly.
Area
As the network keeps extending in scale, if more and more routers in a network run OSPF, LSDB
will become very huge. As a result, a great amount of memory is occupied and much CPU is
consumed to complete SPF algorithm. In addition, network expansion makes it more possible
to change topology. As a result, many OSPF packets are forwarded in the network, and
bandwidth utility of the network is reduced.

To solve this problem, OSPF divides AS into several areas. Areas divide routers into groups
logically. Each area is marked by area ID. One of the most important areas is area 0, which is
also named backbone area.
The backbone area needs to realize the exchange of route information from non-backbone area.
The backbone area must be consecutive. For physically inconsecutive areas, you need to
configure virtual links to keep the backbone area logically consecutive.
The router that connects backbone area and non-backbone area is named Area Border Router
(ABR) .
Route Summary
AS is divided into different areas, each area is interconnected through OSPF ABR. The routing
information between areas can be reduced through route summary. Thus, the size of routing
table can be reduced and the calculation speed of the router can be improved.
After calculating an intra-area route in an area, the ABR will look up the routing table and
encapsulate each OSPF route into an LSA and send it outside the area.
Area and route summary is shown in Figure 4-8.
Figure 4-8 Area and route summary

Area 12 19.1.1.0/24
Area 19
Virtual Link
Area 0
RTA
19.1.2.0/24 19.1.3.0/24
Area 8
For example, in Figure 4-8, there are three intra-area routes in area 19, which are 19.1.1.0/24,
19.1.2.0/24 and 19.1.3.0/24. If route summary is configured and the three routes are aggregated
into one route 19.1.0.0/16, only one LSA, which describes the route after summary, is generated
on RTA.
4.7.4 OSPF Packets
OSPF uses five types of packets:
l Hello packet

It is a kind of most common packet, which is sent to the neighbor of a local router regularly.
It contains the values of some timers, DR, BDR and the known neighbors.
l Database Description (DD) packet
When two routers synchronize their databases, they use the DD packets to describe their
own LSDBs, including the summary of each LSA. The summary refers to the HEAD of an
LSA, which can be used to uniquely identify the LSA. This reduces the traffic size
transmitted between the routers, since the HEAD of an LSA only occupies a small portion
of the overall LSA traffic. With the HEAD, the peer router can judge whether it already
has had the LSA.
l Link State Request (LSR) packet
After exchanging the DD packets, the two routers know which LSAs of the peer routers
are lacked in the local LSDBs. In this case, they will send LSR packets to request for the
needed LSAs to the peers. The packets contain the summary of the needed LSAs.
l Link State Update (LSU) packet
The packet is used to send the needed LSAs to the peer router. It contains a collection of
multiple LSAs (complete contents).
l Link State Acknowledgment (LSAck) packet
The packet is used to acknowledge the received LSU packets. It contains the HEAD(s) of
LSA(s) to be acknowledged (a packet can acknowledge multiple LSAs).
4.7.5 Types of OSPF LSAs
Five Types of Basic LSAs

The OSPF calculates and maintains the routing information mainly based on the LSAs.
Five types of LSAs are defined in RFC 2328:
l Router-LSAs
Type-1 LSAs, generated by routers and spread throughout the area where the routers locate.
They describe the link state and cost of the routers.
l Network-LSAs
Type-2 LSAs, generated by DRs on the broadcast network, and spread throughout the area
where the DRs locate. They describe the link state of the local network segment.
l Summary-LSAs
Type-3 LSAs or Type-4 LSAs, generated by ABR and spread into related areas. They
describe routes to destinations internal to the AS, yet external to the area (i.e., inter-area
routes). Type-3 Summary-LSAs describe routes to networks (with the destination as a
network segment), while Type-4 Summary-LSAs describe routes to ASBRs.
l AS-external-LSAs
Type-5 LSAs (also written as ASE LSA). Generated by ASBRs, they describe routes to
destinations external to the AS. They are spread throughout the entire AS, except stub areas.
A default route for the AS can also be described by an AS-external-LSA.
Type-7 LSA
A new LSA, Type-7 LSA, is added in RFC 1587 (OSPF NSSA Option).
As described in RFC 1587, Type-7 LSAs and Type-5 LSAs mainly differ in:

l Type-7 LSAs are generated and spread throughout Not-So-Stubby Area (NSSA), while
Type-5 LSAs are not.
l Type-7 LSAs can only be spread throughout an NSSA. When Type-7 LSAs reach ABR of
NSSA, they will be translated into Type-5 LSAs and spread into other areas. They can not
be directly spread into other areas or the backbone area.
4.8 Introduction to Policy-Based Routing

Different from the routing based on the destination address in the IP packets, the policy-based
routing is a mechanism in which packets are transmitted and forwarded on the basis of the user-
defined policies.
The policy-based routing on this device can be flexibly designated on the basis of the various
information that in the received packets, such as the source address, address length.
There are two kinds of policy routings: interface policy routing and local policy routing. The
former is configured in interface view and performs strategic routing for packets coming through
this interface, while the latter is configured in global view and performs policy routing for packets
generated by this router. Generally, for the request about forwarding and security, in most cases,
interface policy route will be used.
The policy routing can be used for security and load sharing.
4.9 QoS
4.9.1 QoS Overview
4.9.2 Traditional Packets Transmission Application
4.9.3 New Application Requirements
4.9.4 Congestion Causes, Impact and Countermeasures
4.9.5 Traffic Control Techniques
4.9.1 QoS Overview

Quality of service (QoS) is used to assess the ability of the supplier to meet the customer
demands. In the Internet, QoS is used to assess the ability of the network to transmit packets.
The network provides a wide variety of services and therefore, QoS should be assessed from
different aspects.
QoS generally refers to the analysis of the issues related to the process of sending packets such
as, bandwidth, delay, jitter, and packet loss ratio.
4.9.2 Traditional Packets Transmission Application

It is difficult to ensure QoS in the traditional IP network. Routers in the network handle all the
packets equally and adopt First In First Out (FIFO) method to transfer packets. Resources used
for forwarding packets are allocated based on the arrival sequence of the packets.
All packets share the bandwidth of networks and devices. The quantity of the resources is
obtained depending on the arrival time of the packets. This policy is called best effort (BE) . The

device in this mode tries its best to transmit packets to the destination. The BE mode however,
does not ensure any improvement in delay time, jitter, packet loss ratio, and high reliability.
The traditional BE mode applies only to services that have no specific request for bandwidth
and jitter, such as, World Wide Web (WWW), file transfer, and E-mail.
4.9.3 New Application Requirements

With the rapid development of the network, increasing number of networks are connected to the
Internet. The Internet extends greatly in size, scope, and user numbers. The usage of the Internet
as a platform for data transmission and implementation of various applications is increasing.
Further, the service providers also want to develop new services for more profits.
Apart from traditional applications such as WWW, E-Mail and File Transfer Protocol (FTP),
the Internet has expanded to encompass other services such as E-learning, telemedicine,
videophone, videoconference, and video on demand. Enterprise users want to connect their
branches in different areas through VPN technologies to implement applications such as
accessing corporate databases or managing remote devices through Telnet.
These new services have one common feature, that is, special requirement on the transmission
performance such as the bandwidth, delay, and delay jitter. For instance, the video conference
and video on demand services require the guarantee of high bandwidth, low delay, and low delay
jitter. Though the key tasks such as transaction processing and Telnet may not require high
bandwidth, they demand low delay and require preferential processing when congestion occurs.
With the emergence of new services, the number of requests for the service capability of IP
networks has increased. Users expect improved service transmission to the destination and also
better quality of services. For example, IP networks are expected to provide dedicated
bandwidth, reduce packet loss ratio, avoid network congestion, control network flow, and set
the preference of packets to provide different QoS for various services.
These conditions demand better service capability from the network.
4.9.4 Congestion Causes, Impact and Countermeasures

Low QoS in the traditional networks is mainly caused by the network congestion. When the
current supply resources temporarily fail to meet the requirements of the service transmission,
the bandwidth cannot be ensured. As a result, QoS decreases, which causes long delay and high
jitter. This phenomenon is called congestion.
Congestion Causes
Congestion often occurs in the complex packet switching environment of the Internet. It is caused
by the bandwidth bottleneck of two types of links, as shown in Figure 4-9.

Figure 4-9 Schematic diagram of traffic congestion
100M
100M 10M 100M 100M
Traffic congestion on
interfaces operating at
different speeds 100M
Traffic congestion on
interfaces operating at
the same speeds
l Packets enter the Router at the high speed of v1, and are forwarded at the low speed of v2.
Congestion occurs in the Router because v1 is greater than v2.
l Packets from multiple links enter the Router at the speed of v1, v2, and v3. They are
forwarded at the speed of v4 from a single link. Congestion occurs in the Router because
the sum of v1, v2, and v3 is greater than v4.
The resource bottleneck caused when packets enter the Router at line speed.
Shortage of resources such as available CPU time, buffer or memory size used for sending
packets. The network resources required to handle the traffic exceed the assignable value. This
happens when the system fails to process the traffic flow within a short time.
Congestion Effect
Congestion can lead to the following negative effect:
l Increases the delay and the jitter in sending packets.

l Long delay can cause retransmission of packets.
l Reduces throughput of the network and causes resources to be assigned unequally on the
network.
l Consumes more network resources particularly storage resources when congestion is
aggravated. If resources are not allocated properly, there may be a system deadlock or the
system may crash.
Congestion is the main cause of decline in the QoS. It is very common in complex networks and
must be solved to increase the efficiency of the network.
Countermeasures
The following are the two commonly used methods to address network congestion:
l Increasing the network bandwidth is a direct way to solve the shortage of resources. This
method however, cannot solve all the congestion problems.
l Improving the functions of traffic control and resource allocation at the network layer is a
more effective method. This requires providing differentiated services (Diff-Serv) for

applications that have different demands for QoS. During resource allocation and traffic
control, the direct or indirect factors that cause network congestion can be controlled to a
greater extent. In case of congestion, resource allocation should be balanced according to
the application's demand. The influence of congestion on QoS can thus be reduced to the
minimum.
4.9.5 Traffic Control Techniques

The following are the commonly used techniques to control traffic in the network:
l Traffic classification
Identifies the object according to specific rules. It is the basis of Diff-Serv and is used to
identify packets with a defined rule.
l Traffic policing
Measure to control the traffic rate. The rate of the traffic that enters the network is monitored
and the traffic exceeding its rate limit is restricted. Only a reasonable traffic range is allowed
to pass through the network. This ensures optimization of network resources and protects
the interests of the providers.
l Traffic shaping
Traffic shaping is a traffic control measure to regulate the output rate of the traffic actively.
Traffic shaping regulates the traffic to match the network resources that can be provided
by the downstream devices so as to avoid unnecessary packet loss and congestion.
l Congestion management
Congestion management is necessary for solving resource competition. Congestion
management is generally to cache packets in the queues and arrange the forwarding
sequence of the packets based on a certain scheduling algorithm.
l Congestion avoidance
Excessive congestion will impair the network resources. Congestion avoidance is to
supervise the network resource usage. When it is found that congestion is likely to become
worse, the congestion avoidance mechanism will drop packets and regulate traffic to solve
the overload of the network.
Among these traffic control techniques, traffic classification is the basic one. Traffic
classification identifies packets according to certain matching rules. In this sense, traffic
classification is a prerequisite to differentiated services. Traffic policing and congestion
management control network traffic and resource allocation from different aspects, which
reflects the concept of differentiated services.
The QoS provides assessment on supported service capabilities for core requirements such as
the bandwidth, throughput, delay, delay jitter, packet loss ratio, and availability during packet
forwarding. Generally, the following functions are used to clear congestion:
l Traffic classification and Marking
l Traffic policing
l Congestion management

Feature Description 5 VPN
5 VPN
About This Chapter
The Eudemon supports IPSec VPN and SSL VPN applications, which provides highly reliable
and secure transmission tunnels for users. It also supports many types of VPN applications
constructed by using Layer 2 Tunneling Protocol (L2TP), and Generic Routing Encapsulation
(GRE).
5.1 Introduction
As enterprises and companies develop in scale, staffs go on business more frequently. With
overseas offices and clients increasingly scattered and the number of partners growing, more
and more enterprises need to use public Internet resources for conducting promotion, sale, after-
sale service, training, cooperation, and consultation. The urgent demand helps VPN applications
find a good market.
5.2 L2TP
The Layer 2 Tunneling Protocol (L2TP) is a kind of VPDN tunneling protocol. To know L2TP
better, you need certain knowledge of VPDN.
5.3 IPSec
Through AH and ESP, IPSec guarantees the confidentiality, integrity, authenticity, and anti-
replay of data packets during transmission on networks. IPSec can realize auto-negotiation key
exchange and SA setup as well as maintenance services through Internet Key Exchange (IKE).
That simplifies the use and management of IPSec.
5.4 GRE
The Generic Routing Encapsulation (GRE) protocol is used to encapsulate packet of the network
layer protocol such as Internet Packet Exchange (IPX). The encapsulated packet can be
transmitted in another network layer protocol such as IP. GRE is the third layer tunnel protocol
of the VPN.
5.5 SSL VPN
The SSL VPN is a VPN of enhanced SSL/TLS functions. In addition to providing the web access
service and TCP and UDP applications, the SSL VPN protects IP communications. Additionally,
SSL VPN communications are based on the standard TCP or UDP and are not confined by NAT;
therefore, users anywhere can access intranet resources through the virtual gateway proxy. The
SSL VPN provides a simpler and more flexible solution to secure remote access, hence greatly
reducing the cost of VPN maintenance.
5.6 BGP/MPLS IP VPN

5 VPN Feature Description
BGP/MPLS IP VPN is a kind of PE-based Layer 3 Virtual Private Network (L3VPN) technology
in the Provider Provisioned VPN (PPVPN). It uses the Border Gateway Protocol (BGP) to
advertise VPN routes and uses Multiprotocol Label Switch (MPLS) to forward VPN packets on
the provider backbone network.

5.1 Introduction
As enterprises and companies develop in scale, staffs go on business more frequently. With
overseas offices and clients increasingly scattered and the number of partners growing, more
and more enterprises need to use public Internet resources for conducting promotion, sale, after-
sale service, training, cooperation, and consultation. The urgent demand helps VPN applications
find a good market.
5.1.1 VPN Overview
As a new technology, Virtual Private Network (VPN) rapidly develops as the Internet is widely
used in recent years. It is used to build private networks on a public network. The word virtual
mainly indicates that a VPN network is a kind of logical network.
5.1.2 Basic VPN Technology
The basic principle of VPN is to use tunneling protocols to encapsulate packets into tunnels and
construct private data transmission tunnels on backbone networks to realize transparent
transmission of data packets.
5.1.3 VPN Classification
IP VPN uses IP facilities, including public Internet or dedicated IP backbone networks, to realize
the emulation of WAN device private line services, such as remote dial-up and Digital Data
Network (DDN). According to different standards, IP VPNs can be classified into different types.
5.1.1 VPN Overview

As a new technology, Virtual Private Network (VPN) rapidly develops as the Internet is widely
used in recent years. It is used to build private networks on a public network. The word virtual
mainly indicates that a VPN network is a kind of logical network.
VPN Features
VPN has the following features:
l Different from traditional networks, a VPN does not physically exist. It is a kind of logical
network, a virtual network configured on the basis of existing public network resources.
l A VPN is exclusively used by an enterprise or a user group.
For VPN users, a VPN is the same as a traditional dedicated network in usage. As a kind
of private networks, the resources of VPNs are independent of bear network resources.
Typically, the resources of one VPN are not used by other VPNs on the bear network or
non-authorized VPN users. VPN offers reliable protection mechanism to defend VPN
internal information against external intrusion and interruption.
l VPN is a kind of sophisticated upper-layer service.
VPN services help set up interconnection for the users of a private network. VPN services
realize VPN internal network topology setup, routing calculation, and user login or logout.
VPN technology is much more complicated than common point-to-point application
mechanisms.
VPN Advantages
VPN presents the following advantages:

l Helping set up reliable connection between remote users, overseas offices, partners,
suppliers, and company headquarters to ensure secure data transmission.
This advantage is significant because it realizes the convergence of E-business or financial
networks with communication networks.
l Using public networks to realize information communication. With VPNs, enterprises can
connect remote offices, telecommuters, and business partners at a dramatically low cost.
In addition, VPNs significantly increase the use rate of network resources, thus helping the
Internet Service Providers (ISPs) increase revenue.
l Allowing you to add or delete VPN users through software without changing hardware
facilities.
This mechanism offers great flexibility in VPN applications.
l Allowing telecommuting VPN users to access headquarter resources at any time and in any
place.
That satisfies the increasing demands for mobile services.
l Offering high quality VPNs such as MPLS VPN and diversified VPN services to meet VPN
users' different demands for quality level. Service-specific rating mechanism brings ISPs
more revenue.
5.1.2 Basic VPN Technology

The basic principle of VPN is to use tunneling protocols to encapsulate packets into tunnels and
construct private data transmission tunnels on backbone networks to realize transparent
transmission of data packets.
VPN Basic Networking Application

The following takes an enterprise network as an example to illustrate VPN basic networking.
Figure 5-1 shows the internal network established through VPN.
Figure 5-1 Networking diagram of VPN applications

Remote user Internal server
PoP
PoP
Company
PoP headquarter
Cooperator
As shown in Figure 5-1, eligible users can connect to the Point of Presence (POP) server of the
local ISP through a Public Switched Telephone Network (PSTN), Integrated Services Digital
Network (ISDN), or LAN so as to access the internal resources of an enterprise. Traditional
WAN networking technology requires dedicated physical links to realize connections. With
established virtual networks, remote users and telecommuters can access internal resources of
an enterprise without need of being authorized by the local ISP. It is helpful for telecommuting
staff and scattered users.

To experience VPN services, an enterprise needs to deploy only a server, such as a Windows
NT server or a firewall that supports VPN to share resources. After connecting to the local POP
server through the PSTN, ISDN, or LAN, eligible users can directly call the remote server (VPN
server) of the enterprise. The access server of the ISP and the VPN server work together to realize
the call.
VPN Fundaments
Figure 5-2 Networking diagram of a VPN access
Tunnel
VPN user
NAS VPN Server
As shown in Figure 5-2, VPN users dial up to the Network Access Server (NAS) of the ISP
through the PSTN or ISDN.
The NAS identifies users by checking user names or access numbers. If the NAS server
determines that a user is a VPN user, it sets up a connection (a tunnel) with the user's destination
VPN server. Then the NAS encapsulates the user's data into an IP packet and transmits it to the
VPN server through the tunnel. After the VPN server receives the packet, it decapsulates the
packet to read the real packet.
Packets can be encrypted on both sides of the tunnel. Other users on the Internet cannot read the
encrypted packets. That ensures the security of packets. For users, a tunnel is a logical extension
of the PSTN or ISDN link. The operations on the logical tunnel are similar to that on a physical
link.
Tunnels can be achieved through tunneling protocols.
Based on the realization of tunnels on Open Systems Interconnection (OSI) reference model,
tunnel protocols can be categorized into three groups:
l Layer 2 (L2) tunneling protocols

An L2 tunneling protocol tunnels individual Point-to-Point Protocol (PPP) frames.
The existing L2 tunneling protocols are as follow:
– Point-to-Point Tunneling Protocol (PPTP)
PPTP is supported by Microsoft, Ascend, and 3COM. Windows NT 4.0 and later
versions support PPTP. PPTP supports the tunneling of PPP frames on IP networks.
PPTP, as a call control and management protocol, uses an enhanced Generic Routing
Encapsulation (GRE) technology to provide flow and congestion control encapsulation
services for transmitted PPP packets.
– Layer 2 Forwarding (L2F) protocol
It is a Cisco proprietary protocol. L2F permits the tunneling of the link layer of higher
level protocols and helps divorce the location of the initial dial-up server from the

location at which the dial-up protocol connection is terminated and access to the network
provided.
– Layer 2 Tunneling Protocol (L2TP)
L2TP is drafted by IETF with the support of Microsoft. By integrating the advantages
of the preceding two protocols, L2TP has developed into a standard RFC. L2TP can be
used to realize both dial up VPN services (such as VPDN access) and private line VPN
services.
l Layer 3 (L3) tunneling protocols
For an L3 tunneling protocol, both the starting point and ending point are within an ISP. A
PPP session is terminated on the NAS. Tunnels carry only L3 packets.
The existing L3 tunneling protocols are as follows:
– Generic Routing Encapsulation (GRE)
It is used to realize the encapsulation of the network layer protocol such as IP or Internet
Packet Exchange (IPX) over another arbitrary network layer protocol.
– IP Security (IPSec)
IPSec is not a single protocol. Instead, it offers a set of system architecture for data
security on IP networks, including Authentication Header (AH), Encapsulating Security
Payload (ESP), and Internet Key Exchange (IKE).
– BGP/MPLS
BGP/MPLS IP VPN uses the Border Gateway Protocol (BGP) to advertise VPN routes
and uses Multiprotocol Label Switch (MPLS) to forward VPN packets on the provider
backbone network.
GRE and IPSec are mainly applied to private line VPN services.
l Application layer tunneling protocol: Security Socket Layer (SSL)
SSL is a security protocol, which provides secure connections for TCP-based application
layer protocols. For example, SSL can provide secure connections for HTTP. SSL widely
applies to fields such as e-commerce and online-banking, which provides security
guarantees for data transmission on the network.
l Comparison among L2 tunneling protocols, L3 tunneling protocols and application layer
protocol (SSL VPN)
L3 tunneling protocol is superior to L2 tunneling protocol in the following aspects:
– Security and Reliability
An L2 tunnel usually ends at a user-side device, so it has higher requirements for the
security of user networks and firewall technology. An L3 tunnel usually ends at an ISP
gateway. Therefore, it has not high requirements for the security technology of user
networks.
– Scalability
Since an L2 tunnel tunnels a whole PPP frame, transmission efficiency may be
decreased. In addition, a PPP session runs through a whole tunnel and terminates at a
user-side device. That requires that the user-side gateway should keep a large amount
of PPP session status and information. That may overload the system and impact its
scalability. Moreover, since the Link Control Protocol (LCP) and Network Control
Protocol (NCP) negotiations are quite sensitive to time, degraded tunnel efficiency may
result in a series of problems such as PPP session timeout. On the contrary, an L3 tunnel
terminates on an ISP gateway, and a PPP session ends on the NAS. Thus, the user

gateway does not need to manage and maintain the status of each PPP session. Thereby,
system load is reduced.
The SSL VPN needs no clients. Users can conveniently establish standard secure channels
to access remote applications through Web browsers supporting HTTPS (SSL-based
HTTP). In this case, the workload of the VPN system administrator is greatly reduced. The
feature that requires no clients, however, reduces the security of the SSL VPN. The SSL
VPN applies to the following scenarios:
– Enterprises need to access the Internet remotely through the Web.
– The firewall is deployed between the client and the target server. HTTPS packets are
permitted, but IKE or IPSec packets are denied.
– Refined access control is required.
Typically, L2 tunneling protocols, L3 tunneling protocols and application layer protocols
are used separately. If they are appropriately used together, for example, using L2TP and
IPSec together, they may provide users with high security and better performance.
5.1.3 VPN Classification

IP VPN uses IP facilities, including public Internet or dedicated IP backbone networks, to realize
the emulation of WAN device private line services, such as remote dial-up and Digital Data
Network (DDN). According to different standards, IP VPNs can be classified into different types.
Classification Based on Operation Modes

According to the operation modes, IP VPNs can be classified into the following types:
l Customer Premises Equipment based VPN (CPE-based VPN)

This kind of VPN requires users to install expensive devices and special authentication
tools. In addition, users need to accomplish tedious maintenance tasks such as channel
maintenance and bandwidth management. The networking of this kind of VPN is
complicated and hardly scaled.
l Network-based VPN (NBIP-VPN)
This kind of VPN outsource VPN maintenance to ISPs (meanwhile users are permitted to
manage and control certain services). The functionalities of VPN are realized on network
devices, thus reducing user investment, offering more flexibilities in adding services and
scalability, and bringing new revenue to carriers.
Classification Based on Service Applications

According to usages of services, IP VPNs can be classified into the following types:
l Intranet VPN
An intranet VPN interconnects distributed internal points of an enterprise through public
networks. It is an extension or substitute of traditional private line networks and other
enterprise networks.
l Access VPN
An access VPN provides private connections between internets and extranets for
telecommuting staff, mobile offices, and remote offices through public networks. There
are two type of access VPN architectures:
– Client-initiated VPN connection

– NAS-initiated VPN connection

l Extranet VPN
An extranet VPN uses a VPN to extend an enterprise network to suppliers, partners, and
clients, thus establishing a VPN between different enterprises through public networks.
Classification Based on Networking Modes

According to networking modes, IP VPNs can be classified into the following types:
l Virtual Leased Line (VLL)
A VLL is an emulation of traditional leased line services. By emulating leased line through
an IP network, a VLL provides asymmetric, low cost DDN service. For VLL users, a VLL
is similar to a traditional leased line.
l Virtual Private Dial Network (VPDN)
A VPDN realizes a VPN through a dial-up public network, such as an ISDN and PSTN to
provide access services to enterprise customers, small-sized ISPs, and mobile offices.
l Virtual Private LAN Segment (VPLS)
A VPLS interconnects LANs through VPN segments on IP public networks. It is an
extension of LANs on IP public networks.
l Virtual Private Routing Network (VPRN)
A VPRN interconnects headquarters, branches, and remote offices through network
management virtual routers on IP public networks.
There are two kinds of VPRN services:
– VPRN realized through traditional VPN protocols such as IPSec and GRE
– VPRN based on Multiprotocol Label Switch (MPLS)
5.2 L2TP
The Layer 2 Tunneling Protocol (L2TP) is a kind of VPDN tunneling protocol. To know L2TP
better, you need certain knowledge of VPDN.
5.2.1 VPDN Overview
A Virtual Private Dial Network (VPDN) realizes a VPN by using the dial-up function of public
networks such as the ISDN and PSTN as well as access networks. VPDNs provide access
services for enterprise customers, small-sized ISPs, and mobile offices.
5.2.2 L2TP Overview
L2TP supports the tunneling of PPP link layer packets. L2TP extends the PPP model by allowing
the L2 and PPP endpoints to reside on different devices interconnected by a packet-switched
network. By integrating the advantages of PPTP and L2F, L2TP has developed into the industry
standard of layer two tunneling protocols.
5.2.1 VPDN Overview

A Virtual Private Dial Network (VPDN) realizes a VPN by using the dial-up function of public
networks such as the ISDN and PSTN as well as access networks. VPDNs provide access
services for enterprise customers, small-sized ISPs, and mobile offices.
VPDNs adopt special network encryption protocols to set up secure VPNs for enterprise
customers over public networks. With VPDNs, overseas offices and telecommuting staff can

obtain a network connection to their headquarter through a virtual encryption tunnel over public
networks. Other users on the public networks cannot pass through the virtual tunnel to access
internal resources on the enterprise network.
There are two ways to realize VPDNs:
l The NAS sets up a tunnel to the VPDN gateway based on tunneling protocols.
This realization mechanism directly connects the PPP connection of users to the gateway
of the enterprise network. So far, available tunneling protocols are L2F and L2TP.
The advantages of this realization mechanism are as follows:
– The realization process is transparent to users.
– Users can access the enterprise network after a one-time login.
– Since the enterprise network authenticates users and assigns IP addresses, no extra
public addresses are required.
– Users can implement network access through different platforms.
This realization mechanism requires the NAS to support the VPDN protocol, and the
authentication system to support VPDN attributes. Typically, a firewall or dedicated VPN
server is used as a gateway.
l A client host sets up a tunnel with the VPND gateway.
The client host connects with the Internet first, and then it uses dedicated client software
such as the L2TP client on the Windows 2000 to set up a tunnel with the gateway.
The advantage and disadvantage of this realization mechanism are as follows:
– Since this realization mechanism has no requirements for ISPs, users can access
resources at any place and in any way.
– Since this mechanism requires users to install and use dedicated software, usually
Windows 2000, users can select a specified platform.
There are three types of VPDN tunneling protocols:

l PPTP
l L2F
l L2TP
L2TP is widely used at present.
5.2.2 L2TP Overview

network. By integrating the advantages of PPTP and L2F, L2TP has developed into the industry
standard of layer two tunneling protocols.
Background
PPP defines an encapsulation mechanism for transporting multiprotocol packets across L2 point-
to-point links. Typically, a user obtains a L2 connection to a NAS using one of a number
network.

By integrating the advantages of PPTP and L2F, L2TP has developed into the industry standard
of layer two tunneling protocols.
Typical L2TP Networking Application

Figure 5-3 shows the typical networking of VPDN application based on L2TP.
Figure 5-3 Networking diagram of VPDN application based on L2TP
L2TP tunnel
Remote LAC LNS
user
NAS
Remote
branch
Internal server
As shown in Figure 5-3, the L2TP Access Concentrator (LAC) is attached to the switch network.
The LAC is a PPP endpoint system and can process L2TP. Usually, an LAC is a NAS, which
provides access services for users across the PSTN or ISDN. The L2TP Network Server (LNS)
acts as one node of the PPP endpoint system and is used to process the L2TP server.
An LAC sits between an LNS and a remote system and forwards packets to and from each.
Packets sent from the remote system to the LNS require tunneling with the L2TP protocol.
Packets sent from the LNS are decapsulated and then forwarded to the remote system. The
connection from the LAC to the remote system is either local or a PPP link. For VPDN
applications, the connections are usually PPP links.
An LNS acts as one side of an L2TP tunnel and is a peer to an LAC. The LNS is the logical
termination point of a PPP session that is being tunneled from the remote system by the LAC.
Technology Details
The following describes the technology details of L2TP:
l L2TP protocol structure
Figure 5-4 L2TP protocol structure
PPP frame
L2TP data L2TP control
message messsage
L2TP data tunnel L2TP control tunnel
(unreliable) (reliable)
Packet trasmission network (UDP,...)

Figure 5-4 depicts the relationship of PPP frames and Control Messages over the L2TP
Control and Data Channels. PPP Frames are passed over an unreliable Data Channel
encapsulated first by an L2TP header and then a Packet Transport such as UDP, Frame
Relay, and ATM. Control messages are sent over a reliable L2TP Control Channel which
transmits packets in-band over the same Packet Transport.
L2TP uses the registered UDP port 1701. The entire L2TP packet, including payload and
L2TP header, is sent within a UDP datagram. The initiator of an L2TP tunnel picks an
available source UDP port (which may or may not be 1701), and sends to the desired
destination address at port 1701. The recipient picks a free port on its own system (which
may or may not be 1701), and sends its reply to the initiator's UDP port and address, setting
its own source port to the free port it found. Once the source and destination ports and
addresses are established, they must remain static for the life of the tunnel.
l Tunnel and session
There are two types of connections between an LNS-LAC pair:
– Tunnel: defines an LNS-LAC pair.
– Session: is multiplexed over a tunnel to denote each session process over the tunnel.
Multiple L2TP tunnels may exist between the same LAC and LNS. A tunnel consists of
one control connection and one or several sessions. A session is set up after a tunnel is
successfully created, namely, information such as ID, L2TP version, frame type, and
hardware transmission type are exchanged. Each session corresponds with a PPP data
stream between an LAC and an LNS.
Both control message and PPP packets are transmitted through tunnels.
L2TP uses Hello messages to check the connectivity of a tunnel. The LAC and the LNS
periodically send Hello messages to each other. If no Hello message is received within a
period of time, the session between them is cleared.
l Control message and data message
L2TP utilizes two types of messages:
– Control messages
Control messages are used in the establishment, maintenance, and transmission control
of tunnels and sessions.
Control messages utilize a reliable Control Channel within L2TP to guarantee delivery.
Control messages support traffic control and congestion control.
– Data messages
Data messages are used to encapsulate PPP frames being carried over the tunnel.
Data messages are not retransmitted when packet loss occurs. Data messages do not
support traffic control and congestion control.
L2TP packets for the control channel and data channel share a common header format.
An L2TP message header includes a tunnel ID and a session ID, which are used to identify
tunnels and sessions. Packets with the same Tunnel ID but different session IDs are
multiplexed over the same tunnel. Tunnel IDs and session IDs in a packet header are
assigned by the peer ends.
Two Typical L2TP Tunnel Modes

Figure 5-5 shows the tunnel modes of PPP frames between a remote system or an LAC client
(running L2TP) and an LNS.

Figure 5-5 Two typical L2TP tunnel modes

LAC client
LAC LNS
Remote client
LAC LNS
Connections can be established in two ways:
l Initiated by a remote dial-up user

The Remote Client initiates a PPP connection across the PSTN/ISDN to an LAC. The LAC
then tunnels the PPP connection across the Internet. Authentication, Authorization, and
Accounting may be provided by the Home LAN's Management Domain or by the LNS.
l Initiated directly by an LAC user (a host which runs L2TP natively)
The LAC users can directly initiate a tunnel connection to the LNS without use of a separate
LAC. In this case, the address of the LAC is assigned by the LNS.
Setup Procedure of an L2TP Tunnel Session

Figure 5-6 shows a typical networking of L2TP.
Figure 5-6 Typical networking diagram of L2TP

RADIUS Server RADIUS Server
IP IP
network network
PC
LAC LNS
PC
Eudemon Eudemon
PC
Figure 5-7 shows the procedure for setting up an L2TP call.

Figure 5-7 Procedure for setting up an L2TP call

LAC LAC LNS LNS
PC Eudemon RADIUS server Eudemon RADIUS server
(1) Call setup

(2) PPP LCP setup
(3) PAP or CHAP
authentication (4) Access request
(5) Access accept
(6) Tunnel establishment
(7) PAP or CHAP authentication
(challenge/response)
(8) Authentication passes
(9) User CHAP response, PPP
negotiation parameter
(10) Access request
(11) Access accept
(12) CHAP authentication twice(challenge/response)
(13) Access request
(14) Access accept
(15) Authentication passes
The procedure for setting up an L2TP call is as follows:
1. The PC at user side initiates a connection request.

2. The PC and the LAC (Eudemon) negotiate PPP LCP parameters.
3. The LAC performs the Password Authentication Protocol (PAP) or Challenge Handshake
Authentication Protocol (CHAP) authentication based on the user information provided by
the PC.
4. The LAC sends the authentication information, including VPN username and password, to
the RADIUS server for ID authentication.
5. The RADIUS server authenticates this user and sends back the access accept, such as LNS
address, after the authentication is passed successfully. Meanwhile, the LAC is ready for
initiating a new tunnel request.
6. The LAC initiates a tunnel request to the LNS specified by the RADIUS server.
7. The LAC informs the LNS of CHAP challenge, and the LNS sends back the CHAP response
and its self CHAP challenge, the LAC sends back the CHAP response.
8. Authentication passes.
9. The LAC transmits the CHAP response, response identifier, and PPP negotiation
parameters to the LNS.
10. The LNS sends the access request to RADIUS server for authentication.
11. The RADIUS server re-authenticates this access request and sends back a response if
authentication is successful.
12. If local mandatory CHAP authentication is configured at the LNS, the LNS will authenticate
the VPN user by sending challenge and the VPN user at PC sends back responses.

13. The LNS re-sends this access request to RADIUS for authentication.
14. RADIUS server re-authenticates this access request and sends back a response if
authentication is successful.
15. After all authentications are passed, the VPN user can access the internal resources of the
enterprise.
Features of the L2TP Protocol

The features of the L2TP Protocol are as follows:
l Flexible ID authentication mechanism and high security

– L2TP itself does not provide connection security, but it can depend on the
authentication, such as CHAP and PAP, provided by PPP. Thereby, it has all security
features of PPP.
– L2TP can integrate with IPSec to fulfill data security, which make it more difficult to
attack the data transmitted with L2TP.
– To improve data security, based on the requirement of specific network security, L2TP
adopts:
– Tunnel encryption technique
– End-to-end data encryption
– Application layer data encryption
l Multi-protocol transmission
L2TP transmits PPP data packet and a wide variety of protocols can be encapsulated in
PPP data packet.
l Supporting authentication by the RADIUS server
The LAC sends user name and password to the RADIUS server for authentication request.
The RADIUS server is in charge of:
– Receiving authentication request of the user
– Fulfilling the authentication
l Supporting internal address assignment
The LNS can be put behind Intranet firewall. It can dynamically assign and manage the
addresses of remote users and support the application of private addresses (RFC1918). The
IP addresses assigned to remote users are internal private addresses of the enterprise instead
of Internet addresses. Thus, the addresses can be easily managed and the security can also
be improved.
l Flexible network charging
L2TP charges in both the LAC and the LNS at the same time, that is, in ISP (to generate
bills) and Intranet gateway (to pay for charge and audit).
L2TP can provide the following charging data:
– Transmitted packet number and byte number
– Start time and end time of the connection
L2TP can easily perform network charging based on these data.
l Reliability

L2TP supports the backup LNS. When the active LNS is inaccessible, the LAC can
reconnect with the backup LNS, which improves the reliability and fault tolerance of VPN
service.
5.3 IPSec
Through AH and ESP, IPSec guarantees the confidentiality, integrity, authenticity, and anti-
replay of data packets during transmission on networks. IPSec can realize auto-negotiation key
exchange and SA setup as well as maintenance services through Internet Key Exchange (IKE).
That simplifies the use and management of IPSec.
5.3.1 IPSec Overview
IP Security (IPSec) protocol family is a series of protocols defined by IETF. It provides IP data
packets with cryptology-based security, featuring high quality and interoperability.
5.3.2 IKE Overview
IKE is designed based on the framework provided by the Internet Security Association and Key
Management Protocol (ISAKMP). IKE can automatically negotiate key exchange and create
security associations (SAs) for IPSec. That helps simplify the use and management of IPSec.
5.3.3 IPSec Basic Concepts
The basic IPSec concepts include security association (SA), SA negotiation mode/operation
mode, authentication algorithm and encryption algorithm.
5.3.4 NAT Traversal of IPSec
The NAT traversal of IPSec is to add a standard UDP header between IP and ESP headers of
the original packet (without regard for AH mode).
5.3.5 CA Authentication
The Eudemon supports Public Key Infrastructure (PKI) framework-based Certificate
Authentication (CA) mechanism. The CA mechanism provides a centralized key management
mechanism for IPSec networks and enhances the expansibility of the entire IPSec network.
5.3.6 Realizing IPSec on the Eudemon
Through IPSec, the Eudemon and its peer can implement different means of protection for
different data traffic (authentication, encryption, or both).
5.3.1 IPSec Overview

IP Security (IPSec) protocol family is a series of protocols defined by IETF. It provides IP data
packets with cryptology-based security, featuring high quality and interoperability.
The two sides of communication perform encryption and data source authentication on the IP
layer to ensure the confidentiality, integrity, authenticity, and anti-replay of packets transmitted
on networks. The details are as follows:
l Confidentiality
User data is encrypted and transmitted in cipher text.
l Integrity
Received data is authenticated to check whether they are juggled.
l Authenticity
Data source is authenticated to ensure that data is from a real sender.
l Anti-replay

It prevent malicious users from repeatedly sending captured packets. In other words, the
receiver can deny old or repeated data packets.
IPSec realizes the preceding aims with two security protocols: Authentication Header (AH) and
Encapsulating Security Payload (ESP). IPSec can realize auto-negotiation key exchange and SA
setup as well as maintenance services through Internet Key Exchange (IKE). That simplifies the
use and management of IPSec. The details are as follows:
l AH
AH mainly provides data source authentication, data integrity check, and anti-replay.
However, it cannot encrypt the packet.
l ESP
ESP provides all functions of AH. In addition, it can encrypt the packets. However, its data
integrity authentication does not cover IP headers.
l IKE
IKE is used to automatically negotiate cipher algorithms for AH and ESP and put the
necessary key required by the algorithm to a proper place.
NOTE
l AH and ESP can be used either separately or jointly. Both AH and ESP support the tunnel mode.
l IPSec policy and algorithm can also be negotiated manually. So IKE negotiation is not necessary. The
comparison of these two negotiation modes are introduced in the following sections.
5.3.2 IKE Overview

IKE is designed based on the framework provided by the Internet Security Association and Key
Management Protocol (ISAKMP). IKE can automatically negotiate key exchange and create
security associations (SAs) for IPSec. That helps simplify the use and management of IPSec.
IPSec SA can be created manually. However, when the number of nodes on the network increase,
it is hard to guarantee the security of the network. In this case, IKE can be used to automatically
create SAs and implement key exchange.
With a self-protection mechanism, IKE can distribute keys, authenticates IDs, and establish SAs
on insecure networks.
IKE Security Mechanism

IKE security mechanism is as follows:
l Diffie-Hellman (DH) exchange and key distribution

DH algorithm is a public key algorithm. The both parties in communication can exchange
some data without transmitting the key and find the shared key by calculation. The
prerequisite for encryption is that the both parties must have a shared key. The merit of
IKE is that it never transmits the key directly in the unsecured network, but calculates the
shared key by exchanging a series of data. Even if the third party (such as Hackers) captured
all exchange data used to calculate the shared key for both parties, he cannot figure out the
real key.
l Perfect Forward Secrecy (PFS)
PFS is a security feature. PFS refers to the notion that the compromise of a single key does
not impact the security of other keys. That is because a key cannot be used to derive any

other keys. PFS functions based on DH algorithm. PFS is realized when key exchange is
added during IKE phase 2.
l ID authentication
ID authentication helps identify the two parties of communication. The negotiation modes
are as follows:
– pre-share: you need to configure each peer with the pre-shared key. The peers of a
security connection must have identical pre-shared keys.
– rsa-encr: you need to configure RSA public keys for each peer end.
– rsa-sig: you need to configure local certificates.
l Identity protection
After a shared key is generated, identity data is transmitted in encrypted mode.
IKE Exchange Phases

IKE uses two phases to negotiate IPSec keys and create SAs:
l Phase 1 is where the two ISAKMP peers establish a secure, authenticated channel with
which to communicate. This is called the ISAKMP Security Association (ISAKMP SA or
IKE SA).
l Phase 2 is where SAs are negotiated on behalf of services such as IPSec or any other service
which needs key material and/or parameter negotiation. IPSec SA is used for transmitting
IP data.
Figure 5-8 shows the relationship of IKE and IPSec.
Figure 5-8 Relationship of IKE and IPSec

SA negotiation
Eudemon A IKE IKE Eudemon B
TCP/UDP SA SA TCP/UDP
IPSec IPSec
IP
Encripted IP packets
Figure 5-9 shows the procedure for setting up an SA.

Figure 5-9 Procedure for setting up an SA

Eudemon A Data flow is output from the interface Eudemon B
that applies IPSec
Step 1
Trigger SA of IKE negotiation stage 1

Step 2
Under the protection of security association of
IKE stage 1, IPSec SA of negotiation stage 2
Step 3
Communication under the protection
of security association of stage 2
Step 4
The process for setting up an SA is as follows:
1. On an interface that runs IPSec, an outbound packet should be compared with IPSec
policies.
2. If the packet matches an IPSec policy, search for the relevant SA. If the SA has not been
created, IKE will be triggered to negotiate an SA in stage 1, that is, IKE SA.
3. Under the protection of IKE SA, IKE continues to negotiate the SA in stage 2, that is, IPSec
SA.
4. The IPSec SA is used to protect the communication data.
IKE Negotiation Modes

As defined in RFC 2409 (the Internet Key Exchange), IKE negotiation in phase 1 can use two
modes:
l Main mode
In main mode, key exchange information is separated from identity and authentication
information. This separation realizes identity protection. The exchanged identity
information is protected by the Diffie-Hellman (DH) shared key generated. However, it
takes three extra messages to complete the process.
l Aggressive mode
In aggressive mode, payloads relevant with SA, key exchange, and authentication can be
transmitted simultaneously. Transmitting these payloads in one message helps reduce
round trips. However, this mode cannot provide identity protection.
Although aggressive mode has some functional limitations, it can meet the requirements
of some specific network environment.
For example, during a remote access, the responder (server end) has no way to learn about
the address of the initiator (terminal user) in advanced or the address of the initiator is
always changing, but both parties wish to create IKE SAs through pre-shared key
authentication. In this case, the aggressive mode without identity protection is the only
available exchange method. In addition, if the initiator has learnt about the responder's
policy or had a comprehensive understanding of it, aggressive mode can be adopted to
rapidly create IKE SAs.

5.3.3 IPSec Basic Concepts

The basic IPSec concepts include security association (SA), SA negotiation mode/operation
mode, authentication algorithm and encryption algorithm.
Security Association
IPSec provides secure communication between two endpoints. These two endpoints are called
IPSec peers.
IPSec allows systems, network subscribers, or administrators to control the granularity of

security services between peers.
For example, the IPSec policies of a group define that data streams from a subnet should be
protected with AH and ESP and be encrypted with Triple Data Encryption Standard (3DES) at
the same time. Moreover, the policies define that data streams from another site should be
protected with ESP only and be encrypted with DES only. IPSec can provide protection in
various levels for different data streams based on SA.
An SA is the basis and essence of IPSec. An SA specifies the shared policies and keys used by
two negotiating peers to protect their communication:
l Applied protocols (AH, ESP, or both)
l Operation mode of protocols (transport mode or tunnel mode)
l Encryption algorithm (DES and 3DES)
l Shared keys used to protect data in certain streams
l Life duration of the shared keys
SA is unidirectional. For directional communication between peers, at least two SAs are needed
to protect data streams in two directions. Moreover, if both AH and ESP are applied to protect
data streams between peers, two SAs are needed respectively for AH and ESP.
An SA is uniquely identified by a triplet, including:

l Security Parameter Index (SPI)
l Destination IP address
l Security protocol number (AH or ESP)
SPI is a 32-bit figure, uniquely identifying an SA. It is transmitted in an AH or ESP header.
An SA has a life duration, which can be calculated in one of the two methods:
l Time-based life duration

The SA is updated a specific interval.
l Traffic-based life duration
The SA is updated after a specified volume of data (in byte) is transferred.
SA Negotiation Modes
There are two negotiation modes to create SAs:
l Manual mode (manual)

Manual mode is more complicated than auto-negotiation mode.

In manual mode, all information required to create an SA has to be configured manually.

Moreover, it does not support some advanced features of IPSec, such as scheduled key
update. The advantage of manual mode is that it can realize IPSec without IKE.
l IKE auto-negotiation mode (isakmp)
In IKE auto-negotiation mode, an SA can be created and maintained by IKE auto-
negotiation as long as IPSec policies of IKE negotiation are configured.
Manual mode is feasible in the scenario where only a few peer devices exist or the network is
static and small in size. IKE auto-negotiation mode (isakmp) is recommended for medium or
large-sized dynamic networks.
Operation Modes of the IPSec Protocol

The IPSec protocol has two operation modes:
l Transport mode
In transport mode, AH or ESP is inserted after the IP header but before the transmission
layer protocol, or before other IPSec protocols. Take ah-esp for example. AH is inserted
after the IP header and before ESP.
l Tunnel mode
In tunnel mode, AH or ESP is inserted before the original IP header but after the new header.
An SA specifies the operation mode for the IPSec protocol. Figure 5-10 shows the data
encapsulation format for various protocols in the transmission mode and the tunnel mode.
Figure 5-10 Data encapsulation format for security protocols
Pro-Mode Transport Tunnel

tocol
IP TCP New IP Raw IP TCP
AH header
AH Data
header AH header header
Data
header
IP TCP ESP Raw IP TCP ESP ESP

ESP ESP Data ESP New IP
ESP header header Data
header header Tail Auth data header Tail Auth data
AH-ESP IP TCP Data ESP ESP New IP Raw IP TCP ESP ESP
AH ESP AH ESP header header Data
header header Tail Auth data header Tail Auth data
The tunnel mode is excellent than the transport mode in security. The tunnel mode can
authenticate and encrypt original IP data packets completely. Moreover, it can hide the client IP
address with the IPSec peer IP address.
With respect to performance, the tunnel mode occupies more bandwidth than the transport mode
because it has an extra IP header.
Therefore, when choosing the operation mode, you need weigh the security and performance.
Eudemon supports the tunnel mode only.
Authentication Algorithm and Encryption Algorithm

Details of the authentication algorithm and the encryption algorithm are as follows:

l Authentication algorithm
Both AH and ESP can authenticate integrity for an IP packet so as to determine whether
the packet is juggled. The authentication algorithm is performed through hybrid. The hybrid
is a kind of algorithm that can receive a message of arbitrary length and generate a message
of fixed length. The generated message is called message digest. IPSec peers calculate the
packet through the hybrid respectively. If they get identical summaries, the packet is
considered as integrated and intact.
Usually, there are two types of IPSec authentication algorithms:
– MD5
It inputs a message of arbitrary length to generate a 128-bit message digest.
– SHA-1
It inputs a message less than 264-bit to generate a 160-bit message digest.
The SHA-1 summary is longer than that of MD5, so SHA-1 is safer than MD5.
l Encryption algorithm
ESP can encrypt IP packets so that the contents of the packets are not snooped during the
transmission. Based on the encryption algorithm, packets are encrypted or decrypted with
the same key over the symmetric key system.
Generally, IPSec uses the following types of encryption algorithms:
– DES
It encrypts a 64-bit clear text with a 56-bit key.
– 3DES
It encrypts a clear text with three 56-bit keys (168 bits key in total).
– Advanced Encryption Standard (AES)
It encrypts a clear text through a 128-bit, 192-bit, or 256-bit key.
Obviously, 3DES is more excellent than DES in security. However, its encryption speed
is lower than that of DES.
5.3.4 NAT Traversal of IPSec

the original packet (without regard for AH mode).
NAT Traversal
One of the main applications of IPSec is to set up VPNs. In actual networking applications, there
is one scenario where IPSec VPN deployment may be hindered. When the initiator resides on
an private network and wishes to directly create an IPSec tunnel to the remote responder, the
creation inevitably requires the cooperation of IPSec and NAT. The main problem lies in how
IKE can discover the existence of the NAT gateway between the two endpoints during the
negotiation and how IKE can make ESP packets normally traverse the NAT gateway.
At first, the two endpoints of the desired IPSec tunnel need to negotiate the NAT traversal
capacities. The negotiation is implemented with the first two messages of IKE negotiation. The
Vendor ID payload specifies a group of data to identify the negotiation The definitions of the
payload data vary with the draft versions.
IKE depends on NAT-D payload to discover the NAT gateway.
The payload is used for two purposes:

l To discover the NAT gateway between the IKE peers

l To determine which side of the peer NAT device resides
The peer on the NAT side, as the initiator, needs to periodically send NAT-Keepalive packets
to help the NAT gateway ensure that the security tunnel is in active state.
IPSec Traversing NAT Gateway

the original packet (without regard for AH mode). In this case, when an ESP packet traverses
NAT gateway, NAT will translate the address and port number of the external layer IP header
of the packet and the added UDP header. When the translated packet reaches the peer end of
IPSec tunnel, it will be processed in the same method as the common IPSec. However, an UDP
header also needs to be added between the IP and ESP headers when the response packet is sent.
5.3.5 CA Authentication
The Eudemon supports Public Key Infrastructure (PKI) framework-based Certificate
Authentication (CA) mechanism. The CA mechanism provides a centralized key management
mechanism for IPSec networks and enhances the expansibility of the entire IPSec network.
CA Authentication Function
There are two types of IPSec networks:
l Non-certificate mechanism IPSec

For an IPSec network that does not adopt certificate mechanism, once a new device is
added, you need to change configurations related such as ACL setting on all the other
devices. Such operations are time-consuming and prone to errors.
l Certificate mechanism IPSec
In the IPSec network adopting certificate mechanism, Certification Authority (CA) is
adopted. CA is used to grant a certificate to each IPSec device.
When devices communicate with each other, they can check identity mutually just through
exchanging their certificates. After a new device is added on the IPSec network and applies
for a certificate to the CA, it can communicate with other devices. That can save you from
tedious and trivial configuration operations.
In addition, generating a certificate involves Rivest,Shamir and Adleman (RSA) password
pair. That can enhance the security of the network.
The Eudemon supports application, storage, and validation of certificates.
PKI System
As the collection of software and hardware systems and security policies, PKI provides a whole
security mechanism to provide users with a secure network environment. PKI uses public key
technique and digital certificate to authenticate the identify of a network device so as to ensure
the confidentiality, integrity, and authenticity of date on networks.
A PKI system consists of authentication institution, register institution, digital certificate, and
PKI storage.
Figure 5-11 shows the constitute of PKI system.

Figure 5-11 Constitute of PKI system
PKI application
Digital
certificate
Authentication
Register institution PKI storage library
institution
As shown in Figure 5-11:
l The authentication institution issues and administers certificates.

l The register institution audits identity, revokes certificates, and administers lists.
l Digital certificate technology is developed based on public key technology and mainly used
for authentication. A digital certificate is a file that is issued by the certificate authentication
institution with a digital signature and contains a public key as well as information of its
owner. A digital certificate can serve as an identity card for various entities to exchange
information and undertake business practice on networks.
l The PKI storage is used to keep and administer information such as certificates and logs;
in addition, it provides certain query functions.
Certificate
A digital certificate is granted by CA, a trusted third party, and used to authenticate a user's
identity for the sake of security during IKE/IPSec tunnel negotiation.
In a certificate, CA uniquely determines one IPSec device with Distinguished Name (DN). A
DN includes following information:
l Common user name
l Affiliation
l Country
l Name of the holder
NOTE
Each DN should be unique on networks.
In actual practice, there are two types of certificates:
l CA certificate
The CA certificate is used to check the validity of Certificate Revocation List (CRL) and
the local certificate issued by CA.
l Local certificate

The local certificate is issued by CA, and is used for communication between the IPSec
devices. The local certificate binds the name of the IPSec device to the local public key,
and acts as the network ID.
Each certificate has a life cycle, which is specified when the certificate is generated. The
authentication institution can withdraw a certificate thus terminating its life cycle earlier than
its due date.
Applying a Certificate
For an IPSec device, applying a certificate is to introduce itself to CA.
The process of generating and obtaining a certificate is as follows:
1. The PKI entity sends a certificate request that contains including identity information to
CA. Information contained in the request will be a part of the certificate granted by CA.
2. CA accepts the application and checks the following information to ensure that a certificate
is correctly bound to a certain identity:
l Credibility of the applicant
l Purpose for applying the certificate
l Reliability and authenticity of identity
This standard may require offline and non-automatic offline identity authentication such
as telephone, disk, and email authentication.
3. CA grants a certificate to the applicant.
CA may need to withdraw users' certificates before due date because of:
l Their identity names are changed.
l Their private keys are stolen or disclosed.
l Their affiliations are changed.
Process of Granting a Certificate

Process of granting a certificate need the following steps:
1. CA adopts MD5 or SHA-1 to generate abstract A based on the certificate.
2. CA uses its private key to encrypt abstract A. As a result, digital signature B is generated.
3. CA sends the digitally signed certificate signed.
Checking the Validity of a Certificate

Checking the validity of a certificate needs the following steps:
1. Checking the validity of the time.
2. Checking the validity of the signature.
(1) The IPSec device obtains digital signature B from the certificate and uses the public
key of CA to decrypt digital signature B, then generates abstract C.
(2) The IPSec device uses MD5 or SHA-1 to encrypt it. As a result, abstract A is generated.
(3) The IPSec device compares abstract A with abstract C.
If they match, the IPSec device considers the peer device is reliable.

3. Checking the validity of the CRL.
5.3.6 Realizing IPSec on the Eudemon

Through IPSec, the Eudemon and its peer can implement different means of protection for
different data traffic (authentication, encryption, or both).
Realizing IPSec on the Eudemon

The Eudemon helps realize the functions and mechanisms mentioned in the preceding sections.
The following describes the realization roadmap:

l Through IPSec, data streams between peers (here refer to the Eudemon and its peer) can
perform data stream-specific protection by means of authentication, encryption, or both.
Data streams are differentiated based on ACLs.
Security protection elements are defined in IPSec, including:
– Security protocol
– Authentication algorithm
– Encryption algorithm
– Operation mode
Following are defined in the IPSec policy:
– Association between data streams and the IPSec proposal (namely, apply a certain
protection on a certain data stream)
– SA negotiation mode
– Peer IP address settings (that is, the startpoint/endpoint of the protection path)
– Required key
– Life duration of the SA
l IPSec policies are applied on Eudemon interfaces.
Following details the procedure:
1. Define data streams to be protected.

A data stream is a collection of a group of traffic specified by:
l Source address/mask
l Destination address/mask
l Number of protocol over IP
l Source port number
l Destination port number
An ACL rule defines a data stream. Namely, traffic that matches an ACL rule is a data
stream logically. A data stream can be a single TCP connection between two hosts or all
traffic between two subnets. IPSec can apply different security protections on data streams.
So the first step in IPSec configuration is to define data streams.
2. Define an IPSec proposal.
An IPSec proposal defines the following for the data stream to be protected:
l Security protocol

l Authentication or encryption algorithm

l Operation mode (namely, the packet encapsulation mode)
AH and ESP supported by the Eudemon can be used either separately or jointly. AH
supports MD5 and SHA-1 authentication algorithms.
ESP supports MD5 and SHA-1 authentication algorithms as well as DES , 3DES, and AES
encryption algorithms.
As for a data stream, peers should be configured with the same protocol, algorithm, and
operation mode. Moreover, if IPSec is applied on two firewall (for example between the
Eudemons), the tunnel mode is recommended so as to hide the real source and destination
addresses.
Therefore, you need to define an IPSec proposal based on requirements so that you can
associate it with data streams.
3. Define an IPSec policy or IPSec policy group.
An IPSec policy defines the IPSec proposal adopted by a data stream. An IPSec policy is
uniquely defined by a name and a sequence number.
There are two types of security policies:
l Manual IPSec policies
l IKE negotiation IPSec policies
For manual IPSec policies, you need to manually set parameters such as key, SPI, and SA
life duration. If the tunnel mode is configured, you need to manually set the IP addresses
for the two endpoints of a security tunnel. For IKE negotiation IPSec policies, these
parameters are generated by IKE auto-negotiation.
An IPSec policy group is a collection of IPSec policies with the same name but different
sequence numbers. In an IPSec policy group, the smaller the sequence number is, the higher
the priority is.
4. Apply IPSec policies on an interface.
When you apply an IPSec policy group on an interface, all the security policies in the IPSec
policy group are applied on the interface. Different data streams passing through the
interface are protected with their respective security policies.
Realizing IKE on the Eudemon

The Eudemon supports the two modes of IKE, main mode and aggressive mode. Since the
Eudemon realizes IKE based on RFC 2408 and RFC 2409, the Eudemon can interwork with the
devices of most mainstream manufacturers.
To realize NAT traversal for IPSec on the Eudemon, you need to adopt the main mode or
aggressive mode at the stage 1 of IKE negotiation. In this case, the peer ID type is the name or
IP address of the peer. In addition, you need to configure ESP and encapsulate packets in tunnel
mode.
On the Eudemon, IKE is realized as follows:
1. Set the local ID used in IKE exchange.
2. Specify a series of attributes for the IKE peer, including IKE negotiation mode, pre-shared
key, peer address or peer ID, and NAT traversal to ensure the IKE negotiation.
3. Create an IKE IPSec proposal to determine the algorithm strength during IKE exchange,
namely, the security protection strength, including ID authentication method, encryption
algorithm, authentication algorithm, and DH group. Strength varies with algorithm. The

higher strength the algorithm has, the harder it is to decrypt the protected data. Algorithm
with higher strength consumes more calculation resources. In general, the longer the key
is, the higher the algorithm strength is.
Besides the preceding basic steps, IKE has the keepalive mechanism. It can determine whether
the peer can communicate normally. Two parameters are configured for the keepalive
mechanism, interval and timeout. When IPSec NAT traversal is configured, you can set a time
interval, at which NAT updating packets are sent.
After the preceding IKE configuration, you need to quote the IKE peer in the IPSec policy view
to complete IPSec auto-negotiation configuration.
5.4 GRE
The Generic Routing Encapsulation (GRE) protocol is used to encapsulate packet of the network
layer protocol such as Internet Packet Exchange (IPX). The encapsulated packet can be
transmitted in another network layer protocol such as IP. GRE is the third layer tunnel protocol
of the VPN.
5.4.1 GRE Overview
The GRE Protocol is used to encapsulate packet of the network layer protocol such as IP or
Internet Packet Exchange (IPX). The encapsulated packet can be transmitted in another network
layer protocol such as IP.
5.4.2 Implementation of GRE
The packets transmitted through the GRE tunnel need to be encapsulated and decapsulated.
5.4.3 GRE Application
The GRE protocol can implement many types of services. For example, the combination of GRE
and IPSec can protect multicast data.
5.4.1 GRE Overview

The GRE Protocol is used to encapsulate packet of the network layer protocol such as IP or
Internet Packet Exchange (IPX). The encapsulated packet can be transmitted in another network
layer protocol such as IP.
GRE is the third layer tunnel protocol of the VPN. Tunnel is the technique used between protocol
layers. It is a virtual point-to-point connection. In practice, it is a virtual interface that only
supports the point-to-point connection. The packet is transmitted through the interface, and
encapsulated and decapsulated at the two ends of a tunnel.
5.4.2 Implementation of GRE

The packets transmitted through the GRE tunnel need to be encapsulated and decapsulated.
Take the network of Figure 5-12 as an example for describing the two processes.

Figure 5-12 IP network interconnection through the GRE tunnel
Tunnel
IP Internet IP
group1 group2
Eudemon A Eudemon B
Encapsulation
The Eudemon A connects to the interface of IP group 1 and receives the IP packet. Then the IP
packet is sent to the IP module. The IP module checks the destination address field at the IP
header and decides the route. If the destination address is the virtual network number of the
tunnel, the packet is sent to the port of the tunnel. The packet is encapsulated at the port of the
tunnel, and sent back to the IP module. The IP packet header is encapsulated. The packet is sent
to a network interface based on the destination address and routing table.
Decapsulation
Decapsulation is reversed to encapsulation. The Eudemon B receives the IP packet from the port
of the tunnel. If the destination address of the packet is Eudemon B, the IP header of the packet
is decapsulated. The packet is sent to the GRE module. The GRE module checks the key, verifies
the checking results, and checks serial number of the packet, and then decapsulates the GRE
header. The packet is sent to the IP module. The IP module handles the packet in the common
way.
The packet to be encapsulated and routed is called payload. The payload is encapsulated into a
GRE packet and then an IP packet. In this way, it can be forwarded on the network layer. The
routing protocol for forwarding the packet is called Delivery Protocol or Transport Protocol.
Figure 5-13 shows the format of the encapsulated packet.
Figure 5-13 Format of the encapsulated packet
Delivery Header Transport Protocol
GRE Header Encapsulation Protocol
Payload Packet Passenger Protocol
For example, Figure 5-14 shows an IP packet transported in the tunnel.

Figure 5-14 IP packet transported in the tunnel
IP GRE IP
Passager Protocol
Encapsulation Protocol
Transport Protocol
5.4.3 GRE Application

The GRE protocol can implement many types of services. For example, the combination of GRE
and IPSec can protect multicast data.
Network Enlargement
Figure 5-15 Network enlargement
Tunnel
Eudemon Eudemon
PC PC
As shown in Figure 5-15, when the number of hops exceeds 15, the two terminals can not
communicate with each other. The tunnel hides some hops. In this way, the network is enlarged
and the communication is recovered.

Inconsistent Subnet Connection
Figure 5-16 Inconsistent subnet connection
Tunnel
IP IP
group1 group2
Eudemon Eudemon
VLAN
As shown in Figure 5-16, group 1 and group 2 are IP subnet in different cities. The tunnel
connects group 1 and group 2, and builds the VPN.
GRE-IPSec Tunnel
Figure 5-17 GRE-IPSec tunnel
Eudemon Eudemon
Corporate Remote office
intranet network
IP Netwrok
GRE Tunnel
IPSec Tunnel
As shown in Figure 5-17, the multicast data can be encapsulated in the GRE packet and
transmitted in the GRE tunnel. According to the protocol, the IPSec only encrypts and protects
unicast data. To transmit multicast data such as routing protocol, voice, and video, set up a GRE
tunnel and encapsulate the multicast data in the GRE packet. Then the IPSec encrypts the GRE
packet. In this way, the packet can be transmitted in the IPSec tunnel.
The user can choose to record the keyword of the GRE tunnel interface, and check the
encapsulated packet in end-to-end manner.
Encapsulation and decapsulation, and data increase due to the encapsulation may reduce the
forwarding efficiency of the Eudemon.
5.5 SSL VPN

The SSL VPN is a VPN of enhanced SSL/TLS functions. In addition to providing the web access
service and TCP and UDP applications, the SSL VPN protects IP communications. Additionally,
SSL VPN communications are based on the standard TCP or UDP and are not confined by NAT;

therefore, users anywhere can access intranet resources through the virtual gateway proxy. The
SSL VPN provides a simpler and more flexible solution to secure remote access, hence greatly
reducing the cost of VPN maintenance.
5.5.1 Introduction to SSL
SSL is a security protocol, which provides secure connections for TCP-based application layer
protocols. For example, SSL can provide secure connections for HTTP. SSL widely applies to
fields such as e-commerce and online-banking, which provides security guarantees for data
transmission on the network.
5.5.2 SSL VPN Service
SSL VPN services refer to the services that can be accessed through the SSL VPN, including
the Web proxy, network expansion, file sharing, and port forwarding.
5.5.1 Introduction to SSL

SSL is a security protocol, which provides secure connections for TCP-based application layer
protocols. For example, SSL can provide secure connections for HTTP. SSL widely applies to
fields such as e-commerce and online-banking, which provides security guarantees for data
transmission on the network.
SSL can be classified into the following:

l The lower layer is the SSL record protocol.
This protocol divides, compresses, computes and adds MAC addresses for, and encrypts
the data of the upper layer. Then, the protocol transmits the records to the peer end.
l The upper layer is the SSL handshake protocol, SSL change cipher spec protocol, and SSL
alert protocol.
– SSL handshake protocol: A session between the client and the server is established
through the SSL handshake protocol. The session contains a group of parameters, such
as the session ID, peer certificate, encryption algorithm list (including the key exchange
algorithm, data encryption algorithm, and MAC algorithm), compression algorithm,
and master key. An SSL session can be shared by multiple connections, thus reducing
session negotiation costs.
– SSL change cipher spec protocol: The client and the server inform the receiving end
through the SSL change cipher spec protocol. The subsequent packets adopt the newly
negotiated encryption algorithm list and key for protection and transmission.
– SSL alert protocol: The SSL alert protocol allows one end to report alarm information
to another end. The message includes the severity level and description of the alarm.
The SSL protocol has the following features:

l Confidentiality
After the handshake protocol negotiates the key, data is encrypted by the symmetric
cryptographic algorithm.
l Reliability
Secure hash algorithms are used to check the integrality of a message through a message
authentication code with a key.
l Identity authentication
The identity of an entity can be checked by a public key encryption algorithm.
The handshake process of the SSL-based communication is as follows:

1. The SSL client connects to the SSL server and requires the server to authenticate the server
itself.
2. The server authenticates its identity by sending its digital certificate.
3. The server sends a request to authenticate the certificate on the client.
4. The encryption algorithm and the HASH function are negotiated. The former is used to
encrypt the message, and the latter is used to check the integrity. The client usually provides
the list of all supported algorithms, and the server selects the most powerful algorithm from
the list.
5. The client and the server generate the session key as follows:
(1) The client implements the following actions:
Generating a random number
Encrypting the number with the server's public key that is obtained from the certificate
of the server
Sending the encrypted number to the server
(2) The server responds to the client by using random data. The client's key is used if it
is available; otherwise, data is sent in plain text.
(3) The key is generated from these random numbers by using the HASH function.
Like the IP Security Protocol (IPSec), SSL provides encryption and identity authentication. SSL,
however, encrypts only the application data but not all data transmitted between two hosts.
To use SSL for communications between VPNs, both communication parities must support the
SSL. Currently, most common applications such as IE and Netscape browsers, Outlook, and
Eudora email support the SSL.
5.5.2 SSL VPN Service

SSL VPN services refer to the services that can be accessed through the SSL VPN, including
the Web proxy, network expansion, file sharing, and port forwarding.
The SSL protocol and proxy enable users to access intranet resources remotely and securely.
There are mainly four SSL VPN services:
l Web proxy
Using the web proxy, users can securely access web resources through standard browsers
without installing any client software. The accesses include the intranet web page access,
Outlook web access, and iNotes access.
l Network extension
Network extension is a function extension based on the SSL protocol. It supports all IP
applications to ensure that remote users access intranet resources the way they access a
Local Area Network (LAN).
The virtual network card generated by the network extension client intercepts IP packets,
encrypts them based on the SSL protocol, and then forwards them to the virtual gateway.
In this way, users who have installed the client can work as on hosts in the intranet, accessing
all the intranet resources rapidly and securely when no Access Control List (ACL) is active.
l File sharing
File sharing uses protocol translation technologies to translate network file systems, such
as translating the Network File System (NFS) protocol to the Secure Hypertext Transfer

Protocol (HTTPS). Users can create and browse the directory, and create, download,
upload, modify, and delete files through the browser.
l Port forwarding
The SSL protocol was originally applied to browsers and port forwarding is an application
extension of the SSL protocol. Port forwarding controls user access to application services
at the application layer. The services include Telnet, remote desktop, FTP, and email.
To implement port forwarding, you need to run an ActiveX control on the client as a port
repeater to monitor connections on a port. When data packets are received by the port, they
are transmitted to the Eudemon through the virtual gateway. The Eudemon decapsulates
the packets, and then forwards them to the destination application server.
Through configurations, the administrator can confine internal resources that users access.
Compared with the network extension function, port forwarding ensures higher security,
and theoretically has a faster access rate.
5.6 BGP/MPLS IP VPN

BGP/MPLS IP VPN is a kind of PE-based Layer 3 Virtual Private Network (L3VPN) technology
in the Provider Provisioned VPN (PPVPN). It uses the Border Gateway Protocol (BGP) to
advertise VPN routes and uses Multiprotocol Label Switch (MPLS) to forward VPN packets on
the provider backbone network.
NOTE
The internetworking capability of the Eudemon is the focus. The Eudemon here is looked as a router.
Traditional terms and labels of routers are used here to describe the Eudemon. Therefore, the Eudemon
replaces the router in the following sections.
5.6.1 BGP Overview

BGP is an inter-AS dynamic route discovery protocol.
5.6.2 MPLS Overview
MPLS works between the data link layer and the network layer in the TCP/IP protocol stack. It
provides the IP layer with connection services and obtains services from the data link layer.
MPLS forwards packets based on labels instead of IP addresses. MPLS supports multi-layer
labels and is connection-oriented; therefore, MPLS is widely used in VPN, TE, and QoS.
5.6.3 LDP Overview
The Label Distribution Protocol (LDP) is the control protocol of MPLS. Equal to the signaling
protocol in the traditional network, it is in charge of the FEC classification, label distribution as
well as the LSP establishment and maintenance.
5.6.4 BGP /MPLS IP VPN Introduction
BGP/MPLS IP VPN is a kind of PE-based L3VPN technology in the Provider Provisioned VPN
(PPVPN). It uses BGP to advertise VPN routes and uses MPLS to forward VPN packets on the
provider backbone network. BGP/MPLS IP VPN has flexible networking modes, good
extensibility and convenient support for MPLS QoS and MPLS TE. Hence, it is widely used.
5.6.1 BGP Overview

BGP is an inter-AS dynamic route discovery protocol.
Introduction to BGP
Three early versions of BGP are BGP-1 (RFC 1105), BGP-2 (RFC 1163) and BGP-3 (RFC
1267). The current version in use is BGP-4 (RFC 1771). BGP-4 applies to distributed structure

and supports Classless Inter-Domain Routing (CIDR). BGP-4 is increasingly becoming the
virtually exterior routing protocol standard on the Internet and is commonly used between ISPs.
BGP Characteristics
The characteristics of BGP are as follows:
l BGP is an Exterior Gateway Protocol (EGP). Different from such Interior Gateway
Protocols (IGPs) as OSPF and RIP, it focuses on route propagation control and selection
of optimal routes rather than discovery and calculation of routes.
l Eliminating route loop completely by adding AS path information to BGP routes.
l Using TCP as transport layer protocol so as to enhance reliability of the protocol.
l When routes are updated, BGP only transmits updated routes, which greatly reduces
bandwidth occupation by route propagation and can be applied to propagation of great
amount of routing information on the Internet.
l BGP-4 supports CIDR. This is an improvement comparing with BGP-3.
l In consideration of management and security, users desire to perform control over outgoing
and incoming routing information of each AS. BGP-4 provides abundant route policies to
implement flexible filtering and selecting of routes.
l BGP-4 can be extended easily to support new developments of the network.
NOTE
l With a brand-new perspective of IP address, Class-A network, Class-B network and Class-C network
are no longer distinguished in CIDR. For example, by means of CIDR notation, an illegal Class-C
network address 192.213.0.0 (255.255.0.0) will turn into 192.213.0.0/16, a legal super network address,
wherein the "/16" indicates that the subnet mask is composed of 16 bits starting from the left of the
address.
l The introduction of CIDR simplifies route aggregation. Actually, route aggregation is the process of
aggregating several different routes, which turns advertisement processes of several routes into the
advertisement of single route so as to simplify the routing table.
BGP Operation Modes

BGP runs on a router in any of the following modes:
l Internal BGP (IBGP)

l External BGP (EBGP)
The BGP is called IBGP when it runs in an AS and is called EBGP when it runs among different
ASs.
Message Types of BGP

Running of BGP is driven by messages of the following types:
l Type 1, Open: It is the first message sent after the creation of a connection, which is used
to create the connection relation between BGP peers.
l Type 2, Update: It is the most important information in BGP system, which is used to
exchange routing information between peers. It is composed of up to three parts:
unreachable route, path attributes and network layer reachability information (NLRI).
l Type 3, Notification: It is used to notify errors.

l Type 4, Keepalive: It is used to check the validity of a connection.

l Type 5, Route-Refresh: It is used to notify the peer about its route refresh capability.
The first four messages are defined in RFC 1771, while Type 5 message is defined in RFC 2918
(Route Refresh Capability for BGP-4).
Route Mechanism of BGP

On the first startup of the BGP system, the BGP router exchanges routing information with its
peers by transmitting the complete BGP routing table, after that only update messages are
exchanged. In the operating of the system, Keepalive messages are received and transmitted to
check the correctness of the connections between various peers.
The router transmitting BGP messages is called a BGP speaker, which receives and generates
new routing information continuously and advertises the information to the other BGP speakers.
When a BGP speaker receives a new route advertisement from another AS, it will advertise the
route, if the route is better than the current route that has been learned or is a new route, to all
the other BGP speakers in the AS.
A BGP speaker calls other BGP speakers that exchange information with it peers and multiple
related peers compose a peer group.
BGP follows the policies below when advertising routes:
l If there are several optional routes, BGP speaker selects the optimal one only.
l BGP speaker only advertises the route it uses to the peers.
l BGP speaker advertises the route received from EBGP to all the BGP peers, including
EBGP and IBGP peers.
l BGP speaker does not advertise the route received from IBGP to the IBGP peers.
l BGP speaker does not advertise the route received from IBGP to the EBGP peers (in
Eudemon, the synchronous relationship does not exist between IGP and BGP).
l On establishing a peer connection, BGP speaker advertises all the BGP routes to the peer.
BGP uses the following policies to select routes:
1. First discard the route whose next hop is unreachable.

2. Select the route with the highest local-preference.
3. Select the route initially transmitted by the local router.
4. Select the route passing the least number of ASs (AS-Path).
5. Select the route with the lowest origin type.
The origin attribute defines the origin of a route. It marks the paths of a BGP route. The
origin attribute is divided into the following types:
l IGP: has the highest priority. The original attribute of a route obtained by IGP of the
AS originating the route is IGP. For example, the origin attribute of the routes imported
to the BGP routing table by using the network command is IGP.
l EGP: has the second highest priority. The origin attribute of the routes obtained through
EGP is EGP.
l Incomplete: has the lowest priority. The origin attribute of the routes learned through
other ways, such as the routes imported by BGP using the import-route command, is
Incomplete.

6. Select the route with the lowest Multi-Exit Discriminator.

The MED attribute is equal to the metrics used by IGP. It is used to determine the optimal
route when the traffic enters the AS. When a BGP router obtains multiple routes to the same
destination address but with different next hops through EBGP peers, the route with the
smallest MED value is selected as the optimal route. The MED attribute is exchanged only
between two neighboring ASs. The AS that receives this attribute does not advertise it to
any other ASs.
7. Select the route learned from EBGP.
8. If the load balancing is configured and there are multiple external routes to an AS/AS
confederation, select several routes to perform the load balancing based on the number of
configured routes.
9. Select the route advertised by the router with the lowest BGP ID.
MBGP
The traditional BGP-4 can only manage the routing information of IPv4 and has limitation in
inter-AS routing when used in the application of other network layer protocols (such as IPv6
etc).
In order to support multiple network layer protocols, IETF extended BGP-4 and formed the
Multiprotocol Extensions for BGP-4 (MBGP). The present MBGP standard is RFC 2858
(Multiprotocol Extensions for BGP-4).
MBGP is compatible backward, that is, a router supporting BGP extension can be interconnected
with a router that does not support it.
In the packets BGP-4 uses, three pieces of information related to IPv4 are carried in the update
packet. They are NLRI, Next_Hop (The next hop address) in path attribute and Aggregator in
path attribute (This attribute includes the BGP speaker address which forms the summary route).
To support multiple network layer protocols, BGP-4 need reflect the information about the
specified network layer protocol to NLRI and the Next_Hop in the route attribute. Two new path
attributes are imported into MBGP:
l MP_REACH_NLRI: Multiprotocol Reachable NLRI. It is used to advertise reachable

routes and next-hop information.
l MP_UNREACH_NLRI: Multiprotocol Unreachable NLRI. It is used to remove
unreachable routes.
These two attributes are optional non-transitive. Therefore, the BGP speaker that does not
provide multi-protocol capability will ignore the information about them and will not transfer
them to other peers.
The router adopts address family to differentiate different network layer protocols. For values
of address family, refer to RFC 1700. The Eudemon provides various MBGP extended
applications including extension of multicast and BGP/MPLS VPN etc. Different extended
applications should be performed in their own address family views.
BGP Peer and Peer Group

Definitions of the peer and peer group have been mentioned in "Route Mechanism of BGP".
A BGP speaker calls other BGP speakers that exchange information with it peers and multiple
related peers compose a peer group.

In Eudemon, a BGP peer cannot separate from its peer group and exist independently. In other
words, a peer must belong to a specific peer group. To configure a BGP peer, you must first
configure a peer group and then add the peer into the peer group.
The application of the BGP peer group can facilitate the configuration. When a peer is added
into a peer group, it will obtain the same configuration with the peer group, which can simplify
the configuration in some cases and improve the efficiency of route advertisement.
In the case of any changes in the configuration of the group, configuration of each group member
changes accordingly. For some attributes, you can configure them only for certain member by
designating its IP address. The preference of attribute configured through the IP address is higher
than that of attribute configured through the peer group. Note: a peer group member must adopt
the same route update policy with its group, while the egress policies can be different.
5.6.2 MPLS Overview

MPLS works between the data link layer and the network layer in the TCP/IP protocol stack. It
provides the IP layer with connection services and obtains services from the data link layer.
MPLS forwards packets based on labels instead of IP addresses. MPLS supports multi-layer
labels and is connection-oriented; therefore, MPLS is widely used in VPN, TE, and QoS.
Introduction to MPLS
With the prevalence of the Internet early in the 90s, the IP technology that adopts the longest
match for search becomes the bottleneck to the forwarding performance of the network due to
limitation of the hardware technology. The ATM technology uses the label with fixed length
and maintains the label table with the size much smaller than the size of the routing table.
Therefore, compared with the IP technology, the ATM technology can provide higher
forwarding performance.
The traditional IP technology is simple to implement but limited in performance. The ATM
technology has higher performance but is difficult to popularize because of its complex signaling
and high cost in deployment. The MPLS technology thus emerges to combine the advantages
of IP and ATM technologies.
Initially, MPLS emerges to improve the forwarding speed of the router. With the development
of the ASIC technology, the speed of searching routes is not the bottleneck to the network
development. Therefore, MPLS does not feature in high-speed forwarding. MPLS supports
multi-layer labels and is connection-oriented; therefore, MPLS is widely used in VPN, TE, and
QoS.
MPLS Basic Concepts

MPLS basic concepts are as follows:
l Forwarding equivalent class
MPLS is actually a classification forwarding technology which takes the packets with the
same forwarding mode as a class. This is called Forwarding Equivalent Class (FEC). The
packets of the same FEC are treated same in the MPLS network.
Packets with identical source address, destination address, source port, destination port,
protocol type, VPN or any of their combination can be grouped into an FEC. For instance,
packets that are transmitted to the same destination through the longest matching algorithm
belong to an FEC.
l Label

Label is an identifier of short and fixed length with local significance, and used to identify
a particular FEC uniquely. In some cases, such as load sharing, one FEC may have multiple
labels, while one label can only identify one FEC.
The label of four bytes is carried in the packet header, indicating the local significance
except the topology information. The encapsulation structure of the label is shown in Figure
5-18.
Figure 5-18 Label encapsulation structure
Label Exp S TTL
Totally the label contains four fields:

– Label: label value, 20bits, used as the pointer for forwarding.
– Exp: 3bits, reserved, used for experiment.
– S: 1bit, MPLS supports hierarchical label structure, i.e., multi-layer label. Value 1 refers
to the label of bottom layer.
– TTL: 8bits, with the same meaning as TTL in IP packet.
As a connection identifier, the label is encapsulated in the label field of some link layer
protocols similar to the VPI/VCI in ATM or DLCI in Frame Relay (FR). For the link layer
protocol that does not have a label field, the label is also available by being encapsulated
in a shim between the link layer and the IP layer.
The encapsulation location of the label in packet is shown in Figure 5-19.
Figure 5-19 Encapsulation location of label in packet

Ethernet Layer 3
Ethernet/SONET/SDH Label
header/PPP header packet
Layer 3
Frame mode ATM ATM header Label
packet
Layer 3
Cell mode ATM VPI/VCI
packet
l LSR
A Label Switched Router (LSR) is a basic element in the MPLS network and all LSRs
support the MPLS protocol.
An LSR is composed of a control plane and a forwarding plane:
– The control plane is to allocate labels, select routes, create a label forwarding table, set
up or delete an LSP.
– The forwarding plane is to forward a packet received according to the label forwarding
table.

l LSP
A Label Switched Path (LSP) refers to the path where an FEC is transmitted in the MPLS
network.
Similar to a virtual circuit of ATM or FR, the LSP functions as a unidirectional path from
Ingress to Egress, in which each node is an LSR.
l LDP
The Label Distribution Protocol (LDP) is the control protocol of MPLS. Equal to the
signaling protocol in the traditional network, it is in charge of the FEC classification, label
distribution as well as the LSP establishment and maintenance.
MPLS Network Structure

As shown in Figure 5-20, the basic composing unit of MPLS network is LSR, and the network
consisting of LSRs is called MPLS domain.
The LSR that is located at the edge of the domain and connected with other customer network
is called Labeled Edge Router (LER). And the LSR located inside the domain is called core
LSR. The core LSR can be either the router that supports MPLS or the ATM-LSR upgraded
from ATM switch. The LSRs intercommunicate over MPLS within the domain, while an LER
is adopted to communicate with routers outside the MPLS domain over IP.
The labeled packets are transmitted along the LSP composed of a series of LSRs. The import
LSR is called Ingress, the export LSR is called Egress, and the middle LSR is called Transit.
Figure 5-20 MPLS Network Structure
(1)
Network1 (2)
LSP
(3)
Ingress (4)
Network2
Egress
MPLS Core
Switch (LSR)
MPLS Edge
Router (LER)
The basic working process of MPLS is as follows:

1. The LDP along with the traditional routing protocols such as OSPF establishes a routing
table and a label map for service-desired FECs in each LSR.
2. The ingress LER receives a packet, determines its FEC and then adds a label to the packet,
which is then known as an MPLS labeled packet.
3. LSRs forward the packet according to its label and the label forwarding table without any
layer 3 processing.
4. The egress LER takes off the packet's label and proceeds with the forwarding.

MPLS is a kind of Tunnel technologies rather than a type of service or application. It is a routing
and switching platform possessing the label switched forwarding and network layer routing
technologies. It supports multiple layer protocols, and can guarantee the information
transmission security.
Label Management
In the MPLS architecture, label management includes label distribution, label control, and label
retention. Details of label management are as follows:
l Label Distribution Mode

In the MPLS architecture, downstream LSR makes the decision to bind a particular label
to a particular FEC, and then the downstream LSR notifies the upstream LSR. That is to
say, the label is specified by the downstream LSR, and the assigned label is distributed
from downstream to upstream.
There are two label-distribution modes in MPLS:
– Downstream Unsolicited (DU) label distribution
For a specific FEC, the mode when it is unnecessary for LSR to obtain label request
message from upstream before label assignment and distribution, is referred to as DU
label distribution.
– Downstream-on-Demand (DoD) label distribution.
For a specific FEC, the mode when LSR performs label assignment and distribution
after it has received the label request message, is referred to as DoD label distribution.
It must be agreed on which label distribution mode is used between the upstream LSR and
the downstream LSR with label distribution neighbor relationship, otherwise, the LSP
cannot be established.
l Label Control Mode
There are two kinds of label control modes:
– Independent label control mode
When independent label control mode is in use, each LSR can notify label mapping to
the LSR connected with it at any time.
– Ordered label control mode
When ordered label control mode is in use, only when LSR receives specific label
mapping message from a certain FEC or when LSR serves as the egress node of LSP,
can LSR send label mapping message upstream.
l Label Retention Mode
A label retention mode indicates the way that an LSR binds a label received but unused
temporarily to an FEC.
There are two label-retention modes: liberal label retention mode and conservative label
retention mode.
Suppose there are two routers, Ru and Rd. For a specific FEC, if LSR Ru has received the
label binding from LSR Rd, in case Rd is not the next hop of Ru and Ru saves this binding,
then Ru adopts liberal label retention mode. If Ru discards this binding, then Ru adopts
conservative label retention mode.
In case it is required that LSR be capable of adapting to route variation rapidly, liberal label
retention mode can be adopted. In case it is required that a few labels be saved in LSR, then
conservative label retention mode can be used.

Labeled Packets Forwarding

On ingress, the packets entering the network are classified into Forwarding Equivalence Class
(FEC) according to their characteristics. The packets with the same FEC will pass through the
same path (i.e., LSP) in MPLS area. LSR assigns a short label for the incoming FEC packet, and
then forwards it through the corresponding interface.
On the LSR along the LSP, the mapping table of the import/export labels has been established
[the element of this table is referred to as Next Hop Label Forwarding Entry (NHLFE)]. When
the labeled packet arrives, LSR only needs to find the corresponding NHLFE from the table
according to the label and replace the original label with the new special label, and then forward
the labeled packet. This process is called Incoming Label Map (ILM).
NOTE
TTL processing:
l For labeled packet of public network, it is necessary to copy the TTL value in the original IP packet
into the TTL field in the label. While forwarding the label type packet, LSR will perform minus one
operation for the TTL field of the label on the top of the stack. When the label is out of the stack, the
TTL value on the top of the stack is copied back to IP packet or the label of lower layer.
l However, while LSP goes through the non-TTL LSP segment composing of ATM-LSR or FR-LSR,
the LSR inside the non-TTL LSP segment is not capable of processing TTL field. In this case, it is
necessary to carry out unified processing for TTL while entering non-TTL LSP segment, namely, to
reduce for one time the value that reflects the length of this non-TTL LSP.
LSP Tunnel
MPLS supports LSP tunnel technology.
On an LSP path, LSR Ru and LSR Rd are upstream and downstream for each other. However,
the path between LSR Ru and LSR Rd may not be part of the path provided by routing protocol.
MPLS allows establishing a new LSP path between LSR Ru and LSR Rd, with LSR Ru and
LSR Rd respectively being the starting point and ending point of this LSP. The LSP between
LSR Ru and LSR Rd is referred to as the LSP tunnel, which avoids the traditional encapsulated
tunnel on the network layer.
If the routes along which the tunnel passes is consistent with the route obtained hop by hop from
routing protocol, this tunnel is called hop-by-hop routing tunnel; if not consistent, the tunnel is
called explicit routing tunnel.
As shown in Figure 5-21, LSP<R2 R21 R22 R3> is a tunnel between R2 and R3.
Figure 5-21 LSP tunnel
Layer 1
R1 R2 R4
R3
Layer 2
R21 R22

Multi-Layer Label Stack

When the packet is sent in LSP tunnel, there will be multiple layers for the label of the packet.
Then, on the ingress and egress of each tunnel, it is necessary to implement incoming and
outgoing operation for the label stack. For each incoming operation, the label will be added with
one layer. And there is no depth limitation for the label stack from MPLS.
The labels are organized according to the principle "last in first out" in the label stack, and MPLS
processes the labels beginning from the top of the stack.
Suppose that a packet has the label stack depth of m, then the label at the bottom of the stack is
the label of first level, and the label at the top of the stack is the label of level m. The packet
with no label can be regarded as the packet of blank label stack (namely, the label stack depth
is zero).
5.6.3 LDP Overview

The Label Distribution Protocol (LDP) is the control protocol of MPLS. Equal to the signaling
protocol in the traditional network, it is in charge of the FEC classification, label distribution as
well as the LSP establishment and maintenance.
The LDP is responsible for message regulation and relevant processing in the label distribution.
An LSR can directly map the routing information on the network layer to a switch path on the
data link over LDP, and then establish an LSP on the network layer. The LSP can be set up
between two adjacent LSRs or terminated at an egress LSR. All the middle LSRs in between
adopt the label switching.
LDP Basic Concepts

LDP basic concepts are as follows:
l LDP Peers
LDP peers refer to two LSRs undergo an LDP session by exchanging label/FEC mapping
information over LDP.
The LDP peers can obtain the other's label information through an LDP session, namely,
the LDP is bidirectional.
l LDP Session
An LDP session is to exchange label and release messages between LSRs. There are two
types of LDP session:
– Local LDP Session: an LDP session between two directly connecting LSRs.
– Remote LDP Session: an LDP session between two indirectly connecting LSRs.
l LDP Message
There are four types of message involved in the LDP:
– Discovery message: used to notify or maintain the existing LSRs in the network.
– Session message: used to establish, maintain or terminate a session between LDP peers.
– Advertisement message: used to establish, modify or delete a flag, that is, an FEC
binding.
– Notification message: used to provide suggestive messages or error notifications.
l Label Space

A label space refers to the range of labels that can be allocated to LDP peers. You can
specify a label space for each interface of an LSR or for the entire LSR.
l LDP Identifier
An LDP identifier is to identify a special LSR label space. It is a six-byte value in the
following format:
LSR ID: Label space number
The LSR ID occupies four bytes and the label space number occupies two bytes.
The LSR ID and the label space number constitutes the LDP identifier, which identifies
the label space used by the LSR and establishes and maintains LDP sessions between LSRs.
LDP Working Process

Figure 5-22 illustrates the LDP label distribution.
Figure 5-22 Label distribution process

LSP1
B C
Ingress Egress
A D
LSP2 Label
request
E
Label F G
mapping MPLS LSR
MPLS LER H
LDP session
On an LSP, along the data transmission direction, neighboring LSRs are respectively called as
upstream LSR and downstream LSR. On LSP1 shown in Figure 5-22, LSR B is the upstream
LSR of LSR C.
Labels are distributed in two modes, generally DoD mode and DU mode. The main difference
between these two modes resides in whether the label mapping distribution is up to upstream
request or initially performed downstream.
Processes of the two modes of label distribution are as follows:
l DoD mode
In DoD mode, the label is distributed in this way: the upstream LSR sends label request
message (containing FEC descriptive information) to the downstream LSR, and the
downstream LSR distributes label for this FEC, and then sends the bound label back to the
upstream LSR through label mapping message.
When the downstream LSR feeds back the label mapping message depends on whether this
LSR uses independent label control mode or sequential label control mode:

– When the sequential label control mode is used by the downstream LSR, the label
mapping message is sent back to its upstream LSR if only it has received the label
mapping message from its downstream LSR.
– And when the independent label control mode is used by the downstream LSR, it will
send label mapping message to its upstream LSR immediately, no matter if it has
received the returned label mapping message from its downstream LSR.
Usually, the upstream LSR selects the downstream LSR according to the information in its
routing table. In Figure 5-22, the sequential label control mode has been used by the LSRs
on the way along LSP1, and the independent label control mode has been used by the LSRs
on LSP2.
l DU mode
In DU mode, the label is distributed in the following way: when LDP session is established
successfully, the downstream LSR will actively distribute label mapping message to its
upstream LSR. The upstream LSR saves the label mapping information and processes the
received label mapping information according to the routing table.
LDP Basic Operation

The basic LDP operation includes:
1. Discovery phase
The originating LSR periodically sends a Hello message to its adjacent LSRs, notifying
them its peer information, so that the LSR can automatically find its LDP peer.
There are two types of LDP discovery mechanisms:
l Basic discovery mechanism
The basic discovery mechanism is to discover the local LDP peer, that is, to establish
a local LDP session between directly connecting LSRs.
In this case, the LSR periodically sends a Hello message of the LDP link to a specific
port, carrying the LDP identifier of the label space where the specific port belongs as
well as other relevant information. If the LSR receives the Hello message over the
specific port, it knows that there is a potential reachable peer on the link layer and also
learns the label space of the port.
l Extended discovery mechanism
The extended discovery mechanism is to discover a remote LDP peer, that is, to establish
a remote LDP session between non-directly connecting LSRs.
In this case, the LSR periodically sends an LDP Targeted Hello message to a specific
IP address.
The LDP Targeted Hello message is sent in a UDP packet to the Well-known LDP
discovery port of the specific address. The message contains the desired label space of
the LSR as well as all relevant information.
2. Session establishment and maintenance
After the peer is set up, the LSR begins to establish a session by the following two steps:
(1) Establishing a connection on the transport layer, that is, establishing TCP connection
between the LSR peers.
(2) Initializing the session and negotiating the parameters involved in the session, such
as the LDP version, label distribution mode, timer timeout and label space.
3. LSP setup and maintenance

Actually, LSP establishment refers to the process of binding FEC with the label, and then
advertising this binding to the adjacent LSR on LSP.
This process is implemented through LDP in the following steps:
(1) When the routing of the network changes and an LER finds a new destination address
in its routing table not belonging to any existing FEC, the LER needs to create an FEC
for the address and determine routes for the FEC, and then sends a label request
message to the downstream LSR, indicating the FEC to be allocated.
(2) After the downstream LSR receives the label request message and records it, it relays
the message to the next hop LSR according to its routing table.
(3) When the label request message reaches the destination LSR or the Egress LSR in the
MPLS network and either can allocate the requested label, it will allocate the label to
the FEC after the label request message passes its authentication. Then it sends a label
mapping message to the upstream LSR with the allocated label information included.
(4) The upstream LSR compares the received label mapping message with its label
database, allocates the matched label to the FEC, adds the map to its label forwarding
table, and then sends the label mapping message to its upstream LSR.
(5) When the Ingress ISR receives the label mapping message, it adds the map to its label
forwarding table. In this way, an LSP is set up and the corresponding FEC data packet
can be forwarded based on its label.
4. Session termination
The LDP checks the session integrity depending on the LDP PDU transmitted in the session
connection.
The LSR sets up a living timer for each session and refreshes the timer after receiving an
LDP PDU. If the timer expires before the reception of an LDP PDU, the LSR considers the
session interrupted and tears down the corresponding connection on the transport layer to
terminate the session.
LDP Loop Detection

It is necessary to prevent path loop from happening while establishing LSP in the MPLS domain.
The LSP loop detection mechanism can detect such path loop and avoid message loop occurring
such as the label request message.
LDP loop detection has two methods as follows:
l Maximum Hop Count
The maximum hop count method is to contain the hop-count information in the message
bound with the forwarding label. This value is added by one for each hop. When the value
exceeds the specified maximum value, it is considered that a loop happens, and the process
for establishing LSP is terminated.
l Path Vector
The path vector method is to record the path information in the message bound with the
forwarding label. For every hop, the corresponding router checks if its ID is contained in
this record. If not, the router adds its ID into the record; and if so, it indicates that a loop
happens and the process for establishing LSP is terminated.
5.6.4 BGP /MPLS IP VPN Introduction

BGP/MPLS IP VPN is a kind of PE-based L3VPN technology in the Provider Provisioned VPN
(PPVPN). It uses BGP to advertise VPN routes and uses MPLS to forward VPN packets on the

provider backbone network. BGP/MPLS IP VPN has flexible networking modes, good
extensibility and convenient support for MPLS QoS and MPLS TE. Hence, it is widely used.
Overview of BGP/MPLS IP VPN

The BGP/MPLS IP VPN model contains three parts:
l Customer Edge (CE): is an edge device in the customer network. It has one or more
interfaces directly connected with the service provider network. It can be a router, a switch
or a host. In most cases, the CE cannot "sense" the existence of VPN, and does not need to
support MPLS.
l Provider Edge (PE): is an edge device of the provider network. It is directly connected to
the CE. In MPLS network, the PE router disposes all the VPN processing.
l Provider (P): is a backbone router in the provider network. It is not directly connected to
the CE. The P router should possess MPLS basic forwarding capability.
Figure 5-23 shows the networking diagram of BGP/MPLS IP VPN.
Figure 5-23 BGP/MPLS IP VPN model
VPN1 CE Service provider's CE VPN2

Site backbone Site
P P
PE
PE
PE
VPN1
VPN2 P P
CE Site
Site CE
Site
The term site is often mentioned in the VPN. Its meaning is described as follows:
l A site is a group of IP systems with IP connectivity. It does not require a service provider
network to implement connectivity.
l The classification of a site depends on the topology relationship, not on the geographical
positions of devices, even if the devices in a site are adjacent to each other.
l The devices in a site can belong to multiple VPNs. In other words, a site can belong to
multiple VPNs.
l A site is connected to the provider network through CE. A site can contain many CEs, but
a CE only belongs to a site.

Many sites connected to a same provider network can be classified into different sets through
policies. Only the sites in the same set can access each other through the provider network. Such
a set is called VPN.
Address Spaces Overlapping

The range of addresses independently managed by each VPN is called an address space. The
Address space overlapping occurs if different VPNs use the addresses in the same range.
For example, both VPN1 and VPN2 use the addresses on the network segment 10.110.10.0/24.
VPNs can use overlapping address space in the following two situations:
l Two VPNs share no site.
l Two VPNs share a same site, but the devices in this site and the devices that use address
space overlapping in two VPNs cannot access each other.
VPN-instance
VPN-instance is a special entity that PE creates and maintains for directly connected sites. Each
site has its own VPN-instance on PE.
VPN-instance is also called as VPN Routing and Forwarding table (VRF). There are multiple
forwarding tables on a PE, which include a public routing and forwarding table, and one or
multiple VRFs.
l The public routing table consists of routes of all the PE and P routers. It is generated by
IGP of the backbone network.
l A VPN-instance consists of directly connected routes of sites. These sites are obtained
through route advertisement between CE and PE.
In RFC 2547 (BGP/MPLS VPNs), the VPN-instance is called the per-site forwarding table. As
the name implies, one VPN-instance corresponds to one site. Each connection between a CE
and a PE corresponds to a VPN-instance.
As shown in Figure 5-24, all VPN-instances on the PE are independent of each other, and of
the routing and forwarding table of the public network. You can consider each VPN-instance as
a virtual router, which maintains independent address spaces and has the interface connected to
the router.

Figure 5-24 Schematic diagram of a VPN-instance
VPN1
Site1 VPN1
CE VPN-instance
Backbone
PE
Public
forwarding
table
VPN2
VPN-instance
VPN2
Site2 CE
VPN-instance implements independent address spaces through the Route Distinguisher (RD).
It manages VPN membership of directly connected sites and route rules through VPN Target
attributes.
VPN-IPv4 Address Family

After receiving common IPv4 routes from a CE, the PE needs to import these private routes to
the public routing table, and then advertise them to other PEs.
Traditional BGP cannot process the VPN routes which have overlapping address space. If both
VPN1 and VPN2 use addresses on the segment 10.110.10.0/24 and each of them advertises a
route to this network segment, BGP selects only one of them, thus resulting in loss of the other
route.
The cause lies in that BGP cannot distinguish the same IP address prefixes in different VPNs.
To solve this, BGP/MPLS IP VPN uses VPN-IPv4 address that consists of an IPv4 address and
an RD.
A VPN-IPv4 address consists of 12 bytes. The first eight bytes represent the RD, followed by a
4-byte IPv4 address prefix, as shown in Figure 5-25.
Figure 5-25 VPN-IPv4 address structure
Route Distinguisher ( 8-Byte )
Type Field Administrator Assigned IPv4 Address Prefix

( 2-Byte ) Subfield Number Subfield ( 4-Byte )
RD has two formats differentiated by the 2-byte type field.

l When the type is 0, the Administrator subfield occupies two bytes (16 bits) and the Assigned
Number subfield occupies four bytes (32 bits). The RD format is "16-bit ASN: 32-bit user-
defined number". For example, 100:1.
l When the type is 1, the Administrator subfield occupies four bytes (32 bits) and the
Assigned Number subfield occupies two bytes (16 bits).
The RD format is "32-bit IPv4 address: 16-bit user-defined number". For example,
172.1.1.1:1.
You can use RD to distinguish the IPv4 prefixes that use the same address space, but not to judge
the initiator of a router and the VPN of the route. The service providers can allocate the RD
independently, but it should be globally unique.
In this way, even if several VPNs of different providers use the same IPv4 address, the PE routers
can advertise different routes to that IPv4 address, one for each VPN. VPN-IPv4 addresses with
the RD of zero are equal to common IPv4 addresses.
NOTE
To ensure that RD is globally unique, do not configure the Administrator subfield with a private ASN or
IP address.
The IPv4 addresses being added RD are called VPN-IPv4 addresses. After receiving common
IPv4 routes from a CE, the PE converts them into VPN-IPv4 routes. Thus the private routes can
be transmitted through the public network.
VPN-target
The VPN-target or the Route-target is a 32-bit BGP extended community attribute. BGP/MPLS
IP VPN uses the VPN-target to control the advertisement of VPN routing information.
There are two kinds of VPN-targets:
l Export Target
A local PE sets the Export Target attribute for the VPN-IPv4 routes learnt from its directly
connected sites, before advertising them to other PEs. The attribute is advertised with the
routes as the BGP extended community attribute.
l Import Target
A PE checks the Export Target attribute of VPN-IPv4 routes advertised by other PEs. If
the Export Target is identical with the Import Target of a VPN instance, the PE adds the
route to the VPN routing table.
In other words, the VPN Target attribute defines which sites can receive a VPN-IPv4 route, and
from which sites that PE can receive routes.
Like RD, there are two types of VPN-target formats:
l Autonomous system number: user-defined number, for example, 100:1.
l IP address: user-defined number, for example, 172.1.1.1:1.
BGP/MPLS IP VPN Route Advertisement

In basic BGP/MPLS IP VPN networking, the advertisement of VPN routing information
involves CE and PE. The P router only maintains the routes of the backbone network. It does
not need to know any VPN routing information. The PE router only maintains the VPN route
directly connected to it, and not all VPN routes. Therefore, BGP/MPLS IP VPN has good
extensibility.

The advertisement of VPN routing information consists of three phases:

l Routing Information Exchange Between the Local CE and the Ingress PE
When establishing an adjacency relationship with the directly connected PE, the CE
advertises VPN routes in local site to the PE.
You can use static route, RIP, OSPF, BGP between a CE and a PE. Whichever routing
protocol is used, the CE always advertises standard IPv4 routes to PE.
In general, static route is used for the route exchange between PE and CE of stub VPN only.
NOTE
A VPN that only receives its own routes and the PE-advertised routes is called stub VPN.
l Routing Information Exchange Between the Ingress PE and the Egress PE
After learning VPN routing information from a CE, the ingress PE adds RDs and VPN
Target for these standard IPv4 routes to form VPN-IPv4 routes, and saves them into the
VPN-instance created for the CE.
Then, the ingress PE advertises the VPN-IPv4 routes to the egress PE through MP-BGP.
The Egress PE compares the Export target of the received routes with the Import targets of
all VPN-instances that it maintains. If the Export target is equal to one of the Import targets,
the PE adds the VPN-IPv4 route to the VPN-instance.
PEs use IGP to ensure the connectivity between them.
l Routing Information Exchange Between Egress PE and Remote CE
The egress PE exports the VPN routes learned from the ingress PE to the remote CEs. A
remote CE can learn VPN routes from the egress PE in several ways, including static
routing, OSPF, and BGP. The exchange of routing information between the egress PE and
the remote CE is the same as that between the local CE and the ingress PE.
If External Border Gateway Protocol (EBGP) runs between PE and the CE, BGP detects the
route loop using the Autonomous System Number (ASN). So, you must allocate different ASNs
to different physical locations to ensure correct transmission of the routing information.
The Eudemon provides the BGP ASN substitute function, allowing physically dispersed CEs to
use the same ASN and implement normal routing information exchange.
With the BGP ASN substitute function, when a PE advertises routes to a CE, if the ASN in the
AS-Path of the route is the same as that of the CE, the PE replaces the ASN in the route with its
own ASN.
NOTE
After BGP ASN substitute is enabled, the PE re-advertises routing information to the CEs connected with
it in the peer group. It then substitutes the attribute of the AS_path of the routes according to the above
rule.

Figure 5-26 BGP ASN substitute application
AS: 800
Backbone CE3
AS: 100
PE1
VPNv4_Update: PE2
10.1.0.0/16
RD: 10.1.1.1/32
AS-path: 800
EBGP_Update: EBGP_Update:
CE1 10.1.1.1/32 10.1.1.1/32 CE2
AS: 800 AS-path: 800 AS-path: 100 AS: 800
In Figure 5-26, both CE 1 and CE 2 use ASN 800. Enable ASN substitute function on PE 2 for
substituting the ASN of CE 2. When advertising updates received from CE 1 to CE 2, PE 2 finds
that the ASN in the AS_path is the same as that of CE 2. It substitutes the ASN as 100, its own
ASN, before advertising the route to CE 2. In this way, CE 2 can normally receive routing
information from CE 1.
When PE connects multiple CEs (such as CE 2 and CE 3) through different interfaces, BGP
ASN substitute function can also be used.
NOTE
For a multi-homed CE, you should use the BGP ASN substitute function together with Site-of-Origin
(SOO) function. Otherwise, route loop may occur.
BGP/MPLS IP VPN Packets Forwarding

In the BGP/MPLS IP VPN backbone network, the P router does not know VPN routing
information. And VPN packets are forwarded between PEs through tunnels. The available tunnel
types between PEs include LDP, GRE and CR-LSP.
The following takes the LDP LSP tunnel as an example to describe the forwarding process of
VPN packets. Here, the ingress PE serves as the Ingress LSR, the egress PE as the Egress LSR
and P as the Transit LSR.
In basic L3VPN applications, VPN packets are forwarded with two layers of labels, except in
inter-provider situations:
l The Layer 1 (exterior layer) label is switched inside the backbone network. It indicates an
LSP from the local PE to the remote PE. Based on the layer 1 labels, VPN packets can
reach the remote PE along the LSP.
l The Layer 2 (interior layer) label is used when the packet is forwarded from the remote PE
to the CE. The interior layer label indicates which CE or which site the packet should be
sent to. The PE can find the interface for forwarding the packet according to the interior
layer label.
If the two sites (CE) belonging to the same VPN are connected to the same PE, it is only necessary
to know how to reach the remote CE.

Consider Figure 5-27 as an example.
Figure 5-27 Diagram of forwarding VPN packets
Layer 1
1.1.1.2 Layer 2 Layer 2 1.1.1.2
1.1.1.2 1.1.1.2
CE1 PE1 PE2 CE2
(1) (4)
(2) P P (3)
Site (5)
Site2
1
1.1.1.1/24 1.1.1.2/24

1. An IP packet with the destination address 1.1.1.2 is sent out from Site 1. CE 1 transmits it
to PE 1.
2. PE 1 searches the VPN-instance entries based on the arriving interface and the destination
address of the packet. On finding a matching entry, PE 1 forwards the packets with the
interior layer and exterior layer labels.
3. MPLS transmits the packet to PE 2 according to the exterior layer label. Note that the
exterior layer label is removed from the packet at the former hop of PE 2.
4. PE 2 searches VPN-instance entries according to the interior layer label and the destination
address to find the egress and then forwards the packet to CE2.
5. CE 2 transmits the packet to the destination by common IP forwarding process.
BGP/MPLS IP VPN Access Control

In BGP/MPLS IP VPN, the VPN Target attribute is used to control the transmission of VPN
routes among sites. Export Target and Import Target can be set independently. And they both
can be assigned one or more values. Thus, the VPN access can be flexible and there are multiple
VPN networking schemes.
The two networking schemes are as follows:
l Basic VPN Networking
The simplest case is that all users in a VPN form a closed user group. They can forward
traffic to each other but they cannot communicate with any user outside the VPN.
For this networking scheme, you should assign a VPN Target for each VPN as the Export
Target and Import Target of the VPN. Moreover, this VPN Target cannot be used by other
VPNs.
In Figure 5-28, the VPN Target value assigned for VPN 1 on the PE is 100:1, and the VPN
Target value assigned for VPN 2 is 200:1. Two VPN 1 sites can communicate with each
other. Two VPN 2 sites can communicate with each other. However, VPN 1 sites cannot
communicate with the VPN 2 sites.

Figure 5-28 Basic VPN networking scheme
VPN1 VPN2
Import: 100:1 Import: 200:1 VPN2
VPN1 Export: 100:1 Export: 200:1
CE
CE Site3
Site1 Backbone
PE P PE VPN1
VPN2
VPN2 VPN1
CE Import: 200:1 Import: 100:1 CE
Site2 Site4
Export: 200:1 Export: 100:1
l Extranet Networking
Extranet networking can be used when users in a VPN want to provide a part of the VPN
site resources to users that are not in the VPN.
For this kind of networking, if a VPN needs to access a shared site, the Export Target and
the Import Target of the VPN must be contained respectively in the Import Target and the
Export Target of VPN-instance in the shared site.
Figure 5-29 Extranet networking scheme
VPN1
Import: 100:1
CE Export: 100:1
Site1
VPN1
VPN1
PE1
CE
PE2
PE3 Site3
VPN1
Import: 100:1, 200:1
VPN2
Export: 100:1, 200:1
VPN2
CE Import: 200:1
Site2 Export: 200:1
In Figure 5-29, VPN 1 and VPN 2 can access site 3 of VPN 1:

– PE 3 can accept the VPN-IPv4 routes advertised by PE 1 and PE 2.
– PE 1 and PE 2 can accept the VPN-IPv4 routes advertised by PE 3.

– Based on the above, site 1 and site 3 of VPN 1 can communicate with each other, and
site 2 of VPN 2 and site 3 of VPN 1 can communicate each other.
– PE 3 advertises neither the VPN-IPv4 routes received from PE 1 to PE 2, nor the VPN-
IPv4 routes received from PE 2 to PE 1. Therefore, site 1 of VPN 1 and site 2 of VPN
2 cannot communicate with each other.
OSPF VPN Extension

The Eudemon implements the OSPF VPN extension features by running OSPF between the PE
and the CE in BGP/MPLS IP VPN.
l OSPF Multi-Instance on PE
OSPF is one of the IGP routing protocols that are widely applied at present. Running OSPF
between the PE and the CE in VPN can simplify the configuration and management of the
CE because, the CE only needs to support OSPF rather than other protocols.
To run OSPF between the CE and the PE, the PE must support OSPF multi-instance. Each
OSPF instance should correspond to a VPN-instance and have its own interface and routing
table.
l Configuration of OSPF areas between PE and CE
The OSPF area between the PE and the CE can be a non-backbone area or a backbone area.
In the OSPF VPN extension, the MPLS VPN backbone network is considered as the
backbone area (area 0). All the interfaces that are configured as area 0 on the VPN sites
should be connected with the MPLS VPN backbone network.
That is, if a VPN site contains an OSPF area 0, the PE connected with the site must be
connected with the area 0 in this VPN site through an area 0 (The virtual link can be used
for logical connection).
l BGP/OSPF interaction
After OSPF runs between the PE and the CE, the PE advertises the VPN routes to the CE
through OSPF.
As shown in Figure 5-30, CE 1, CE 3, and CE 4 belong to VPN 1. Suppose that all the
routers in the figure belong to the same AS, that is, CE 1, CE 3, and CE 4 belong to the
same OSPF domain.
Figure 5-30 Application of OSPF in VPN

VPN1
VPN1 Area1
Site1 Site3
Area0
CE1 CE3
Area0
Area0 OSPF 100
OSPF 100 MPLS VPN
Backbone VPN1
VPN1
Area1 PE1 PE2 Area1
OSPF 200 OSPF 200
VPN2 VPN1
CE2 CE4 Area2
Area1
Site2 Site4
VPN2 VPN1

The advertisement procedure of VPN 1 routes is as follows:

1. PE 1 imports OSPF routes from CE 1 into BGP.
2. PE 1 advertises the VPN routes to PE 2 through MP-BGP.
3. PE 2 imports the BGP VPN routes into OSPF, and advertise them to CE 3 and CE 4.
The standard BGP/OSPF interaction enables PE 2 to advertise the BGP VPN routes to CE
3 and CE 4 through Type 5 LSAs (ASE LSAs). However, CE 1, CE 2, and CE 3 belong to
the same OSPF domain, and the route advertisement between them should be Type 3 LSAs
(inter-area routes).
To avoid the above cases, PE applies an extended BGP/OSPF interaction process called
BGP/OSPF interoperability. It can advertise routes from one site to another, and
differentiate the routes from real AS-External routes. The process requires an extension
community attribute of BGP that carries the information for identifying the OSPF attributes.
The Eudemon requires that each OSPF domain has a Domain ID. It is recommended to
configure the domain ID for all OSPF instances in the network related to each VPN-
instance, or adopt the default ID. The domain ID is taken as the extension community
attribute of BGP. In this way, the system can know that all the VPN routes with the same
domain ID come from the same VPN-instance.
l Routing loop detection
If OSPF runs between the CE and the PE, when a PE advertises the BGP VPN routes learnt
from the backbone network to CE through LSAs, the LSA may be advertised to another
PE through the OSPF domain of CE, thus forming a routing loop.
PE may advertise routes to the CE through Type 3 LSA (Summary LSA) or Type 5 LSA
(AS-external LSA).
Type 5 LSA and Type 7 LSA use a special kind of OSPF route tag called VPN route tag
to prevent routing loop. When a PE advertises Type 5 or Type 7 LSA to the CE, the PE
serves as an ASBR, and the LSA contains the VPN route tag of the OSPF instance. The PE
ignores the Type 5 or Type 7 LSA during SPF calculation if the VPN tag value in the LSA
is the same as that configured on the PE.
For Type 3 LSAs, OSPF uses a reserved bit, DN, in the LSA Options field as the flag bit.
When advertising Type 3, Type 5 or Type 7 LSAs to the CE, the PE sets the flag bit DN
to 1. The DN value of other types of LSAs is set to 0. PEs ignore the LSAs whose DN bit
is set to 1 during the SPF calculation. Figure 5-31 shows the DN bit in the LSA Options
field.
Figure 5-31 DN bit in the LSA Options field

DN * DC EA N/P MC E *
l Sham link
In general, BGP peers carry routing information on the MPLS VPN backbone network
through the BGP extension community attribute. The OSPF that runs on the remote PE can
use the information to create Type 3 LSAs that are transmitted to the CEs. These routes are
the inter-area routes.
As shown in Figure 5-32, site 1 and site 2 both belong to VPN 1 and the same OSPF area.
They are connected to different PEs, PE 1 and PE 2. There is an intra-area OSPF link called
backdoor link between them. In this case, the route connecting the two sites through PEs

is the inter-area route. It is not preferred by OSPF because its preference is lower than that
of the intra-area route across the backdoor link.
Figure 5-32 Sham link application
MPLS VPN
backbone
PE2
PE1 sham link
Area1 Area1
OSPF 200 OSPF 200
CE12 CE22
VPN1 VPN1
Site1 Site3
backdoor
The above case will cause VPN traffic to be forwarded always through the backdoor link
instead of the backbone network. To solve the problem, you can establish a sham link
between the two PEs so that the routes between them over the MPLS VPN backbone
become an intra-area route.
The sham link acts as an inter-area point-to-point link and is advertised through the Type
1 LSA. You can select a route between the sham link and backdoor link by adjusting the
metric.
The sham link is considered as the link between the two VPN instances with one endpoint
address in each VPN-instance. The endpoint address is a Loopback interface address with
a 32-bit mask in the VPN address space on the PE. Different sham links of the same OSPF
process can share an endpoint address, but that of different OSPF processes cannot.
The BGP advertises the endpoint addresses of sham links as VPN-IPv4 addresses. A route
across the sham link cannot be imported into BGP as a VPN-IPv4 route.
The sham link can be configured in any area. You need to configure it manually in
Eudemon. In addition, the local VPN-instance must contain a route to the destination of
sham link.
l Multi-VPN-Instance CE
Generally, the OSPF multi-instance runs on PEs. The routers running the OSPF multi-
instance inside a LAN are called Multi-VPN-instance CEs. Compared with the OSPF multi-
instance on PE, the Multi-VPN-instance CEs need not support the BGP/OSPF
interoperability.
Multi-VPN-instance CEs are used to solve the security problem of LANs with the low cost.
It is hard to implement the complete separation of different services in LANs with
traditional routers. Eudemon can run multiple OSPF processes on a router. The OSPF
process can belong to the public network or a VPN-instance. Therefore, you can run
multiple OSPF processes on a router and bind them to different VPN-instances.
In practice, you can create OSPF instances for different services to separate services and
ensure their security.

Feature Description 6 Intrusion Detection
6 Intrusion Detection
About This Chapter
The Eudemon can identify applications that use nonstandard ports through the intrusion detection
function. Moreover, the Eudemon deeply detects the application data, and thus the network
protection capability is improved.
6.1 Identification of Protocols Using Nonstandard Ports
The protocol identification function of the Eudemon solves the problem of false positive and
false negative in protocol identification of service packets using nonstandard ports.
6.2 Protocol Detection
The protocol detection function of the Eudemon analyzes and detects application layer payload
packets. Thus, potential attacks from the payload packets can be prevented.
6.3 IPS Detection
This topic describes process and working principle of the IPS detection, and process and upgrade
method of the IPS rule.

6 Intrusion Detection Feature Description
6.1 Identification of Protocols Using Nonstandard Ports

false negative in protocol identification of service packets using nonstandard ports.
6.1.1 Overview
This topic describes the reasons and advantages of protocol identification using nonstandard
ports.
6.1.2 Supported Protocol Types
This topic describes what type of packets that use the nonstandard ports can be identified by the
Eudemon.
6.1.3 Working Principles
This topic describes the working principles of identifying the protocols of application packets
that use nonstandard ports.
6.1.1 Overview
This topic describes the reasons and advantages of protocol identification using nonstandard
ports.
With the emergence of new network protocols and software, traditional methods for identifying
protocols based on ports are seeing greater and greater limitations. The Eudemon supports
protocol identification based on both standard and nonstandard ports. Thus, the following
common network problems can be solved:
l Certain new network protocols do not use fixed ports. Instead, the protocols negotiate ports
when they work. Protocol identification based on ports cannot identify protocols of this
type.
l Certain network administrators use nonstandard ports for common network application
services to reduce the risks of external attacks.
l A large number of services run on nonstandard ports. During attack detection, the protocol
types of the packets of these services cannot be identified. Therefore, attacks in these
services can evade the detection.
false negative in protocol identification of application packets using nonstandard ports.
6.1.2 Supported Protocol Types

This topic describes what type of packets that use the nonstandard ports can be identified by the
Eudemon.
The Eudemon can identify the following types of protocols:
l Hypertext Transfer Protocol (HTTP)

l Internet Message Access Protocol (IMAP)
l Post Office Protocol revision 3 (POP3)


This topic describes the working principles of identifying the protocols of application packets
that use nonstandard ports.
The Eudemon adopts the following process to perform protocol identification:
1. When a session is established, the Eudemon intercepts the packets.
2. The Eudemon automatically identifies the protocol type according to the features of the
intercepted packets. Thus, the Eudemon can identifies protocol type in real time.
3. The Eudemon verifies the accuracy of protocol identification according to the protocol
authentication rules. Thus, the accuracy of protocol identification is ensured.
4. The identification result is saved in the solidification table, which is used for subsequent
protocol identification.
NOTE
The followings are included in the result in the solidification table:

l Server IP address discovered during protocol identification, for example, the IP address of the Web
server
l The nonstandard server port, on which services are enabled, discovered during protocol identification
l Protocol type that uses nonstandard ports for sessions during protocol identification, including HTTP,
FTP, IMAP, SMTP, and POP3
6.2 Protocol Detection

The protocol detection function of the Eudemon analyzes and detects application layer payload
packets. Thus, potential attacks from the payload packets can be prevented.
6.2.1 Overview
This topic describes the common types of detected protocols and response policies of abnormal
packets detected.
6.2.2 DNS Protocol Detection
Through the DNS protocol detection, the Eudemon can prevent attacks through DNS packets
from the application layer.
6.2.3 HTTP Detection
This topic describes the contents, principle, and reference to the HTTP detection. The
Eudemon can protect the WWW server and client through the HTTP detection.
6.2.4 FTP Detection
Through the FTP detection, the Eudemon can protect the FTP server.
6.2.5 SMTP Detection
This topic describes the contents and working principle of the SMTP detection. Through the
SMTP detection, the Eudemon can protect the mail server or client.
6.2.6 IMAP/POP3 Detection
When the IMAP or POP3 clients receive emails from the internal mail server, the Eudemon
detects IMAP or POP3 packets.

6.2.1 Overview
This topic describes the common types of detected protocols and response policies of abnormal
packets detected.
Types of Detected Protocols

The Eudemon supports the protocol detection of Hypertext Transfer Protocol (HTTP), File
Transfer Protocol (FTP), Post Office Protocol 3 (POP3), Internet Message Access Protocol
(IMAP), Simple Mail Transfer Protocol (SMTP), and Domain Name Service (DNS) sessions.
During the detection, the Eudemon mainly supports the following types of attack detection:
l Overflow attack detection
The application server generally responds by resolving different fields in the header of a
request packet. If the request packet is too large, the overflow attack may occur on the
application server. The Eudemon detects this type of attacks through the overflow attack
detection, and prevents this type of attacks by restricting the length threshold of the
specified field.
l Dangerous behavior detection and control
This function is mainly used to detect dangerous operations on the application server, such
as deleting important files on the server. Behavior detection of the Eudemon usually
consists of the following types:
– Restricting dangerous commands, such as the Delete and Put commands.
– Restricting user login times in a session.
– Restricting the protocol version of the request packet.
– Restricting the length of the Chunk block of the HTTP packet.
– Restricting abnormal reply packets.
l RFC Standard Compliance Detection
Besides the previous types of protocol detection, the Eudemon also supports RFC standard
compliance detection, that is, to detect whether packets are consistent with the RFC
standard. Inconsistent packets are processed by the Eudemon according to response
policies.
Response Policies
After the protocol detection, the Eudemon processes abnormal packets detected according to
response policies as shown in Table 6-1.
Table 6-1 Response Policies

Response
Detection Result Policy Packet Processing Method
Abnormal alert The packet is forwarded as usual, but the alarm

information is sent to the information center.
reset The current session is disconnected, and the

alarm information is sent to the information
center.

6.2.2 DNS Protocol Detection

Through the DNS protocol detection, the Eudemon can prevent attacks through DNS packets
from the application layer.
DNS Overflow Detection

The DNS protocol detection of the Eudemon is realized through restricting the maximum length
of the UDP-based DNS packets.
Reference
For details about the working principle of the DNS detection, refer to the following standards:
l RFC1034: DOMAIN NAMES - CONCEPTS AND FACILITIES

l RFC1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
l RFC1101: DNS Encoding of Network Names and Other Types
NOTE
When you read this guide, the draft number in the preceding standards may be added.
6.2.3 HTTP Detection

This topic describes the contents, principle, and reference to the HTTP detection. The
Eudemon can protect the WWW server and client through the HTTP detection.
HTTP Overflow Detection

When the Eudemon performs the HTTP overflow detection, the following are detected to prevent
overflow attacks on the WWW server through HTTP packets:
l Length of the Authorization field

l Length of the Content-type field
l Length of the Cookie field
l Length of the Header-line field
l Length of the Host field
l Length of the Referer field
l Length of the request line
l Length of the User-agent field
HTTP Dangerous Behavior Detection and Control

l Restrict the commands that HTTP services use. You can decide whether to forbid the GET,
POST, HEAD, DELETE, OPTIONS, PUT, TRACE, CONNECT commands and
commands that are not defined by RFC.
l Restrict the versions that HTTP services use. You can decide whether to forbid the 0.9, 1.0,
1.1 versions, or other unknown versions.

l Restrict the size of the Chunk block if HTTP packets are transferred in Chunk mode. Some
attack packets are packed as a big Chunk block to attack the WWW server, which may
cause the Web server cache to overflow.
l Restrict the receiving of abnormal HTTP response packets. Some attack packets pretend
to be HTTP response packets to attack the HTTP client.
CGI Attack Detection

In addition to the overflow detection and abnormality detection, the Eudemon also provides the
Common Gateway Interface (CGI) detection.
Different Web servers decode the Uniform Resource Identifier (URI) in different ways, and
illegal users may escape the detection by using this feature. The Eudemon adopts the URI
standardization to prevent the preceding situation. The CGI attack detection of the Eudemon is
realized according to the following procedure:
1. The Eudemon decodes the URI in different ways according to the encoding types, such as
Apache and IIS, of the Web server configured by users.
2. The Eudemon performs the feature detection on the decoded data to prevent CGI attacks.
Working Principles
Figure 6-1 shows the working process of the HTTP detection of the Eudemon.
Figure 6-1 Working principle of the HTTP detection
WWW server HTTP client

Eudemon
Internal External
network network
3 2/5 HTTP detection 1
4 Overflow/behavior/CGI 6
attack detection
The following describes the working principle of the HTTP detection through the example that
the HTTP client accesses a WWW server:
1. The HTTP client sends a request packet to the WWW server.
2. The Eudemon intercepts the request packet and performs the HTTP detection.
3. The Eudemon processes the request packet according to the detection result.
l If the detection result of the packet is normal, the Eudemon forwards the request packet
to the WWW server.
l If the detection result of the packet is abnormal, the Eudemon processes the request
packet according to the response policies configured by users.
4. The HTTP server sends a response packet after receiving the HTTP request packet.
5. The Eudemon intercepts the response packet and performs the HTTP detection.

6. The Eudemon processes the response packet according to the detection result.
l If the detection result of the packet is normal, the Eudemon forwards the response packet
to the HTTP client.
l If the detection result of the packet is abnormal, the Eudemon processes the response
packet according to the response policies configured by users.
Reference
For details about the working principle of the HTTP detection, refer to the following standards:
l RFC1945: Hypertext Transfer Protocol HTTP/1.0
l RFC2616: Hypertext Transfer Protocol HTTP/1.1
l RFC3986: Uniform Resource Identifier (URI) Generic Syntax
NOTE
6.2.4 FTP Detection

Through the FTP detection, the Eudemon can protect the FTP server.
FTP Overflow Detection

When the Eudemon performs the FTP overflow detection, the following are detected to prevent
overflow attacks on the FTP server through FTP packets:
l Length of the FTP command line
l Length of the FTP user name
l Length of the FTP password
l Length of the SITE field
FTP Dangerous Behavior Detection and Control

l Restrict the commands that FTP services use. You can decide whether to forbid the
APPE, RETR, CDUP, RMD, DELE, RNFR, STOR, RNTO, HELP, SITE, MKD, and
STOU commands.
l Restrict the maximum number of consecutive login failures allowed in an FTP session.
l Detect and control attacks to an FTP server through another FTP server by the FTP
springboard attack detection.
Hiding FTP Server Information

The Eudemon supports the hiding of FTP server information during the sending of an FTP
packet.
The Eudemon can protect the FTP server through hiding FTP server information in the following
messages:
l Hiding welcome messages
After an FTP session is established, the FTP server sends a welcome message that contains
the name and version information of the FTP server.

l Hiding responses to the SYST command

After an FTP session is established, the FTP server sends a response message to the
SYST command. The response message to the SYST command contains the name and
version information of the FTP sever.
Working Principles
Figure 6-2 shows the working process of the FTP detection of the Eudemon.
Figure 6-2 Working principle of the FTP detection
FTP server FTP client

Eudemon
Internal External
network network
3 1
2/5 FTP detection
4 Overflow/behavior 6
Figure 6-2 describes the working process of the FTP detection of the Eudemon through the
example that the FTP client accesses an FTP server:
1. The FTP client establishes a connection to the FTP server.

2. The Eudemon intercepts the packets during the connection.
3. The Eudemon processes the packets according to the detection result.
l If no abnormal packet is detected, the Eudemon enables the port of the FTP client, which
is used to negotiate with the FTP server.
l If abnormal packet is detected, the Eudemon processes the request packet according to
the response policies configured by users.
4. The FTP server sends the data requested to the FTP user after receiving the request packet.
5. The Eudemon intercepts the data.
6. The Eudemon processes the data according to the detection result.
l If no abnormal packet is detected, the Eudemon forwards the data to the FTP client.
l If abnormal packet is detected, the Eudemon processes the request packet according to
the response policies configured by users.
Reference
For details about the working principle of the FTP detection, refer to the following standards:
RFC0959: File Transfer Protocol
NOTE

6.2.5 SMTP Detection

This topic describes the contents and working principle of the SMTP detection. Through the
SMTP detection, the Eudemon can protect the mail server or client.
SMTP Overflow Detection

When the Eudemon performs the SMTP overflow detection, the following are detected:
l Length of the command line

l Length of the reply line
l Length of the email address of the sender
l Length of the email address of the receiver
SMTP Dangerous Behavior Detection and Control

l Restrict the commands that SMTP services use. You can decide whether to forbid the
VRFY, EXPN, and TURN commands.
l Restrict the maximum number of error reply codes allowed in an SMTP session.
l Restrict the maximum number of resetting SMTP mail transmission allowed of an SMTP
session.
Working Principle
Figure 6-3 shows the working process of the SMTP detection of the Eudemon.
Figure 6-3 Working principle of the SMTP detection
External mail server
Internet
Internal mail
SMTP client 6 server
Eudemon
Trust DMZ
2/5
4
1 SMTP
detection
3
Figure 6-3 describes the process of the SMTP detection when the SMTP client sends an email.
1. The SMTP client sends an email to the internal SMTP server.

2. The Eudemon intercepts the packets during the sending and performs the SMTP detection.
3. The Eudemon processes the email according to the detection result.

l If no abnormal packet is detected, the Eudemon sends the email to the internal mail
server.
l If abnormal packet is detected, the Eudemon processes the email according to the
response policies configured by users.
4. The internal mail server sends an email received to the external mail server.
5. The Eudemon intercepts the packets during the sending and performs the SMTP detection.
l If no abnormal packet is detected, the Eudemon sends the email to the external mail
server.
Reference
For details about the working principle of the HTTP detection, refer to the following standards:
l RFC2821: Simple Mail Transfer Protocol

l RFC2822: Internet Message Format
l RFC2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies
l RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
l RFC2047: MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header
Extensions for Non-ASCII Text
NOTE
6.2.6 IMAP/POP3 Detection

When the IMAP or POP3 clients receive emails from the internal mail server, the Eudemon
detects IMAP or POP3 packets.
IMAP/POP3 Overflow Detection

When the Eudemon performs the IMAP/POP3 overflow detection, the following contents are
detected to prevent overflow attacks on the IMAP/POP3 client through IMAP/POP3 packets:
l Length of the IMAP/POP3 command line

l Length of the IMAP/POP3 user name
l Length of the IMAP/POP3 password
l Length of the TAG field in an IMAP packet
l Length of the email address in an IMAP packet
l Length of the APOP field in POP3
The POP3 APOP commands are used to encrypt user names and passwords of POP3 users.
User information can be protected through the POP3 APOP commands; however, the
command line may be extra long and thus the mail server cache may overflow.

IMAP/POP3 Dangerous Behavior Detection and Control

You can realize the IMAP/POP3 dangerous behavior detection and control by restricting the
maximum number of consecutive login failures of IMAP/POP3 users in an IMAP/POP3 session.
Working Principle
Figure 6-4 shows the working process of the IMAP/POP3 detection of the Eudemon.
Figure 6-4 Working principle of the IMAP/POP3 detection
External mail
Internet server
IMAP/POP3 Internal mail
1
client server
Eudemon
Trust DMZ
2/5
IMAP/POP3 3
6
detection
4
Figure 6-4 shows the working process of the IMAP/POP3 detection through the example that
the IMAP/POP3 client on the internal network receives emails from the external mail server:
1. The external mail server sends an email to the internal mail server.
2. The Eudemon intercepts the packets during the sending and performs the IMAP/POP3
detection on them.
l If no abnormal packet is detected, the Eudemon sends the email to the internal mail
server.
4. The internal mail server sends an email to the IMAP/POP3 client.
5. The Eudemon intercepts the packets during the sending and performs the IMAP/POP3
detection on them.
l If no abnormal packet is detected, the Eudemon forwards the email to the IMAP/POP3
client.
Reference
For details about the working principle of the IMAP/POP3 detection, refer to the following
standards:

l RFC2060: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1

l RFC1939: Post Office Protocol - Version 3
NOTE
6.3 IPS Detection

This topic describes process and working principle of the IPS detection, and process and upgrade
method of the IPS rule.
6.3.1 Overview
This topic describes the function and general concepts of the IPS detection.
When detecting application layer data, the Eudemon first adopts the traditional detection method
of the firewall and then performs the IPS detection.
6.3.3 IPS Rule
This topic describes the concept of IPS rule and methods of version upgrade and rollback.
6.3.4 Upgrade of the IPS Rule
This topic describes the upgrade process of the IPS rule of the Eudemon.
6.3.1 Overview
This topic describes the function and general concepts of the IPS detection.
Introduction
Through the IPS detection, the Eudemon detects application layer data and prevents various
types of vulnerability exploits, such as worm viruses, Trojan, DoS attacks, and code attacks.
Through the IPS function, the Eudemon can detect both the quintuple (source addresses, source
port numbers, destination addresses, source port numbers, and protocol types) and the payload
of the application layer data.
General Concepts
The following concepts are involved in the IPS detection of the Eudemon:
l IPS rules
The Eudemon detects application layer data with the IPS rule file. The IPS rules can be
categorized into the following two types:
– System predefined IPS rules that are provided by Huawei and can be updated through
the online upgrade.
– User defined IPS rules that are defined according to the network requirement and ensure
the network security in the earliest time.
l Event response policies
– The Eudemon records the IPS detection result, and thus the network operation can be
audited, which provides reference for the network administrator and other network
security decision-makers.

– In addition, the Eudemon can stop abnormalities on the network in time according to
the response policies configured by users. In this way, the internal network is less likely
to be attacked and the information security is ensured.
When detecting with the IPS rule file, the Eudemon processes abnormal packets according
to the packet processing polices shown in Table 6-2.
Table 6-2 Packet processing policies

Response Policy Packet Processing Method
alert The packet is forwarded as usual, but the alarm information is

sent to the information center.
block Different packets are processed in different ways:

l For Transfer Control Protocol (TCP) and User Datagram
Protocol (UDP) packets, the current and subsequent packets
of the session are discarded, and the alarm information is
sent to the information center.
l For IP and ICMP packets, the current packet is discarded,
and the alarm information is sent to the information center.
drop Different packets are processed in different ways:

l For TCP packets, the current packet and packets following
the session are discarded, and the alarm information is sent
to the information center.
l For UDP, IP, and ICMP packets, the current packet is
discarded, and the alarm information is sent to the
information center.
reset Different packets are processed in different ways:

l For TCP packets, the current packet is discarded, the session
is disconnected, and the alarm information is sent to the
information center.
l For UDP packets, the processing method is the same as that
in block.
l For IP and ICMP packets, the current packet is discarded,
and the alarm information is sent to the information center.

When detecting application layer data, the Eudemon first adopts the traditional detection method
of the firewall and then performs the IPS detection.
Principle of Application Layer Data Detection

Figure 6-5 shows the working process of the application layer data detection of the Eudemon.

Figure 6-5 Working process of the application layer data detection

Application
layer data
No Whether the ASPF

function is enabled?
Yes
Whether the data is No

Discard
allowed to pass?
Yes
Whether the IPS No

Pass
detection is needed?
Yes
Whether attacks are No

detected? Pass
Yes
Process according to event

response policies
IPS Detection
The IPS detection realizes the attack detection through the comparison between packets and IPS
rules. Each IPS rule contains an attack feature. When a packet matches an IPS rule, the
Eudemon regards the packet as an attack packet and processes the packet according to the
response policy of the IPS rule.
NOTE
If a packet matches several IPS rules, the Eudemon processes the packet according the response policy of
the IPS rule that is of the highest security level.
According to the severity level of threats on the network security, the Eudemon classified the IPS rules
predefined by the system into three levels. They are high, medium, and low in the order.
6.3.3 IPS Rule

This topic describes the concept of IPS rule and methods of version upgrade and rollback.
Introduction
The IPS rule is used to save attack features of network attacks that have been detected. The
Eudemon performs the intrusion defense through the IPS and thus the internal network is

protected. The IPS rule is developed and maintained by Huawei. In addition, the IPS rule is
periodically updated by Huawei. The latest version provides the latest feature information.
Version Upgrade
After buying the IPS rule upgrade service, users can update the IPS rule of the device periodically
in the following three ways:
l Automatic upgrade
Connect to the configured upgrade server periodically to upgrade the IPS rule.
The automatic upgrade cycle is one day. If new attacks occur on the network after an
automatic upgrade, the automatic upgrade function cannot update the IPS rule immediately
and you have to wait for the next automatic upgrade. In this way, the IPS rule cannot be
upgraded in real time.
l Manual upgrade
Connect to the configured upgrade server immediately to upgrade the IPS rule.
In this way, the IPS rule can be upgraded in real time.
l Local upgrade
Download the IPS rule from the upgrade server and manually upload the IPS rule file to
the device. Thus, the IPS rule is upgraded.
Version Rollback
If faults occur on the current IPS rule, you can roll back to the previous version through the
version rollback function.
6.3.4 Upgrade of the IPS Rule

This topic describes the upgrade process of the IPS rule of the Eudemon.
Automatic/Manual Upgrade Process

Figure 6-6 shows the upgrade process of the IPS rule of the Eudemon.
Figure 6-6 Automatic/manual upgrade diagram of the IPS rule

IPS rule file upgrade request
Eudemon Upgrade server
Internal
network
Identify the upgrade permission
Download the IPS rule file
Figure 6-6 shows the automatic/manual upgrade procedure of the IPS rule:

1. Specify the address of the upgrade server of the IPS rule on the Eudemon.
2. The Eudemon sends an HTTP request for the IPS rule to the upgrade server.
3. The upgrade server authenticates whether the device has bought the IPS rule upgrade
service.
4. The authenticated Eudemon downloads the latest IPS rule through FTP.
5. The Eudemon saves the latest IPS rule in the flash.
NOTE
The earlier IPS rule is stored on the Eudemon for version rollback.
Local Upgrade Process

The local upgrade of the IPS rule of the Eudemon is realized through the following procedure:
1. The configuration terminal of the Eudemon accesses the sec.huawei.com Website and
downloads the IPS rule.
2. The configuration terminal uploads the downloaded IPS rule to the Eudemon and thus the
IPS rule of the Eudemon is upgraded.

Feature Description 7 Surfing Behavior Management
7 Surfing Behavior Management
About This Chapter
The surfing behavior management can control and audit the IM. In addition, the surfing behavior
management can identify and control P2P traffic, game applications, and stock applications.
7.1 Overview
This topic describes basic functions of the surfing behavior management.
7.2 Type
The surfing behavior management functions of the Eudemon can be classified into four types
according to contents.
7.3 Working Principles
This topic describes the working principle of the IM management and management of P2P,
stock, and game data.

7 Surfing Behavior Management Feature Description
7.1 Overview
This topic describes basic functions of the surfing behavior management.
Currently, in addition to convenience on work, networks provide us with many entertainment

functions, such as games, stock, video, and instant messaging. However, the application of these
entertainment functions during work time reduces overall work efficiency. In addition, this also
consumes a lot of the enterprise network bandwidth, which may affect the operation of some
important services.
To diminish impacts of the entertainment functions, the Eudemon provides the surfing behavior
management function to control enterprise internal users' applications of QQ, MSN, P2P traffic,
stock applications, and game applications.
7.2 Type
The surfing behavior management functions of the Eudemon can be classified into four types
according to contents.
7.2.1 IM Management
This topic describes the application of the Instant Messaging (IM) management of the
Eudemon to QQ and MSN.
7.2.2 P2P Traffic Identification and Control
The Eudemon can identify P2P traffic and specify P2P control policies to restrict P2P traffic.
7.2.3 Game Identification and Control
The Eudemon can identify game and specify game control policies to restrict game.
7.2.4 Stock Identification and Control
The Eudemon can identify stock data and specify stock control policies to restrict stock.
7.2.1 IM Management
This topic describes the application of the Instant Messaging (IM) management of the
Eudemon to QQ and MSN.
The IM management of the Eudemon is realized through the IM login control and IM login audit.
IM Login Control
The Eudemon controls the login of QQ/MSN users through IM control policies based on the
address set and time range.
Based on IM control policies, the Eudemon controls whether users in the specified network
segment can use the IM in the specified time period. For example, there are managers and
engineers on an enterprise network. You can configure two IM control policies to manage
different employee networks. One IM control policy allows managers to use the IM at any time.
The other IM control policy allows engineers to use the IM only during the non-work time.
In addition, the Eudemon supports the control on QQ/MSN users who have logged in.

IM Login Audit
The Eudemon records the following information when a QQ/MSN user logs in and uploads the
information to the log server:
l Login time of an IM user

l Login account of an IM user
l Source/destination address and source/destination port number when an IM user logs in
l Login result of an IM user
The preceding information provides reference for making IM control policies.
Applications Supported by the IM Management

Table 7-1 shows the applications supported by the IM login control and audit.
Table 7-1 Applications supported by the IM login control and audit
Program Version
MSN Messenger Windows Live Message 2008 ( build 8.5 1302 1018 )
Windows Messenger ( 4.7.3001 )
Windows Live Message 8.1 ( build 8.1 0178 00 )
Windows Live Message BETA 2009 (14.0 5027 908)
QQ QQ2007 7.0 BETA3 (9.0.313.203)
QQ2007 7.0 BETA4 (7.0.370.204)
QQ2007 Official Version (7.0.439.400)
QQ2008 Official Version
7.2.2 P2P Traffic Identification and Control

The Eudemon can identify P2P traffic and specify P2P control policies to restrict P2P traffic.
The Eudemon adopts the deep detection and behavior detection technologies to accurately
identify P2P packets and restrict P2P traffic.
Through Huawei-proprietary dynamic loadable pattern files, the Eudemon can also identify
newly-emerged P2P applications, game, and stock.
The Eudemon identifies and restricts P2P applications in the following ways:
l Identify popular P2P applications and constantly update its P2P library.
l Restrict P2P traffic and enable users to set upper thresholds for P2P traffic.
l Control the using of P2P applications according to control policies defined by users.
Control policies control P2P applications in the following fields:

– Control P2P based on source addresses.

– Control P2P based on source ports.
– Control P2P based on destination addresses.
– Control P2P based on destination ports.
7.2.3 Game Identification and Control

The Eudemon can identify game and specify game control policies to restrict game.
The Eudemon identifies game in the following ways:
l Identify various types of game and constantly update its library, such as Ourgame, QQ
Game, Zhengtu Online Game, and Legend.
l Control the using of game according to control policies defined by users.
Control policies control game in the following fields:
– Control game based on source addresses.
– Control game based on source ports.
– Control game based on destination addresses.
– Control game based on destination ports.
7.2.4 Stock Identification and Control

The Eudemon can identify stock data and specify stock control policies to restrict stock.
The Eudemon identifies stock in the following ways:
l Identify various types of stock and constantly update its library, such as Xinshidai and
Citics.
l Control the using of stock according to control policies defined by users.
Control policies control stock in the following fields:
– Control stock based on source addresses.
– Control stock based on source ports.
– Control stock based on destination addresses.
– Control stock based on destination ports.

This topic describes the working principle of the IM management and management of P2P,
stock, and game data.
7.3.1 Working Principle of the IM Management
This topic describes the working principle of the IM management.
7.3.2 Working Principle of the Management of P2P/Game/Stock
This topic describes the working principle of the management of P2P/game/stock.
7.3.1 Working Principle of the IM Management

This topic describes the working principle of the IM management.

Figure 7-1 shows the working principle of the IM management of the Eudemon.
Figure 7-1 Working principle diagram of the IM management

Internal user Eudemon QQ Server
Trust Untrust
Login request
IM login audit
Address set/time range/action
Discard the login request Forward the login request
The following describes the process of the IM management:

1. An IM user sends a login request to the IM server such as the QQ server shown in Figure
7-1.
2. The Eudemon intercepts the request. If the interzone IM audit function is enabled, the
Eudemon audits the request.
3. Process the IM according to IM management polices:
l If the Eudemon identifies that the corresponding IM management policy of the request
is permit, the request is sent to the IM server.
l If the Eudemon identifies that the corresponding IM management policy of the request
is deny, the request is discarded and the alarm message is sent to the log server.
7.3.2 Working Principle of the Management of P2P/Game/Stock

This topic describes the working principle of the management of P2P/game/stock.
Figure 7-2 shows the working principle of the management of P2P/game/stock of the
Eudemon.

Figure 7-2 Working principle of the management of P2P/game/stock

Internal Server
user Eudemon
Trust Untrust
Access request
P2P/stock/game data
management
Source IP/Source Port/Dest IP
/Dest Port/Protocol
Discard the request packet Forward the request packet
Response packet
P2P/stock/game data
management
Source IP/Source Port/Dest IP
/Dest Port/Protocol
Forward the response packet Discard the response packet
The following describes the process of the management of P2P/game/stock through the example
of the management of P2P application.
1. An internal user sends a request to the external P2P server such as the Web server shown
in Figure 7-2.
2. The Eudemon intercepts the request and detects it according to internal P2P management
policies.
3. The Eudemon processes the request according to P2P management polices.
l If the Eudemon identifies that the corresponding P2P management policy of the request
is permit, the request is sent to the P2P server.
l If the Eudemon identifies that the corresponding P2P management policy of the request
is deny, the request is discarded and the alarm message is sent to the log server.
4. After receiving the request, the external P2P server sends the response packet.
5. The Eudemon intercepts the response packet and detects it according to internal P2P
management policies.
6. The Eudemon processes the response packet according to P2P management polices.
l If the Eudemon identifies that the corresponding P2P management policy of the
response packet is permit, the response packet is sent to the internal user.
l If the Eudemon identifies that the corresponding P2P management policy of the
response packet is deny, the response packet is discarded and the alarm message is sent
to the log server.

Feature Description 8 Mail Filtering
8 Mail Filtering
About This Chapter
The mail filtering function detects mails transferred through SMTP and identifies whether they
should be filtered or not.
8.1 Overview
This topic describes the mail filtering function of the Eudemon.
8.2 Concept
This topic describes some general concepts of the mail filtering function.
This topic describes the working principle of mail filtering of the Eudemon.

8 Mail Filtering Feature Description
8.1 Overview
This topic describes the mail filtering function of the Eudemon.
The mail filtering function detects mails transferred through SMTP and identifies whether they
should be filtered or not. The mail filtering function of the Eudemon is realized mainly through
the Real-time Blackhole list (RBL) server.
8.2 Concept
This topic describes some general concepts of the mail filtering function.
Reply Code
The reply code is the specified field in a DNS packet the RBL server returned when users query
mails through the RBL server.
The reply code indicates whether an mail should be filtered or not. The system processes the
mail matching the reply code according to the reply codes and mail processing policies
configured by users. If no matched reply code is found, the unknown-code processing policy is
adopted.
RBL Server
The RBL server provides the spam query function. After receiving a query request, the RBL
server performs the query and returns the query result in the form of reply codes. The spam query
is realized directly or indirectly through the RBL server:
l If the RBL server can provide the direct query service, the address of the RBL server is
configured as the parameter of the rbl-filter server command.
l If the RBL server cannot provide the direct query service, for example, most servers (outside
China) that provide the RBL service for free, IP addresses of some famous DNS servers
on the network can be configured as the parameter of the rbl-filter server command.
Then, the query service is redirected to the RBL server through the DNS server.
RBL Server Query Sets

You can obtain the RBL server query sets of the RBL service provider on its home page.
The following are some of the RBL servers that are free of charge and their query sets:
l www.anti-spam.org.cn, where query sets such as cbl, cdl, cbl+, and cbl- are available.
l www.spamhaus.org, where query sets such as sbl, xbl, and pbl are available.
Unknown-code Processing Policies

For the following situations, the Eudemon adopts unknown-code processing policies:
l The source IP address of the mail does not exist in the RBL query sets.

Feature Description 8 Mail Filtering
l The RBL server returns the reply code, but the corresponding processing policy is not
configured in the Eudemon.
Table 8-1 shows the unknown-code processing policies of mail filtering of the Eudemon.
Table 8-1 Unknown-code processing policies

Response Policy Mail Processing Method
deny Rejects to forward the mail.
permit Allows to forward the mail.
Timeout Processing Policies

If it is timeout for the RBL server to return the reply code, the Eudemon adopts timeout
processing policies.
Table 8-2 shows the timeout processing policies of mail filtering of the Eudemon.
Table 8-2 Timeout processing policies

Response Policy Mail Processing Method
deny Rejects to forward the mail.
permit Allows to forward the mail.

This topic describes the working principle of mail filtering of the Eudemon.
Figure 8-1 shows the working principle of mail filtering of the Eudemon through the example
of mail filtering in the DMZ-Untrust interzone.
Figure 8-1 Principle diagram of mail filtering
Receiver
Trust Sender
RBL server
Mail server Eudemon
DMZ Untrust
SMTP connection request
Mail server
Email filtering query
Return reply code
Email filtering policy
Forward the email Disconnect SMTP connection

8 Mail Filtering Feature Description
When a sender on the external network sends a mail to the internal mail server on the internal
network through the external mail server, the Eudemon performs the following detection to
prevent spam:
1. The Eudemon detects the SMTP connection request.
2. The Eudemon obtains the IP address of the sender and queries it in the RBL server.
3. The RBL server queries the IP address in the query sets. If the corresponding reply code is
found, the RBL server sends the reply code to the Eudemon.
4. The Eudemon processes the mail according to the query result and mail filtering policy.
l If the returned reply code matches that configured by users in the Eudemon and the
corresponding mail filtering policy is deny, the connection request is rejected.
l If the returned reply code matches that configured by users in the Eudemon and the
corresponding mail filtering policy is permit, the connection request is forwarded.
l If the source IP address of the mail does not exist in the RBL query sets, or the RBL
server returns the reply code but no corresponding processing policy is configured in
the Eudemon, the Eudemon processes the mail according to the unknown-code
processing policies.
l If it is timeout for the RBL server to return the reply code, the Eudemon processes the
mail according to the timeout processing policies.

Feature Description 9 Reliability
9 Reliability
About This Chapter
The Eudemon supports VRRP, VGMP, and HRP. It can implement routing information backup,
backup group management, and dual-system hot backup. Therefore, the Eudemon delivers high
reliability.
9.1 VRRP Overview
The Virtual Router Redundancy Protocol (VRRP) is a fault-tolerant protocol defined by the RFC
3768. By separating physical devices from logical devices, VRRP chooses a path from multiple
egress gateways.
9.2 VGMP Overview
To avoid VRRP state inconsistency, Huawei develops the VRRP Group Management Protocol
(VGMP) based on VRRP. VGMP can manage the VRRP state of each backup group. With the
VGMP mechanism, you can manage multiple VRRP backup groups (the virtual firewalls) in
terms of: state consistency, preemption, and channel.
9.3 Introduction to Dual-System Hot Backup
The dual-system hot backup function of the Eudemon accomplishes hot backup of the
configuration commands and the state information. This function supports automatic backup
and manual patch backup.
9.4 Hierarchical Protocol Relation Between VRRP Backup Group, Management Group, and
HRP
Protocol relationships exist between the VRRP backup group and the VGMP group, and the
VGMP group and HRP. HRP packets are carried by VGMP packets for transmission.
9.5 Checking the Configuration Consistency
Consistency check of configurations is used in the dual-system hot backup to check whether the
ACL configurations and HRP configurations of the master and backup devices are consistent
with each other.
9.6 IP-Link Auto-detection Overview
IP-Link auto-detection automatically checks whether a service link works normally by utilizing
the features of the Internet Control Message Protocol (ICMP) or the Address Resolution Protocol
(ARP).

9 Reliability Feature Description
9.1 VRRP Overview

The Virtual Router Redundancy Protocol (VRRP) is a fault-tolerant protocol defined by the RFC
3768. By separating physical devices from logical devices, VRRP chooses a path from multiple
egress gateways.
9.1.1 Introduction to the Traditional VRRP Protocol
The Eudemon supports the Virtual Router Redundancy Protocol (VRRP) and formation of
backup groups based on virtual IP addresses. The hosts on a network continuously communicate
with other networks through a virtual router.
9.1.2 Traditional VRRP on Eudemon Backup
The Eudemon adopts security zone mechanism. Two Eudemons can realize the route redundancy
function with one Eudemon acting as the master and the other as the backup. Interfaces on the
master and backup are connected with different security zones.
9.1.1 Introduction to the Traditional VRRP Protocol

The Eudemon supports the Virtual Router Redundancy Protocol (VRRP) and formation of
backup groups based on virtual IP addresses. The hosts on a network continuously communicate
with other networks through a virtual router.
Usually, each host in an internal network is configured with a default route to the next hop, which
is the IP address of the egress router; for example, 10.100.10.1/24 as shown in Figure 9-1.
Figure 9-1 Networking diagram of adopting default route
PC
10.100.10.1/24
Server Router
10.100.10.0/24
The interactive packets between the internal and the external users all pass through the router.
When the router fails, all hosts (whose default next hop is the router) in the internal network fail
to communicate with the external networks. Therefore, communication is unreliable in the
default route mode.
VRRP can solve the preceding problem.
As a kind of fault tolerant protocol, VRRP applies to LANs that support multicast or broadcast,
for example, the Ethernet.
VRRP groups several routers on a LAN as a virtual router, which is called a backup group. In
a backup group, only one router functions as an active device, which is called master device; all
the other routers act as backup devices (functioning in priority order), ready to take over
transactions at any time.
Figure 9-2 shows a backup group consisting of three routers.

Figure 9-2 Networking diagram of adopting VRRP virtual router

Master
Router A
10.100.10.2/24
PC
Backup
10.100.10.3/24
Router B
Server 10.100.10.0/24
Backup
Backup group
Virtual IP Address 10.100.10.4/24 Router C
10.100.10.1/24
l Routers A, B, and C set up a backup group (acting as a virtual router), whose virtual IP
address is 10.100.10.1/24.
l Router A is the master device, whose IP address is 10.100.10.2/24.
l Routers B and C are backup devices, whose IP addresses are 10.100.10.3/24 and
10.100.10.4/24 respectively.
l For VRRP, only the master device can forward packets whose next hop addresses are the
virtual IP address.
Hosts on the internal network only know that the virtual IP address is 10.100.10.1. They do not
know the IP addresses of the master or backup devices. Therefore, each host configures its default
route to the virtual IP address. In this case, all hosts on the internal network can communicate
with external networks through this backup group.
The VRRP module on the master router monitors the state of the communication interface and
sends notification packets to the backup routers in multicast mode.
If the master router fails because of interface or link faults, the VRRP notification packets cannot
be sent out as usual.
When the backup routers do not receive any VRRP notification packet in a specified interval,
VRRP specifies the backup router with the highest priority as the new master router by bringing
the state of VRRP on it to master, and switches related transactions to the new master router.
Once the new master router fails, another backup router is selected as the master router according
to the priority, continuing to provide routing services to internal hosts.
The VRRP technology can ensure the communication between hosts on the internal network
and the external networks, thus enhancing reliability effectively.

9.1.2 Traditional VRRP on Eudemon Backup

The Eudemon adopts security zone mechanism. Two Eudemons can realize the route redundancy
function with one Eudemon acting as the master and the other as the backup. Interfaces on the
master and backup are connected with different security zones.
Typical Networking of Eudemon Backup

Traditional VRRP requires that each zone is configured with a VRRP group for monitoring the
working state of interfaces connected with the zone. Namely, interfaces connected with the same
zone on the Eudemon set up a backup group (a virtual firewall) and each group is assigned with
a virtual IP address. Figure 9-3 shows the typical networking of Eudemon backup.
Figure 9-3 Typical networking diagram of Eudemon backup

10.100.10.0/24
10.100.10.1/24
Trust
Virtual IP address Master
Backup group1 Eudemon A
LAN Switch
LAN Switch
LAN Switch
Untrust
Backup group3
Eudemon B Virtual IP address
Backup group2 202.38.10.1/24
10.100.20.0/24 Backup
Virtual IP address
DMZ
10.100.20.1/24
l Eudemon A acts as the master device and Eudemon B acts as the backup device.
l Interfaces connected with the Trust zone on the master and backup devices set up backup
group 1, which virtual IP address is 10.100.10.1/24.
l Interfaces connected with the DMZ on the master and backup devices set up backup group
2, which virtual IP address is 10.100.20.1/24.
l Interfaces connected with the Untrust zone on the master and backup devices set up backup
group 3, which virtual IP address is 202.38.10.1/24.
State Requirements
As a stateful firewall, the Eudemon checks only the head packet of a session flow and
dynamically creates session entries. Subsequent packets, including response packets can pass
through the Eudemon only when they match these session entries. If the outgoing and incoming
paths of a session are inconsistent, subsequent packets or response packets are dropped because
they cannot match the session entries of the Eudemon. Figure 9-4 shows the process.

Figure 9-4 Eudemon backup state

Trust
Untrust
Eudemon A
(1) (2) Master
Session entry
PC1 (3)
(8)
(7)
(4)
(6)
PC2
(5)
(9)
Backup
Eudemon B Actual connection
DMZ Packets traffic

l Suppose that the status of VRRP on Eudemon A and Eudemon B are respectively identical,
that is, all the interfaces on Eudemon A are master, and all the interfaces on Eudemon B
are backup. In this case, when PC 1 in the Trust zone attempts to access PC 2 in the Untrust
zone, the request packet is forwarded by (1)-(2)-(3)-(4). Eudemon A dynamically creates
session entries when forwarding the request packet. The response packet from PC 2 can
successfully reach Eudemon A along (5)-(6)-(7)-(8) because it matches session entries.
That ensures the continuity of communication.
l Suppose that the status of VRRP on Eudemon A and Eudemon B are not identical. For
example, the interface on Eudemon B connected with the Trust zone is backup while the
interface connected with the Untrust zone is master. After the packet from PC 1 reaches
PC 2 through Eudemon A, session entries are dynamically created on Eudemon A. The
response packet from PC 2 travels along (5)-(9) to PC 1. In this case, because no
corresponding session entries are available on Eudemon B and no other packet-filtering
rules allowing this packet to pass through, Eudemon B drops the packet. The session,
therefore, is torn down.
Consistent VRRP state means that for a Eudemon, the status of interfaces connected security
zones are identical, namely, all in master state or backup state.
The Eudemon connects with several security zones. Related interfaces in the same security zone
set up a backup group.
The traditional VRRP mechanism requires that VRRP in each backup group works
independently. This mechanism cannot ensure that the VRRP on each interface of the
Eudemon is master or backup. Therefore, the traditional VRRP cannot achieve VRRP state
consistency on the Eudemon.
Disadvantages of Traditional VRRP on Eudemon Backup

For the current networking application, the Eudemon, as a security device, is usually deployed
at the service access point between a protected network and an unprotected network.

As the requirements of customers for network reliability increase, it is necessary to ensure the
continuity of certain critical service ingresses or access points such as Internet access points and
database server access points.
If only one Eudemon is deployed at the service access point, no matter how reliable the
Eudemon is, the network is still prone to interruption because of single point failure.
In this case, you need to depend on the redundancy backup mechanism to enhance the stability
and reliability of the entire system.
9.2 VGMP Overview

To avoid VRRP state inconsistency, Huawei develops the VRRP Group Management Protocol
(VGMP) based on VRRP. VGMP can manage the VRRP state of each backup group. With the
VGMP mechanism, you can manage multiple VRRP backup groups (the virtual firewalls) in
terms of: state consistency, preemption, and channel.
9.2.1 VRRP Management Group Overview
To implement state consistency management, preemption management, and channel
management on multiple added backup groups, the concept of the VRRP management group is
introduced in the design of the Eudemon. A VRRP management group is a logical collection of
several backup groups that meet certain backup requirement.
9.2.2 Protocol Hierarchical Relation Between VRRP Management Groups and Backup Groups
A VRRP management group acts like a logical layer covering certain VRRP backup groups,
which exchange information through VGMP packets. VRRP backup groups exchange
traditional VRRP packets.
9.2.3 Functions of the VRRP Management Group
The VRRP group management has functions such as state consistency management, preemption
management, and channel management.
9.2.4 Relation Among a VRRP Management Group, Backup Group, and Interface
Typically, each security zone is configured with a VRRP backup group. A VRRP management
group realizes the state consistency of each VRRP. Each Eudemon is configured with at least
one VRRP management group that is responsible for managing the backup groups connected
with the security zones of the Eudemon.
9.2.5 Backup Mode Classification
The different combinations of interfaces, backup groups, and management groups help two
Eudemons realize different cooperation modes, such as master/backup mode and load balancing
mode. The Eudemon selects the backup mode according to the number of backup groups and
the priority of the Eudemon in each backup group.
9.2.1 VRRP Management Group Overview

To implement state consistency management, preemption management, and channel
management on multiple added backup groups, the concept of the VRRP management group is
introduced in the design of the Eudemon. A VRRP management group is a logical collection of
several backup groups that meet certain backup requirement.
A VRRP management manages added backup groups in a centralized way. Therefore VRRP
backup groups can communicate their VRRP state information.

You can determine whether to add a backup group to the VRRP management group or not
according to actual backup demand. The VRRP management group can manage backup groups
that have been added to it.
9.2.2 Protocol Hierarchical Relation Between VRRP Management

Groups and Backup Groups
A VRRP management group acts like a logical layer covering certain VRRP backup groups,
which exchange information through VGMP packets. VRRP backup groups exchange
traditional VRRP packets.
Figure 9-5 shows the protocol hierarchical relation between VRRP management groups and
backup groups.
Figure 9-5 Protocol hierarchical relation between VRRP management groups and backup
groups
VRRP management group
VGMP packet
VRRP backup group

Traditional
VRRP packet
Interface
VRRP backup groups report their own state information to the VRRP management group and
accept the management of the VRRP management group. When there is a problem with an
interface of a backup group or a related link, the state of the backup group changes. That may
affect the state of the VRRP management group.
In addition, a VRRP backup group can run independently without being added to the VRRP
management group. If the priority of the dissociative backup group is higher than that of the
backup groups in the VRRP management group, the master device determined by the
management group may be not identical with that elected by the dissociative backup groups. To
avoid system confusion caused by inconsistency, you need to configure higher priorities for
backup groups in the VRRP management group.
9.2.3 Functions of the VRRP Management Group

The VRRP group management has functions such as state consistency management, preemption
management, and channel management.
State Consistency Management

After the VRRP group management function is started, each backup group needs to notify the
VRRP management group of its own state change. The VRRP management group determines
whether the VRRP backup group can implement master/backup switch. If the VRRP

management group does not agree on the switchover, the VRRP state of each Eudemon in the
VRRP backup group cannot change.
State consistency management helps the devices of a VRRP group share VRRP state
information. The VRRP management group determines whether to perform state switchover,
thus ensuring that the VRRP backup groups are consistent in state.
Besides a notification packet, the master device can also initiatively send a Hello message to
backup device. Then backup device sends a notification packet after receiving the Hello message.
This mechanism helps the master and backup devices exchange state information.
Preemption Management
When a backup group is added into a VRRP management group and the VRRP management
group is already enabled, the VRRP management group determines whether to take preemption
no matter whether the preemption function is configured on the Eudemons in each VRRP backup
group. Namely, when a Eudemon finds that its own priority is higher than the present master
device, it is the VRRP management that determines whether to perform the preemption
operation.
When the communication between VRRP backup groups is interrupted while VGMP packets
can be normally transmitted, the state consistency can still be assured. In this case, no state
switchover occurs.
When the communication between the master device and the backup device is interrupted, and
no VGMP packet can be transmitted, that is, all data channels fail, the backup device
automatically changes to the master state.
When network communication resumes, there are two master devices on the network, sending
notification packets to each other. In this case, the VRRP management group determines the
master device according to priority.
Channel Management
Channel management can provide reliable channels for transferring the following packets:
l VGMP packets
l Packets over VGMP
l VRRP state packets
A VRRP management group can include several data channels. A data channel can exist in the
same physical link with a service flow channel or exist alone in a physical link. That depends
on your configuration. Your configuration also determines whether the state of a data channel
affects the state of each VRRP in a VRRP management group.
Figure 9-6 shows the relation between service channels and data channels.

Figure 9-6 Data channel for transmitting VGMP packets

Eudemon A
Master
A3
A1
A2 A4
Trust
LAN
Hub Untrust
switch
LAN
B1 B4 switch
DMZ B2
LAN
B3
switch
Eudemon B Actual connection
Backup Packets traffic
A1, A2, A3, and A4 Interface of Eudemon A
B1, B2, B3, and B4 Interface of Eudemon B
Any interface that connects the master device with a security zone can act as a starting end of a
data channel. An ending end is on the backup device. As a result, a data channel traversing the
LAN switch is set up.
Figure 9-6 consumes that A and B are interfaces and S is the LAN switch. Then A1-S-B1, A2-
S-B2, and A3-S-B3 are data channels.
In some cases, for the sake of link bandwidth and transmission quality, you can directly connect
the master device to the backup device (multiple lines are allowed) to protect service flows
against the interference of VRRP state information. In this case, you can set up data channel A4-
Hub-B4 between the master device and the backup device.
9.2.4 Relation Among a VRRP Management Group, Backup Group,

and Interface
Typically, each security zone is configured with a VRRP backup group. A VRRP management
group realizes the state consistency of each VRRP. Each Eudemon is configured with at least
one VRRP management group that is responsible for managing the backup groups connected
with the security zones of the Eudemon.
Figure 9-7 shows the relationship between a VRRP management group and a backup group.

Figure 9-7 Relation between a VRRP management group and a backup group
Eudemon A
Master Management
group 1
A1
Backup group 1 A3
A2
Trust
Untrust
Backup group 3
DMZ B1
Backup group 2 B3 Management
B2 group 1
Backup
Eudemon B
Actual connection
Traffic
A1, A2, and A3 Interface of Eudemon A
B1, B2, and B3 Interface of Eudemon B
The function of the redundancy backup mechanism is to duplicate a device in some sense. The
following sections describe the relationship between interfaces, backup groups, and management
groups on the Eudemons.
Relation Between Interfaces on the Two Eudemons

Connections between interfaces and security zones on the two Eudemons must be identical in
terms of:
l Interface slot
l Interface type
l Interface number
l Relevant configurations (except IP address settings)
For example, the configuration of interface A1 on Eudemon A must be identical with that of
interface B1 on Eudemon B. Be specific, both of them should be Ethernet interfaces, numbered ,
and associated with backup group 1.
Relation Between the VRRP Backup Groups on the Two Eudemons

Backup group number as well as component on the two Eudemons must be strictly identical.
For example, if interface A1 on Eudemon A belongs to backup group1, interface A2 to backup

group 2, and interface A3 to backup group 3, interfaces B1, B2, and B3 on Eudemon B should
belong to backup groups 1, 2, and 3 respectively.

Relation Between VRRP Management Groups on the Two Eudemons

Management group number as well as component on the two Eudemons must be strictly
identical.
For example, if a certain management group on Eudemon A includes <interface A1-backup
group 1>, <interface A2-backup group 2>, and <interface A3-backup group 3>, the management
group with the same number on Eudemon B should also includes <interface B1-backup group
1>, <interface B2-backup group 2>, and <interface B3-backup group 3>.
Relation Between Interfaces, Backup Groups, and Management Groups on One

Eudemon
One physical interface on a Eudemon (Eudemon A for example) should associate with multiple
VRRP backup groups. One backup group can associate with multiple physical interfaces and
correspond to several virtual IP addresses. One VRRP management group can include multiple
backup groups; the same backup group, however, cannot belong to different VRRP management
groups.
9.2.5 Backup Mode Classification

The different combinations of interfaces, backup groups, and management groups help two
Eudemons realize different cooperation modes, such as master/backup mode and load balancing
mode. The Eudemon selects the backup mode according to the number of backup groups and
the priority of the Eudemon in each backup group.
Master/Backup Mode
Based on the VGMP mechanism, you can carry out backup for two Eudemons. Each
Eudemon is configured with a VRRP management group with the same number but different
priorities, as shown in Figure 9-8.
Figure 9-8 Networking diagram of Eudemons in master/backup mode

Eudemon A
Master
A1
Backup group 1 A3
A2
Trust
Untrust
Backup group 3
DMZ B1
Backup group 2 B3
B2
Backup
Eudemon B
Actual connection
Traffic

In Figure 9-8:
l The backup groups are as follows:

– Backup group 1: includes interface A1 on Eudemon A and interface B1 on Eudemon
B.
B.
B.
l VRRP management group 1 on Eudemon A includes backup groups 1, 2, and 3 with Level
1 priority.
l VRRP management group 1 on Eudemon B also includes backup groups 1, 2, and 3 but
with Level 2 priority.
Since Level 1 priority is higher than Level 2 priority, Eudemon A works as the Master and
Eudemon B as the Backup.
Table 9-1 lists the device status in master/backup mode.
Table 9-1 Device status in master/backup mode
Eudemon VRRP Management Group 1
Member Priority Status Sessions

Processed
Eudemon A Backup groups Level 1 Master Whole

1, 2, and 3
Eudemon B Backup groups Level 2 Backup 0

1, 2, and 3
Hosts in the Trust zone, DMZ, and Untrust zone respectively send service data to interfaces A1,
A2 and A3 on Eudemon A (Master). All sessions are transferred through Eudemon A.
When the master device or its link fails, its status changes. The backup device becomes the
master device and transfers all session data.
Load Balancing Mode

The load balancing mode is also called the master/slave mode. This mode includes simplified
load balancing and complex load balancing:
l Simplified load balancing (through multiplexing the former interfaces)

Each Eudemon is configured with two VRRP management groups with different numbers
and different priorities, as shown in Figure 9-9.

Figure 9-9 Networking diagram of simplified load balancing

Backup Eudemon A
Backup Master/Backup
group 1 group 4
A1
A3
A2
Trust
Untrust
DMZ Backup
B1 Backup group 3
group 6
B3
B2
Backup Backup Backup/Master
group 2 group 5 Eudemon B
Actual connection
Traffic
The backup groups in the networking are as follows:

– Backup groups 1 and 4: include A1 interface of Eudemon A and B1 interface of
Eudemon B.
Eudemon B.
Eudemon B.
On Eudemon A:
– VRRP management group 1 includes backup groups 1, 2, and 3, with Level 1 priority.
– Level 1 > Level 2.
On Eudemon B:
– Level 3 < Level 4.
The priority relationship of the management groups on Eudemon A and Eudemon B are
listed as follows:
– Level 1 = Level 4
– Level 2 = Level 3
So Eudemon A is the master device negotiated by VRRP management group 1 and the
backup device negotiated by VRRP management group 2. In the same way, Eudemon B is
the backup device negotiated by VRRP management group 1 and the master device
negotiated by VRRP management group 2.

Table 9-2 lists the device status in load balancing mode I when the master and backup
devices work normally.
Table 9-2 Device status in simplified load balancing mode I

Eudemon VRRP VRRP Priority Status Sessions
Managem Backup Processed
ent Group Group
Eudemon A Manageme Backup Level 1 Master Partial

nt group 1 group 1, 2, 3
Eudemon B Manageme Backup Level 3 Backup 0

Eudemon A Manageme Backup Level 2 Backup 0

Eudemon B Manageme Backup Level 4 Master Partial

The priorities of the two VRRP management groups overlap, that is, Level 1 > Level 3 and
Level 2 < Level 4. Therefore, hosts in the Trust zone, DMZ, and Untrust zone respectively
send sessions to interfaces A1, A2 and A3 on Eudemon A and send the other sessions to
interfaces B1, B2 and B3 on Eudemon B. The two Eudemons share the communication
load.
When Eudemon B becomes faulty, VRRP management group 2 will switch the status of
each device. Eudemon A becomes the master device in VRRP management group 2 and
Eudemon B becomes the backup device. Eudemon A will transmit all sessions in this case.
The status listed in Table 9-2 change to these in Table 9-3.
Table 9-3 Device states in simplified load balancing mode II

Eudemon VRRP VRRP Priority Status Sessions
Managem Backup Processed
ent Group Group

Eudemon B Manageme Backup Level 3 Backup 0


Eudemon B Manageme Backup < Level 2 Backup 0

However, when Eudemon B recovers, it will be the master device in management group 2
again and share load with Eudemon A.

l Complex load balancing (newly added load balancing interfaces)

In the event that the interface rate of the Eudemon is not enough to smoothly transmit high
speed service flows, to ensure the normal transmission over a physical line, you are
recommended to add interfaces to the Eudemon and configure backup groups for load
balancing based on the newly added interfaces, as shown in Figure 9-10.
Figure 9-10 Networking diagram of complex load balancing

Backup Master / Backup
group 1 Eudemon A
A1
A2 A6 Backup
Backup A3 group 3
Trust A4 A5
group 4
Backup Untrust
group 2
Backup B3 B4 B5
DMZ B2 Backup
group 5 group 6
B1 B6
Eudemon B
Backup / Master
A1, A2, A3, A4, A5, and A6 Interface of Eudemon A
B1, B2, B3, B4, B5, and B6 Interface of Eudemon B
The original backup groups are backup groups 1, 2, and 3. Where:

– Backup group 1 includes Interface A1 on Eudemon A and Interface B4 on Eudemon B.
The new backup groups are backup groups 4, 5, and 6. Where:
The relationship between the management group and backup group of Eudemon A and
Eudemon B is listed as follows:
– The management group 1 includes backup groups 1, 2, and 3.
– The management group 2 includes backup groups 4, 5, and 6.
Eudemon A is the master device in VRRP management group 1 and the backup device in
VRRP management group 2; Eudemon B is the backup device in VRRP management group
1 and the master device in VRRP management group 2.

9.3 Introduction to Dual-System Hot Backup

The dual-system hot backup function of the Eudemon accomplishes hot backup of the
configuration commands and the state information. This function supports automatic backup
and manual patch backup.
9.3.1 HRP Application
The Huawei Redundancy Protocol (HRP) is transmitted through the VGMP packets to back up
key configuration commands and session status information of the master device and the backup
device.
9.3.2 Master/Slave Configuration Device
In load balancing mode, there are two master devices in the network. To avoid confusion during
backup, Eudemon devices are grouped into master configuration devices and backup
configuration devices.
9.3.1 HRP Application

The Huawei Redundancy Protocol (HRP) is transmitted through the VGMP packets to back up
key configuration commands and session status information of the master device and the backup
device.
The Eudemon is a stateful firewall so that there is a session entry for each dynamic session
connection on the Eudemon, as shown in Figure 9-11.
Figure 9-11 Data path in master/backup mode

PC
Backup
Eudemon A
(1) group 1 (2) Master PC
Session entries
Trust
(3)
LAN (4)
Server switch (6) (7)
(8)
(5) Backup LAN Untrust
group 3switch
DMZ Backup Eudemon B
LAN group 2 Backup Actual connection
switch Traffic
In master/backup mode, presume that:

l Eudemon A is the master device, it transmits all data and creates related dynamic session
entries.
l Eudemon B is the backup device, no data passes through it.
When errors occur on Eudemon A or on associated links, Eudemon B will become the master
device and begin to transfer data. However, if there are no backup session entries or configuration
commands on Eudemon B before status switch, all sessions that passed through Eudemon A will
be disconnected because the sessions cannot match the session entries on Eudemon B. As a
result, services are interrupted.

In order to make the backup device smoothly take over work when the master device breaks
down, backing up of configuration commands and session entries between the master device
and the backup device are necessary.
Huawei Redundancy Protocol (HRP) is developed for this purpose. HRP is transmitted over
VGMP packets in the data channels of a VRRP management group.
After the HRP dual-system hot backup function is enabled, if the status of the VRRP management
group changes because the master device becomes faulty, fault of master device leads to the
state change of VRRP management group, the VRRP management group reports the status
switch the HRP module, Then the HRP module decides whether to synchronize the backing up
of the configuration commands and information about the session status. Upon completion of
the backing up process, the VRRP management group preemption and then the VRRP backup
group preemption take place. In this way, the backup device smoothly takes over the service.
9.3.2 Master/Slave Configuration Device

In load balancing mode, there are two master devices in the network. To avoid confusion during
backup, Eudemon devices are grouped into master configuration devices and backup
configuration devices.
In load balancing mode, there are two master firewalls in the network. Users can enter many
commands on the two master firewalls. When one of the master firewalls fails, you should take
the following into consideration:
l How to backup information
l What to backup
l In which direction to backup
To avoid confusion during backup, Eudemon are grouped into master configuration devices and
backup configuration devices, which send or receive backup contents respectively.
When determining a master configuration device, comply with the following principle:
l In the VRRP management group, only the Eudemon that is in master state can have the
chance to be the master device for configurations.
l In load balancing mode, both Eudemon devices that take part in dual-system hot backup
are master devices. In this case, the Eudemon that first starts the HRP module becomes the
master device for configurations.
To assure the stability of the master device for configurations, status switch takes places only
when the master device for configurations becomes faulty or exits the VRRP backup group.
NOTE
The concepts of the master and slave configuration devices are introduced only in load balancing mode
rather than master/backup mode.
9.4 Hierarchical Protocol Relation Between VRRP Backup

Group, Management Group, and HRP
Protocol relationships exist between the VRRP backup group and the VGMP group, and the
VGMP group and HRP. HRP packets are carried by VGMP packets for transmission.
Figure 9-12 shows the hierarchical protocol relation between VRRP backup group, management
group, and HRP.

Figure 9-12 Hierarchical protocol relation between VRRP backup group, management group,
and HRP
HRP module
HRP packet
VRRP management group

VGMP packet
VRRP backup group
When the state of the VRRP management group changes, the system notifies the HRP and
master/slave configuration devices to change their states accordingly. In this way, configuration
commands and session status information are backed up in time between two devices.
Meanwhile, the state of the VRRP management group is also affected by HRP state change. In
other words, VRRP adjusts the priority and switch VRRP state according to the result of HRP
state switch.
When the state of the VRRP backup group changes, the VRRP management group decides
whether to change the state of the following elements:
l VRRP management group
l HRP
l Master and slave configuration devices
9.5 Checking the Configuration Consistency

Consistency check of configurations is used in the dual-system hot backup to check whether the
ACL configurations and HRP configurations of the master and backup devices are consistent
with each other.
If configurations of the master and backup devices do not match, packets will be discarded by
the backup device when the master device becomes faulty. As a result, internal and external
users cannot communicate through the backup device, and sessions between them are disrupted.
In this case, you can check the consistency between devices at both ends, and modify inconsistent
configurations as required.
The consistency check function enables you to do the following:
l Check whether ACL configurations of the master and backup devices are the same.
ACL configuration check includes the following:
– Whether the numbers of ACL groups are exactly the same.
– Whether the description of ACL groups, the order of matching ACL rules, step length,
and all ACL rules configurations with the same group numbers are the same.
l Check whether HRP configurations, including the VGMP group configurations and HRP
configuration commands, of the master and backup devices are the same.
VGMP group configuration check includes the following:

– Whether the VRRP management group numbers configured and enabled on the master
and backup devices are the same.
– Whether the configurations of VRRP backup groups within the same VRRP
management group are the same.
– Whether the configurations of the triggerdown attribute of interfaces within the same
VRRP management group are consistent.
– Whether the intervals for sending Hello packets within the same VRRP management
group are the same.
9.6 IP-Link Auto-detection Overview

IP-Link auto-detection automatically checks whether a service link works normally by utilizing
the features of the Internet Control Message Protocol (ICMP) or the Address Resolution Protocol
(ARP).
IP-Link detection periodically sends an ICMP or ARP requests to the specified destination IP
address, waits for the reply packets from the destination IP address, and then determines the
connection status of the network.
If no reply packet is received in the specific time, IP-Link auto-detection determines that faults
occur on the link and performs related operations. If three reply packets are received
consecutively in a specified period, IP-Link auto-detection determines that the faulty link has
recovered, and then performs related operations.
The detection result (destination host reachable or unreachable) provided by IP-Link auto-
detection can be referred by other features such as:
l Static route
When IP-Link auto-detection discovers faults on the link, the Eudemon adjusts its own
static routes correspondingly. If a link used by the static route of higher preference is found
faulty, the Eudemon selects a new link for forwarding services. If the link recovers from
the fault, the Eudemon adjusts its own static routes, replacing the lower preference route
with the higher preference route. Such adjustment ensures that the Eudemon always uses
a reachable link of the highest preference available, thus keeping the continuity of services.
l Dual-system hot backup
If the faulty link detected by IP-Link detection affects the active/standby service of the
firewall, the Eudemon adjusts the priority of the VRRP Group Management Protocol
(VGMP) to implement active/standby switch, thus ensuring service continuity.

Feature Description A Glossary
A Glossary
This describes glossaries in this document.
A
AAA An integrity framework for configuring the authentication, authorization, and
accounting functions. It is a way to manage the network security.
ACL A sequential instruction list consisting of a series of permit | deny statements.
In the scenario where a firewall is deployed on a network, an ACL is applied
to the interface of a router, and the router determines which packets can be
received and which should be denied according to the ACL. In QoS, ACLs
are also used for traffic classification.
AES The Advanced Encryption Standard (AES) is an encryption algorithm for
securing sensitive but unclassified material by U.S. Government agencies
and, as a likely consequence, may eventually become the de facto encryption
standard for commercial transactions in the private sector. (Encryption for the
US military and other classified communications is handled by separate,
secret algorithms.)
AH A protocol used in transport mode and tunnel mode for providing data
integrity and authentication services for IP packets.
ALG In the context of computer networking, an application-level gateway (also
known as application layer gateway) consists of a security component that
augments a firewall or NAT employed in a computer network. It allows
legitimate application data to pass through the security checks of the firewall
that would have otherwise restricted the traffic for not meeting its limited filter
criteria.
ARP A protocol used to resolve an IP address into an Ethernet MAC address.
AS In the Internet, an autonomous system (AS) is a collection of IP networks and
routers under the control of one entity (or sometimes more) that presents a
common routing policy to the Internet.
Issue 01 (2009-12-25) Huawei Proprietary and Confidential A-1

A Glossary Feature Description
ASPF A state-based packet filter mechanism applied to the application layer. ASPF
can be used to jointly work with a common static firewall to implement
security policies of an internal network. As ASPF is based on the session
information of the application layer protocol, it can intelligently filter TCP
and UDP packets. In addition, ASPF can detect sessions originated by any
side of the firewall.
B
BGP An interautonomous system routing protocol. An autonomous system is a
network or group of networks under a common administration and with
common routing policies. BGP is used to exchange routing information for
the Internet and is the protocol used between Internet service providers (ISP).
C
CA An organization that issues digital certificates (digital IDs) and makes its
public key widely available to its intended audience.
CAR An instance of traffic policing. CAR defines three traffic parameters, that is,
Committed Information Rate (CIR), Committed Burst Size (CBS), and Excess
Burst Size (EBS). CAR depends on the preceding parameters to evaluate
traffic. In addition, CAR classifies the monitoring objects and defines the
monitoring actions.
CE The router that is on the customer's side of the customer-provider interface.
CHAP A password authentication method. It is a three-way handshake authentication
with encrypted passwords. The authenticating party first sends some
randomly generated packets (Challenge) to the authenticated party. Then the
authenticated party encrypts the random packets with its own password and
MD5 algorithm and resends the generated encryption to the authenticating
party (Response). Finally, the authenticating party encrypts the original
random packets with the authenticated party password and MD5 algorithm,
compares the two encryptions, and returns the response (Acknowledge or Not
Acknowledge) according to the comparison.
CIDR An internetworking routing protocol. It is a way of using the existing 32-bit
Internet address space more efficiently commonly used by Internet Service
Providers. It allows the assignment of Class C IP addresses in multiple
contiguous blocks.
COPS COPS specifies a simple client/server model for supporting policy control
over Quality of Service (QoS) signaling protocols.
CPE-based A type of VPN application based on the client side device. The VPN function
VPN is realized on the client side device. The client is responsible for maintain the
VPN.
A-2 Huawei Proprietary and Confidential Issue 01 (2009-12-25)

DDN Digital Data Network (DDN) combines the digital channel such as fiber
channel, digital microwave channel or satellite channel with the cross
multiplex technology, providing a high-quality data transport tunnel.
DES A data encryption standard encrypting data in 64-bit block and generating 64-
bit encrypted text.
DH A shared key protocol proposed by Diffie and Hellman. With this protocol,
the communication parties can exchange data without transmitting the shared
key and calculate the shared key.
DHCP A client-server networking protocol used to obtain all necessary
configurations including IP addresses.
DNS A system used to map a human-friendly domain name to an IP address.
E
EGP Exterior Gateway Protocol (EGP) is a protocol for exchanging routing
information between two neighbor gateway hosts (each with its own router)
in a network of autonomous systems.
ESP A secure packet encapsulation protocol used in transport mode and tunnel
mode. Adopting encryption and authentication mechanisms, it provides IP
data packets with such services as data source authentication, data integrity,
anti-replay, and data confidentiality services.
F
FTP An application layer protocol used to transmit files between remote hosts.
FTP is realized based on the corresponding file system.
FIFO A message processing mode where packets are forwarded in the same order
in which they arrive at the interface.
G
GGSN The location register function in the GGSN stores subscription information
and routing information (needed to tunnel packet data traffic destined for a
GPRS MS to the SGSN where the MS is registered) for each subscriber for
which the GGSN has at lest one PDP context active.
GRE A protocol for performing encapsulation of an arbitrary network layer
protocol over another arbitrary network layer protocol.
H
HTTP A protocol used to transfer files for WWW service programs.

ICMP A layer 2 protocol that reports errors and provides other information relevant
to IP packet processing.
IETF An organization that is dedicated to developing and designing TCP/IP
protocol stack and Internet standards.
IKE A protocol used to exchange keys between Oakley and SKEME through
ISAKMP.
IP A protocol that provides connectionless best effort delivery of datagram
across heterogeneous physical networks. IP is a network layer protocol in the
TCP/IP protocol stack.
IPSec A series of protocols defined by the Internet Engineering Task Force (IETF).
This protocol family includes a set of system structures concerning data
security on an IP network, including such protocols as AH, ESP, and IKE.
ISAKMP A protocol providing a framework for authentication and key exchange. This
protocol does not specify specific implementation about authentication and
key exchange.
ISP A company that provides access to the Internet for users.
L
L2F A protocol that offers the tunnel encapsulation for the higher-level link layer.
L2F helps realize the physical separation between the dial-up server and dial-
up protocol connection.
L2TP A protocol that is drafted by the IETF and involves the participation of
companies such as Microsoft. L2TP combines the advantages of both PPTP
and L2F.
LAC A device that is attached to a switching network and is capable of L2TP
processing. It possesses PPP terminal system and generally provides the
access service to users.
LAN A network consisting of personal computers and workstations residing in the
same building or within several kilometers in circumference. LAN features
high speed and low error rate. Ethernet, FDDI, and Token Ring are three main
LAN techniques.
LNS A set of server software that processes the L2TP protocol on a PPP terminal
system.
M
MAC The lower of the two sublayers of the Data Link Layer. The MAC layer is
closer to the physical layer.
MAN A network of LANs or computers within a wide geographical area such as a
university campus. An MAN usually adopts the same technology as LAN. An
MAN can cover dozens of kilometers wide or a metropolitan (city-wide) area.

MD5 The fifth of the hash function series developed by Ron Rivest. The algorithm
converts a message of any length into a 128-bit "fingerprint" or digest to
realize digital signature and ensure the integrity of messages.
MTU The largest amount of data that is permissible to transmit as one unit according
to a protocol specification.
N
NAS A server that provides PSTN/ISDN dial-in users with Internet access services.
NAT A mechanism for reducing the need for globally unique IP addresses. NAT
allows an organization with private addresses to connect to the Internet by
translating those addresses into a globally unique and routable address.
P
PAP A protocol that requires twice handshake authentications. The password of
PAP is in plain text. The authenticated side first sends the user name and
password to the authenticating side. Then the authenticating side checks
whether the user exists and whether the password is correct according to user
configuration, and then returns response (Acknowledge or Not
Acknowledge).
PFS Perfect forward secrecy means that the attacker does not also gain the ability
to decrypt past or future connections, and only the messages from the one
connection can be read.
PING A utility program which tests access to a device by sending a series of ICMP
Echo messages and measuring its acknowledgement.
PPP A dedicated transmission link between two devices.
PPTP A tunnel protocol that encapsulates PPP on the tunnels of an IP network. The
protocol is supported by Microsoft, Ascend, and 3COM.
Q
QoS A way of evaluating the packet delivery ability of IP networks. The core
factors to determine the QoS are delay, delay jitter, and packet loss ratio.
These core factors require technical support.
R
RADIUS A distributed client/server system developed by Livinggston Enterprise.
RADIUS can provide the AAA function. As an authentication and accounting
protocol, RADIUS can realize access authentication, authorization, and
accounting functions for a great amount of users through serial ports and
modems.
RFC An Internet standard-related formal document from the IETF.

RIP A routing protocol that calculates routes with the D-V algorithm and selects
routes according to the hop number. RIP is widely used in small-sized
networks.
S
SA IPSec depends on SAs to realize security services for data streams. In IPSec,
a security association is uniquely identified by a triple consisting of a Security
Parameters Index (SPI), an IP Destination Address, and a security protocol
identifier, which specify how to process IP packets.
SPI A 32-bit pointer that is carried by each IPSec packet. An SA is uniquely
identified by a triple consisting of a Security Parameters Index (SPI), an IP
Destination Address, and a security protocol identifier.
SSH A set of network standards and protocols that provide secure Telnet access.
T
TCP A transport layer protocol that provides a connection-oriented, full-duplex,
point-to-point service between hosts.
TCP/IP TCP/IP protocol stack.
ToS Type of Service. The IP uses the ToS field to provide an indication of the
quality of service desired.
U
UDP Part of the TCP/IP protocol suite. UDP is a standard, connectionless, host-to-
host protocol that is used over packet-switched computer communication
networks.
V
VLAN A logically independent network. It divides a LAN into multiple logical
LANs. Each VLAN is a broadcast domain. The communication between the
hosts in a VLAN is similar to that in a LAN.
VP A logical terminal line used to access a router through Telnet.
VPDN A network that realizes VPN through the access network and the dialing up
function of the public network such as ISDN and PSTN.
VPLS A technology that enables interconnection of Local Area Networks (LANs)
through virtual private networks. VPLS realizes the extension of LANs to the
Internet.
VPN A new technology that helps implement a private network link, which is
carried on a public network through the use of tunneling. A VPN is a logical
network.

VPRN A network that realizes the communication between the headquarters,

branches, and the remote offices through the network management virtual
routers.
VRP A versatile operating system platform developed by Huawei and acts as the
general operating system platform of Huawei data communication products.
VRRP A protocol designed for the LAN that has multicast or broadcast capability,
such as the Ethernet. VRRP organizes a group of routers in a LAN (including
one master router and several backup routers) into a virtual router, namely,
the backup group. The virtual router has its own IP address and hosts in the
network communicate with other networks with this address. If the master
router in the backup group fails, a backup router in the backup group becomes
the new master router and continues to provide routing services for the hosts
in the network. In this way, hosts in the network can continue to communicate
with hosts in external networks.
VT A logic interface in VRP.
VTP A protocol used for managing VLAN-related operations such as adding,
deleting, and renaming a VLAN in the switching network. When a switch is
added to the network, the switch receives revision information from VTP and
automatically configures the existing VLAN in the network.
W
WAN A network that provides data communications to a large number of
independent users spread over a larger geographic area such as a country or
a province. It may consist of a number of LANs connected together.
WWW A large scale hypermedia information system that allows users to browse
information.

Feature Description B Acronyms and Abbreviations
B Acronyms and Abbreviations
This describes acronyms and abbreviations in this document.
A
AAA Authentication, Authorization and Accounting
ACK Acknowledgement
ACL Access Control List
AES Advanced Encryption Standard
AH Authentication Header
ALG Application Level Gateway
ARP Address Resolution Protocol
AS Autonomous System
ASPF Application Specific Packet Filter
B
BSD Berkeley Software Distribution
BGP Border Gateway Protocol
C
CA Certification Authority
CAR Committed Access Rate
CE Customer Edge
CHAP Challenge Handshake Authentication Protocol
CIDR Classless Inter-Domain Routing
CMS Call Management Server
Issue 01 (2009-12-25) Huawei Proprietary and Confidential B-1

B Acronyms and Abbreviations Feature Description
CMTS Cable Modem Terminal System

COPS Common Open Policy Service
CPE Customer Premises Equipment
CPU Central Processing Unit
CRL Certificate Revocation List
D
DDN Digital Data Network
DES Data Encryption Standard
DH Diffie-Hellman algorithm
DHCP Dynamic Host Configuration Protocol
DLCI Data-Link Connection Identifier
DMZ Demilitary Zone
DN Distinguished Name
DNS Domain Name System
DoD Downstream On Demand
DoS Denial of Service
DU Downstream Unsolicited
E
EGP Exterior Gateway Protocol
EMTA Embedded Multifunctional Terminal Adapter
ESP Encapsulating Security Payload
F
FEC Forwarding Equivalence Class
FIFO First In First Out
FTP File Transfer Protocol
G
GGSN Gateway GPRS Support Node
GRE Generic Routing Encapsulation
B-2 Huawei Proprietary and Confidential Issue 01 (2009-12-25)

GSR Gigabit Switching Router
H
HRP Huawei Redundancy Protocol
HTTP Hyper Text Transfer Protocol
HWCC Huawei Conference Control Protocol
HWTACACS Huawei Terminal Access Controller Access Control System
I
ICMP Internet Control Message Protocol
ID Identity
IDC Internet Data Center
IETF Internet Engineering Task Force
IGMP Internet Group Management Protocol
IGP Interior Gateway Protocol
IKE Internet Key Exchange
ILS Internet Locator Service
IP Internet Protocol
IPC Inter-Process Communication
IPSec IP Security Protocol
IPX Internet Packet Exchange
ISAKMP Internet Security Association and Key Management
Protocol
ISDN Integrated Services Digital Network
ISP Internet Service Provider
L
L2F Layer 2 Forwarding
L2TP Layer 2 Tunneling Protocol
LAC L2TP Access Concentrator
LAN Local Area Network
LCP Link Control Protocol
LDP Label Distribution Protocol

LER Labeled Edge Router

LNS L2TP Network Server
LR Limit Rate
LSA Localized Service Area
LSP Label Switched Path
LSR Label Switched Router
M
MAC Media Access Control
MBGP Multiprotocol Border Gateway Protocol
MD5 Message Digest 5
MED Multi-Exit Discriminator
MGCP Media Gateway Control Protocol
MIB Management Information Base
MMS Microsoft Media Service
MPLS Multi-Protocol Label Switch
MSDP Multicast Source Discovery Protocol
MSN MSN Messenger Service
N
NAPT Network Address and Port Translation
NAS Network Access Server
NAT Network Address Translation
NCP Network Control Protocol
NCS Network Call Signalling
NetBIOS Network Basic Input/Output System
NLRI Network Layer Reachable Information
O
OSI Open System Interconnection
OSPF Open Shortest Path First

P
P2P Peer To Peer
PAP Password Authentication Protocol
PC Personal Computer
PCI Peripheral Component Interconnect
PDU Packet Data Unit
PE Provider Edge
PFS Perfect Forward Secrecy
PKC Public Key Certificate
PKI Public Key Infrastructure
POP Point Of Presence
PPP Point-to-Point Protocol
PPPoE PPP over Ethernet
PPTP Point to Point Tunneling Protocol
PQ Priority Queue
PSTN Public Switched Telephone Network
Q
QoS Quality of Service
QQ Tencent QQ
R
RADIUS Remote Authentication Dial in User Service
RD Route Distinguisher
RFC Request For Comments
RIP Routing Information Protocol
RSA Rivest, Shamir and Adelman
RTSP Real-Time Streaming Protocol
S
SA Security Association
SACG Security Access Control Gateway

SHA Secure Hash Algorithm

SIP Session Initiation Protocol
SMTP Simple Mail Transfer Protocol
SP Service Provider
SPI Security Parameter Index
SQL Structured Query Language
SRS Security Recover Server
SSH Secure Shell
SSL Secure Socket Layer
T
TACACS Terminal Access Controller Access Control System
TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol / Internet Protocol
TFTP Trivial File Transfer Protocol
ToS Type of Service
TTL Time To Live
U
UDP User Datagram Protocol
V
VGMP VRRP Group Management Protocol
VLAN Virtual Local Area Network
VLL Virtual Leased Line
VPDN Virtual Private Dial Network
VPLS Virtual Private LAN Service
VPN Virtual Private Network
VPRN Virtual Private Routing Network
VRP Versatile Routing Platform
VRRP Virtual Router Redundancy Protocol

W
WAN Wide Area Network
WAP Wireless Application Protocol
WFQ Weighted Fair Queuing
WRED Weighted Random Early Detection
WWW World Wide Web


Quidway Eudemon 200E-B Firewall Feature Description (V100R002 - 01)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Quidway Eudemon 200E-B Firewall Feature Description (V100R002 - 01)

Uploaded by

Copyright:

Available Formats

Quidway Eudemon 200E-B Firewall

Huawei Proprietary and Confidential

Huawei Technologies Co., Ltd.

Copyright © Huawei Technologies Co., Ltd. 2009. All rights reserved.

Trademarks and Permissions

Huawei Proprietary and Confidential

About This Document.....................................................................................................................1

2 Introduction to the Eudemon...................................................................................................2-1

Issue 01 (2009-12-25) Huawei Proprietary and Confidential i

3.1.3 ACLs on the Eudemon...........................................................................................................................3-5

ii Huawei Proprietary and Confidential Issue 01 (2009-12-25)

4.3.3 PPPoE Session Period..........................................................................................................................4-12

Issue 01 (2009-12-25) Huawei Proprietary and Confidential iii

5.4.2 Implementation of GRE.......................................................................................................................5-27

7 Surfing Behavior Management...............................................................................................7-1

iv Huawei Proprietary and Confidential Issue 01 (2009-12-25)

Issue 01 (2009-12-25) Huawei Proprietary and Confidential v

Figure 2-1 Networking diagram in route mode....................................................................................................2-2

Issue 01 (2009-12-25) Huawei Proprietary and Confidential vii

Figure 5-3 Networking diagram of VPDN application based on L2TP.............................................................5-10

viii Huawei Proprietary and Confidential Issue 01 (2009-12-25)

Figure 9-4 Eudemon backup state........................................................................................................................9-5

Issue 01 (2009-12-25) Huawei Proprietary and Confidential ix

Table 3-1 Classification of the ACL.....................................................................................................................3-5

Issue 01 (2009-12-25) Huawei Proprietary and Confidential xi

About This Document

Product Name Version

Quidway Eudemon 200E-B V100R002

Issue 01 (2009-12-25) Huawei Proprietary and Confidential 1

1 Overview Describes network security, classification and implementation

4 Internetworking This section describes the network interconnection features of

5 VPN Describes the VPN features of the Eudemon, including L2TP,

6 Intrusion Detection Describes the intrusion detection features of the Eudemon.

7 Surfing Behavior Describes the surfing behavior management features of the

8 Mail Filtering Describes the mail filtering features of the Eudemon.

9 Reliability Describes VRRP, VGMP, HRP, and the implementation of dual-

A Glossary Lists the glossaries used in this document.

Indicates a hazard with a high level of risk, which if not avoided,

2 Huawei Proprietary and Confidential Issue 01 (2009-12-25)

Indicates a hazard with a medium or low level of risk, which if

Indicates a potentially hazardous situation, which if not avoided,

NOTE Provides additional information to emphasize or supplement

Times New Roman Normal paragraphs are in Times New Roman.

Boldface Names of files, directories, folders, and users are in boldface.

Italic Book titles are in italics.

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by vertical

[ x | y | ... ] Optional items are grouped in brackets and separated by vertical

{ x | y | ... } * Optional items are grouped in braces and separated by vertical

Issue 01 (2009-12-25) Huawei Proprietary and Confidential 3

[ x | y | ... ] * Optional items are grouped in brackets and separated by vertical

4 Huawei Proprietary and Confidential Issue 01 (2009-12-25)

Updates in Issue 01 (2009-12-25)

Issue 01 (2009-12-25) Huawei Proprietary and Confidential 5

About This Chapter

Issue 01 (2009-12-25) Huawei Proprietary and Confidential 1-1

1.1 Introduction to the Product

Enhanced Security Features

All these features help the Eudemon effectively protect networks.

High-speed Processing Capability