Skip to content
View in the app

A better way to browse. Learn more.
hosang I.T.

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

guru

Administrators

  • Joined

  • Last visited

View Profile Find content

Blog Entries posted by guru

  1. K8 Strong the Journey

    Prayer · guru · 02/05/2020 06:12 AM

    This journey I try and capture as much as I can as my wife battles cancer in hopes to help someone else that might be fighting cancer as well will have an idea of what to face which include the good and the bad.
    I'm writing this from the ER waiting room at the McLaren hospital in Flint, Michigan but let me explain how we got here.
    My wife, Kate (aka K8), has been feeling sluggish (no energy) and she has been loosing lots of weight without even trying.  Lack of wanting to eat which are all signs she needs to see a doctor so she went to her primary care doctor, Dr Winston on Dec 9th which diagnosed Kate as having a cold and she just needs to fight through it with vitamins and rest.
    Kate continued to have the same symptoms so in January we went to Urgent Care thinking her doctor just doesn't know since she didn't take any blood or do any testing.  Urgent Care checked Kate over and gave her a vitamin B complex shot which made Kate feel a bit better since she had some energy but that faded after a week and she was back to the way she was previously.
    We had a parent from our sons FIRST Robotics team that mentioned she could have Lyme Disease which when looking it up, appeared to possibly be the answer.  We were just in Tennessee and she did lead the way down a trail outside our cabin which had spider webs (could of a wolf spider fell down and bite her giving her this Lyme Disease or a tick?) 
    Kate was having a difficult time standing, having to sit down because she was getting very nauseous and light headed.  Horrible migraines which her Primary Care physician prescribed medicine for that which you supposedly have to take as soon as you feel you have a migraine coming on but it usually made her super sleepy.  Loss of appetite where she didn’t want to eat anything but Tropical Smoothies for some nutrition.  I went to a natural health store and got her some Ginger Shots and some essential oils to help her fight a possible Lyme disease naturally (if it’s even that).  Forced her to take vitamins…. Based on one of my friends (rob) recommendation, I bought some Bovin Colustrum and encouraged her to take that since Indians used it to cure many illnesses and in hopes to beat this as well as several other “remedies” but nothing was helping.
    Kate was going to make another appointment with her primary care doctor but her supervisor at work suggested Kate go see her primary care doctor, Bridgett Dyson, since everyone at Kate's place of work could clearly see something was wrong with her health wise.  They described Kate's skin tone as almost a gray color and everyone was concerned, even the stuck up bitches that caused her so much stress.  So Kate figured why not since she wasn't making any headway with her primary care doctor and urgent care.
    I told her, if this new doctor says "it’s a cold" we are going to the Emergency Room because I know in my gut it's not a dang cold.
    Yesterday Kate went to her appointment with Bridgett Dyson and first site Bridgett had immediate concerns as she confirmed that Kate did not look healthy and immediately ordered three pages worth of blood testing and told Kate if its urgent she will call her that night, otherwise will get with her on Thursday.  
    Well guess what, we went to bed around 10:15pm and we got a call which appeared to be spam call (no-caller id) but what spam caller leaves a message?  Kate listened to the message and it was Bridgett saying she is calling right back and please answer.  So Kate answered the second time and Bridgett said, very calmly, that Kate's blood came back with some concerns and that she (the doc) strongly recommends Kate go to the Emergency Room right away (which I overheard since we were both in bed) so before she even got off the phone I’m getting dressed.  I rush her to the ER at McLaren in Flint and of course begin the waiting period which is why I was able to write this.
    I'll post more as I get it....

  2. AWAF Policies

    · guru · 08/31/2023 03:56 PM

    Trying to migrate an LTM from old school to doing to via JSON and this particular LTM has AWAF Resource Provisioned so its what makes it difficult AND we are running version 15.x which only supports exporting policies into XML.  In newer versions (16.x and 17.x) the AWAF policies can be exported into JSON format.
    We exported the policies and imported them and now when you go to a child policy and you want to update it, the settings are grayed out like shown here

    But it use to look like this here where you can Add and do changes.

     
    It took a minute to understand what's happening but I eventually discovered that inheritance is taking place so you could make the changes at the parent policy but it would affect all child policies.  If you want to edit just certain child policies then you will need to go to Inheritence Settings on the child policy and click Decline and you will see that button change from Decline to Declined.  Below is a picture of what it looks like..  (in red is declining inheritance and in gray it is keeping the inheritance)

  3. This is extremely useful troubleshooting external URLs going through proxy / eGTMs / iGTMs and all other sort of combinations.
    What i really like about it is it really gives good data for different touch points.
    1.time_namelookup
    2.time_connect
    3.time_appconnect
    4.time_pretransfer
    5.time_redirect
    6.time_starttransfer
    It helped me handling extrenal 3rd party URLs and their response times, handshake failures.
    *****************************************************************************************************************************************************
    $ cat curl-format.txt
    time_namelookup: %{time_namelookup}\n
    time_connect: %{time_connect}\n
    time_appconnect: %{time_appconnect}\n
    time_pretransfer: %{time_pretransfer}\n
    time_redirect: %{time_redirect}\n
    time_starttransfer: %{time_starttransfer}\n
    ----------\n
    time_total: %{time_total}\n
    $ curl -p 10.43.196.140:80 -w "@curl-format.txt" -o /dev/null -k https://na60.mywiseguys/services/Soap/class/AllySFBridgeIntegrationService?wsdl
    % Total % Received % Xferd Average Speed Time Time Time Current
    Dload Upload Total Spent Left Speed
    100 677 100 677 0 0 41924 0 --:--:-- --:--:-- --:--:-- 42312
    time_namelookup: 0.000
    time_connect: 0.007
    time_appconnect: 0.000
    time_pretransfer: 0.008
    time_redirect: 0.000
    time_starttransfer: 0.016
    ----------
    time_total: 0.016

    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
    <title>Error 405 Only POST allowed</title>
    </head>
    <body><h2>HTTP ERROR 405</h2>
    <p>Problem accessing /services/Soap/class/EventGuyZSFBridgeIntegrationService. Reason:
    <pre> Only POST allowed</pre></p><hr /><br/>
    <!-- Body events -->
    <script type="text/javascript">function bodyOnLoad(){if(window.PreferenceBits){window.PreferenceBits.prototype.csrfToken="null";};}function bodyOnBeforeUnload(){}function bodyOnFocus(){}function bodyOnUnload(){}</script>
    </body>
    </html>

    <!--
    ...................................................................................................
    ...................................................................................................
    ...................................................................................................
    ...................................................................................................
    -->time_namelookup: 0.012
    time_connect: 0.013
    time_appconnect: 0.251
    time_pretransfer: 0.251
    time_redirect: 0.000
    time_starttransfer: 0.507
    ----------
    time_total: 0.507
    *****************************************************************************************************************************************************
    Here is what each value represents, according to curl’s manual page:
    lookup: The time, in seconds, it took from the start until the name resolving was completed. connect: The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed. appconnect: The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed. (Added in 7.19.0) pretransfer: The time, in seconds, it took from the start until the file transfer was just about to begin. This includes all pre-transfer commands and negotiations that are specific to the particular protocol(s) involved. redirect: The time, in seconds, it took for all redirection steps include name lookup, connect, pretransfer and transfer before the final transaction was started. time_redirect shows the complete execution time for multiple redirections. (Added in 7.12.3) starttransfer: The time, in seconds, it took from the start until the first byte was just about to be transferred. This includes time_pretransfer and also the time the server needed to calculate the result. total: The total time, in seconds, that the full operation lasted. The time will be displayed with millisecond resolution. Note:- Proxy details are below, replace proxies as & when requested in the curl command.
    User Proxies (from branches) 
    DFW: 10.43.196.141,142,143,144,148,149
    SAT: 10.47.196.141,142,143,144,148
    System Proxies (from data center, system to system) 
    DFW: 10.43.196.139, 140
    SAT: 10.47.196.139, 140
    NOTE: You must create the curl-format.txt file where it is that you are going to run the command.  The contents need to be
    time_namelookup: %{time_namelookup}\n time_connect: %{time_connect}\n time_appconnect: %{time_appconnect}\n time_pretransfer: %{time_pretransfer}\n time_redirect: %{time_redirect}\n time_starttransfer: %{time_starttransfer}\n ----------\n time_total: %{time_total}\n SYNTAX of the command is
    curl -p <enter proxy IP:port> -w "@curlformat.txt" -o /dev/null -k <enter URL>  
    BELOW you will find some examples of running the command
    Here is another example:
    Here is a FAILED request
    linux001:~ iSupportU$ curl -p 10.43.196.140:80 -w "@curl-format.txt" -o /dev/null -k https://na60.mywiseguys.com/services/Soap/class/EventGuyZSFBridgeIntegrationService?wsdl % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 799 100 799 0 0 9384 0 --:--:-- --:--:-- --:--:-- 9400 time_namelookup: 0.005050 time_connect: 0.043789 time_appconnect: 0.000000 time_pretransfer: 0.043842 time_redirect: 0.000000 time_starttransfer: 0.085053 ---------- time_total: 0.085140 time_namelookup: 0.066539 time_connect: 0.000000 time_appconnect: 0.000000 time_pretransfer: 0.000000 time_redirect: 0.000000 time_starttransfer: 0.000000 ---------- time_total: 225.609011 curl: (7) Failed to connect to na60.mywiseguys.com port 443: Operation timed out  
    Here is a SUCCESSFUL request (reason this is being truncated is because the entire page is displayed in html text format and its just too much to copy and paste)
    linux001:~ iSupportU$ curl -p 10.43.196.140:80 -w "@curl-format.txt" -o /dev/null -k https://confluence.int.eventguyz.com % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 799 100 799 0 0 9385 0 --:--:-- --:--:-- --:--:-- 9400 time_namelookup: 0.005206 time_connect: 0.044339 time_appconnect: 0.000000 time_pretransfer: 0.044383 time_redirect: 0.000000 time_starttransfer: 0.085003 ---------- time_total: 0.085130 <!DOCTYPE html> <html> <head> <title>Dashboard - EventGuyZ Confluence Powered Wiki</title> <------- tons of stuff that I'm removing and skipping to the end ------→ <script type="text/javascript"> AJS.BigPipe = AJS.BigPipe || {}; AJS.BigPipe.metrics = AJS.BigPipe.metrics || {}; AJS.BigPipe.metrics.pageEnd = typeof window.performance !== "undefined" && typeof window.performance.now === "function" ? Math.ceil(window.performance.now()) : 0; AJS.BigPipe.metrics.isBigPipeEnabled = 'false' === 'true'; </script> </body> </html> time_namelookup: 0.004505 time_connect: 0.040007 time_appconnect: 0.184635 time_pretransfer: 0.184683 time_redirect: 0.000000 time_starttransfer: 0.256104 ---------- time_total: 0.272074 With an example of both you can now do comparisons and see the difference of a successful and failed connection attempt

  4. Using BIG-IQ to troubleshoot

    · guru · 03/08/2022 02:15 PM

    If you have BIG-IQ in your environment to help manage/monitor your applications then let me help understand how to use some cool features of BIG-IQ.
    Many times you have several F5's in your environment and trying to identify what F5 has the application you need to troubleshoot is kind of a pain in the butt unless you have BIG-IQ.
    First thing I do is if someone says they have an issue with their application is I ask for the FQDN or the URL that is having issues.
    Next thing I do is go to BIG-IQ and click on the Configuration Tab then click on Virtual Servers and you get a screen like the one below

    You can enter the fqdn in the filter box on the right and if that doesn't work because the name of the virtual server may differ, go to your command prompt and do a dig on the FQDN to get the IP Address and come back to BIG-IQ and enter the IP Address in the Filter box on the right.
    What if you get nothing still?
    Then a few things could be happening
    Maybe there application doesn't go through the F5 BIG-IQ is only up to date if the application was deployed via JSON/AS3 and for those legacy apps that didn't use JSON/AS3 to deploy, under the Devices Tab you must click those legacy boxes and click import on the services to keep the BIG-IQ database up to date.

  5. Splunk Request Logging

    · guru · 03/12/2020 04:00 AM

    Assumptions:
    Log volume will be huge and will only turn for critical applications that too in production. This can be tested in Dev/Pre-prod prior moving to the production but need to be turned off immediately.This will not cause performance issues because of High-speed logging HSL feature.
    This logging feature can also be turned on for troubleshooting purposes if required.
    Dependencies:
    Enterprise splunk team should provision dedicated storage for the new applications with F5 logging feature turned on a permanent basis.
    Estimation:
    If we turn on logging for all applications in production, current rough estimate would be 1TB logs per day.
    Introduction:
    Request logging feature is inline F5 feature that replace the functionality of the splunk logging irule. This request logging feature provide metrics such as client-ip, elapsed time, request type & details, response code, pool member etc.These logs integrated to splunk will provide lot of details about a particular application behind  a single vip.
    Alerts, dashboard and reports can also be generated based of the metrics available per application basis.
    These logs will provide lot of help in troubleshooting and understanding more about the application for sustain teams.
    Sample Log:
    Description of log fields:-
    Time stamp of the log in splunk
    3/4/2019 15:57
    Device ip sending log
    10.47.194.101
    descriptive field for splunk queries
    Splunk Logging
    Device_hostname
    txsat1slbdv03.thezah.corp
    Requesttime_milli-sec
    1551736658724
    Requesttime_micro-sec
    1551736658724868
    Client_ip
    10.7.156.86
    Client_port
    63710
    vip_name
    /Development/vs.dev.103867.aap-api-cit2.thezah.corp
    vip_ip
    10.47.37.242
    vip_port
    443
    pool_name
    /Development/pool.dev.103867.aap-api-cit2.thezah.corp"
    snat_ip
    10.47.34.35
    snat_ip_port
    46235
    poolmember_ip
    10.47.49.66
    poolmember_port
    12000
    http_method
    GET
    http_uri
    /sa-health/f5chk.html
    http_version
    HTTP/1.1
    referrer
    "  "
    user-agent
    Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36
    http_statuscode
    304
    Responsetime_milli-sec
    2
    response_size
    0
    Responsetime_micro-sec
    2056
     
     
    Procedure:-
    Navigate to the following.
    Local Traffic -> Profiles -> Other -> Request Logging -> Create as per below fields.

    Template contents from image:
    "Splunk Logging"|"$BIGIP_HOSTNAME"|"$TIME_MSECS"|"$TIME_USECS"|"$CLIENT_IP"|"$CLIENT_PORT"|"$VIRTUAL_NAME"|"$VIRTUAL_IP"|"$VIRTUAL_PORT"|"$VIRTUAL_POOL_NAME"|"$SNAT_IP"|"$SNAT_PORT"|"$SERVER_IP"|"$SERVER_PORT"|"$HTTP_METHOD"|"$HTTP_URI"|"$HTTP_VERSION"|"$Referer"|"${User-agent}"|"$HTTP_STATCODE"|"$RESPONSE_MSECS"|$RESPONSE_SIZE|"$RESPONSE_USECS" Once logfile is created, apply to virtual server that need this logging feature turned on as per below command.
    #tmsh modify ltm virtual /Development/vs.dev.103867.aap-api-cit2.thezah.corp profiles add { logprofile } Note:- turning logprofile on would not cause any performance issues because of HSL logging feature used, it will only need additional storage assigned from splunk team to get the logs indexed in splunk.
     
    Verification:-
    Check logs in F5 index ( index=infra_network )  to make sure transaction logs coming in.
    index=infra_network “Splunk Logging” “aap-api-cit2.thezah.corp” latest=+15m  

  6. Unable to Redirect using Policy

    · guru · 04/20/2022 12:55 PM

    Ran into an issue last night where I had to redirect
    https://example.thezah.com/
    to
    https://example.thezah.com/?idp_id=two
     
    Attempted a few different way of redirecting the URI in the Policy and they all didn't work.  Ran into a few issues...
    When creating the Redirect_URI policy under the do the following: Replace - HTTP URI - path with value /?idp_id=two at request time
    What would happen is when you enter the value /?idp_id=two and save F5 would change it to /\?idp_id=two and my assumption is its using reg-ex to escape the ? so I used the URL encode for question mark which is %3F so it looked like /%3Fidp_id=two and still no luck.
    Then realized they were breaking because to use policies you need an HTTP Profile (Client) of http.
    Then we added an SSL Profile (Client) with the FQDN in for example.thezah.com and also add the F5 default SSL Profile (Server) called serverssl
    The Policy still wouldn't work so created an iRule like the one below
    when HTTP_REQUEST { if { [HTTP::uri] equals "/" } { HTTP::uri "/?idp_id=two" } } Assigned the iRule to the Virtual Server Resources and now we are in business.
  7. Here is a very helpful script that can be used to export
    Virtual Server Profile Certificate Ciphers I personally create a file called: show-vs-cpfl-cert-ciphers.sh
    Then I make it executable: chmod 755 show-vs-cpfl-cert-ciphers.sh
    Now copy the code below and paste it in the new file
    #!/bin/bash # Search /config and sub directories (partitions) for bigip.conf files LIST=`find /config -name bigip.conf | xargs awk '$2 == "virtual" {print $3}' 2> /dev/null | sort -u` echo "Virtual: Profile: Certificate: Ciphers:" echo "__________________________________________________________" for VAL in ${LIST} do PROF=`tmsh show /ltm virtual ${VAL} profiles 2> /dev/null | grep -B 1 " Ltm::ClientSSL Profile:" | cut -d: -f4 | grep -i "[a-z]" | sed s'/ //'g| sort -u` test -n "${PROF}" 2>&- && { VIRTS=`expr $VIRTS + 1` for PCRT in ${PROF} do CERT=`tmsh list /ltm profile client-ssl ${PCRT} | awk '$1 == "cert" {print $2}' 2> /dev/null | sort -u` test -n "${CERT}" 2>&- && { CIPHERS=`tmsh list /ltm profile client-ssl ${PCRT} ciphers | grep ciphers | awk '{print $2}'` echo "${VAL} ${PCRT} ${CERT} ${CIPHERS}" } done } done echo "Virtual server count: ${VIRTS}" Finally you can run the newly created file: ./show-vs-cpfl-cert-ciphers.sh
    My preference is to run it and capture the output to a txt file that I can manipulate later to sort by each of the fields so I run the command this way: ./show-vs-cpfl-cert-ciphers.sh > /var/tmp/how-vs-cpfl-cert-ciphers_output_$HOSTNAME"."$(date +%Y%m%d).txt
    Hope this helps you out as it has helped me

  8. LTM Migration compare OLD to NEW

    · guru · 08/31/2023 06:24 PM

    When migrating you want to make sure you don't miss anything so here are a few commands that I run to help me make sure what was on the old is on the new.
    CONFIGURATION PHASE
    Virtual Servers
    First objective is to check to make sure all the Virtual Servers are present.  If you aren't changing IP addresses then all I grab is the destination field since in many cases the name and/or partition may change.  For example we are moving to deploying all our Virtual Servers using JSON format and the Partition is now the IP address so all pools, profiles etc that are specific to that virtual server would be found under that partition/ip address.
    Anyhow, so how do you get all the destination IPs from all partitions?  Just run this command:
    tmsh -q -c 'cd / ; show ltm virtual recursive' | grep -i "destination " > /var/tmp/vs-destination-old_$HOSTNAME"."$(date +%Y%m%d).txt Why do I use show versus list?
    List command will show the destination IP with the port in the common name like 443 would be listed as https but on the show command its always the port number no matter how it was configured which is consistent which also makes it easier to do compares.
    Certificates and Keys
     
    AWAF Policies
     
     
    DEPLOYMENT PHASE - BEFORE MIGRATION
     
     
    DEPLOYMENT PHASE - AFTER MIGRATION
     
     
    VALIDATION PHASE
     
     
     
     

  9. F5 GTM-DNS Sync Group

    · guru · 04/20/2020 04:00 AM

    This is to help better explain the purpose of a sync group on the F5 GTM's or otherwise known as BIG-IP DNS.
    The following figure shows that, after a configuration change is made on the Los Angeles BIG-IP DNS system, the local big3d process initiates an iQuery connection to BIG-IP DNS sync group members in New York and Europe and advertises the updated configuration to the remote gtmd processes.

    Synchronization details
    When you configure BIG-IP DNS synchronization, the sync group members share and synchronize BIG-IP DNS configuration objects and metrics data. The following table lists the relevant configuration objects and whether the objects are synchronized.
    BIG-IP DNS configuration object Synchronized Wide IP addresses Yes Data centers Yes Servers Yes Virtual servers Yes Links Yes GSLB iRules Yes Topology records / Regions Yes Distributed applications Yes GSLB global settings Yes GSLB monitors Yes DNSSEC zones / Keys Yes DNS zone files Not synchronized by default Named configuration Not synchronized by default Listener addresses No DNS express zones No DNS cache No Synchronization group requirements
    Before you configure synchronization, you should be aware of the requirements for BIG-IP DNS synchronization group members to communicate and synchronize properly which are found on F5 K13734,  but the high level summary of it is this for the BIG-IP DNS synchronization group members to properly synchronize their configuration settings. 
    Verify that the following requirements are in place:
    BIG-IP DNS synchronization group members must be running the same software version
    A BIG-IP DNS device should be running the same software version as other members in the synchronization group. BIG-IP DNS devices that are running different software versions will not be able to communicate and properly synchronize BIG-IP DNS configuration and zone files. For information about displaying the software version, refer to K8759: Displaying the BIG-IP software version. Synchronization parameters must be properly defined for all members
    Synchronization must be enabled and each device must have the same synchronization group name. You can define the synchronization parameters by navigating to on BIG-IP DNS 11.5.0 and later: DNS > Settings > GSLB > General NTP must be configured on each device
    Before you can synchronize BIG-IP DNS systems, you must define the network time protocol (NTP) servers for all synchronization group members. Configuring NTP servers ensures that each BIG-IP DNS synchronization group member is referencing the same time when verifying the configuration data that needs to be synchronized. You can configure NTP by navigating to System > Configuration > Device > NTP. Port Lockdown must be set properly for the relevant self IP addresses
    Port lockdown is a security feature that specifies the protocols and services from which a self IP address can accept traffic. F5 recommends using the Allow Custom option for self IP addresses that are used for synchronization and other critical redundant pair intercommunications. You can configure port lockdown by navigating to Network > Self IPs. Note: Management-IP address are not compatible with iQuery; you should not use them as server IP addresses in the DNS server list.
    Configure the service ports shown in the following table for BIG-IP DNS operation on the specific self IP.
    Allowed Protocol Service Service Definition TCP 4353 iQuery TCP 22 SSH TCP 53 DNS UDP 53 DNS UDP 1026 Network Failover For further information on Port Lockdown behavior, please refer to K17333 listed in the Supplemental Information section below.
    TCP port 4353 must be allowed between BIG-IP GTM systems
    BIG-IP DNS synchronization group members use TCP port 4353 to communicate. You must verify that port 4353 is allowed between BIG-IP DNS systems. Compatible big3d versions must be installed on synchronization group members
    The big3d process runs on BIG-IP systems and collects performance information on behalf of the BIG-IP DNS system. For metrics collection to work properly, synchronization group members must run the same version of the big3d process. For more information about verifying big3d version information, refer to K13703: Overview of big3d version management. A valid device certificate must be installed on all members
    The device certificate is used by the F5 system to identify itself to a requesting F5 client system. The default device certificate, /config/httpd/conf/ssl.crt/server.crt, must be installed on each sync group member. You can verify the certificate validity by navigating to System > Device Certificates. Configuration review via GUI
    Enable synchronization on the system to ensure that the BIG-IP DNS system that is already installed on your network can share configuration changes with other BIG-IP DNS systems that you add to the BIG-IP DNS synchronization group.
    On the Main tab, click DNS > Settings > GSLB > General . The General configuration screen opens. Select the Synchronize check box. In the Group Name field, type the name of the synchronization group to which you want this system to belong. In the Time Tolerance field, type the maximum number of seconds allowed between the time settings on this system and the other systems in the synchronization group.The lower the value, the more often this system makes a log entry indicating that there is a difference. Tip: If you are using NTP, leave this setting at the default value of 10. In the event that NTP fails, the system uses the time_tolerance variable to maintain synchronization. Click Update.
    When a change is made on one BIG-IP DNS system in the BIG-IP DNS synchronization group, that change is automatically synchronized to the other systems in the group.
    Creating a data center on the existing BIG-IP DNS
    Create a data center on the existing DNS system to represent the location where the new BIG-IP DNS system resides. On the Main tab, click DNS > GSLB > Data Centers . The Data Center List screen opens. Click Create. The New Data Center screen opens. In the Name field, type a name to identify the data center. Important: The data center name is limited to 63 characters. In the Location field, type the geographic location of the data center. In the Contact field, type the name of either the administrator or the department that manages the data center. From the Prober Preference list, select the preferred type of prober(s). Option Description Inside Data Center By default, select probers inside the data center. Outside Data Center Select probers outside the data center. Specific Prober Pool Select one of the Probers from the drop-down list. When you want to assign a Prober pool at the data center level. Note: Prober pools are not used by the bigip monitor.
    From the Prober Fallback list, select the type of prober(s) to use if insufficient numbers of the preferred type are available. Option Description Any Available By default, select any available prober. Inside Data Center Select probers inside the data center. Outside Data Center Select probers outside the data center. None No fallback probers are selected. Prober fallback is disabled. Specific Prober Pool Select one of the Probers from the drop-down list. When you want to assign a Prober pool at the data center level. From the State list, select Enabled or Disabled. The default is Enabled, which specifies that the data center and its resources are available for load balancing. Click Finished. Defining a server on the existing BIG-IP DNS
    You must ensure that a data center where the new DNS system resides is available in the configuration of the existing BIG-IP® DNS before you start this task. You define a new server, on the existing BIG-IP DNS system, to represent the new BIG-IP DNS system. On the Main tab, click DNS > GSLB > Servers . The Server List screen opens. Click Create. The New Server screen opens. In the Name field, type a name for the server. Important: Server names are limited to 63 characters. From the Product list, select BIG-IP System. From the Data Center list, select the data center where the server resides. From the Prober Preference list, select the preferred type of prober(s). Option Description Inherit From Data Center By default, a server inherits the prober preference selection assigned to the data center in which the server resides. Inside Data Center A server selects the probers from inside the data center where the server resides. Outside Data Center A server selects the probers from outside the data center where the server resides. Specific Prober Pool Select one of the Prober pools from the drop-down list. When assigning the Prober pool at the server level. Note: Prober pools are not used by the bigip monitor.
    From the Prober Fallback list, select the type of prober(s) to be used if insufficient numbers of the preferred type are available. Option Description Inherit From Data Center By default, a server inherits the prober fallback selection assigned to the data center in which the server resides. Any Available For selecting any available prober. Inside Data Center A server selects probers from inside the data center where the server resides. Outside Data Center A server selects probers from outside the data center where the server resides. None No fallback probers are selected. Prober fallback is disabled. Specific Prober Pool Select one of the Probers from the drop-down list. When you want to assign a Prober pool at the server level. From the State list, select Enabled. In the BIG-IP System Devices area, click Add to add a device (server). Type a name in the Device Name field. Type an external (public) non-floating IP address in the Address field. If you use NAT, type an internal (private) IP address in the Translation field, and then click Add. Click Add. Click OK. From the Configuration list, select Advanced. Additional controls display on the screen. In the Health Monitors area, assign the bigip monitor to the server by moving it from the Available list to the Selected list. From the Availability Requirements list, select one of the following and enter any required values. Option Description All Health Monitors By default, specifies that all of the selected health monitors must be successful before the server is considered up (available). At Least The minimum number of selected health monitors that must be successful before the server is considered up. Require The minimum number of successful probes required from the total number of probers requested. From the Virtual Server Discovery list, select how you want virtual servers to be added to the system. Option Description Disabled The system does not use the discovery feature to automatically add virtual servers. This is the default value. Use this option for a standalone BIG-IP DNS system or for a BIG-IP DNS/LTM® combo system when you plan to manually add virtual servers to the system, or if your network uses multiple route domains. Enabled The system uses the discovery feature to automatically add and delete virtual servers. Use this option for a BIG-IP DNS/LTM combo system when you want the BIG-IP DNS system to discover LTM virtual servers. Enabled (No Delete) The system uses the discovery feature to automatically add virtual servers and does not delete any virtual servers that already exist in the configuration. Use this option for a BIG-IP DNS/LTM combo system when you want the BIG-IP DNS system to discover LTM virtual servers. In the Virtual Server List area, if you selected Disabled from the Virtual Server Discovery list, specify the virtual servers that are resources on this server. In the Name field, type the name of the virtual server. In the Address field, type the IP address of the virtual server. From the Service Port list, select the port the server uses. Click Add. Click Finished. Note: The gtmd process on each BIG-IP DNS system will attempt to establish an iQuery® connection over port 4353 with each self IP address defined on each server in the BIG-IP DNS configuration of type BIG-IP. Allow port 4353 in your port lockdown settings for iQuery® to work. The Server List screen opens displaying the new server in the list. The status of the newly defined BIG-IP DNS system is Unknown, because you have not yet run the gtm_add script. Running the gtm_add script
    Before you start this task, you must determine the self IP address of a DNS system in the BIG-IP® DNS synchronization group to which you want to add another BIG-IP DNS. You run the gtm_add script on the BIG-IP DNS system you are adding to your network to acquire the configuration settings from a BIG-IP DNS system that is already installed on your network. For additional information about running the script, see SOL13312 on AskF5.com (www.askf5.com). Note: The BIG-IP DNS and other BIG-IP systems must have TCP port 22 open between the systems for the script to work. You must perform this task from the command-line interface. Log in as root to the BIG-IP DNS system you are adding to your network. Run this command to access tmsh. tmsh Run this command to run the gtm_add script run gtm gtm_add Press the y key to start the gtm_add script. Type the IP address of the BIG-IP DNS system in the synchronization group to which you are adding this BIG-IP DNS system. Press Enter. If prompted, type the root password. Press Enter. The BIG-IP DNS system you are installing on your network acquires the configuration of the BIG-IP DNS system already installed on your network. Implementation result
    The new BIG-IP® DNS system that you added to the network is a part of a BIG-IP DNS synchronization group. Changes you make to any system in the BIG-IP DNS synchronization group are automatically propagated to all other BIG-IP DNS systems in the group.
     
    Troubleshooting BIG-IP DNS sync connections (11.x - 16.x)
    tmsh 
    The tmsh utility lists failing server objects as Offline and a failing iQuery connection as Not Connected. The following table lists tmsh commands that you can use to check the status of BIG-IP DNS synchronization group members and iQuery connections.
    tmsh component Description Example commands server Summary of defined DNS/GTM server objects tmsh list /gtm server all tmsh show /gtm server all
    iquery Summary of iQuery statistics tmsh show /gtm iquery all gtm Summary of DNS/GTM statistics tmsh show /gtm Note: All members that participate in the iQuery mesh must be listed in the Server List. If a member of the iQuery mesh is not included in the Server List, it may result in some or all monitors intermittently or consistently failing. The monitors fail any time the big3d agent on the missing member (server) is expected to perform and report the monitor status. This can result in virtual servers being marked offline with a reason of no reply from big3d: timed out.
    Verify required configuration elements for synchronization group members
    For BIG-IP DNS synchronization group members to communicate and synchronize properly, you must verify that certain requirements are in place. To do so, review the following checklist.
    Sync requirement Description Configuration utility location tmsh Software versions Run the same software version for synchronization group members System > Software Management tmsh show /sys software Sync settings Use the same synchronization group settings for all members DNS > Settings > GSLB > General (BIG-IP 11.5.0 and later) System > Configuration > Global Traffic > General (BIG-IP 11.4.1 and earlier)
    tmsh list /gtm global-settings general all-properties NTP Configure NTP for all members System > Configuration > Device > NTP tmsh list /sys ntp servers Port Lockdown Use the Allow Default option for self IPs that process iQuery traffic Network > Self IPs tmsh list /net self allow-service iQuery port Verify that TCP port 4353 is allowed on interconnecting devices Not Applicable Not Applicable big3d versions Run the same big3d version on all members. Note: The big3d version should not be older than the host BIG-IP version.
    Not Applicable big3d -v /shared/bin/big3d -v
    Review log files
    Reviewing the log files is one way to determine the cause of synchronization/iQuery connection issues. The system logs global traffic events to the /var/log/gtm file. Some of the logging related to synchronization/iQuery connection issues is as follows:
     
    Device certificate messages
    The BIG-IP system uses SSL certificates for inter-device communication using the iQuery protocol. If device certificates are missing, expired, or contain duplicate common name (CN) entries with certificates on one of the synchronization group members, the system is marked Offline and logs an error message to the /var/log/gtm file that appears similar to the following example:
    SSL error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed When creating or renewing BIG-IP device certificates, use the following guidelines:
    Device certificates should have unique and meaningful subject data. For example, the CN field should match the hostname of the BIG-IP system in which the certificate was created. When possible, create device certificates with an extended expiration date. Make sure that SSL certificates are not expired.  
    iQuery Connectivity messages
    The iQuery protocol uses TCP port 4353 to connect to synchronization group members. The system logs a successful iQuery connection to the /var/log/gtm file.
    For example:
    gtmd[8472]: 011ae020:5: Connection in progress to <iquery_peer> gtmd[8472]: 011ae01c:5: Connection complete to <iquery_peer>. Starting SSL handshake gtmd[11895]: 011a5003:1: SNMP_TRAP: Server /Common/<hostname> (ip=<iquery_peer>) state change red --> green gtmd[11895]: 011a5008:1: SNMP_TRAP: BIG-IP GTM /Common/<hostname> (<iquery_peer>) joined sync group default If the iQuery protocol is blocked; for example, by a router ACL, or packet filter, the BIG-IP DNS system marks its iQuery peer as Unavailable and attempts to reestablish the iQuery connection every 10 seconds. When this behavior occurs, a log sequence appears in the /var/log/gtm file that appears similar to the following example:
    gtmd[11895]: 011a500c:1: SNMP_TRAP: Box <iquery_peer> state change green --> red (Box <iquery_peer> on Unavailable) gtmd[11895]: 011a5004:1: SNMP_TRAP: Server /Common/<hostname> (ip=<iquery_peer>) state change green --> red (No communication) gtmd[8472]: 011ae020:5: Connection in progress to <iquery_peer> gtmd[8472]: 011ae020:5: Connection in progress to <iquery_peer> gtmd[8472]: 011ae020:5: Connection in progress to <iquery_peer> gtmd[8472]: 011ae020:5: Connection in progress to <iquery_peer> NTP messages
    The Synchronization Time Tolerance setting specifies the number of seconds that one system clock can be out of sync with another system clock in the synchronization group. If the time difference between synchronization group members is greater than the Synchronization Time Tolerance value, the system logs a message to the /var/log/gtm file that appears similar to the following example:
    gtmd[11895]: 011a0022:2: Time difference between GTM /Common/B3900-242 and me is 486 seconds -- Make sure NTP is running and GTM times are in sync This error message is an indication that NTP may not be configured on one or more synchronization group members.
     
    Troubleshoot iQuery connectivity
    BIG-IP DNS systems in a synchronization group create an iQuery mesh across synchronization group members. For example, the local BIG-IP DNS system's gtmd process opens an iQuery connection to its own big3d process, and to remote synchronization group member's big3d process. There may be occasions when you must test iQuery connectivity between synchronization group members. For example, if log messages indicate that a BIG-IP DNS system has marked its iQuery peer as Unavailable, you can perform the following troubleshooting procedure to test TCP port 4353 connectivity:
    Impact of procedure: Performing the following procedure should not have a negative impact on your system.
    Log in to the command line.
    To verify the iQuery connection status, enter the following netstat command: netstat -na |grep 4353
    The following netstat output indicates that the local system (10.11.16.238) is listening on port 4353 and has an iQuery connection established to its own big3d process. In addition, the local system and its iQuery peer (10.11.16.242) have established an iQuery mesh:
    Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 :::4353 :::* LISTEN tcp 0 0 ::ffff:10.11.16.238:52794 ::ffff:10.11.16.238:4353 ESTABLISHED tcp 0 0 ::ffff:10.11.16.238:4353 ::ffff:10.11.16.242:58779 ESTABLISHED tcp 0 0 ::ffff:10.11.16.238:4353 ::ffff:10.11.16.238:52794 ESTABLISHED tcp 0 0 ::ffff:10.11.16.238:46882 ::ffff:10.11.16.242:4353 ESTABLISHED If the synchronization group iQuery mesh is incomplete, you can use the iqdump command to determine if the iQuery packets arrive at the destination.
    If the iQuery channel is not established, iqdump returns with an SSL error similar to the following example:
    iqdump 10.10.10.20 46947856243768:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1168: Note: If the iqdump command returns a connection refused message, you should ensure connectivity for the iQuery channel is allowed, such as ensuring port 4353 is allowed by the self IP addresses on each system and devices in between. You may need to restart the big3d process to recover from the connection-refused condition.
    If the iQuery channel is established, iqdump returns XML similar to the following example:
    iqdump 10.10.10.20 <!-- Local hostname: lc1.example.com --> <!-- Connected to big3d at: ::ffff:10.10.10.10:4353 --> <!-- Subscribing to syncgroup: default --> <!-- Tue May 6 09:55:43 2014 --> <xml_connection> <version>11.5.1</version> <big3d>big3d Version 11.5.1.0.0.110</big3d>  
    Verify device SSL certificates
    Each synchronizing group member must have a valid SSL device certificate installed in the /config/httpd/conf/ssl.crt/ directory for iQuery connections to succeed. If log messages indicate an issue with a device certificate on one of the synchronization group members, you can verify the certificate status by performing the following procedure:
    Note: SSL certificates signed by a third-party certificate authority (CA) must include both the client authentication (clientAuth) and server authentication (serverAuth) extended key usage (EKU) extensions, to allow use by both server and client applications. For example, the big3d process operates as a server (serverAuth), while the gtmd process operates as a client (clientAuth). For information, refer to K7717: BIG-IP DNS and Link Controller support for third-party SSL certificates.
    Impact of procedure: Performing the following procedure should not have a negative impact on your system.
    Log in to the command line.
    Check the status of the device certificate by entering the following command:
    openssl x509 -noout -text -in /config/httpd/conf/ssl.crt/server.crt Verify the certificate validity date and confirm whether the certificate is expired.
    If necessary, renew the certificate. To do so, refer to K16951115: Changing the BIG-IP DNS system device certificate using the Configuration utility.
    Troubleshoot daemons
    Impact of procedure: Performing the following procedure should not have a negative impact on your system.
    The tmm, mcpd, big3d, and gtmd processes are all critical to synchronizing BIG-IP DNS configurations. To confirm that the daemons are running as expected, use the tmsh command.
    For example, to confirm the status of the tmm, mcpd, big3d, and gtmd processes, enter the following command:
    tmsh show sys service tmm mcpd big3d gtmd If the mcpd process is consuming more than 90 percent of a CPU, and synchronizing actions, such as saving the configuration, may fail. To check the CPU usage for the mcpd process, enter the following command:
    top -p `pidof mcpd` To quit, enter q.
     
    Troubleshoot synchronization group members using the server type
    Starting from BIG-IP 12.x, you can use the Server Type field from the tmsh show /gtm iquery command output to determine if the listed BIG-IP DNS devices are fully setup to be in the same BIG-IP DNS synchronization group.
    If the BIG-IP DNS device is fully setup to be in the same BIG-IP DNS synchronization group as the remaining listed BIG-IP DNS devices, the command output would have the value of BIGIP-DNS for Server Type as shown in the following example:
    ----------------------------------------------------------- Gtm::IQuery: 192.168.74.129 ----------------------------------------------------------- Server                                                 b100 Server Type                                       BIGIP-DNS Note: The previous example output is truncated for brevity.  
    If the BIG-IP DNS device is not properly setup to be in the same BIG-IP DNS synchronization group as the remaining listed BIG-IP DNS devices, the command output would have the value of BIGIP for Server Type as shown in the following example:
    Important: For remote BIG-IP LTM devices that are integrated into the network with BIG-IP DNS, their Server Type continues to indicate as BIGIP.
    -------------------------------------------------- Gtm::IQuery: 192.168.74.130 -------------------------------------------------- Server                                        b101 Server Type                                  BIGIP Note: The previous example output is truncated for brevity. In the case of the BIG-IP DNS device not properly setup, you may want to re-run the gtm_add utility on the affected BIG-IP DNS device again.

  10. iQuery issues troubleshooting

    · guru · 04/28/2022 04:00 PM

    REQUIREMENTS:
    For the BIG-IP DNS synchronization group members to properly synchronize their configuration settings, verify that the following requirements are in place:
    BIG-IP DNS synchronization group members must be running the same software version A BIG-IP DNS device should be running the same software version as other members in the synchronization group. BIG-IP DNS devices that are running different software versions will not be able to communicate and properly synchronize BIG-IP DNS configuration and zone files. For information about displaying the software version, refer to K8759: Displaying the BIG-IP software version.
    Synchronization parameters must be properly defined for all members Synchronization must be enabled and each device must have the same synchronization group name. You can define the synchronization parameters by navigating to:
    BIG-IP DNS 11.5.0 and later:
    DNS > Settings > GSLB > General
    BIG-IP GTM 10.0.0 through 11.4.1:
    System > Configuration > Device > GTM > General
    NTP must be configured on each device Before you can synchronize BIG-IP DNS systems, you must define the network time protocol (NTP) servers for all synchronization group members. Configuring NTP servers ensures that each BIG-IP DNS synchronization group member is referencing the same time when verifying the configuration data that needs to be synchronized. You can configure NTP by navigating to System > Configuration > Device > NTP.
    Port Lockdown must be set properly for the relevant self IP addresses Port lockdown is a security feature that specifies the protocols and services from which a self IP address can accept traffic.
    F5 recommends using the Allow Custom option for self IP addresses that are used for synchronization and other critical redundant pair intercommunications. You can configure port lockdown by navigating to Network > Self IPs.
    Note: Management-IP address are not compatible with iQuery; you should not use them as server IP addresses in the DNS server list.
    Configure the service ports shown in the following table for BIG-IP DNS operation on the specific self IP.
    Allowed Protocol Service Service Definition TCP 4353 iQuery TCP 22 SSH TCP 53 DNS UDP 53 DNS UDP 1026 Network Failover For further information on Port Lockdown behavior, please refer to K17333 listed in the Supplemental Information section below.
    TCP port 4353 must be allowed between BIG-IP GTM systems BIG-IP DNS synchronization group members use TCP port 4353 to communicate. You must verify that port 4353 is allowed between BIG-IP DNS systems.
    Compatible big3d versions must be installed on synchronization group members The big3d process runs on BIG-IP systems and collects performance information on behalf of the BIG-IP DNS system. For metrics collection to work properly, synchronization group members must run the same version of the big3d process. For more information about verifying big3d version information, refer to K13703: Overview of big3d version management.
    A valid device certificate must be installed on all members The device certificate is used by the F5 system to identify itself to a requesting F5 client system. The default device certificate, /config/httpd/conf/ssl.crt/server.crt, must be installed on each sync group member. You can verify the certificate validity by navigating to System> Device Certificates.
     
    EXPLANATION of DNS SYNC
    A BIG-IP DNS synchronization group is a collection of multiple BIG-IP DNS systems that share and synchronize configuration settings. You must meet several minimum requirements for BIG-IP DNS synchronization group members to communicate and synchronize properly.
    Starting in 11.x, the BIG-IP DNS system uses a commit_id structure, which is linked to an MCP transaction, as a timestamp when updating the configuration for a given sync group. The BIG-IP DNS sync group communication flow works as follows:
    The Configuration utility or the TMOS Shell (tmsh) communicates configuration changes to the mcpd process. The mcpd process forwards the new configuration in its entirety to the local gtmd process. The gtmd process updates the commit_id value and writes the new configuration to the /config/bigip_gtm.conf file. The local big3d process begins advertising the updated commit_id value using heartbeat messages transmitted to all remote gtmd processes. When a remote gtmd process notices that the peer BIG-IP DNS system has a newer commit_id value, the remote gtmd invokes the iqsyncer utility to pull the newer configuration. The iqsyncer utility connects to the big3d process of the BIG-IP DNS system with the newer commit_id and requests the changes between the newer commit_id and its current commit_id. The big3d process connects to its mcpd process and if the differences between commit_ids exist in the incremental config sync cache, then just these incremental changes are passed back. If not, the full configuration are passed in one or more messages. The big3d process then transmits those messages back to the requesting iqsyncer utility, and iqsyncer passes the new configuration directly to its own mcpd process, which loads it into memory. After the mcpd process receives the new configuration, it passes the configuration to its own gtmd process, which updates its timestamp with the commit_id of the source BIG-IP DNS system, and writes the configuration to the /config/bigip_gtm.conf file.

  11. Davison Robotics

    · guru · 03/08/2021 01:50 AM

    Today is the last day supporting the website.  Some bad eggs.
    No longer supporting the following websites
    davisonrobotics.com davisonrobotics.net davisonrobotics.org team10058.com team9514.com team3534.com DONE!
    Yes this logo is something provided by EventGuyZ

  12. Davison Robotics

    Charity · guru · 01/13/2021 07:42 PM

    Davison Robotics is part of an extra curricular activity offered to students of the Davison Community Schools that offers the ability to learn STEM (Science, Technology, Engineering, and Mathematics) and is part of FIRST.  
    Current Davison Community School FIRST Teams include:
    Davison High School (Team 3534) Davison Middle School (Team 10058, Team 9514 ) Davison Intermediate School ( ) Davison Elementary School ( ) EventGuyZ became a supporter and addressed the lack of a davisonrobotics.com website in early 2018.  They were using team3534.com but nothing to represent any of the other Davison Robotics teams so we registered davisonrobotics.com and created a general Davison Robotics logo

    Then we created email accounts for the domain @davisonrobotics.com since the turnover on volunteers and board members is pretty often so when volunteers contact supporters and/or vendors the email will be saved for the next person.  All we do is setup a forward to personal email of volunteer so they can see the email come into there mailbox (still leaving the original in the mailbox on the server).  To respond, they can email with [email protected] so everything is saved.  All working beautifully.
    Initial website used Wordpress which was slow... very very slow.  Was getting attacked on a regular basis (unsuccessfully) but the investment to build the website on Wordpress and add all the requested features was taking more money than we felt comfortable donating so we had to regroup and strategize on a better solution.  We ended up building an Invision Community website that was beautiful, functional and half the cost.  Also provided much better security.
    Kids and Coaches were using the site successfully and then began the downward spiral which is why the website no longer exists.  We did this to help the kids and support volunteers since they are giving up their time to help the students be successful but being ungrateful for the thousands invested breaks that relationship very easily.
    We wish Davison Robotics much success.  You can follow them on Facebook.
     

Account

Navigation

Search

Search

Configure browser push notifications
Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.