Devcentral relaunch || Really very confusing || Errors and Moved Stuff ..?!! || Complain
This is very sad that the community which is a very elegant healthy place that differ F5 from anyone else is not available when I needed that :( I know that change is the most truth and change is for all good , but I have complains . Dears , please make an action regarding moved or retired stuff messages as it's very annoying and a lot of help just evaporates ?! I hope you guys understand our concerns and have a plan. Thanks
Mattermost, F5 LTM, and Websockets
I recently worked with a team that wanted to use the F5 Local Traffic Manager (LTM) feature to load balance connections to their new deployment of the Mattermost open source messaging platform within their on-premises datacenter. This application uses both HTTPS and Websockets connections for real-time chat. We ran into a few configuration issues but eventually found the right combination of “nerd knobs” to allow successful ingress traffic. This post is to consolidate these details and hopefully save time to other F5 engineers attempting to do the same. Business Requirements Ingress (client-side) connections TLS 1.1 or higher Support Websockets Only allow customized Mattermost mobile (iOS and Android) applications, provisioned from within the organization and using a custom header, to connect from the public Internet. The same VIP for the mobile traffic should be used by internal desktop or web browsers, which will not include this custom header Virtual Server Configuration The virtual server configuration was fairly straight forward: Protocol Profile (Client) = a mobile optimized TCP profile Protocol Profile (Server) = a LAN optimized TCP profile SSL Profile (Client) = profile with the Option No TLSv1 enabled SSL Profile (Server) = standard serverssl profile or custom one WebSocket Profile = WebSocket (or a custom one with this as the parent) SNAT = custom pool, but AutoMap would work OneConnect = standard oneconnect profile (or a custom one with this as the parent) Default Persistence = cookie Fallback Persistence = source address Pool = Mattermost server pool iRule = custom Mattermost iRule Mattermost iRule To meet some of the business requirements a custom iRule was created to handle some of the conditions outlined. Comments in-line, but this checks to see if the connection was outside of the organization and if so verifies the presence of the custom HTTP header and value. This also checks to see if the connection was requested to upgrade to Websockets, and if it is, change the HTTP filter from full parsing to passthrough mode. when HTTP_REQUEST { if { !(IP:addr [IP::client_addr] equals 192.168.0.0/255.255.255.0]) } { Request from IP outside of organization, check for customer HTTP header if { [HTTP::header x-the-custom-http-header-name] contains "customvalue" } { Custom HTTP header and matching value found if { [string tolower [HTTP::header Upgrade]] contains "websocket" }{ Connection is requesting WebSockets, stop HTTP parsing HTTP::disable } } elseif { [HTTP::cookie exists MMAUTHENTOKEN] && [HTTP::cookie exists MMUSERID] } { Since WebSocket connections do not have HTTP Header, check to see if connection has already authenticated and allow the connection return } else { Connection fails conditions, reject it reject } } else { if { [string tolower [HTTP::header Upgrade]] contains "websocket" }{ Connection is requesting WebSockets, stop HTTP parsing HTTP::disable } } }
Lab Guide: How To Build Your Own F5 Lab Environment
Introduction There are numerous of reasons why you should set up your own lab environment. Perhaps you are new to F5 or you might be studying for one of their exams. You might even want to evaluate one of their products. Setting up a lab environment is not always straight forward and currently there aren’t that many guides out there that starts from scratch. That is why I have put together this guide in order to assist you with building your first lab environment. This lab will be installed on your local computer using free for non-commercial use applications. The download components are hosted on https://www.f5books.eu which is an organization I’m running together with Steven Iveson. If you run into any problems using this guide or you find any errors, please comment below or contact me at philip.jonsson@f5books.eu. Together we can keep this document updated. :) The Lab Architecture So, what are we building? It’s pretty simple yet covers all our needs. These are the computing components; A Linux client running Lubuntu, allowing the use of CLI and GUI based tools and software such as ping, PuTTY (SSH), Filezilla (FTP) and a web browser. A BIG-IP VE running version 13.1.1 A Linux server running the Tomcat Apache web server, configured with five virtual hosts, listening on different IP addresses and TCP ports. We’ll be using these networks; Management - used for configuring the BIG-IP. External - the client-side network connecting the Linux client and BIG-IP; this will be a private (internal) network. Internal - the server-side network connecting the BIG-IP and Linux server; this will be another private (internal) network Client NAT – In order to gain Internet access on the client, we have assigned an interface that operates in NAT mode. Using that interface, we can download additional applications and also assist when we license our BIG-IP through the manual method. Here’s a diagram to help you visualize the end state: The full guide is located at the following download mirrors: Google Drive Dropbox Microsoft OneDrive I hope you find this guide helpful! :)TCP 3-WAY Handshake vs TCP Half-Open
1. TCP 3-Way handshake – TCP is a connection-oriented protocol, a connection needs to be established before two devices can communicate. TCP uses a process called three-way handshake to negotiate the sequence and acknowledgment fields and start the session. Here is a graphical representation of the process. The three way handshake process consists of three steps: a. Host A initiates the connection by sending the TCP SYN packet to the destination host. The packet contains the random sequence number (e.g. 5432) which marks the beginning of the sequence numbers for data that the Host A will transmit. b. The Server receives the packet and responds with its own sequence number. The response also includes the acknowledgment number, which is Host A’s sequence number incremented by 1 (in our case, that would be 5433). a. Host A acknowledges the response of the Server by sending the acknowledgment number, which is the Server’s sequence number incremented by 1. Post TCP 3 way handshake, the data transfer starts. After the data transmission process is finished, the connection will get terminated by sending FIN (FINISHED) flag which does graceful termination of connection. TCP Half Open connection – TCP connections are called Half Open connections when the third step of the 3-Way handshake sending final ACK to the server fails (as shown in below figure) or if one of the hosts closes the connection without acknowledging the other. Half Open connection process is given below – 1. Host initializes the request by sending SYN packet. 2. Server replies to the client with SYN_ACK, and at this point server reserves some resource for the client and waits for the final ACK to arrive (Acknowledgment message). 3. However, the client does not respond to the server with final Acknowledgment. So an established connection is said to be "half-open" if one of the TCPs has closed or aborted the connection at its end without the knowledge of the other, or if the two ends of the connection have become desynchronized owing to a crash that resulted in loss of memory. Such connections will automatically become reset if an attempt is made to send data in either direction. However, half-open connections are expected to be unusual. F5 TCP-Half Open monitor – F5 also have TCP-Half Open monitor available under Local trafficàMonitors. Tcp_half_open monitor is most widely used for gateway monitoring when you just need to ensure the socket is responding to connection requests and desire the lowest overhead on the monitoring target. The tcp_half_open monitor sends a SYN packet to the pool member, and if a SYN-ACK is received from the server in response, the pool member is marked UP. There are few use cases to use TCP-half open monitor as given below – For example, a webserver would be less impacted by a half open connection request that is immediately reset than a connection that completes the entire open and close handshake sequence. Another common use for the tcp_half_open monitor is to prevent the application from spewing a bunch of log messages indicating connections were opened but not used. It should be noted that some applications cannot gracefully handle the half open connection and subsequent reset, so some testing should be done in order before implementing this monitor. There is option available to test same under ‘Test’ tab shown in above image. Under Test tab, you can put webserver IP alongwith its associated port. And it will show Test results and it can be confirmed if application supports TCP-Half open or not. Do test same in your environment and share your observations. I hope, this article helps you. Your inputs, suggestions or questions are always welcome. Mayur
need help to download web servers OVA files.
Hello everyone, I am following the Keith Barker CBT nuggets video to create a lab in my local machine. Can someone help me to download web servers (red, blue, green) OVA files ? or can some one share the link where i can download these files ? Thanks RejanishRabbitMQ monitor.
We are trying to configure RabbitMQ health monitors to determine which node is primary and send all traffic to it, and failover if the primary goes down. Configuration is 2 nodes in two different Azure regions (total 4) with web services and RabbitMW running on all 4. Any thoughts? Frank
