gtm_add failing due to CERT error
I am trying to cluster to GTM devices using the gtm_add command, but this is failing with this error: ERROR: found "END CERT..." without BEGIN at line: 0. ERROR: Malformed certificates found in local /config/httpd/conf/ssl.crt/server.crt. But when I check the mentioned file it looks like a valid certificate: more /config/httpd/conf/ssl.crt/server.crt -----BEGIN CERTIFICATE----- MIIHFjCCBP6gAwIBAgIDbUVxMA0GCSqGSIb3DQEBCwUAMGwxDDAKBgNVBAoTA0lORzERMA8GA1UE CxMIU2VydmljZXMxIDAeBgNVBAsTF0NlcnRpZmljYXRlIEF1dGhvcml0aWVzMScwJQYDVQQDEx5J TkcgQ29ycG9yYXRlIEludGVybmFsIENBIC0gRzMwHhcNMjQwNjI0MTQyMzAyWhcNMjUwNzI0MTMw ... E1Zg8g9QlL+jksX7ew0tIuZPNGPbhPE3StATtD7b4oi1TYjVfIwn79DluSwkIp5hwVDrAcW/B5T6 zK+sJJlib4ZeCnV19cCkwBnYyRz0p46VrwXw7i3bYeC8Cq4Of++LaYaXDuhOVq/V61phJRoGTlRU vOII3wHBmXiXQv7MIScQQbmKaBRC2lxu0gAJV9a8vzpXfN6T+n7PxNBH4AuNdR5KeeG7 -----END CERTIFICATE----- Also via the browser the correct certificate is shown. Any suggestions on what the problem could be?
Geolocation when LDNS in a different geography than user doing the lookup
I am wondering if anyone has clever thoughts on how to address the situation with Topology load-balancing on F5 DNS. If a user is in EMEA but their ISP DNS server is in the US, it will be that DNS server in the US whose IP is analyzed by the geolocation database on the F5 and the GTM will respond with the DNS entry appropriate for US IP addresses. This circumvents our geolocation intent. Is there anything anyone has come up with to do to address this?Virtual server address space on disaster recovery F5 instance
I am working on setting up a disaster recovery instance of an existing HA BIGIP pair. I would like to ConfigSync (sync only) my local devices to the new device which is located in a different data center. The issue is that if/when I needed to "fail over" (manually) to the new disaster recovery device, the IP space of the virtual servers are different. So for example if my virtual server "A" has a destination address of 192.168.1.10 in my existing data center, the new destination address might be 10.1.1.10. (Note: I am less worried about pool member IP space, because I can use priority groups and have the disaster recovery pool member IPs pre-configured but disabled). My first thought was a "DR go live" script which would search & replace the config file and reload it, but is there a more "elegant" way to handle this dilemma, without having them have the same IP space?
LTM replacement question(LTM as a server of the other F5 DNS): Is there any problem of the crt?
I want to replace a pair of LTMs(1600 to i2600, v11 to v13), but the LTMs are the server of another F5 DNS. Is there any problem should I concern? I configuated the new LTMs with the ucs files of the old LTMs, but I generated new device crt when I configures HA group at the same time. Will it affect the communication between the new LTMs and the DNS? If so, I want to replcace the crt files of the new LTMs with the old LTMs'(/config/httpd/conf/ssl.crt/server.crt, /config/httpd/conf/ssl.key/server.key, /config/gtm/server.crt). Is this a correct methold? Or any other advise? thanks!
