This connection type also activates a GUI feature that allows you to build your own custom TCP/IP packets. Because LANforge has almost no control over what you send, it cannot detect received packets on the other end of the connection. You can use traffic sniffers or look at the port counters to get ideas of how many packets were actually received. See Configuring Payloads. Custom Ethernet endpoints will receive, count, and throw away frames accepted by the port the endpoint runs on. This includes any packets sent by other LANforge connections. If the port is put into PROMISC mode, the port may even receive frames destined for other MAC addresses. So, received packets/bytes/bits-per-second stats for Custom Ethernet protocols should be used with care. UDP traffic is a non-stream oriented IPv4 protocol that is commonly used for streaming video, music, and other real-time (and possibly lossy) protocols. UDP can be routed, so it is not constrained to the local LAN like the Ethernet protocol is.
UDP6 is similar to UDP, but uses the IPv6 protocol.
Custom UDP connections let you specify the exact bytes to transmit as the payload of a UDP datagram. This might be useful for simulating RTP, for instance. See Configuring Payloads.
TCP is a stream based protocol that carries the vast bulk of the Internet's traffic. It is routable, and it will re-transmit packets that are dropped, so the only packets LANforge should show as dropped are those that are still in the kernel buffers, or those in transit when the CX is stopped. LANforge can report the number of retransmitted packets on Linux. This provides an estimate of dropped frames, but TCP may also retransmit on an overly delayed packet that was not actually lost.
TCP6 is similar to TCP, but uses the IPv6 protocol which provides a much larger address space and is expected to replace IPv4 sometime in the future.
Custom TCP connections let you specify the exact bytes to stream over a TCP/IP connection. LANforge has no way of knowing where one of your 'packets' starts or ends, so it cannot detect dropped or mangled bytes on the receive side. You can use the bytes sent and received counters to get a good idea though. See Configuring Payloads.
SCTP is a protocol with a mix of features somewhat simialar to UDP and TCP. It runs over IPv4, generates PDUs similar to UDP, but has guaranteed delivery and ordering guarantees like TCP. It is only supported on Linux platforms.
SCTP6 is the same as SCTP, except it runs over the IPv6 protocol.
Report Timer The Report Timer specifies how often the LANforge data generators send updates to the LANforge server, and how often the LANforge server pushes endpoint information up to the clients (GUIs) that have requested the automatic updates. If you are running the GUI over a slow link, or have a slower machine, it is recommended to increase the report timer to 5000ms (5 seconds) or higher. Test Manager The Test Manager specifies who 'owns' this CX, and can be used to segregate a large LANforge system for use by many engineers. For most users, however, assigning all CXs to the default_tm Test Manager is fine. Quiesce When the user clicks 'Quiesce' to stop a test, instead of just 'Stop', LANforge will gracefully stop the transmitting Endpoint and wait the selected number of seconds before stopping the receiving Endpoint so that test data flowing through the device-under-test will be completely received by LANforge. This can give more exact results when doing detailed investigation of packets and bytes sent and received, for instance. Layer-3 Cross Connect Endpoints The left and right form columns of each info panel are used to define endpoints A and B. They are labeled TX Endpoint and RX Endpoint and are respectively colored green and purple. Endpoints are generally symmetric for UDP and Ethernet. For TCP/IP, the TX endpoint acts as a client, and the RX endpoint acts as a server (it waits for connections). Selecting different options may enable/disable certain fields. Resource The machine on which this endpoint should reside. Port The physical or virtual interface with which this endpoint should be associated. Min Tx Rate The minimum transmit rate that LANforge will attempt to send, in bits per second. This value is not applicable for the packet-capture replay function as the packets are replayed at the exact rates they were captured. Max Tx Rate The maximum transmit rate that LANforge will attempt to send, in bits per second. If this is greater than the min-tx-rate, then LANforge will vary the speed between the min and max creating a random stairstep pattern of data transmission over time that randomly returns to the min-tx-rate. That is, the traffic distribution is a random rate and random duration burst with random intervals between bursts. The bursts are bounded by the Min and Max TX Rate. Traffic will initially be sent at the Tx Min rate. This value is not applicable for the packet-capture replay function as the packets are replayed at the exact rates they were captured. Min/Max PDU Size The write size, in bytes. The PDU size includes only the bytes for the selected protocol. For instance, if you select a 1472 byte packet for a UDP connection, the Ethernet frame will actually be 1514 bytes in length because of the addition of the 14 bytes of Ethernet header, the 20 bytes of IP header, and the 8 bytes of the UDP header. When configuring an Ethernet connection, you would select a length of 1514 to create a packet of 1514 bytes since there is no underlying data protocol.For UDP and TCP protocols, the packets on the wire will never exceed the port's MTU + Ethernet-Header-Length (1514 on normal Ethenet ports). If the maximum is larger than the minimum, then each packet will be a random size between min and max. NOTE: When using IPv4 or IPv6 multicast, LANforge may have trouble receiving PDUs that span multiple frames. So, a maximum payload size of 1472 is suggested. Please contact support if you want more details on this restriction. IP ToS For IP based protocols, you can specify the ToS (aka QoS) bits in the IP header. This can be useful for testing QoS settings in the device under test. You can select one of the values from the drop-down menu or enter your own value. The following website might be helpful in decyphering ToS and DSCP values: , -tos. NOTE: When running LANforge in Windows, QoS must first be setup by following the instructions in the Microsoft Knowledge Base article 248611: =kb;EN-US;q248611 Pkts to Send This specifies the number of packets to send before LANforge will automatically quiesce the test. Set this value to zero (Infinite) to have the test run until stopped by the user. Pld Pattern The payload pattern for the data generated by LANforge: Increasing: A pattern of bytes repeatedly incrementing from 0x00 to 0xFF. Decreasing: A pattern of bytes repeatedly decreasing from 0xFF to 0x00. Random: A pattern of random bytes from 0x00 to 0xFF. This pattern is generated for every packet sent and hence is CPU intensive. Random-Fixed: A pattern of random bytes from 0x00 to 0xFF is created for the first packet and then duplicated for subsequent packets. Zeros (0x00): A payload of only zeros. Ones (0xFF): A payload of all 0xFF. CUSTOM: A user-specified payload pattern. PRBS-4-0-3: A payload pattern from a 4-bit linear shift register. PRBS-7-0-6: A payload pattern from a 7-bit linear shift register. PRBS-11-8-10: A payload pattern from a 11-bit linear shift register. PRBS-15-0-14: A payload pattern from a 15-bit linear shift register. Min/Max IP Port If left 'AUTO', the LANforge system will select the IP ports for both transmit and receive endpoints. The user can also specify a particular IP port, but should be aware of potential port conflicts with other LANforge tests and third-party services running on the Linux machine. Endpoints will send traffic with the source IP port as specified, and peer endpoints will send to that port. To send traffic to a specific port without expecting a response from the target, the destination port can be specified by making the receive endpoint UnManaged and specifying the destination IP and IP Port. If configured to make many connections with the TCP Duration option, set the IP Port to 0 (zero) or use a large range on the 'A' endpoint. Using 0 means that the OS can choose any local IP port that it wishes when making the connections. A previously used IP port will not be usable for a short timeout period (30+ seconds typically). These timers are configurable in most operating systems...contact support if you have questions. TTL This specifies the 'time-to-live' when configuring Multicast endpoints. It does not apply to other prototocols at this time. Min/Max Duration This specifies how long the connection will run before it is torn down and reestablished. For instance, this option can be used to test how many TCP connections per second a firewall can handle. If you want a single long running connection, just use 'Forever'. Otherwise, select the number of milliseconds the connection should run before it is reestablished. NOTE: You should set the IP Port to 0 (zero) or use a large port range on the endpoint A (this is the endpoint that originates the connection) when setting TCP Duration to values other than 'Forever'. Min/Max Reconn This determines how long to wait before initiating a new connection. This only takes affect when using Min/Max duration. Multi-Conn LANforge now supports running Endpoints in separate processes to make optmimal use of multi-core CPU systems. In addition, it is now possible to create multiple TCP connections for TCPv4 and TCPv6 Cross-Connect types. The first option of simply running the Endpoint in a separate process involves setting Multi-Conn to 1. This works for UDP and TCP Layer-3 Cross-Connects. To enable multiple concurrent connections in a single TCP cross-connect, use '1' for the 'B' endpoint (since it acts as the server-side socket) and then set the connection count in the A endpoint. For instance, if you wanted 5000 TCP connections to test your firewall, set Multi-Conn to 5000 on the A endpoint, and 1 on the B endpoint. The settings for the endpoint (rate, packet size, etc) will be the same for each of the multi-connections. So, if you have Multi-Conn of 5000 and a min/max speed of 100kbps, LANforge will attempt to generate 500Mbps of traffic. The statistic totals for all multi-connections will be reported in the single Cross-Connect. Running multiple thousands of multi-connections is much more efficient than running thousands of regular Layer-3 connections in LANforge, but it still uses up resources. It is suggested that you ramp up your load slowly at first to make sure your system has enough RAM and CPU power to handle the load. NOTE: Some advanced features, such as using IP address ranges, cause the endpoints to be started and stopped. When this happens to multi-conn endpoints, the counters for the previous run will be cleared each re-start. This limitation may be fixed in future releases if it becomes a problem. IP Addr When using secondary IP addresses, you may choose the primary or any of the secondaries for each endpoint. You may also choose to use a random IP address or do a linear walk of all addresses on the configured interface (Port). When using random or linear IP addresses, the connection logic should be configured to only run for a limited duration (see Min Duration). Internally, this will cause LANforge to stop and restart the connection when the duration is completed, choosing a new IP address and/or IP port as needed. For un-managed endpoints, it specifies the destination IP address for the peer interface. Replay File Select this to replay a previously captured packet stream specified in the 'Filename' field for Custom-Ethernet connections. For other connection types, the file contents will be used as payload for the selected protocol. Loop When this and 'Replay File' is selected, the file will be replayed continuously until the user stops the test. When Loop is NOT selected, the test will stop after the file has been played once. Filename This field is only available when the Replay File checkbox selected. For the Custom-Ethernet protocol, this selects the filename for replaying a previously captured stream of packets. The file capture protocol must be pcap or the proprietary format saved by LANforge-ICE. For other protocol types, the file data will be used as the protocol payload. This would be somewhat similar to a file-transfer protocol such as FTP or HTTP. Dest MAC The destination MAC address to be used when replaying a packet capture. This is useful for replaying captured files against a different router than was originally sniffed. The MAC should address should be that of the router's interface connected to LANforge. Send & Receive Buffer Size Configure socket buffer send and receive buffer sizes. For TCP connections, this correlates to sending and receiving window sizes. Using the OS Default is suggested for most users, but setting it larger can increase throughput in some higher-latency situations. Send Bad FCS For layer-2 Ethernet protocols one can also specify the number of frames to be generated with purposefully bad Ethernet CRCs. This 'bad CRC' feature is only supported by certain Ethernet adapters and drivers. Please contact Candela if you wish to use this feature. Src MAC This is used to configure the MAC address of un-managed layer-2 Ethernet endpoints. The peer (managed) interface will then send packets to this MAC. Use-Proxy Selecting the Use-Proxy option allows you to direct packets to an intermediate system instead of directly to the peer endpoint. May be useful for testing certain firewall configurations. Proxy Addr This configures the proxy IP address. This may be used to re-direct LANforge traffic through a third-party proxy system. It is expected that the proxy will properly forward the connection to the other LANforge endpoint. For TCP traffic, the proxy only makes sense on the A endpoint. The Use-Proxy checkbox must be selected to enable these settings. Proxy Port This configures the proxy IP port. This should be used in conjunction with the Proxy Addr described above. Socket Priority You can use the 'Socket Priority' field to set a particular priority for the generated packets. When used in conjunction with the priority -> .1q priority mapping supported in the 802.1Q VLAN stack on Linux, you can have packets created with particular 802.1Q priorities. You can also use other Linux tools external to LANforge to modify behavior of the packets based on the priority. Socket Priority may influence ToS if the operating system is configured to do so, but it will not do so by default. Connection Timeout This determines how long LANforge will wait for a TCP connection to establish. This is independent of any TCP level settings, which are controlled by the operating system. TCP MSS By default, the OS will determine the TCP MSS based on the MTU for the network path between the two endpoints. The user may over-ride this value by setting it to a fixed size smaller than the MTU. This ensures that packets on the wire are no larger than the configured MSS plus protocol headers. Modern NICs can offload the TCP Segmentation allowing very rates with small TCP packets. This is a good way to do high packet-per-second testing with TCP protocol packets. Checksum This option will cause LANforge to perform a 32-bit CRC calculation for the payload. This gives a very high degree of packet corruption detection at each layer, but due to the extra work the CPU has to do, the maximum traffic rates may be smaller. Note that TCP/IP, and the Ethernet protocol itself already has CRC checks, so you may not need to enable LANforge checksumming to perform your testing successfully. Received bit-errors will be calculated in the LANforge payload portion starting 28 bytes into the UDP or TCP payload. In addition, the bit-errors are only checked when LANforge CRC is enabled and detected to be invalid. If the 28-byte header is corrupted, LANforge will not detect it, and may also give false positives for other packet errors. Bit-Errors are only calculated for certain payload patterns: Increasing, Decreasing, Zeros, Ones, and the PRBS patterns. Bit-error results will be displayed on the L3 Endps tab under the RX BER column for each endpoint. UnManaged This designates an endpoint as not controlled by LANforge. This can be used to fling UDP packets at some third-party application, for instance. It would be less useful for testing TCP in most cases. Duration Quiesce This will cause the connection to Quiesce (pause transmit and stop), after the first connection duration has completed. This allows the user to configure the connection to run for a fixed amount of time. Quiesce-After-Range This option will cause the connection to stop after it has completed a linear IP-Port range and/or a linear IP address range. TCP_NODELAY Selecting the 'TCP_NODELAY' checkbox will decrease latencies in many cases and aid generation of small TCP frames by disabling the connection's Nagle algorithm. Selecting 'TCP_NODELAY' will normally decrease performance at higher speeds. Concurrent IP Addrs When using multiple-connections, and when the associated Port has secondary IP addresses enabled, this option causes the multiple-connections to use multiple IP addresses concurrently. With this disabled, only one IP will be used at a time. Clear-Port-On-Start This option will cause the ports in use by the connection to have their counters cleared upon start of the Endpoint. This is most useful when only a single Endpoint is using a port at a time. Linear-IP-Ports This option will cause an IP Port range to be used in a linear manner. For instance, if you use min-ip-port of 5000 and max of 5005, the connections will be made from port 5000, 5001, .. 5005. If you do not select this option, and have an IP port range, a random port between min and max will be used for each connection attempt. Endp Name Endpoint names must be no more than 47 alpha-numeric characters and contain no spaces. LANforge automatically fills this in based on the CX name, so normally there is no need to change this field. Rcv Mcast This designates the endpoint as a multicast receiver as opposed to a sender. Batch-Create Cross-Connects A series of tests can be created based on the CX Name and other current settings in the Create/Modify Cross-Connect window by using the Batch-Create function. For best results, create a valid connection for the first in the series to be batch-created, select the connection and click Modify. Clicking the Batch-Create button at the bottom of the window will pop up the Layer-3 Batch Creator: After the desired settings have been entered, click Apply or OK to create the series (batch) of Layer-3 Cross-Connects. Quantity The number of Layer-3 connections to batch-create, using the selected Cross-Connect for the initial values. Number of Digits The number of characters (padding) to be used in appending each connection name. Adds leading zeros (zero-pads) to connection names as required (this may help with sorting connections). For best results, this number should match the format of the selected connection (Ex: 3 for an initial connection named LFtcp-001). Zero Padding Checkbox Uncheck the 'Zero Padding' checkbox if you do not desire leading zeros for the connection names when they are created. Starting Name Suffix The first number in the series (Ex: 001 for LFtcp-001) from which subsequent connections will be incremented. If the original connection name ends in a number or series of numbers, it will be displayed here. Name Increment Connection Names in the batch will be incremented by this amount. If set to 2, the next connections following cx-001 would be cx-003, cx-005, etc. Port Increment A/B Ports used for each connection will be incremented by this amount. If set to 2, then eth2 would be incremented to eth4, eth6, etc. IP-Port Increment IP-Ports used for each connection will be incremented by this amount if the IP-Port field is not set to AUTO. If set to 2, then IP-Port 1234 would be incremented to 1236, 1238, etc. Custom Payloads The Payload button allows for the configuration of custom payloads if a custom CX Type has been selected. A payload from a previous packet capture can be copied/pasted or one can be created by entering data into the various fields. For a Custom Ethernet Endpoint, clicking the Defaults button followed by Apply in each panel of the Configure Payload window will create a payload that looks something like this: var ratio = 1.0247058823529 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Apply button in each panel transfers the hex to the appropriate portion of the payload. The Apply All Protocols button at the bottom of the window can be used instead of the individual Apply buttons if desired. When finished, click Apply or OK to save the protocol to the selected endpoint. Protocol Builders LANforge supports several protocol builders. If a builder is not available for a protocol you wish to transmit, you can always paste a captured packet, or hand build one in HEX and transfer it to the text editor at the top of the Payload panel. You can also initialize most protocols to defaults, and the resulting values will correspond to live packets gathered from our network. The ethernet protocol is slightly different, see the notes below. Make sure you initialize from the lower layers up to the higher layers. Ethernet Header You can specify the Source, Destination and Protocol fields in the Ethernet Header. If you tell this protocol to initialize to defaults, it will grab the MAC addresses from the two ports it is connected to. This may or may not be what you want, so be ready to re-enter the fields accordingly. Selecting the 'Insert MPLS Label' checkbox adds another panel to the window to configure the payload for MPLS (Multiprotocol Label Switching). MPLS Header(s) You can specify one or more MPLS labels in this panel. Multiple MPLS labels can be added creating a "label stack" by selecting the 'Insert MPLS Label' checkbox in each new panel. For details, look up RFC 3031. IP Header You can specify the various IP header fields. For details, look up the venerable RFC 791. If you change a field, you will probably want to re-checksum both the IP header and higher protocols too (in that order). TCP Header You can specify the various TCP header fields. For details, look up the venerable RFC 793. If you change a field, you will probably want to re-checksum the header with the checksum button. Protocol builders for 802.1Q VLAN, ARP, IP-IP, IPX, LLC/SNAP, and MPLS labels have recently been added. Please let us know if there is a particular builder you would like to see implemented and more can be added in a future release. Cross Connect Display Individual Cross-Connects can be selected for display from the Layer-3 tab. Select a Cross-Connect and click the Display button to bring up a summary window for that cross-connect. The Cross Connect display is divided into three panels. The left and right panels describe information for endpoints A and B, respectively. The center panel describes the number of confirmed packets flowing and dropped from left-to-right and right-to-left, as indicated by the arrows. var ratio = 0.35159141376758 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Scripted Cross Connect As of release 5.1.2 and later, a Layer-3 Cross Connect can be scripted via the LANforge GUI so that the user can setup a single connection to run at different rates and payload sizes for various durations. Release 5.2.7 includes improvements that allows iterating through Attenuations too (provided the user has a LANforge Attenuator) and running scripts on Connection Groups. The Add/Modify Script window is divided into two panels. The top panel identifies the endpoint and defines the script type and scripting options. The bottom panel describes the script configuration. The 2544 script allows implementing part of the RFC 2544 script and is generally used to test throughput performance at various packet sizes, and tx rates. For WiFi testing, Attenuation steps may also be added. The user may specify constraints that mark each iteration as pass/fail based on how it performs against the constraints. var ratio = 0.72222222222222 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Endpoint Name The Endpoint that the script will control. Script Type There are three Script Types. The default values that appear for Script2544, HuntScript and ScriptWL can be modified to suit your testing needs. NONE - Deletes any existing script on the endpoint.
Script2544 - Defines a default set of rates, payload sizes and Attenuations for a Layer-3 or Armageddon endpoint. You may use the default rates and payload sizes which are described in RFC-2544, a methodology for benchmark testing, or you can modify the default rates and payload sizes by typing in the values you want to use in the script configuration text boxes.
ScriptWL - Defines a default set of rates, latencies, jitter and drops for a scripted WanLink.
Script Name The name of the script. At this time only one script can be associated with each endpoint and the name is basically ignored. Group Action LANforge 5.2.7 introduces the use of Connection Groups. This is a collection of cross-connects and other tests that can be controlled by a single Connection Group entity. For scripting, this allows some unique opportunities. If Group action is All then the script on a Connection Group will apply to all connection group entities at the same time. If the group action is Sequential then only one CX in that Connection Group will be started at a time, and the script will only affect that one CX at a time. Generic Script Options These checkboxes allow you to control various script options. Enable Script: Whether or not to enable the use of the script. A script configuration can be defined for an endpoint and then disabled so that the script configuration is preserved for future use when the script is enabled again.
Show Reports: During the running of a script, this option will allow per-iteration and summary results to be generated and displayed in a pop-up text display window.
Symmetric: Symmetric allows the script configuration to apply to both endpoints associated with a connection. This would be used for a bi-directional test. With this option, the script per-iteration and summary results will include both endpoints in a single report. NOTE: With 5.2.7, the scripts support 'B' side settings as well, so the values configured on each endpoint by the Symmetric script may not be identical.
Loop: Run the script to completion over and over until stopped by the user. When this is not selected, the test will stop after one full run of the script.
Hide Iteration Details: Hides only the per-iteration results in the script report. Summary results will still be displayed.
Hide Legend: Hides only the report legend that describes the column headings in the script report.
Hide CSV: Hides only the comma seperated value data in the script report.
Script Iterations Displays a running tally of the number of iterations your current script configuration contains. For Hunt Scripts, this is an upper bound since each hunt iteration may stop early if it detects it has properly met its precision constraints. Estimated Duration Displays an estimated total script running time that the current script configuration will take to complete. For Hunt Scripts, this is an upper bound since each hunt iteration may stop early if it detects it has properly met its precision constraints. Script Configuration The details of each iteration of the script. Not all of these settings apply to each script type. Hunt and 2544 Script Options These checkboxes allow you to control options for the 2544 and Hunt scripts. Show Dups: Whether or not to report Duplicate packet statistics in the script results.
Show OOO: Whether or not to report Out-of-Order packet statistics in the script results.
Show Attenuation: Whether or not to report RX-Signal and Attenuation statistics in the script results. This is only useful when Attenuation is being used (which requires LANforge Attenuator hardware.)
Hide Latency Distributions: Whether or not Latency Distributions should be included in the script results.
Hide Hunt Steps: Whether or not the individual Hunt-Step results should be included in the script results.
Hide Constraints: Whether or not the constraints messages should be included in the script results.
Run Duration The length of time that each iteration should run. Values can be chosen from the list or typed in with one of the following suffixes: ms - milliseconds, s - seconds, m - minutes, h - hours, d - days. Pause Duration The length of time between each iteration. Values can be chosen from the list or typed in with one of the following suffixes: ms - milliseconds, s - seconds, m - minutes, h - hours, d - days. Starting Rate For Hunt scripts, the rate at which to start hunting. Choosing a value close to the expected results may slightly speed up the Hunt script, but using the default value should be fine as well. Max Iterations For Hunt scripts, this is the maximum number of hunt steps for each script iteration. If this is set too small, the script may not have enough steps to zero in on the maximum rate with the desired precision. Max Drop Percent This determines the maximum allowed drop percentage for the iteration to be considered a success. Max-Tx-Underrun This determines the maximum allowed difference between requested TX Rate and actual TX Rate for the iteration to be considered a success. For instance, when transmitting on Wireless interfaces, the maximum speed that the system can actually transmit will be limitted by the WiFi connection rate at that time. Max Jitter This determines the maximum allowed average jitter for the iteration to be considered a success. Max RT Latency This determines the maximum allowed average round-trip time for the iteration to be considered a success. Max Failed OK For 2544 scripts: This determines the maximum number of iterations that can fail before the entire test is considered a failure. Rates A default set of rates is shown when the script type is selected, but you can also enter your own set of rates that each script iteration should step through. Rates can be entered using bps or pps units. Values should be seperated by a comma or newline. With LANforge release 5.2.7, ranges can be entered as well. The syntax is: start..oper..stop For example: 1M..+5M..100M would start at 1Mbps and increase by 5Mbps for each iteration step until it reached 100Mbps. Valid operators are: +, -, x, *, / Payload Sizes A default set of payload sizes is shown when the script type is selected, but you can also enter your own set of payload sizes that each script iteration should step through. Payload sizes can be entered with one of the following suffixes: B - Bytes, KB - Kilobytes, MB - Megabytes. Values should be separated by a comma or newline. Note: For Layer-3 TCP and UDP, payload size is the size in bytes of just the payload. For Layer-3 Ethernet or Armageddon, payload size corresponds to the actual Ethernet frame size. Ranges can be entered as well. The syntax is: start..oper..stop For example: 64..*2..9000 would start at 64 and double each iteration step until it reached 9000. Valid operators are: +, -, x, *, / Attenuations If you are using a LANforge Attenuator, you may have the 2544 and Hunt scripts iterate through attenuation settings. Attenuations may be entered as ddB (tenths of a dB). Values should be seperated by a comma or newline. Ranges can be entered as well. The syntax is: start..oper..stop For example: 0..+5..955 would start at 0 and increase by 5 for each iteration step until it reached 955. Valid operators are: +, -, x, *, / Show Previous Report Show the results of the last script run. Using 'ctrl-T' after selecting the CX in the main LANforge-GUI window will also pop up the last results. Sync Update the script configuration fields with the current script settings already in use. Apply Attempt to apply changes to the script configuration to the current endpoint, but do not close the window. OK Attempt to apply changes to the script configuration to the current endpoint and close the window. If the apply fails, your changes will be lost. Cancel Make no changes and close the window. The scripts create text output when they are running, and when finished, the GUI can create some 2D and 3D graphs for Hunt and 2544 scripts. The script results are plain text, so they can be saved for later viewing. As of LANforge 5.2.7, there is not a clean way to 'load' old results, but you can just delete any existing script results and paste in old ones from a text editor. Click the Graphical Display button on the Script Report window to see the graphs. The Grapical Display may be saved to an HTML report (after optional adjustment of the 2D and 3D graphs). Example Hunt Script Graphical results. var ratio = 0.625 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Layer-3 Endpoints (FIRE) Although the Layer-3 tab will be used to stop/start/modify your (non-IGMP) CXs, the fine details of each Cross-Connect are displayed on the L3 Endps tab. If you select a CX on the Layer-3 tab by single-clicking on its row, the Endpoints associated with that CX will be selected when switching to the L3 Endps tab. The L3 Endps tab displays Endpoints 0-400 by default. Endpoint numbering is 0-based where 0 represents the first Endpoint name. To display all Endpoints or a specified range of Endpoints, select 'all' from the View field drop-down menu or enter range values ([min]-[max]) in the View field, then click the Go button to display the new range of Endpoints. var ratio = 0.51894736842105 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width L3 Endps tab. For example, if you want several of your Endpoints running at 56000bps then you can select them, and use the 'MIN Tx Rate' combo-box to set the desired value. Additional bulk changes can be made to selected Endpoints by clicking the Batch Modify button. Selected values from the drop-down menus will be applied to all selected Endpoints. Endpoint values marked 'NA' will remain unchanged. For more specific modifications, select the Endpoint in question and click the Modify button. Endpoints can also be modified through their respective Cross-Connect on the Layer-3 tab. var ratio = 0.67741935483871 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Display button. The display of a sample Endpoint is shown here: var ratio = 0.75748031496063 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Creating & Modifying Multicast Endpoints LANforge supports the IGMP UDP Multicast protocol. Because there is a one-to-many relationship, these Endpoints are not handled by the standard cross-connect paradigm. Instead, you can create multiple Endpoints, specifying one generator and zero or more receivers for a particular IGMP address/port pair. To create an IGMP Endpoint, click the Create button on the L3 Endps tab. This will bring up the Create/Modify Endpoint window. To modify an existing IGMP Endpoint, select it and click the Modify button. var ratio = 0.30255057167986 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Endp Type The Endpoint Type should be 'Multicast.' Custom Multicast is not supported at this time (please enquire if you are interested in this feature.) Report Timer The Report Timer is how often (in millisecond units) the Endpoint reports to the GUI. 1000-5000 (1-5 seconds) is suggested for most cases. IGMP Address The IGMP Address is the 'IP' address of the multicast group. Multicast IP addresses must be in the range between 224.0.0.0 and 239.255.255.255, inclusive. The IGMP Address and Port specifies a particular multicast group. IGMP Dest Port The IGMP Destination Port is the UDP port that this Endpoint will transmit to, assuming it is a transmitter. If it is a receive-only Endpoint, then this field can be left blank ("IP Port" specifies the receiving port.) IP Port The IP Port is the port that the Endpoint listens to if it is a receiver. If it is a transmitter, then this field can be left at the default setting. TTL The Time-to-Live field determines how far the IGMP packet may travel. '1' restricts travel to the local subnet only. Larger numbers allow it to travel across routers. Be careful not to flood other networks by accident! Rcv Mcast If the 'Rcv Mcast' checkbox is selected, this Endpoint will be a receiver. If not, then it will be an IGMP multicast generator. You should have one generator per unique multicast IP address and port, and zero or more receivers. Candela Technologies, Inc., 2417 Main Street, Suite 201, P.O. Box 3285, Ferndale, WA 98248, USA www.candelatech.com sales@candelatech.com +1 360 380 1618
VoIP Call Generator (SIP, RTP, RTCP) LANforge can create Voice over IP (VoIP) calls between LANforge interfaces. You may also setup third-party phones to call LANforge or be called by LANforge. VoIP consists of several protocols. LANforge currently supports the SIP (Session Initiated Protocol) emssaging protocol. The voice payload is transmitted with the Real Time Protocol (RTP) which runs over UDP. The Real Time Control Protocol (RTCP) is used for latency and other accounting, and runs over UDP with the same priority as the RTP traffic. The VoIP/RTP tab displays connections 0-200 by default. Connection numbering is 0-based where 0 represents the first connection name. To display all connections or a specified range of connections, select 'all' from the View field drop-down menu or enter range values ([min]-[max]) in the View field, then click the Go button to display the new range of connections. var ratio = 0.47578947368421 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Creating & Modifying VoIP Cross-Connects When creating a VoIP Cross-Connect (CX), you specify the details of each Endpoint, including the Shelf, Resource, and Port that the Endpoint resides on. In this way, you determine upon which data-generating port (which is connected to some port on the system under test) the call's traffic will flow. In order to create a CX, click the Create button on the VoIP/RTP tab. This will bring up the Create/Modify VoIP Cross Connect window: var ratio = 0.60953177257525 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Apply or OK to create the Cross-Connect. NOTE: A series of tests based off the current configuration can be created by clicking the Batch-Create button. Cross Connect Information The top panel of the Create/Modify Cross Connect window contains information relating to the entire CX, including the name, CX Type, report timer, and the assigned test manager. The CX name must be unique in the LANforge system. Report Timer The report timer specifies how often the LANforge data generators send updates to the LANforge server, and how often the LANforge server pushes endpoint information up to the clients (GUIs) that have requested the automatic updates. If you are running the GUI over a slow link, or have a slower machine, it is recommended to increase the report timer to 5000ms (5 seconds) or higher. Test Manager The Test Manager specifies who 'owns' this CX, and can be used to segregate a large LANforge system for use by many engineers. For most users, however, assigning all CXs to the default_tm Test Manager is fine. CX Type The CX Type determines the protocol that the CX will use. LANforge currently only supports SIP. SIP makes a voice call using the SIP messaging protocol. If you are using 'Directed' mode, then the endpoints can call directly to each other without using a SIP proxy server. With the 'Use Gateway' option, a SIP server will be used to handle the call routing. LANforge has been tested with a wide variety of third-party SIP gateways, including Asterisk. Call Modes Two call modes are available: 'Continuous Call' makes a single call and plays the wave file in a loop until the call is stopped by the user. 'Multi-Call' mode allows you to select the number of times to loop the wave file, the number of calls to make, and the maximum time of the call. For PESQ, you should use the 'Multi-Call' option. Call Gateway Options Two Call Gateway options are available: 'Directed' means that the VoIP endpoints directly call themselves, without registering with or using a proxy or gateway. In this configuration most of the endpoint attributes can be 'AUTO' because LANforge can determine the settings automatically. In 'Use Gateway' mode the call endpoints will register with a gateway or proxy and make calls through it. To authenticate and register a VoIP endpoint with a call gateway/proxy use the following format to supply the password: [@][:] Call Duration Min/Max Call Duration determine the length of the call. If 'File' is selected then the call will be as long as it takes to play the chosen wave file. If Min is not equal to Max, a random value between the min and max will be chosen for each call made. For PESQ, select 'File' for the call duration. Max Ring Time Determines how long the calling endpoint will wait for the called party to pick up before deciding the call was a 'No Answer'. Codec Determines the codec for the RTP voice payload. Currently G729, G711u, G726-16, G726-24, G726-32, G726-40 and Speex codecs are supported. By default, the phones will advertise all supported Codecs, with a preference on the one selected here. If you want to only advertise the single selected codec, then also enable the 'Single Codec' checkbox in the Endpoint configuration sections. Start Delay Specifies the amount of time (in seconds) to wait before initiating a call after a test has been started. Number of Calls Specifies the number of calls to make before the endpoint stops itself. Select 'INFINITE' if you want to run until the user stops the call manually. Inter-Call Gap Min/Max Inter-Call Gap specifies how long to wait between calls. If min is not equal to max, a random value will be chosen between min and max for each call. Don't Send RTP By default, LANforge will generate the RTP payload for each call. This requires significant processing resources, so if you only care about the SIP messaging, you can select this checkbox to disable sending of RTP. VoIP Cross Connect Endpoints Each Endpoint can be configured independently of the other. The default is to have the 'A' endpoint call the 'B' endpoint. The 'B' endpoint can be un-managed, which means LANforge assumes that it is a third-party endpoint, such as a Cisco or Grandstream SIP phone. Name, Shelf, Resource, Port The Endpoint name, shelf, resource, and port information determines the Port (interface) this endpoint will use. Phone Number The Phone Number is the SIP identifier for the endpoint. If you are using a Gateway, then this number must be configured in the Gateway so that the endpoint can register. For directed calls, this can be 'AUTO' and LANforge will choose some random value and make it work. For SIP, if you put in a number, the SIP To/From headers will be number@IP:port. If you want LANforge to use a domain for the To/From headers, then you can enter something like: 1234@domain.com for the phone number. If you are using non-standard SIP ports, then you must specify the SIP port too: 1234@domain.com:50600 Display Name Allows configuration of the SIP Display Name attribute for caller ID. The default is AUTO which will display the phone number. Auth User Name Specify the user in this field if using an authenticating proxy and/or authenticating calls. The phone number will be used if 'AUTO' is selected. Reg Expire Allows you to set the registration expire timer. Flags & Options Several flags (checkboxes) are used to enable or disable certain features which affect the behavior of the selected endpoints. UnManaged tells LANforge that this particular Endpoint is not a LANforge endpoint. Use this when configuring LANforge to call third-party SIP phones, for example.
Don't Answer will make LANforge decline to 'pick up' the phone when called.
Rcv Call configures this endpoint to wait for calls to be made to it, but will not originate any calls.
Single Codec tells LANforge to only use the codec specified in the top panel of this window. With this function disabled, the specified codec will be preferred, but any supported codec will be advertised and accepted.
Bind SIP should be checked if the gateway is connected to the same (ethernet) interface as the VoIP endpoint. This is usually required for Directed calls. If you are using the management network for the gateway, then deselect this checkbox.
Record tells LANforge to record the received audio stream to the specified wav file. This must be selected if you want to enable PESQ reporting.
Enable PESQ activates LANforge VoIP PESQ automated voice quality reporting. You must purchase a separate PESQ license for your LANforge system in order to enable this feature. To configure the VoIP endpoint for PESQ, select the 'Enable PESQ' checkbox. You must also configure the PESQ server. The PESQ server is the LANforge machine on which you install the PESQ license. PESQ can run along side other LANforge processes, so everything can be installed on a single machine if desired. For optimal results, select the 'Multi-Call' call mode and 'File' for the call duration. You also have to enable the 'Record' feature so that the received audio is saved to the local file system for processing by PESQ.
Play to speaker tells the LANforge server to play received audio on its speaker, providing a sound system exists and is configured correctly. The default sound device for Linux is /dev/audio.
VAD (Voice Activity Detection) is supported by SIP and will suppress RTP packets if silence is detected more than the specified 'VAD Delay' in milliseconds.
Override SDP replaces the connection IP address in the SDP with the 'real' IP address of the SIP peer. This feature should normally be deselected, but it may help if the peer is running through a 'dumb' NAT.
UDP Port UDP Port specifies the port that RTP traffic will use. RTCP will use one port higher than that, so if you choose to configure these manually, be sure to leave space. You can also use 'AUTO', in which case LANforge will allocate ports accordingly. SIP Port SIP Port specifies the UDP port for the SIP messaging protocol. The default SIP port is 5060, so if you are trying to configure an un-managed endpoint that corresponds to a third-party SIP phone, using 5060 is a good choice. IP ToS You can specify the ToS/DSCP (aka QoS) bits in the IP header. This value will be set on RTP and SIP packets. Please refer to the IP ToS section in this user guide. Socket Priority If you are running VoIP over 802.1Q VLAN interfaces on the LANforge system, setting the socket priority can allow you to map the priority to the 802.1Q priority. Use the external 'vconfig' Linux tool to configure the mappings between a particular socket priority and the .1Q priority. VAD Delay How much consecutive silence before VAD is enabled. VAD Force Send Force a send of an RTP packet at least every X milliseconds. Helps keep connections from being timed out with some phones. Jitter Buffer Jitter buffer is used to smooth out network jitter inherent in RTP traffic. Specify the buffer size (number of 20ms packets). Tx File The Tx File is the WAV file to play. LANforge comes with two sample wav files: A male and female reading some standard phrases meant to fully exercise the english language sounds. You may also create your own. Wave files must use single-channel 8-bit encoding. The Linux tool, SoX, can be used to convert various formats to the correct encoding. Assuming you have a sound/music file called muzak.ogg, the command syntax is: sox muzak.ogg -U -c 1 -b -v 1.1 -r 8000 /tmp/muzak.wav resample -q1 # muzak.ogg == input file, can be almost any type of sound file. # -U == ulaw encoding # -c 1 == one channel # -b == 1-byte encoding (8-bit) # -v 1.1 == increase volume by 1.1/1.0 percent, optional # -r 8000 == 8000 samples per second. # /tmp/muzak.wav == output file, has to be a .wav extension. # resample -q1 == makes it sound better, evidently, I can't tell. Destination If the destination number/URL to be called is different from the peer endpoint's phone number, you may specify it in this field. Speaker If you have a properly configured sound card, you can play the received call to the speaker real-time. Only a single endpoint can play on a particular machine at the same time. Select the 'Play to Speaker' checkbox to enable this feature. This feature is only supported for SIP, and only on Linux. You can also save the received audio to a file and play it through normal audio programs on any operating system. Call Gateway For 'Use Gateway' calls, you will need to specify the SIP Proxy. The proxy or gateway should usually be located in the system/network under test. This is a potentially complex matter, so please contact Candela Technologies or your supplier if you have any questions. For authenticated SIP registration, append the password to the front of the IP address: [password@]IP[:port] Record File If you want a copy of the received wav file, or if you are using PESQ, enter the filename to which to save the received audio stream. This should be unique for all endpoints so that you do not corrupt other calls' files. PESQ Server To enable PESQ automated reporting, you must have a PESQ license and/or access to a machine running a licensed PESQ server. Enter the IP address of that machine and the port (default port is 3998) in this field. For multi-core PESQ machines, there can be up to 5 PESQ processes running (one per core). In this case, you can se the Port to be the number of processes to have LANforge randomize the port. For instance, on a 4-core machine, you could use: 172.0.0.1:4 to randomly use ports 3995-3998. This feature is available in release 5.2.9 and later. Quiesce Instead of stopping both VoIP Endpoints immediately, LANforge will gracefully stop the transmitting Endpoint and wait the selected number of seconds before stopping the receiving Endpoint so that all transactions may be completed. Batch-Create Cross-Connects A series of tests can be created based on the CX Name and other current settings in the Create/Modify Cross-Connect window by using the Batch-Create function. For best results, create a valid connection for the first in the series to be batch-created, select the connection and click Modify. Clicking the Batch-Create button at the bottom of the window will pop up the VoIP Batch Creator: var ratio = 1.0834752981261 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Apply or OK to create the series (batch) of VoIP Cross-Connects. Quantity The amount of VoIP connections to batch-create, using the selected Cross-Connect for the initial values. Number of Digits The number of characters (padding) to be used in appending each connection name. Adds leading zeros (zero-pads) to connection names as required (this may help with sorting connections). For best results, this number should match the format of the selected connection (Ex: 2 for an initial connection named call-01). Zero Padding Checkbox Uncheck the 'Zero Padding' checkbox if you do not desire leading zeros for the connection names when they are created. Starting Name Suffix The first number in the series (Ex: 01 for call-01) from which subsequent connections will be incremented. If the original connection name ends in a number or series of numbers, it will be displayed here. Name Increment Connection Names in the batch will be incremented by this amount. If set to 2, the next connections following cx-01 would be cx-03, cx-05, etc. Port Increment A/B Ports used for each connection will be incremented by this amount. If set to 2, then eth2 would be incremented to eth4, eth6, etc. Phone# Increment Phone numbers will be incremented by this amount if the Phone # field is not set to AUTO. UDP Port Increment UDP Ports will be incremented by this amount if the UDP Port field is not set to AUTO. SIP Port Increment SIP Ports will be incremented by this amount if the SIP Port field is not set to AUTO. Record File Increment The Record File will be incremented by this amount if the Record File field is not blank. Start Delay Increment Start Delay will be incremented by this amount. VoIP Call Display Panel Individual VoIP cross-connects can be selected for display from the VoIP/RTP tab. Select a cross-connect and click the Display button to bring up a summary window for that cross-connect. The VoIP Cross Connect display is divided into three panels. The left and right panels describe information for endpoints A and B, respectively. The center panel describes the number of confirmed packets flowing and dropped from left-to-right and right-to-left, as indicated by the arrows. var ratio = 0.45176695319962 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width VoIP Endpoints Although the VoIP/RTP tab will be used to stop/start/modify your VoIP/RTP Call CXs, the fine details of each Cross-Connect are displayed on the VoIP/RTP Endps tab. If you select a call on the VoIP/RTP tab by single-clicking on its row, the Endpoints associated with that CX will be selected when switching to the VoIP/RTP Endps tab. The VoIP/RTP Endps tab displays Endpoints 0-400 by default. Endpoint numbering is 0-based where 0 represents the first Endpoint name. To display all Endpoints or a specified range of Endpoints, select 'all' from the View field drop-down menu or enter range values ([min]-[max]) in the View field, then click the Go button to display the new range of Endpoints. var ratio = 0.47578947368421 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width VoIP/RTP Endps tab by selecting one or more endpoints and clicking the Batch Modify button. Selected values from the drop-down menus will be applied to all selected endpoints. Endpoint values marked 'NA' will remain unchanged. Endpoints can also be modified through their respective Cross-Connect on the VoIP/RTP tab. var ratio = 0.390625 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width NOTE: If you are running Armageddon on a flat (non-routed) network, then LANforge can figure out all the defaults for you. However, if you are running in a routed network, you will need to manually enter the MAC address of your router in the Destination MAC field of the Armageddon section 2 configuration panel. var ratio = 0.47578947368421 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Batch Modify button. Selected values from the drop-down menus will be applied to all selected endpoints. Endpoint values marked 'NA' will remain unchanged. var ratio = 0.27147766323024 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Creating & Modifying Armageddon Cross-Connects When creating an Armageddon CX, you specify the details of each Endpoint, including the Shelf, Resource, and Port that the Endpoint resides on. In this way, you determine which data-generating port (which is connected to some port on the system under test) the CX's traffic will flow over. In order to create an Armageddon CX, click the Create button on the Armageddon tab. This will bring up the Create/Modify Armageddon Endpoint window: var ratio = 0.72820037105751 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width CX Type The CX Type determines the protocol that the CX will use. The current supported types are: Armageddon UDP generates and receives UDP packets. Protocol header fields will default to sane values based on the ports you select, but you can specify or randomize most fields to customize the packets that you send. For generating traffic for a routed network, you may have to override the default destination MAC address with the one from your router. Currently, the payload will just be random bytes from un-initialized memory, except for a small header at the beginning of the UDP payload that LANforge uses to detect dropped and reordered packets.
Armageddon TCP will frame up TCP frames and send them at very high rates. This is NOT stateful TCP, so it acts a lot like UDP in that it will not back-off, and does not use any real TCP protocol features
Quiesce Instead of stopping both Armageddon endpoints immediately, LANforge will gracefully stop the transmitting Endpoint and wait the selected number of seconds before stopping the receiving Endpoint so all transactions may be completed. Relative-Timestamps Selecting the 'Relative-Timestamps' checkbox directs LANforge to use the CPU's 'TSC' cycle counter for the selected connection. This is more efficient on most platforms, but not all hardware has a stable TSC counter, so if you suspect latency timing issues, disable this option. Relative timestamps will never be used if the peer endpoint is on a different machine. Report Timer The report timer specifies how often the LANforge data generators send updates to the LANforge server, and how often the LANforge server pushes endpoint information up to the clients (GUIs) that have requested the automatic updates. If you are running the GUI over a slow link, or have a slower machine, it is recommended to increase the report timer to 5000ms (5 seconds) or higher. Test Manager The Test Manager specifies who 'owns' this CX, and can be used to segregate a large LANforge system for use by many engineers. For most users, however, assigning all CXs to the default_tm Test Manager is fine. Armageddon Cross Connect Endpoints The left and right form columns of each info panel are used to define endpoints A and B. They are labeled TX Endpoint and RX Endpoint and are respectively colored green and purple. Selecting different options may enable/disable certain fields. Endp Name The unique name for this endpoint. LANforge generates a default value based on the CX Name. Shelf The virtual 'shelf' for this endpoint. The default of 1 is the only correct answer in most configurations. Resource The LANforge machine that this endpoint should be associated with. Choose from the drop-down values. Port The real or virtual network interface this endpoint should be associated with. Choose from the drop-down values. Pps Tx The desired packets-per-second to transmit. If the hardware/network cannot actually run at this speed, it will run as fast as it is able. Min Pkt Size The minimum packet size. This includes all ethernet headers, but does NOT include the 4 byte CRC at the end of the ethernet frame. The reported bits-per-second and bytes received WILL take the 4 byte CRC into account. Est. Rate The estimated transmit rate in bits-per-second based on configured settings. Max Pkt Size The maximum packet size. This includes all ethernet headers, but does NOT include the 4 byte CRC at the end of the ethernet frame. If this value is larger than the Min Pkt Size, each new packet will have a random size between min and max, in a random distribution. Pkts to Send This specifies the number of packets to send before LANforge will automatically quiesce the connection. Set this value to zero (Infinite) to have the test run until stopped by the user. Multi-Pkt This setting determines the number of times the exact same packet will be transmitted before a new one is created. Setting this value to greater than one can increase performance of the LANforge machine, but it will decrease the chance of detecting out-of-order packets. This is not usually a problem. When using Armageddon on virtual interfaces, such as MAC-VLANs and 802.1Q VLANs, this value must be 0 due to internal driver limitations. Other drivers *may* have this limitation as well. Burst Enables 'xmit_more' bursting at the driver layer. This can provide significant throughput improvement with some modern network adapters. Src MAC The source MAC address in the generated packets. If DEFAULT is entered in this field, LANforge will use the MAC address of the configured port for this endpoint. Dest MAC The destination MAC address in the generated packets. If DEFAULT is entered in this field, LANforge will use the MAC address of the peer endpoint's configured port. Src MAC Cnt If greater than 1, the source MAC address will be incremented through the specified range. This allows the test to create packets from what appears to be many different ethernet NICs and can be good for stress-testing ethernet switches and other types of equipment that attempt to detect and optimize for network flows. Dst MAC Cnt If greater than 1, the destination MAC address will be incremented through the specified range. This allows the test to create packets to what appears to be many different ethernet NICs and can be good for stress-testing ethernet switches and other types of equipment that attempt to detect and optimize for network flows. Min Src IP The source IP address for the generated packets. If DEFAULT is entered in this field, LANforge will use the IP address of the configured port for this endpoint. Max Src IP The source IP address for generated packets. If this value is larger than the Min Src IP, then the generated packets will cycle through the IP address range creating traffic from each IP address. If DEFAULT is entered in this field, LANforge will use the IP address of the configured port for this endpoint. Min Src Port The source IP port for the generated packets. Max Src Port The source IP port for generated packets. If this value is larger than the Min Src Port, then the generated packets will cycle through the IP port range creating traffic from all IP ports. Min Dst IP The destination IP address for the generated packets. If DEFAULT is entered in this field, LANforge will use the IP address of the peer endpoint's configured port. Max Dst IP The destination IP address for generated packets. If this value is larger than the Min Dst IP, then the generated packets will cycle through the IP address range creating traffic to each IP address. If DEFAULT is entered in this field, LANforge will use the IP address of the peer endpoint's configured port. Min Dst Port The destination IP port for the generated packets. Max Dst Port The destination IP port for generated packets. If this value is larger than the Min Src Port, then the generated packets will cycle through the IP port range creating traffic to all IP ports. Thread-ID The kernel thread on which this endpoint should be running. Both endpoints currently default to thread '0'. If 'AUTO' is entered, the endpoint will use a native method to spread packet generation load across the available Armageddon threads. When the CPU is not the bottleneck (often on today's hardware), it is usually best to keep all endpoints on the same thread. Thresholds Set the min/max transfer and receive rates. If the connection throughput goes outside of the set range, an alert and/or event will be sent. This is useful for longer term throughput tests. Script Please see the Layer-3 script section. Scripts basically work the same for Armageddon as they do for Layer-3 CXs. Use Router MAC If specified, and if Destination MAC is 'DEFAULT', then LANforge will attempt to find and use the MAC of the default gateway for the interface (Port) associated with this endpoint for the destination MAC. This option should always be selected when using Armageddon to test a routed network. UnManaged This designates endpoint B as not controlled by LANforge. With this enabled, LANforge will not expect a response from the target. This setting can be used to fling UDP packets at some third-party application, for instance. It would be less useful for testing TCP in most cases. Slow Start Use slow-start logic. This ramps up the speed a bit slower when starting the endpoint and after a clear of its stats. With this disabled (the default value), the endpoint may over-shoot the desired bandwidth for a fraction of a second causing unexpected stress on the network under test. Checksum This option will cause LANforge to perform a 16-bit UDP checksum on send and receive. Note that TCP/IP already has CRC checks so the checksum option is unnecessary and disabled for Armageddon TCP connections. Clear-Port-On-Start This option will cause the ports in use by the connection to have their counters cleared upon start of the endpoint. This is most useful when only a single endpoint is using a port at a time. Candela Technologies, Inc., 2417 Main Street, Suite 201, P.O. Box 3285, Ferndale, WA 98248, USA www.candelatech.com sales@candelatech.com +1 360 380 1618 WanLinks (ICE) WanLinks support the LANforge WAN/Network emulation feature set called LANforge-ICE. In the default WanLink configuration, two interfaces act like a transparent layer-2 ethernet bridge. The WAN emulation is applied as traffic flows through this bridge. Each WanLink is composed of two WanLink Endpoints that represent one of the sides of the WAN/Network emulation. WanLinks can apply various characteristics to traffic flowing through them including maximum-bandwidth, latency, jitter, jitter-frequency, dropped-packets, duplicated-packets, reordered-packets, bit & byte errors, and more! If a network's values for probed latency, packet loss and others are captured using LANforge-ICEcap, the resulting XML file can be replayed using the LANforge-ICEcap Replay (WAN-Playback) feature. This will provide realistic WAN emulations based on real-world networks. Please note that LANforge-ICEcap can only probe round-trip latency with any significant accuracy, so other network configurations should be specified manually in most cases. Overview of WanLink Configuration A WanLink emulates a bridged Ethernet network with characteristics determined by the user. Packets are received in one Ethernet (or virtual) interface and are transmitted out the other interface. This means that when you add the LANforge machine to an existing network configuration, no routing changes are needed. When designing your network, you can think of a pair of WanLink ports as an ethernet switch or even just a pass-through cable! WanLinks can bridge 802.1Q VLAN, Ethernet and Redirect interfaces. LANforge-ICE supports multiple virtual routers per system when LANforge is running on Linux. On Windows, only bridge-mode is supported. Use the Netsmith tool described earlier in this guide to configure LANforge-ICE in the routed mode. LANforge-ICE works best using a minimum of three ethernet ports: two for each WanLink and the third to access the LANforge machine remotely for management purposes. To ensure that there is no interaction with the LANforge machine's protocol stacks, the IP address for each WanLink port is automatically removed. It is possible to run WanLinks on a machine with only two ports, but you will not have the option to manage LANforge remotely unless you cleverly configure some virtual interfaces. In this scenario, your machine will need to be configured for a loopback device to manage LANforge. See the LANforge Server Installation Documentation for how to configure a loopback device on your machine. NOTE: There are work-arounds for even this restriction if you use a more complex Netsmith setup with bridge devices. Contact support if you have such a need. var ratio = 0.54 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Batch Modify button. Selected values from the drop-down menus will be applied to all selected endpoints. Endpoint values marked 'NA' will remain unchanged. var ratio = 0.37592867756315 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width Creating & Modifying WanLinks When creating a WanLink, the details of each WanLink Endpoint must be specified, including the Port where the WanLink Endpoint resides. This determines which port the WanLink will use for receiving traffic. The peer endpoint's interface will be used for transmitting packets. In order to create a WanLink, click the Create button on the WanLinks tab. WanLinks can be attached to Ethernet, Redirect, and 802.1Q VLAN interfaces. WanLinks should NOT be directly attached to MAC-VLAN, 802.11a/b/g, or PPP interfaces at this time. var ratio = 0.59847328244275 ; var win_width = -120 + (window.innerWidth document.documentElement.clientWidth document.getElementsByTagName('body')[0].clientWidth 400); win_width = (win_width + button to expose new configuration sections. You may also use keystrokes control + and control - to expose and hide sections. Generally, more advanced or obscure features are found on the higher sections.
Vista Codec Package 5.2.9 Serial Key
2ff7e9595c
Comments