Simulations

Try us out!

Indeni offers the first proactive root cause analysis solution for network devices, designed to cut setup and administration time, lower costs, and ensure a stable, secure network. It is the first truly proactive system that:

  • Automatically identifies known devices.

  • Correctly identifies proper settings for known devices, cutting deployment time to five minutes or less.

  • Understands and analyzes thousands of parameters and compares settings in relation to each other.

  • Measures traffic throughput and flags approaching maximums.

  • Determines whether devices are partly or wholly functional or dead and, if non-functioning, identifies the cause and suggests remedial actions.

  • Flags the administrator when an error is seen, via alerts which can be forwarded by SNMP, email or pager.

  • Allows priority analysis of chosen critical parameters so that potentially severe problems can be flagged and dealt with first.

This demonstration guide provides detailed instructions for simulating issues and reviewing how indeni reacts to them.

These tests can be set-up on your F5 and triggered safely. However best practices doing this in a lab or 


Precompressed content types in Web Compression profiles

Simulating compression profiles with pre-compressed content-types. There is no need to waste CPU cycles compressing something that is already compressed.

1. Click on Local Traffic -> Profiles -> Services -> HTTP Compression -> "Create..."

2. Populate the form as the one below and then click Finished.

 Setting high compression in Web Compression profiles

Setting too high compression levels uses up a lot of CPU for very very little gain:

1. Click on Local Traffic -> Profiles -> Services -> HTTP Compression -> "Create..."

2. Populate the form as the one below and then click Finished.


Matchclass used in an iRule

This is bad because it's a deprecated command using way more cycles than the new class command.

1. Go to Local Traffic -> iRules -> "Create..."

2. Paste the following and click "Finished"

when HTTP_REQUEST {
 
    if{[class match "nothing" equals images]}{
 
        HTTP::respond 200 content "<html>class match</html>"
 
    }
}


Usage of Auto Map.

This will make the F5 automatically use its own IP addresses as source before sending the request to the server. It's a smart way of testing assymetric routing but could easily lead to port exhaustion in case of many clients.

1. Go to Local Traffic -> Virtual Servers and click on "Create..."

2. Enter a name, and a destination address and a port. Any unused address in the clients space will do, or something unlikely to be used like 1.1.1.1. Let the service port be anything, ie 80.

3. Locate Source Address Translation further down and change it from None to Auto Map.

4. Click "Finished"

"Action on service down should be reject". 
The default option for "Action On Service Down" is "None", which maintains connections to pool member even when the monitor fails, but does not create new connections. If using a good monitor that is able to determine the status of the member however, the better option in most cases is "Reject", which instead resets the existing connection and forces the client to establish a new one. This ensures that the client has an optimal chance of connecting to a functioning pool member.

1. Go to Local Traffic -> Pools and click on "Create..."
2. Give it a name and click on "Finished"

Self IP not locked down
There are self IPs configured on this device which are listening to open ports. This example will configure a self IP to listen to the management port of the web interface so make sure that the client takes part in choosing the self IP. The steps are harmless as long as they are done onto an IP that is on a secure network.

1. Go to Network -> Self IPs

2. Locate an internal IP address on a secure network.

3. Change Port Lockdown from "Allow None" to Custom

4. Choose TCP and port 443. Then click "Add", then Update