Elfiq Linkbalancer Administrator Guide v3 04 PDF

Elfiq Link Balancer (Link LB) Administrator Guide
Elfiq Operating System (EOS) - Version 3.5.2 and higher

Document Version 3.04 - July 2012
Elfiq Networks (Elfiq Inc.) www.elfiq.com
1. About the Document

Purpose This document provides detailed information on configuring and managing Elfiq Link Balancer.
Conventions In this document, the following conventions are used:
Command syntaxes are written in 12pt courier on a single line with the parameters in brackets:
command name [parameter1] [parameter2option1|parameter2option2]
Example configurations or excerpts from output of commands are written in a box:

LinkLB-enable:system [single] #set int eth0 auto
Specific annotations are written in bold and can be of 3 types: NOTE IMPORTANT WARNING
Additional Information For online access to our complete set of documentation and tools, please visit the support section of our website at http://www.elfiq.com
Support Center You can contact the Elfiq Support Center at support@elfiq.com. A member of our team will be pleased to answer you.
Copyright 2004-2011, Elfiq Networks (Elfiq Inc.). All rights reserved.

All the information contained in this document is owned by Elfiq inc. and protected by worldwide copyright laws. No modification or reproduction is permitted without the prior written authorization of the owner. Elfiq is a trademark of Elfiq inc. All trademarks mentioned herein belong to their respective owners. Elfiq inc. shall not be liable for any damages resulting from the use of this information and the products described herein. Elfiq inc. reserves the right to make changes to any information within this document and to make improvements and/or changes in the products described herein at any time and without notice.
Link LB Administrator Guide EOS 3.5.2 and higher Document Version 3.04 - July 2012
2/160
Table of Contents
1. 2. ABOUT THE DOCUMENT .................................................................................................................................... 2 GETTING STARTED .............................................................................................................................................. 8
2.1. About the Elfiq Link Balancer .................................................................................................................................................8 2.1.1. Layer 2 Integration and Primary Link ..................................................................................................................................... 8 2.1.2. Ports ....................................................................................................................................................................................... 9 2.2. Access the Elfiq Link Balancer .............................................................................................................................................. 10 2.2.1. Console Port ......................................................................................................................................................................... 10 2.2.1. Management Port ................................................................................................................................................................ 11 2.3. Configure and Manage the Elfiq Link Balancer ..................................................................................................................... 11 2.3.1. Required Information before Configuring ........................................................................................................................... 11 2.3.2. Command Line Interface (CLI) .............................................................................................................................................. 11 2.3.3. Elfiq Operating System (EOS) Overview ............................................................................................................................... 12 2.3.4. Navigate through EOS Modules ........................................................................................................................................... 13 2.3.5. Graphical User Interface (GUI) ............................................................................................................................................. 14 2.3.1. Application Programming Interface (API) ............................................................................................................................ 15 2.4. Monitoring and Troubleshooting ......................................................................................................................................... 15 2.4.1. System Log Events ................................................................................................................................................................ 15 2.4.2. VFI Probe and Statistics ........................................................................................................................................................ 16
3.
3.1. 3.2.
SYSTEM MODULE (SYST) .................................................................................................................................. 19

About System Module ......................................................................................................................................................... 19 Initial Configuration ............................................................................................................................................................. 19
3.3. Change Settings ................................................................................................................................................................... 22 3.3.1. Set Date and Time ................................................................................................................................................................ 22 3.3.2. Set Local Time Zone ............................................................................................................................................................. 22 3.3.3. Set a Network Time Protocol (NTP) Server .......................................................................................................................... 23 3.3.4. Set the IP Address ................................................................................................................................................................ 23 3.3.5. Set the Default Gateway ...................................................................................................................................................... 23 3.3.6. Set IP Address and Default Gateway Simultaneously .......................................................................................................... 23 3.3.7. Set the Hostname ................................................................................................................................................................ 24 3.3.8. Set SYSLOG Server Information ............................................................................................................................................ 24 3.3.9. Set Ethernet Network Port Speed and Duplex ..................................................................................................................... 24 3.3.10. Create Dynamic Network Interfaces .................................................................................................................................... 25 3.3.11. Set a Virtual Management (VMGMT) Interface ................................................................................................................... 25 3.3.12. Set LAN Bypass Ports............................................................................................................................................................ 26 3.3.13. Change the LCD Display Mode ............................................................................................................................................. 27 3.4. Change Services ................................................................................................................................................................... 28 3.4.1. HTTP/HTTPS Service ............................................................................................................................................................. 28 3.4.2. SNMP Configuration ............................................................................................................................................................. 28 Link LB Administrator Guide EOS 3.5.2 and higher Document Version 3.04 - July 2012
3/160
3.4.3.
SMTP Alert Service ............................................................................................................................................................... 29
3.5. Display System Information ................................................................................................................................................. 30 3.5.1. EOS Version and License ...................................................................................................................................................... 31 3.5.2. System Module Information and Environment Metrics ...................................................................................................... 31 3.5.3. System Log Events ................................................................................................................................................................ 32 3.6. Manage User Access ............................................................................................................................................................ 32 3.6.1. First Log In with the Management User ............................................................................................................................... 32 3.6.2. Set the Enable Mode ............................................................................................................................................................ 33 3.6.3. Change the Management User Password ............................................................................................................................ 33 3.6.4. Change the Enable User Password ....................................................................................................................................... 34 3.6.5. Define Users and Assign to Security Groups ........................................................................................................................ 34 3.6.6. Show All Users ...................................................................................................................................................................... 34 3.6.7. Show All Groups ................................................................................................................................................................... 34 3.6.8. Add/Remove a User to/from a Group.................................................................................................................................. 35 3.6.9. Change a User Password ...................................................................................................................................................... 35 3.6.10. Add a DSA Key to a User ...................................................................................................................................................... 35 3.6.11. Show a User DSA Key ........................................................................................................................................................... 36 3.6.12. Lightweight Directory Access Protocol (LDAP) and Active Directory (AD) ........................................................................... 36 3.6.13. Password Reset .................................................................................................................................................................... 41 3.7. Manage Configuration Files ................................................................................................................................................. 41 3.7.1. Save the Running Configuration of a Module to Flash......................................................................................................... 42 3.7.2. Save the Running Configuration of all Modules to Flash ..................................................................................................... 44 3.7.3. Execute a Configuration from Flash ..................................................................................................................................... 44 3.7.4. Manually Edit Configuration Files ........................................................................................................................................ 44 3.7.5. Manage Configuration Files on Flash ................................................................................................................................... 46 3.8. 3.9. EOS Firmware Update .......................................................................................................................................................... 46 Shutdown or Reload the System .......................................................................................................................................... 47
4.
4.1.
VIRTUAL FORWARDER INTERFACE (VFI) .................................................................................................. 49

About Virtual Forwarder Interface ....................................................................................................................................... 49
4.2. Initial Configuration of Primary Link..................................................................................................................................... 50 4.2.1. Inside and Outside Interfaces .............................................................................................................................................. 50 4.2.2. VFI features .......................................................................................................................................................................... 54 4.2.3. ARP Requests and MAC Adresses ........................................................................................................................................ 57 4.2.4. Primary Link GMAC .............................................................................................................................................................. 61 4.2.5. Installation and Verification ................................................................................................................................................. 64 4.3. Add Alternate Links and GMAC Management ...................................................................................................................... 66 4.3.1. DHCP and PPPoE Configuration ........................................................................................................................................... 66 4.3.2. Discover MAC Addresses ..................................................................................................................................................... 67 4.3.3. Assign a GMAC to an Outside Inteface ................................................................................................................................ 67 4.3.4. GMAC MTU .......................................................................................................................................................................... 68 4.3.5. GMAC Aliases ....................................................................................................................................................................... 68 4.3.6. GMAC Networks ................................................................................................................................................................... 68
4/160
4.3.7. 4.3.8. 4.3.9. 4.3.10. 4.3.11. 4.3.12.
Change the State of a GMAC ................................................................................................................................................ 68 GMAC probe......................................................................................................................................................................... 69 GMAC tcpprobe ................................................................................................................................................................... 69 GMAC Weight, Speed, Threshold and Description .............................................................................................................. 69 Remove a GMAC Entry ......................................................................................................................................................... 70 GMAC Statistics .................................................................................................................................................................... 70
4.4. IP Association between Links, Access Lists and Persistence ................................................................................................. 70 4.4.1. IP Association Table ............................................................................................................................................................. 70 4.4.2. Access Lists ........................................................................................................................................................................... 71 4.4.3. Outside Network Address Translation (NAT) Rules ............................................................................................................. 75 4.4.4. Persistence ........................................................................................................................................................................... 78 4.4.5. Protocol Specific Fixes .......................................................................................................................................................... 80 4.5. Outgoing Load Balancing (OLB) ............................................................................................................................................ 80 4.5.1. IP Address Pools ................................................................................................................................................................... 80 4.5.2. Outgoing Load Balancing Algorithms Using NAT ................................................................................................................. 84 4.5.3. Inside Network Address Translation Rules........................................................................................................................... 85 4.6. Incoming Load Balancing (ILB) .............................................................................................................................................. 89 4.6.1. Intelligent DNS Facility (IDNS) .............................................................................................................................................. 89 4.6.2. DNS Server Configuration .................................................................................................................................................... 90 4.6.3. Incoming Traffic Balancing Algorithms ................................................................................................................................ 93 4.6.4. IDNS Interceptors ................................................................................................................................................................. 94 4.6.5. IDNS Resource Records ........................................................................................................................................................ 95 4.7. Advanced Options and Tools ................................................................................................................................................ 97 4.7.1. Child GMACs......................................................................................................................................................................... 97 4.7.2. Route Policy Based Balancing .............................................................................................................................................. 98 4.7.3. Quality of Service (QoS) ....................................................................................................................................................... 99 4.7.4. Deep Packet Inspection (DPI) ............................................................................................................................................. 102 4.7.5. TAG Load Balancing ............................................................................................................................................................ 105 4.7.6. Internal Condition Verificator (ICV).................................................................................................................................... 107 4.7.7. Intelligent Service Verificator (ISV) .................................................................................................................................... 115 4.7.8. Filtering Access Lists ........................................................................................................................................................... 117 4.7.9. Shunning Engine................................................................................................................................................................. 119 4.7.10. Tap Interface ...................................................................................................................................................................... 120 4.7.11. Debug Tools ....................................................................................................................................................................... 121 4.7.12. How to manage the LLB using Inline Access ...................................................................................................................... 122 4.8. Site-to-site Resilience with SitePathMTPX ......................................................................................................................... 123 4.8.1. About SitePathMTPX .......................................................................................................................................................... 123 4.8.2. Components ....................................................................................................................................................................... 124 4.8.3. SitePathMTPX Algorithms .................................................................................................................................................. 125 4.8.4. BSFA Adjustments .............................................................................................................................................................. 126 4.8.5. Polling................................................................................................................................................................................. 127 4.8.6. Encryption .......................................................................................................................................................................... 127 4.8.7. Dynamic SitePath IP Address ............................................................................................................................................. 127 4.9. Geographic Balancing with Geolink .................................................................................................................................... 128 4.9.1. About Geolink .................................................................................................................................................................... 128 4.9.2. Geolink ............................................................................................................................................................................... 129
5/160
4.9.3. 4.9.4. 4.9.5.
Geotag and Geotag Groups................................................................................................................................................ 130 Inbound Geolink ................................................................................................................................................................. 132 Global Geolink .................................................................................................................................................................... 132
5.
5.1.
FAILOVER MODULE (FOVE).......................................................................................................................... 134

About Failover Module ...................................................................................................................................................... 134
5.2. Initial Configuration ........................................................................................................................................................... 136 5.2.1. IP Address of the Peer Unit ................................................................................................................................................ 136 5.2.2. Interfaces to Monitor ......................................................................................................................................................... 137 5.2.3. Virtual IP Address (VIP) ...................................................................................................................................................... 137
6.
6.1. 6.2. 6.3. 6.4.
APPENDIXES ...................................................................................................................................................... 139

Appendix A: Information Sheets for Configuration ............................................................................................................ 139 Appendix B: System Log Events .......................................................................................................................................... 146 Appendix C: API Programming Examples ........................................................................................................................... 151 Appendix D: DNS Delegation on a Microsoft DNS Server ................................................................................................... 156
6/160
Table of Figures
Figure 1: Typical setup with a single Internet Service Provider (ISP) ..................................................................................... 8 Figure 2: Typical setup with multiple ISPs .............................................................................................................................. 9 Figure 3: USB, console, and Ethernet ports ........................................................................................................................... 9 Figure 4: Graphical User Interface ........................................................................................................................................ 15 Figure 5: Configuration files flowchart ................................................................................................................................... 42 Figure 6: VFI in a monomode setup with 2 links ................................................................................................................... 50 Figure 7: Ethernet network port selection example in a monomode setup with 2 links ........................................................ 51 Figure 8: Ethernet network ports on a 4-port unit ................................................................................................................. 52 Figure 9: Virtual Forwarder Interface packet flow diagram ................................................................................................... 56 Figure 10: ARP interception flowchart .................................................................................................................................. 58 Figure 11: ARP verification order .......................................................................................................................................... 59 Figure 12: Display of 2 GMACs where a VFI balances 2 ISPs ............................................................................................. 61 Figure 13: DHCP link connected on the eth2 interface ......................................................................................................... 66 Figure 14: IP association with 3 links .................................................................................................................................... 70 Figure 15: Access list flowchart............................................................................................................................................. 72 Figure 16: dnat and rnat out .................................................................................................................................................. 75 Figure 17: dnat and rnat in .................................................................................................................................................... 88 Figure 18: Flowchart of the IDNS facility DNS interception process ..................................................................................... 89 Figure 19: Flowchart of a typical DNS query ........................................................................................................................ 91 Figure 20: Flowchart of the IDNS facility DNS interception process ..................................................................................... 92 Figure 21: Setup with a tap interface to monitor the network through a network IDS ........................................................ 120 Figure 22: SitePathMTPX ................................................................................................................................................... 124 Figure 23: BSFA Adjustments ............................................................................................................................................. 126 Figure 24: Inbound Geolink ................................................................................................................................................. 128 Figure 25: Typical failover scenario .................................................................................................................................... 134 Figure 26: Failover to peer unit after a failure from a critical port in a VFI .......................................................................... 134 Figure 27: Failover to peer unit after a failure from switch .................................................................................................. 135 Figure 28: Failover to peer unit after a failure from a master unit ....................................................................................... 135 Figure 29: No changes occur after a failure of a management port ................................................................................... 136 Figure 30: No changes occur after a failure of an ISP link ................................................................................................. 136 Figure 31: Management LAN with 2 Link LB units in failover mode with a virtual IP (VIP) ................................................ 137
7/160
2. Getting Started
In this section, you will find information about the Elfiq Link Balancer (Link LB) and how to: Access the Link LB. Configure and manage the Link LB. Monitor and troubleshoot the Link LB.
2.1.
About the Elfiq Link Balancer

2.1.1. Layer 2 Integration and Primary Link
When you install an Elfiq Link Balancer, no network configuration changes are required because of the layer 2 integration design. The Link LB operates at the data link layer (layer 2) of the OSI model. Therefore, it is transparent, or inline to your firewall and internal network.
Typical setup with a single Internet Service Provider (ISP):
Internal Network
ISP Link Firewall Public IP: 194.204.1.2 ISPs router IP: 194.204.1.1/25
ISP network
Internet
Figure 1: Typical setup with a single Internet Service Provider (ISP)
NOTE: The public network segment has been randomly chosen for this guide and must be changed for your link IP addresses. In this setup, all internal computers are connected to a firewall and the firewall is in turn connected to the ISP router. All the internal computers are configured with private IP addressing and using the firewall as their default gateway. In most cases, no information about internal IP addressing is necessary for configuring the Link LB. On the public internet side, the firewall itself uses the IP address of the ISP router as its default gateway. The Link Balancer is installed between the firewall and the ISP router on the public and unprotected side. Inbound connections from the Internet will pass through the Link LB and be proces sed by the firewalls corporate security policies. From this point, you can install alternate links without changing the configuration of your firewall. The Link LB will handle all the links transparently.
Typical setup with two Internet Service Providers (ISP):
8/160
Client Network
Firewall IP: 194.204.1.3
ISP A Link
ISP A network
ISP As router IP: 194.204.1.1/25
Internet
ISP B network
ISP B Link
ISP Bs router IP: 212.217.1.1/28

Figure 2: Typical setup with multiple ISPs
ISP A becomes the primary link and is the only ISP logically visible to your firewall. To your firewall, all data will always seem to come and go from your primary link as the Link LB will take care of handling the other links in a transparent manner. In case of a primary link failure or a primary link router being turned off, your firewall will still have the impression it is in operation and continue to send traffic to the Link LB and the alternate links. IMPORTANT: The only difference at layer 2 for your firewall is that the primary link router MAC address will change for the Link LB inside interface MAC address. NOTE: The term "primary link" does not imply any preference or performance considerations. It is called as such because of its IP addressing. From a load balancing perspective, this link and all the other links are considered based on the configured strategy carried out by the algorithms.
2.1.2.
Ports
Figure 3: USB, console, and Ethernet ports
Console Port The console port is a serial DB-9 or RJ45 port, depending on the Link LB model and is used to access the Command Line Interface (CLI).
Ethernet Ports Ethernet ports can be 10/100 or 10/100/1000 Mbps copper ports, Single Fibre Ports (SFP) or CX4 Ports, depending on the Link LB model. Copper ports are referred as ethx, SFP ports as sfpx and CX4 ports as cx4x where x is the port number (for example, eth1 refers to copper port 1). The number and type of Ethernet ports depend on the Link LB model. Ethernet ports are divided into three categories: Management interface (MGMT) The Ethernet port of the management interface is configured with an IP address. It is used to configure the Link LB, access statistics, and send alerts, syslog and SNMP traps. This can be done via the Web-based Link Balancer Management console or an SSH client. It is a dedicated port by default but it can be virtualized for certain environments. With a virtual management interface, the physical port becomes available for use with ISP
9/160
links. Inside interface The inside interface is connected to the inside device, usually the firewall. Outside interfaces Outside interfaces are connected to link routers.
NOTE: The inside and outside interfaces are not dedicated to specific physical ports in order to fulfill different operating modes and architectures. They are assigned in the Link LB configuration. NOTE: Only one physical port or VLAN can be configured to be the inside interface. You cannot attach multiple ports or VLANs to the inside interface of the Link LB. In the case of multiple primary link devices, a switch must be used. Bypass Your Link LB model is equipped with one or more pairs of ports supporting the Elfiq LAN Failsafe technology. They are identified with the keyword Bypass on the faceplate. On some models, LAN Failsafe can be turned on or off in the configuration while on others it is always on. IMPORTANT: In a single unit installation, the WAN interface of the firewall and the LAN interface of the primary link router should be connected to a LAN Failsafe port. WARNING: In a physical redundancy (failover) installation, LAN Failsafe ports must not be used or must be deactivated in the configuration. This is because it would cause a loop in one of the connected switches. USB Ports A USB port can be used to inject a configuration at boot up or to perform an EOS firmware update via USB thumb drive. It can also be used to connect a USB Mobile Stick for 3G/4G ISP links.
2.2.
Access the Elfiq Link Balancer
You can access the Link LB directly through the console port or through a secured network connection.
2.2.1.
Console Port
In case of network failure, or for security purposes, the Link LB can always be accessed through the console port. Since physical access is required and no information is passed over the network, this is the most secure way to manage your Link LB. Before you can access the system through the console port, you must first connect your computer or terminal to the Elfiq Link Balancer with a DB9 F/F or RJ45 null modem cable, like the one provided with your Link LB. You must then setup a terminal application, in which you will set the console port on your system with the following options: Bits per seconds: 9600 Data bits: 8 Parity: None Stop bits: 1 Flow Control: None
Once your physical connectivity is completed, simply press the enter key to establish a session and have the login prompt.
login as:
There are several terminal applications that are freely available, depending on your systems operating system. For Microsoft Windows users, you can use the built-in HyperTerminal application, available in the Program Files Accessories Communications sub menu of the Start Menu. Other suggested freeware applications include Tera Term Link LB Administrator Guide EOS 3.5.2 and higher Document Version 3.04 - July 2012
10/160
Pro, PuTTY and IVT, which are freely accessible for download on the Internet. For Linux or Unix users, notable suggestions are Minicom and Kermit.
2.2.1.
Management Port
The Link LB can also be managed via the management port. This Ethernet port is identified as MGMT on the front bezel of the unit and is referred to as the management interface. The default IP address for a Link LB is 10.1.0.100 (subnet mask 255.255.255.0 or /24). The following management methods can be used via this management interface: Web Interface (GUI) via HTTP and/or HTTPS, accessible via most browsers SSHv2 (CLI), for use with SSH clients, such as PuTTY SNMP API SYSLOG
Access to the management interface and IP address on all TCP/UDP ports corresponding to the services mentioned above is required. For the initial configuration setup, the MGMT port may be connected to a computer with an IP address in the 10.1.0.0/24 network (with the exception of 10.1.0.100). NOTE: This initial setup can be done using a provided orange or red crossover network cable directly connected to the Link LB management interface and the computer Ethernet network port. That computers IP address could be set to 10.1.0.101 with a subnet mask of 255.255.255.0 and an optional gateway of 10.1.0.1. A simple test to ensure connectivity between the computer and the management interface is to ping the default Link LBs IP address (10.1.0.100) from that computer.
2.3.
Configure and Manage the Elfiq Link Balancer
You can configure and manage the Link LB through the Command Line Interface, a web-based interface as well as remotely through the Application Programming Interface.
2.3.1.
Required Information before Configuring
Before configuring the Elfiq Link Balancer, you should fill out the information sheets provided in appendix. The basic installation and initial configuration will be made easier as all required information This will help you simplify the initial configuration of your Link LB by limiting the delays related to information gathering, since most of the required information will already be contained in the sheets for a basic installation. A more complex installation, however, will require additional information and possibly the support of an Elfiq specialist. In this case, a network diagram is also required. For the list of information sheets to fill in, please refer to Appendix A.
2.3.2.
Command Line Interface (CLI)
The CLI is your main access point to configure and manage the Elfiq Link Balancer. You can access the CLI using one of the following accesses: Console port SSHv2 connection Graphical User Interface
For detailed information on the CLI and a complete list of all available commands, please consult the Command Reference Guide.
11/160
2.3.3.
Organization
Elfiq Operating System (EOS) Overview
The EOS is divided into modules and each module provides a specific set of functions and settings.
The following modules are available: broker: Master module Link and access point to all the other modules. syst: System module Manage system configuration such as IP address configuration, system name, date and time, SMTP alerts, SNMP settings, logging, system loading options, configuration files on flash, EOS upgrades vfix: Virtual Forwarder Interface (x is the ID of the VFI) Manage all traffic passing through the inside and outside ports, links, access lists, NAT, IDNS, balancing rules, etc. Advanced Link LB models have multiple instances of the VFI module (vfi0, vfi1, etc.). fove: Failover module Manage the failover engine including setting and monitoring the peer status and the virtual IP interface.
Versions and License Keys Depending of the model, Elfiq Operating Systems are available in up to four different versions per model: Single version. Failover version. Single version with Geolink option. Failover version with Geolink option.
Each Elfiq Link Balancer model and version requires a unique license to operate which is specific to the activated features/modules. The maximum number of VFI instances (1, 2 or 5) is also a parameter inside your license key. License keys are unique to each Link LB unit. A license key is comprised of 32 characters in upper case letters and was supplied at purchasing. IMPORTANT: Please contact your Elfiq partner or the Elfiq support center at support@elfiq.com if you do not have your license key. It is required prior to configuring the Elfiq Link Balancer. NOTE: Keep your Elfiq license key. You will need the license key in the future if you remove the flash configuration to return to factory settings.
Activate a new license key A new license key must be activated following a firmware update in these cases: EOS with additional features (failover module, Geolink option, etc.) EOS with a different license type (end-user, demo, not for resale, etc.); A major EOS software update (for example passing from version 3.x to 4.0).
12/160
When required, the new license key is sent to your administrative contact. If you did not receive your new license key, please contact the Elfiq support center at support@elfiq.com. Command syntax: licence
[licence key]
LinkLB-mgmt: [single] #ena Password: LinkLB-enable: [single] #syst LinkLB-enable:system [single] #license EEECAAA4966658F86HG80L400F2J0F4P LinkLB-enable:system [** License not verified **] #sh license Key[EEECAAA4966658F86HG80L400F2J0F4P] Type[Not Available] Description[LinkLB-AX-VFI1-SH-EXT] Hw Model[LB1000] Version[3] Status[Key not verified] LinkLB-enable:system [** License not verified **] #LinkLB-enable:system [single] #ram2flash LinkLB-enable:system [** License not verified **] #LinkLB-enable:system [single] #reload
Verify License Activation Verify that the [key ok] status is displayed. Command syntax: sh
license
LinkLB-enable:system [single] #sh license Key[EEECAAA4966658F86HG80L400F2J0F4P] Type[Demo] Description[LinkLB-AX-VFI1-SH-EXT] Hw Model[LB1000] Version[3] Status[key ok, DEMONSTRATOR, Evaluation only] LinkLB-mgmt: [single] #sh license Key[EEECAAA4966658F86HG80L400F2J0F4P] Description[LinkLB-NX-VFI5-SH-TP-EXT] Hw Model[LB3000] Version[3] Status[key ok]
EOS Firmware version verification To make sure that you are running the latest EOS firmware, check the version with the module.
LinkLB-enable:system [single] #sh ver Version [3] Revision [4] Build [3 (701)] Date [Jan 29 2011] HW Model [LB1000] Type [LinkLB-AX-VFI1-SH-EXT] Compiled By [eosmaker1@elfiq.com RC13]
sh ver command from any
2.3.4.
Navigate through EOS Modules
To navigate through the different modules, all you have to do is enter its name on the command prompt. This will then take you into the appropriate module. Typing exit will either return you to the broker master module, or if you were already in broker, exit the configuration utility. There is no need to go back to the broker module to switch between one of the sub modules. Once again, just entering the name of the module will bring you into it. Here is an example:
LinkLB-mgmt: [master] # syst LinkLB-mgmt:system [master] # exit LinkLB-mgmt: [master] # vfi0 LinkLB-mgmt:vfi0 [master] # syst LinkLB-mgmt:system [master] # broker LinkLB-mgmt: [master] #
13/160
2.3.5.
Graphical User Interface (GUI)
The GUI is the easiest way to verify the Link LB status, see real-time link usage and statistics, and perform basic configuration in a typical NAT-based implementation using public Internet links. You can access the GUI by typing the Link LB management port IP address in the address bar of a web browser. IMPORTANT: The HTTP and/or HTTPS module must be enabled in the system module configuration in order to access the GUI. Once connected, a login screen is displayed for user authentication.
14/160
Figure 4: Graphical User Interface
2.3.1.
Application Programming Interface (API)
You can manage your Elfiq Link Balancer remotely through the Application Programming Interface and custom applications. The Elfiq API is based on XML and connections are handled through port 9998. Any command that can be issued on the CLI can be used in the API. For examples of API programming, please refer to Appendix C.
2.4.
Monitoring and Troubleshooting
You can monitor and troubleshoot the Link LB using the following available tools. NOTE: You can also refer to the Troubleshooting Knowledge Base in the support section of the Elfiq website at www.elfiq.com/support
2.4.1.
System Log Events
The system module logs all the events of the Elfiq Link Balancer. You can display the log to view the most recent events that took place in the Link LB. For a list of system log events, please refer to Appendix B.
Display System Log Events
15/160
Command syntax: sh
log event
event 4 (Info) Restoring system configuration from flash 2 (Warning) Flash2ram, start 2 (Warning) Flash2ram, done 4 (Info) VFI ready, initial status [running] 1 (Alert) Elfiq Operating System (EOS) loaded/initialized 3 (Notice) Api service ready 4 (Info) Acquiring VFI reconfig state 4 (Info) Clearing all VFI configuration 4 (Info) Releasing VFI reconfig state 4 (Info) Outside interface [eth2], carrier ok, [interface up] 1 (Alert) Inside interface [eth1], carrier ok, [interface up] 2 (Warning) TCP probe OK for gmac2 [test], enabled [link up] 3 (Notice) TCP probe[1] timeout for gmac2 [test], tcpprobe [20.0.0.2:22] 1 (Alert) Verification of gmac1 [test] failed, disabled [link down] 1 (Alert) Verification of gmac2 [test] successfull, enabled [link up
LinkLB-mgmt:system [single] #sh log Feb 25 14:41:41 I-EOS2-007001 Feb 25 14:41:41 W-EOS2-006100 Feb 25 14:41:41 W-EOS2-006101 Feb 25 14:41:43 I-VFI0-020702 Feb 25 14:41:45 A-SYST-004001 Feb 25 14:41:47 N-BNET-000162 Feb 25 14:41:51 I-VFI0-020601 Feb 25 14:41:51 I-VFI0-020600 Feb 25 14:41:51 I-VFI0-020602 Feb 25 14:41:54 I-VFI0-020703 Feb 25 14:41:54 A-VFI0-020705 Feb 25 14:41:58 W-VFI0-020201 Feb 25 14:41:59 N-VFI0-009001 Feb 25 14:42:24 A-VFI0-009004 (N) Feb 25 14:42:24 A-VFI0-009003
2.4.2.
VFI Probe and Statistics
Each VFI instance has a probe. You can use this probe to see actual sessions passing through the Elfiq Link Balancer and display statistics. The probe stores the following statistics for each session: The link that the session is balanced on. Actual session link usage (in Kb/s for incoming and outgoing packets). Top bandwidth usage that the session achieved (in Kb/s for incoming and outgoing packets). Protocol. Inside IP address of the session (primary link or associated IP on an alternate link). Inside port number. Session flow, defines if the session was initiated from the inside (outgoing) or from the outside (incoming). Outside IP address of the session. Outside port number. Total number of KB transferred for incoming and outgoing packets. Duration of the session since it was established.
NOTE: The rank is calculated with the total number of KB transferred (incoming + outgoing).
Enable the Probe Feature Command syntax: feature
probe enable
IMPORTANT: You must first enable the probe feature in order for the probe to be activated into the VFI stack.
LinkLB-enable:vfi0 [single] #feature probe enable
Display Probe Statistics Command syntax: sh
probe report [number of sessions]
LinkLB:vfi0 [single] #sh probe report 10 Top 10 live sessions

Rank Gmac In (kb/s) Out (kb/s) Top In (kb/s) Top Out (kb/s) Proto IP Inside Port Flow IP Outside Port In KB Out KB Duration ---- ---- ---------- ---------- -------------- -------------- ---------- ---------------- ------ ------ ---------------- ------ -------- -------- --------------1 1 0.00 0.83 0.00 1.75 icmp 172.16.1.100 --> 172.16.1.1 0 459302 51d18h29m53s 2 1 55.25 1564.87 69.61 1874.94 tcp 172.16.1.102 52865 <-172.16.1.1 58048 872 24323 0d 0h 1m58s 3 1 59.07 1652.08 69.21 1885.84 tcp 172.16.1.102 18187 <-172.16.1.1 58435 869 24025 0d 0h 1m59s 4 2 0.71 0.00 2.90 0.00 icmp 10.0.2.102 <-10.0.2.1 1313 0 0d 5h48m11s 5 2 0.00 0.00 0.12 0.00 tcp 10.0.2.102 ftp <-10.0.2.1 59314 0 0 0d 0h 2m11s 6 2 0.00 0.00 0.12 0.00 tcp 10.0.2.102 ftp <-10.0.2.1 59312 0 0 0d 0h 2m21s 7 2 0.00 0.00 0.12 0.00 tcp 10.0.2.102 ftp <-10.0.2.1 59306 0 0 0d 0h 2m34s 8 2 0.00 0.00 0.12 0.00 tcp 10.0.2.102 ftp <-10.0.2.1 59326 0 0 0d 0h 1m47s
16/160
9 10
2 2
0.00 0.00
0.00 0.00
0.12 0.12
0.00 0.00
tcp tcp
10.0.2.102 10.0.2.102
ftp ftp
<-<--
10.0.2.1 10.0.2.1
59324 59308
0 0
0 0
0d 0h 1m57s 0d 0h 2m30s
Total of 522998736 bytes, number of sessions 196 icmp 471671302 bytes, 90.19 % tcp 51302542 bytes, 9.81 % udp 24892 bytes, 0.00 % Outgoing traffic Incoming traffic 519835714 bytes, 99.40 % 3163022 bytes, 0.60 %
Report generated Mar 14 2011 10:33:49
Reset Probe Statistics Command syntax: clr
probe
Display VFI Statistics Command syntax: sh
vfi stats
[Dec 16 2010 17:27:24] [542.722 (kb/s)] [271.774 (kb/s)] [63423.288 (kb/s)] [3069.437 (kb/s)] [552795152] [191877066620, 178.699 GB] [120531128] [33747066145, 31.429 GB] [944116] [0] [382094018] [2413222] [1489105] [1607] [52] [0] [0.000] [25.108 us (microseconds)] [2643.928 us (microseconds)] [227] [1636] [2] [2.000] [26.000] [3584499 since Dec 16 2010 17:27:24] [83] [939] [2] [0.500] [0.000] [1573239 since Dec 16 2010 17:27:24] [0.000] [1.000] [257 since Dec 16 2010 17:27:24] [0.000] [2.000] [1054 since Dec 16 2010 17:27:24]
LinkLB-enable:vfi0 [single] #sh vfi stats Packets Inside/Outside Since Total incoming throughput (all gmacs) Total outgoing throughput (all gmacs) Top total incoming throughput (all gmacs) Top total outgoing throughput (all gmacs) Total number of packets received (outside) Total number of bytes received (outside) Total number of packets received (inside) Total number of bytes received (inside) Total number of L2 dropped packets Total number of IP dropped (Shun) packets Total number of IP dropped (All) packets Total number of IP fragmented (Nat) packets Total number of TCP MSS modified Total number of TCP checksum error (Nat) packets Total number of UDP checksum error (Nat) packets Total number dropped packets (probe) Total number dropped packets/sec (probe) Last vfi packet time traversal Top vfi packet time traversal Dynamic Nat Inside (dnat in) Total number of live sessions Top total number of live sessions Sampling interval Total number of new sessions/sec Total number of ending sessions/sec Total number of handled sessions Dynamic Nat Outside (dnat out) Total number of live sessions Top total number of live sessions Sampling interval Total number of new sessions/sec Total number of ending sessions/sec Total number of handled sessions Dns Requests Outside (idns) Total number of dns requests/sec Top total number of dns requests/sec Total number of handled dns requests Dns Requests Inside (idns) Total number of dns requests/sec Top total number of dns requests/sec Total number of handled dns requests Packets Inside/Outside
17/160
Since Total incoming throughput (all gmacs) Total outgoing throughput (all gmacs) Top total incoming throughput (all gmacs) Top total outgoing throughput (all gmacs) Total number of packets received (outside) Total number of bytes received (outside) Total number of packets received (inside) Total number of bytes received (inside) Total number of L2 dropped packets Total number of IP dropped (Shun) packets Total number of IP dropped (All) packets Total number of IP fragmented (Nat) packets Total number of TCP MSS modified Total number of TCP checksum error (Nat) packets Total number of UDP checksum error (Nat) packets Total number dropped packets (probe) Total number dropped packets/sec (probe) Last vfi packet time traversal Top vfi packet time traversal Dynamic Nat Inside (dnat in) Total number of live sessions Top total number of live sessions Sampling interval Total number of new sessions/sec Total number of ending sessions/sec Total number of handled sessions Dynamic Nat Outside (dnat out) Total number of live sessions Top total number of live sessions Sampling interval Total number of new sessions/sec Total number of ending sessions/sec Total number of handled sessions Dns Requests Outside (idns) Total number of dns requests/sec Top total number of dns requests/sec Total number of handled dns requests Dns Requests Inside (idns) Total number of dns requests/sec Top total number of dns requests/sec Total number of handled dns requests
[May 07 2009, 16:57:24] [1890.894 (kb/s)] [509.723 (kb/s)] [11858.776 (kb/s)] [5673.762 (kb/s)] [20949512] [13446554793, 12.523 GB] [12392648] [4127428193, 3.844 GB] [323533] [0] [128] [402] [197690] [122] [6] [0] [0.000] [19.712 us (microseconds)] [132.864 us (microseconds)] [112] [7201] [2] [1.500] [0.000] [393096 since May 07 2009, 16:57:24] [320] [640] [2] [0.500] [0.000] [140973 since May 07 2009, 16:57:24] [0.000] [0.000] [0 since May 07 2009, 16:57:24] [1.000] [10.000] [43515 since May 07 2009, 16:57:24]
Reset VFI Statistics Command syntax: clr
vfi stats
18/160
3. System Module (syst)

In this section, you will find information about the System Module and how to: Initialize the module. Change settings and services. Manage user acess. Display system information. Manage configuration files. Shutdown or reload the system.
3.1.
About System Module
All system configurations for the Elfiq Link Balancer are managed by the syst module, which, as mentioned before, is the core system module. It is with this module that you configure the network Ethernet ports, management interface, users, system parameters, SNMP, SMTP alerts, as well as manage your configuration files and EOS versions. Through the syst module, you can monitor your Link LB; including environment values, uptime, processes and network port status and statistics. All commands in this section assume that you are in the syst module of the command line interface. Once again, to enter the syst module, simply type syst from anywhere in the interface. IMPORTANT: The current Elfiq Link Balancer Admin Guide mainly contains examples and screenshots using the command line interface (CLI) via console or SSHv2 access. Altough the Web-based Link Balancer Management can be used to send CLI commands, please refer to alternate documents and screencasts for using that user interface.
3.2.
Initial Configuration
To configure the system module and management interface for the first time, you will need to log into the Link Balancer with the management user. The initial configuration has to be done through the serial console port or via the default management interface IP address 10.1.0.100 through an SSH connection. Also, because there is currently no configuration in the device, once you log in with the enable user, you will be asked to configure basic elements of the system module. During the initial configuration, you will be asked to provide the following information: Hostname of the device IP address of the management interface Network mask of the management interface IP address of the default gateway for the management network IP address of the logging system (syslog) destination IP address and port of the SMTP relay if you want to be notified by email Email address for recipient SMTP alert and SMTP sender address Link LB license key
Once the session is established, you will be prompted to login to the Elfiq Link Balancer command line interface.
Login as: mgmt mgmt@10.1.0.100s password: ****
The default username and password are the following: User: mgmt Password: mgmt
19/160
Once you log into the Link LB in enabled mode ( enable command after the mgmt login), you will be taken through the initial setup script. Some defaults values are included as examples and will be applied, should you press enter without entering any other value.
LinkLB-mgmt: [** License missing **] #ena Password: Basic system configuration -------------------------Enter basic system configuration now [yes]: yes Enter hostname [LinkLB]: LinkLB Enter management ip/bitmask [10.1.0.100/24]: 192.168.0.200/24 Enter default gateway [192.168.0.1]: 192.168.0.1 Enter logging (syslog) destination ip [disable]: 10.0.30.243 Configure time/date/timezone [yes]: yes Enter UTC date and time [Mar 16 2011 19:56:55]: 2011-03-16 19:56:28 Enter UTC timezone [+00:00]: -05:00 Activate HTTP service [yes]: yes Configure SMTP (mail) alerts [yes]: yes Enter mail (smtp) relay ip [10.1.0.254]: 10.0.30.242 Enter mail (smtp) relay port number [25]: 25 Enter smtp recipients separated by commas [helpdesk@mydomain]: support@mydomain Enter smtp sender [LinkLB@mydomain]: LinkLB@mydomain Configure license now [yes]: yes Enter license key: CC70FA92F626D449A65BBCB090F29B9E Hostname [LinkLB] Ip [192.168.0.200] Netmask [255.255.255.0] Network [192.168.0.0] Broadcast [192.168.0.255] Default gateway [192.168.0.1] Syslog destination [10.0.30.243] UTC Date and time [2011-03-16 19:56:28] UTC Timezone [-05:00] Smtp relay [10.0.30.242:25] Smtp recipients [support@mydomain] Smtp sender [LinkLB@mydomain] License [CC70FA92F626D449A65BBCB090F29B9E] Accept these values and apply changes, [y]es/[n]o/[a]bort [y]: y Save basic system configuration in FLASH and reload to apply new license, [y]es/[n]o [y]: y Reloading...
After you have configured these values and saved them in system configuration flash memory, the system will reload. If you were connected via a SSH access, the session will be closed during the reload and you must start a new session to the new management IP address (if changed). Once the system has reloaded, you will be prompted to login to the Elfiq Link Balancer command line interface.
login as: mgmt mgmt@192.168.0.200's password: THIS SOFTWARE IS SUBJECT TO TERMS OF ELFIQ OPERATING SYSTEM (EOS) END USER LICENSE AGREEMENT. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ELFIQ NETWORKS (ELFIQ INC.) OR ITS SUPPLIERS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
20/160
Copyright 2004-2008
Elfiq Networks (Elfiq Inc.) Support: support@elfiq.com
Website: www.elfiq.com License status: key ok LinkLB-mgmt: [single] #
IMPORTANT: It is recommended that you verify the license status is OK and test the network connection to the management LAN. NOTE: The system module initial configuration can be made through the graphical user interface. After the system has reloaded and you have logged in enabled mode, you can see the new system configuration with the sh conf command.
LinkLB-mgmt: [single] #ena Password: LinkLB-enable: [single] #sh conf # ================================================================ # # E L F I Q N E T W O R K S (www.elfiq.com) # # ================================================================ ## syst ## EOS Version [3.3.0] ## Loadopt (boot time options) set loadopt vmgmt disable ## Snmp snmp sysname Elfiq1 snmp sysdescr Elfiq system snmp syslocation Elfiq Networks. Montreal, Canada snmp syscontact support@elfiq.com snmp acl 0.0.0.0/0 snmp community public snmp disable ## System settings set utc timezone -00:00 set mgmtip 192.168.0.200 255.255.255.0 192.168.0.255 set hostname LinkLB set logging 10.0.30.243 ## HTTP service http enable ## SMTP messaging clr smtp smtp disable clr smtp suppress ## Network interfaces set int eth1 auto set int eth2 auto set int eth3 auto set int eth0 auto ## Generated: Feb 04 16:36:22 ## vfi0 ## EOS Version [3.3.0] ## ( vfi0 ) clr all ## Description description Not defined ## !! WARNING: no inside interface attached ## !! WARNING: no outside interface attached ## Generated: Feb 04 16:36:22 LinkLB-enable: [single] #
21/160
Your configuration is saved in flash as the default configuration, default.cfg. If you want to restart the setup, you must delete the configuration from flash memory and reload your Elfiq Link Balancer. This will enable you to go through the setup phase again, and enter the proper values.
LinkLB-enable: [single] #syst LinkLB-enable:system [single] #flashls Filesystem Size Used Avail Use% Mounted on /dev/hda3 4.0M 23K 4.0M 1% /mnt/flash3 Configuration on Flash: default.cfg 8.5K Feb 4 16:30 LinkLB-enable:system [single] #flashrm default.cfg LinkLB-enable:system [single] #reload
3.3.
Change Settings
3.3.1. Set Date and Time
set UTC
To manually set the system date and time of your Elfiq Link Balancer, you need to use the set date and timezone commands, which sets both the date and the time of the system to your local time zone.
The date and time must be the Coordinated Universal Time (UTC). UTC replaced Greenwich Mean Time (GMT) as the basis for the main reference time scale. Time zones around the world can be expressed as positive or negative offsets from UTC. The commands uses the following syntax:
set date [yyyy]-[mm]-[dd] [hh]:[mm]:[ss] set utc timezone [+|-][hh:mm]

For example, in Eastern North America, the UTC time zone is minus 5 hours and current local time is 13:24:35. Setting the time and date would be:
LinkLB-enable:system [single] #set date 2009-02-07 18:24:35 LinkLB-enable:system [single] #set utc timezone -05:00
NOTE: The Link LB uses the standard international format for date and time settings (YYYY-MM-DD HH:MM:SS). Adjusted date and time can be verified with the
sh sys command.
LinkLB-enable:system [single] #sh sys Hostname [LinkLB] Uptime [0.026 Hours] UTC Date/Time/Zone [2009-02-07] [18:24:50] Local Date/Time/Zone [2009-02-07] [13:24:50] [UTC -05:00] Logging [10.0.30.243] Default Gateway [192.168.0.1] Management IP [192.168.0.200] Management Netmask [255.255.255.0] Management Broadcast [192.168.0.255] LinkLB-enable:system [single] #
3.3.2.
Set Local Time Zone
Daylight saving time (DST) is the convention of advancing clocks typically forward one hour near the start of spring and backward in autumn. It is typically observed in the Northern Hemisphere. The Link LB system clock can be adjusted to match DST using the set utc time zone command.
22/160
Setting the local time zone replaces the previously mentioned manual method for setting the UTC offset. Also, daylight savings time (DST) will be followed if the local time zone is set. This can be done with the set timezone command, using the following syntax:
set timezone [zone]

LinkLB-enable:system [single] # set timezone US/Eastern
The list of available time zones can be viewed with the
sh timezone command.
3.3.3.
Set a Network Time Protocol (NTP) Server
Setting a network time protocol (NTP) server is an alternative to setting the date and time manually. The Link LB will check the current date and time at a configurable interval to ensure that its clock is set correctly. The command is ntp server command and the proper syntax is as follows:
ntp server [ip address] [refresh interval (hours)]

Additionaly, the internal NTP client must be enabled:
ntp [enable|disable]
LinkLB-enable:system [single] # ntp server 10.200.25.10 12 LinkLB-enable:system [single] # ntp enable
NOTE: It is recommended to use an NTP server in order to ensure that timestamps on event logs are synchronized with that of other devices on the network.
3.3.4.
Set the IP Address
To change the management IP, you need to use the set mgmtip command. The netmask and broadcast addresses need to be set with this command. The proper syntax is the following:
set mgmtip [ip address] [netmask] [broadcast] | [ip address]/[netmaskbits] [gateway]

LinkLB-enable:system [single] #set mgmtip 10.200.25.10 255.255.255.0 10.200.25.255
3.3.5.
set gateway [ip]
Set the Default Gateway

gateway command, using the following syntax:
The default gateway of the management interface is set with the set
LinkLB-enable:system [single] #set gateway 10.200.25.1
NOTE: To disable the use of a default gateway, you can enter the IP address 0.0.0.0
3.3.6.
Set IP Address and Default Gateway Simultaneously

set mgmtip, using the
To change both the IP address and the default gateway at the same time with the command following syntax:
23/160
set mgmtip [ip address] [netmask] [broadcast] | [ip address]/[netmaskbits] [gateway]

LinkLB-enable:system [single] # set mgmtip 10.200.25.10/24 10.200.25.1
3.3.7.
Set the Hostname

set hostname command, using the following
The hostname of your Elfiq Link Balancer can be modified with the syntax:
set hostname [name]

LinkLB-enable:system [single] #set hostname test
NOTE: Hostname change will not be displayed in the command prompt until the command line interface has been exited.
3.3.8.
Set SYSLOG Server Information
Since the Elfiq Link Balancer runs entirely in RAM, log messages should be sent to a remote host, also known as a syslog server if you wish to keep then through reboots. If you have no syslog server in your network infrastructure and want to disable remote logging, specify the term disabled. Use the set
logging command to configure the address of the log server with the following syntax:
set logging [ip]

LinkLB-enable:system [single] #set logging 192.168.200.137
LinkLB-enable:system [single] #set logging disabled
For a list of syslog system messages, please refer to Appendix B. The system module also logs important events in memory. They can be accessed with the
sh log event command.
3.3.9.
Set Ethernet Network Port Speed and Duplex

set
The Elfiq Link Balancer allows you to set the speed and duplex settings of all physical network ports through the int command. Here is the command syntax:
set int [port] [auto]|[[10|100|1000|10000] [full|half]]

The network port settings can be automatically negotiated with the auto parameter, which is the default setting. Alternatively, you can force the network speed at 10, 100 or 1000 mbps, with the respective 10, 100 or 1000 values and duplex settings at either half duplex or full duplex, with half or full settings respectively. To set a port to automatic negotiation:
LinkLB-enable:system [single] #set int eth0 auto
To force a port to 10 mbps, half duplex:

LinkLB-enable:system [single] #set int eth0 10 half
To force an port to 100 mbps, full duplex:

LinkLB-enable:system [single] #set int eth0 100 full
24/160
3.3.10.
802.1q (for use with VLANs) Ethernet Bonding USB Mobile Stick Ethernet point-to-point
Create Dynamic Network Interfaces
It is possible to attach an interface that is not Ethernet. Here are the different types of interfaces that can be used:
It is necessary to create a Dynamic Network Interface prior to integrating into the VFI configuration. The proper syntax is the following:
dyn int [id] [description] [interface(s)|hardware model] [options]

[iftype]
[vlan
id|instance]
The iftype parameter is used to indicate the interface type. The possible values are: dot1q for defining a VLAN within the trunk that will be created ethernet-bonding to use ports in aggregation mode usb-cellular for USB cellular devices ethernet-ppp for Ethernet point-to-point, for use with PPPoE links
A configuration example for a 802.1q trunk interface:

LinkLB-enable:system [single] #dyn int 1 vlan_100_on_eth2 dot1q 100 eth2 LinkLB-enable:system [single] #sh conf ## Dynamic network interfaces dyn int 1 vlan_100_on_eth2 dot1q 100 eth2
A configuration example for Ethernet bonding:

LinkLB-enable:system [single] #dyn int 2 bonded ethernet-bonding 2 eth6,eth7 backup LinkLB-enable:system [single] #sh conf ## Dynamic network interfaces dyn int 3 3g_Internet usb-cellular 3 E182E imei:123456789123456 dyn int usb-cellular apn 3 internet.3gwireless.com
A configuration example for a USB Mobile Stick:

LinkLB-enable:system [single] #dyn int 3 3g_Internet usb-cellular 3 E182E imei:123456789123456 LinkLB-enable:system [single] #dyn int usb-cellular apn 3 internet.3gwireless.com LinkLB-enable:system [single] #dyn int usb-cellular pin 3 1111 LinkLB-enable:system [single] #sh conf ## Dynamic network interfaces dyn int 3 3g_Internet usb-cellular 3 E182E imei:123456789123456 dyn int usb-cellular pin 3 1111 dyn int usb-cellular apn 3 internet.3gwireless.com
A configuration example for an Ethernet point-to-point:

LinkLB-enable:system [single] #dyn int 4 pointtopoint ethernet-ppp 30 eth4 LinkLB-enable:system [single] #sh conf ## Dynamic network interfaces dyn int 4 eos_generator ethernet-ppp 30 eth4
3.3.11.
Set a Virtual Management (VMGMT) Interface
An Link LBs dedicated management port may be converted to a link balancing interface if needed. Once this conversion takes place, that port becomes available for use within a VFI module as an inside or outside interface. The management ports mode is shown in the SYST module configuration:
LinkLB-enable:system [single] #sh conf ##
25/160
syst ## EOS Version [3.4.3] ## Loadopt (boot time options) set loadopt vmgmt disable
By default, vmgmt (which means Virtual Management) is disabled. While disabled, the management interface is dedicated and can be reached by conventional means. To turn on vmgmt, you must issue the following command while in ena mode in the SYST module:
set loadopt vmgmt enable

Then, it is important to save the configuration:
saveall
Finally, a reboot is required for the management port to be released.
reload
When the Link LB comes back up, a new interface will be available:
LinkLB-enable:system [single] #sh int Name[eth0 (MGMT)] Status[Non applicable] Supported Link Modes[Not available] Extended Link Status[No extended link status available] Hardware Address[0:14:b7:0:26:5d] IP Address[10.1.0.100] Network Mask[255.255.255.0 or /24] Name[eth1] Status[UP] Line Protocol[UP] Supported Link Modes[10 Half/Full, 100 Half/Full] Extended Link Status[Negotiated, 100baseT, Full-duplex] Hardware Address[0:14:b7:0:26:5e] Name[eth2] Status[UP] Line Protocol[UP] Supported Link Modes[10 Half/Full, 100 Half/Full] Extended Link Status[Negotiated, 100baseT, Full-duplex] Hardware Address[0:14:b7:0:26:5f] IP Address[194.204.1.3] Network Mask[255.255.255.255 or /32] Bypass Group[1] Bypass Pair[eth2/eth3] Bypass Type[Hardware] Bypass Status[enable] Name[eth3] Status[UP] Line Protocol[UP] Supported Link Modes[10 Half/Full, 100 Half/Full] Extended Link Status[Negotiated, 100baseT, Full-duplex] Hardware Address[0:14:b7:0:26:60] Bypass Group[1] Bypass Pair[eth2/eth3] Bypass Type[Hardware] Bypass Status[enable] Name[eth4] Status[UP] Line Protocol[UP] Supported Link Modes[10 Half/Full, 100 Half/Full] Extended Link Status[Negotiated, 100baseT, Full-duplex] Hardware Address[0:14:b7:0:26:5d]
Note that once this change has been made, the only way to communicate with the Link LB will be the console port or Inline Access, which is designed for access from outside the network infrastructure where the Link LB is installed. This change may be reversed by simply issuying this command while in ena mode in the SYST module:
set loadopt vmgmt disable

Once again, it is important to save the configuration:
saveall
A reboot is required for the management port to be once again dedicated.
reload
3.3.12.
Set LAN Bypass Ports
Elfiq LAN Failsafe technology allows IP packets to pass through a pair of LAN bypass ports in case of failure or if the unit is powered off.
26/160
If your Elfiq Link Balancer model supports software programmable lan bypass Ethernet ports, the system module configuration can specify if the pair of LAN bypass ports are activated or not during a power failure. A Link LB can have multiple pairs of LAN bypass ports and each group configurable. The following commands allow the configuration of LAN bypass ports:
set bypass failure action [failsafe|reload]

Define lan bypass failure action
set bypass group1 [enable|disable] set bypass group2 [enable|disable] set bypass group3 [enable|disable]
Activate/desactivate lan bypass group The LAN bypass configuration can be displayed with the
LinkLB-enable:system [single] #sh bypass bypass failure action [failsafe] bypass group1 [disable] bypass group2 [disable] bypass group3 [disable]
sh bypass command.
It can also be reviewed in the system module configuration in the bypass options section.
## Bypass options ## Bypass group1 (eth2/eth3) ## Bypass group2 (eth4/eth5) ## Bypass group3 (eth6/eth7) set bypass failure action failsafe set bypass group1 enable set bypass group2 disable set bypass group3 disable
NOTE: The available bypass failure actions, the number of bypass groups and the associated physical Ethernet ports (ethx) are specific to your Elfiq Link Balancer model. NOTE: In a hardware redundancy installation with two units in failover, lan bypass ports must be deactivated (or not both ports used) to ensure the master unit traffic is not bypassed by the second unit being powered off.
3.3.13.
Change the LCD Display Mode

set lcd
For Elfiq Link LB equipped with an LCD display, it is possible to change the information displayed with command and the display type number:
set lcd [type id]

LinkLB-enable:system [single] #set lcd 5
Available LCD display types are: Display Type ID 01 02 Displayed Information Hostname Management IP address Status Management IP address Example LinkLB 192.168.0.200 Single 192.168.0.200
27/160
03
04
05 06
Status Management IP address Last log event ID Status Management IP address (last 3 digits) Last log event ID Hostname Last log event ID Status Hostname Last log event ID For all connections: Total incoming throughput Total outgoing throughput
SI 192.168.0.200 I-VFI0-020705 SI .100 I-VFI0-009001 LAB_TEST_LB3000 I-VFI-009001 SI_LAB_TEST_LB30 I-VFI0-009001 In 0 Kb/s Out 0 Kb/s
07
NOTE: Possible status messages are Single (SI), Master (MA) and Slave (SL).
3.4.
Change Services
3.4.1. HTTP/HTTPS Service
The web-based Elfiq Link Balancer Management interface can be used over HTTP or HTTPS. This is configured with the following commands:
http [enable|disable] https [enable|disable]

HTTP is enabled by default. HTTP and HTTPS can be enabled independently.
3.4.2.
SNMP Configuration
SNMP support for the Elfiq Link Balancer is also configured through the syst module. From here, you can enable or disable SNMP support, as well as configure all of its parameters. SNMP support is disabled by default in the Elfiq Link Balancer.
## SNMP snmp sysname Elfiq1 snmp sysdescr Elfiq system snmp syslocation Elfiq Networks. Montreal, Canada snmp syscontact support@elfiq.com snmp acl 0.0.0.0/0 snmp community public snmp notification 192.168.202.137:162 snmp enable
To control the SNMP service, use the snmp command with the following syntax:
snmp [enable|disable|refresh]
You can enable the snmp service with snmp enable and disable it with snmp disable. If you need to refresh the settings after modifying them, you can do so with snmp refresh to restart the snmp service with new parameters. The following commands allow the configuration of SNMP parameters:
28/160
snmp acl [network]/[netmask-bits]

query the snmp service.
Set the IP network mask of the systems that will be allowed to
snmp community [string]
Set the community string for the snmp service.
snmp notification [ip address:port,...] Configure up to four remote monitoring servers, IP

address and port to which SNMP notifications (traps) can be sent.
snmp syscontact [person to contact] snmp syslocation [physical location] snmp sysname [system name]
Set the name of the person to contact for this system.
snmp sysdescr [system description] Set the description of the system.

Set the location of the system. Set the name of the system. Set the
snmp user [username] [md5|sha] [password] [aes] [passphrase]

securityName used for authenticated SNMPv3 messages.
snmp [enable|disable|refresh] Activate/deactivate snmpv3 service.
NOTE: The standard SNMP trap port on the remote monitoring server is UDP 162. This is where the Link LB would send its SNMP notifications. NOTE: The default SNMP port on the Link LB is UDP 161. Remote monitoring platforms would connect to this port on the Link LB. This setting is not configurable.
3.4.3.
SMTP Alert Service
The email alerts provides notification of important event via a SMTP service. Problems or states from your Elfiq Link Balancer are periodically sent as notifications in a message. This notification allows you to be informed of problems that may have been encountered, along with their error code and a brief description. Refer to section 6.2 for a list of message codes. SMTP support is disabled by default in the Elfiq Link Balancer. To enable the SMTP service, use the with the following syntax:
smtp command
smtp [enable|disable]
You can enable the smtp service with smtp
enable and disable it with smtp disable.
The following commands allow the configuration of SMTP parameters:
smtp relay [ip address:port,...] Set the IP address of the mail relay server. Default SMTP port is
25.
smtp sender [username@domain.name] Set mail sender for smtp service. smtp recipient [username@domain.name,...]
who will receive SMTP email alert messages. Set the email addresses (up to four recipients)
smtp timer [timer in seconds] Set the minimum delay between SMTP email alert messages are sent
to the relay. Multiple events within the timer delay are sent in a single email message.
smtp severity [1 - 4]
(Alert), 2 (Warning), 3 (Notice), 4 (Info)
Set the threshold severity level of events being sent via the SMTP service: 1
29/160
smtp allow [message id]

encompass the specified message ID.
Allow a message to be sent via SMTP, even if the severity threshold does not
smtp suppress [message id]
Prevent a specified message to be sent via smtp. Enter one smtp suppress command per message id to suppress. The message id is the unique log event numerical identification number. NOTE: The required commands to send SMTP alerts are:
smtp enable, smtp relay and smtp
recipient.
LinkLB-enable:[single] #syst LinkLB-enable:system [single] LinkLB-enable:system [single] LinkLB-enable:system [single] LinkLB-enable:system [single] LinkLB-enable:system [single] LinkLB-enable:system [single] LinkLB-enable:system [single] #smtp #smtp #smtp #smtp #smtp #smtp #smtp relay 10.0.30.238:25 sender LinkLB@domainname recipient heldesk@domainname timer 60 severity 2 suppress 020006 enable
The example below is a sample Email notification sent by the Link LB:
FROM : LinkLB@domainname [mailto: LinkLB@domainname] TO : heldesk@domainname Subject : Elfiq Link Balancer notification Oct 19 02:56:23 I-VFI0-020200 1 TCP probe failure threshold met for gmac3 [link to 1st provider], disabled [link down] Automatically sent by Elfiq Link Balancer, don't reply
WARNING: Default SMTP severity level is 3 which can generate many email alerts. Elfiq recommends setting it to level 1 as soon as your links are configured and tested.
LinkLB-enable:system [single] #smtp severity 1 LinkLB-enable:system [single] #sh smtp relay0 [10.0.30.238:25] sender [LinkLB@domainname] recipient [heldesk@domainname] timer [60] severity [1] LinkLB-enable:system [single] #
It is possible to have the Link LB send alerts that have a lower severity level than the configured limit. If the global limit is set to 1 but it is required to receive alerts pertaining to possible network loops, which are severity level 2 messages, a set of exceptions can be set. Please refer to section 6.2 for a complete list of alerts and their identifiers.
## SMTP messaging smtp relay 10.0.30.238:25 smtp sender LinkLB@mydomain.com smtp recipient heldesk@domainname smtp severity 1 smtp enable clr smtp suppress clr smtp allow smtp allow 020002 smtp allow 020001
3.5.
Display System Information
The Elfiq Link Balancer also provides commands to display key system information, such as EOS version and license, log events and system status.
30/160
3.5.1.
EOS Version and License
The sh ver command displays the current EOS firmware version. This lists information on the major and minor versions, and release point of your EOS, along with the date at which it was released by Elfiq. It will also display the type of EOS that you are running, which defines what features are available with it along with the hardware model. This information is very important to have in hand in case of any support request.
LinkLB-enable:system [single] #sh ver Version [3] Revision [3] Build [0 (9)] Date [Jan 27 2009] HW Model [LB500] Type [LinkLB-AX-VFI1-EXT] Compiled By [eosmaker1@elfiq.com Prod]
The
sh license command displays the license information and status.
LinkLB-enable:system [single] #sh license Key[CC70FA92F626D449A65BBCB090F29B9E] Description[LinkLB-AX-VFI1-EXT] Hw Model[LB500] Version[3] Status[key ok] Serial[S74E61040B00039]
WARNING: An invalid license means that VFI and FOVE modules are not activated.
3.5.2.
System Module Information and Environment Metrics
The sh sys and sh env commands display important information like system date/time, uptime, management interface IP configuration, CPU usage and memory usage. Some model specific information can also be displayed like the fan speeds and CPU temperature.
LinkLB-enable:system [single] #sh sys Hostname [LinkLB] Uptime [1171.849 Hours] UTC Date/Time [2011-03-11] [15:54:22] Local Date/Time [2011-03-11] [10:54:22] Local Zone [US/Eastern] [DST: off] [EST] Local Zone UTC conversion [UTC -05:00] Logging [192.168.0.100] Default Gateway [192.168.0.1] Management IP [192.168.0.200] Management Netmask [255.255.255.0] Management Broadcast [192.168.0.255] Syslog Service [enabled] Http Service [enabled] Smtp Service [enabled] Snmp Service [enabled] Ntp Service [enabled] shHostname [LinkLB] Uptime [0.219 Hours] UTC Date/Time/Zone [2009-02-07] [18:56:04] Local Date/Time/Zone [2009-02-07] [13:56:04] [UTC -05:00] Logging [10.0.30.243] Default Gateway [192.168.0.1] Management IP [192.168.0.200] Management Netmask [255.255.255.0] Management Broadcast [192.168.0.255] LinkLB-enable:system [single] #sh env CPU Usage [6.0 %] CPU Usage Average [4.6 %] Memory Usage [87 MB / 115 MB] CPU Usage [11.4 %] Memory Usage [63 MB / 115 MB]
31/160
3.5.3.
System Log Events
All modules log events are centralized in the system log events. It is very important to always consult the log events for troubleshooting/diagnostic purposes or simply verifying the unit good operation. The sh log event returns events in the following format: Date and time Module Event number - Severity level Event description Severity levels are: 1: Alert (A) 2: Warning (W) 3: Notice (N) 4: Information (I or Info)
LinkLB-mgmt:system [single] #sh log Feb 25 14:41:41 I-EOS2-007001 Feb 25 14:41:41 W-EOS2-006100 Feb 25 14:41:41 W-EOS2-006101 Feb 25 14:41:43 I-VFI0-020702 Feb 25 14:41:45 A-SYST-004001 Feb 25 14:41:47 N-BNET-000162 Feb 25 14:41:51 I-VFI0-020601 Feb 25 14:41:51 I-VFI0-020600 Feb 25 14:41:51 I-VFI0-020602 Feb 25 14:41:54 I-VFI0-020703 Feb 25 14:41:54 A-VFI0-020705 Feb 25 14:41:58 W-VFI0-020201 Feb 25 14:41:59 N-VFI0-009001 Feb 25 14:42:24 A-VFI0-009004 (N) Feb 25 14:42:24 A-VFI0-009003 event 4 (Info) Restoring system configuration from flash 2 (Warning) Flash2ram, start 2 (Warning) Flash2ram, done 4 (Info) VFI ready, initial status [running] 1 (Alert) Elfiq Operating System (EOS) loaded/initialized 3 (Notice) Api service ready 4 (Info) Acquiring VFI reconfig state 4 (Info) Clearing all VFI configuration 4 (Info) Releasing VFI reconfig state 4 (Info) Outside interface [eth2], carrier ok, [interface up] 1 (Alert) Inside interface [eth1], carrier ok, [interface up] 2 (Warning) TCP probe OK for gmac2 [test], enabled [link up] 3 (Notice) TCP probe[1] timeout for gmac2 [test], tcpprobe [20.0.0.2:22] 1 (Alert) Verification of gmac1 [test] failed, disabled [link down] 1 (Alert) Verification of gmac2 [test] successfull, enabled [link up]
NOTE: The (N) at the beginning of the event indicates that the event is new and awaiting verification by the SMTP subsystem to be sent or not via an email alert. For a list of system log events, please refer to Appendix B.
3.6.
Manage User Access

3.6.1. First Log In with the Management User
In order to log into your Elfiq Link Balancer, you will need a valid username and password. The default user, mgmt, allows you to get into the system and view the status of the links and the configuration for each module. No sensitive information such as passwords can be viewed when logged in with the mgmt user, nor can any changes can be performed.
login as: mgmt mgmt@10.1.0.100's password: ****
IMPORTANT: The default password for mgmt mode is mgmt. Once logged in, you will see the Elfiq Operating System (EOS) End User License Agreement, the license status and the command prompt.
THIS SOFTWARE IS SUBJECT TO TERMS OF ELFIQ OPERATING SYSTEM (EOS) END USER LICENSE AGREEMENT. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL ELFIQ NETWORKS (ELFIQ INC.) OR ITS SUPPLIERS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
32/160
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright 2004-2011 Elfiq Networks (Elfiq Inc.) Website: www.elfiq.com Support: support@elfiq.com License status: key invalid LinkLB-mgmt: [** License missing **] #
NOTE: When connecting to an unconfigured unit for the first time, it is normal that your license status is invalid and that you are not able to issue commands in the VFI and FOVE modules. NOTE: When a syslog server is properly configured, all authentication attempts are logged through the syslog for auditing purposes.
3.6.2.
Set the Enable Mode
In order to display all possible configuration values, including sensitive information, as well as to make changes to the configuration, you will need to increase your security privileges. IMPORTANT: The default password for enable mode is mgmt, the same as the default mgmt user password. Command syntax: In order to go into privileged mode, you first have to be logged in with the mgmt user. Then, issue the enable command (or ena for the abbreviated command), which will prompt you for a password.
LinkLB-mgmt: [single] #enable Password: LinkLB-01-enable: [single] #
Please be sure to change this password as soon as possible to ensure a higher level of security on your Elfiq Link Balancer. This can be done with the passwd command while logged in enable mode. To exit enable mode, simply type the exit command.
LinkLB-enable: [single] #exit exit LinkLB-mgmt: [single] #
3.6.3.
Change the Management User Password
A password change can only be performed by and for the currently logged user. To change the management user password, simply issue the command while logged in with the mgmt user and inside the system module. It will prompt you for your current password, and then ask you to enter the new password twice. Command syntax: passwd
LinkLB-mgmt:system [single] #passwd Changing password for user mgmt Changing password for mgmt (current) UNIX password: New password: Retype new password: passwd: all authentication tokens updated successfully. LinkLB-mgmt:system [single] #
To save the new password, you will need to type the saveall command as a user with high privileged rights.
LinkLB-enable: [single] #saveall Generating [syst] configuration
33/160
Generating [vfi0] configuration Writing to flash... Configuration for all modules saved LinkLB-mgmt: [single] #
3.6.4.
Change the Enable User Password
The procedure to change the enable user password is exactly the same as with the mgmt user, except that you have to do it while logged with the enable user. NOTE: The enable user cannot change the password for the mgmt user.
3.6.5.
Define Users and Assign to Security Groups
It is possible to define users and assign them to different security groups. These users are independent from the usual mgmt and enable users. Once new custom users are created, you can log in the Link LB using your own username and password. The mgmt and enable users are always active and available to ensure a last resort access; they cannot be disabled by configuration so please choose those passwords wisely. Users can be managed both from the web interface using the User management wizard or the Command-Line interface in the system module Command syntax:
LinkLB-enable: [single] #user test eos_enable LinkLB-enable:[single]#sh user Username[test] Group[eos_enable] Auth key[none]
NOTE: The default password for any newly created user is mgmt.
3.6.6.
Command syntax: sh
Show All Users
user
LinkLB-enable: [single] #sh user Username[geolink] Group[eos_geolink] Auth key[present:DSA] Username[test] Group[eos_enable] Auth key[none]
NOTE: If you have a firmware with the Geographic balancing option, a user called geolink will automatically be created for the purposes of geolink connections.
3.6.7.
The groups are: eos_read eos_reload eos_eosupdate eos_diagnostic eos_enable eos_geolink
Show All Groups
Right to see statistics and logs. Right to use the reload command. Right to use the eosupdate command. Right to use the status altering commands but not the configuration altering commands. Full rights to the user, configuration creation, modification, destruction. Special group reserved for incoming geolink connections.
Command syntax: sh
group
LinkLB-enable: [single] #sh group Group[eos_read] Username[mgmt] Group[eos_geolink] Username[geolink] Group[eos_reload]
34/160
Group[eos_eosupdate] Group[eos_diagnostic] Group[eos_api] Group[eos_enable] Username[enable] Username[test]
3.6.8.
Command syntax: user
Add/Remove a User to/from a Group
addgroup [username] [group1,group2...]
LinkLB-enable: [single] #user addgroup test eos_reload,eos_eosupdate,eos_diagnostic LinkLB-enable: [single] #sh user Username [test] Group [eos_enable,eos_reload,eos_eosupdate,eos_diagnostic] Authkey[present:DSA]
Command syntax: user
delgroup [username] [group1,group2...]
LinkLB-enable: [single] #user delgroup test eos_reload,eos_eosupdate,eos_diagnostic
3.6.9.
Change a User Password
The procedure to change a user password is exactly the same as with the mgmt user, except that you have to do it while logged as the user.
3.6.10.
Add a DSA Key to a User
It is possible to log into a Link LB via SSH with a certificate as opposed to providing credentials. This is done by setting a DSA key for the user intended to log in this way. The first step would be to generate a key on the host that will be connecting to the Link LB. Here is an example using Ubuntu, a popular Linux distribution:
bob@computer:~$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/bob/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/bob/.ssh/id_dsa. Your public key has been saved in /home/bob/.ssh/id_dsa.pub. bob@computer:~$ cat /home/bob/.ssh/id_dsa.pub ssh-dss AAAAB3NzaC1kc3MAAACBAK4m0nE+rvd2pfhDZIJ4fuMf0C3crFAPmab1YIu4sEGu9QlEM5tjlNkFbvGT8BlMPnVNB21IMiYnfq6U0T4vVXvWZhXm J2g7LSP2YyYAmUFU+Idk2GjWysLEJAEc13J1MsByHugEZ6vtt6ilWwRHF8KXunFyk/HYuRB1/e9C15WFAAAAFQCwJoSZpQCiU4Ciqn6Lid7xsNm3 xQAAAIAGxa+XvFN1E6LXIyYFGmAF9YnVqMR/xDGYj2honyMXZ+zQHruc5+ypGnbgR423ZtoqP/nsMLh/uVdAXxEZtwEwxcCsCCuyRreJOToq8rL/ 1RNLvE8cNr+/LcF6dUyUNX7Qf4LtxVcvPVFHgef9XEVYkPLNC/FCk0110ZRdfMpgXwAAAIB2JyI6K8nCgxZEYlhFBqtkZ36pHDwhqZy0SAAApZ/+ bX3EbQHGDIlcdmGa4Lh9qk/Bc6AQYqOkzO4T8tR1FVgfNS1rRb3hUg5c23psvuyb99wDNQLFRhqGkYPNLMI5gtOvOfngzavovS9E0HcchaeXnaC2 yQI09VAtAnM/rb0MNQ==
The next step is to set the above DSA key under the appropriate existing user in the Link LB. Command syntax: user
key [username] [host] [key]
LinkLB-enable: [single] #user key bob hostname AAAAB3NzaC1kc3MAAACBAK4m0nE+rvd2pfhDZIJ4fuMf0C3crFAPmab1YIu4sEGu9QlEM5tjlNkFbvGT8BlMPnVNB21IMiYnfq6U0T4vVXvWZhXm J2g7LSP2YyYAmUFU+Idk2GjWysLEJAEc13J1MsByHugEZ6vtt6ilWwRHF8KXunFyk/HYuRB1/e9C15WFAAAAFQCwJoSZpQCiU4Ciqn6Lid7xsNm3 xQAAAIAGxa+XvFN1E6LXIyYFGmAF9YnVqMR/xDGYj2honyMXZ+zQHruc5+ypGnbgR423ZtoqP/nsMLh/uVdAXxEZtwEwxcCsCCuyRreJOToq8rL/ 1RNLvE8cNr+/LcF6dUyUNX7Qf4LtxVcvPVFHgef9XEVYkPLNC/FCk0110ZRdfMpgXwAAAIB2JyI6K8nCgxZEYlhFBqtkZ36pHDwhqZy0SAAApZ/+ bX3EbQHGDIlcdmGa4Lh9qk/Bc6AQYqOkzO4T8tR1FVgfNS1rRb3hUg5c23psvuyb99wDNQLFRhqGkYPNLMI5gtOvOfngzavovS9E0HcchaeXnaC2 yQI09VAtAnM/rb0MNQ== LinkLB-enable: [single] #sh user key Username[bob] Group[eos_geolink] Public auth key host[bob@computer] Public auth key type[DSA]
35/160
Public key[ ...BEGIN-KEY... AAAAB3NzaC1kc3MAAACBAIahND/LlJ3GUH8II0D7OSiz+Xp0qEKjOHDRqRUSIjnBGm+BZL/lOT8o26MueewEPFI9VW3qf7urI4hUQwANdPQ8Y6Dw LTY6cNo42bYLAB5XtClwfUtfzfNM0xj8wwOa9X4z1ymXIapyT8mo/r62V3BFhLlVCB0amlV++1QWR57vAAAAFQCcObCQq36egYRTE05Ug5HgNjTs wQAAAIBAWm4/hhRJ7SWS1c0ES9haFJCpkTSxh6ItYezK4/uQm8qZMlicYgc04haq0uDZCFVxeG0Zn7ap94/VTBI8YkypIAd8d2lJXGIXmjvLO4I6 odqrm5CYXlGg0FDnKKUe+Iyf528AceeROC9jYxXAvg8os7YY2e8FcGsgjLTKgKWOKgAAAIAJ/w34iUdFlVBK0IIev8kIPHq3oBFdq4DnfDdfYiAC LAtiF3sqZkpOWdghM7Yri/aai8JhwUk+rP5erb/XZAyrv4zoazmUcgntbOXa0NxDVj7hDmN1SthDd7mbxqw5lE5Y0MeW33QX21QbGuJFVrpcmD2A clC5Md5JHOUYjmL4lA== ...END-KEY... ]
The next step would simply be to connect to the Link LB from the appropriate computer with the appropriate username:
bob@computer:~$ ssh -l bob 10.1.0.100
NOTE: DSA keys are necessary to establish the trust between two Link LBs for geolink establishment. In a geolink setup, the local user that will be used to receive the geolink connection will need to be configured with the DSA key of the geolink user of the remote Link LB.
3.6.11.
Command syntax: sh
Show a User DSA Key
user key
LinkLB-enable: [single] #sh user key Username[user] Group[eos_geolink] Public auth key host[user@unit01] Public auth key type[DSA] Public key[ ...BEGIN-KEY... AAAAB3NzaC1kc3MAAACBANa2mwDBFyRcH1j4a/eOZY7cBXwtXn62U23Fpj6LtRsD5mF1WujgWI/TBe6ZxPrffVDvEGfUVDXStBMpmduNuuQj7XTD CaIU+wTNgN2LtOgUvAlohPM9+SrYRutinP9YFXYIkaEh789ZXiCLWjQctp1WtCvTMqAFCL7cxMrmh6u7AAAAFQC/AoQrU1ool0Tq+dLrbB4ABmBv zQAAAIEA0xXKNAuHQWwedXpHElAfXRHgHW3hfXQD98Qq1MyeVq+M/YPhiu/AyC/bAHTb7xTB+F0D2qH0zWvgiykQN8LaxcWxq+EFg1CihtNVMItE QvZaYk94uQYopHblzdMfhbVyN0aO/IzpJEG8RzMshTKFkN8HGPdOFQdx5k++0kUqfrYAAACAMj14HvhT0a1CvAfMKoO7gmtFjggrfTA8mmoxZnin Ub2ViM/AncvTAXCS96Xg+sOqG7xRvWKomCLkZ4PiW7au1xYfYKkSdLC/FsfOWIMbStxIeIatsONFfmdjmPMjpUC7MFEsF8pUBLRdFPPOS9S+JVaU hjyTQcAGURiLzWWIN2M= ...END-KEY... ]
3.6.12. Lightweight Directory Access Protocol (LDAP) and Active Directory (AD)
LDAP and AD integration makes centralized user and access management easy.
3.6.12.1.
-
Specifications and Group list
To avoid conflict with internal LB users/groups, the EOS will: Automatically increment UID by 2000 to avoid conflict with local user (therefore the UID max limit in the LDAP database is 63000). Automatically increment GID by 2000 to avoid conflict with local groups (therefore the UID max limit in the LDAP database is 63000). HomeDirectory and LoginShell will be overwritten (during connection attempts) with the proper values. Group with a wrong name definition will not be recognized and ignored. mgmt and enable user names are not authorized to be used in LDAP / AD and so will be ignored. eos_geolink and eos_failover group names are not authorized to be used in LDAP / AD and so will be ignored. Home directory of LDAP users will be created with the username_uid. Password types supported are crypt and md5crypt. (AD automatically uses crypt).
NOTE: At the moment, the commands regarding LDAP and AD are not replicated in the FOVE module.
36/160
You will need to create the Elfiq groups in your directory server configuration. Here are the Elfiq groups and a small explanation. In the next section you will see an example on how to configure those groups. eos_read Members of this group will be able to consult the stats and the logs without making changes to the configuration or confidential information in the configuration. Members of this group are able to update the EOS firmware and use its associated wizard and settings. Members of this group can change the configuration of the Elfiq. Members of this group can access certain commands associated to the troubleshooting of the Elfiq. Members of this group can reload the Elfiq.
eos_eosupdate
eos_enable eos_diagnostic eos_reload
NOTE: Other Elfiq groups are not pertinent to the LDAP/AD server configuration. WARNING: User names and group names are case sensitive.
3.6.12.2.
Lightweight Directory Access Protocol (LDAP)
LDAP is an application protocol for directories which is detailed in RFC 4510. The Link LB supports this for user management. LDAP administrators have to create posixGroup entries in its LDAP server (group schema). In each group entry, users are added with their unique memberUid. This feature eases user access to the Link LB while requiring some configuration on the server end.
3.6.12.3.
Active Directory (AD)
Supported version: Microsoft Server 2003/2003 R2/2008/2008 R2 Active Directory is based on LDAP protocol but some attributes are Windows specific. Therefore the Elfiq LB needs to know when it is required to communicate with AD. The Elfiq LB will ask the server for AD specific attributes. On the Windows server, the administrator has to install the SFU (Microsoft's Services for Unix ). Windows Services for UNIX version 3.0 and up is recommended based on your Windows server version. In the latest version of Windows server 2008, it can be called Subsystem for UNIX-based Applications (SUA). When installing SFU/SUA in active directory, the domain administrator will need to configure the UID, GID, Groups, home directory* and login shell* per user (*not required ).
3.6.12.4.
LDAP Server configuration example
The following lines show an example of how to configure a PosixGroup entry: Example of an organisation unit (OU), here it is elfiq.com.
dn: ou=Group,dc=elfiq,dc=com ou: Group objectClass: organizationalUnit objectClass: top
Example of the group you need to create libpam with its associated users. The usernames are fictional.
dn: cn=eos_read,ou=Group,dc=elfiq,dc=com cn: eos_read objectClass: posixGroup objectClass: top gidNumber: 5000 memberUid: alice dn: cn=eos_enable,ou=Group,dc=elfiq,dc=com cn: eos_enable objectClass: posixGroup objectClass: top gidNumber: 5002 memberUid: bob
37/160
dn: cn=eos_diagnostic,ou=Group,dc=elfiq,dc=com cn: eos_diagnostic objectClass: posixGroup objectClass: top gidNumber: 5001 memberUid: roger dn: cn=eos_reload,ou=Group,dc=elfiq,dc=com cn: eos_reload objectClass: posixGroup objectClass: top gidNumber: 5005 memberUid: steve
dn: cn=eos_update,ou=Group,dc=elfiq,dc=com cn: eos_update objectClass: posixGroup objectClass: top gidNumber: 5003 memberUid: celine
The LDAP administrators also have to create posixAccount (people schema) entries in its LDAP server. Exemple of a LDAP posixAccount entry: Here is the People entry definition for elfiq.com
dn: ou=People,dc=elfiq,dc=com ou: People objectClass: organizationalUnit objectClass: top
Here is the user creation example:

dn: cn=eos_read,ou=People,dc=elfiq,dc=com cn: eos_read objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson givenName: Alice sn: Alice uid: Alice uidNumber: 2000 gidNumber: 2000 homeDirectory: /tmp/home/Alice loginShell: /bin/bash
3.6.12.5.
Show the authentication order
Commands
The following commands are used to configure the Link LB with regards to LDAP and AD.
sh auth
Reset the authentication order to the default value: local
clr auth
Set the addresses of the LDAP servers.
ldap server [ipserver1[,ipserver2]]

LinkLB-enable:system [single] #ldap server 10.0.30.252,10.0.30.253
Set the port number of the LDAP server. This command is optional; if no port is specified and SSL encryption is selected, port 636 is used. Otherwise, port 389 is used.
38/160
ldap port [number]

LinkLB-enable:system [single] #ldap port 389
Set the LDAP binding user in distinguished name format. The binding user should have read access to base user and basegroup in the LDAP scheme.
ldap rootdn [rootdn]

LinkLB-enable:system [single] #ldap rootdn cn=admin,ou=managers,dc=mydomain,dc=com
Set the password of the binding user.
ldap secret [password]

LinkLB-enable:system [single] #ldap secret 1234
Set the path in distinguished name format to the container where EOS groups will be searched. This is an optional command.
ldap basegroup [basegroup]

LinkLB-enable:system [single] #ldap basegroup ou=eos_groups,ou=support,ou=it,dc=mydomain,dc=com
Set the path in distinguished name format to the container where EOS users will be searched. This is an optional command.
ldap baseuser [baseuser]

LinkLB-enable:system [single] #ldap baseuser ou=eos_users,ou=support,ou=it,dc=mydomain,dc=com
Set the encryption mechanism to communicate with the server. This is an optional command. If no encryption is specified, tls is used by default.
ldap encryption [encryption]

LinkLB-enable:system [single] #ldap encryption ssl LinkLB-enable:system [single] #ldap encryption tls LinkLB-enable:system [single] #ldap encryption none
Activates LDAP authentication.
ldap enable
Deactivates LDAP authentication.
ldap disable
Display LDAP configuration.
sh ldap server
39/160
Set the addresses of the Active Directory servers.
ad server [ipserver1[,ipserver2]]
LinkLB-enable:system [single] #ad server 10.0.30.252,10.0.30.253
Set the port number of the Active Directory server. This command is optional; if no port is specified and ssl encryption is selected, port 636 is used. Otherwise, port 389 is used.
ad port [number]
LinkLB-enable:system [single] #ad port 389
Set the LDAP binding user in canonical name format. The binding user should have read access to baseuser and basegroup in the Active Directory scheme.
ad user [user]
LinkLB-enable:system [single] #ad user admin@mydomain.com
Set the password of the binding user.
ad secret [password]
LinkLB-enable:system [single] #ad password 1234
Set the path in canonical name format to the container where EOS groups will be searched. This is an optional command.
ad basegroup [basegroup]
LinkLB-enable:system [single] #ad basegroup it/support/eos_groups
Set the path in distinguished name format to the container where EOS users will be searched. This is an optional command.
ad baseuser [baseuser]
LinkLB-enable:system [single] #ad baseuser it/support/eos_users
Set the encryption mechanism to communicate with the server. This is an optional command. If no encryption is specified, tls is used by default.
ad encryption [encryption]
LinkLB-enable:system [single] #ad encryption ssl LinkLB-enable:system [single] #ad encryption tls LinkLB-enable:system [single] #ad encryption none
Activates Active Directory authentication.
ad enable
40/160
Deactivates Active Directory authentication.
ad disable
Display Active Directory configuration.
sh ad server
3.6.13.
Password Reset
If you lose the password of your Elfiq Link Balancer, you can log to the Link LB from the console port with the security user. The system will then automatically reset the passwords of both the mgmt and enable users to their default value and exit back to the login prompt. The security user is only available from the console port. Therefore, you will need physical access to the device, or access to a console access server. IMPORTANT: The password reset process is built into the Link LB as a rescue mechanism and cannot be disabled or changed.
Log In with the Security User Password: security

LinkLB login: security Password: Eos users: mgmt, password success Eos users: enable, password reset success LinkLB login:
3.7.
Manage Configuration Files
The Elfiq Link Balancers configuration is stored on flash memory. The configuration is loaded in RAM when the system initializes. All changes that are performed through the command line interface or the graphical user interface are done on the active configuration, which is stored in RAM. Therefore, the active configuration needs to be written to flash memory to be saved. This type of behavior offers many advantages. Since changes are not automatically saved, any undesired change made can be quickly rolled back by reloading the configuration that was saved on flash. If a major mistake was made, it is also possible to power down the unit and then restart it with the last saved default configuration file. However, this also means that it is really important to save any configuration changes to flash after they have been validated, or else they will be lost the next time the system is restarted. The Link LB also allows you to save more than one configuration on flash using the filename of your choice, but the main configuration file is default.cfg. This default configuration file will always be used during system startup, so make sure to save your desired changes to this default configuration, should you opt to also save it under a different name. Finally, there is also a temporary space in RAM which serves as a buffer between the running configurations and the configuration files stored on flash. Any configuration that is to be saved on flash must first reside in this buffer in the form of a text file. Likewise, any configuration that resides on flash and that you would like to be executed must first be loaded into the buffer.
41/160
There is an independent configuration for every module in the EOS, each of which is expanded in its temporary buffer. Once they have been saved to flash, they are archived as one main configuration. Therefore each configuration file on flash contains the configuration for all of the EOS modules. The econf utility can be used from the command line interface to manually edit the configuration of any module. This makes it possible to restore files from flash, edit any configuration manually as well as validate a configuration before saving it to flash.
Figure 5: Configuration files flowchart
IMPORTANT: The Link LBs running configuration is module dependent. Therefore, any changes that are made in different modules must be saved to flash individually. Example: If you create changes in the syst module and other changes in the vfi module, you need to save the configuration in both modules. Likewise, the configuration that resides in the temporary buffer space is only relevant to the current module.
3.7.1.
Save the Running Configuration of a Module to Flash
To save the running configuration from RAM to flash for a specific module which has been modified, you first need to issue the wconf command into the specified module. This builds and displays a temporary text file into a temporary buffer from the running configuration of the current module in order to edit it or save it later. The wconf can be executed with the right module components, as shown below: Component BROKER FOVE SYST VFI0 Wconf NO YES YES YES
42/160
VFI1 VFI2 VFI3 VFI4
YES YES YES YES
WARNING: Running the wconf command does not save the configuration to flash. It only creates a temporary configuration buffer in a savable format. Once the configuration file has been built in the temporary buffer, you can then save it to flash by executing the ram2flash command into the system module. The ram2flash command will take all temporary configuration buffers (all modules) and save them to the flash memory card to ensure the latest configuration is executed after a reload of the Link LB. Optionally, you can pass an argument to the ram2flash command to save your configuration into a different file then the default, default.cfg. Please be aware that if you do so, you will also need to update the default.cfg configuration file if you want your changes to be effective after a reload, as this is the only configuration file that is read by the system. The option to save to different configuration files is provided as a mean of reference or backup of various configuration options. Below is an example of saving the configuration file after a change in the system module:
LinkLB-enable:system [single] #set hostname NewHostName LinkLB-enable:system [single] #wconf ## syst ## EOS Version [3.3.0] ## Loadopt (boot time options) set loadopt vmgmt disable ## Snmp snmp sysname Elfiq1 snmp sysdescr Elfiq system snmp syslocation Elfiq Networks. Montreal, Canada snmp syscontact support@elfiq.com snmp acl 0.0.0.0/0 snmp community public snmp disable ## System settings set utc timezone -05:00 set mgmtip 192.168.0.200 255.255.255.0 192.168.0.255 set gateway 192.168.0.1 set hostname NewHostName set logging 10.0.30.243 ## HTTP service http enable ## SMTP messaging clr smtp smtp relay 10.0.30.242:25 smtp sender llb01@mydomain smtp recipient helpdesk@mydomain smtp enable clr smtp suppress ## Network interfaces set int eth1 auto set int eth2 auto set int eth3 auto set int eth0 auto ## Generated: Feb 07 13:44:57 ## Configuration written to ram buffer LinkLB-enable:system [single] #ram2flash
IMPORTANT: Each time the ram2flash command is issued, the previous default.cfg configuration file on the flash is renamed to before_ram2flash.cfg. This backup copy allows to rollback the configuration to its previous version.
LinkLB-enable:system [single] #flashls
43/160
Filesystem Size Used Avail Use% Mounted on /dev/hda3 4.0M 32K 4.0M 1% /mnt/flash3 Configuration on Flash: before_ram2flash.cfg 8.5K Feb 7 13:45 default.cfg 8.5K Feb 7 13:45 LinkLB-enable:system [single] #
NOTE: ram2net is a variant of the via a scp2 transfer.
ram2flash command and allows saving the configuration to a remote server
3.7.2. Flash
Save the Running Configuration of all Modules to
In enabled mode, running saveall into any module will automatically generate for each module the configuration in temporary buffers and save the global configuration file default.cfg to flash.
LinkLB-enable:vfi0 [single] #saveall Generating [syst] configuration Generating [vfi0] configuration Writing to flash... Configuration for all modules saved LinkLB-enable:vfi0 [single] #
3.7.3.
Execute a Configuration from Flash
The Elfiq Link Balancer also allows you to execute the configuration that was saved to flash to overwrite the running configuration. This can be especially useful in the case of a rollback, or to change between different configuration files that you could have saved to flash. The first step is to load the configuration file into the temporary buffer. This is achieved by running the ram2flash command. The ram2flash command allows you to restore the saved configuration in flash memory into the temporary buffer. You need to execute a xconf command for every module to execute the configuration. Once again, you can optionally specify a filename as a parameter to flash2ram in order to load a different file then default.cfg. If no arguments are passed, default.cfg will be loaded in the buffer. Afterwards, running xconf into the EOS module you want to execute the configuration from the temporary buffer to the current running module. The xconf command is performed on a per module basis.
3.7.4.
Manually Edit Configuration Files
As mentioned before, any configuration file that is loaded into the temporary buffer can be manually edited with the econf utility in the command line interface. Executing econf will open a text editor with the loaded configuration. IMPORTANT: Editing a configuration does not execute it, nor does it save it to flash. executed to do so. You can do changes directly in a text file format, and after you have to execute for the current module, and system;ram2flash to write the change in flash card.
LinkLB-enable:system [single] #econf GNU nano 1.2.5 ## syst ## EOS Version [3.3.0] ## Loadopt (boot time options) set loadopt vmgmt disable ## Snmp snmp sysname Elfiq1
xconf or ram2flash must be
xconf to execute the new configuration
File: /tmp/config_syst.txt
44/160
snmp sysdescr Elfiq system snmp syslocation Elfiq Networks. Montreal, Canada snmp syscontact support@elfiq.com snmp acl 0.0.0.0/0 snmp community public snmp disable ## System settings set utc timezone -05:00 set mgmtip 192.168.0.200 255.255.255.0 192.168.0.255 set gateway 192.168.0.1 set hostname LinkLB set logging 10.0.30.243 ## HTTP service http enable ## SMTP messaging clr smtp smtp relay 10.0.30.242:25 smtp sender llb01@mydomain smtp recipient helpdesk@mydomain smtp enable clr smtp suppress ## Network interfaces set int eth1 auto set int eth2 auto set int eth3 auto set int eth0 auto ## Generated: Feb 07 13:50:42
^G Get Help ^X Exit
Ô WriteOut ^J Justify
^R Read File ^W Where Is
^Y Prev Page ^V Next Page
[ Read 34 lines ] ^K Cut Text ^C Cur Pos Û UnCut Txt ^T To Spell
Econf command reference:

Here is a list of basic commands that are available inside
econf
[ CTRL + a ] [ CTRL + e ] [ CTRL + v ] [ CTRL + y ] [ CTRL + w ] [ CTRL + d ] [ CTRL + ^ ] [ CTRL + k ] [ CTRL + u ] [ CTRL + o ] [ CTRL + x ]
Move to the beginning of the current line Move to the end of the current line Move forward one page Move backward one page Search for text Delete the current character Begin selecting text Cut current line or selected text Paste selection Save the file Exit econf
45/160
3.7.5.
Manage Configuration Files on Flash
There are two utilities that allow you to manage the different configuration files that are saved on flash, namely flashls and flashrm. flashls will list all the configuration files for the current module, while flashrm allows the removal of saved configuration files.
flashls will also list the usage percentage of the flash drive, allowing you to see how much space is available for
extra configuration files, as well as the date and size of each of the configuration files saved. Once again, this lists the global configurations and not the configurations of each individual module. NOTE: Should you delete the default configuration and reload your Link LB, it will re boot in new configuration mode and therefore will not operate properly.
LinkLB-enable:system [single] #flashls Filesystem Size Used Avail Use% Mounted on /dev/hda3 4.0M 32K 4.0M 1% /mnt/flash3 Configuration on Flash: before_ram2flash.cfg 8.5K Feb 7 13:45 default.cfg 8.5K Feb 7 13:45 LinkLB-enable:system [single] #flashrm before_ram2flash.cfg LinkLB-enable:system [single] #flashls Filesystem Size Used Avail Use% Mounted on /dev/hda3 4.0M 23K 4.0M 1% /mnt/flash3 Configuration on Flash: default.cfg 8.5K Feb 7 13:45 LinkLB-enable:system [single] #
3.8.
EOS Firmware Update
To keep up with fixes or add features to Elfiq Link Balancer, you will need to update the EOS firmware. In order to obtain the latest version of the EOS firmware, please contact the Elfiq support center at support@elfiq.com or register an account at www.elfiq.com/login. WARNING: Before any firmware update, best practices recommend to always do a full backup of the configuration in a text file. The firmware update process is initiated by issuing the Command syntax:
eosupdate command from the SYST module.
eosupdate
1. You will need to supply the following information in order to perform the update: Transfer type: At the moment, the following methods are supported: Secured SCP v2. The access to the remote system needs to be available through password authentication FTP transfer TFTP transfer HTTPS transfer USB port via thumb drive Local disk browsing (web interface only) IP address of the scp2/ftp/tftp/HTTPS server: The IP address of the system where the new EOS image resides. This needs to be a server that can accept SCP v2 protocol, FTP, TFTP or HTTPS connections for file transfer. NOTE: The file transfer portion of the firmware update process will be done through the management interface, unless an Inline Access rule exists for the IP address of the firmware repository.
46/160
Destination port for the scp2 server: The destination port to connect to the scp2 server. Usually SSH port 22. EOS filename: The name of the new EOS image file, including the full path where it resides. Username: The name of the user that will be used to connect to the scp2, FTP, TFTP or HTTPS server.
2. Abort or Accept After entering those values, you have the option to abort the operation, accept the values, or re-enter the values. 3. The Link LB will then connect to the remove server, prompt you for the password of the specified username. If you are prompted to accept the SSH certificate host file during the connection, you need to answer yes, or else the process will be aborted. 4. Before the image is replaced, the Link LB will ask you to confirm the operation. This is the last chance to cancel the operation before the EOS is replaced. 5. After a successful update, you need to reload the Link LB in order to complete the update process. IMPORTANT: After a successful update, the default.cfg configuration file is copied to before_eosupdate.cfg. This backup copy allows a comparison between the configuration before the firmware update and after. WARNING: Units in failover should be updated within the same activity window. Units running a different build (example version 3.3.x and 3.4.x) will not synchronize commands automatically.
LinkLB-enable:system [single] #eosupdate Updating EOS system ------------------Enter Enter Enter Enter Enter transfert type [scp2]: the IP address of the scp2 server [192.168.1.1]: 192.168.30.252 the destination port for the scp2 server [22]: 22 the EOS filename and path [path/eos_image.bin]: /images/eos_link balancer_3.1.56_AX_VFI1-SH-EXT.bin user name [mgmt]: admin
Transfert type [scp2] scp2 server IP:port [192.168.30.252:22] Remote file [/images/eos_link balancer_3.1.56_AX_VFI1-SH-EXT.bin] User [admin] Accept these values [A]bort/[Y]es/[N]o ? y Creating temporary storage... Copying new image to temporary storage... admin@192.168.30.252's password: eos_link balancer_3.1.56_AX_V 88% |************************* Transfert to temporary storage completed. Replacing with new image... Continue [Y]es/[N]o ? y Done. Please reload the system to complete the EOS update. LinkLB-enable:system [single] #reload
6016 KB
00:08 ETA
3.9.
Shutdown or Reload the System
Since the Elfiq Link Balancer operates fully from RAM, you can shutdown the system by using the power or reset switches located at the back of the system without having to worry about doing any damage. This can also be done via the command line interface. To turn off the Link LB, you can execute the halt command, which must be executed in enabled mode. No confirmation is asked, so be careful when issuing this command.
LinkLB-enable:system [single] #halt
47/160
The Link LB can be rebooted immediately when no option is specified after the command or after a delay, stated in minutes. The delayed reboot can be cancelled with the cancel option.
reload [delay in minutes | cancel]

LinkLB-enable:system [single] #reload
LinkLB-enable:system [single] #reload 10 LinkLB-enable:system [single] #reload cancel
NOTE: Only the following commands require to reload the Link LB: eosupdate to perform an EOS firmware update, license to change the license key and loadopt to change the system loading options.
48/160
4. Virtual Forwarder Interface (VFI)

In this section, you will find information about the Virtual Forwarder Interface Module and how to: Initialize the module. Configure all available services GMAC IP Association OLB ILB Advanced balancing options Traffic filtering Geolink SitePathMTPX
4.1.
About Virtual Forwarder Interface
Before getting into the actual link configuration of your Elfiq Link Balancer, let s first take a look at some important concepts to better understand how the Link LB manages them. In order to manage multiple links, the Elfiq Link Balancer relies on a module called the virtual forwarder interface, known as a VFI. A virtual forwarder interface can be defined as a virtual network bridge (data link layer of the OSI model) with additional capabilities, which handle all tasks related to packet balancing by the Link LB. The basic role of the virtual forwarder interface is to forward traffic between two or more interfaces (inside and outside(s)) while providing a fast packet interception service. A VFI consists of a minimum of two physical network Ethernet ports, one of them acting as the inside interface, and the other as the outside interface. The inside interface of a VFI represents the physical Ethernet port or VLAN that is linked with your own network infrastructure. The outside interface represents the physical Ethernet port or VLAN that is linked with the WAN connections, whether it is the Internet, a LAN extension, a private link to another network. A VFI can be configured in different operating modes. The difference between those modes is the number of interfaces used for the outside of the VFI and the usage of VLANs. For example, in monomode, each available Link LB Ethernet port is assigned as an outside interface and is used to redirect traffic to a link. No extra network devices are needed. The Link LB outside interfaces is connected to the link routers. Typically any Ethernet port besides the selected port for the VFI inside and the management interface is available to be configured as an outside interface. Depending of your model, you will have two or more available ports for the VFI outside interfaces.
49/160
Internet
ISP B network ISP A network
Two Elfiq outside interfaces (one per physical port) Virtual Forwarder Interface (VFI) has one inside port and one or multiple outside port(s)
Elfiq inside interface
Client Network
Figure 6: VFI in a monomode setup with 2 links
The available operating modes are: Monomode: One physical port per outside interface/link. Multimode: One physical port is the outside interface and is connected to an unmanaged switch or the untagged VLAN of a switch. All links are connected to the switch. Monomode with VLANs: One physical port is an 802.1q trunk with multiple outside interfaces. A switch supporting VLAN trunking is required. Mixed mode: The primary link is configured in monomode on the LAN Failsafe port. Alternate links are configured in multimode or monomode with VLANs.
Depending of your Elfiq Link LB model and license, your Link LB unit can have multiple instances of the VFI module. Each instance has its index number and referred as vfi0, vfi, vfi2, etc. Each VFI module runs independently has its configuration, inside and outside interfaces.
4.2.
Initial Configuration of Primary Link

4.2.1. Inside and Outside Interfaces
The first step to allow your Elfiq Link Balancer to manage a group of network connections is to configure which of the ethernet ports will be the inside and outside interface(s). To do so, you need to attach available physical ports to the virtual forwarder interface module with the attach in and attach out commands, which have the following syntax:
attach in [interface] attach out [interface, ]
50/160
In the event where an interface which is part of a list is not available to be attached, EOS will partially attach the interfaces that are ready. This will generate a message at the command line. The interface parameter can refer to a physical or a logical interface. Physical interfaces are refered to as ethx for copper Ethernet or sfpx for Single Fibre Port. Logical interfaces, such as for VLANs, USB Mobile Stick or Ethernet Bonding, can also be attached to a VFI. NOTE: Logical interfaces must be created as Dynamic Interfaces (dyn int) in the SYST module prior to attaching to a VFI. NOTE: SFP adapters are offered only on some models. WARNING: VLANs are supported in LB550E and higher models. There can not be more than one network interface attached to the inside of a VFI, but depending of your operating mode, you can have one or more network interfaces attached to the outside of the same VFI. IMPORTANT: When connecting two network devices with an RJ45 patch cable, it is important to verify the cable type to ensure proper connectivity. Here are some general guidelines to follow: Link LB to a switch: Straight Link LB to a device: Crossover A device being: router, cable modem, server, PC, laptop, firewall, etc. Some devices may contain a built-in switch. In that case, you should use a straight cable.
LinkLB-enable:vfi0 [single] #attach in eth3 LinkLB-enable:vfi0 [single] #attach out eth2,eth1
Internet
Alternate link
Primary link
Firewall
Client Network
Figure 7: Ethernet network port selection example in a monomode setup with 2 links
IMPORTANT: In a single unit installation, in order to ensure primary link communication between the firewall and primary link router in case of a unit failure, the inside and primary link outside interfaces are assigned to a group of bypass ports.
51/160
WARNING: In a physical redundancy (failover) installation, both ports in a group of bypass ports must not be used (or must be deactivated via software if this is supported by your Link LB model). The reason is that we do not want to bypass the master unit in case the slave unit is in failure. To configure a VFI in multimode, you will need to attach a single physical interface to the outside interface, like the following example:
LinkLB-enable:vfi0 [single] #attach out eth2 LinkLB-enable:vfi0 [single] #attach in eth3
IMPORTANT: The first device that is included to the outside interface of the VFI with the attach out command becomes the interface that will be used in pass-through mode (also called the multimode outside interface). Packets on the inside interface that are not balanced by any algorithm will be sent on the multimode outside interface. If a VLAN is entered as being an interface, the Link LB will automatically configure the physical port as a trunk in 802.1q standard with the vlan number. VLANs are necessary to isolate links that can not coexist on the same layer 2 network. For example to support multiple DHCP or PPPoE links, each link must be isolated into their own VLAN. The VLAN virtual interfaces will be displayed in the system module with the physical Ethernet ports.
LinkLB-enable:vfi0 [single] #attach out eth1.100,eth1.101,eth2 LinkLB-enable:vfi0 [single] #syst;sh int Name[eth0 (MGMT)] Status[UP] Line Protocol[UP] Supported Link Modes[10 Half/Full, 100 Half/Full] Extended Link Status[Negotiated, 100baseT, Full-duplex] Hardware Address[0:60:e0:e0:de:17] IP Address[10.0.30.96] Network Mask[255.255.255.0 or /24] Name[eth1] Status[UP] Line Protocol[DOWN] Supported Link Modes[10 Half/Full, 100 Half/Full] Extended Link Status[No extended link status available] Hardware Address[0:60:e0:e0:de:1a] Name[eth2] Status[UP] Line Protocol[DOWN] Supported Link Modes[10 Half/Full, 100 Half/Full] Extended Link Status[No extended link status available] Hardware Address[0:60:e0:e0:de:19] Name[eth3] Status[UP] Line Protocol[DOWN] Supported Link Modes[10 Half/Full, 100 Half/Full] Extended Link Status[No extended link status available] Hardware Address[0:60:e0:e0:de:18] Name[eth1.100] Status[UP] Line Protocol[DOWN] Supported Link Modes[Not available] Extended Link Status[802.1Q Vlan 100] Hardware Address[0:50:c2:55:21:1] Name[eth1.101] Status[UP] Line Protocol[DOWN] Supported Link Modes[Not available] Extended Link Status[802.1Q Vlan 101] Hardware Address[0:50:c2:55:21:2]
In a mixed mode operation, one physical Ethernet port is dedicated to the primary link in order to take advantage of the LAN Failsafe support. A second physical Ethernet port is used in multimode for all other links (with or without VLANs). Below you will find a concise table of recommended Ethernet port usage for best practices with different installation and operation modes with a four Ethernet port unit.
Figure 8: Ethernet network ports on a 4-port unit
52/160
Installation
Number of Links 2 3+
Management Port (MGMT) Dedicated Dedicated
Operation Mode Monomode Mixed mode Mixed mode (with VLANs) Monomode
Inside Interface Eth3 Eth3
Single unit Single unit
First Outside Interface Eth2 primary link Eth2 primary link Eth2 primary link
Single unit
3+
Dedicated
Eth3
Single unit
Virtual
Eth3
Eth2 primary link Eth1
Failover units
2+
Dedicated
Multimode
Eth3
Second Outside Interface Eth1 alternate link Eth1 to a switch for all alternate links Eth1 to a switch port in trunk (802.1q) for all VLANs Eth1 alternate link A Eth2 must not be used if bypass port is not deactivated via software Eth2 must not be used if bypass port is not deactivated via software
Third Outside Interface n/a n/a
n/a
Eth4 alternate link B n/a
Failover units
2+
Dedicated
Monomode with VLANs
Eth3
Eth1 configured with VLANs, typically one per link
n/a
Failover units
n/a
Virtual
Not supported, dedicated management ports are required for FOVE module synchronisation
NOTE: Bypass ports are eth2 and eth3 to support LAN Failsafe technology on 4-port models. NOTE: Alternative scenarios are possible especially if your unit has more than four physical Ethernet ports. To deactivate a Virtual Forwarder Interface, you need to detach the interfaces that were previously attached to this VFI. This is done with the detach in and detach out commands. When no parameters are given with the detach commands, all interfaces are detached.
LinkLB-enable:vfi0 [single] #detach in LinkLB-enable:vfi0 [single] #detach out
Detaching interfaces individually is possible by passing the interface name as a parameter to the detach command.
LinkLB-enable:vfi0 [single] #detach out eth1 LinkLB-enable:vfi0 [single] #detach out eth1,eth5
WARNING: Be very careful when running those commands in a production environment, especially if you are working remotely. Detaching all interfaces has the immediate effect of stopping all traffic in the VFI. In the event where it is necessary to replace all interfaces at once, it is recommended that the following method be used to keep risks of downtime to a safe minimum:
LinkLB-enable:vfi0 [single] #detach out; attach out eth2,eth1.100,eth1.101
53/160
4.2.2.
VFI features
The capabilities of the VFI are referred to as features inside the VFI stack. Every packet passing through the VFI module (from the inside to outside interfaces or vice-versa) crosses (or traverses) the VFI stack and the enabled features. Elfiq Link Balancers offer a high level of granularity to enable or disable features in order to reduce the VFI stack and increase performance for heavily loaded environments. Typical NAT traversal time (for a packet to pass through the entire VFI stack) is between 0,05 and 0,15 millisecond. Each VFI feature is a built-in optional service that can be activated or deactivated on demand, according to your network infrastructure needs. Activation or deactivation of a feature can be done in real-time, without altering its configuration. When a feature is disabled, any custom settings remain unchanged, however they will not be taken in consideration until the feature is re-enabled. By default, all the features of a VFI are disabled, since each activated feature has a potential impact on the global performance of the Elfiq Link Balancer. Allowing a customized selection of activated features provides you with the ability to better tune the performance of your Link LB. A master group of features is called the default_balancing_group and can be used to globally enable or disable all its subfeatures. The default balancing group includes a consistent set of features to ensure proper link balancing in almost every implementation using public Internet links and NAT load balancing. Use the
feature command to enable or disable features:
feature [feature] [enable|disable]

LinkLB-enable:vfi0 [single] #feature default_balancing_group enable LinkLB-enable:vfi0 [single] #sh feature Name[default_balancing_group] Status[enable] Name[arp_group] Status[enable] Name[arp_reply_in] Status[enable] Name[arp_reply_out] Status[enable] Name[arp_learn_in] Status[enable] Name[arp_learn_out] Status[enable] Name[gmac_group] Status[enable] Name[gmac] Status[enable] Name[gmac_tcp_probe] Status[enable] Name[gmac_true_traffic] Status[enable] Name[gmac_link_flap] Status[enable] Name[idns_group] Status[enable] Name[idns_in] Status[enable] Name[idns_out] Status[enable] Name[l2_filtering] Status[enable] Name[nat] Status[enable] Name[persistence] Status[enable] Name[probe] Status[enable] Name[acl] Status[disable] Name[acl_ip_unknown_proto_drop] Status[disable] Name[channel] Status[disable] Name[dhcp] Status[disable] Name[pppox] Status[disable] Name[icv] Status[disable] Name[idns_ipv6_block] Status[disable] Name[inline_access] Status[disable] Name[isv] Status[disable] Name[nattp] Status[disable] Name[qos] Status[disable] Name[route_pref_no_acct] Status[disable] Name[route_pref_algo] Status[disable] Name[shun] Status[disable] Name[spath] Status[disable] Name[tag_group] Status[disable] Name[tag_in] Status[disable] Name[tag_out] Status[disable]
54/160
Name[tag_nat_exclusive] Status[disable]
WARNING: Disabling features into the default balancing group must be done with caution and is usually for advanced configurations. Below is a graphical representation of the VFI stack that packets have to go through to cross the Link LB. Since some of these are optional features of the VFI, the following diagram illustrates an example where every module would be enabled. Should one module be disabled, it would simply not pass through it.
55/160
Figure 9: Virtual Forwarder Interface packet flow diagram
56/160
4.2.3.
4.2.3.1.
ARP Requests and MAC Adresses

Devices and Network IP Segments
After configuring the inside and outside interfaces and activating the VFI features, the last step to complete layer 2 passthrough connectivity is to define the different devices and network IP segments that are connected on the inside and outside interfaces of the primary link. This information is required for the Elfiq Link Balancer to define which packets are allowed to passthrough the VFI stack. It must also be configured to prevent network loops with different providers, universal compatibility to all switch manufacturers and support of advanced implementations.
4.2.3.2.
Address Resolution Protocol (ARP) Requests
Its important to understand the close relationship between the Address Resolution Protocol (ARP) table and the rest of the operations before going further into the configuration of the Elfiq Link Balancer. Since the Elfiq Link Balancer integrates at the data link layer (layer 2), it does not directly deal with IP addresses, but physical Ethernet addresses. In order to still be able to manage IP data while keeping its operations at the data link layer, most of the functions of the Link LB will rely on its ARP table for its IP to MAC (or MAC to IP) references. The Link LB needs to maintain a table of MAC addresses associated to either the inside and outside interfaces. You can create static ARP entries or use ACL ARP to map an entire network. We need to specifically add ARP table entries for resources that we want to publish to the outside world. Why? In order to properly forward the traffic to the desired host, the Link LB needs to intercept all ARP requests that will come from the primary link router of your Internet service providers. This means that the Link LB will answer on behalf of the real host, making the router think that the Link LB is, in fact, the host it is trying to reach. Let s take a look at the following flowchart to see how the Link LB does this.
57/160
Internal Network
Firewall Public IP: 194.204.1.3
ISP network
ISPs router IP: 194.204.1.1/25
t: Who has ARP reques 3? 194.204.1.
Is it in ARP table?
Internet
Connection request to 194.204.1.3
No. Try find it on Elfiq inside interface Generate similar ARP request with Elfiq inside MAC address
Yes . Elfi ARP qo r uts eply w ide MA ith C
o Wh st: .3? e u 1 eq 204 . . Pr AR s 194 a h

No. Drop request Is it in ARP table?
Yes . FW ARP r out eply si d e w MA ith C

Add entry to Elfiq ARP table Yes. AR
P reply outside with Elfiq MAC

Add entry to router ARP table e id ts ou fiq
Apply security rules and send traffic to internal network host 194.204.1.3
l MAC c to firewal Route traffi address
Route traffi
c to El MAC
Figure 10: ARP interception flowchart
NOTE: Similar operations are done with the alternate links to forward traffic from associated IP addresses to primary link IP addresses. IMPORTANT: This data layer operation allows, when alternate links are configured with proper load balancing rules, to completely turn off the primary link router. Because of the way the Link LB intercepts and balances the traffic coming from the firewall, the availability of the primary link is not related to the status of the internet access, from the firewall point of view, there is no change in the link state. Traffic to and from the internet will still flow freely with the help of the Link LB. If a connection attempt is made through the alternate ISP links, the Link LB will intercept and process the traffic. Once processed the packets will be delivered to your firewall exactly as-if they came in on the primary link. The Link LB will translate the IP address to the primary link IP address and forward the traffic to the firewall, who will process the packets as if they came from the primary network. This operation is perform at layer 2 and 3 and sessions are not closed and restarted by the Link LB, they simply passthrough it inline. NOTE: The Link LB always replies to ARP requests with its own MAC addresses. If the Link LB is used in a failover environement, the replied MAC address is a special MAC address called VMAC. The defined entry in the ARP or ACL ARP statements are used later as a lookup table when traffic passthrough to recover the initial destination MAC address. In order for this interception to work properly, it is very important to correctly program the ARP configuration of your Link LB, as well as the network address translation (NAT) entries. Lets first take a look at how to manage ARP entries.
58/160
4.2.3.3.
ARP Entries
The Elfiq Link Balancer manages ARP entries at two levels. The first one is a table of static and dynamic ARP entries. A static ARP entry is defined in the configuration and the Link LB always keep and refreshes it in its ARP table. A dynamic ARP entry is learned by the Link LB during its operation and is added to the ARP table. Static entries are actively refreshed on a timer interval. Dynamic entries can be refreshed by the host during normal network transmissions (ARP requests). The second level is an access-list to manage ARP entries for entire IP network segments. Access-lists can be programmed to actively scan an entire range of IP addresses on a timer interval. The ARP verification order follows the following diagram:
Received ARP request
Static / Dynamic ARP entries
MATCH
NOT MATCH
ACL ARP
MATCH
Reply to requestor
Passthrough on inside / primary link
Figure 11: ARP verification order
NOTE: If an ARP verification is unsuccessful, the Link LB will let it passthrough on the inside or multimode interface in order for the ARP request to be resolved. It if is resolved, a new dynamic entry is added to the ARP table.
4.2.3.4.
Static and Dynamic ARP entries
The addition of a static ARP entry inside your Elfiq Link Balancer configuration is done through the arp command, which requires the IP address. It is considered good practice to let the Elfiq LB automatically find the associated MAC address but it can also be entered as a parameter. Its important to specify where the device will reside: inside or outside. Primary link devices are usually connected to the inside interface of the Elfiq Link LB. At the expiration of the specified timeout, the Link LB will refresh the ARP entry by issuing an ARP REQ.
arp [ip address] [mac [inside|outside] [expiration]
address
format
00:00:00:00:00:00|auto]
NOTE: The Elfiq Link LB automatically creates static ARP entries with each link router IP address. The information is taken in the link configuration and no separate arp command has to be entered in the configuration. IMPORTANT: A static ARP entry must be entered for each primary link device connected to the inside interface.
59/160
The IP address that you need to enter is the one of the device behind the Link LB, which should normally be your corporate firewall. The expiration value is in seconds. A static ARP entry must be entered for each primary link device connected to the inside interface. In our example, the Link LB must have a static ARP entry for the firewall IP 194.204.1.3.
LinkLB-enable:vfi0 [single] #arp 194.204.1.3 auto inside 30
What the Link LB learns from the inside interface will be published on the outside and vice-versa. We can see this in the ARP entry table:
sh arp [auto|gmac|outside|inside|static]|[network/netmask-bits]
LinkLB-enable:vfi0 [single] #sh arp IP Address[194.204.1.3] Mac Address[0:d0:b7:5e:78:b0] Type[auto] Expiration[30] Vendor[intel corporation] Learned[inside (eth3)] Published[outside] Aging[27]
The SH ARP statement can also be entered for a specific network segment or arp entry type (auto, static, gmac, inside or outside):
LinkLB-enable:vfi0 [single] #sh arp inside IP Address[194.204.1.3] Mac Address[0:d0:b7:5e:78:b0] Type[auto] Expiration[30] Vendor[intel corporation] Learned[inside (eth3)] Published[outside] Aging[6] IP Address[194.204.1.100] Mac Address[0:d0:b7:5e:78:b0] Type[dynamic] Expiration[14400] Vendor[intel corporation] Learned[inside (eth3)] Published[outside] Aging[213]
LinkLB-enable:vfi0 [single] #sh arp 194.204.1.3/32 IP Address[194.204.1.3] Mac Address[0:d0:b7:5e:78:b0] Type[auto] Expiration[30] Vendor[intel corporation] Learned[inside (eth3)] Published[outside] Aging[9]
To remove ARP entries, the command is no
arp, with the IP address of the entry as a parameter.
no arp [ip address]

As an example, to remove the entry we have just added:
LinkLB-enable:vfi0 [single] #no arp 194.204.1.3
You can also remove all your dynamic ARP table entries with the entries and refresh all the static ones.
clr arp command. This will delete all dynamic ARP
4.2.3.5.
ACL ARP Access Lists
ACL ARP access-lists allow the Elfiq Link Balancer to reply to layer 2 ARP requests for an entire IP segment and allows IP packets to passthrough the VFI module. It is important to redirect all primary link traffic from the router to the firewall mac address while using an ACL ARP command. We can ARP the entire network 194.204.1.0/25 instead of using individual static ARP entries. NOTE: Static and dynamic ARP entries are verified before ACL ARP access-lists. IP packets for primary link devices other than the firewall will still reach destination. NOTE: Other types of access-lists are used in the Elfiq Link LB configuration for filtering, IP association between links and outgoing balancing. To measure the importance of creating an ACL ARP, lets consider this example: You have more than one server in the DMZ zone and NATed by the firewall. In order not to create entries for each one, you will create an ACL ARP entry for the subnet where all the servers will be redirected with one command.
60/160
acl arp [+][ip] [idx] [+|-][target ip]/[netmask-bits] [mac:mac address|fw:ip] [inside|outside]
[+|-][pass|reply]
LinkLB-enable:vfi0 [single] # acl arp +ip 1 +194.204.1.0/25 +reply fw:194.204.1.3 inside LinkLB-enable:vfi0 [single] #sh acl arp Protocol[+ip] Index[1] Target[+194.204.1.0/25] Action[+reply fw:194.204.1.3 inside published outside] Hit Count[0]
The action can be passed or replied. If it is passed, the ARP request is not handled. If the action is to reply, the MAC addresss of the Link LB will be sent as a reply. The keywords inside or outside reflect if the ARP entry is residing on the inside or outside interfaces. If the ARP entry resides on the outside then only requests from the inside can be answered by the rule. And vice-versa. ARP replies are sent to devices identified by their MAC address or IP address. ACL ARP entries can also be used to scan an entire subnet. When configured as such, the Link LB will send ARP requests for each IP in the subnet automatically. Once the subnet is scanned the Link LB will have dynamic entries for every available IP in the subnet. Scanning restarts automatically every 5 minutes. To configure ARP scanning simply create an ACL ARP entry in which the target network is forwarded to an IP address included inside this same target network. If no device is consistently present in that range, you can choose the network IP as the forward IP address. See examples:
LinkLB-enable:vfi0 [single] # acl arp +ip 1 194.204.1.0/25 +reply fw:194.204.1.3 inside
Will enable scanning of the whole 194.204.1.0/25 range as the 194.204.1.3.

LinkLB-enable:vfi0 [single] # acl arp +ip 2 24.201.1.0/24 +reply fw:24.201.1.0 inside
Will enable scanning of the whole 24.201.1.0/24 range.
4.2.4.
Primary Link GMAC
Since the Elfiq Link Balancer operates at the data link layer of the OSI model (layer 2), it needs to know the Ethernet MAC addresses of the external devices it communicates with. Every WAN connection linked to a VFI is represented in the Link LB by a gateway MAC address (or GMAC) entry. In basic scenarios, a configuration has one GMAC per link.
ISP A network
ISP As router IP: 194.204.1.1/25
Client Network
Firewall IP: 194.204.1.3
GMAC 1
Internet
ISP B network
GMAC 2
ISP Bs router
Figure 12: Display of 2 GMACs where a VFI balances 2 ISPs
In other scenarios, multiple GMACs can point to the same router. A typical example is if you have an MPLS router handling both Internet and private traffic, having two GMACs allow different polling mechanisms for both types of traffic. A GMAC entry represents every aspect of the connected link. This includes: Small description: Identify the link associated with the GMAC MAC address of the router: Used to identify the router associated with a given ISP. This tells the Link LB that this MAC address is a valid source from which it can receive packets and to which it can send packets. The MAC address is an important key and must be unique to a GMAC. We usually let the Elfiq LB automatically find the
61/160
associated MAC address but it can also be entered as a parameter. Advanced scenarios can have a parent GMAC (to support same MAC address for two GMACs), a channel GMAC (for inter-VFI communication) and shadow GMAC (replicated GMAC information from a remote site through a Geolink communication between two Link LBs). Refer to advanced sections for more information on those concepts. IP address of the router: This IP address, in conjunction with the MAC address of the router, is used to automatically add a static entry for the router in the ARP table of the Link LB. The addition of this table entry is the key in allowing the Link LB to exchange data between that ISP and your internal network. The IP address, along with the subnet mask is used by the Link LB to tie IP traffic flows with their destination MAC address. Without it, the Link LB would not be able to know which GMAC it should send packets to. If you have more than one IP address range provided by your ISP, the Link LB should know about those networks too. They can be configured separately by associating additional GMAC networks using the gmac net command. Maximum bandwidth for incoming and outgoing traffic: Depending on the chosen balancing algorithm, the bandwidth (speed) of your link can serve as a determining factor in the redirection of the traffic flow. This value is also used during the statistic analysis of the links. Therefore, its important to enter the appropriate value. The bandwidth must be entered in kilobits per seconds, and not in kilobytes. If you are unsure about this value, please be sure to contact your Internet or private link service provider. They will be able to provide you the correct information.
Layer 2 encapsulation delta (or adjustment): This value has been used to adjust the frame size delta between different network technologies, It is now deprecated, simply put zero as value in this field. Weight: Used during the priority selection of the link for balancing protocols. Specify the weight of the link with a value between 1 and 65535. Links with the lowest numerical value have the highest priority. Examples: Weights of equal value: No link is prioritized Weights of 1 and 2: Link with a weight of 1 is favoured Weights of 1, 1, 2 and 100: Links with a weight of 1 are the most favored, link with a weight of 2 is next, and link with a weight of 100 is last in the selection. TCP polling addresses and ports: Used to test the status of the GMAC, as well as calculate the Round Trip Time (RTT). Polling destinations can either be addresses configured directly in the GMAC or groups of addresses. Up to 8 different addresses per polling destination group can be configured to more accurately determine the links condition. The same group can be used for many GMACs at once. Any given GMAC can use only one group at a time. The maximum number of groups per VFI depends on the Link LB model. Should one host stop responding while others still do, then the problem can be attributed to that host instead of the link. A packet is sent to specified hosts in round-robin every 3 seconds and the difference in time between the time the packet was sent and the time the response was received is calculated.
gmac [id] [auto|mac address|chn:id|gmac:id] [description] [ip address]/[netmask-bits]|[dhcp:id|pppox:id] [weight] [speed (kb/s) in] [speed (kb/s) out] [layer 2 adj] [[polldestgrp:id]|[poll ip address]:[tcp port],[poll ip address2]:[tcp port2]] [% threshold in]/[% threshold out]
62/160
Threshold percentages for incoming and outgoing traffic: Used to limit the amount traffic on the link to the specified percentage in a best effort manner. This is especially useful to control link traffic in cases where the monthly price of the link depends on the bandwidth usage. Example: If you have a T1 with a fixed price for a monthly usage of 1 Mbps, but for which the price will increase if your average use was above this rate; you can set the threshold for this link at 66%. This will make the Link LB limit the use of this link to 66% of the capacity of your T1, which is about 1Mbps. Threshold are also useful in algorithms to use specific links after the threshold is met on some other links.
You are now able to add the primary link GMAC entry that Elfiq Link Balancer will manage with the gmac command, which has the following syntax:
gmac [id] [auto|mac address|chn:id|gmac:id] [description] [ip address]/[netmask-bits]|[dhcp:id|pppox:id] [weight] [speed (kb/s) in] [speed (kb/s) out] [layer 2 adj] [poll ip address]:[tcp port],[poll ip address2]:[tcp port2] [% threshold in]/[% threshold out]
Lets take a look at how we would configure the primary link on the Link LB, assuming we have a T1 link and want a threshold of 1 Mbps:
LinkLB-enable:vfi0 [single] # gmac 1 auto Primary_Link_T1 194.204.1.1/25 1 1544 1544 0 0.0.0.0:0,0.0.0.0:0 66/66
NOTE: When you specify the AUTO parameter, the Link LB will discover the MAC address of the link router automatically and update it in case the router NIC card is replaced. NOTE: If the first TCP destination probe is 0.0.0.0:0, the TCP polling will be disabled so the GMAC will always be up and RTT values will remain at zero. NOTE: Another way to restrict link traffic is to create a QoS queue for the GMAC and activate the QoS module. WARNING: The TCP polling addresses and ports must be adjusted in your configuration for dependable destinations. By default, the GMAC is assigned to the first outside interface of the VFI with the attach out command and used in passthrough mode. In the current example, it is not strictly required to specify to which outside interface the GMAC is connected. However, it is considered best practice to always configure the interface in the gmac configuration, use the gmac dev command for this purpose:
gmac dev [mac address|id] [interface]

gmac dev 1 eth2
By default, the Elfiq Link LB will dynamically choose the first source IP address it detects for the TCP polling and verifying link status. It is best practice (and mandatory on alternate links) to always specify for every GMAC which source IP to use with the gmac tcpprobe command:
gmac tcpprobe [mac address|chn:id|id] [dynamic] | [ip address]

gmac tcpprobe 1 194.204.1.3
Once this has been done, you can validate the information you have entered by issuing the will display all the information on your currently configured GMAC entry for your current VFI.
LinkLB-enable:vfi0 [single] # sh gmac Name[Gmac1] Type[local] Mac Address[auto] Description[Primary_Link_T1] Mode[mono (eth2)] IP Address[194.204.1.1] Netmask[255.255.255.128 or /25] Mtu[1500] Status[enabled, incomplete] Message[searching for mac address] Probe src IP[194.204.1.3] Probe src type[static] Probe dst IP[0.0.0.0:0] Probe Interval (s)[3] Probe Failure Threshold[5] Probe Failure Timeout (s)[3] Probe Syn Seq[2] Probe Failures[0] RTT (ms)[0.000] Weight[1] In Thresh[66] Out Thresh[66] Speed In (kb/s)[1544] Speed Out (kb/s)[1544] Sample interval (s)[2.990] Sample count[1] L2no[0] Total In (MB)[0.000] Total Out (MB)[0.000] Avg In (kb/s)[0.000] Avg Out (kb/s)[0.000]
sh gmac command. This
63/160
Usage In (kb/s)[0.000] Usage Out (kb/s)[0.000] Usage In (%)[0.000] Usage Out (%)[0.000] Top Speed In (kb/s)[0] Top Speed Out (kb/s)[0] Qos[not activated] Before Qos Usage In (kb/s)[0.000] Before Qos Usage Out (kb/s)[0.000] Primary Network0[194.204.1.0/25]
NOTE: The Ethernet MAC address of the router that is associated with a GMAC will always be the main identity that will be used to identify a GMAC. Therefore, all other commands associated with GMAC entries will always require the MAC address or GMAC ID to be entered, in order to make the right association with the proper GMAC entry. NOTE: At this point, it is normal that the primary link gmac does not display the MAC address and the status being incomplete. This is because it is not connected and the Link LB is searching for the GMAC MAC address.
4.2.5.
At this point, we have:
Installation and Verification
Assigned inside and outside interfaces Enabled the default balancing group features of the VFI Defined the static firewall ARP entry and an ACL access-list for the primary link Configured the primary link GMAC
The required steps to install your Elfiq Link Balancer in a live environment are completed and your configuration should look like this:
LinkLB-enable:vfi0 [single] #sh conf ## vfi0 ## EOS Version [3.3.0] ## ( vfi0 ) clr all ## Description description Not defined ## Inside interface attach in eth3 ## Outside interface(s) attach out eth2,eth1 ## Features feature default_balancing_group enable ## Arp entries (static) arp 194.204.1.3 auto inside 30 ## Acl arp (static) acl arp +ip 1 +194.204.1.0/25 +reply fw:194.204.1.3 inside ## Gmac entries gmac 1 auto Primary_Link_T1 194.204.1.1/25 1 1544 1544 0 0.0.0.0:0,0.0.0.0:0 66/66 gmac dev 1 eth2 gmac tcpprobe 1 194.204.1.3
Once you have connected the Link LB inside and primary link outside interfaces into your infrastructure, the firewall and primary link router will update their respective ARP tables for the Elfiq inside and outside interface MAC addresses and the IP packets will pass through the VFI module. WARNING: Check if you need straight or crossover cables. Verification can be done with the following commands:
sh arp: to verify that the primary link router and firewall MAC addresses have been resolved sh gmac: to verify link status and current usage sh probe report: to see the actual most active sessions passing through the Elfiq Link
Balancer
LinkLB:vfi0 [single] #sh arp IP Address[194.204.1.1] Mac Address[0:90:27:fc:3c:fd] Type[gmac, auto] Expiration[30]
64/160
Vendor[intel corporation] Learned[outside (eth2)] Published[inside] Aging[7] IP Address[194.204.1.3] Mac Address[0:d0:b7:5e:78:b0] Type[auto] Expiration[30] Vendor[intel corporation] Learned[inside (eth3)] Published[outside] Aging[7] LinkLB:vfi0 [single] #sh gmac Name[Gmac1] Type[local] Mac Address[0:90:27:fc:3c:fd] Description[Primary_Link_T1] Mode[mono (eth2)] IP Address[194.204.1.1] Netmask[255.255.255.128 or /25] Mtu[1500] Status[enabled] Message[all ok] Probe src IP[194.204.1.3] Probe src type[static] Probe dst IP[0.0.0.0:0] Probe Interval (s)[3] Probe Failure Threshold[5] Probe Failure Timeout (s)[3] Probe Syn Seq[2] Probe Failures[0] RTT (ms)[0.000] Weight[1] In Thresh[66] Out Thresh[66] Speed In (kb/s)[1544] Speed Out (kb/s)[1544] Sample interval (s)[5.000] Sample count[11] L2no[0] Total In (MB)[37.747] Total Out (MB)[1.842] Avg In (kb/s)[6777.696] Avg Out (kb/s)[289.541] Usage In (kb/s)[585.643] Usage Out (kb/s)[217.104] Usage In (%)[37.930] Usage Out (%)[14.061] Top Speed In (kb/s)[1020] Top Speed Out (kb/s)[576] Qos[not activated] Before Qos Usage In (kb/s)[585.643] Before Qos Usage Out (kb/s)[217.104] Primary Network0[194.204.1.0/25] LinkLB:vfi0 [single] #sh probe report 10 Top 10 sessions Rank Gmac In(kb/s) Out(kb/s) TopIn(kb/s) TopOut(kb/s) Proto IP Inside Port Flow IP Outside Port InKB OutKB Duration ---- ---- -------- --------- ----------- ------------ ----- ----------- ----- --- ----------- ----- ----- ---- ---------1 1 0.00 0.00 1725.23 870.57 tcp 194.204.1.3 60111 --> 78.0.1.1 http 49713 1062 0d 0h 0m47s 2 1 0.00 0.00 1396.26 772.05 tcp 194.204.1.3 60625 --> 78.0.1.1 http 49530 1087 0d 0h 0m29s 3 1 0.00 0.00 1326.23 274.52 tcp 194.204.1.3 60050 --> 78.0.1.1 http 20944 429 0d 0h 0m50s 4 1 0.00 0.00 1158.27 321.65 tcp 194.204.1.3 60500 --> 78.0.1.1 http 20945 392 0d 0h 0m33s 5 1 0.00 0.00 0.00 0.00 tcp 194.204.1.3 33099 --> 78.0.1.1 https 8119 71 0d 0h 0m 7s 6 1 0.00 0.00 0.00 0.00 tcp 194.204.1.3 33102 --> 78.0.1.1 https 3616 32 0d 0h 0m 7s 7 1 0.00 0.00 594.07 25.12 tcp 194.204.1.3 60326 --> 78.0.1.1 https 3166 30 0d 0h 0m38s 8 1 0.00 0.00 453.74 21.90 tcp 194.204.1.3 59806 --> 78.0.1.1 https 2995 26 0d 0h 0m56s 9 1 0.00 0.00 0.00 0.00 tcp 194.204.1.3 33104 --> 78.0.1.1 https 107 3 0d 0h 0m 6s 10 1 0.00 0.00 88.13 2.52 tcp 194.204.1.3 60519 --> 78.0.1.1 https 107 3 0d 0h 0m31s Total of 171261984 bytes, number of sessions 2163 Tcp 171219648 bytes, 99.98 % Udp 0 bytes, 0.00 % Ip (not Udp and Tcp) 42336 bytes, 0.02 % Outgoing traffic Incoming traffic Report generated Apr 02 14:53:12 4612176 bytes, 2.69 % 166649808 bytes, 97.31 %
65/160
4.3.
Add Alternate Links and GMAC Management

4.3.1. DHCP and PPPoE Configuration
Although the Elfiq Link Balancer normally integrates at the layer 2 of the OSI model, the Link LB can use links with dynamic IP addresses on the outside interfaces if no routers are available to perform this task. This mostly targets network connections such as cable links. A single physical or logical (with VLAN) outside interface cannot support more than one dynamic IP link (DHCP or PPPoE). These links must be isolated on different outside interfaces in monomode (one link per physical interface) or with a switch and VLANs (one VLAN per link with a trunk to the Link LB). NOTE: Incoming load balancing is not currently supported by the Link LB at this time for links with a dynamic IP address. To enable a DHCP link configuration, the first steps are to enable the DHCP feature and then create a DHCP entry that will be bound to the selected outside interface with the dhcp command.
feature dhcp [enable|disable] dhcp [dhcp id] [interface]

After your DHCP entry is created, you will be able to create your DHCP based GMAC and link them together by using the auto MAC address discovery and dhcp id options during your GMAC definition.
Figure 13: DHCP link connected on the eth2 interface LinkLB-enable:vfi0 LinkLB-enable:vfi0 LinkLB-enable:vfi0 LinkLB-enable:vfi0 [single] [single] [single] [single] # # # # feature dhcp enable dhcp 1 eth1 gmac 3 auto cable_modem dhcp:1 3 6000 1000 0 0.0.0.0:0,0.0.0.0:0 95/95 gmac dev 3 eth1
Once all these steps have been completed, the Link LB will try to get a DHCP lease and bring up the IP address upon success. You can manage and view the state of the DHCP lease with the sh dhcp and dhcp state command.
sh dhcp state dhcp [dhcp id] [release|init|renew]

LinkLB-enable:vfi0 [single] # sh dhcp ID[1] Interface[eth1] Status[complete] Server[24.200.242.19] Router[24.203.146.1] XID[0x55210311] Ip[24.203.146.100] Netmask[255.255.255.0] Broadcast[255.255.255.255] Lease (sec)[86400] Lease expire in (sec)[76094] Renew (sec)[43200] Renew in (sec)[32894]
66/160
If you need additional information to troubleshoot your DHCP configuration, there is a DHCP specific debug command that may be turned on for more extensive logging: debug dhcp on A very similar approach is performed for a PPPoE dynamic link:
LinkLB-enable:vfi0 LinkLB-enable:vfi0 LinkLB-enable:vfi0 LinkLB-enable:vfi0 [single] [single] [single] [single] # # # # feature pppox enable pppox 1 eth1 ethernet login password gmac 3 auto PPPoE_modem pppox:1 3 6000 1000 0 0.0.0.0:0,0.0.0.0:0 95/95 gmac dev 3 eth1
NOTE: Ensure to enter your PPPoE login and password in parameters. It is required that a Dynamic Network Interface be created prior to configuring a PPPoE GMAC in the VFI. Please see 3.3.10 for details on how to create a Dynamic Network Interface.
LinkLB-enable:vfi0 [single] # sh pppox ID[1] Interface[eth2] Type[ethernet (PPPoE)] Sid[0x8223] Status[session established] Local ip[216.252.82.129] Remote ip[216.252.64.5] Netmask[255.255.255.255] Mtu[1492]
NOTE: If your DHCP or PPPoE link supplies you a static IP, it is possible to assign additional network segments to your GMAC if your ISP supplied you additional static IP addresses. You will also be able to use those links with incoming load balancing as the IP addresses are static.
4.3.2.
Discover MAC Addresses
In order to discover the MAC address associated with an IP address, the Elfiq Link Balancer provides the gmac disc command. This is also useful to verify layer 2 connectivity between the Elfiq Link LB and another device connected to an outside or inside interface. For the discovery to work, you must specify on which interface the Link LB is supposed to be able to reach this IP address. In option and to ensure additional discovering methods to be used, enter the IP address from which you want to pretend you are coming from. This can be any address on the same network segment as the target IP, but ideally one that is not currently being used by another device on the corresponding network segment.
gmac disc [target ip address] [interface] [source ip address]

LinkLB-enable:vfi0 [single] #gmac disc 194.204.1.100 eth3 194.204.1.126 IP Address[194.204.1.100] GMac Address[0:d0:b7:5e:78:b0]
4.3.3.
Assign a GMAC to an Outside Inteface
By default, a GMAC is linked to the first attached outside interface (also called the multimode interface). This is achieved through the gmac dev command, which takes the GMAC ID and the outside interface to which you wish to bind your GMAC as parameters.
gmac dev [mac address|id] [interface]]

As an example, we can associate our primary GMAC with the eth2 interface and alternate link with the eth1 interface like this:
LinkLB-enable:vfi0 [single] # gmac dev 1 eth2 LinkLB-enable:vfi0 [single] # gmac dev 2 eth1
IMPORTANT: It is important to bind all GMAC entries of a VFI to their respective network interfaces for proper VFI operations. NOTE: To change the interface bound to a GMAC, simply reissue the gmac dev command with the new desired interface. To remove a gmac dev configuration use the no gmac dev command.
67/160
4.3.4.
GMAC MTU
In some situations and especially with xDSL links using PPPoX, the Maximum Transmission Unit of IP packets is smaller than the default of 1500. In order for the Elfiq Link Balancer to properly manage TCP sessions on alternate links, we can force all TCP sessions on a GMAC with TCP MSS Clamping with the gmac mtu command.
gmac mtu [mac address|id] [mtu] [mss|nomss]

gmac mtu 3 1492 mss
To remove MSS clamping, simply issue the same command with the standard 1500 MTU and the nomss parameter
gmac mtu 3 1500 nomss
WARNING: MSS clamping only affects TCP sessions. UDP, IPsec and other protocols could still run into fragmentation issues, check the MTU values of other devices to solve those issues.
4.3.5.
GMAC Aliases
In some situations, such as when two high available routers are used for a single link and bound through HSRP protocol, a GMAC can be associated with more than one MAC address. To properly link the additional MAC address to the GMAC, you can configure GMAC aliases with the gmac alias command.
gmac alias [mac address|gmac id] [alias mac address]

In a traditional HSRP setup you would set the GMAC on the VIP with auto discovery of the virtual MAC. Then you add a GMAC alias for each real MAC of each router.
4.3.6.
GMAC Networks
So far weve seen that the Elfiq Link Balancer can manage the IP addresses that are on the same network as the router once a GMAC entry has been created. However, what happens when you have more than one subnet of IP addresses provided by your Internet Service Provider? This is where the GMAC networks come into play. GMAC networks are basically extra networks that can be added to a given GMAC. Two commands allow the management of GMAC networks: to remove them. Below is the syntax for both commands:
gmac net, to add GMAC networks and no gmac net,
gmac net [mac address|chn:id|id] [network]/[netmask-bits] no gmac net [mac address|chn:id|id] [network]/[netmask-bits]
As an example, lets suppose we wanted to add the 44.44.45.0/24 network to our first GMAC from the previous example. To do so, we would need to add the following command:
LinkLB-enable:vfi0 [single] # gmac net 1 44.44.45.0/24
IMPORTANT: When assigning an additional network to a GMAC, also create an ACL ARP access-list.
4.3.7.
Change the State of a GMAC
You can freely enable or disable a GMAC. This is done through the state gmac command, which can alter the state of a GMAC between the enabled, disabled and shutdown state. You can also use this command to reset your GMAC. We can do this by identifying the gmac via the mac address, id channel or index for the concerned GMAC:
state gmac [mac address|chn:id|id] [enable|disable|reset|shutdown]
68/160
To administratively disable a GMAC:

LinkLB-enable:vfi0 [single] # state gmac 1 disable
A GMAC can also have the shutdown state. The difference with disabled is that the shutdown state is written into the configuration and the GMAC remains down after a system reload. To administratively shutdown a GMAC:
LinkLB-enable:vfi0 [single] # state gmac 1 shutdown
NOTE: Once you disable or shutdown a GMAC, all resources that were using the GMAC, such as balancing algorithms, will automatically stop using the GMAC until it is re-enabled. Incoming traffic is not affected by the gmac state, if the link is truly up, incoming sessions could still be established on this link, even in a disabled state. To administratively re-enable a GMAC:
LinkLB-enable:vfi0 [single] # state gmac 1 enable
And finally, to reset a GMAC:

LinkLB-enable:vfi0 [single] # state gmac 1 reset
NOTE: The reset will perform a polling soft reset on failures and GMAC state. Counters are left untouched.
4.3.8.
GMAC probe
Each GMAC uses up to 8 destination polling IP/ports in order to verify link status and RTT for algorithms. We can modify the timeout of the polling (polling timeout). After this timeout is reached a certain number of times (polling threshold), we consider the link is down. The GMAC probe command allows you to change the polling timeout and the polling threshold.
gmac probe threshold]
[mac
address|chn:id|id]
[polling
timeout
in
sec]
[polling
LinkLB-enable:vfi0 [single] # gmac probe 2 3 5
4.3.9.
GMAC tcpprobe
gmac tcpprobe command:
The configured source probe IP for polling can be changed using the
gmac tcpprobe [mac address|chn:id|id] [dynamic] | [ip address]

LinkLB-enable:vfi0 [single] # gmac tcpprobe 1 194.204.1.3
By default, the GMAC tcpprobe is set to dynamic. In this mode, the Link LB automatically pick an active source IP from packets passing through the VFI. It is always recommended to specify a source IP for the TCPPROBE of each GMAC.
4.3.10.
GMAC Weight, Speed, Threshold and Description
In order to choose between two GMAC and set link priority for the algorithms, we can modify the weight for each GMAC. The GMAC with the smallest weight will be selected first in algorithms.
gmac weight [mac address|chn:id|id] [new weight]

LinkLB-enable:vfi0 [single] # gmac weight 1 3
Other GMAC parameters can be changed like the GMAC speed (bandwidth), threshold values and description.
LinkLB-enable:vfi0 [single] # gmac speed 1 1544 1544 LinkLB-enable:vfi0 [single] # gmac threshold 1 80/80 LinkLB-enable:vfi0 [single] # gmac desc 1 MyGMAC_Desciption
69/160
4.3.11.
Remove a GMAC Entry

no gmac command.
To remove a GMAC entry from a Virtual Forwarder Interface, simply use the
no gmac [mac address|chn:id|gmac id]

LinkLB-enable:vfi0 [single] #no gmac 1
NOTE: Similar commands no dhcp and no pppox allows to remove DHCP or PPPoX entries. NOTE: All gmacs, DHCP or PPPoX entries can be deleted at once with the clr gmac, pppox commands. Be careful as no confirmation is required and changes are immediate.
clr dhcp and clr
4.3.12.
GMAC Statistics
In order to reset the statistics of a GMAC, a specific command is:
stats gmac [mac address|chn:id|id] [reset]
4.4. IP Association Persistence

4.4.1.
between
Links,
Access
Lists
and
IP Association Table
Now that the primary link and alternate links are configured, a planning of how the Elfiq Link Balancer will use alternate link(s) IP addresses is required in order to configure the Link LB. Of course, this visibility of multiple links is only at the Link LB level and your firewall remains configured only with the primary link IP addresses. With the Elfiq layer 2 design and primary link concept, no need to modify the firewall security rules to support alternate links, even if the primary link router itself is in failure.
Figure 14: IP association with 3 links
70/160
PRIMARY LINK IP ADDRESSES
ASSOCIATED IPs FOR ALTERNATE LINKS
Primary_Link_T1 /25
AlternateLink_xDSL /28
DynamicIP_DHCP_or_DSL
T1 router
194.204.1. 1 194.204.1. 2
212.217.1.1 212.217.1.2 212.217.1.3 212.217.1.4 212.217.1.5
DSL router
Firewall default browsing IP
194.204.1. 3 194.204.1. 4 194.204.1. 5
Firewall default alternate IP
dynamic IP
Default associated IP to 194.204.1.3
VPN concentrator
194.204.1. 22 194.204.1.
212.217.1.12 212.217.1. 212.217.1.13
VPN alternate IP
dynamic IP dynamic IP
incoming UDP 500/4500 sessions not supported on dynamic IP
outgoing UDP 500 and IPSEC-ESP sessions only
Incoming web server & outgoing FTP access
194.204.1. 115
Web and FTP alternate IP
dynamic IP dynamic IP
incoming TCP 80 sessions not supported on dynamic link outgoing FTP 21 (and data sessions) only
Outgoing DNS requests Reserved, broadcast IP
194.204.1. 127 194.204.1. 128
14 212.217.1.15
DNS alternate IP
dynamic IP
outgoing UDP 53 sessions only
NOTE: If your alternate link has less IP addresses than your primary link, you can do port address translation (PAT) to share the same alternate IP address with multiple primary link services using different primary link IP addresses. NOTE: With version 3.4.0 and higher of the EOS firmware, you can load balance multiple source IP addresses of the primary link with a single alternate IP address without conflict of source ports with masquerading (instead of overloading). Of course, the traffic being balanced must support source port translation. Before configuring the Elfiq Link LB with the information in the IP association table, an introduction an important concept is required: the access-lists.
4.4.2.
4.4.2.1.
Access Lists
Acces List Rules
An Elfiq access list (ACL) is a set of rules that are used for traffic selection in the VFI stack. Rules can be very broad and pick-up a lot of traffic or very narrow and tailored to pick-up traffic flowing only between two specific hosts for a given protocol type. Different types of access-lists are configured to take action at different locations of the Link LB VFI stack and enabled or disabled via the features. Depending on the feature, the "action" assigned to sessions selected by the ACL will be different. Refer to section 4.2.2 for additional information on the VFI stack. The content of the configuration will show all of the ACLs grouped by their layer 4 protocol (TCP, UDP, IPSEC-ESP, etc) followed by the layer 3 ACLs that will catch IP packets. This is the list of supported protocols for access-lists: UDP ICMP TCP IGMP GRE IPSEC-ESP IPSEC-AH SKIP EIGRP OSPF
71/160
L2TP IP
Apply the protocol access-list TCP YES
Apply the IP access-list YES Is there a match in the IP list?
IP Packets
Is it a supported protocol?
UDP
Is there a match in the list?
NO
NO
Packets continue the VFI stack
ICMP
IPSEC-ESP
OTHER OTHER PROTOCOLS
Figure 15: Access list flowchart
As you can see, the TCP, UDP and ICMP protocols each have their own set of access-lists. If a packet does not match the TCP, UDP, ICMP, IPSEC-ESP protocols, it will go straight to the IP access-lists. The lists have been separated by protocol to provide a much higher level of performance. In addition to the protocol, an access-list is uniquely defined with a combination of source IP/bitmask and port, destination IP/mask and port. Those five elements in an access-list can be very wide of very narrowed to a specific port and protocol between two IP addresses. The format is [network ip]/[netmask-bits]:[start port]-[stop port]. ACLs are always checked in a top-down fashion, once a match is found, the action assigned to the ACL is performed. The rest of the list will never be re-entered after a selection has been made, no matter the outcome of the "action". If the "action" cannot be carried out for the first matching ACL, then this session will not be modified by the ACLs. The order in which you list the ACLs rules are very important and should always be from narrow to broad. If you program one broad rule encompassing all IP addresses, a narrow rule listed after would never be used by the Link LB since all sessions would be selected by the broad rule first. IMPORTANT: Each access-list rule has an index number and access-lists are verified in order. The first rule that match the IP packet is applied. ACL numbering is handled dynamically in the Link LB, all ACLs have an ID number and those are rearranged whenever you add or delete rules. Adding a new ACL with an ID that was already used will insert the new ACL at the ID specifed, incrementing the rest of the list IDs by one and thus sending the existing rules lower in the list. In the same fashion, deleting a rule will decrement the rest of the list's IDs by one sending the remaining rules higher in the list. NOTE: Incoming access-lists are often from any source IP address and outgoing access-lists are often to any destination IP address. The keyword any is used to represent any IP address (0.0.0.0/0:0-0)
4.4.2.2.
Types of Access Lists
The Elfiq Link Balancer allows the creation of various types of access-lists. Each one is being verified at different locations of the VFI stack. ARP: ARP access-lists give you the possibility to redirect traffic to specified hosts or mac addresses.
72/160
NAT: NAT access-lists permit to translate source IP (nat in) or translate the destination IP (nat out) and/or destination port (nat out). They are used for associating IP addresses between the primary link and alternate link(s). For NAT balancing, they are also the rules to select algorithms for outgoing traffic. Persistence: Persistence access-lists serve the purpose of keeping specified protocols, hosts or ports on a single network path; which in our case means a single GMAC, or link, for the complete duration of a session. This is especially useful with protocols like HTTPS, where multiple short sessions will be created when a user navigates through a secured site. Depending on the chosen balancing algorithm, running without persitence rules would entail risks of splitting sessions that should have been logically kept toghether on a single link. The outcome of this session splitting is that the remote server would see a client coming in from multiple IP addresses with no way to ensure that those sessions belong to the same client and thus killing all alternate sessions and breaking the sessions. With the addition of a persistence accesslist, you can therefore enable the Link LB to keep all related sessions on a specific link, for a determined period of time. Persistence access-lists persist triggers and protofix are the three VFI elements to ensure compatibility in a link balancing environment. Debug: Debugging access-lists are used to specify which kind of traffic are traced and sent to the debug log. Filtering: Filtering access-lists purpose is to filter incoming and outgoing traffic, allowing you to prevent undesired packets from reaching or leaving your network. Access-lists in the Elfiq Link Balancer can provide the first layer of security in your network infrastructure, blocking packets before they even reach your corporate firewall. IMPORTANT: The Link LB is not meant to be used as a replacement for a corporate firewall. Instead, the use of its security features, such as access-lists and shunning engine are meant to provide an extra layer of security. Some of your firewalls features, such as stateful packet filtering and VPN capabilities, are not part of the features of the Link LB and are meant to stay on your corporate firewall. Therefore, since there is no stateful packet filtering in the Link LB, all the filtering rules created by the access-lists will either allow the packets to pass, or drop them. Any extra filtering will need to be done on the firewall. WARNING: Filtering access-lists in the Elfiq Link Balancer will drop packets as a default policy. Therefore, before enabling the filtering access-list feature in your VFI, you need to make sure to create all the rules needed to allow your traffic to pass through it. Of course, disabling the access-list feature will not alter your configurations, but will enable all packets to pass through the Link LB. Nattp: Nattp access-lists create tunnel encapsulation for point to point communication between two Link LBs. This allows you to encapsulate traffic that is normally not routable. It is especially used with the GeoLink option. Channel: Channel access-lists are used to create static communication paths between two VFI (also called inter-VFI communication). TAG: TAG access-lists provide policy based routing. In opposition to NAT balancing, no changes are made to the IP addresses; a dynamic routing table is applied per session and sessions are tracked to ensure consistent load-balancing decisions.
4.4.2.3.
You can view all access-lists with the sh
Display Access Lists

[access rule] commands.
sh acl arp sh acl nat in
ARP access-lists Outgoing NAT balancing
sh acl nat out Associating IP address between links for incoming traffic; required for
incoming NAT balancing
sh acl per in
Outgoing persistence rules
sh acl debug in/out Selecting traffic in debug mode sh acl in Outgoing filtering rules
73/160
sh acl out sh acl nattp in sh acl tag in
Incoming filtering rules NAT tunneling protocol encapsulation between two Link LB units Inter-VFI channel rules
sh acl channel in/out
Outgoing TAG balancing
4.4.2.4.
no acl arp [ip] [idx]
Remove Access Lists
Each type of access-list has a command to remove a specific entry. The commands are:
Remove an arp ip access-list by index
no acl channel in [ip|icmp|tcp|udp|...] [idx]

Remove an Channel inside ip access-list by index
no acl channel out [ip|icmp|tcp|udp|...] [idx]

Remove an Channel outside ip access-list by index
no acl debug in [ip|icmp|tcp|udp|...] [idx]

Remove a debug inside ip access-list by index
no acl debug out [ip|icmp|tcp|udp|...] [idx]

Remove a debug outside ip access-list by index
no acl in [ip|icmp|tcp|udp|...] [idx]

Remove an inside ip filtering access-list by index
no acl nat in [ip|icmp|tcp|udp|...] [idx]

Remove a nat inside ip access-list by index
no acl nat out [ip|icmp|tcp|udp|...] [idx]

Remove a nat outside ip access-list by index
no acl out [ip|icmp|tcp|udp|...] [idx]

Remove an outside ip filtering access-list by index
no acl per in [ip|icmp|tcp|udp|...] [idx]

Remove an persistence inside ip access-list by index
no acl tag in [ip|icmp|tcp|udp|...] [idx]

Remove a tag inside ip access-list by index All access-lists of a specific type can be removed at once using:
clr acl [type] [in|out] [proto]

Possible types are: arp, channel, debug, nat, nattp, per and tag. If not specified, the command is applied to level 3 filtering access-lists.
74/160
4.4.3.
4.4.3.1.
Outside Network Address Translation (NAT) Rules

Outside NAT Rules
Now that the planning of IP addresses assignment from the alternate links to the primary link services is done, the first step is to configure the access-lists for incoming traffic. We must configure the Elfiq Link Balancer to redirect the traffic coming to all the different IP addresses on the alternate links to the primary link IP address of each resource. This is done through outside network address translation rules. After the outside NAT rules are configured, each service can be accessed either with its primary link IP address or any of its alternate IP addresses on alternate links. Since the traffic balancing of outside traffic is done through DNS queries, no balancing algorithms are specified into the outside NAT rules. Because of this, translations are associated on a one to one basis or per block of IP addresses. Configuring the Intelligent DNS service (IDNS) to perform incoming load balancing is covered in a following chapter. Each time an incoming session hits an outside NAT access-list rule, control blocks (DNAT OUT and RNAT OUT) are created into the VFI stack to keep a record of the unique session identifiers and which link it is using. Those control blocks ensure that incoming and outgoing packets for this specific IP session will use the same link. DNAT OUT blocks will keep track of incoming packets, RNAT OUT will keep track of outgoing (returning) packets. Control blocks expire after a configurable timeout period. Each time a packet for a specific session passes through the VFI stack, the timeout countdown for this session control blocks is reset. Those control-blocks are stored in optimized hashing tables and are the centerpiece of NAT load balancing. The maximum number of sessions that can be handled depends of your Link LB model.
Figure 16: dnat and rnat out
75/160
4.4.3.2.
Create Outside NAT Rules

nat out command:
Outside NAT rules, are created with the acl
acl nat out [+|-][ip|icmp|tcp|udp|...] [idx] [+|-][source ip]/[netmaskbits]:[start port]-[stop port] [+|-][dest]/[netmask-bits]:[start port][stop port] [+|-][pass|nat] [ndip:ip|ndnet:network/netmask-bits] [ndport:port] [qos:id] [geotag:id] [iagrp:id] [inactivity timeout]
The first element that you need to specify for outside network translation rules is the protocol that you wish to balance. An index is also entered because access-lists are verified in order. If you select 0, it will be added at the end of the accesslist. Positive and negative logics are supported. A standard approach is to follow a positive logic for all access-list rules. IMPORTANT: Access-lists are verified in order of their index. When creating an access-list, it will be inserted at the specified index. If an access-list already exists, it will not be deleted but moved to the next index. The next parameter is the source IP address, which represents the IP address from which the clients will be connecting. The source IP address can be linked with the source port, depending on the chosen protocol. When creating IP based rules, no ports are specified since the rule will match all the possible protocol requests. The next element is the destination IP and port. While this is more frequently a statically defined IP address or subnet, it can also be a dynamic IP address if a DHCP or PPPoE link is used.
LinkLB-enable:vfi0 [single] #acl nat out +ip 2 +any +dhcp:1 +nat ndnet:194.204.1.3/32
NOTE: The keyword any is often used as a source ip for outside NAT rules and represents 0.0.0.0/0:0-0. The next element to specify is for deciding if the action is to pass the packet or NAT it. In NAT load balancing, the action is usually to NAT the packet. Choosing NAT will create control-blocks and possibly change the IP addresses on the packets; choosing pass will do neither. The next element is the new destination address with the new destination port associated to, it s the IP address to reach on the primary link, also, the destination can be a network segment. If you have balanced a network address from your second link, instead of specifying address by address to reach, you can specify the destination network IP as destination, then IP addresses will be matched one by one. IMPORTANT: Doing access rules by block is very powerful to reduce the number of access-lists. It is also called performing a block NAT. The next element is the ID of the Quality of Service (QoS) queue assigned to this access-list. This parameter is optional and QoS is covered in a following chapter. The next element is the ID of geotag which the ACL associated to. Geotags are part of the geographic load balancing option called GeoLink. This parameter is optional and Geolink is covered in a following chapter. The next element is the Internet Condition Verificator (ICV) action group (iagrp). An ICV allows to verify certain conditions to trigger an action. In this case they allow to enable or disable access-list rules. This parameter is optional and ICV is covered in a following chapter. The last parameter is the timeout period in second of the session control block. This parameter is optional and used in specific configurations where sessions are idle for very long period. NOTE: When the inactivity timeout is not specified, the default is 300 seconds for TCP, 30 seconds for UDP and 5 seconds for the other protocols: Protocol TCP UDP Other (IP) Default Timeout (in seconds) 300 30 5
We will now add outside NAT rules for our planned table of associated IP addresses:
76/160
LinkLB-enable:vfi0 LinkLB-enable:vfi0 LinkLB-enable:vfi0 LinkLB-enable:vfi0 LinkLB-enable:vfi0 LinkLB-enable:vfi0
[single] [single] [single] [single] [single] [single]
#acl #acl #acl #acl #acl #acl
nat nat nat nat nat nat
out out out out out out
+ip +ip +ip +ip +ip +ip
1 2 3 4 5 6
+any +any +any +any +any +any
+194.204.1.0/25 +nat ndnet:194.204.1.0/25 +212.217.1.3/32 +nat ndnet:194.204.1.3/32 +212.217.1.12/32 +nat ndnet:194.204.1.22/32 +212.217.1.13/32 +nat ndnet:194.204.1.115/32 +212.217.1.14/32 +nat ndnet:194.204.1.127/32 +212.217.1.0/28 +nat ndnet:194.204.1.0/28
IMPORTANT: Outside NAT rules must also be created for the primary link IP segments. The last acl nat out rule is an example of a block nat to associate a large number of IP addresses from the alternate link to the primary link with a single line. This access-list rule automatically associate the following IP addresses: Alternate Link IP 212.217.1.0 212.217.1.1 212.217.1.2 212.217.1.3 212.217.1.4 212.217.1.5 212.217.1.6 212.217.1.7 212.217.1.8 212.217.1.9 212.217.1.10 212.217.1.11 212.217.1.12 212.217.1.13 212.217.1.14 212.217.1.15 Associated Primary Link IP 194.204.1.0 194.204.1.1 194.204.1.2 194.204.1.3 194.204.1.4 194.204.1.5 194.204.1.6 194.204.1.7 194.204.1.8 194.204.1.9 194.204.1.10 194.204.1.11 194.204.1.12 194.204.1.13 194.204.1.14 194.204.1.15 Note Even if it is associated, no packets can be routed from the Internet to the network IP address. Even if it is associated, packets forwarded on the Internet to the router IP will not reach the Link LB. This association does not generate hit counts because rule index 2 has higher priority.
This association does not generate hit counts because rule index 3 has higher priority. This association does not generate hit counts because rule index 4 has higher priority. This association does not generate hit counts because rule index 5 has higher priority. Even if it is associated, no packets can be forwarded from the Internet to the broadcast IP address.
NOTE: The advantage of associating unused alternate IP addresses with a block nat is that the Link LB is pre-configured for future usage of those IP addresses since they are already associated to primary link IP addresses. IMPORTANT: The IP addresses 212.217.1.3, .12, .13 and .14 will never hit the rule index number 6 because rules 2, 3, 4 and 5 have a higher priority index and are verified before.
4.4.3.3.
Display Outside NAT Rules

sh acl nat out command:
To display all ACL outside NAT rules of a VFI, issue the
LinkLB-enable:vfi0 [single] #sh acl nat out Protocol[+ip] Index[1] Source[+any] Destination[+194.204.1.0/25] Action[+nat ndnet:194.204.1.0/25] Hit Count[0] Protocol[+ip] Index[2] Source[+any] Destination[+212.217.1.3/32] Action[+nat ndnet:194.204.1.3/32] Hit Count[0] Protocol[+ip] Index[3] Source[+any] Destination[+212.217.1.12/32] Action[+nat ndnet:194.204.1.22/32] Hit Count[0] Protocol[+ip] Index[4] Source[+any] Destination[+212.217.1.13/32] Action[+nat ndnet:194.204.1.115/32] Hit Count[0] Protocol[+ip] Index[5] Source[+any] Destination[+212.217.1.14/32] Action[+nat ndnet:194.204.1.127/32] Hit Count[0] Protocol[+ip] Index[6] Source[+any] Destination[+212.217.1.0/28] Action[+nat ndnet:194.204.1.0/28] Hit Count[0]
77/160
NOTE: The sh
acl nat out command display the number of times (hit count) a packet has hit the accell-list rule.
4.4.3.4.
Outside NAT rules are removed with the no
Delete Outside NAT Rules

acl nat out command, followed by the index of the ACL. nat out command.
no acl nat out [ip|icmp|tcp|udp|...] [idx]

It is also possible to clear all of the existing outside NAT rules for a given protocol with the clr
clr acl nat out [ip|icmp|tcp|udp|...]
4.4.3.5.
Rnat Out and Dnat Out Control Blocks
As mentioned previously, each time a new IP session is initiated from the outside of the Link LB, control blocks are created to keep a record of the session unique identifiers and in which link it is balanced. You have the possibility to display the return NAT (RNAT out) or dynamic NAT (DNAT OUT) control blocks on the outside with the following commands:
sh dnat out sh rnat out

LinkLB-enable:vfi0 [single] #sh dnat out Protocol[udp] Src IP[74.56.138.144:4500] Dst IP[217.217.1.12:4500] New Dst IP[194.204.1.22:4500] Chn[0] Cleanup Flags[fl: inac timer] Timer Expiry[28] Hit Counts[1470]
Also, you can be more granular by filtering the source/destination and the network/netmask-bits:
sh dnat out [source|destination] [network/netmask-bits] sh rnat out [source|destination] [network/netmask-bits]

LinkLB-enable:vfi0 [single] #sh dnat out source 194.204.1.3/32
The same options are offered to clear the rnat/dnat rules:
clr dnat out [source|destination] [network/netmask-bits] clr rnat out [source|destination] [network/netmask-bits]
4.4.4.
4.4.4.1.
Persistence
Persistence Access Lists
Persistence access-lists can only be applied to the inside interface of the Elfiq Link Balancer, since they are only meant to force outgoing sessions to keep using the same network path on which they started. The command to add persistence access-lists is the following:
acl per in [+|-][ip|icmp|tcp|udp|...] [idx] [+|-][source ip]/[netmaskbits]:0-0 [+|-][dest]/[netmask-bits]:0-0 [+|-][pass|persist] [timeout]

Except for the action parameter, the persistence access-lists use the same parameters as other access-lists. The action can be either pass or persist; pass meaning that the packets will pass through the Link LB normally, while the persist action means to force sessions to persist on the same link. A standard configuration should ensure to have persistence access-list rules for the default browsing IP addresses for HTTPS and HTTP traffic. This ensures that all session to a specific destination will use the same link for compatibility reasons for a specific timeout period. Link LB Administrator Guide EOS 3.5.2 and higher Document Version 3.04 - July 2012
78/160
Since this persistence request is general to the Internet and to ensure the rule is generic for any IP address, it is usually entered from any source to any destination:
LinkLB-enable:vfi0 [single] #acl per in +tcp 1 +any +any:443-443 +persist 600 LinkLB-enable:vfi0 [single] #acl per in +tcp 2 +any +any:80-80 +persist 600
NOTE: A recommended timeout of 10 minutes (600 seconds) is usually more than sufficient. The sh
acl per in command allows to see the hitcounts for each persistence access-list.
LinkLB-enable:vfi0 [single] #sh acl per in Protocol[+tcp] Index[1] Source[+any] Destination[+any:443-443] Action[+persist 600] Hit Count[1253] Protocol[+tcp] Index[2] Source[+any] Destination[+any:80-80] Action[+persist 600] Hit Count[2631]
As usual, removing an access-list is performed with the no statement:
no acl per in [ip|icmp|tcp|udp|...] [idx]
4.4.4.2.
Persistence Triggers
A persistence trigger (or persist trigger) is another method to create persistence control blocks. The main difference between persistence ACLs and persist triggers is that while ACLs guarantee persistence for the specified protocol between the two hosts at the protocol level, persist triggers will use the specified protocol as a signal to start persistence for any other possible network traffic between those two IP addresses. In other words, an ACL persist rule would have all the HTTPS stay on a single link for the duration of the exchange, but FTP traffic between the same two hosts might be balanced on another link. A Persist Trigger on TCP port 443 would keep all traffic between the two hosts on a single link. Persistence trigger can be initiated by inside or outside traffic. Control blocks are created when a session with a specific protocol and destination port is initiated. It ensures persistence between two IP addresses to use the same link.
persist trigger [id] [vpn]|[proto]:[dest port] [ttl in seconds] [global]

A persistence trigger can be initiated with a specific protocol and destination port. For vpn tunnels, entering the vpn keyword create persistence triggers for all commonly used VPN ports. The persistence trigger for the specific source IP and destination IP is kept up to a specific timeout. The global keyword defines if only the specified protocol and destination port will reset the persistence timeout counter or all IP sessions between those two IP addresses. To ensure that VPN users are able to establish VPN tunnels, the required persistence trigger is
persist trigger 1 vpn 1800 global
The Link LB can be SIP-aware to ensure control and voice calls are using the same link. This persistence trigger must be used in conjunction with the sip protofix.
persist trigger 2 udp:5060 3600
Removing a persistence trigger is performed with the no statement:
no persist trigger [id]
4.4.4.3.
Persistence Control Blocks

sh preip in
Both inside persistence access-lists and persistence triggers control blocks can be displayed with the command
sh preip in [source|destination] [network/netmask-bits]

Here is an example of control blocks created via a persistence access-list and via a persistence trigger:
79/160
LinkLB-enable:vfi0 [single] #sh preip in Protocol[tcp] Src IP[194.204.1.3] Dst IP[208.80.152.3:80] Selected Src IP[212.217.1.3] Cleanup Flags[fl: inac timer] Timer Expiry[43] Protocol[ip] Src IP[194.204.1.3] Dst IP[24.203.164.224] Selected Src IP[194.204.1.3] Cleanup Flags[fl: persist trigger, inac timer] Timer Expiry[1796]
4.4.5.
Protocol Specific Fixes
Some protocols, mostly those that create multiple sessions on different ports or protocols, cannot be balanced over all algorithms without special handling. Protocols that also need special handling can be fully balanced by the Elfiq Link Balancer through the use of protofix rules. The protocols that are currently supported by protofix rules are FTP and SIP. More protocols will be added as official support is included into the Link LB. NOTE: User VPNs and most applications can be fully balanced with persist triggers. The protofix has the difference with persist trigger that it must modify information at the application level to ensure compatibility in a multihomed network. Protofix rules are simple to manage and cover both inside and outside traffic. To add a protofix rule, simply issue the protofix command, followed by the protocol to fix.
protofix [protocol] [port]

LinkLB-enable:vfi0 [single] #protofix ftp 21 LinkLB-enable:vfi0 [single] #protofix sip 5060
To remove a protofix, issue a
no protofix command, also followed by the protocol to fix: no protofix
[protocol]
4.5.
Outgoing Load Balancing (OLB)

4.5.1.
4.5.1.1.
IP Address Pools
Pool ID
IP address pools, or IP pools, are a sort of network containers that store ranges of IP addresses of alternate links. It is from these pools of IP addresses, whether they contain one or more addresses, that the Elfiq Link Balancer will be able to select a balanced IP address for outgoing balancing. An advantage of using IP pools is to be able to modify IP address associations for balancing algorithms easier than modifying all associated access-list rules. NOTE: Address pools and the related address translation (outgoing traffic).
poolip commands, can only be used in reference to inside traffic network
Each pool can contain up to 256 IP addresses, as long as their IP addresses have the same first 3 bytes. This means that any pool of IP addresses must stay in the same class C network. A maximum of up to 254 pools of IP addresses can be defined in a single VFI. All the address pools are associated with a unique identification number, the pool id, which is used to identify the pools when used throughout the Link LB VFI configuration. Any pool id must be a unique value between 2 and 255. Pool ID 1, the self identifying routable address pool When outgoing sessions get to the Link LB, the source IP address on the packets is already set to a public IP address by the firewall; this IP address should be routable through the primary link as it is. This original IP address as received by the Link LB is saved in pool ID 1. For each and every session passing through the Link LB, pool ID 1 represents the original IP for the specific session being handled at this time.
80/160
When configuring an ACL for outbound load-balancing, you will need to list the available pool IDs for the ACL you are creating. Using the poolip 1 in any rule will command the Link LB to consider the primary link. If the primary link (poolip 1) is chosen, the Link LB will process the session as any other NAT operation but keep the original source IP for the session. The purpose of NAT in this case is to create control blocks for the session ensuring persistence and complete session handling. If another pool ID is chosen, then the NAT process will change the source IP to comply with the chosen poolip and again, create control blocks for the session ensuring persistence and complete session handling. Once the NAT operation is done, the packets will proceed to the rest of the VFI functional stack. Eventually making it to the internet on the link (or GMAC) chosen by the Link LB at this stage.
4.5.1.2.
Add Address Pools
Address pools can be created with the poolip command, which takes a unique ID and the desired range of IP addresses as parameters. Since the pool ID 1 is used to represent routable traffic (By default, it s associated to primary internet connection), the first pool ID that can be used is 2 and the last available one is 255. poolip [id] [network]/[netmask-bits]|[dhcp:id|pppox:id] [masq] As an example, we could create a few pools of IP addresses for our second GMAC entries:
LinkLB-enable:vfi0 LinkLB-enable:vfi0 LinkLB-enable:vfi0 LinkLB-enable:vfi0 LinkLB-enable:vfi0 [single] [single] [single] [single] [single] #poolip #poolip #poolip #poolip #poolip 3 212.217.1.3/32 22 212.217.1.12/32 115 212.217.1.13/32 127 212.217.1.14/32 255 212.217.1.0/28
When you create a poolip 212.217.1.0/28, all of the subnet is used by the Link LB, from 212.217.1.0 to 212.217.1.15. For the third link which is a dynamic DHCP or PPPoE link, the IP address is unknown in the configuration and the poolip is created with the DHCP or PPPoE identification number which is also used for the GMAC configuration.
LinkLB-enable:vfi0 [single] #poolip 250 dhcp:1
or
LinkLB-enable:vfi0 [single] #poolip 250 pppox:1
If you look carefully at the IP pools we have just created, they are using the required IP addresses in the IP association table in section 4.4.3.2. You can list the pool of IP addresses that you have created with the
LinkLB-enable:vfi0 [single] #sh poolip ID[3] Range[212.217.1.3/32] Hit Count[0] ID[22] Range[212.217.1.12/32] Hit Count[0] ID[115] Range[212.217.1.13/32] Hit Count[0] ID[127] Range[212.217.1.14/32] Hit Count[0] ID[250] Range[dhcp:1 24.203.146.100/32] Hit Count[0] ID[255] Range[212.217.1.0/28] Hit Count[0] LinkLB-enable:vfi0 [single] #
sh poolip command.
NOTE: The pool ID tag is important because it is used to reference the pool IP when you use it in a load balancing rule. The Link Balancer configuration now looks like the following with the primary link, alternate links, outside NAT rules and persistence:
LinkLB-enable:vfi0 [single] #sh conf ## vfi0 ## EOS Version [3.3.0] ## ( vfi0 ) clr all ## Description description Not defined
81/160
## Inside interface attach in eth3 ## Outside interface(s) attach out eth2,eth1 ## Features feature default_balancing_group enable feature dhcp enable ## Arp entries (static) arp 194.204.1.3 auto inside 30 ## Acl arp (static) acl arp +ip 1 +194.204.1.0/25 +reply fw:194.204.1.3 inside ## Protofix rules protofix ftp 21 ## Gmac entries gmac 1 auto Primary_Link_T1 194.204.1.1/25 1 1544 1544 0 0.0.0.0:0,0.0.0.0:0 66/66 gmac dev 1 eth2 gmac tcpprobe 1 194.204.1.3 gmac 2 auto AlternateLink_xDSL 212.217.1.1/28 2 5000 1000 0 0.0.0.0:0,0.0.0.0:0 95/95 gmac dev 2 eth1 gmac mtu 2 1492 mss gmac tcpprobe 2 212.217.1.3 gmac 3 auto cable_modem dhcp:1 3 6000 1000 0 0.0.0.0:0,0.0.0.0:0 95/95 gmac dev 3 eth1 ## Acl persistence inside acl per in +tcp 1 +any +any:443-443 +persist 600 acl per in +tcp 2 +any +any:80-80 +persist 600 ## Persistence triggers persist trigger 1 vpn 1800 global ## Acl nat outside acl nat out +ip 1 +any +194.204.1.0/25 +nat ndnet:194.204.1.0/25 acl nat out +ip 2 +any +212.217.1.3/32 +nat ndnet:194.204.1.3/32 acl nat out +ip 3 +any +212.217.1.12/32 +nat ndnet:194.204.1.22/32 acl nat out +ip 4 +any +212.217.1.14/32 +nat ndnet:194.204.1.115/32 acl nat out +ip 5 +any +212.217.1.15/32 +nat ndnet:194.204.1.127/32 acl nat out +ip 6 +any +212.217.1.0/28 +nat ndnet:194.204.1.0/28 ## IP pools poolip 3 212.217.1.3/32 poolip 22 212.217.1.12/32 poolip 115 212.217.1.13/32 poolip 127 212.217.1.14/32 poolip 250 dhcp:1 poolip 255 212.217.1.0/28 ## Dhcp dhcp 1 eth1
To balance outbound traffic on the different links on the outside of a virtual forwarding interface, the main task is to add network address translation (NAT) rules into the Elfiq Link Balancer s configuration. As opposed to regular NAT rules found in other devices, such as firewalls, the inside NAT rules of the Link LB do not just translate addresses, but also take care of balancing outgoing traffic. As they translate inside traffic, the resulting address will always be an IP chosen according to the balancing algorithms, making sure that your outgoing traffic is always balanced accordingly. This task also ensures that all traffic going through one of the links always has a routable IP address inside that network. However, before creating inside NAT rules to balance outgoing traffic, we must first examine masquerading and the various balancing algorithms that are available when managing outgoing traffic.
4.5.1.3.
no poolip [pool id]
Delete Address Pools

poolip command, followed by the ID of the pool.
To delete a pool of IP addresses, simply use the no
LinkLB-enable:vfi0 [single] #no poolip 11
82/160
4.5.1.4.
Create IP Address Pools Masquerading
By default, address pools are used to perform a 1:1 IP association with primary link IP addresses. The Elfiq Link Balancer will not modify the source and destination ports. It is also possible to combine multiple services on the primary link and to use a single alternate IP address. This is called IP overloading and must be carefully planned to avoid conflicts or ports for both incoming and outgoing services. With version 3.4.3 of the Elfiq Operating System, it is possible to combine multiple source IP addresses on a single alternate link IP address with a poolip performing masquerading. Masquerading is the action to track the source ports of outgoing sessions in order to ensure no collisions with other sessions on a single alternate IP address, ports are changed on a need basis. To have a poolip perform masquerading, the masq keyword must be added when creating the poolip:
poolip [id] [network]/[netmask-bits]|[dhcp:id|pppox:id] [masq]

LinkLB-enable:vfi0 [single] #poolip 250 dhcp:1 masq
NOTE: Only poolip with a /32 bitmask can perform masquerading. NOTE: Multiple servers hosting a given service cannot use a single alternate IP for incoming load balancing. For example, two web servers, each one listening on TCP port 80 on their own separate public IPs from the primary link, cannot use a single IP address on an alternate link because the TCP port 80 of the alternate IP can be redirected only once. By default, all ports higher than 1024 (except for a few standard ones for VPNs) are available for masquerading.
LinkLB-enable:vfi0 [single] #sh poolip ID[250] Range[dhcp:1 24.203.146.100/32] Masquerading[usage tcp 0/64468 0.000 %, udp 0/64468 0.000 %, icmp 0/65536 0.000 %] Hit Count[0]
It is possible to specify the range of TCP/UDP ports available for masquerading (globally for the VFI) with the masq range command. This command can be issued more than once to select different ranges of ports.
masq range [start port]-[stop port],[reserved] [description]

For example to perform masquerading on ports 8000 to 50000:
LinkLB-enable:vfi0 [single] #masq range 8000-50000 Available_Ports_for_Masquerading LinkLB-enable:vfi0 [single] #sh poolip ID[250] Range[dhcp:1 24.203.146.100/32] Masquerading[usage tcp 0/41996 0.000 %, udp 0/41996 0.000 %, icmp 0/65536 0.000 %] Hit Count[0]
NOTE: Reserved port numbers (below 1024) and some others specific to VPN traffic will not be changed of source port by the Link LB. If you have incoming services on a poolip doing masquerading, you must ensure to reserve the ports for those incoming services to prevent conflicts. It is also possible to use a reservation approach to specify which ports must not be used for masquerading within the available range of ports with the reserved keyword. For example if a web server is using port 8080:
LinkLB-enable:vfi0 [single] #masq range 8080-8080,reserved Reserved_Port_for_webserver LinkLB-enable:vfi0 [single] #sh poolip ID[250] Range[dhcp:1 0.0.0.0/0] Masquerading[usage tcp 0/41995 0.000 %, udp 0/41995 0.000 %, icmp 0/65536 0.000 %] Hit Count[0]
IMPORTANT: The Link LB will first allocate the available port range(s) for masquerading then substract the reserved ports. The masq range commands are displayed in this order in the configuration.
4.5.1.5.
Delete Address Pool Masq Ranges

masq range command must be issued for each
Since the masquerading ranges do not have an index or ID, a no range to delete by specifying the start and stop ports of the range.
no masq range [start port]-[stop port]

Link LB Administrator Guide EOS 3.5.2 and higher Document Version 3.04 - July 2012 83/160
4.5.2.
4.5.2.1.
Outgoing Load Balancing Algorithms Using NAT

RR: Round Robin
The round robin algorithm will always alternate its link selection, one after another. The only factor that can influence the round robin algorithm is the status of the links. Should a link become unavailable, this link will simply be discarded from the possible list of selection until it becomes available again. Its link selection is based on the following criteria: 1. The next link in the round robin list 2. The current status of the link (up/down)
4.5.2.2.
WFA: Weight First Algorithm
The Weight First Algorithm is the algorithm that is most influenced by the weight of the link. Its link selection is based on the following criteria: 1. 2. 3. 4. The weight of the link: links with the lowest weight value have the highest priority The threshold set on incoming traffic The threshold set on outgoing traffic The current status of the link (up/down)
Should two different links have the same weight, the WFA algorithm will decide on which links to use in a round robin fashion.
4.5.2.3.
RWFA: Reversed Weight First Algorithm
Reverse Weight First Algorithm is the opposite of the WFA algorithm. It is also influenced by the weight of the link but in a reverse manner. Its link selection is based on the following criteria : 1. 2. 3. 4. The weight of the link: link with the HIGHEST weight value have now HIGHEST priority The threshold set on incoming traffic The threshold set on outgoing traffic The current status of the link (Up/Down)
Should two different links have the same weight, the RWFA algorithm will decide on which links to use in a round robin fashion.
4.5.2.4.
1. 2. 3. 4. 5.
ETFA: Equalized Traffic First Algorithm
The Equalized Traffic First Algorithm will make its link selection based on the following criteria: Current utilization percentage on incoming traffic Current utilization percentage on outgoing traffic The threshold set on incoming traffic The threshold set on outgoing traffic The current status of the link (up/down)
Should two different links end up with the same value after calculations, the ETFA algorithm will decide on which links to use in a round robin fashion.
4.5.2.5. Algorithm
WFA-ETFA: Weighted then Equalized Traffic First
The Weighted then Equalized Traffic First Algorithm will make its link selection based on the following criterias: 1. The weight of the link: links with the lowest weight value have the highest priority
84/160
2. 3. 4. 5. 6.
Current utilization percentage on incoming traffic Current utilization percentage on outgoing traffic The threshold set on incoming traffic The threshold set on outgoing traffic The current status of the link (up/down)
Should two different links have the same weight, the WFA-ETFA algorithm will decide on which links to use with ETFA algorithm.
4.5.2.6.
OPFA: Order Preferred First Algorithm
The OPFA algorithm is based on the specified order of pool IPs for link selection. Each outgoing balancing rule specifies the associated IP pools. With the OPFA you select or prioritize IP pools and if there is a failure it can use the following IP pool in the list. Its link selection is based on the following criteria: 1. The defined order of the IP pool in the ACL command 2. The current status of the link associated to the IP pool (up/down)
4.5.2.7.
FOPFA: Forced Order Preferred First Algorithm
With FOPFA you select or prioritize IP pools like OPFA. The main difference is that, if a link that failed becomes available again, then all current and future sessions will be positioned back on the link associated with the preferred IP pool (in order). This means that all control blocks will be cleared and new sessions will be established. The link selection of FOPFA is based on the following criteria: 1. The defined order of the IP pool in the ACL command 2. The current status of the link associated to the IP pool (up/down)
4.5.2.8.
1. 2. 3. 4. 5.
LTFA: Least Traffic First Algorithm
The Least Traffic First Algorithm will make its link selection based on the following criterias: The incoming bandwidth of the link The outgoing bandwidth of the link The threshold set on incoming traffic The threshold set on outgoing traffic The status of the link (up/down)
Should two different links end up with the same value after calculations, the LTFA algorithm will decide on which links to use in a round robin fashion. NOTE: MTPX is another algorithm used for point-to-point resiliency.
4.5.3.
4.5.3.1.
Inside Network Address Translation Rules

Create Inside NAT Rules
Once pools of IP addresses have been created for alternate IP addresses and outgoing balancing algorithms have been determined, it is possible to create inside NAT rules. Those rules are created to translate all source IP addresses from traffic coming on the inside interface of a VFI to an IP address that is routable on one of the available GMACs of the outside interface of the VFI.
85/160
The addresses used in the translation coming come from pools of IP addresses, created with the poolip command. To be able to load balance traffic from the inside interface, the NAT rules must translate inside IP addresses to pools of IP addresses. Inside NAT rules, are created with the acl
nat in command:
acl nat in [+|-][ip|icmp|tcp|udp|...] [idx] [+|-][source ip]/[netmaskbits]:[start port]-[stop port] [+|-][dest]/[netmask-bits]:[start port][stop port] [+|-][pass|nat] [poolip:id,...] | [spathgrp:id] [etfa|ltfa|wfa|wfa-etfa|rr|opfa|mtpx] [qos:id,...] [geotag:id] [iagrp:id] [inactivity timeout]
When creating inside NAT rules, the first element that you need to specify is the protocol that you wish to balance followed by an access-list index. The list of supported protocols is: UDP ICMP TCP IGMP GRE IPSEC-ESP IPSEC-AH SKIP EIGRP OSPF L2TP IP
NOTE: NAT inside access-lists are regrouped by protocol in the configuration and also verified with the same order. The next parameter that needs to be specified is the source IP address and ports from which the traffic is coming. This tells the Link LB on which sources it must apply this translation rule. The following parameter is the destination address and port followed by the action to perform a NAT of the session. The next parameter is the list of pools of IP addresses (for load balancing), separated by commas. To specify pools of IP addresses, you must first precede the IDs of the pools with the poolip: directive. The SitePath group ID is optional. Finally, the last parameter you need to add is the balancing algorithm that you wish to use for this rule. Qos, geotag and iagrp parameters are optional. When the inactivity timeout is not specified, the default is 300 seconds for TCP, 30 seconds for UDP and 5 seconds for the other protocols: Protocol TCP UDP Other (IP) Default Timeout (in seconds) 300 30 5
Lets take a look at different types of inside NAT rules creations, modeled on the IP association example listed and the IP pools. A good outgoing rule is to load balance all traffic at the IP level (all protocols) using the OPFA algorithm from the primary link in failover to alternate links. To balance the primary link services with an OPFA algorithm, the following statements would be created:
acl nat in +ip 1 +194.204.1.3/32:0-0 +any +nat poolip:1,3,250 opfa acl nat in +ip 2 +194.204.1.22/32:0-0 +any +nat poolip:1,12 opfa
86/160
acl nat in +ip 3 +194.204.1.115/32:0-0 +any +nat poolip:1,115 opfa acl nat in +ip 4 +194.204.1.127/32:0-0 +any +nat poolip:1,127 opfa
For future use, we can add a default block rule for the remaining IP addresses on the primary link in a one to one association with the remaining IP addresses on the alternate link.
acl nat in +ip 5 +194.204.1.0/28:0-0 +any +nat poolip:1,255 opfa
Other outgoing balancing rules for the services are:

acl nat in +udp 1 +194.204.1.22/32:500-500 +any:500-500 +nat poolip:1,12,250 opfa acl nat in +ipsec-esp 1 +194.204.1.22/32 +any +nat poolip:1,12,250 opfa
In order to fully use the links, we can add rules to use all three links for outgoing HTTP and HTTPS traffic and the second link first in a failover cascade for FTP transfers.
acl nat in +tcp 1 +194.204.1.3/32:0-0 +any:80-80 +nat poolip:1,3,250 etfa acl nat in +tcp 2 +194.204.1.3/32:0-0 +any:443-443 +nat poolip:1,3,250 etfa acl nat in +tcp 3 +194.204.1.115/32:0-0 +any:21-21 +nat poolip:115,250,1 opfa
The last identified outgoing service in our IP association table is the DNS requests from IP 194.204.1.127. It is already handled in failover on the second link with the fourth ACL NAT IN IP rule. However to ensure it is working properly in case the primary link and second link are in failover, we must add a rule to use the third link.
acl nat in +udp 2 +194.204.1.127/32:0-0 +any:53-53 +nat poolip:1,127,250 wfa
NOTE: Elfiq Link LB supports up to 1024 ACL NAT IN rules. NOTE: Once an ACL NAT IN rule has been hit and no poolip is available because their associated gmacs are down/disable, the Link LB will not continue the ACL NAT IN list. The session will pass through the VFI stack unchanged with the same source IP it was initiated (primary link). IMPORTANT: To ensure a one to one IP association, the pool IP addresses in an inside nat rule usually have the same bitmask than the source IP network mask (except if using masquerading). WARNING: Although the Link LB allows you to balance just about any protocol, it is very important to understand that some protocols cannot be balanced properly with some algorithms; since the client, the server, or the application to which you are connected will not be able to understand the session traffic if it comes from multiple sources. This is especially true for all protocols or applications that must establish sessions through multiple ports or protocols. Please consult your applications documentation if you are unsure about its session establishment mechanism. The most notable of such protocols are IPSEC, PPTP, L2TP and VOIP. It is recommended in your first configurations that those protocols are only balanced through WFA or OPFA algorithms. Persistence should also be required for most of those protocols to load balance them. WARNING: Some DNS servers could deny DNS requests originating from an alternate link because its source IP is from another provider. You must ensure to test this and add more specific rules for DNS requests as required. For maximum failover we recommend to have one DNS server per provider or to use open DNS servers.
4.5.3.2.
Display Inside NAT Rules

sh acl nat in command:
All the NAT rules of a VFI can be displayed with the
LinkLB-enable:vfi0 [single] #sh acl nat in Protocol[+tcp] Index[1] Source[+194.204.1.3/32:0-0] Destination[+any:80-80] Action[+nat poolip:1,3,250 etfa] Hit Count[0] Protocol[+tcp] Index[2] Source[+194.204.1.3/32:0-0] Destination[+any:443-443] Action[+nat poolip:1,3,250 etfa] Hit Count[0] Protocol[+tcp] Index[3] Source[+194.204.1.115/32:0-0] Destination[+any:21-21] Action[+nat poolip:115,250,1 opfa] Hit Count[0] Protocol[+udp] Index[1] Source[+194.204.1.22/32:500-500] Destination[+any:500-500] Action[+nat poolip:1,12,250 opfa] Hit Count[0] Protocol[+udp] Index[2] Source[+194.204.1.127/32:0-0] Destination[+any:53-53] Action[+nat poolip:1,127,250 wfa] Hit Count[0] Protocol[+ipsec-esp] Index[1] Source[+194.204.1.22/32:0-0]
87/160
Destination[+any] Action[+nat poolip:1,12,250 opfa] Hit Count[0] Protocol[+ip] Index[1] Source[+194.204.1.3/32:0-0] Destination[+any] Action[+nat poolip:1,3,250 opfa] Hit Count[0] Protocol[+ip] Index[2] Source[+194.204.1.22/32:0-0] Destination[+any] Action[+nat poolip:1,12 opfa] Hit Count[0] Protocol[+ip] Index[3] Source[+194.204.1.115/32:0-0] Destination[+any] Action[+nat poolip:1,115 opfa] Hit Count[0] Protocol[+ip] Index[4] Source[+194.204.1.127/32:0-0] Destination[+any] Action[+nat poolip:1,127 opfa] Hit Count[0] Protocol[+ip] Index[5] Source[+194.204.1.0/28:0-0] Destination[+any] Action[+nat poolip:1,255 opfa] Hit Count[0]
The output of this command will display all the information inserted into the NAT rule, along with hit counts, which represent the amount of packets that have matched this rule.
4.5.3.3.
Delete Inside NAT Rules

acl nat in command:
NAT rules can be deleted individually with the no
no acl nat in [ip|icmp|tcp|udp|...] [idx]

LinkLB-enable:vfi0 [single] # no acl nat in ip 3 OR LinkLB-enable:vfi0 [single] # no acl nat in udp 3 OR LinkLB-enable:vfi0 [single] # no acl nat in tcp 3
It is also possible to remove all the inside NAT rules of a VFI at once with the
LinkLB-enable:vfi0 [single] #clr acl nat in
clr acl nat in command.
4.5.3.4.
Display RNAT/DNAT Entries
Figure 17: dnat and rnat in
88/160
Each time a new IP session is initiated from the inside of the Link LB, control blocks are created to keep a record of the session unique identifiers and on which link it is balanced. DNAT IN blocks will keep track of outgoing packets, RNAT IN will keep track of incoming (returning) packets. You can display all dynamic NAT (DNAT) and the reverse NAT (RNAT) in the inside, just typing
sh [rnat|dnat] in
Also, you can be more granular by filtering by the source/destination and the network/netmask-bits:
sh rnat in [source|destination] [network/netmask-bits] sh dnat in [source|destination] [network/netmask-bits]

LinkLB-enable:vfi0 [single] #sh rnat in LinkLB-enable:vfi0 [single] #sh dnat in source 194.204.1.3/32
4.6.
Incoming Load Balancing (ILB)

4.6.1. Intelligent DNS Facility (IDNS)
As opposed to traffic generated from the inside of the network, there is no control over the source of the incoming traffic, which makes it impossible to rely solely on network address translation to balance outside traffic. Therefore, even if network translation entries are still needed, the key element for the Elfiq Link Balancer that will allow it to balance inbound traffic is to properly manage domain name resolution (DNS) requests. Internet users that try and reach your resources will almost always try to access them with a fully qualified domain name, and not through their IP addresses. Standard DNS servers usually map resource records to a single IP address statically. Although some improvements have been made to allow DNS servers to link a resource record to multiple IP addresses, this will still limit incoming requests to round robin balancing and no verification that the link or service are available is performed by standard DNS servers. The Link LB, on the other hand, can dynamically answer DNS queries submitted by the clients according to the balancing algorithms configured for each of the resources, providing a very high level of flexibility and a much higher level of balancing. The Intelligent DNS (IDNS) module monitors all traffic going through the Elfiq Link Balancer and watches for incoming DNS requests on UDP port 53. When it sees one, it checks the request, verifies if it has a matching entry in its DNS resource record table and if it does, intercepts the requrest and answers on behalf of the DNS server for which it was destined. It is at this moment that the incoming traffic balancing is handled. Every time the Link LB intercepts a DNS request, before sending back the reply, it verifies what balancing algorithm is associated with this record, applies the algorithm and send the DNS response with the resulting IP address.
Figure 18: Flowchart of the IDNS facility DNS interception process
89/160
4.6.2.
DNS Server Configuration
The addition of IDNS resource records consists of adding resource records in the Elfiq Link Balancer, and telling the Link LB which DNS server IP addresses receives DNS requests. This will make the Link only answers to queries that were actually destined to the proper DNS server. The first step of this process is the proper configuration of your public DNS servers. There are two possibilities for this; depending on whether you host your public DNS servers internally, or whether they are hosted by an external source, such as your Internet service provider. Internal public DNS server If the public DNS server is hosted internally, a domain-level delegation will need to be made by declaring a name server (NS record) on each ISP link. This can be done at the domain registrar. No modifications to your DNS servers are needed. Any query about a balanced resource within your domain will automatically pass through the Link LB before reaching your DNS servers. While all DNS queries pass through the Link LB, the unit will verify if it has an IDNS resource record associated with that DNS query. If it does, it will intercept the query and answer with the appropriate IP address according to the balancing algorithm. This means every DNS query for which you create IDNS resource records will never reach your real DNS server. However, any query for which there are no IDNS resource record inside the configuration of the virtual forwarder interface of the Link LB will still be routed to your real public DNS server. Also, in case you bypass the Elfiq Link Balancer with the primary link (hardware LAN Failsafe intervention in a single installation), your public DNS server must have statically mapped resource records (A records) to the primary link IP addresses for each IDNS resource record. External public DNS server If one or more of your public DNS servers are hosted by an external site, then some changes will need to be performed to the current DNS entries of each of the resources that you want to be balanced by the Elfiq Link Balancer. In a typical configuration, a DNS entry for each resource would be added as an A record. This works well with most static situations, but for load balancing, we want to perform intelligent queries and resolve a DNS name to the IP of the resource on the proper link. Balancing algorithms will decide which link is the best to use. Such a resolution is impossible if the DNS queries are to be answered by an external DNS server, since that server has no information on which IP to give, let alone on which link is the best to use. Moreover, because the DNS server is not behind the Link LB, there is no way that the Link LB can intercept those DNS queries before they reach the DNS server, like it is the case when all the DNS servers are hosted internally. In order to solve this issue, we need to configure a redirection of all DNS queries for resources that we want to load balance to the Link LB, who will then be able to resolve the hostname to the desired balanced IP address. This is performed by modifying the A records on the external DNS servers that you wish to be balanced into NS records, pointing to the Link LB. This enables your external DNS server to delegate the resolution of those records to the Link LB, which will now be able to properly resolve the DNS queries according to the balancing methods configured on your Link LB. However, since the Link LB operates at the data link layer and does not have any IP addresses, queries have to be redirected to a virtual DNS server that would correspond to an IP address in the network segment behind your Link LB. No real DNS servers have to exist at this address, but as you will see in the following sections, this IP address will be used in the creation of the IDNS resource record in your Link LB, so that it knows that it should only intercept DNS queries destined for this virtual DNS server. Lets take a look at the following example, from a BIND DNS configuration, which illustrates how the zone file for your DNS could be configured, should it be hosted on the public DNS server from ISP B from our previous example:
$TTL 1h example.com. IN SOA ns1.ispb.com. hostmaster.ispb.com. ( 2005041301 ; serial yymmddxx 1800 ; Refresh 30 min. 3600 ; Retry 1hours
90/160
360000 3600 ) ; IN NS IN NS IN MX 10 mail www IN A IN A
; Expire 100hours ; Minimum TTL 1 hour ns1.ispb.com. ns2.ispb.com. mail.example.com. 194.204.1.3 194.204.1.115
As you can see from the IN NS records, the only DNS servers that are available for your domain are the two public DNS servers of ISP B, namely ns1.ispb.com and ns2.ispb.com. No mention of the Elfiq Link Balancer is present in this configuration. There are also two A records of hosts that are currently being resolved, mail and www. Below is an example of the flowchart of a typical DNS query t hat would request the IP address of the www A type record:
DNS Query: What is the IP of www.example.com DNS Answer: The IP of www.example.com is 194.204.1.3 Remote Client Remote DNS Server
Examine example.com zone file for www entry
www
IN A 194.204.1.3
Figure 19: Flowchart of a typical DNS query
Now, lets presume that we want to start to balance www, but leave the mail entry as it is. To do so, as mentioned before, we would have to change the A type record of the www entry, to an NS type record, pointing to a virtual DNS server behind our Link LB. Here is how the new DNS entry for www would look like:
www IN NS virtualdns1.example.com.
The hostname that you give to this virtual DNS server can be anything you wish, however, the DNS server must know at which IP it can reach it. Therefore, you would need to add another entry, pointing to the IP address of the virtual DNS, like the following:
virtualdns1 IN A 194.204.1.127
As mentioned before, no real DNS servers have to exist at the 194.204.1.127 IP address, but the corresponding IP will need to match the IDNS interceptor IP that you will list in your IDNS configuration. Here is the layout of the new flowchart of the DNS query, once the above changes have been performed:
91/160
DNS Query: What is the IP of www.example.com
Examine example.com zone file for www entry
DNS Answer: The IP of www.example.com is 194.204.1.115 Remote Client Remote DNS Server
www
IN NS virtualdns.example.com
What is the IP of virtualdns.example.com?

DNS Answer: The IP of www.example.com is 194.204.1.115
virtualdns IN A 194.204.1.127 Generate the DNS reply packet
DNS Query: What is the IP of www.example.com
Redirect DNS Query to 194.204.1.127
Calculate the DNS answer according to the algorithm
Is it for a configured virtual DNS server YES
NO
Let the request pass through
Verify which algorithm is associated with the resource record
YES
Is it in my IDNS RR table
NO
Let the request pass through
Figure 20: Flowchart of the IDNS facility DNS interception process
The virtual DNS server entry is still incomplete, as it only points to the IP address of a virtual DNS server of only one of your links. Another entry needs to be added per link that you are balancing, pointing to the virtual DNS server on each of those links. In this example, the virtualdns entry would end up looking like this:
virtualdns1 virtualdns2 www www IN IN IN IN A A NS NS 194.204.1.127 212.217.1.14 virtualdns1.example.com. virtualdns2.example.com.
This will instruct your DNS server to direct all DNS resource queries that point to virtualdns1.example.com to any of the available virtual DNS server IP addresses, ensuring that queries will always be properly resolved by the Link LB on each of your balanced links for optimal availability. NOTE: The virtualdns A records are created once for all the incoming services you want to balance. For each additional service, all you need is to change the resource to balance for NS records. IMPORTANT: A valid ARP or ACL ARP entry must exist in the configuration of the Elfiq Link Balancer for every virtual DNS server IP, even if no device really exists with that address. This is required so that the Link LB accepts inbound DNS traffic for processing. NOTE: Incoming SMTP mail can be configured in a full load balancing scenario using the IDNS module and NS records for the mail.example.com DNS entry. A simpler failover example for the mail could be done by adding a new MX record per additional link.
IN MX 10 IN MX 20 mail.example.com. mail2.example.com.
92/160
mail mail2
IN A IN A
194.204.1.3 212.217.1.3
Notice 1: If you wish to have your external DNS hosted by both of your providers, you will need to apply all the changes described in this section on the zone file of each DNS server. Also, if your main DNS server is hosted internally, but replicated to external slave servers, separate zones should be created, one with A records internally and a second zone with NS records externally. For a detailed example on how to set up DNS delegations on a Microsoft Windows 2003 DNS server, please refer to Appendix D. Notice 2: Best practices recommend always having two DNS Servers. If your Elfiq Link Balancer is not in failover mode (one single unit), we strongly recommend having a real DNS server in your DMZ with the IDNS virtual server IP address and static map resource records to the primary link IP addresses for each IDNS resource record. In case the Link LB is temporarily removed, the NS resolutions will be provided by the backup DNS server using the primary link.
4.6.3.
Incoming Traffic Balancing Algorithms
The Elfiq Link Balancer provides many different balancing algorithms in order to balance incoming traffic from the outside world.
4.6.3.1.
1. 2. 3. 4.
WFA: Weight First Algorithm
The Weight First Algorithm is influenced by the weight of the link. Its link selection is based on the following criteria: The weight of the link: links with the lowest weight value have the highest priority The threshold set on incoming traffic The threshold set on outgoing traffic The current status of the link (up/down)
Should two different links end up with the same value after calculations, the WFA algorithm will use both in a round robin fashion.
4.6.3.2.
RWFA: Reversed Weight First Algorithm
Reversed Weight First Algorithm is simply the opposite of WFA. The GMAC with the highest numerical value will be preferred for link selection. All other factors are the same as with WFA.
4.6.3.3.
RR: Round Robin
The round robin algorithm will always alternate its link selection, one after another. The only factor that can influence the round robin algorithm is the status of the links. Should a link become unavailable, this link will simply be discarded from the possible list of selection until it becomes available again.
4.6.3.4.
RR-nogmac: Round Robin without GMAC association
This round robin algorithm is not linked with any GMAC entry. Therefore, it will answer in a round robin fashion without checking the status of the links. Whether the links are available or not, whether they are saturated or not, it will answer the DNS requests in a round robin fashion, and this, for each configured IP address.
4.6.3.5.
OPFA: Ordered Preferred First Algorithm
The OPFA algorithm selects its link by using the order in which the RRA IP addresses are entered in the IDNS resource record. It will always use the first resource record address unless it becomes unavailable.
93/160
In the event of a link failure, it will proceed to using the next resource record address.
4.6.3.6.
1. 2. 3. 4. 5. 6.
LTFA: Least Traffic First Algorithm
The Least Traffic First Algorithm will make its link selection based on the following criterias: The incoming bandwidth of the link The outgoing bandwidth of the link The threshold set on incoming traffic The threshold set on outgoing traffic The ratio of incoming and outgoing metrics in the algorithm options The status of the link (up/down)
Should two different links end up with the same value after calculations, the LTFA algorithm will decide on which links to use in a round robin fashion.
4.6.3.7.
1. 2. 3. 4. 5. 6.
ETFA: Equalized Traffic First Algorithm
The Equalized Traffic First Algorithm will make its link selection based on the following criterias: Current utilization percentage on incoming traffic Current utilization percentage on outgoing traffic The threshold set on incoming traffic The threshold set on outgoing traffic The ratio of incoming and outgoing metrics in the algorithm options The current status of the link (up/down)
Should two different links end up with the same value after calculations, the ETFA algorithm will decide on which links to use in a round robin fashion.
4.6.4.
4.6.4.1.
IDNS Interceptors
Add IDNS Interceptors
IDNS interceptors monitor UDP port 53 on configured IP addresses to intercept the DNS requests received for resource records in incoming load balancing. The interceptor IP addresses are the virtual servers handled by the Elfiq Link LB transparently and can be used by the inside devices as well. Usually one interceptor is required per link and they are grouped together. In advanced configurations, you can associate different IDNS interceptors to different groups. The command to create IDNS interceptors is:
idns interceptor [id] [virtual dns ip] [itcgrp:id] [auth resource] [auth ttl]
Here are the parameters of the command in more details:
[virtual dns ip] [itcgrp:id]
This is the IP address of the virtual DNS server to which the DNS query is performed.
This is the Interceptor group ID we wish to assign the interceptor. This group ID binds the interceptors to the resource records. In a standard deployment, all interceptors have the same group ID.
[auth resource]
The authority name of the virtual DNS server. It is the name that was registered to redirect the NS records. This is only used by the Link LB when answering in authoritative mode, when the SOA (Start Of Authority) server is hosted in your network behind the interceptors.
[auth ttl]
The authority time to live delay of the virtual DNS server (in seconds). 94/160
For our primary and alternate links, the commands to create the interceptors are:
idns interceptor 1 194.204.1.127 itcgrp:10 virtualdns1.example.com 120 idns interceptor 2 212.217.1.14 itcgrp:10 virtualdns2.example.com 120
4.6.4.2.
Display IDNS Interceptors

sh idns interceptor command in order to
All IDNS interceptors of a VFI can be displayed with the help of the be listed and display their hit counts.
LinkLB-enable:vfi0 [single] #sh idns interceptor Index[1] Virtual DNS IP[194.204.1.127] Group ID[itcgrp:10] Authoritative Resource[virtualdns1.example.com] Authoritative TTL[120] Hit Count[0] Index[2] Virtual DNS IP[212.217.1.14] Group ID[itcgrp:10] Authoritative Resource[virtualdns2.example.com] Authoritative TTL[120] Hit Count[0]
4.6.4.3.
IDNS interceptors are removed with the no
Delete IDNS Interceptors

idns interceptor command, followed the interceptor ID. clr idns interceptor
no idns interceptor [id]

It is also possible to clear all of the existing IDNS interceptors of a VFI with the command.
LinkLB-enable:vfi0 [single] #clr idns interceptor
4.6.5.
4.6.5.1.
IDNS Resource Records

Add IDNS Resource Records
All of the Elfiq Link Balancer DNS management is centered on the IDNS resource record entries, or idns rr. You need to create one IDNS RR per incoming service you want to load balance. To add an IDNS resource record, you need to use the
idns rr command.
idns rr [itcgrp:id|virtual dns ip] [resource] [ttl] [algo] [algo options] [rra1,rra2,...] geotag:[id,...]/[id,...]/[id] isvgrp:[id,...] [multi] [noauth] [persist] [nsn]
NOTE: An IDNS RR could be created with older EOS versions without an IDNS interceptor by entering the virtual DNS IP in parameter. This previous method is still supported but it is strongly recommended to use IDNS interceptors to ease configuration, use IDNS interceptors new options and be compatible with the GeoLink functionnalities. Here are the parameters of the command in more details:
[itcgrp:id]
This is the IDNS interceptor group ID that the IDNS RR is associated. This is the IP address of the virtual DNS server to which the DNS query is performed.
[virtual dns ip]
IMPORTANT: A valid ARP table entry must exist in your configuration for each IP address specified as a virtual DNS server for which there is no real IP address behind the Elfiq Link Balancer.
[resource] [ttl]
The name of the resource record entry that you wish to add. Examples: mail.example.com, www.example.com or ftp.example.com The time to live of the resource record. Like with all other DNS entries, this affects the amount of time that DNS servers or clients will cache the entry in their DNS cache. Usually 30 seconds is a good default.
95/160
[algo]
The balancing algorithm that you wish to use for this record. Please consult the previous section for more information regarding the different balancing algorithms.
[algo options] The options that you wish to pass to the balancing algorithm, expressed as [percentage in]/[percentage out]. These are percentage values that represent the importance of incoming versus
outgoing traffic for this resource. This will be taken into account during the link evaluation calculation. The recommended guideline is to put as much importance on incoming and outgoing, and therefore to use a value of 100/100. NOTE: Algorithm options are only valid for LTFA and ETFA balancing algorithms. They are not taken into consideration for all other algorithms. If you are not using LTFA or ETFA, you must omit this option.
[rra1,rra2,...]
The IP addresses that are available for the resource record. This is the list of IP addresses, for every available link, that the IDNS can answer. In comparison with regular DNS entries, these are the IP addresses associated with A type records. A maximum of 16 IP addresses can be used for each IDNS resource record.
geotag:[id,...]/[id,...]/[id] This option is available only with the GeoLink option and is covered in
another chapter.
isvgrp:[id,...] [multi]
algorithm.
If supported by your model, this parameter associate a group of Internet Service Verificators to your IDNS RR records. This ensures testing that the services are available. This option returns all possible IP addresses for the service on top of the recommended one by the
[persist] Just as with outgoing access, some services require persistence during sessions in order to operate
properly. Therefore, should you need to force persistence on incoming traffic for one of your hosted services, append persist at the end of your IDNS RR entry. This will make sure that sets of sessions are persistent on the first link on which they have been initiated for an additional duration of 300 seconds. If you do not need persistence, simply omit this option in your IDNS RR entry. NOTE: IDNS resource record persistence is based on the source IP address and the DNS answer given by the Elfiq Link Balancer to the client. Therefore, if all of the traffic is coming from the same source, like many clients behind a firewall or a proxy server, there will not be any balancing performed between all of the queries from those clients, since they will all have the same source IP address.
[noauth] [nsn]
Ensures future DNS requests for the domain are not redirected to the Elfiq Link LB.
IMPORTANT: This option is mandatory if your DNS servers are externally hosted. This is the no such name DNS option. In certain cases, the DNS chain of events calls for an MX record request followed by an A record request for the same RR. Since the Link LB will only respond to A record requests, it is necessary that a "no such name" reply is given so that the requestor can follow with an A record request which will be handled as usual. Here is an example on how to add the incoming services in our example using different algorithms and persistence, into the VFI configuration of your Link LB:
LinkLB-enable:vfi0 [single] # idns rr itcgrp:10 mail.example.com 30 opfa 194.204.1.3,212.217.1.3 noauth LinkLB-enable:vfi0 [single] # idns rr itcgrp:10 vpn.example.com 30 rr 194.204.1.22,212.217.1.12 noauth LinkLB-enable:vfi0 [single] # idns rr itcgrp:10 www.example.com 30 etfa 100/100 194.204.1.115,212.217.1.13 persist noauth
4.6.5.2.
Display IDNS Resource Records
All IDNS resource records of a VFI can be displayed with the help of the sh idns rr command. The following is an extract of the command displaying the IDNS entries related to the example.com resource record entries:
sh idns rr
LinkLB-enable:vfi0 [single] #sh idns rr
96/160
Resource Record[vpn.example.com] Type[local] Virtual DNS IP[itcgrp:10] TTL[30] Algorithm[round-robin] Hit Count[0] Persistence[disabled] Persistence Cache Hit Count[0] Auth RRA[no] Multi RRA[no] Nsn[no] Rra0[ip [194.204.1.22], type [local], hc [0], gmac [gmac1]] Rra1[ip [212.217.1.12], type [local], hc [0], gmac [gmac2]] Resource Record[www.example.com] Type[local] Virtual DNS IP[itcgrp:10] TTL[30] Algorithm[etfa] In[100 %] Out[100 %] Hit Count[0] Persistence[enabled] Persistence Cache Hit Count[0] Auth RRA[no] Multi RRA[no] Nsn[no] Rra0[ip [194.204.1.115], type [local], hc [0], gmac [gmac1]] Rra1[ip [212.217.1.13], type [local], hc [0], gmac [gmac2]] Resource Record[mail.example.com] Type[local] Virtual DNS IP[itcgrp:10] TTL[30] Algorithm[opfa] Hit Count[0] Persistence[disabled] Persistence Cache Hit Count[0] Auth RRA[no] Multi RRA[no] Nsn[no] Rra0[ip [194.204.1.3], type [local], hc [0], gmac [gmac1]] Rra1[ip [212.217.1.3], type [local], hc [0], gmac [gmac2]]
4.6.5.3.
Delete IDNS Resource Records

no idns rr command, followed by the virtual DNS server IP and the
IDNS resource records are removed with the resource record.
no idns rr [itcgrp:id|virtual dns ip] [resource]

LinkLB-enable:vfi0 [single] #no idns rr itcgrp:10 www.example.com
It is also possible to clear all of the existing IDNS resource records of a VFI with the
LinkLB-enable:vfi0 [single] #clr idns rr
clr idns rr command.
4.7.
Advanced Options and Tools

4.7.1. Child GMACs
A GMACs key identifier for a link is the routers MAC address which must be unique. In some cases where two links are from the same provider and do not have a dedicated IP segment/block and router, they can have the same gateway MAC address. The Link LB refuses to create a second GMAC with a duplicate MAC address. Some provider configurations (especially cable links but sometimes DSL and WI-FI) have the local modem bridging to a central router and all connected modems share the same central router. The onsite equipment is not a router and provides one or non-contiguous IP addresses. Two links of the same provider will connect to the same router and have the same MAC address. The link is shared and all cable modems are connected at the same network layer 2. NOTE: It is important to understand that using links from the same provider/technology will bring you additional bandwidth but no failover/redundancy because the chances are that both links can be down at the same time. Elfiq recommends using links from different providers and different technologies. In order to use these links with the Elfiq Link LB you will need to create the first GMAC as a standard GMAC and the second link to the same ISP will be a "child gmac". This is simply done by specifying the parent gmac ID instead of the auto parameter. gmac [id] [auto|mac address|chn:id|gmac:id] [description] [ip address]/[netmask-bits]|[dhcp:id|pppox:id] [weight] [speed (kb/s) in] [speed (kb/s) out] [layer 2 adj] [poll ip address]:[tcp port],[poll ip address2]:[tcp port2] [% threshold in]/[% threshold out]
gmac 4 gmac:3 cable_modem2 dhcp:2 4 6000 1000 0 0.0.0.0:0,0.0.0.0:0 95/95
IMPORTANT: If the child GMAC is assigned to a different outside interface than the parent GMAC, the child GMAC will calculate its own link metrics (especially current link speed in/out) for algorithm decision making. Otherwise, the child GMAC will use its parent GMAC link metrics.
97/160
4.7.2.
4.7.2.1.
Route Policy Based Balancing

Network Route Policies
To provide greater control over the management of traffic balancing, the Elfiq Link Balancer also allows the integration of network route policies that will affect traffic management as well as the balancing algorithms. Such entries become useful when some of your links should be prioritized for accessing certain networks such as access to private networks which also allow access to the Internet. It can also be used to prefer specific links, when traffic is coming from, or going to, specific IP addresses on the internet. For example, for a specific destination on the internet the "round trip time" is 3 times better on ISP B link than on ISP A, you could then configure a route ip entry for this destination in the Link LB. The route policies affect both the NAT and the TAG balancing. If the preferred route is currently unavailable (because the GMAC is disabled) the Link LB will behave as usual and balance the packets normally with algorithms. The route policies also affect the IDNS module, if a client queries for a domain name handled by the Link LB and his source IP address fits in a preferred route ip entry, the Link LB will take this information in consideration for the DNS answer. Each route policy that is created is always associated with the GMAC through which this network is favored. IMPORTANT: Route policy based balancing will be evaluated before any balancing algorithms, for as long as the GMAC associated with the route is available. Should the GMAC become unavailable, all the route policies associated with it will no longer be evaluated.
4.7.2.2.
Activate the Route Policy Feature
In order to use route policy based balancing, the appropriate feature must first be activated in the configuration of the VFI. Even if route policy rules have been created, they will not take effect until the feature has been activated. The route_pref_algo is the feature that must be activated to enable the route policies to affect the balancing algorithms. It can be enabled with the feature route_pref_algo enable command, and be disabled with the feature route_pref_algo disable command.
LinkLB-enable:vfi0 [single] #feature route_pref_algo enable LinkLB-enable:vfi0 [single] #feature route_pref_algo disable
The route_pref_no_acct extra feature allows a change in the GMAC account table that will omit the accounting of all traffic balanced through route policy based balancing, in order to fine tune the accounting to your preferences. Therefore, any data that matches a route policy based rule will not affect the packet counters for the corresponding GMAC.
4.7.2.3.
Static IP route policies are created with the route ip [network/netmask-bits] [gateway]
Create Static Route Policy Rules

route ip command.
The first parameter for the command is the IP address of the network and its subnet mask bit count. The second parameter is the gateway, which must be the IP address of the router of the GMAC through which the data should be sent.
LinkLB-enable:vfi0 [single] #route ip 22.22.22.0/24 194.204.1.1
98/160
4.7.2.4.
Display Static Route Policy Rules
Static IP route policies are displayed with the sh route ip command. However, all IP route policies are displayed, and not just the static ones. The Type value in the commands output will describe if the route has been added statically or through BGP. sh route ip [network/netmask-bits] The sh route ip command can also take a network address and subnet mask bit count as optional parameters, in order to filter the routes display. This is especially useful when a large quantity of routes have been added into the Elfiq Link Balancer.
LinkLB-enable:vfi0 [single] #sh route ip Network[22.22.22.0/24] Gateway[194.204.1.1] Type[static] Hit Count[0]
4.7.2.5.
Static IP route policies are deleted with the mask bit count as parameters. no route ip [network/netmask-bits]
Delete Static Route Policy Rules

no route ip command, which takes the network address and the subnet
LinkLB-enable:vfi0 [single] #no route ip 22.22.22.0/24
All the static route policy rules can also be deleted at once with the clr
LinkLB-enable:vfi0 [single] #clr route ip
route ip command.
4.7.3.
Quality of Service (QoS)
Quality of Service can take multiple forms within an enterprise to ensure delivery of key traffic across networks. The Link LB can integrate QoS in your internet or WAN infrastructure in order to guarantee a given rate or to apply a ceiling limit to chosen traffic flows before transmitting the packets to one of your links. Because of the Elfiq Layer 2 integration, it is typically the only device to be aware of the bandwidth availability and usage on each link. Therefore, it becomes important to properly integrate QoS in the Link LB for your key traffic based on your network policies. NOTE: QoS needs to be enabled or disabled as a feature of the VFI (Virtual Forwarder Interface). It is not part of the default balancing group of features.
4.7.3.1.
Hierarchical Token Bucket
A well-known way to apply QoS is through Traffic Shaping. The Link LB uses the Hierarchical Token Bucket method which gives the ability to guarantee bandwidth or to apply a ceiling limit as well as to handle burstable link. A rate ceiling is a way to restrict selected traffic flows to a specified maximum amount of bandwidth. The ceiling rate limit is enforced at all times and cannot be breached even if there is no other traffic on the link. A bandwidth rate guarantee is a way to ensure the specified amount of bandwidth to a selected traffic flow when a link is saturated. Guaranteed rates are enforced only when necessary. The L ink LB can loan unused bandwidth to other traffic flows temporarily. On the other hand, if the link is saturated and new sessions are established, the Link LB will slow down other traffic types to make place for the traffic up to the guaranteed rate. Any bandwidth requirement beyond the guaranteed rate will be unregulated by the QoS engine and subject to free TCP/IP competition for the bandwidth. The traffic shaping slows down the traffic flows by dropping packets if too much data is sent across a link. In effect this will gracefully reduce the TCP throughput but the same mechanism is employed for all traffic types (even for protocols that do not have a delivery guarantee through retransmission).
99/160
When the QoS feature is enabled while there are no existing gmac qos definitions in the configuration, the Link LB automatically creates a gmac qos definition for each GMAC.
The syntax for this command is:
gmac qos [mac address|id] [tc_htb] [speed (kb/s) in]/[speed out],[burstable speed (kb/s) in]/[burstable speed (kb/s) out]
(kb/s)
By default, the Link LB will add a gmac qos equivalent to the declared bandwidth for each GMAC. If needed, you should adjust the gmac qos queue to the links true bandwidth as opposed to the ISP advertised bandwidth. The parent queue size is important for two different key aspects:
1- If the parent queue is set too low (smaller than the real link capacity), the Link LB will artificially restrict the available bandwidth because you cannot transmit more bandwidth over a given GMAC than the parent queue size. 2- If the parent queue is set too high (bigger than the link capacity), the Link LB will not correctly protect guaranteed traffic flows since it will calculate that there is still bandwidth left to service more traffic even if the link really is filled up to capacity.
The gmac qos command structure allows a user to enter the total capacity of the link speed and also its burstable speed in case you have a link that allows this. The command structure is built so that the [speed (kb/s) in]/[speed (kb/s) out] values indicate the link saturation threshold and the [burstable speed (kb/s) in]/[burstable speed (kb/s) out] values indicate the maximum available physical link bandwidth. When configuring a burstable bandwidth link, the [speed (kb/s) in]/[speed (kb/s) out] values should typically be configured with the ratings guaranteed by your provider and the [burstable speed (kb/s) in]/[burstable speed (kb/s) out] values should be configured with the maximum available bandwidth. When configuring a non-burstable link the [speed (kb/s) in]/[speed (kb/s) out] and the [burstable speed (kb/s) in]/[burstable speed (kb/s) out] should be configured with the true bandwidth rating of the link. User configured QoS queues need to be added for each traffic class you wish to have a guaranteed rate or a ceiling rate limit.
qos [id] [description]
[tc_htb]
[rate_dl/rate_up,ceil_dl/ceil_up]
[gmac:id]
While the syntax looks the same as the gmac qos rule then meaning of each parameter is slightly different: rate_dl/rate_up: Guarantee (rate value) in kb/s for upload and download. ceil_dl/ceil_up: Restrict (ceil value) in kb/s for upload and download. The qos definitions defines each bucket or queue, a numeral ID and the amount of bandwidth you wish to have for a given type of traffic per GMAC. A typical configuration needs one qos queue definition per GMAC for a given traffic flow. This is required because the links have different bandwidth ratios.
100/160
Traffic selection is made with the traditional ACL rules using the qos:ID1,ID2,ID3 markers at the end of the relevant ACL entries. The IDs in the marker refer to the numeral ID of each definition you created. It is worth mentioning that the qos queues or buckets apply to all selected traffic as a whole and not on a per session basis. NOTE: The sum of the guarantees in qos rules should not exceed the related gmac qos parent queue size, doing would impact the bandwidth reservation and loan algorithm and prevent the guarantee to be correctly enforced.
4.7.3.1.
Differentiated Services
The Link LB also supports DiffServ markings. When using DiffServ marking it is important to know that while the Link LB can classify packets, it will not police or shape the traffic based on the markings. The next-hop gateways need to be configured to read and process the traffic according to the markings made by the Link LB for a working setup.
The Link LB: CAN mark outgoing packets with DiffServ markings based on traffic type. CANNOT recognize existing DiffServ markings on outgoing packets. WILL NOT affect (hinder, destroy, remove) existing DiffServ markings on outgoing packets, unless the configuration re-marks. CAN mark incoming packets with DiffServ markings based on traffic type. CANNOT recognize existing DiffServ markings on incoming packets. WILL NOT affect (hinder, destroy, remove) existing DiffServ markings on incoming packets, unless the configuration re-marks.
DSCP Classes and Per Hop behavior
Expedited Forwarding (EF) is given priority over any other group. Networks should limit the amount of traffic given this priority to a maximum of 30% of the link capacity in order to prevent causing an overload of EF traffic. Assured Forwarding (AF) will ensure delivery as long as the total amount of traffic doesnt exceed the subscribed rate for the link. Classes are not levels of priority, but simply different "containers" that allow more flexibility in configuration.
Class 1 Low drop Medium drop High drop af11 af12 af13
Class 2 af21 af22 af23
Syntax: qos [id] [dsmark] [diffserv_code] [gmac:id] [description] Traffic selection is made with the traditional ACL rules using the qos:ID1,ID2,ID3 markers at the end of the relevant ACL entries. The IDs in the marker refer to the numeral ID of each definition you created. Link LB Administrator Guide EOS 3.5.2 and higher Document Version 3.04 - July 2012 101/160
4.7.4.
Deep Packet Inspection (DPI)
DPI stands for Deep Packet Inspection and is also known as the Elfiq App Optimizer module. DPI module can be activated on supported models with the appropriate license. The DPI engine works on layer 7 of the OSI model. This is an application and sub application identification process, as opposed to a content-filtering identification. DPI can assign the session to a pre-defined QoS Queue or just drop the session. Sessions are handled by the VFI in the traditional way, and a copy is sent to the DPI engine for identification. Once a session is identified, the Link LB goes back to the DPI group to find a suitable signature match. If the signature is found, the attached Action is carried as configured. Multiple groups can be set to carry different actions to different signatures. ACLs and Groups can be used to carry different actions for the same signature based on the session information (IP, Port or Protocol). NOTE: DPI needs to be enabled or disabled as a feature of the VFI (Virtual Forwarder Interface). It is not part of the default balancing group of features. The syntax for this command is:
## feature feature dpi enable
4.7.4.1.
Licensing
The Link LB licensing was upgraded to support DPI. There are new licenses that have been created specifically for the DPI module, these licenses are optional and separate from the main Link LB license. New licenses (both LINKLB and DPI) can now be applied at any time and do not require a reboot to activate. The syntax for this command is:
LabUnit-enable: [master] #syst license [license name] [license key]:[extended key] Examples: license LINKLB 8157628B51EXAMPLEB2630E35B34E70C
or
license DPI 9481A62AB0EXAMPLE8E326620D8AD8C8:7F70EC6088EXAMPLEF8F7FB2F04E14C1

They can also be overwritten simply by re-applying a new license "on top" of the previous one. Licenses are now part of the "syst" configuration and are therefore saved and displayed with the configuration. This will definitely help when dealing with backups/restore of the same physical unit but special care needs to be taken when porting configurations from one unit to the next (copy-pasting). DPI licenses differ from the traditional Link LB licenses because they contain an "expiration date". The DPI license will need to be renewed by the client in order for the DPI module to stay active at all times. Should a license not be renewed, "Severity 1" alerts will be logged and sent by email by the Link LB when we get closer to the expiration date (1 message at 60 days, 1 message at 30 days, 1 message per day in the last 15 days, and 1 last message upon expiration). NOTE: You can check the status of your licence using sh
licence command.
LabUnit-mgmt:system [master] #sh licence Name[LINKLB] Key[********************************] Feedback[key ok, DEMONSTRATOR, Evaluation only] State[ok] Type[Demo] Desc[LinkLB-AR-VFI2-FO-GEO-SH-TP-EXT] Hw Model[LB2500E] Version[3] Resource0[vfi0] Resource1[vfi1]
102/160
Exp Key[none] Name[DPI] Key[********************************] Feedback[key ok, DEMO] State[ok] Exp Key[61C27689F3B3A13192D0D1B6E7A66B32] Exp Version[3] Exp Type[demo] Exp Creation Date[2012-05-24] Exp Date[2017-07-21]
4.7.4.2.
Deep Packet Inspection module
The VFI module and the DPI engine run side-by-side as opposed to being in an inline disposition. Sessions are therefore handled by the VFI in the traditional way and a copy is sent to the DPI engine for identification. Multiple packets are typically required to identify a session with confidence which means that all the load balancing decisions will have been made by the time the Link LB can establish a DPI identification. Once a session has been identified, VFI stops sending packets to the DPI engine for this session. The maximum number of packets sent to the DPI engine for any given session is configurable and set to 32 by default. To change the number of packets you use the command:
dpi option [id] [max_packets] [5-64]

acl dpi rules for incoming and outgoing traffic need to be created. These access lists may be based on the protocol name, port number, IP source, IP destination. Certain traffic types (like short DNS requests) can override the inspection process by using the pass argument. You can inspect or pass this specified type of traffic. Use acl
dpi command:
## Acl dpi inside for outgoing traffic acl dpi in [+|-][ip|icmp|tcp|udp|...] [idx] [+|-][source ip]/[netmaskbits]:[start port]-[stop port] [+|-][dest ip]/[netmask-bits]:[start port][stop port] [+|-][inspect|pass] [dpigrp:id,...] ## Acl dpi outside for incoming traffic acl dpi out [+|-][ip|icmp|tcp|udp|...] [idx] [+|-][source ip]/[netmaskbits]:[start port]-[stop port] [+|-][dest ip]/[netmask-bits]:[start port][stop port] [+|-][inspect|pass] [dpigrp:id,...]
You can create different groups of applications. For traffic types that are sent to the DPI engine with the argument, the next step consists of recognizing the application. This is done with the
inspect
dpi group commands. The
signature parameter will hold the different applications for which an action will be applied. ## DPI Signature Group dpi group [id] signature [peer_to_peer|messaging|mail|social_networking|...]
Dpi groups may be created for individual signatures, signature groups or for both.
103/160
You can see the list of sgnatures and signature grous using the command: sh
dpi signature
In this example there is a signature group database and there are two signatures in this group mysql and oracle
LabUnit-enable:vfi0 [master] #sh dpi signature Application[collaboration] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[ctrxjedi] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[ctrxonln] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[database] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[mysql] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[oracle] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[file_sharing] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[astraweb] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[dropbox] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[file_transfer] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[ftp] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[ftps] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[games] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[battlnet] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[xbox] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[mail] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[exchange] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[gmail] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[messaging] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[aol_im] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[gtalk] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[network_monitoring] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, Application[snmp] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[tivoli] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[networking] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[3comtsmx] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %] Application[8021q] Sessions[0, 0.00 %] Total Outgoing (MB) [0.00, 0.00 %]
The action parameter will then carry out the intended effect, usually classify or drop. Using
classify parameter you can assigne a QoS to a group.
## DPI Action Group dpi group [id] action [drop|classify]

Usage example:
## Dpi action group dpi group 1 signature skype,skypauth,skypep2p,skyprobe dpi group 1 action classify qos:11,21 dpi group 2 signature peer_to_peer dpi group 2 action drop
To find out more DPI commands go to vfi0 module as enable user and hit help
| se dpi command:
Labunit-enable:vfi0# help | se dpi

LabUnit-enable:vfi0 [master] #help | se Searching for [dpi]... acl dpi in Insert acl dpi out Insert clr acl dpi in Remove dpi new dpi access-list applied to inside new dpi access-list applied to inside all dpi inside ip access-lists
104/160
clr acl dpi out clr dpi group clr dpi stats dpi group dpi option no acl dpi in no acl dpi out no dpi group no dpi option sh acl dpi in sh acl dpi out sh dpi group sh dpi option sh dpi signature sh dpi stats LabUnit-enable:vfi0 [master] #
Remove all dpi outside ip access-lists Remove all dpi action groups Clear DPI statistics Add a dpi action group Set the number of packets per session to be inspected Remove a dpi inside ip access-list by index Remove a dpi outside ip access-list by index Remove a dpi action group element or the whole group Remove a dpi option Display all dpi inside ip access-lists Display all dpi outside ip access-lists Display dpi action group Display dpi options Display the list of supported DPI signatures Display the DPI statistics
4.7.5.
4.7.5.1.
TAG Load Balancing

Activate TAG Features
TAG load balancing is an alternate method to NAT load balancing. It is used primarily when you have multiple routers that are able to route all of your IP addresses. In the most common scenario, there are two or more private WAN links per site to interconnect two or more offices. The WAN routers are all able to route any internal IP addressing so the Link LB doesn't need to change the source IP addresses on the fly (as opposed to NAT load balancing). The Link LB can balance packets to the WAN link that is best suited to handle each specific session. Balancing is always done on a per session basis. If a Link LB is installed at the remote site in TAG load balancing, it will create control blocks for its incoming sessions and ensure packets are using the same link in both directions. Some network protocols cannot be NATed easily because they are split over many different sessions with different port numbers and some of the protocols also negotiate session information inside the IP packets which makes it very hard to follow. These "intra-network" protocols are normally used on a WAN Link so Elfiq recommends that you use TAG load balancing. TAG load balancing can also be used with Internet links in some specific implementations. TAG based implementations require to enable features in the VFI stack and disable the NAT features. TAG features can be activated for incoming and outgoing sessions independently.
Name[tag_group] Status[disable] Name[tag_in] Status[disable] Name[tag_out] Status[disable] Name[tag_nat_exclusive] Status[disable]
When a router (GMAC) supports both public and private links, the usage of both NAT and TAG balancing rules is possible with a child GMAC. It is also possible to specify if a packet being NAT can also be TAG further in the VFI stack. This is specified with the tag_nat_exclusive feature.
4.7.5.2.
Create Inside TAG Rules

tag in command:
Inside TAG rules are a type of access-list and are created with the acl
acl tag in [+|-][ip|icmp|tcp|udp|...] [idx] [+|-][source ip]/[netmask-bits]:[start port]-[stop port] [+|-][dest]/[netmask-bits]:[start port]-[stop port] [+|-][pass|tag] [gmac:id,...] [etfa|ltfa|wfa|wfa-etfa|rr|opfa] [qos:id,...] [iagrp:id] When creating inside TAG rules, the first element that you need to specify is the protocol that you wish to balance followed by an access-list index. The list of supported protocols is: UDP ICMP
105/160
TCP IGMP GRE IPSEC-ESP IPSEC-AH SKIP EIGRP OSPF L2TP IP
NOTE: TAG inside access-lists are regrouped by protocol in the configuration and also verified with the same order. The next parameter that needs to be specified is the source IP address and ports from which the traffic is coming. This tells the Link LB on which sources it must apply this translation rule. The following parameter is the destination address and port followed by the action to perform a TAG of the session. The next parameter is the list of GMAC IDs (no pool IP is required since packets are not source NAT), separated by commas. To specify GMACs, you must first precede the IDs of the GMACs with the gmac : directive. Finally, the last parameter you need to add is the balancing algorithm that you wish to use for this rule. NOTE: TAG and NAT algorithms are the same. Refer to section 4.5.2 for a description of the available algorithms. NOTE: The default inactivity timeout is 300 seconds for TCP, 30 seconds for UDP and 5 seconds for the other protocols. NOTE: TAG outside control blocks are automatically created for incoming sessions when the tag feature is enabled.
4.7.5.3.
Display Inside TAG Rules

sh acl tag in command:
All the TAG rules of a VFI can be displayed with the
LinkLB-enable:vfi0 [single] #sh acl tag in Protocol[+ip] Index[1] Source[+any] Destination[+any] Action[+tag gmac:1,2 etfa] Hit Count[0]
The output of this command will display all the information inserted into the TAG rule, along with hit counts, which represent the amount of packets that have matched this rule.
4.7.5.4.
Delete inside TAG Rules

acl tag in command:
TAG rules can be deleted individually with the no no acl tag in [ip|icmp|tcp|udp|...] [idx]
LinkLB-enable:vfi0 [single] # no acl tag in ip 1
It is also possible to remove all the inside TAG rules of a VFI at once with the
LinkLB-enable:vfi0 [single] #clr acl tag in
clr acl tag in command.
4.7.5.5.
Display RTAG/DTAG Entries
Each time a new IP session is initiated from the inside or the outside of the Link LB, control blocks are created to keep a record of the session unique identifiers and on which link it is balanced. DTAG IN blocks will keep track of outgoing sessions/packets, RTAG OUT will keep track of incoming (returning) sessions/packets. You can display all dynamic RTAG (DNAT) and the reverse NAT (RNAT) in the inside, just typing sh dtag in
106/160
sh rtag out Also, you can be more granular by filtering by the source/destination and the network/netmask-bits: sh dtag in [source|destination] [network/netmask-bits] sh rtag out [source|destination] [network/netmask-bits]
LinkLB-enable:vfi0 [single] #sh dtag in LinkLB-enable:vfi0 [single] #sh dtag in source 194.204.1.3/32
4.7.6.
4.7.6.1.
Internal Condition Verificator (ICV)

About ICV
The Internal Condition Verificator (ICV) feature allows organizations to develop advanced and customized conditionbased configurations. Common uses for the Internal Condition Verificator include: Taking action when specific conditions appear such as link failure or link saturation Modify traffic algorithms based on the time of day Optimize utilization on burstable links or links with data transfer limits Reset statistics and counters at a specific date/time
The ICV command describes a test to run and can only have a true or false status based on the results of the test. For example, test whether the second link usage has exceeded 200 Gigabytes or if the current date/time is contained within business hours (mon-fri 9am-5pm). In a more advanced setup, a number of conditional tests may need to be performed before an action can be taken. ICVs can be chained together with logical operators (and/or) to build comprehensive tests encompassing multiple conditions. This layer of flexibility also means that there is usually more than one way to configure the wanted set of conditions to achieve the target effect. Once ICVs are configured and the tests give the expected results, ICV Action commands can be used to program the desired effects in the Link LB unit. The ICV Action configuration uses the resulting status from an ICV to execute a configuration change when the correct conditions are met. ICV Actions can have a wide range of effects, for example: enabling or disabling a GMAC, change the GMAC threshold values or reset the GMAC statistics. Another potential use for an ICV Action is to alter the ACL lists to modify load balancing strategies. This is done through ICV Action groups. The ICV Action groups are not explicitly defined but rather implied by their usage in an ICV Action rule. Their objective is to activate or deactivate ACLs. Marking the relevant ACLs in your configuration is as simple as appending the ICV Action group number to the target ACLs. NOTE: Deactivated ACLs remain visible in the configuration but stop processing new sessions. Sessions that were already load-balanced prior to an ACL activation/deactivation keep the same control blocks.
4.7.6.2.
Syntax for ICV
icv [id] [description] [expression|timer.[trigger_on|trigger_off|state_on|state_off]] [monfri|weekend|daily|yyyy/mm/dd|dd] [hh:mm] [hh:mm]

The [id] is a numerical identifier. This number will be used as a reference when chaining ICVs or using ICV actions. The [description] is an explanation label that will help you remember its purpose (no spaces are allowed in the label).
107/160
The [expression|timer.[trigger_on|trigger_off|state_on|state_off]] section refers to the expression of the condition that will be checked by the Link LB. There are two major types of conditions: state and time. For those based on state, the expressions syntax will look like this: vfix:gmac:x.state_down. The parameters are the index number of the target vfi module (virtual forwared interface) followed by the component and its index number, followed by the relevant status check. The passing from one state to another, known as a trigger, can also be verified as a condition. Unlike the state, a trigger is the infinitely short moment when a condition changes, as opposed to the relatively long duration of that condition. Time-based expression will look like this:
timer.[trigger_on|trigger_off|state_on|state_off]][monfri|weekend|daily|yyyy/mm/dd|dd] [hh:mm] [hh:mm] The following example is designed to

return a true value when the current date/time is contained within business hours (mon-fri 9am-5pm).
icv 1 business_hours timer.state_on mon-fri 09:00 08:00

The time-based ICVs always use ISO 8601 24h format time (hh:mm). The trigger_on|trigger_off is used when you want to make an action happen only once as opposed to a condition that you wish to be continually true or false for the duration of the period. For example, a timed based ICV to add a log entry to the system logs.
4.7.6.3.
ICV logical concatenation
Multiple ICVs can be chained together to get a precise result out of a conjunction of multiple conditions. The ICV command syntax varies depending on the operator used.
Operator or and gt lt ge le eq Definition True if one or the other ICV is true True when both ICVs are true Greater than (>) Lower than (<) Greater or equal to (>=) Lower or equal to (<=) Equal to (=) Example icv 1 one_or_the_other icv:2 or icv:3 icv 1 both_are_true icv:2 and icv:3 icv 1 totalmb_limit vfi0:gmac:1.total_mb gt 50000 icv 1 low_rtt icv:1 lt 50 icv 1 totalmb_limit vfi0:gmac:1.total_mb ge 50000 icv 1 low_rtt icv:1 le 50 icv 1 average_in vfi0:gmac:1.usage_avg_in eq 60
You can combine multiple ICV verifications using the above expressions in order to get a precise result based on different situation. For example, you may want to combine the 2 following situations: 1. Is the secondary GMAC currently over 50 GB of download? AND 2. Is the primary link up and running? For those 2 situations we get those ICV: 1. icv 1 total_download_mb_limit vfi0:gmac:2.total_in_mb gt 50000 2. icv 2 gmac_down vfi0:gmac:1.state_up Those ICV will each return true or false based on the result of the verifications. A third ICV can be configured to evaluate the results of the first two: 3. icv 3 if_download_limit_reached_AND_primary_link_up icv:1 and icv:2 Link LB Administrator Guide EOS 3.5.2 and higher Document Version 3.04 - July 2012 108/160
Then we configure the action based on the conjunction of the two ICV: 1. icv action 1 disable_gmac_2 icv:3 true vfi0:gmac:2.state_disable
Remember that the ICV Actions do not imply their reverse action, the rule above by itself would work perfectly the first time, but then your second GMAC would remain down forever (or until you reboot the Link LB) because there are no rule that says otherwise. Even the condition result becomes false, the Link LB will not automatically do the opposite of the true rule. You need to explicitly configure the opposite rule to re-enable the secondary link whenever the condition is false. 2. icv action 2 enable_gmac_2 icv:3 false vfi0:gmac:2.state_enable As you can see ICV Actions and their ICV Action groups brings flexibility and power to the ICV mechanic.
4.7.6.4.
Syntax for ICV Action
Based on the results of the verifications made by the ICVs an ICV Action will apply an action or enable/disable an action group. Here is the syntax:
icv action [id] [description] [icv:id] [true|false] [action]

Lets have a closer look to each element of that command: The first element is the [id] which is a numerical number that represents a single ICV Action. The [description] is a simple explanation label that will help you remember its purpose (no spaces are allowed in the label). The [icv:id] specifies which ICVs results will the ICV Action depend on. If you need to chain together ICVs, only the last ICV will be specified here. The [true|false] parameter is used to specify whether to act on a true or false IC V verification result. It is important to note that the opposite action is never implied and therefore it usually needs to be configured as well. Typically this means the whenever a true ICV results in a given action, the false result needs to be confi gured for the opposite action. For example, if you wish to change the load balancing rules during business hours for a given set of special configuration rules, you also need to configure an action to disable those special configuration rules once business hours come to an end. This last part of the command is the actual action to be performed. It may look like this:
vfi0:iagrp:1.state_enable. This action means that the ICV action will enable the ICV Action group 1 (iagrp:1) in the VFI0 module. The result of this group activation is the activation of each configuration line marked with iagrp:1 in the VFI0 configuration. If this is applied to an acl, it means that the acl will become enabled. For the list of
all possible actions, you can see the table below. An ICV Action Group (IAGRP) is a set of configuration markers noted in this format: iagrp:x where x is an index number. The groups are not specifically created in the configuration and are simply evoked by their usage in ICV Action rules of ACL rules. Multiple events can trigger the same effect through different actions. If we look at this action: vfi0:iagrp:1.state_enable, it refers to iagrp:1 which can then be applied to the end of an acl. Here is the acl syntax when attached to its iagrp:id:
acl nat in +tcp 3 +194.204.1.3/32:0-0 +any:80-80 +nat poolip:1,10 wfa qos:10,20 iagrp:1
This acl nat in +tcp 3 will be applied whenever the ICV Action group 1 is enabled. One or many ICV Actions can alter the state of the ICV Action group. When disabled, the group and related ACLs will remain in the configuration but will not be used by new sessions.
109/160
4.7.6.5.
ICV/ICV Action Examples
Here are some examples to better understand how the ICV and the ICV Action work together, and how they interact with the configuration. This first example is a configuration to rate limit the browsing bandwidth during business hours (9AM to 5PM). The first step would be to create an ICV that will return a true result during business hours:
icv 1 business_hours timer.state_on mon-fri 09:00 08:00

This ICV will return true (timer.state_on) Monday through Friday between 09:00 and 17:00. Note that the expression of time is in this format: [start time (24-hour standard)] [duration in hours:minutes] Therefore, the ICV would be configured with 09:00 to express the time at which to start counting and 08:00 to express the duration of the time window. Here is the ICV Action that will respond to the state of the ICV above:
icv action 1 throttle_down_browsing icv:1 true vfi0:iagrp:1.state_enable icv action 2 unlimited_browsing icv:1 false vfi0:iagrp:1.state_disable
The first ICV Action will look at the returned value of the ICV with id 1 ( icv:1). When the returned value is true, it will enable iagrp (ICV Action group) id 1 within the vfi0 (vfi0:iagrp:1.state_enable). As a result, this ICV Action group will in turn enable each configuration line to which it is attached. The second ICV Action rule will also look at the return value of the ICV with id 1 (icv:1). When that value is false, it will disable the iagrp (ICV Action group) id 1 within the vfi0 (vfi0:iagrp:1.state_disable). This ICV Action group will in turn disable each configuration line to which it is attached. With this ICV and its related ICV Action, we can start applying the iagrp:1 (ICV Action group 1) to different parts of the configuration. The web browsing traffic can be identified with the help of an acl nat in rule that will select TCP traffic with a source IP of the firewall on any source port going to any destination IP on port 80. Since the goal is to apply a ceiling (or limitation) to the bandwidth usage, we will use QoS markers to be applied to the relevant acl nat in rule. Because this rule will be enabled or disabled based on the state of the iagrp, we will create a second rule to catch the traffic whenever the rate-limiting ACL is disabled. The first ACL will rate limit the bandwidth with QoS during business hours with the iagrp:1 marker, and the second one with no QoS and no iagrp:1 marker. Because ACLs are always read by the Link LB from top to bottom, the second rule will not be used whenever the first one is enabled.
acl nat in +tcp 3 +194.204.1.3/32:0-0 +any:80-80 +nat poolip:1,10 etfa qos:10,20 iagrp:1 acl nat in +tcp 4 +194.204.1.3/32:0-0 +any:80-80 +nat poolip:1,10 etfa
110/160
qos 10 tc_htb 1/1,1024/1024 gmac:1 catchall_qos_gmac1 qos 20 tc_htb 1/1,768/768 gmac:2 catchall_qos_gmac2
4.7.6.6.
ICV notes and considerations
The ICV can work across multiple VFI if needed. As an example, if you have 2 VFI, you can change the rules in vfi0 based on the state of the gmac in vfi1.
Also, it is possible to use ICV to monitor the state of exported data in a GEO environment. For example, you can apply a change based on the state of a gmac shadow located at the other site.
Another example in a GEO environment is to use ICVs to determine the ultimate destination of inbound traffic. Depending on the state of an ISV, the Link LB can change the acl nat out rules in order to select the best possible destination. In other words, if all the internet links at the primary site are down but the servers are still running, we can receive traffic at the DR site for those servers and send it over to the primary site through a WAN link. However, if the primary servers are down as well, then we can send the incoming traffic to the backup servers at the DR site.
IMPORTANT: When using time based ICV, always ensure that your NTP configuration is complete and pointing to a valid NTP server.
4.7.6.7.
ICV Tables
The following tables are designed to help define the different logic tests that can be applied and also the actions that can be taken based on the results of those tests. This first table contains all the syntax and examples for the ICV conditions.
Expression (where x is an ID)
Definition
Type of value returned True or false
Example
icv:x
True when referenced ICV is true True when GMAC comes up True GMAC down when goes
icv 1 reference_icv vfi0:gmac:1.state_up icv 2 depends_on_icv_1 icv:1
vfix:gmac:x.trigger_up
Momentarily true Momentarily true
icv 1 up_instant vfi0:gmac:1.trigger_up
vfix:gmac:x.trigger_down
icv 1 down_instant vfi0:gmac:1.trigger_down
vfix:gmac:x.state_up
True while GMAC is up True while GMAC is down Holds the current total data transferred for other ICVs to reference
True or false
icv 1 current_up vfi0:gmac:1.state_up
vfix:gmac:x.state_down
True or false
icv 1 current_down vfi0:gmac:1.state_down
vfix:gmac:x.total_mb
Integer
icv 1 totalmb_var vfi0:gmac:1.total_mb icv 2 high_totalmb icv:1 gt 50000
111/160
Definition
Type of value returned Integer
Example
vfix:gmac:x.total_in_mb
Holds the current downloaded data for other ICVs to reference Holds the current uploaded data for other ICVs to reference True when total data matches value as per operator True when downloaded data matches value as per operator True when uploaded data matches value as per operator Is a valueholding variable for other ICVs to reference True when RTT matches value as per operator Holds the current inbound usage (%) for other ICVs to reference Holds the current outbound usage (%) for other ICVs to reference Holds the average inbound usage (%) for other ICVs to reference Holds the average outbound usage (%) for other ICVs to reference True when the
icv 1 in_mb_var vfi0:gmac:1.total_in_mb icv 2 high_in_mb icv:1 gt 25000
vfix:gmac:x.total_out_mb
Integer
icv 1 out_mb_var vfi0:gmac:1.total_out_mb icv 2 high_out_mb icv:1 gt 25000
vfix:gmac:x.total_mb [operator] [value]
True or false
icv 1 totalmb_limit vfi0:gmac:1.total_mb gt 50000
vfix:gmac:x.total_in_mb [operator] [value]
True or false
icv 1 inmb_limit vfi0:gmac:1. total_in_mb gt 25000
vfix:gmac:x.total_out_mb [operator] [value]
True or false
icv 1 outmb_limit vfi0: gmac:1.total_out_mb gt 25000
vfix:gmac:x.rtt
Integer
icv 1 rtt_var vfi0:gmac:1.rtt icv 2 high_rtt icv:1 gt 200 icv 3 low_rtt icv:1 lt 50
vfix:gmac:x.rtt [operator] [value]
True or false
icv 1 rtt_limit vfi0:gmac:1.rtt gt 299
vfix:gmac:x.usage_in
Integer
icv 1 usage_in_var vfi0:gmac:1.usage_in icv 2 high_usage_in icv:1 gt 75 icv 3 low_usage_in icv:1 lt 25
vfix:gmac:x.usage_out
Integer
icv 1 usage_out_var vfi0:gmac:1.usage_out icv 2 high_usage_out icv:1 gt 75 icv 3 low_usage_out icv:1 lt 25
vfix:gmac:x.usage_avg_in
Integer
icv 1 average_in_var vfi0:gmac:1.usage_avg_in icv 2 high_average_in icv:1 gt 75 icv 3 low_average_in icv:1 lt 25
vfix:gmac:x.usage_avg_out
Integer
icv 1 average_out_var vfi0:gmac:1.usage_avg_out icv 2 high_average_out icv:1 gt 75 icv 3 low_average_out icv:1 lt 25
vfix:gmac:x.usage_in [operator] [value]
True or false
icv 1 usage_in vfi0:gmac:1.usage_in gt 75
112/160
Definition download usage (%) reaches the value as per operator
Type of value returned
Example
vfix:gmac:x.usage_out [operator] [value]
True when the upload usage (%) reaches the value as per operator True when the average download usage (%) reaches the value as per operator True when the average upload usage (%) reaches the value as per operator True when the specified ISV is up True when the specified ISV is down True when the specified SitePath is up True when the specified SitePath is down Holds the current average RTT for specified SitePath for other ICVs to reference True when current average RTT for specified SitePath reaches value as per operator
True or false
icv 1 usage_out vfi0:gmac:1.usage_out gt 75
vfix:gmac:x.usage_avg_in [operator] [value]
True or false
icv 1 average_in vfi0:gmac:1.usage_avg_in gt 60
vfix:gmac:x.usage_avg_out [value]
[operator]
True or false
icv 1 average_out vfi0:gmac:1.usage_avg_out gt 60
vfix:isv:x.state_up
True or false
icv 1 isv_check vfi0:isv:1.state_up
vfix:isv:x.state_down
True or false
icv 1 isv_check vfi0:isv:1.state_down
vfix:spath:x.state_up
True or false
icv 1 sitepath_check vfi0:spath:1.state_up
vfix:spath:x.state_down
True or false
icv 1 sitepath_check vfi0:spath:1.state_down
vfix:spath:x.rtt_avg
Integer
icv 1 current_rtt vfi0:spath:1.rtt_avg icv 2 high_rtt_average icv:1 gt 299 icv 3 low_rtt_average icv:1 lt 61
vfix:spath:x.rtt_avg [operator] [value]
True or false
icv 1 current_rtt vfi0:spath:1.rtt_avg gt 299
This table focuses on the time-based logic tests.

Expression Definition Example(s)
113/160
Expression timer.state_on [value] [start time] [duration]
Definition True while the current date/time is within the specified value, start time and duration. Possible values are: mon-fri (from Monday at midnight to Friday at 11:59pm) weekend (from Saturday at midnight to Sunday at 11:59pm) daily sun mon tue wed thu fri sat yyyy/mm/dd dd (day of month)
Example(s) icv 1 business_hours timer.state_on mon-fri 09:00 08:00
icv 2 weekend_nights weekend 19:00 08:00
timer.state_on
icv 3 lunchtime timer.state_on daily 12:00 01:00
icv 4 saturday_morning timer.state_on sat 07:00 05:00
icv 5 specific_day timer.state_on 2009/12/31 00:00 24:00
icv 6 month_end timer.state_on 27 08:00 01:00
timer.state_off [value] [start time] [duration]
False while the current date/time is within the specified value. Possible values are the same as above.
icv 1 business_hours timer.state_on mon-fri 09:00 08:00 icv 2 exception timer.state_off thu 09:00 08:00 icv 3 logic_test icv:1 and icv:2
timer.trigger_on [value] [start time]
True for the instant when the date/time reaches the specified value. False for the instant when the date/time reaches the specified value.
icv 1 monthly_trigger timer.trigger_on 01 00:00
timer.trigger_off [value] [start time]
icv 1 inverted_trigger timer.trigger_on daily 00:00
Here is the ICV action table.

Action (where x is an ID) vfix:gmac:x.state_disable Effect Disables the specified GMAC Example icv 1 totalmb_limit vfi0:gmac:1.total_mb gt 50000 icv action 1 disable_gmac1 icv:1 true vfi0:gmac:1.state_disable vfix:gmac:x.state_enable Enables the specified GMAC icv action 1 enable_gmac1 icv:1 true vfi0:gmac:1.state_disable the icv action 1 reset_gmac1 vfi0:gmac:1.stat_reset icv:1 true
vfix:gmac:x.stat_reset
Resets the statistics specified GMAC
for
vfix:spathgrp:x.stat_reset
Resets the statistics for specified SitePath group
the
icv action 1 reset_spathgrp1 icv:1 true vfi0:spathgrp:1.stat_reset
114/160
vfix:qos:x.stat_reset
Resets the statistics specified QoS instance Resets the specified VFI statistics
for
the
icv action 1 reset_qos1 vfi0:qos:1.stat_reset icv action 1 vfi0.stat_reset reset_vfi0
icv:1
true
vfix.stat_reset
for
the
icv:1
true
vfix:gmac:x.set_thresh [% threshold in]/[% threshold out] vfix:iagrp:x.state_disable
Sets the threshold for the specified GMAC Disables access lists with the specified iagrp ID Activates access lists with the specified iagrp ID Generates a log event at the specified interval time. Event ID allowed range is 10000-10999
icv action 1 threshold_gmac1 icv:1 true vfi0:gmac:1.set_thresh 50/50 icv action 1 disable_line vfi0:iagrp:1.state_disable icv action 1 enable_line vfi0:iagrp:1.state_enable icv action 1 alert event:10001:severity:1 30 icv:1 true
vfix:iagrp:x.state_enable
icv:1
true
event:[event ID]:severity:[severity 1 4] [interval]
icv:1
true
4.7.6.8.
Troubleshooting
You can run the sh icv and sh icv action commands to verify the state of the ICV statements and ICV actions.
LinkLB-enable:vfi0 [single] #sh icv Index[1] Description[night_time] Exp1[timer.state_on daily 17:00 07:00] Op[none] Exp2[none] Status[ok] Result[false] Index[2] Description[day_time] Exp1[timer.state_on daily 07:00 17:00] Op[none] Exp2[none] Status[ok] Result[true] LinkLB-enable:vfi0 [single] #sh icv action Index[1] Description[all_links] Icv[icv:1] Logic[true] Action[vfi0:iagrp:1.state_enable] Execution Rate Limit (sec)[none] Index[2] Description[single_link] Icv[icv:1] Logic[false] Action[vfi0:iagrp:1.state_disable] Execution Rate Limit (sec)[none] Index[3] Description[increase_links] Icv[icv:2] Logic[true] Action[vfi0:iagrp:2.state_enable] Execution Rate Limit (sec)[none] Index[4] Description[special_link] Icv[icv:2] Logic[false] Action[vfi0:iagrp:2.state_disable] Execution Rate Limit (sec)[none]
4.7.7.
Intelligent Service Verificator (ISV)
Inbound link balancing and redundancy is ensured by the IDNS module which will monitor link metrics in order to answer DNS requests with the IP address associated to the best link. In some infrastructures, there are two or more servers for the same service. For example, a network may have two web servers that host the same content and they are redundant in case of server failure. An Intelligent Service Verificator (ISV) can be configured to verify those servers for basic connectivity and take those metrics into consideration when answering DNS requests tied into the IDNS module.
Generally, the polling of internal services is done by the management interface. As such, polling packets from the Link LB will need to be able to reach the intended servers. When polling this way, the target servers will be identified by their local IP address. ISV command syntax:
isv [id] [dest ip] [url|alias] [verification string|isv:id] (ms)] [timeout (ms)] [failure threshold] [weight]
## Intelligent service verificators isv 1 172.20.200.99 http://www.llb.com:80/ VerificationString 5000 1000 3 1
[interval
115/160
In order to simulate more accurately the real life experience of Internet users accessing the tested resources, polling can be done via the inside interface. With this method, called Inline ISV, the Link LB generates packets and sends them to the firewalls WAN interface.
## Intelligent service verificator inline polling isv inline eth3 194.204.1.5/24 ## Intelligent service verificators isv 1 194.204.1.99 http://www.llb.com:80/ VerificationString 5000 1000 3 1
There are two main categories for the type of polling: layer 4 or layer 7. Currently, all polling is done based on TCP as the connection layer. Layer 4 polling consists of opening a socket on the system being tested. It can be any TCP socket, such as port 25 for example.
isv 10 194.204.1.102 tcp://unused:25/ unused 3000 1000 3 1
Layer 7 polling will go a few steps further in testing the system in question. This method will make some sort of transaction with the system in order to ascertain availability. There are a few types of layer 7 transactions which are configurable on a Link LB:
HTTP : The Link LB will download a given page on a configurable path and verify the presence of a verification string. HTTPS : Same concept as HTTP but over TCP 443. The Link LB can also be configured to log into a web site in order to read the verification string. FTP : The Link LB can log into an FTP server and navigate to a configured path. It can then download and open a file and read a verification string within or it can simply validate that a file (by name) exists on a path. API : An external script/service can be used as a heartbeat for the API ISV. The external script/service updates the ISV within the specified timeout to maintain an ISV feedback. The API command is ISV UPDATE.
## Intelligent service verificators isv 1 194.204.1.99 http://www.llb.com:80/ VerificationString 5000 1000 3 1 isv 2 194.204.1.99 https://user:password@secure.llb.com:443/ VerificationString 5000 1000 3 1 isv 3 212.217.1.99 alias isv:1 1 isv 4 212.217.1.99 alias isv:2 1 isv 5 194.204.1.100 http://www.llb.com:80/ VerificationString 5000 1000 3 1 isv 6 194.204.1.100 https://user:password@secure.llb.com:443/ VerificationString 5000 1000 3 1 isv 7 212.217.1.100 alias isv:5 1 isv 8 212.217.1.100 alias isv:6 1 isv 10 194.204.1.102 tcp://unused:25/ unused 3000 1000 3 1 isv 11 212.217.1.102 alias isv:10 1 isv 20 194.204.1.99 ftp://user:password@194.204.1.99:21/Path/VerificationFile VerificationString 3000 1000 3 1 isv 21 194.204.1.99 ftp://user:password@194.204.1.99:21/ VerificationFileNameDirectoryContent 3000 1000 3 1 isv 22 212.217.1.99 alias isv:20 1 isv 23 212.217.1.99 alias isv:21 1 isv 24 194.204.1.99 api://unused:1/ unused 5000 1000 3 1 isv 25 194.204.1.100 ftp://user:password@194.204.1.100:21/Path/VerificationFile VerificationString 3000 4000 3 1 isv 26 194.204.1.100 ftp://user:password@194.204.1.100:21/ VerificationFileNameDirectoryContent 3000 1000 3 1 isv 27 212.217.1.100 alias isv:25 1 isv 28 212.217.1.100 alias isv:26 1 isv 29 194.204.1.100 api://unused:1/ unused 5000 1000 3 1
116/160
ISVs can be grouped together using the ISV GROUP command. This allows for certain services which are dependent on other services to be grouped together. For example, a regular web service (HTTPS) that chains to a secure server (HTTPS) for a login process. The ISV group performs a logical AND amongst a set of ISVs. The group will be up only when all ISVs contained within are also up and ISV groups can be used as parameters for the IDNS RR command. By binding together the information from the ISVs and the best link selection, we can determine the best IP address to fulfill a DNS request for a resource record.
## Intelligent service verificator groups isv group 1 isv:1,2,3,4 ISVGroupWebServer1 gms-weight isv group 2 isv:5,6,7,8 ISVGroupWebServer2 gms-weight ## Intelligent service verificators isv 1 194.204.1.99 http://www.llb.com:80/ VerificationString 5000 1000 3 1 isv 2 194.204.1.99 https://user:password@secure.llb.com:443/ VerificationString 5000 1000 3 1 isv 3 212.217.1.99 alias isv:1 1 isv 4 212.217.1.99 alias isv:2 1 isv 5 194.204.1.100 http://www.llb.com:80/ VerificationString 5000 1000 3 1 isv 6 194.204.1.100 https://user:password@secure.llb.com:443/ VerificationString 5000 1000 3 1 isv 7 212.217.1.100 alias isv:5 1 isv 8 212.217.1.100 alias isv:6 1 ## Idns rr (DNS Resource Records) idns rr itcgrp:10 www.llb.com 30 etfa 100/100 194.204.1.99,212.217.1.99,194.204.1.100,212.217.1.100 isvgrp:1,2 noauth persist
ISV group syntax:
isv group [id] isv:[id,...] [description] [group metric selector]

## Intelligent service verificator groups isv group 2 isv:5,6,7,8 ISVGroupFTPServer1 ## Idns rr (DNS Resource Records) idns rr itcgrp:10 secure.llb.com 30 etfa 100/100 194.204.1.101,212.217.1.101,194.204.1.102,212.217.1.102 isvgrp:2
In addition to verifying the state of a service, ISVs can, to a degree, determine performance based on response time. Considering that every transaction requires CPU processing, hard drive access, network conditions and so on, the total reaction time can be used to approximate the overall performance of a given service. Group metric selectors (GMS) can be used in conjunction with ISV groups to take response time into consideration when selecting an RRA.
## Intelligent service verificator groups isv group 1 isv:1,2,3,4 ISVGroupWebServer1 gms-weight ## Idns rr (DNS Resource Records) idns rr itcgrp:10 secure.llb.com 30 etfa-isv 100/100 194.204.1.99,212.217.1.99,194.204.1.100,212.217.1.100 isvgrp:1
NOTE: GMS can only be used with special IDNS algorithms called ETFA -ISV or WFA-ISV.
4.7.8.
4.7.8.1.
Filtering Access Lists

Filter Incoming and Outgoing Traffic
Filtering access-lists purpose is to filter incoming and outgoing traffic, allowing you to prevent undesired packets from reaching or leaving your network. Traffic filtering features are integrated into the Elfiq Link Balancer to help increase the security of your network, in the form of access-lists and a real time packet filtering (shunning) agent.
117/160
Access-lists in the Elfiq Link Balancer can provide the first layer of security in your network infrastructure, blocking packets before they even reach your corporate firewall. IMPORTANT: The Link LB is not meant to be used as a replacement for a corporate firewall. Instead, the use of its security features, such as access-lists and shunning engine are meant to provide an extra layer of security. Some of your firewalls features, such as stateful packet filtering and VPN capabilities, are not part of the features of the Link LB and are meant to stay on your corporate firewall. Therefore, since there is no stateful packet filtering in the Link LB, all the filtering rules created by the access-lists will either allow the packets to pass, or drop them. Any extra filtering will need to be done on the firewall.
4.7.8.2.
Add Filtering Access lists
This kind of access-lists allows filtering packets at layer 3. It can also be used simply to assign packets with quality of service (either queues or diffserv marking) and let them pass through the VFI stack. To add filtering, you will need to use the following command: acl [in|out] [+|-][ip|icmp|tcp|udp|...] [idx] [+|-][source ip]/[netmask-bits]:[start port]-[stop port] [+|-][dest]/[netmask-bits]:[start port]-[stop port] [+|-][drop|pass] [qos:id,...] [iagrp:id] Here are the parameters in more details.
[in|out] Determine whether you want the filtering access-list to be applied on the inside or on the outside interface of
the Elfiq Link Balancer. [+|-][ip|icmp|tcp|udp|...] Specify the protocol filter list for which the rule will be added, which needs to be specified with at + or option. A + sign means that you want the rule to be applied to the specified protocol, while a - sign means that you want it to be applied to every protocol but the one specified.
[idx] This is the index of the rule, which will dictate where the rule will be applied in the access-list. If you select an
index value that has already been used, then that rule will be inserted before the rule that used to have its index, and all rules with a higher index value will be pushed down by 1. This makes the index very useful to add rules exactly in the desired order of an access-list, without having to delete and then recreate your access-list. The index is also the reference identification number that will be used to delete rules.
[+|-][source ip]/[netmask-bits]:[start port]-[stop port] This is where you specify the

source addresses on which the filter will take effect. The source address needs to be specified in the form of a network address, to add the flexibility of either filtering hosts or network addresses. To filter a host, simply add a netmask of /32. The address is then followed by the range of ports that will be filtered. Once again, for a single port entry, simply enter the same port number as the start and the stop port values. The + or sign, just as with the protocol value, is used to imply a positive or negative input, meaning that a + will make this source filtered, and a sign will make all sources except this one filtered.
[+|-][dest ip]/[netmask-bits]:[start port]-[stop port] This is just like the input of the
source address, but for the destination address.
[+|-][drop|pass] Determine the action performed by the filter. It can either drop the packets or let them pass
through. Qos and iagrp parameters are optional. IMPORTANT: The ACL feature must be enabled for ACL access-lists to be verified in the VFI stack. WARNING: Filtering access-lists in the Elfiq Link Balancer will drop packets as a default policy. Therefore, before enabling the filtering access-list feature in your VFI, you need to make sure to create all the rules needed to allow your traffic to pass through it. Of course, disabling the access-list feature will not alter your configurations, but will enable all packets to pass through the Link LB.
LinkLB-enable:vfi0 [single] #acl in +ip 1 +any +any +pass LinkLB-enable:vfi0 [single] #acl out +ip 1 +any +any +pass
118/160
4.7.8.3.
Display ACL Filtering Rules

sh acl [in|out] command:
All the ACL filtering rules of a VFI can be displayed with the
LinkLB-enable:vfi0 [single] #sh acl in Protocol[+ip] Index[1] Source[+any] Destination[+any] Action[+pass] Hit Count[0]
The output of this command will display all the information inserted into the ACL rule, along with hit counts, which represent the amount of packets that have matched this rule.
4.7.8.4.
Delete ACL Filtering Rules

no acl in command:
ACL filtering rules can be deleted individually with the no acl [in|out] [ip|icmp|tcp|udp|...] [idx]
LinkLB-enable:vfi0 [single] #no acl in ip 1 LinkLB-enable:vfi0 [single] #no acl out ip 1
It is also possible to remove all the inside ACL filtering rules of a VFI at once with the command.
LinkLB-enable:vfi0 [single] #clr acl in LinkLB-enable:vfi0 [single] #clr acl out
clr acl [in|out]
4.7.9.
4.7.9.1.
Shunning Engine
Real Time Packet Filtering Engine
The Elfiq Link Balancer also comes with a shunning facility, which is the second major module provided for security purposes. The shunning facility is a real time packet filtering engine, which is complementary to the access-lists. Its purpose is only to drop packets from specified sources, either for a determined period of time, or as long as desired. It does not provide any additional functions than source IP based packet filtering, not even port filtering. The shunning engine is especially useful when combined with a network intrusion detection system (IDS), since you can allow your IDS to speak to the shunning engine through the use of the API. Therefore, depending on the rules you wish to implement, you can decide to temporarily block a suspecting source address in real time. Once again, since you are working through the API, you can script any possible business needs for the shunning engine.
4.7.9.2.
You can add a shunning rule with the parameters. shun [ip address] [ttl in seconds]
Add Shunning Rules

shun command, which takes the source IP address and the timeout of the rule as
Example, to block IP address 33.33.33.45 for 900 seconds, you would issue the following command:
LinkLB-enable:vfi0 [single] #shun 33.33.33.45 900
This shunning rule would be automatically cleared after 900 seconds. If you wish to create a permanent rule, you need to specify a time to live of -1 second.
LinkLB-enable:vfi0 [single] #shun 33.33.33.48 -1
In this case, the rule will always be active until you wish to manually delete it. NOTE: The SHUN feature must be enabled for shunning rules to be verified in the VFI stack.
119/160
LinkLB-enable:vfi0 [single] #feature shun enable
WARNING: Be careful when adding shunning rules, as sometimes the IP that you block could be a gateway or proxy server; which means that you could end up blocking a lot more people than initially intended.
4.7.9.3.
List Shunning Rules

sh shun command.
You can view all the current shunning rules with the
LinkLB-enable:vfi0 [single] #sh shun IP Address[33.33.33.45] TTL[900] Hit Count[0] IP Address[33.33.33.48] TTL[-1 (perm)] Hit Count[0]
As you can see, this will give you a list of all the IP addresses that are currently being blocked. The total time to live value that was specified with the rule will be listed, as well as the hit count, which is the total number of packets that have been blocked by the rule.
4.7.9.4.
Delete Shunning Rules
All the shunning rules that were entered with a different time to live than -1 will automatically be removed after the set period of time. However, should you wish manually delete a rule, either because the TTL was too high or because it was a permanent rule, use the no shun command, followed by the IP address that you wish to clear: no shun [ip address]
LinkLB-enable:vfi0 [single] #no shun 33.33.33.48
You can also remove all shunning rules at once through the
LinkLB-enable:vfi0 [single] #clr shun
clr shun command.
4.7.10.
Tap Interface
Alternate link
Primary link
MGMT TAP Network IDS Firewall
Client Network
Figure 21: Setup with a tap interface to monitor the network through a network IDS
120/160
Except for the management interface, you can use any other interface as a tap interface in order to monitor and troubleshoot your network. Through the tap interface, you can log packets to debug network issues, or setup a network IDS system to monitor possible attacks on your network. NOTE: Only one interface can be configured as a tap interface. IMPORTANT: Tapping is not supported by some Link LB models or in operating modes with VLANs. IMPORTANT: Link LB models that only have four Ethernet ports must be configured in multimode to support tapping.
Configure a Tap Interface Command syntax:
tap
[source
interface0],[source
interface1]
[destination
interface]
LinkLB-enable:vfi0 [single] #tap eth5,eth6 eth4
Display Tap Interface Information Command syntax: sh
tap
LinkLB-enable:vfi0 [single] #sh tapSource Interface0[eth5] Source Interface1[eth6] Destination Interface[eth4]
4.7.11.
Debug Tools
You can use the set of debug tools to troubleshoot your settings and links. Debug tools are provided for each VFI instance and are related to each available facility.
Enable Debug Tools Command syntax:
debug [vfi|gmac|arp|nat|rnat|frag|acl|nattp|shun|timers|poolip|idns|packet_l2|pa cket_ip|proc|channel|ftp|sip|tag|rtag|probe|spath|dhcp|isv|icv|qos|geo|all ] [on|off]

IMPORTANT: Enabling debug tools must be done from the proper VFI interface menu(vfi0, vfi1, etc).
LinkLB-mgmt: [single] #enable LinkLB-enable: [single] #vfi0 LinkLB-enable:vfi0 [single] #debug acl on
View Real-Time Debug Tools Activation Message Command syntax: sh
log
LinkLB-mgmt: [single] #sh log
View Status of Debug Tools of a VFI Interface Command syntax:
sh debug
121/160
LinkLB-enable: [single] #vfi0 LinkLB-enable:vfi0 [single] #sh debug Name[vfi] Status[off] Name[probe] Status[off] Name[gmac] Status[off] Name[arp] Status[off] Name[nat] Status[off] Name[rnat] Status[off] Name[frag] Status[off] Name[acl] Status[on] Name[shun] Status[off] Name[timers] Status[off] Name[qos] Status[off] Name[poolip] Status[off] Name[idns] Status[off] Name[packet_l2] Status[off] Name[packet_ip] Status[off] Name[proc] Status[off] Name[persistence] Status[off] Name[channel] Status[off] Name[ftp] Status[off] Name[sip] Status[off] Name[tag] Status[off] Name[rtag] Status[off] Name[dhcp] Status[off] Name[pppox] Status[off] Name[spath] Status[off] Name[isv] Status[off] Name[icv] Status[off]
Delete Debug Entries Command syntax: clr
log
NOTE: Debug entries are deleted all at once.
4.7.12.
How to manage the LLB using Inline Access
There are different ways to manage the Elfiq. One of them is by using the inline access feature. To enable it, under the vfi0 module, type feature inline_access enable. The inline access feature allows a remote administrator to connect to an Elfiq device via Internet. That means, we cannot use the inline access feature to connect from the inside to manage the Elfiq, for that we recommand to use the management port. That being said, we need to gather what informations are required to use this feature. Mainly, there is 3 specific informations for this to work. source IP address of the connection destination IP address of the connection listening network interface on the link balancer
The source address is the IP where the connection will come from. This needs to be a specific IP address of a host (meaning a /32, not a range of IP addresses). The same reasoning applies for the destination address. It is the IP to where the connection is destined (also a /32). This IP destination needs to be part of the network routed to the customer. Even though this IP is used for inline access on the Elfiq, you can use the same IP address on another device behind the Elfiq unit. Just keep in mind that if there is a such device, any service request using the following ports 22,80,443,161 and 9998 coming from the IP source as defined below will be intercepted by the Elfiq. If the internal device is listening on the same services, again 22,80,443,161 and 9998, then it will be more than safe to use a different IP, if available, to use for the inline access. As a side note, the link balancer also listens for the incoming ping echo request. The default router (Gateway) IP is somehow implicit on the inline access definition syntax.
122/160
The syntax of the inline access is straightforward:

inline access [index] [ethX] source_IP destination_IP gateway_IP
There is a maximum limit of 8 for the index, ethX is the interface used by the Elfiq device to listen to the connection and should match the link configuration under vfi0, source_IP and destination_IP are as explained above, the gateway_IP is the router IP used by Elfiq to receive/send the packets back/forth from/to the source IP request's initiator. Let's illustrate the concept using a detailed example: ## inline access listening on eth2 interface
inline access 5 eth2 24.200.1.3 194.204.1.5 194.204.1.1
index=5, interface=eth2, source_IP=24.200.1.3 destination_IP=194.204.1.5, gateway_IP=194.204.1.1 N.B: you cannot use different interfaces (e.g eth2 and eth1) to listen for a connection from the same source (*) . Also, you cannot use different destination IP on the same interface (**) That means the following settings are not correct:
inline access 5 eth2 24.200.1.3 194.204.1.5 194.204.1.1 inline access 6 eth1 24.200.1.3 212.217.1.5 212.217.1.1 -- (*) eth2 already listens on source 24.200.1.3 inline access 7 eth2 24.200.1.3 194.204.1.10 194.204.1.1 -- (**) destination IP already set at 194.204.1.5
4.8.
Site-to-site Resilience with SitePathMTPX

4.8.1.
About SitePathMTPX
For infrastructures where site-to-site applications such as VPNs are used over the Internet, a Link LB can be deployed at each site and configured to use SitePathMTPX. When new outbound traffic is processed by a load-balancing algorithm and an alternate link is selected, the NAT engine will change the source IP address of the packets. This translation can be undone by a Link LB receiving this traffic at the opposite end of a site-to-site connection across the Internet. This method allows for conservation of primary link concept and relieves the need for any endpoint reconfiguration for redundancy purposes. The Link LB units will make this transition transparent. Multiple Internet links can be used to define different paths from one site to the other. As such, two sites with two links per site allows for four paths to be used by SitePathMTPX. Therefore, link utilization and availability is expressed in terms of paths, which are called SitePaths. WARNING: The number of configurable SitePaths and SitePath Groups varies from one model to the other.
123/160
Figure 22: SitePathMTPX
Redundancy is achieved for site-to-site applications since, in an integration with four SitePaths, connectivity is maintained through at least one ISP link per site. This ensures that traffic placed on the SitePath benefits from point-to-point (IP-to-IP) resiliency.
4.8.2.
1. Enabled SitePath feature
Components
There are four main components necessary for SitePathMTPX to be deployed:
LinkLB-enable:vfi0 [single] #feature spath enable LinkLB-enable:vfi0 [single] #sh conf (omitted) ## Features feature default_balancing_group enable feature inline_access enable feature spath enable (omitted)
2. ACL NAT IN rule(s) to qualify traffic for point-to-point resiliency:

## Acl nat inside acl nat in +ip 1 +194.204.1.3/32 +24.201.1.3/32 +nat spathgrp:1 mtpx
3. SitePath group(s) A SitePath group must be configured for every site-to-site association. This group will define the SitePath algorithm that will be used as well as the encryption, if selected. It will also specify the encryption parameters for polling, if configured to do so.
## Spath groups (Site path group) spath group 1 mtpx nodataenc aes128 01:02:03:04:05:06:07:08:09:10:11:12:13:14:15:16
4. SitePaths Individual SitePaths also need to be configured. Each one will represent a path which pertains to a local GMAC as well as a remote IP address. SitePaths are associated to a SitePath group.
## Spath (Site path) spath 1 spathgrp:1 gmac:1 194.204.1.3 24.201.1.3 R1_to_R3 1
124/160
spath 2 spathgrp:1 gmac:1 194.204.1.3 24.201.2.3 R1_to_R4 2 spath 3 spathgrp:1 gmac:2 212.217.1.3 24.201.1.3 R2_to_R3 3 spath 4 spathgrp:1 gmac:2 212.217.1.3 24.201.2.3 R2_to_R4 4
SitePath identifiers should be unique to each path. If the path defined by 194.204.1.3 24.201.2.3 is identified as spath 2, then the path defined by 24.201.2.3 194.204.1.3 on the peer Link LB should also be identified as spath 2. When SitePath is configured, it can be verified with the
LinkLB-enable:vfi0 [single] #sh spath summary Name[ Spath1] Spath Group[1] Description[R1_to_R3] (kb/s)[0] Name[ Spath2] Spath Group[1] Description[R1_to_R4] (kb/s)[0] Name[ Spath3] Spath Group[1] Description[R2_to_R3] (kb/s)[0] Name[ Spath4] Spath Group[1] Description[R2_to_R4] (kb/s)[0] Total of Spath[4] Total of Spath down [0] UP (%) [100.000]
sh spath summary command:

Status[up] Message[all ok] In Usage (kb/s)[0] Out Usage Status[up] Message[all ok] In Usage (kb/s)[0] Out Usage Status[up] Message[all ok] In Usage (kb/s)[0] Out Usage Status[up] Message[all ok] In Usage (kb/s)[0] Out Usage
4.8.3.
Weight First Algorithm (WFA)
SitePathMTPX Algorithms
This algorithm will look at the configured weight for each SitePath and use the one with the lowest weight. If that SitePath becomes unavailable, this algorithm will use the SitePath with the next lowest weight. Best SitePath First Algorithm (BSFA) By default, this algorithm will consider effective bandwidth, which is the sum of the declared bandwidth for each link comprised in the SitePath minus the currently used bandwidth for those same links. It will also consider the current and average Round Trip Time (RTT) values and packet loss for the links comprised in the SitePath, as well as the weight for each SitePath if the previously mentioned metrics are too similar to each other. Round Trip First Algorithm (RTFA) This algorithm will exclusively look at the Round Trip Time (RTT) values for the links comprised in the SitePath. It will dynamically change the SitePath on which traffic is being placed based in order to use the path with the lowest RTT value. Multiplexing Algorithm (MTPX) This algorithm will attempt to aggregate bandwidth by placing traffic on as many available SitePaths as possible. The guideline metric is the Round Trip Time (RTT) values for each SitePath. MTPX will allow simultaneous packet transmission when the RTT value of candidate SitePaths gets within a configurable percentage of the currently used SitePath. The MTPX algorithm can be calibrated with regards to the inclusion threshold. This is the value, in percentage, that will be used to determine if two or more SitePaths can be used simultaneously for data transmission. Syntax: spath group calibrate mtpx [id] [inclusion threshold]
LinkLB-enable:vfi0 [single] #spath group calibrate mtpx 1 15
125/160
4.8.4.
BSFA Adjustments
Figure 23: BSFA Adjustments
Calibration is possible for the BSFA algorithm. When an algorithm considers multiple factors, each factor is not worth the same consideration. The default proportions of all factors are: Effective inbound bandwidth Effective outbound bandwidth Current Round Trip Time (RTT) Average Round Trip Time (RTT) Polling packet loss Number of hops Average number of hops SitePath weight 0% 40% 20% 10% 20% 0% 0% 10%
With the spath group calibrate bsfa command, those proportions can be modified. With regards to the effective outbound bandwidth, the local Link LB actually factors in the effective inbound bandwidth from the remote Link LB. That is why it is the factor with the largest proportion by default. Syntax: spath group calibrate [id] [ebin] [ebout] [rtt] [rtta] [lost] [hop] [hopa] [wei]
LinkLB-enable:vfi0 [single] #spath group calibrate 1 10 33 33 20 3 0 0 1
126/160
4.8.5.
Polling
By default, each SitePath will be monitored at the rate of one polling packet every second. Each Link LB will manage the results of the polling packets that it sends. It is through this polling that some information will be exchanged between Link LB units. This information includes the ID of the GMAC for the SitePath that is being monitored, the local timestamp for RTT calculation and the GMAC metrics which are used by the SitePathMTPX algorithms. If required, the polling parameters can be changed with the spath probe command. Syntax: spath probe [id] [payload length] [polling interval [adaptive|timer] [rtt threshold msec] [hop threshold]
LinkLB-enable:vfi0 [single] #spath probe 1 10 800 5 timer 500 32
msec]
[polling
threshold]
4.8.6.
Encryption
By default, data passing through SitePathMTPX is not encrypted. So, a VPNs data would not be re-encrypted but if required, a SitePath group can be configured to encrypt data with a 128-bit AES pre-shared key. Note the dataenc keyword.
spath group 12 mtpx dataenc aes128 00:11:22:11:00:11:22:00:11:22:11:22:00:11:22:11
IMPORTANT: The same encryption key must be used on both Link LBs.
4.8.7.
Dynamic SitePath IP Address
Any SitePathMTPX deployment must have a primary path defined by static IP addresses. For alternate links, SitePathMTPX can also be used where the local or remote IP address is unknown, such as with DHCP, PPPoE or if the GMAC is based on a router that performs NAT. In cases where the local IP address is unknown, the SitePath configuration will use the appropriate dhcp or pppox identifier.
spath 14 spathgrp:20 gmac:2 dhcp:2 50.50.1.3 mtl_2_tor_line4 4
In the event that the local GMAC is based on a router that performs NAT, the local IP address should be used.
spath 11 spathgrp:20 gmac:1 192.168.1.3 40.40.1.3 mtl_2_tor_line1 1
Through the exchange of information between Link LB units, the outside (as seen on the Internet) IP address is reported back to the local Link LB.
LinkLB-enable:vfi0 [single] #sh spath 11 Name[Spath11] Spath Group[spathgrp:20] Associated Gmac[gmac:1] Src IP[192.168.1.3, public (translated) 20.20.0.1] Dst IP[40.40.1.3] (omitted)
When it is the remote IP address that is unknown, the dynamic keyword must be used.
spath 14 spathgrp:20 gmac:2 50.50.1.3 dynamic mtl_2_tor_line4 4
NOTE: At least one link per site must have a static IP address to initiate the discovery process and to configure the relevant ACL NAT IN rule(s).
127/160
4.9.
Geographic Balancing with Geolink

4.9.1. About Geolink
Geographic balancing is used when redundancy is required across multiple locations. It can be deployed in two modes: Inbound Geolink and Global Geolink. In both cases, a communication link is configured so that information can be exchanged between Link LB units. This information exchange is called a GEOLINK and it can be established over a WAN link, VPN or over a secure SSH connection over the Internet, and even a combination of those methods. Up to 5 physically separate sites can be made geographically resilient with this technology. Geographic balancing can be activated on supported models with the appropriate license. Inbound Geolink Inbound Geolink is deployed when resources are available at more than one geographical location. DNS requests from Internet users can be received via any of the connected sites and processed by the Link LB.
Figure 24: Inbound Geolink
128/160
Global Geolink Global Geolink provides Internet access redundancy across multiple geographical locations. Inbound and outbound Internet traffic can be redirected to a remote site via a WAN link if the local Internet links are down.
4.9.2.
Geolink
A key element for geographic balancing is the exchange of information between Link LB units at different geographical sites. Information is exchanged via the GEOLINK which is usually established over a WAN link between connected sites or through a VPN connection. This connection can also be further secured by encryption when DSA keys are used to establish the Geolink. The Link LB unit at one site will push data to the Link LB at a remote site via this GEOLINK. The same occurs in the opposite direction. With both sites pushing their data, there is a bidirectional information flow but each individual GEOLINK is unidirectional. Data is sent at a configurable rate. Once GEOLINKs are configured between all units, each Link LB has the knowledge of the other sites for decision making. The exchanged data contains local site information including metrics on link availability, iDNS resources and their related metrics, ISV resources and their metrics. Starting with EOS version 3.4, the Link LB supports user and group definition and customization. GEOLINK configuration has changed accordingly to make use of this development and the connection method was changed from a clear text session on TCP port 9998 to an encrypted session through SSH (TCP port 22) using DSA public key authentication. From a configuration standpoint, this means typing passwords in the GEOLINK configuration will no longer be required. A public DSA key will need to be configured for each GEOLINK instead. This password-free configuration is recommended and will become the only supported configuration in an upcoming firmware release.
geolink 1 172.16.1.5 geotag:2 mtl_geo_rcv auth-key dsa geolink_to_Toronto 5 2000
To prepare the Link LB units for each GEOLINK connection you will need to perform the following operations on each Link LB. Remember, each unit is responsible for pushing the local information to the remote unit, so for a two site deployment (site A and B) you will configure two GEOLINKs (A B and B A). You will also need to export the DSA keys twice (A B and B A).
129/160
1. Create a user on the receiving side (site B) of a Geolink, this user will be used to receive incoming connections (from site A). This user will need to be in the eos_geolink group and cannot be used for any other purpose. You can create a new user with the user command in the system module or the web interface. You can choose any username you want (except for already existing usernames including geolink).
user [username] eos_geolink
2. All the Geolink connections are always initiated from the user called "geolink", this user and its DSA key are automatically generated when you have a GEO-enabled EOS firmware. Using the sh user key geolink in the system module (in site A), find the DSA key under the "geolink" user on the sending side a nd copy it to your clipboard (or a notepad program).
sh user key
3. In the site B unit: Paste the geolink users DSA key under the user created in step #1 using the following command: user key [username from step 1] [hostname of the site A Link LB] [Long Key]. Its very important that the whole key is kept as a single line (no carriage returns).
user key [user created in step 1] [hostname] [paste key here]
4. In the site A Link LB vfi module: Configure the geolink with the username created in step #1, the whole line should look like this: geolink 1 [site B mgmtip] geotag:[remote ID] [username] auth-key dsa [comment] 5 3000
geolink [id] [remote geolink peer] geotag:[remote geotag id] [user created in step 1] auth-key dsa [description] [update interval (sec)] [tx timeout (msec)]
5. Repeat the procedure while reversing the sites for the opposite geolink (pushing data from site B to Site A). The username created in step 1 can be different but the geolink user always keeps the same name.
4.9.3.
Geotag and Geotag Groups
A Geotag is a configuration item that represents a site. As such, resources that are local to one site can be exported to a remote Geotag. A set of policies which is configured on each Link LB governs the interaction between the local and remote Geotags.
policy policy policy policy policy policy policy policy policy policy geotag geotag geotag geotag geotag geotag geotag geotag geotag geotag 1 1 1 1 1 2 2 2 2 2 allocate RemoteSite rflow active itraffic blocking otraffic blocking resources active allocate local rflow blocking itraffic blocking otraffic blocking resources active
These policies are configured with the policy geotag command which modifies an attribute. These attributes can have different values based on what the strategy calls for. This grid shows the different attributes and what they are used for:
allocate
string
active blocking established
String used to define the site. Note that the word local is reserved and cannot be used. A remote site can make changes to the state of itraffic, otraffic or resources. A remote site cannot make changes to the state of itraffic, otraffic or resources. Temporary state while going from an "active" state to a "blocking" state. This can only last up to 15 minutes, during which time only the established sessions are allowed to continue. A remote site can make changes to the state of ACL NAT IN rules that have the geotag statement on them.
rflow
itraffic
active
130/160
blocking
A remote site cannot make changes to the state of ACL NAT IN rules that have the geotag statement on them. Temporary state while going from an "active" state to a "blocking" state. This can only last up to 15 minutes, during which time only the established sessions are allowed to continue. A remote site can make changes to the state of ACL NAT OUT rules that have the geotag statement on them. A remote site cannot make changes to the state of ACL NAT OUT rules that have the geotag statement on them. Temporary state while going from an "active" state to a "blocking" state. This can only last up to 15 minutes, during which time only the established sessions are allowed to continue. Local IDNS resources will be used when DNS requests are intercepted. Local IDNS resources will not be used when DNS requests are intercepted.
established
active
otraffic
blocking
established
active resources blocking
A Geotag is identified as local with the allocate policy when it is used to define the local Link LBs resources. When remote Geotags need to be identified, a user-defined description will be used. In other words, local is a reserved parameter value in EOS for the allocate policy, any other user-defined value indicates that the Geotag is a remote site. Since the remote GEOLINK can connect to the local Link LB in order to push commands and values, a policy is configured to control this interaction. It is the rflow policy that controls whether a remote site can connect and change t he state the following policy items: itraffic, otraffic and resources for the relevant Geotag number. NOTE: The rflow policy cannot be changed for the local geotag as no remote Link LB should be allowed to alter the local policies, as such, it is always set to blocking . When Global Geolink is used and traffic needs to be redirected from a remote site, some ACL NAT rules need to be triggered on or off. The ability that a remote site has to do this locally, is controlled by the itraffic policy item for A CL NAT IN rules and the otraffic policy item for ACL NAT OUT rules. For Inbound Geolink where resource records are merged between sites, the resources policy item controls how the local IDNS module handles its DNS requests. When using the geotag keyword, it will be possible to specify how to handle load balancing per IDNS entry. This means that a different site order could be specified for different IDNS entries. When using the geotaggrp keyword, management will be simplified by re-grouping the site order in a single geotag group that can be changed at once for all affected IDNS entries. In other words switching a set of IDNS entries from one site to the next (ex.: for maintenance or redundancy) is a matter of changing the geotag group definition once.
## Geotag group geotag group 1 corp_website geotag:1,2/2/2 ## Idns rr (DNS Resource Records) idns rr itcgrp:10 www.llb.com 60 etfa 100/100 194.204.1.100,212.217.1.100 geotaggrp:1 noauth
The first parameter of the geotag option is the sites geotag ID where traffic is sent when the desired links are available. This is called the primary group. If the Link LB cannot select a valid answer from the geotags listed in the primary group, it will try to select a valid answer from the alternate group. In case this fails as wel l, the Link LB will answer with the last group without geotag state verification. You can define up to 4 geotag IDs for the primary group and for the alternate group and a single geotag ID for the last group. When using geotag groups instead, the I DNS resource record syntax will contain the geotaggrp option with the relevant group ID. This group needs to be defined using the geotag group commands.
131/160
4.9.4.
Inbound Geolink
This type of geographic balancing is used to ensure the availability of hosted services even after a total failure of the primary site. Inbound Geolink is combined with IDNS technology so that incoming DNS requests can be intercepted by multiple sites as well as multiple links per site. As part of a standard IDNS deployment, additional name server (NS) records are added. These records point to IP addresses on the alternate links. The same applies for Inbound Geolink deployments except that NS records pointing to all sites will be added. When an Internet user makes a DNS request for a Fully Qualified Domain Name (FQDN), it will be intercepted by a Link LB at any site that is still available. Local resources, such as web servers or FTP servers, will be configured in the IDNS RR section of the Link LB configuration. They may be available via multiple local links, if applicable. In the context of Inbound Geolink, they will also be exported to the Link LB at a remote site with the export command. They will be merged with local records on the remote unit that have the same FQDN. In that manner, an Internet user that makes a DNS request for a geographically dispersed resource record at one site may get an IP address pointing to a different more available site.
## Idns interceptor groups idns interceptor group 10 MTL_itcgrp idns interceptor group export 10 geotag:2
The algorithms to determine what site the user should connect to are the same as with standalone IDNS deployments except that they will be applied to groups of sites at a time. The geotag or geotaggrp keyword in the IDNS RR entry configures which sites will be chosen for the DNS resolution in any given situation. For a given balancing algorithm (ETFA, WFA, ), the Link LB will balance traffic on all IP addresses belonging to all links of all the sites specified in the primary group, and this balancing will be decided based on the current state and metrics of each one of those links. If none of those links are available, then the Link LB will evaluate the links contained in the alternate group. As a last resort, the Link LB will answer with the IP belonging to the last group. If the GEOLINK communication should fail, the shadow GMACs belonging to the Link LB usually connected by this GEOLINK will time out and be considered as down. From a local standpoint, a shadow GMAC is a GMAC programmed and exported from a remote unit. The index numbering for these shadow GMACs can be dynamically or statically defined using the gmac export command and its parameters. Local GMACs and ISV Groups can also be exported to multiple remote sites (Geotags).
## Gmac entries gmac 1 auto provider1_T1 194.204.1.1/24 1 1544 1544 0 DstIP1:DstPort1,DstIP2:DstPort2 95/95 gmac dev 1 eth2 gmac export 1 geotag:2,3 static gmac tcpprobe 1 194.204.1.3 gmac 2 auto provider2_xDSL 212.217.1.1/24 2 5000 1000 0 DstIP1:DstPort1,DstIP2:DstPort2 95/95 gmac dev 2 eth1 gmac export 2 geotag:2 static gmac mtu 2 1492 mss gmac tcpprobe 2 212.217.1.3
4.9.5.
Global Geolink
This type of geographic balancing is used when Internet access needs to be redundant across multiple geographical locations. Through the use of NATTP (Network address translation transfer protocol) and Channels, the local Link LB can send Internet traffic to a remote site when no local Internet links are available. As with a single unit, when a new outbound session needs to be established on a GMAC, the load balancing algorithm will select the best link to use. In the event there are no local GMACs available in the public VFI, a Channel GMAC will be selected. As opposed to a link routers MAC address, the Channel GMAC will send traffic to a private VFI through a Channel.
## Gmac entries gmac 1 auto provider1_T1 194.204.1.1/24 1 1544 1544 0 DstIP1:DstPort1,DstIP2:DstPort2 95/95 gmac dev 1 eth2
132/160
gmac export 1 geotag:2 gmac tcpprobe 1 194.204.1.3 gmac 2 auto provider2_xDSL 212.217.1/24 2 5000 1000 0 DstIP1:DstPort1,DstIP2:DstPort2 95/95 gmac dev 2 eth1 gmac export 2 geotag:2 gmac mtu 2 1492 mss gmac tcpprobe 2 212.217.1.3 gmac 10 chn:1 Channel_to_private 127.127.0.1/24 10 100000 100000 0 0.0.0.0:0,0.0.0.0:0 100/100
Private VFIs are used for WAN or private link balancing while public VFIs are used for Internet link balancing. They are identified with numbers (e.g. VFI0, VFI1, VFI2) but this manual may refer to them as private or public. Communication between VFIs within the same Link LB is done through Channels. A Channel is a conduit within the Link LB from one VFI to another, or to the same VFI itself. That is because when a Channel is configured, it can be made to point to the inside or outside of a given VFI.
## Features feature default_balancing_group enable feature channel enable ## Vfi channels channel 1 vfi1:inside
Once traffic is received on the inside of the private VFI, there may be one or more GMACs available for transport to the remote Link LB. Those would be WAN links from the local site whos Internet links are down, to the remote site. This traffic is sent via the WAN using NATTP, an advanced encapsulation protocol with encryption support.
## IP Nattp nattp 1 10.1.0.100 10.1.1.100 mss df
NOTE: Using the MSS option in the NATTP configuration is highly recommended as this will reduce the TCP maximum segment size for the sessions going through the tunnel to compensate for the 10 byte encapsulation overhead therefore avoiding fragmentation. The df keyword can also be used to force the Link LB not to fragment packest going through the NATTP tunnel. When traffic is sent to the remote site via the secure, point-to-point NATTP tunnel, the remote Link LB will receive it through the outside of its private VFI. It will then decapsulate the NATTP and pass the packets along to its public VFI, on the inside via a Channel. From that point, this traffic will go through the load balancing rules (ACL NAT/TAG IN) in place and get out to the Internet. Once traffic is sent out to the Internet, it will return on the public VFI, take a Channel back to the private VFI on the remote Link LB and then get sent back across the WAN link to the original site. Another way of using Global Geolink is by having inbound Internet traffic come in via a remote site and then passed through the WAN link back to local resources, such as web or FTP servers. It is the same process as with outbound traffic in that, here again, NATTP and Channels will be used. This ensures continuity even in case of total Internet link failure at the local site.
133/160
5. Failover Module (fove)

In this section, you will find information about the Failover Module and how to: Initialize the module.
5.1.
About Failover Module
The Elfiq Link Balancer offers the possibility of running two Link LB units in a failover configuration (also called High Availability or HA) allowing a second unit to take over the tasks of the first one in case of failure. To help understand how the Elfiq Link Balancer works in failover mode, here is an example of a setup with two Link LB units in failover mode:
Figure 25: Typical failover scenario
The two Link LB units are connected to two Internet Service Providers and joined by two switches that are split in a VLAN configuration. The internal network is isolated behind a pair of firewalls, also in failover, and the management LAN is isolated from the internal network for additional security. To determine if the master unit should transfer the load to the slave unit, the Link LB can verify the state of each port which can be configured as critical or not. It will do so by using a heartbeat between all defined interfaces. This heartbeat consists of Elfiq L2FO packets which operate at the second layer of the OSI model. When a Link LB fails to receive L2FO packets from its paired unit on a given interface, that interface is declared as down.
Failure of a Critical Port
Figure 26: Failover to peer unit after a failure from a critical port in a VFI
134/160
If one of the interfaces set to critical fails, then the failover module will automatically transfer the load to the slave unit. Both Internet Service Providers would still be active and balanced, except that the load will be handled by the Link LB that used to be the slave. This will be achieved in a completely transparent way to the users and performance will not be affected.
Failure of a Switch
Figure 27: Failover to peer unit after a failure from switch
If the switch connected to the master Link LB unit fails, the failover module will automatically transfer the load to the slave unit. The Internet Service Provider A would no longer be available. There would be a degradation of performance until the failed switch is replaced, or until the link of Internet Service Provider A is transferred from the first switch to the second switch; in which case the Link LB would be able to use it once more. Therefore, it is a good idea to keep a port available on each of the public VLAN or public switches, depending on your setup. WARNING: Because the Elfiq Link LB units monitor themselves through the inside, outside and management ports, it is recommended to connect the management ports to another switch. Otherwise, both Link LB units could become master in case of a trunk failure.
Failure of an Elfiq Link Balancer
Figure 28: Failover to peer unit after a failure from a master unit
If one of the Link LB units fails, the failover module will automatically transfer the load to the slave unit. Both Internet Service Providers will remain active and balanced, except that the load will be handled by the Link LB that used to be the slave. This will be achieved in a completely transparent way to the users and performance will not be affected.
135/160
Failure of a Management Interface
Figure 29: No changes occur after a failure of a management port
If the management interface connection fails; and if it has properly been set up with the set int command as mgmt and therefore not critical, it will not affect the behavior of the Link LB. The failover module will not transfer the load and both units will keep their current state.
Failure of an Internet Service Provider
Figure 30: No changes occur after a failure of an ISP link
If an Internet Service Provider link fails, the failover portion of the Link LB unit would not be affected. Since this does not impact the Link LB units, the problem will only affect the performance of the network as well as the VFI module of the Link LB.
5.2.
Initial Configuration
Step 1= On each Link LB unit, provide the management interface with the IP address of the peer unit. Step 2 = Select which interfaces the L2FO protocol will monitor. Step 3 = Create a Virtual IP address (optional but strongly recommended)
5.2.1.
IP Address of the Peer Unit
On each Link LB unit, you must provide the management interface with the IP address of the peer unit. This is used to transfer information that needs to be replicated between the two units.
136/160
Provide IP Address of the Peer Unit Command syntax: set
peer [ip]
bal1-enable:system [master] #set peer 10.0.30.202
IMPORTANT: The peer IP address must be different on each Link LB unit.
5.2.2.
Interfaces to Monitor
You must select which interfaces the L2FO protocol will monitor and, for each interface, you must set its level of importance. The following levels of importance are available: critical and if the interface goes down, the unit will automatically switch from the master to the slave. mgmt and if the interface goes down, the system will continue to operate normally.
List Interfaces to Monitor Command syntax: set
int [interface],[critical|mgmt] ...
bal1-enable:failover [master] # set int eth0,mgmt eth7,critical eth8,critical eth9,critical eth10,critical
5.2.3.
Virtual IP Address (VIP)
Once your Elfiq Link Balancer units are configured in failover mode, you can create a virtual IP address (VIP) that will always connect you to the management interface of the master unit, no matter which of the two units is master. This is useful since almost all changes are made on the master unit and then replicated on the slave unit. Here is the following situation:
Figure 31: Management LAN with 2 Link LB units in failover mode with a virtual IP (VIP)
In this situation, to connect to the master unit, you would normally need to connect to either the 10.0.30.201 or 10.0.30.202 IP address. However, since either of those units can be master, it is more conventient to connect to the VIP which is 10.0.30.200.
Enable the VIP Command syntax: set
vip [ip] [netmask] [broadcast] [mac address]
bal1-enable:failover [master] #set vip 10.0.30.200 255.255.255.0 10.0.30.255
IMPORTANT: The fove module must be restarted in order to activate the virtual IP access.
137/160
Set Different vmac Groups In the event where you would have multiple sets of failover pairs within the same layer 2 network, you will need to distinguish each pair with an identifier. For this purpose, you may use different vmac groups. Command syntax: set
vmac group [0-3]
bal1-enable:failover [master] #set vmac group 0
You would then have a similar configuration on the other pair of Link LBs except that you would use a different vmac group identifier.
bal13-enable:failover [master] #set vmac group 1
138/160
6. Appendixes
6.1.
Installation Mode Elfiq Link Balancer units can be installed in a standalone (single) or failover mode for physical redundancy. The installation mode should be decided first because it can affect the available operation modes or require additional preconfiguration information. In a physical redundancy setup you should also plan for a pair of network switches that can support VLANs. ____ Single unit ____ Physical Redundancy (Two units in high availability mode with switches) NOTE: The physical redundancy installation requires an EOS version type with failover (FO) support. At this stage, it is also recommended to check the Configuration Guide and/or the Quick Configuration Guide in order to determine which scenario matches the most to your desired network infrastructure. This will also help you evaluate the number of physical Ethernet ports needed for your Link LB and the number of switches that might be required. Once you have completed this evaluation, you will be able to identify the primary link devices, the operating mode of your Link LB for the outside interfaces and the required configuration information
Appendix A: Information Sheets for Configuration
Primary Link Devices The primary link is usually the link in operation before installing the Elfiq Link Balancer. The primary link devices are the firewall(s) and other devices having IP addresses in the primary link IP range(s). The Link LB can support multiples devices on the primary link. Devices in high availability (for example two firewalls in failover) are also supported. The primary link device(s) traffic must pass through the Link LB via the Elfiq inside interface in order to be balanced on different links. The inside interface can be any Link LB port (except the management interface port) and is defined in the configuration. NOTE: Some advanced configuration could use multiple primary links. Typically this is done to install a Link LB to support two existing firewalls without any configuration change to the firewalls, each one operating with its original link IP addresses and default gateway.
Operating Mode for the Outside Interfaces The Link LB outside interfaces is connected to the link routers. Typically any Ethernet port besides the selected ports for the inside and management interfaces is available to be configured as an outside interface. Depending of your model, you have two or more available ports for the outside interfaces. Different operating modes are possible: ____ Monomode ____ Multimode ____ Monomode with VLANs ____ Mixed mode
139/160
Monomode One physical port per outside interface/link, no switch is required; crossover cables are used to connect the link routers to Link LB.
Multimode One physical port is the outside interface and is connected to an unmanaged switch or the untagged VLAN of a switch. All links are connected to the switch. This mode supports installations in physical redundancy. This mode also supports more links than the available number of physical Ethernet ports.switch. All links are connected to the switch. This mode also supports more links than the available number of physical Ethernet ports.
140/160
Monomode with VLANs One physical port is an 802.1q trunk with multiple outside interfaces. A switch supporting VLAN trunking is required. Each outside interface operates in its own VLAN and is connected to a link. This mode supports installations in physical redundancy. VLANs are also required when monomode cannot be used (more links than the number of available physical Ethernet ports) or when links are not compatible with multimode (multiple DHCP or PPPoE links cannot share the same layer 2 network).
Mixed Mode Both monomode and multimode or monomode with VLANs are used. This configuration is typically used and recommended for single unit installations with more than three links and where the LAN Failsafe feature is used. The inside and primary link outside interfaces are configured with the LAN Failsafe ports. Alternates links are configured on different outside interface(s) with an alternate physical port and a switch. This mode isolates at layer 2 the primary link devices and router from the alternate links and allows supporting more links than the number of available physical Ethernet ports for outside interfaces.
NOTE: It is important to carefully plan the required amount of physical Ethernet ports to be sure that your link balancer has enough to suit your needs. For example, the four Ethernet port units must be configured in multimode, monomode with VLANs or Mixed mode to support more than two links. If your model can support multiple link balancer instances (also called Virtual Forwarder Interface or VFI), planning the Ethernet ports for both VFIs is required.
141/160
NOTE: The dedicated management interface can be converted to an "outside interface" for the purpose of connecting additional alternate links. When the management interface is converted, you can still manage the unit through its console port or with a direct outside access to a virtual management IP. There are some restrictions involved in the ways to access or configure the unit once the management interface is converted.
Management Interface In order to manage your Elfiq Link Balancer, the first step that needs to be done is to decide and/or create a management LAN. Since the Link LB operates at the data link layer of the OSI model, and therefore does not have an IP address, it is impossible to manage the device through its operating interfaces. This design is also to meet the highest security standards by preventing access to the management from unsecured networks. One of the networks Ethernet port on the unit, referred to as the management interface (MGMT), is dedicated to the management of the device. It is through this interface that you will be able to connect either with an SSH connection, or with the graphical user interface in order to configure, manage and update the Elfiq Link Balancer. IMPORTANT: The management LAN is logically referred to as eth0 for all available models. For small networks, the management LAN may be connected to your internal network, as you may not have the infrastructure or the desire to dedicate an isolated network to this task. For larger networks, it is recommended that the management LAN resides on a separate network where access would be limited and filtered behind a firewall. This reduces the risk of possible intruders trying to log in and possibly modify your configuration. Once you have decided which network will be used as your management LAN, you can then determine the IP address that will be used for the management interface of your Link LB and required system information.
Hostname for the unit (i.e.: LinkLB): __________________ Configuration of the management interface (to be connected to a management network or your internal LAN): IP Address: Subnet Mask: _____._____._____._____ _____._____._____._____
Gateway IP Address: _____._____._____._____
Configuration of the Link LB in physical redundancy (Yes/No): _____ Second unit management IP address: _____._____._____._____
if yes:
Virtual IP address (This IP is shared by both units and used to access the master): _____._____._____._____
Usage of SNMP service (Yes/No): _____ IP address of SNMP server: SNMP community string:
if yes:
_____._____._____._____ ___________________
Usage of NTP service (Yes/No): _____ if yes: IP address of NTP server: _____._____._____._____
Frequency of refresh (in hours): ___________________
142/160
Usage of SMTP e-mail alert service (Yes/No): _____ IP address of SMTP server:
if yes:
_____._____._____._____ ____________________ ____________________ ____________________ ____________________
E-mail addresses to receive alerts:
Syslog server IP address: _____._____._____._____ NOTE: Any system respecting RFC3164 syslog standards can be used. Password for mgmt user: Password for enable user: __________________ __________________
NOTE: The management (mgmt) user password has read-only privileges to access the unit status and statistics. The enable user has full privileges to modify the unit configuration. NOTE: For remote management, you will need an SSH client that supports SSH version 2; such as OpenSSH for all UNIX/Linux platforms or PuTTY, for Microsoft Windows.
External Links for the Outside Interfaces Number of links to balance: ____ For each of those links, fill in the following form: Provider (ISP) name and link type IP address of ISP router Primary subnet mask Other subnets routed through this link Upload and download speed in kbps MTU Size (if known) Example MY_ISP_NAME, T1 Link 194.204.1.1 255.255.255.128 or /25 212.217.1.0/29 1544 / 1544 1492 Primary Link Link 2 Link 3
Primary Link Devices and Outgoing Services IP address of firewall or router: _____._____._____._____ IP address of second firewall or router (optional): _____._____._____._____ List all other devices installed on the primary link (in parallel of the firewall): Device VPN concentrator IP Address on the Primary Link 194.204.1.22 Note Example
143/160
Default source IP address for outgoing traffic (like web browsing):
_____._____._____._____ _____._____._____._____ _____._____._____._____ _____._____._____._____
List business critical outgoing services: Service Outgoing FTP access Outgoing DNS requests Site to site VPN Source IP Address on the Primary Link 194.204.1.115 194.204.1.127 194.204.1.22 Protocol tcp udp udp ipsec-esp Port 21 53 500 n/a Note Example Example Example
IMPORTANT: Some protocols are more complex to balance, especially encrypted protocols such as HA. Also, services such as SMTP can be sensitive to using multiple source IP addresses and may need special DNS PTR records. You will need to advise the proper service providers that from now on, this service might present itself from various source IP addresses and have the new ISPs create DNS PTR records.
Incoming Services List incoming protocols that will need to be balanced associated with their respective IP address on the primary link. Service and/or URL www.example.com vpn.example.com mail.example.com IP Address on the Primary Link 194.204.1.115 194.204.1.22 194.204.1.3 Protocol TCP TCP TCP Port 80 443 25 Note Example, website server Example, SSL VPN access SMTP server
144/160
DNS Services Management Are the DNS servers inside the local DMZ or network (DNS requests will pass through the Link LB) or externally hosted (remote location or via ISP)? _____ If the DNS servers are within my network: DNS IP addresses: _____._____._____._____ _____._____._____._____ IMPORTANT: If the DNS servers are hosted internally, once the Link Balancer has been installed, it is strongly recommended that you increase the redundancy of the DNS services by balancing the DNS requests between each external link (primary and alternate links). You will then be able to configure the Link LB for each of those DNS server addresses. If the DNS servers are hosted externally, you will need to plan the redirection of some DNS queries to the Link LB via each external link (primary and alternate links) in order to properly manage incoming traffic. You will need to verify this procedure with your service provider.
Balancing Notes for Various Protocols and Services There are a few key points to keep in mind when balancing protocols over different links. Most protocols will balance on multiple links without the need for any special configuration, but some protocols, especially the ones that verify source and destination, or the ones that establish multiple connections on various TCP/UDP ports, may need special configuration or changes in order to be balanced properly. In most of those cases, using persistent access-lists or persist triggers will be enough, since all connections to a given host will be carried over the same link, for the duration of the session. Other protocols or types of applications, however, will need to follow strict guidelines in order to be balanced properly. Below are some examples of the most used protocols and the verifications or changes that need to be performed before they can operate properly. FTP: Since FTP establishes a communication on various ports and exchange port numbers at layer 7, it needs to be handled in its own specific way. In order to balance FTP traffic, you need to use the protofix ftp statement. HTTP/HTTPS: HTTP and HTTPS traffic can be balanced without any issues. However, if you host or need to access web applications that require host based sessions, such as access to banking sites, you will need to enable persistent accesslists to or from these hosts. It is recommended by default in all Elfiq configuration examples and wizards. SIP: Since SIP establishes a communication on various ports and exchange port numbers and IP addresses at layer 7, it needs to be handled in its own specific way. In order to balance SIP traffic, you need to use the protofix sip statement. SMTP: For SMTP servers, source IP verification is often performed to prevent servers from being open mail relays. Therefore, if your SMTP server is hosted externally, you need to make sure that connections are accepted from the determined IP addresses of each of the links. If your SMTP server is hosted internally, to comply with SMTP standards, you should make sure that all IP addresses for which your SMTP servers can accept connections are listed as valid A and MX records in the DNS zone file of each hosted domain. Also, to ensure outgoing mail from the determined IP addresses of each of the links is RFC compliant, each determined IP address for outgoing SMTP must be registered with a PTR record in your ISP DNS servers. It is the system administrator responsibility to ensure the PTR record for each SMTP gateway address is registered with the SMTP gateway name. If you are not sure this PTR record is registered properly for your mail server on all your links, you should use the primary link for all outgoing SMTP mail (for example OPFA algorithm).
145/160
VPN: Since source IP verification is often performed when establishing VPN tunnels, its important to make sure that the remote VPN system accepts connections from the determined IP addresses for each of the links or support NAT traversal. If not, the VPN tunnel will not be established through the alternate links. The following list of protocols are the most commonly used protocols for which you should use special care when including them in the list of protocols/applications that must be balanced: ESP, H.323, HA, IRC, Kerberos, NFS, Portmapper, RADIUS, RTCP, RTP, VOIP.
6.2.
Appendix B: System Log Events
System event log messages can also be sent to a remote SYSLOG server. As such, the messages listed bellow can also be found in a SYSLOG servers log file. The Link Balancer system module centralizes informational log events that can be accesses and/or sent via the SMTP alert service. Severity levels are: 1: Alert 2: Warning 3: Notice 4: Information (or Info) The module is the EOS module. Modules are EOS2, SYST, BROK; BNET, WEB0, VFIx, FOVE. The %d parameter in a VFI module message code (for example VFI%d) refers to the VFI instance number. NOTE: %s parameter indicates the message will include a specific string in the message. %d, %ld, %u, %lu or %f parameters indicate the message will include a number. Event Code W-AUTH-001100 W-AUTH-001101 W-AUTH-001102 W-AUTH-001103 N-BNET-000144 W-BNET-000145 N-BNET-000146 N-BNET-000147 N-BNET-000149 N-BNET-000151 N-BNET-000152 N-BNET-000154 N-BNET-000155 N-BNET-000156 N-BNET-000157 W-BNET-000158 A-BNET-000159 N-BNET-000160 A-BNET-000161 N-BNET-000162 A-BROK-000200 I-EOS2-001007 N-EOS2-001008 N-EOS2-001010 W-EOS2-001011 Severity 2 2 2 2 3 2 3 3 3 3 3 3 3 3 3 2 1 3 1 3 1 4 3 3 2 Description Eos users: mgmt, password reset success Eos users: mgmt, password reset failed Eos users: enable, password reset success Eos users: enable, password reset failed User[mgmt], authentification failure Client ip [%s], pool is full no connection available User[%s], basic level, authenticated OK User[%s], basic level, authenticated REJECTED User[enable], authentification failure User[%s], enable level, authenticated OK User[%s], enable level, authenticated REJECTED REJECTED, bad user [%s] Dst[%s], Cmd[%s], REJECTED, not authenticated REJECTED, bad user [%s] REJECTED, bad user [%s] Wrong XML command, rc [%d], xml len [%d] Hub registration failed Inactivity timeout met, resetting connection Hub registration failed Api service ready Hub registration failed Component [%s] ended with rc [%d], cleaning sub-components Usb config file [%s] has [%ld] bytes Usb config file [%s] not found Usb device filesystem error
146/160
Event Code W-EOS2-006000 W-EOS2-006001 W-EOS2-006002 W-EOS2-006003 W-EOS2-006004 W-EOS2-006005 W-EOS2-006006 W-EOS2-006007 W-EOS2-006008 W-EOS2-006009 W-EOS2-006010 W-EOS2-006011 W-EOS2-006011 W-EOS2-006012 W-EOS2-006012 W-EOS2-006013 W-EOS2-006013 W-EOS2-006100 W-EOS2-006101 W-EOS2-006110 W-EOS2-006111 W-EOS2-006120 W-EOS2-006121 W-EOS2-006130 W-EOS2-006131 W-EOS2-006200 W-EOS2-006201 W-EOS2-006210 I-EOS2-007001 I-EOS2-007001 N-FOVE-002000 N-FOVE-002001 A-FOVE-002002 A-FOVE-002003 N-FOVE-002100 W-FOVE-002101 N-FOVE-002102 N-FOVE-002103 W-FOVE-002104 N-FOVE-002105 W-FOVE-002106 N-FOVE-002107 W-FOVE-002108 W-FOVE-002109 N-FOVE-002110 W-FOVE-002111 N-FOVE-002112 N-FOVE-002113
Severity 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 4 4 3 3 1 1 3 2 3 3 2 3 2 3 2 2 3 2 3 3
Description Eosupdate, start Eosupdate, ramfs failed Eosupdate, transfer[$z_transfert], file [$z_file2] Eosupdate, transfert failed Eosupdate, can not access flash device, aborting Eosupdate, [crypto] invalid EOSv2 image format Eosupdate, [uncompress] invalid EOSv2 image format Eosupdate, Eosv2 image file verified [OK] Eosupdate, replacing image cancelled by user Eosupdate, failed to backup flash configuration Eosupdate, done Webexpand, start Webexpand, start Webexpand, done Webexpand, done Webexpand: nothing to do, end Webexpand: nothing to do, end Flash2ram, start Flash2ram, done Flashrm, start Flashrm, done Net2ram, start Net2ram, done Ram2flash, start Ram2flash, done Eosprepare [$z_eosprepare_action], start Eosprepare [$z_eosprepare_action], ramfs failed Eosprepare [$z_eosprepare_action], done Restoring system configuration from flash Restoring system configuration from flash Vip enabled Vip disabled Hub attach failed, aborting service Hub registration failed Negotiations begin (pref MASTER) Network failure Peer already master, we go SLAVE Peer is negociating too, we go MASTER Peer didn't take the control, we go MASTER Negotiations begin (pref SLAVE) Network failure Peer already master, we go SLAVE Peer didn't take the control, we go MASTER Entering MASTER mode Taking master VIP OK Management failure or no L2FO from peer Warning - Peer is MASTER too, we go SLAVE Releasing master VIP OK
147/160
Event Code N-FOVE-002114 W-FOVE-002115 W-FOVE-002116 N-FOVE-002117 N-FOVE-002118 W-FOVE-002119 N-FOVE-002120 W-FOVE-002121 N-FOVE-002122 W-FOVE-002123 W-FOVE-002124 N-FOVE-002201 N-FOVE-002300 N-FOVE-002301 N-FOVE-002302 N-FOVE-002400 N-FOVE-002401 W-FOVE-002500 W-FOVE-002501 W-FOVE-002502 A-FOVE-002600 N-ISVU-005100 A-SYST-004001 W-SYST-004002 A-SYST-004003 A-SYST-004004 I-SYST-004100 I-SYST-004110 I-SYST-004111 I-SYST-004112 I-SYST-004113 W-SYST-004200 N-SYST-004201 A-VFI%d-000000 W-VFI%d-000000 N-VFI%d-000000 I-VFI%d-000000 N-VFI%d-009000 N-VFI%d-009001 N-VFI%d-009002 A-VFI%d-009003 A-VFI%d-009004 W-VFI%d-020001 W-VFI%d-020002 N-VFI%d-020003
Severity 3 2 2 3 3 2 3 2 3 2 2 3 3 3 3 3 3 2 2 2 1 3 1 2 1 1 4 4 4 4 4 2 3 1 2 3 4 3 3 3 1 1 2 2 3
Description Exiting MASTER mode Entering SLAVE mode Management failure Peer lost control state [%d], we go MASTER Exiting SLAVE mode Critical Failure Detected Critical Interface OK Management Failure Detected Management Interface OK The system is paused The system is resumed Failover services OK Peer IP don't match, closing connection Slave connected Master/Slave Synchronisation in progress Connected to master Connection with peer terminated, renegotiating Got one l2fo packet in interface [%s], but wrong data Got bad l2fo packet in interface [%s], wrong id [%u] Peer [%s], interface [%s] has same state [MASTER] as us, going to renegociate Hub registration failed ISV, Transaction failed, isv:%d Elfiq Operating System EOS [%d.%d.%d(%d)] loaded/initialized Cpu usage average [%.3f %%] met threshold [%d %%] Cpu temp average [%.3f C] met threshold [%d C] Fan RPM [%d] met threshold [%d] Hub registration failed Timezone [changed] Date [changed] Ntp [%s] Ntp [cleared] Smtp message transmission failed Failed, expected code [%d], invalid code [%d] from smtp server [%s] Iagrp:%d, description [%s] Iagrp:%d, description [%s] Iagrp:%d, description [%s] Iagrp:%d, description [%s] TCP probe[0] timeout for gmac:%lu [%s], tcpprobe [%s:%u] TCP probe[1] timeout for gmac:%lu [%s], tcpprobe [%s:%u] TCP probe error, polling on [%s] and receiving on [%s] Verification of gmac:%lu [%s] successful, enabled [link up] Verification of gmac:%lu [%s] failed, disabled [link down] Arp for mac address [%s] received on inside [%s], it belongs to my interface [%s], possible LOOP detected Arp for mac address [%s] received on outside [%s], it belongs to my interface [%s], possible LOOP detected Mac address of a GMAC has changed and defined as static, change rejected, ip [%s], mac [%s], new mac [%s]
148/160
Event Code W-VFI%d-020004 N-VFI%d-020005 W-VFI%d-020006 I-VFI%d-020100 I-VFI%d-020101 I-VFI%d-020103 I-VFI%d-020104 I-VFI%d-020105 I-VFI%d-020106 I-VFI%d-020107 I-VFI%d-020108 I-VFI%d-020109 I-VFI%d-020110 I-VFI%d-020111 N-VFI%d-020150 W-VFI%d-020200 W-VFI%d-020201 I-VFI%d-020202 I-VFI%d-020203 N-VFI%d-020204 N-VFI%d-020205 W-VFI%d-020206 W-VFI%d-020207 I-VFI%d-020208 N-VFI%d-020209 N-VFI%d-020210 N-VFI%d-020211 N-VFI%d-020211 N-VFI%d-020212 N-VFI%d-020213 N-VFI%d-020214 I-VFI%d-020215 I-VFI%d-020216 I-VFI%d-020217 N-VFI%d-020218 N-VFI%d-020219 N-VFI%d-020220 N-VFI%d-020221 N-VFI%d-020221 I-VFI%d-020222 N-VFI%d-020223 N-VFI%d-020224 N-VFI%d-020225 N-VFI%d-020226 N-VFI%d-020227 A-VFI%d-020228 A-VFI%d-020229 I-VFI%d-020232
Severity 2 3 2 4 4 4 4 4 4 4 4 4 4 4 3 2 2 4 4 3 3 2 2 4 3 3 3 3 3 3 3 4 4 4 3 3 3 3 3 4 3 3 3 3 3 1 1 4
Description Mac address auto discovery for ip [%s] type [%s] failed, retrying Arp for [%s] already exists as a GMAC, change rejected Device ip [%s] type [%s] stopped responding to arp request, retrying Flow change, rflow [active] for geotag [%d] Flow change, rflow [blocking] for geotag [%d] Flow change, incoming traffic flow [active] for geotag [%d], requester [%s] Flow change, incoming traffic flow [blocking] for geotag [%d], requester [%s] Flow change, incoming traffic flow [established] for geotag [%d], requester [%s] Flow change, outgoing traffic flow [active] for geotag [%d], requester [%s] Flow change, outgoing traffic flow [blocking] for geotag [%d], requester [%s] Flow change, outgoing traffic flow [standby] for geotag [%d], requester [%s] Flow change, resources [active] for geotag [%d], requester [%s] Flow change, resources [blocking] for geotag [%d], requester [%s] Flow change, resources [standby] for geotag [%d], requester [%s] Geotaggrp:%d change from [%s] to [%s] TCP probe failure threshold met for gmac:%lu [%s], disabled [link down] TCP probe OK for gmac:%lu [%s], enabled [link up] Gmac:%lu [%s], admin disable%s Gmac:%lu [%s], admin enable Gmac:%lu [%s], incoming traffic [%d %%] current use, last %d seconds Gmac:%lu [%s], outgoing traffic [%d %%] current use, last %d seconds Gmac:%lu [%s], incoming traffic [%d %%] average use, last %d seconds, link saturated Gmac:%lu [%s], outgoing traffic [%d %%] average use, last %d seconds, link saturated Gmac:%lu [%s], stats reset Gmac:%lu [%s], can't be inserted, same MAC is used by gmac:%lu Gmac:%lu [%s], mononode [%s] and receiving mac from other interface [%s] Gmac:%lu [%s], can't be inserted, limit [%d] Gmac:%lu [%s], can't be inserted, limit [%d] Mac alias, can't be inserted, table is full Mac alias, can't be inserted, table is full Mac alias, can't be inserted, already associated Gmac:%lu [%s], admin disable via geolink Gmac:%lu [%s], admin enable via geolink Gmac:%lu [%s], admin disable geolink timeout, ttl [%lu] Gmac:%lu [%s], can't be inserted, parent [gmac:%lu] does not exist Gmac:%lu [%s], can't be inserted, parent [gmac:%lu] is a child Gmac:%lu [%s], can't be inserted, parent [gmac:%lu] child table is full Gmac:%lu [%s], has no parent, incomplete Gmac:%lu [%s], has no parent, incomplete Gmac:%lu [%s], linked to parent gmac, completed Gmac:%lu [%s], linked to parent gmac, incomplete Gmac:%lu [%s], enforcing /32 network on gmac child Gmac:%lu [%s], can not be completed, mac already in use Gmac:%lu [%s], can not be completed, dhcp:%lu on different port Gmac:%lu [%s], can not be completed, pppox:%lu on different port Gmac:%lu [%s], is considered unstable (link flap), admin disabled [link down] Gmac:%lu [%s], reactivating gmac, admin enable Gmac:%lu [%s], icv action admin disable
149/160
Event Code I-VFI%d-020233 N-VFI%d-020234 I-VFI%d-020238 A-VFI%d-020240 A-VFI%d-020241 N-VFI%d-020242 N-VFI%d-020243 N-VFI%d-020244 N-VFI%d-020245 N-VFI%d-020246 W-VFI%d-020247 W-VFI%d-020248 W-VFI%d-020300 W-VFI%d-020301 N-VFI%d-020302 N-VFI%d-020303 N-VFI%d-020304 N-VFI%d-020305 N-VFI%d-020306 I-VFI%d-020307 I-VFI%d-020308 N-VFI%d-020400 N-VFI%d-020401 N-VFI%d-020402 I-VFI%d-020500 I-VFI%d-020501 I-VFI%d-020502 I-VFI%d-020503 I-VFI%d-020600 I-VFI%d-020601 I-VFI%d-020602 I-VFI%d-020603 I-VFI%d-020604 I-VFI%d-020610 W-VFI%d-020700 I-VFI%d-020701 I-VFI%d-020702 I-VFI%d-020703 W-VFI%d-020704 A-VFI%d-020705 A-VFI%d-020706 I-VFI%d-020707 N-VFI%d-020800 N-VFI%d-020800
Severity 4 3 4 1 1 3 3 3 3 3 2 2 2 2 3 3 3 3 3 4 4 3 3 3 4 4 4 4 4 4 4 4 4 4 2 4 4 4 2 1 1 4 3 3
Description Gmac:%lu [%s], icv action admin enable Resetting dhcp:%d of gmac:%lu [%s] Gmac:%lu [%s], icv action stats reset TCP probe failure threshold met for gmac:%lu [%s], last %d seconds, disabled [link down] TCP probe OK for gmac:%lu [%s], after downtime greater than %d seconds, enabled [link up] Gmac:%lu [%s], can't be inserted, no throughput available Gmac:%lu [%s], max in throughput exceeded [%lu kbps], corrected speed in [%lu kbps] Gmac:%lu [%s], max out throughput exceeded [%lu kbps], corrected speed out [%lu kbps] Gmac:%lu [%s], max in throughput exceeded [%lu kbps], corrected speed in [%lu kbps] Gmac:%lu [%s], max out throughput exceeded [%lu kbps], corrected speed out [%lu kbps] Dhcp:%lu released for gmac:%lu [%s], disabled [link down] Pppox:%lu released for gmac:%lu [%s], disabled [link down] Spath:%lu [%s], polling threshold met, status change to [down] Spath:%lu [%s], status change to [up] Spath:%lu [%s], can't be created, limit [%d] Spath:%lu [%s], can't be created, invalid spathgrp:%lu Spathgrp:%lu, can't be created, limit [%d] Spath:%lu [%s], can't be created, spathgrp:%lu is full Spath group clr, group id [%lu] failed, use count > 0 Spathgrp:%lu, icv action stats reset Spathgrp:%lu, stats reset Idns rr can't be inserted, limit [%d] Idns rr, rra merge limit reached Idns rr, isv group merge limit [%d] reached Inline access, SSH session started, client ip [%s] Inline access, SSH session ended, client ip [%s] Inline access, API session started, client ip [%s] Inline access, API session ended, client ip [%s] Clearing all VFI configuration Acquiring VFI reconfig state Releasing VFI reconfig state Pausing VFI operations Resuming VFI operations Attach failed, if_name [%s] Poolip masq init failed Ready, initial status [paused] reason [failover] Ready, initial status [running] Outside interface [%s%s], carrier ok, [interface up] Outside interface [%s%s], carrier lost, [interface down] Inside interface [%s%s], carrier ok, [interface up] Inside interface [%s%s], carrier lost, [interface down] Reconfig_lock released, timer exceeded Failed, interface [%s] already in use Failed, interface [%s] already in use
150/160
Event Code W-VFI%d-020900 W-VFI%d-020901 I-VFI%d-020902 I-VFI%d-020903 I-VFI%d-020904 N-VFI%d-020905 N-VFI%d-020906 N-VFI%d-020907 I-VFI%d-020908 I-VFI%d-020909 I-VFI%d-021001 I-VFI%d-021002 I-VFI%d-021101 I-VFI%d-021102 I-VFI%d-021201 I-VFI%d-021202 A-VFIU-005000 I-WEB0-007000 I-WEB0-007001
Severity 2 2 4 4 4 3 3 3 4 4 4 4 4 4 4 4 1 4 4
Description isvgrp:%d, state change [down] caused by isv:%u, down count [%hu] isvgrp:%d, state change [up] caused by isv:%u, down count [%hu] Isv:%u [%s], admin state change [enable] Isv:%u [%s], admin state change [disable] Isv:%u [%s], state change [disable] Isv:%u [%s], state change [ok] Isv:%u [%s], state change [down] Isv:%u [%s], state change [incomplete] Isv:%u [%s], update timeout, state change [down] Isv:%u [%s], update timeout, state change [down] Iagrp:%d, icv action enable Iagrp:%d, icv action disable Qos:%lu, icv action stat reset Qos:%lu, stats reset Vfi, icv action stat reset Vfi, stat reset Hub registration failed Sid [%s], user[%s], login ok Sid [%s], user[%s], logout ok
6.3.
Appendix C: API Programming Examples
The following examples are samples of code in various languages that illustrate how to communicate with the Elfiq Link Balancer through the application programming interface. Any command that can be issued on the command line interface can be used in the application programming interface, which means that you are free to create maintenance, modification or monitoring applications tailored for all your needs.
Example in C This is a simple Linux application in C. For other UNIX platforms, some modifications to the code, such as libraries and sockets, might be required. Please consult your platforms respective documentation for more information.
/* -----------------------------------------------------Author: Date: Project: Source: Version: Elfiq Inc. 2004 sample1.c
Description: very simple C app using Link Balancer API's Paths: Changes: ------------------------------------------------------ */ #include #include #include #include <stdio.h> <string.h> <unistd.h> <fcntl.h>
#include <sys/types.h>
151/160
#include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #define LINK_LB_API_PORT #define #define #define #define #define #define g_user g_pass g_enab g_dest g_cmd g_dst_ip 9998
"mgmt" "mgmt" "" "syst" "sh ver" "192.168.30.245"
// m a i n int main(void) { int int int int char struct sockaddr_in struct in_addr char char fd_set struct timeval fds; tv;
flags = 0; nb; rc; sock; ascii_ip[128]; s_in; bin_ip; cmd_req[2048]; buffer[65536];
socklen_t s_len = sizeof(struct sockaddr); strcpy(ascii_ip, g_dst_ip); if (inet_pton(AF_INET, ascii_ip, &bin_ip) < 0) { printf("Invalid ip address [%s]\n", ascii_ip); return 0; } printf("Connecting to Link LB at [%s:%d]\n", ascii_ip, LINK_LB_API_PORT); memset(&s_in, 0x00, sizeof(struct sockaddr_in)); memcpy(&s_in.sin_addr,&bin_ip,sizeof(struct in_addr)); s_in.sin_family = AF_INET; s_in.sin_port = htons(LINK_LB_API_PORT); if ((sock = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) { printf("Can't open socket\n"); return 0; } if ((rc = connect(sock,(struct sockaddr*)&s_in, s_len)) < 0) { close(sock); printf("Can't connect to [%s]\n", ascii_ip); return 0; } sprintf(cmd_req, "<cmd user=\'%s\' pass=\'%s\' enab=\'%s\' dst=\'%s\' cmd=\'%s\'/>", g_user, g_pass, g_enab, g_dest, g_cmd); sprintf(buffer, "%04X%s", strlen(cmd_req), cmd_req); printf("Sending [%s]\n", buffer); // sending to the Link LB
152/160
if ((nb = send(sock, buffer, strlen(buffer), 0)) != nb) { close(sock); printf("Send failed\n"); return 0; } // going into non-blocking mode for receving fcntl(sock, F_GETFL, flags); fcntl(sock, F_SETFL, flags | O_NONBLOCK); while (1) { FD_ZERO(&fds); FD_SET(sock, &fds);
// initialise the file descriptior set // put our filedescriptior to the set
tv.tv_sec = 2; // 2 seconds for the timeout tv.tv_usec = 0; // 0 micro-seconds // verifying if the our socket is ready if ((rc = select(FD_SETSIZE, &fds, NULL, NULL, &tv)) < 0) { printf("Error in select\n"); close(sock); return 0; } else if (rc == 0) { printf("Timeout in select\n"); close(sock); return 0; } else { if (FD_ISSET(sock, &fds)) { // getting the data if ((nb = recv(sock, buffer, 65536, MSG_NOSIGNAL) > 0)) printf("Receiving [%s]\n", buffer); } } } close(sock); return 0; }
Example in Perl Another example on Linux, but this time in Perl; which means that it should easily be ported to the platform of your choice.
#!/usr/bin/perl # Elfiq Inc. 2004 # # Simple API application for Link Balancer # use IO::Select; use IO::Socket; my $rc = 0; ############################################################################
153/160
## C O N F I G U R A T I O N ## C O N F I G U R A T I O N my $r_ip my $r_port 'mgmt'; my $r_pass my $r_enab ## a list of commands my @list_cmd = ( [ "syst", "set logging 192.168.30.252", 0 ], [ "syst", "sh conf", 0 ] ); $rc = talk_to_linklb($r_ip, $r_port, \@list_cmd, $r_user, $r_pass, $r_enab); exit(0); ############################## R O U T I N E S ############################# ############################## R O U T I N E S ############################# ############################## R O U T I N E S ############################# ## t a l k _ t o _ l i n k l b sub talk_to_linklb($$$$$$) { my $remote_ip = shift; my $remote_port = shift; my $ref_list_cmd = shift; my $user = shift; my $pass = shift; my $enab = shift; my $sock = new IO::Socket::INET ( PeerAddr => "$remote_ip", PeerPort => "$remote_port", Proto => 'tcp' ) or return -1; $sock->autoflush(1); foreach $lref (@$ref_list_cmd) { my $component = $$lref[0]; my $command = $$lref[1]; my $timer = $$lref[2]; my $req_xml my $req_len my $buffer = ""; = 0; = ""; = '192.168.30.245'; = 9998; = 'mgmt'; = 'mgmt'; ## VIP or management IP of Link LB ## default port for APImy $r_user =
$req_xml = "<cmd user=\'$user\' pass=\'$pass\' enab=\'$enab\' dst=\'$component\' cmd=\'$command\'/\>"; $req_len = length($req_xml); $buffer = sprintf("%04X%s", $req_len, $req_xml); print "the Request: req_xml = [$req_xml]\n"; ## sending the request to the Link LB print $sock $buffer; my $rset = new IO::Select($sock); while (1) { my $tmp1;
154/160
my @ready_set = $rset->can_read(1); if ($ready_set[0] == $sock) { recv($sock, $tmp1, 65536, 0); last if ("$tmp1" eq "");
## timeout of 1 seconds
## removing answer length (4 digits in hex) substr($tmp1, 0, 4) = ""; ## print the answer print "$tmp1\n"; ## ## ## ## ## } else { last; } } sleep($timer); } ## foreach close($sock); return 0; } parse parse parse parse parse the the the the the XML XML XML XML XML here here here here here
Example in .NET Here is a sample of a VB.NET 2003 form which contains the relevant information for the Elfiq Link Balancer API. The complete VB.NET project is available in a compressed archive on the CDROM that came with your Link LB.
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim tcpClient As New TcpClient Try ' We connect to the Link LB's management IP and port tcpClient.Connect(Me.tbIP.Text, Integer.Parse(Me.tbPort.Text)) tbOutput.Text = "Connected" & vbCrLf ' We send a command and wait for the response, for the first command, ' we must provide good username, password and enable password. ' We send the "sh ver" command to the "syst" module Me.SendCmd("sh ver", "syst", tbUsername.Text, tbPassword.Text, tbEnable.Text, tcpClient) Catch ex As ArgumentNullException Console.WriteLine("ArgumentNullException: {0}", ex) Catch ex As SocketException Console.WriteLine("SocketException: {0}", ex) Finally ' Close everything. tcpClient.Close() tcpClient = Nothing End Try End Sub Sub SendCmd(ByVal cmd As String, ByVal dst As String, ByVal username As String, ByVal password As String, ByVal enable As String, ByVal tcpClient As TcpClient) ' We build the command to send (in XML) Dim builder As New StringBuilder builder.Append("<cmd user='") builder.Append(username)
155/160
builder.Append("' pass='") builder.Append(password) builder.Append("' enab='") builder.Append(enable) builder.Append("' dst='") builder.Append(dst) builder.Append("' cmd='") builder.Append(cmd) builder.Append("'/>") ' We append the lengt (4 digits, in hexadecimal) of the XML command at the ' start (ex. 001A<cmd ...) Dim to_send As String = Format(builder.ToString().Length(), "X4") & builder.ToString() Dim data As [Byte]() = System.Text.Encoding.ASCII.GetBytes(to_send) ' Get a client stream for reading and writing. ' Stream stream = client.GetStream(); Dim stream As NetworkStream = tcpClient.GetStream() ' Send the message to the connected TcpServer. stream.Write(data, 0, data.Length) tbOutput.Text = tbOutput.Text & ("Sent: " & to_send) & vbCrLf ' Receive the TcpServer.response. ' Buffer to store the response bytes. data = New [Byte](1024) {} ' String to store the response ASCII representation. Dim responseData As [String] = [String].Empty ' Read the first batch of the TcpServer response bytes. Dim bytes As Int32 = 0 Dim i As Integer = 0 For i = 0 To 9 If stream.DataAvailable Then bytes = stream.Read(data, 0, data.Length) responseData = System.Text.Encoding.ASCII.GetString(data, 0, bytes) tbOutput.Text = tbOutput.Text & ("Received: " & responseData) & vbCrLf Exit For End If tbOutput.Text = tbOutput.Text & ("Sleeping") & vbCrLf Thread.Sleep(100) Next If bytes = 0 Then tbOutput.Text = tbOutput.Text & ("NO DATA RECEIVED") & vbCrLf End If End Sub
6.4.
Appendix D: DNS Delegation on a Microsoft DNS Server
In order to properly route DNS queries from external DNS servers to the Elfiq Link Balancer, you will need to configure the delegation for name resolution of all the entries that you wish to balance to the Link LB. The example in that section dealt with the BIND DNS server. Here is how this would be performed in a Microsoft Windows 2003 DNS server. IMPORTANT: These configuration changes are only needed if your DNS server is hosted externally, or if it is hosted internally but serves as a master for slave servers that are hosted externally. They do not need to be performed if all your public DNS servers are behind your Elfiq Link Balancer. STEP 1: Create a new delegation The first step in adding a new delegation is to select the domain for which you want to add the new delegation, right click it and then select the New Delegation option.
156/160
A window will then initiate the New Delegation Wizard.
Click Next to continue. STEP 2: Select the name of the delegation The second step is to determine the name of the delegation. Normally, this is used to delegate a full subdomain, but in our case, the Link LB will answer as if it was asked to resolve a hostname. Therefore, the name of the DNS domain that we want to delegate is the name of the resource that we want to balance. In this case, the example is www:
157/160
Once this is completed, press Next to continue. STEP 3: Specify the name servers for the delegation The third step is to specify the name servers to which we will delegate this resource.
Click on the Add button to add the name servers to be used for this delegation.
158/160
The given name to the virtual name server can be anything you wish, but it is very important that it points to the IP addresses that will be specified in the IDNS resource records of your Link LB. You need to specify as many IP addresses for this name server as you will have virtual DNS servers, which normally means one per link that you wish to balance. Click OK to continue. A window will then display the DNS configuration for this new delegation.
Click Next to continue. This will complete the wizard and the new delegation will be completed. Afterwards, you will be able to view your new delegation as a grayed sub tree entry into your DNS zone.
159/160
Selecting the delegation will illustrate its configuration, which will display the virtualdns.example.com DNS server that has been configured for it. Simply repeat the process for each of the resources that you wish to balance in your Link LB.
160/160

Elfiq Linkbalancer Administrator Guide v3 04 PDF

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Elfiq Linkbalancer Administrator Guide v3 04 PDF

Caricato da

Copyright:

Formati disponibili

Elfiq Link Balancer (Link LB) Administrator Guide

Elfiq Operating System (EOS) - Version 3.5.2 and higher

Elfiq Networks (Elfiq Inc.) www.elfiq.com

1. About the Document

Conventions In this document, the following conventions are used:

command name [parameter1] [parameter2option1|parameter2option2]

Example configurations or excerpts from output of commands are written in a box:

Copyright 2004-2011, Elfiq Networks (Elfiq Inc.). All rights reserved.

SYSTEM MODULE (SYST) .................................................................................................................................. 19

SMTP Alert Service ............................................................................................................................................................... 29

VIRTUAL FORWARDER INTERFACE (VFI) .................................................................................................. 49

4.3.7. 4.3.8. 4.3.9. 4.3.10. 4.3.11. 4.3.12.

4.9.3. 4.9.4. 4.9.5.

FAILOVER MODULE (FOVE).......................................................................................................................... 134

APPENDIXES ...................................................................................................................................................... 139

About the Elfiq Link Balancer

Typical setup with a single Internet Service Provider (ISP):

Figure 1: Typical setup with a single Internet Service Provider (ISP)

Typical setup with two Internet Service Providers (ISP):

ISP Bs router IP: 212.217.1.1/28

Figure 3: USB, console, and Ethernet ports

Access the Elfiq Link Balancer

Configure and Manage the Elfiq Link Balancer

Required Information before Configuring

Command Line Interface (CLI)

Elfiq Operating System (EOS) Overview

sh ver command from any

Navigate through EOS Modules

Graphical User Interface (GUI)

Figure 4: Graphical User Interface

Application Programming Interface (API)

Monitoring and Troubleshooting

System Log Events

Display System Log Events

VFI Probe and Statistics

Enable the Probe Feature Command syntax: feature

Display Probe Statistics Command syntax: sh

probe report [number of sessions]

LinkLB:vfi0 [single] #sh probe report 10 Top 10 live sessions

Report generated Mar 14 2011 10:33:49

Reset Probe Statistics Command syntax: clr

Display VFI Statistics Command syntax: sh

Reset VFI Statistics Command syntax: clr

3. System Module (syst)

About System Module

Elfiq Networks (Elfiq Inc.) Support: support@elfiq.com

Website: www.elfiq.com License status: key ok LinkLB-mgmt: [single] #

set date [yyyy]-[mm]-[dd] [hh]:[mm]:[ss] set utc timezone [+|-][hh:mm]

Set Local Time Zone

set timezone [zone]

The list of available time zones can be viewed with the

Set a Network Time Protocol (NTP) Server

ntp server [ip address] [refresh interval (hours)]

Set the IP Address

set mgmtip [ip address] [netmask] [broadcast] | [ip address]/[netmaskbits] [gateway]

Set the Default Gateway

LinkLB-enable:system [single] #set gateway 10.200.25.1

Set IP Address and Default Gateway Simultaneously

set mgmtip [ip address] [netmask] [broadcast] | [ip address]/[netmaskbits] [gateway]

Set the Hostname

set hostname [name]

Set SYSLOG Server Information