f5 - yar145/mytestrepo1 GitHub Wiki

F5 DDoS Protection: Recommended Practices

BIG-IP AFM: Security for Data Center DDoS Protection

AFM DoS Protection

Configure a DoS/DDoS protection profile

SIP

Manual Chapter : Using SIP Profiles

Configuring SIP Load Balancing

BIG-IP® Service Provider: SIP Administration

WebSocket

WebSocket

Browser-based WebSocket connection

<title>Web Socket Client Example</title> <script type="text/javascript"> window.onload = function () { var conn; var log = document.getElementById("log"); var msg = document.getElementById("msg");
        function appendLog(item) {
            var doScroll = log.scrollTop === log.scrollHeight - log.clientHeight;
            log.appendChild(item);
            if (doScroll) {
                log.scrollTop = log.scrollHeight - log.clientHeight;
            }
        }

        document.getElementById("connect").onclick = function () {
            var server = document.getElementById("wsURL");
            conn = new WebSocket(server.value);
            if (window["WebSocket"]) {
                if (conn) {
                    conn.onopen = function (evt) {
                        document.getElementById("disconnect").disabled = false
                        document.getElementById("sendMsg").disabled = false
                        document.getElementById("connect").disabled = true
                        document.getElementById("status").innerHTML = "Connection opened"
                    }
                    conn.onclose = function (evt) {
                        document.getElementById("status").innerHTML = "Connection closed"
                        document.getElementById("connect").disabled = false
                    };
                    conn.onmessage = function (evt) {
                        var messages = evt.data.split('\n');
                        for (var i = 0; i < messages.length; i++) {
                            var item = document.createElement("pre");
                            item.innerText = messages[i];
                            appendLog(item);
                        }
                    }
                }
            } else {
                var item = document.createElement("pre");
                item.innerHTML = "<b>Your browser does not support WebSockets.</b>";
                appendLog(item);
            }
        };

        document.getElementById("disconnect").onclick = function () {
            conn.close()
            document.getElementById("sendMsg").disabled = true
            document.getElementById("connect").disabled = false
            document.getElementById("disconnect").disabled = true
            document.getElementById("status").innerHTML = "Connection closed"
        };

        document.getElementById("form").onsubmit = function () {
            if (!conn) {
                return false;
            }
            if (!msg.value) {
                return false;
            }
            conn.send(msg.value);
            var item = document.createElement("pre");
            item.classList.add("subscribeMsg");
            item.innerHTML = msg.value;
            appendLog(item);
            return false;
        };
    };

</script>
<style type="text/css">
    html {
        overflow: hidden;
    }

    body {
        overflow: hidden;
        padding: 0;
        margin: 0;
        width: 100%;
        height: 100%;
        background: gray;
    }

    #log {
        background: white;
        margin: 0;
        padding: 0.5em 0.5em 0.5em 0.5em;
        top: 1.5em;
        left: 0.5em;
        right: 0.5em;
        bottom: 3em;
        overflow: auto;
        position: absolute;
        height: 530px;
    }

    #form {
        padding: 0 0.5em 0 0.5em;
        margin: 0;
        position: absolute;
        bottom: 3em;
        top: 5em;
        left: 8px;
        width: 100%;
        overflow: hidden;
    }

    #serverLocation {
        padding-top: 0.3em;
    }

    #requestSection {
        height: 38px;
    }

    #responseMsgSection {
        height: 570px;
        position: relative;
    }
</style>
Server Location
Request Response

Securing Applications That Use WebSocket Overview: Securing applications that use WebSocket connections

K14754: BIG-IP support for the WebSocket protocol (9.x - 14.x)

Archived - K14814: The BIG-IP system may drop WebSocket traffic

K000132320: Overview of the Websocket profile

websocketd is the WebSocket daemon

Routing traffic by URI using iRule

when HTTP_REQUEST { if { [string tolower [HTTP::path]] starts_with "/path/" } { persist none set pm [lsearch -inline [active_members -list ] x.x.x.x*] catch { pool member [lindex $pm 0] [lindex $pm 1] } } }

Dynamic FQDN Node DNS Resolution based on URI with Route Domains and Caching iRule

High CPU utilization

K52991500: datasyncd consuming a lot of CPU after upgrade

K12201682: Datasync Obfuscator Process Runs Daily Causing High CPU Usage

high cpu usage independent from Traffic

HA

High Availability Fail-safe

Intro to: BIG-IP HA - Do it the Proper Way

MAC masquerade BIG-IP's default failover mechanism is based on gratuitous ARP. BIG-IP has to send a gratuitous ARP for every floating IP and service IP address like virtual server IP address and SNAT address. The gratuitous ARP contains the physical MAC address of the new primary BIG-IP. With gratuitous ARP, the device that takes over sends gratuitous ARP packets, which asks all hosts on the LAN segment to update their ARP table. After the hosts updated their ARP table with the MAC address of the new primary BIG-IP, they send all traffic to the active BIG-IP.

Sometimes hosts like Firewalls or routers do not update their ARP table when they receive a gratuitous ARP. In this case the firewall or router will keep sending traffic to the old MAC address, which leads to service intererruption.

This issue can be addressed with MAC masquerade.

With MAC masquerade configured, BIG-IP devices will use the MAC masquerade address as source MAC for packets leaving BIG-IP. In case of a failover, the MAC address will not change. The new primary BIG-IP will start using the MAC masquerade MAC address. Now there is no need to update the hosts ARP table.

The MAC address used for MAC masquerade is free configurable. A best practices guide how to choose the MAC masquerade MAC address is described in K-Article K3523. https://support.f5.com/csp/article/K3523

For more information on MAC masquerade see K-Article K13502 https://support.f5.com/csp/article/K13502

Architectures that are recomended for MAC masquerade: Traditional Datacenter deployments with BIG-IP applicances, Viprion or Velos Chassis

Architectures that are NOT recommended for MAC masquerade: BIG-IP Virtual Edition deployments on VMWare ESXi.

Per default ESXi does not support multiple MAC addresses on a single NIC. To enable MAC masquerade the ESXi port group has to have promiscuous mode enabled. Check VMWare documentation on promiscuous mode.

Architectures that do not support MAC masquerade: BIG-IP VE deployments in public cloud providers like AWS, Azure and GCP

K3523: Choosing a unique MAC address for MAC masquerade

Locally administered MAC addresses are assigned to a network interface by a network administrator, overriding the burned-in address. Locally administered addresses are distinguished by the value of the locally administered bit, which is the second-to-last bit of the first byte of the address. If the value of this bit is 1, the address is locally administered. Using the MAC address 02-XX-XX-XX-XX-01 as an example, the first byte is 02h. The bits making up that byte are 00000010. Since the second-to-last bit has a value of 1, the address is a locally administered address.

F5 recommends that you construct MAC masquerade addresses by following the IEEE locally administered addressing scheme and flipping the locally administered bit in the existing burned-in MAC address.

You can convert the pre-assigned MAC address to a locally administered MAC address by performing the following procedure:

determine the base MAC address for the BIG-IP system by entering following command: tmsh show sys hardware | grep -i "base mac" Change the second-to-last bit from 0 to 1.

00:01:D7:01:02:03 -> 02:01:D7:01:02:03

K14515: The Force to Standby feature should not be used when the HA group feature is enabled

⚠️ **GitHub.com Fallback** ⚠️