Home » D-Link Manuals » Networking » D-Link DFL-800-AV-12 » Manual Viewer

D-Link DFL-800-AV-12 User Manual - Page 291

High Availability Mechanisms

View all D-Link DFL-800-AV-12 manuals

Add to My Manuals
Save this manual to your list of manuals

Page 291 highlights

11.2. High Availability Mechanisms Chapter 11. High Availability 11.2. High Availability Mechanisms D-Link HA provides a redundant, state-synchronized hardware configuration. The state of the active unit, such as the connection table and other vital information, is continuously copied to the inactive unit via the sync interface. When cluster failover occurs, the inactive unit knows which connections are active, and traffic can continue to flow. The inactive system detects that the active system is no longer operational when it no longer detects sufficient Cluster Heartbeats. Heartbeats are sent over the sync interface as well as all other interfaces. NetDefendOS sends 5 heartbeats per second from the active system and when three heartbeats are missed (that is to say, after 0.6 seconds) a failover will be initiated. By sending heartbeats over all interfaces, the inactive unit gets an overall view of the active unit's health. Even if sync is deliberately disconnected, failover may not result if the inactive unit receives enough heartbeats from other interfaces via a shared switch, however the sync interface sends twice as many heartbeats as any of the normal interfaces. The administrator can disable heartbeat sending on any of the interfaces. Heartbeats are not sent at smaller intervals because such delays may occur during normal operation. An operation such as opening a file, could result in delays long enough to cause the inactive system to go active, even though the other is still active. Cluster heartbeats have the following characteristics: • The source IP is the interface address of the sending firewall • The destination IP is the shared IP address • The IP TTL is always 255. If NetDefendOS receives a cluster heartbeat with any other TTL, it is assumed that the packet has traversed a router, and hence cannot be trusted. • It is a UDP packet, sent from port 999, to port 999. • The destination MAC address is the ethernet multicast address corresponding to the shared hardware address. In other words, 11-00-00-C1-4A-nn. Link-level multicasts are used over normal unicast packets for security: using unicast packets would mean that a local attacker could fool switches to route heartbeats somewhere else so the inactive system nevers receives them. The time for failover is typically about one second which means that clients may experience a failover as a slight burst of packet loss. In the case of TCP, the failover time is well within the range of normal retransmit timeouts so TCP will retransmit the lost packets within a very short space of time, and continue communication. UDP does not allow retransmission since it is inherently an unreliable protocol. Both master and slave know about the shared IP address. ARP queries for the shared IP address, or any other IP address published via the ARP configuration section or through Proxy ARP, are answered by the active system. The hardware address of the shared IP address and other published addresses are not related to the actual hardware addresses of the interfaces. Instead the MAC address is constructed by NetDefendOS from the Cluster ID in the following form: 10-00-00-C1-4A-nn, where nn comes from combining the Cluster ID configured in the Advanced Settings section with the hardware bus/slot/port of the interface. The Cluster ID must be unique for each cluster in a network. As the shared IP address always has the same hardware address, there will be no latency time in updating ARP caches of units attached to the same LAN as the cluster when failover occurs. When a cluster member discovers that its peer is not operational, it broadcasts gratuitous ARP queries on all interfaces using the shared hardware address as the sender address. This allows switches to re-learn within milliseconds where to send packets destined for the shared address. The only delay in failover therefore, is detecting that the active unit is down. ARP queries are also broadcast periodically to ensure that switches don't forget where to send 291

Section	Page
User Manual	3
Table of Contents	4
Preface	12
Chapter 1. Product Overview	14
1.1. About D-Link NetDefendOS	14
1.2. NetDefendOS Architecture	16
1.2.1. State-based Architecture	16
1.2.2. NetDefendOS Building Blocks	16
1.2.3. Basic Packet Flow	17
1.3. NetDefendOS State Engine Packet Flow	19
Chapter 2. Management and Maintenance	23
2.1. Managing NetDefendOS	23
2.1.1. Overview	23
2.1.2. Default Administrator Accounts	23
2.1.3. The CLI	24
2.1.4. The WebUI	26
2.1.5. Working with Configurations	29
2.2. Events and Logging	35
2.2.1. Overview	35
2.2.2. Event Messages	35
2.2.3. Event Message Distribution	35
2.2.3.1. Logging to Syslog Hosts	36
2.2.3.2. SNMP Traps	37
2.3. RADIUS Accounting	39
2.3.1. Overview	39
2.3.2. RADIUS Accounting Messages	39
2.3.3. Interim Accounting Messages	41
2.3.4. Activating RADIUS Accounting	41
2.3.5. RADIUS Accounting Security	41
2.3.6. RADIUS Accounting and High Availability	41
2.3.7. Handling Unresponsive Servers	42
2.3.8. Accounting and System Shutdowns	42
2.3.9. Limitations with NAT	42
2.4. Monitoring	43
2.4.1. SNMP Monitoring	43
2.5. Maintenance	45
2.5.1. Auto-Update Mechanism	45
2.5.2. Configuration Backup and Restore	45
2.5.3. Resetting to Factory Defaults	45
Chapter 3. Fundamentals	48
3.1. The Address Book	48
3.1.1. Overview	48
3.1.2. IP Addresses	48
3.1.3. Ethernet Addresses	50
3.1.4. Address Groups	51
3.1.5. Auto-Generated Address Objects	51
3.2. Services	52
3.2.1. Overview	52
3.2.2. TCP and UDP Based Services	53
3.2.3. ICMP Services	55
3.2.4. Custom IP Protocol Services	55
3.3. Interfaces	57
3.3.1. Overview	57
3.3.2. Ethernet	58
3.3.3. VLAN	60
3.3.4. PPPoE	61
3.3.4.1. Overview of PPP	61
3.3.4.2. PPPoE Client Configuration	62
3.3.5. GRE Tunnels	63
3.3.6. Interface Groups	66
3.4. ARP	68
3.4.1. Overview	68
3.4.2. ARP in NetDefendOS	68
3.4.3. ARP Cache	68
3.4.4. Static and Published ARP Entries	69
3.4.5. Advanced ARP Settings	71
3.5. The IP Rule Set	73
3.5.1. Security Policies	73
3.5.2. IP Rule Evaluation	74
3.5.3. IP Rule Actions	75
3.5.4. Editing IP rule set Entries	76
3.6. Schedules	77
3.7. X.509 Certificates	79
3.7.1. Overview	79
3.7.2. X.509 Certificates in NetDefendOS	80
3.8. Setting Date and Time	82
3.8.1. General Date and Time Settings	82
3.8.2. Time Servers	83
3.9. DNS Lookup	87
Chapter 4. Routing	89
4.1. Overview	89
4.2. Static Routing	90
4.2.1. Basic Principles of Routing	90
4.2.2. Static Routing	91
4.2.3. Route Failover	94
4.2.4. Proxy ARP	96
4.3. Policy-based Routing	98
4.3.1. Overview	98
4.3.2. Policy-based Routing Tables	98
4.3.3. Policy-based Routing Rules	98
4.3.4. Policy-based Routing Table Selection	99
4.3.5. The Ordering parameter	99
4.4. Dynamic Routing	103
4.4.1. Dynamic Routing overview	103
4.4.2. OSPF	104
4.4.3. Dynamic Routing Policy	107
4.5. Multicast Routing	110
4.5.1. Overview	110
4.5.2. Multicast Forwarding using the SAT Multiplex Rule	110
4.5.2.1. Multicast Forwarding - No Address Translation	111
4.5.2.2. Multicast Forwarding - Address Translation Scenario	112
4.5.3. IGMP Configuration	114
4.5.3.1. IGMP Rules Configuration - No Address Translation	115
4.5.3.2. IGMP Rules Configuration - Address Translation	116
4.6. Transparent Mode	119
4.6.1. Overview of Transparent Mode	119
4.6.2. Comparison with Routing mode	119
4.6.3. Transparent Mode Implementation	119
4.6.4. Enabling Transparent Mode	120
4.6.5. High Availability with Transparent Mode	120
4.6.6. Transparent Mode Scenarios	120
Chapter 5. DHCP Services	127
5.1. Overview	127
5.2. DHCP Servers	128
5.3. Static DHCP Assignment	130
5.4. DHCP Relaying	131
5.5. IP Pools	132
Chapter 6. Security Mechanisms	135
6.1. Access Rules	135
6.1.1. Introduction	135
6.1.2. IP spoofing	135
6.1.3. Access Rule Settings	136
6.2. Application Layer Gateways	138
6.2.1. Overview	138
6.2.2. HTTP	139
6.2.3. FTP	140
6.2.4. TFTP	145
6.2.5. SMTP	146
6.2.5.1. DNSBL SPAM Filtering	147
6.2.6. POP3	151
6.2.7. SIP	152
6.2.8. H.323	155
6.3. Web Content Filtering	169
6.3.1. Overview	169
6.3.2. Active Content Handling	169
6.3.3. Static Content Filtering	170
6.3.4. Dynamic Web Content Filtering	172
6.3.4.1. Content Filtering Categories	176
6.4. Anti-Virus Scanning	183
6.4.1. Overview	183
6.4.2. Implementation	183
6.4.3. Activating Anti-Virus Scanning	184
6.4.4. The Signature Database	184
6.4.5. Subscribing to the D-Link Anti-Virus Service	184
6.4.6. Anti-Virus Options	184
6.5. Intrusion Detection and Prevention	188
6.5.1. Overview	188
6.5.2. IDP Availability in D-Link Models	188
6.5.3. IDP Rules	190
6.5.4. Insertion/Evasion Attack Prevention	191
6.5.5. IDP Pattern Matching	192
6.5.6. IDP Signature Groups	192
6.5.7. IDP Actions	194
6.5.8. SMTP Log Receiver for IDP Events	194
6.6. Denial-Of-Service (DoS) Attacks	198
6.6.1. Overview	198
6.6.2. DoS Attack Mechanisms	198
6.6.3. Ping of Death and Jolt Attacks	198
6.6.4. Fragmentation overlap attacks: Teardrop, Bonk, Boink and Nestea	199
6.6.5. The Land and LaTierra attacks	199
6.6.6. The WinNuke attack	199
6.6.7. Amplification attacks: Smurf, Papasmurf, Fraggle	200
6.6.8. TCP SYN Flood Attacks	201
6.6.9. The Jolt2 Attack	201
6.6.10. Distributed DoS Attacks	201
6.7. Blacklisting Hosts and Networks	202
Chapter 7. Address Translation	204
7.1. Dynamic Network Address Translation	204
7.2. NAT Pools	207
7.3. Static Address Translation	210
7.3.1. Translation of a Single IP Address (1:1)	210
7.3.2. Translation of Multiple IP Addresses (M:N)	213
7.3.3. All-to-One Mappings (N:1)	215
7.3.4. Port Translation	216
7.3.5. Protocols handled by SAT	216
7.3.6. Multiple SAT rule matches	217
7.3.7. SAT and FwdFast Rules	217
Chapter 8. User Authentication	220
8.1. Overview	220
8.2. Authentication Setup	221
8.2.1. Setup Summary	221
8.2.2. The Local Database	221
8.2.3. External Authentication Servers	221
8.2.4. Authentication Rules	222
8.2.5. Authentication Processing	223
8.2.6. HTTP Authentication	223
Chapter 9. VPN	229
9.1. Overview	229
9.1.1. The Need for VPNs	229
9.1.2. VPN Encryption	229
9.1.3. VPN Planning	229
9.1.4. Key Distribution	230
9.2. VPN Quickstart Guide	231
9.2.1. IPsec LAN to LAN with Pre-shared Keys	231
9.2.2. IPsec Roaming Clients with Pre-shared Keys	232
9.2.3. IPsec Roaming Clients with Certificates	234
9.2.4. L2TP Roaming Clients with Pre-Shared Keys	234
9.2.5. L2TP Roaming Clients with Certificates	236
9.2.6. PPTP Roaming Clients	236
9.2.7. VPN Troubleshooting	237
9.3. IPsec	240
9.3.1. Overview	240
9.3.2. Internet Key Exchange (IKE)	240
9.3.3. IKE Authentication	245
9.3.4. IPsec Protocols (ESP/AH)	247
9.3.5. NAT Traversal	248
9.3.6. Proposal Lists	249
9.3.7. Pre-shared Keys	250
9.3.8. Identification Lists	251
9.4. IPsec Tunnels	253
9.4.1. Overview	253
9.4.2. LAN to LAN Tunnels with Pre-shared Keys	253
9.4.3. Roaming Clients	253
9.4.3.1. PSK based client tunnels	254
9.4.3.2. Self-signed Certificate based client tunnels	255
9.4.3.3. CA Server issued Certificates based client tunnels	256
9.4.3.4. Using Config Mode	257
9.4.4. Fetching CRLs from an alternate LDAP server	259
9.5. PPTP/L2TP	260
9.5.1. PPTP	260
9.5.2. L2TP	261
Chapter 10. Traffic Management	267
10.1. Traffic Shaping	267
10.1.1. Introduction	267
10.1.2. Traffic Shaping in NetDefendOS	268
10.1.3. Simple Bandwidth Limiting	269
10.1.4. Limiting Bandwidth in Both Directions	270
10.1.5. Creating Differentiated Limits with Chains	271
10.1.6. Precedences	272
10.1.7. Guarantees	274
10.1.8. Differentiated Guarantees	274
10.1.9. Groups	275
10.1.10. Recommendations	276
10.1.11. A Summary of Traffic Shaping	277
10.2. Threshold Rules	279
10.2.1. Overview	279
10.2.2. Connection Rate/Total Connection Limiting	279
10.2.3. Grouping	279
10.2.4. Rule Actions	279
10.2.5. Multiple Triggered Actions	280
10.2.6. Exempted Connections	280
10.2.7. Threshold Rules and ZoneDefense	280
10.2.8. Threshold Rule Blacklisting	280
10.3. Server Load Balancing	281
10.3.1. Overview	281
10.3.2. Identifying the Servers	282
10.3.3. The Load Distribution Mode	282
10.3.4. The Distribution Algorithm	282
10.3.5. Server Health Monitoring	284
10.3.6. SLB_SAT Rules	284
Chapter 11. High Availability	289
11.1. Overview	289
11.2. High Availability Mechanisms	291
11.3. High Availability Setup	293
11.3.1. Hardware Setup	293
11.3.2. NetDefendOS Setup	294
11.3.3. Verifying Cluster Functioning	294
11.4. High Availability Issues	296
Chapter 12. ZoneDefense	298
12.1. Overview	298
12.2. ZoneDefense Switches	299
12.3. ZoneDefense Operation	300
12.3.1. SNMP	300
12.3.2. Threshold Rules	300
12.3.3. Manual Blocking and Exclude Lists	300
12.3.4. Limitations	302
Chapter 13. Advanced Settings	304
13.1. IP Level Settings	304
13.2. TCP Level Settings	307
13.3. ICMP Level Settings	311
13.4. ARP Settings	312
13.5. Stateful Inspection Settings	314
13.6. Connection Timeouts	316
13.7. Size Limits by Protocol	318
13.8. Fragmentation Settings	320
13.9. Local Fragment Reassembly Settings	324
13.10. DHCP Settings	325
13.11. DHCPRelay Settings	326
13.12. DHCPServer Settings	327
13.13. IPsec Settings	328
13.14. Logging Settings	330
13.15. Time Synchronization Settings	331
13.16. PPP Settings	333
13.17. Hardware Monitor Settings	334
13.18. Packet Re-assembly Settings	335
13.19. Miscellaneous Settings	336
Appendix A. Subscribing to Security Updates	338
Appendix B. IDP Signature Groups	340
Appendix C. Checked MIME filetypes	344
Appendix D. The OSI Framework	348
Appendix E. D-Link worldwide offices	349

Match case Limit results 1 per page

11.2. High Availability Mechanisms

D-Link HA provides a redundant, state-synchronized hardware configuration. The state of the active

unit, such as the connection table and other vital information, is continuously copied to the inactive

unit via the

sync

interface. When cluster failover occurs, the inactive unit knows which connections

are active, and traffic can continue to flow.

The inactive system detects that the active system is no longer operational when it no longer detects

sufficient

Cluster Heartbeats

. Heartbeats are sent over the

sync

interface as well as all other

interfaces. NetDefendOS sends 5 heartbeats per second from the active system and when three

heartbeats are missed (that is to say, after 0.6 seconds) a failover will be initiated. By sending

heartbeats over all interfaces, the inactive unit gets an overall view of the active unit's health. Even

sync

is deliberately disconnected, failover may not result if the inactive unit receives enough

heartbeats from other interfaces via a shared switch, however the

sync

interface sends twice as many

heartbeats as any of the normal interfaces. The administrator can disable heartbeat sending on any of

the interfaces.

Heartbeats are not sent at smaller intervals because such delays may occur during normal operation.

An operation such as opening a file, could result in delays long enough to cause the inactive system

to go active, even though the other is still active.

Cluster heartbeats have the following characteristics:

•

The source IP is the interface address of the sending firewall

•

The destination IP is the shared IP address

•

The IP TTL is always 255. If NetDefendOS receives a cluster heartbeat with any other TTL, it is

assumed that the packet has traversed a router, and hence cannot be trusted.

•

It is a UDP packet, sent from port 999, to port 999.

•

The destination MAC address is the ethernet multicast address corresponding to the shared

hardware address. In other words,

11-00-00-C1-4A-nn

. Link-level multicasts are used over

normal unicast packets for security: using unicast packets would mean that a local attacker could

fool switches to route heartbeats somewhere else so the inactive system nevers receives them.

The time for failover is typically about one second which means that clients may experience a

failover as a slight burst of packet loss. In the case of TCP, the failover time is well within the range

of normal retransmit timeouts so TCP will retransmit the lost packets within a very short space of

time, and continue communication. UDP does not allow retransmission since it is inherently an

unreliable protocol.

Both master and slave know about the shared IP address. ARP queries for the shared IP address, or

any other IP address published via the ARP configuration section or through Proxy ARP, are

answered by the active system. The hardware address of the shared IP address and other published

addresses are not related to the actual hardware addresses of the interfaces. Instead the MAC address

is constructed by NetDefendOS from the Cluster ID in the following form: 10-00-00-C1-4A-nn,

where nn comes from combining the Cluster ID configured in the Advanced Settings section with

the hardware bus/slot/port of the interface. The Cluster ID must be unique for each cluster in a

network.

As the shared IP address always has the same hardware address, there will be no latency time in

updating ARP caches of units attached to the same LAN as the cluster when failover occurs.

When a cluster member discovers that its peer is not operational, it broadcasts gratuitous ARP

queries on all interfaces using the shared hardware address as the sender address. This allows

switches to re-learn within milliseconds where to send packets destined for the shared address. The

only delay in failover therefore, is detecting that the active unit is down.

ARP queries are also broadcast periodically to ensure that switches don't forget where to send

11.2. High Availability Mechanisms

Chapter 11. High Availability

291