《GTMEssentials_V1.5.2.ppt》由會員分享，可在線閱讀，更多相關《GTMEssentials_V1.5.2.ppt（83頁珍藏版）》請在裝配圖網上搜索。
1、GTM Essentials,Prepared and presented by: LinJing V1.5.2 ,Updates,Updates,說明,該PPT適合對GTM/LTM已經有一定基礎同學 如無GTM知識，建議首先閱讀metoo的GTM安裝指南-V2.0bible啊，下面連接是v1.0 請到 錯別字請自行糾正 本文不是bible，F5軟件日新月異，可能部分內容需基于指定版本 問題請在帖子下指出并討論，感謝,GTM關鍵點,GTM中的對象關系 Listener決策策略 證書交換機制 Add new GTM to sync group八步法 iquery結構關系 gtmd、big3d的選
2、舉 部分重要算法 Monitor及path metric collection 私有地址server情形下的NAT處理 Named.conf,zone,wideip.conf,persistence的同步 ZoneRunner ;,ZoneRunner & BIND,由于使用動態更新方式控制zone，所以不要輕易嘗試手工編輯zone文件 Wideip,zonerunner界面的配置修改，并不會立即同步到對應的zone文件中 這些變化臨時存在于/var/named/config/namedb下對應zone的jnl文件中 BIND 的named.conf文件存放于/var/named/config
3、目錄下，zonerunner界面也可以編輯 F5的BIND默認不提供遞歸功能,ZoneRunner & BIND,See SOL7176:F5 Networks support for ZoneRunner, BIND, and the named daemon,GTM配置十步法,Define VLANs Define Self IPs Create default route Define NTP servers Define GTM listeners Create data centers Create Server objects big3d_install or bigip_add
4、for BIG-IP servers Create GTM pool Objects Create WideIPs,日志檢查及排錯,Gtm日志保存在/var/log/gtm中 當需深入排錯時，可以打開gtmd的一些高級日志 GTM.QueryLogging = enable /default disable GTM.DebugProbeLogging=enable /default disable Log.GTM.Level = debug /default notice Log.Big3d.Level = debug /defualt notic,日志檢查及排錯,rootb1500-930-
5、1b:Active config # tail -f /var/log/gtm |grep 172.24.9.15 Jul 22 13:55:20 b1500-930-1b gtmd1036: 011ae039:7: Check probing of IP:Port 172.24.9.15:80 in DC dc3 Jul 22 13:55:20 b1500-930-1b gtmd1036: 011ae03a:7: Will not probe 172.24.9.15:80 in DC dc3 because will be done by other GTM (:172.24.9.12) J
6、ul 22 13:55:31 b1500-930-1b gtmd1036: 011ae03d:5: Probe from 172.24.9.13: buffer = tcp :ffff:172.24.9.15 80 :ffff:172.24.9.15 80 6 4 2 state: timeout Jul 22 13:55:31 b1500-930-1b gtmd1036: 011ae0f2:1: Monitor instance tcp 172.24.9.15:80 UP - DOWN from 172.24.9.13 (state: timeout) Jul 22 13:55:31 b15
7、00-930-1b gtmd1036: 011a6006:1: SNMP_TRAP: VS 172.24.9.15:80 (Server dc3_ext- host_training_server) state change green - red (VS dc3_ext- host_training_server: Monitor tcp from 172.24.9.13 : state: timeout) Jul 22 13:55:31 b1500-930-1b gtmd1036: 011a5004:1: SNMP_TRAP: Server dc3_ext- host_training_s
8、erver (ip=172.24.9.15) state change green - red (Server dc3_ext- host_training_server: No enabled VS available) rootb1500-930-1b:Active ucs # tail -f /var/log/gtm |grep Wide Jul 22 13:55:31 b1500-930-1b gtmd1036: 011a3004:1: SNMP_TRAP: Wide IP state change green - red (Wide IP : No enabled pools ava
9、ilable),日志檢查及排錯,rootb1500-925-1a:Active ucs # tail -f /var/log/gtm |grep 172.24.9.15 Jul 22 13:55:26 b1500-925-1a gtmd987: 011ae039:7: Check probing of IP:Port 172.24.9.15:80 in DC dc3 Jul 22 13:55:26 b1500-925-1a gtmd987: 011ae03b:7: Will probe 172.24.9.15:80 in DC dc3 Jul 22 13:55:26 b1500-925-1a
10、gtmd987: 011ae03d:5: Probe to 172.24.9.13: buffer = tcp :ffff:172.24.9.15 80 :ffff:172.24.9.15 80 120 1 5 1 1 0 0 4 2 SEND= 1 RECV_I= 3 Jul 22 13:55:31 b1500-925-1a gtmd987: 011ae03d:5: Probe from 172.24.9.13: buffer = tcp :ffff:172.24.9.15 80 :ffff:172.24.9.15 80 6 4 2 state: timeout Jul 22 13:55:3
11、1 b1500-925-1a gtmd987: 011ae0f2:1: Monitor instance tcp 172.24.9.15:80 UP - DOWN from 172.24.9.13 (state: timeout) Jul 22 13:55:31 b1500-925-1a gtmd987: 011a6006:1: SNMP_TRAP: VS 172.24.9.15:80 (Server dc3_ext- host_training_server) state change green - red (VS dc3_ext- host_training_server: Monito
12、r tcp from 172.24.9.13 : state: timeout) Jul 22 13:55:31 b1500-925-1a gtmd987: 011a5004:1: SNMP_TRAP: Server dc3_ext- host_training_server (ip=172.24.9.15) state change green - red (Server dc3_ext- host_training_server: No enabled VS available),日志檢查及排錯,Mar 17 05:55:48 gtm3 gtmd1260: 011ae03c:7: getc
13、onfig_put: Could not find my own box, will not continue with auto discovery. 把LTM加入到GTM，iquery都建立了，卻沒有vs被發現，如果有此日志說明gtm自己沒有被加入到server中,日志檢查及排錯,Iqdump peer_ipaddress sync_group_name 不跟sync_group_name只能看到基本的心跳和server統計信息，無法看到vs信息 Dig或nslookup得到類似AUTHORITY: 2的flag，意味著結果是由BIND給出。,日志檢查及排錯,某個object由哪個big3
14、d負責探測是可能不斷變化的，這在某種情形下或許會導致server狀態的flapping 在1500平臺上，Big3d，gtmd競爭20%的CPU資源，因此大量的path探測可能會導致性能問題，可以關閉GTM上的big3d對path的探測功能，在加gtm到server的時候有iquery option，關閉path探測即可,日志檢查及排錯,SOL8187: Troubleshooting BIG-IP LTM and GTM device certificates SOL8195:Overview of the BIG-IP GTM big3d_install, bigip_add, and g
15、tm_add utilities SOL4039:Overview of iQuery communication between BIG-IP and 3-DNS version 4.x and BIG-IP LTM and GTM version 9.x SOL5965:The BIG-IP GTM is unable to monitor BIG-IP version 4.x,日志檢查及排錯,wideip層面選擇GA，GA所要選擇的pool變紅，但是該pool里的某個算法可以實現解析出一個IP地址，測試GTM依然會選擇該POOL。 例如pool里的算法是fall back ip/retu
16、rn to dns. 因此如果要在WIDEIP層面做GA，應該不容許 pool層面總是可以得到結果 的情況出現。 Pool中算法選擇none是控制算法跳過或跳躍到下一個可用pool的好方法。,Topology, ,Topology都miss的情況下 (注意備注),如果wideip層面的top算法都failed，則行為如下（V9.3.1 wideip下有2個pool）： 1.選擇第一個可用的pool 2.按照被選擇的pool里所設定的算法來作為pool間的算法，例如pool中是的第一算法是RR，則在POOL間輪詢。 3。如果被選擇pool的第一算法failed，則使用第二算法，因此類推。 4。如
17、果被選擇pool的算法所決定的最終算法是return to dns 則意味著這個pool不可用，此時return to到wideip上，而不是真正的BIND，即又會回到wideip層面選取下一個可用pool并按照該pool設定的算法執行，如果這個pool的算法最終又是return to dns，就會真正的return to BIND.,與排錯相關的更多資源,GTM配置關鍵點及排錯總結.pptx 這篇文檔在給channel 的資料U盤上有 超超的GTM 2 days training - v2.pptx GTM部署模型方案討論 ,關于開GTM CASE,NSE雖然通過wideip.conf可以大
18、體復現一個網絡結構，但是這往往不全面，提供全面清晰的GTM 網絡結構圖往往非常有助于解決問題 L3的服務，記得一定先自我仔細排查并搜集有效的信息及證據，準確描述問題現象及時間是關鍵 提供gtmd的debug及gtmd的probe debug日志信息往往更有效 Askf5,devcentral,擁有很多優秀的資源，常規問題或許別人已經見過 出現問題前做過什么，往往會有驚奇發現 相互理解更能快速解決問題,CASE-cert troubleshooting-clue,Iquery通信正常時候，gtmd,big3d之間的SSL過程： 以GTM和LTM為例，gtm要用其gtmd主動發起一個SSL到LTM
19、上的big3d的協商，此過程中，GTM作為ssl的client端，ltm作為ssl的server端。這是一個雙向SSL認證過程： GTM(gtmd)ssl client-LTM(big3d)ssl server 那么： 1.Gtmd發client hello 2.big3d響應server hello 并發送服務端cert （httpd證書），cert request（攜帶可接受的CA-從client.crt中讀?。┙ogtmd 3.Gtmd得到big3d發來的證書后，用其server.crt來校驗big3d發來的證書。并看big3d發來的可接受CA中是否有自己device cert所對應的CA
20、。然后gtmd發送客戶端cert（httpd證書）給big3d，并發送cert verify申請 4.big3d端檢驗gtmd發來的客戶端證書并做hash校驗 如果一切OK，則通過,正常時模擬iquery 連接,rootB3600-R18-S41:Active config # openssl s_client -tls1 -showcerts -connect 61.61.61.200:4353 -cert /config/httpd/conf/ssl.crt/server.crt -key /config/httpd/conf/ssl.key/server.key -verify /con
21、fig/gtm/server.crt verify depth is 0 CONNECTED(00000003) depth=0 /C=CN/ST=beijing/L=beijing/O=f5ltm/OU=20100701/CN=B3400-R17-S20-server端發出的證書信息 verify error:num=18:self signed certificate -可以忽略 verify return:1 depth=0 /C=CN/ST=beijing/L=beijing/O=f5ltm/OU=20100701/CN=B3400-R17-S20 verify return:1 -
22、Certificate chain-server端證書鏈信息 0 s:/C=CN/ST=beijing/L=beijing/O=f5ltm/OU=20100701/CN=B3400-R17-S20 i:/C=CN/ST=beijing/L=beijing/O=f5ltm/OU=20100701/CN=B3400-R17-S20 -BEGIN CERTIFICATE- -下面的證書傳給client MIICTDCCAbWgAwIBAgIBADANBgkqhkiG9w0BAQUFADBsMQswCQYDVQQGEwJDTjEQ MA4GA1UECBMHYmVpamluZzEQMA4GA1UEBxM
23、HYmVpamluZzEOMAwGA1UEChMFZjVs dG0 xETAPBgNVBAsTCDIwMTAwNzAxMRYwFAYDVQQDEw1CMzQwMC1SMTctUzIwMB4X DTEwMDcwMTA1MjA1N1oXDTIwMDYyODA1MjA1N1owbDELMAkGA1UEBhMCQ04xEDAO BgNVBAgTB2JlaWppbmcxEDAOBgNVBAcTB2JlaWppbmcxDjAMBgNVBAoTBWY1bHRt MREwDwYDVQQLEwgyMDEwMDcwMTEWMBQGA1UEAxMNQjM0MDAtUjE3LVMyMDCBnzAN BgkqhkiG9
24、w0BAQEFAAOBjQAwgYkCgYEAxy1oFb8B1wmBRUwJGwY1kCVlAlpqUMnH slOpA2aWNguADkI5P5cL2KSnoQvdt/6pX1WjJDhipA4yEJbCkYpmO+Lj28rzVKs+ 5FEa+IRDYsA/B6jUs5rwlzB07TWx8SZY5kLNX3IOzegOBnCw5Sllrm2rEdc3GCG2 ciQGC14wlCkCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBq0yhPtxNdAfZlNgRw06cD X5B1lmZS/C+N12B8a5R9fpqaZ4VX5jbFZT/rxs8S/G9G6ch+b
25、+RQHEW9L0D8yjc1 5l3Mii4eWH7mbjJBaJ7rDSRvQomYOIqIs+FZrXqmLdn75YNIc+wdrZcNiC6ud1Le cue+/sO7PKCPa+iZVSbjgQ= -END CERTIFICATE-,正常時模擬iquery 連接Cont.,- Server certificate -服務端證書信息及其issuer subject=/C=CN/ST=beijing/L=beijing/O=f5ltm/OU=20100701/CN=B3400-R17-S20 issuer=/C=CN/ST=beijing/L=beijing/O=f5ltm/OU=20
26、100701/CN=B3400-R17-S20 - Acceptable client certificate CA names -服務端發出的cert request，表明其可接受這些CA下的證書 /C=-/ST=WA/L=Seattle/O=MyCompany/OU=1277774828/CN=localhost.localdomain/emailAddress=rootlocalhost.localdomain /C=CN/ST=beijing/L=beijing/O=f5ltm/OU=20100701/CN=B3400-R17-S20 - SSL handshake has read
27、1040 bytes and written 1414 bytes - New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: 63010946C033659C1F0D739320E9B514A2247F828B600D4DAC35D003308BA3B9 Session-ID
28、-ctx: Master-Key: 930D767A9579440DE37D5CD45D989E9FD2BA646896669A33A068DD7531BC3CE85DCE77E82C45BEF70625409EBA43D702 Key-Arg : None Krb5 Principal: None Compression: 1 (zlib compression) Start Time: 1278039408 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) - x2?O?M.?K-*,a.?0?Qh?
29、gg?glllS?. -握手通過后傳出的壓縮報文,CASE1：cert troubleshooting -clue,環境：一個GTM，一個LTM，bigip_add同步證書后，應該在GTM的server.crt里有GTM+LTM的證書，在LTM的client.crt里有GTM+LTM的證書 確認證書同步沒錯，iquery正確，LTM也綠色 在GTM的trusted server certificate中刪掉LTM的證書，然后重啟LTM的big3d，使iquery重連。 在GTM上openssl發起連接測試，得到下頁結果,在gtm-server.crt中刪除ltmcert測試,verify de
30、pth is 0 CONNECTED(00000003） depth=0 /C=CN/ST=beijing/L=beijing/O=f5ltm/OU=20100701/CN=B3400-R17-S20 verify error:num=18:self signed certificate- verify return:1 depth=0 /C=CN/ST=beijing/L=beijing/O=f5ltm/OU=20100701/CN=B3400-R17-S20 verify return:1 - Certificate chain 0 s:/C=CN/ST=beijing/L=beijing
31、/O=f5ltm/OU=20100701/CN=B3400-R17-S20 i:/C=CN/ST=beijing/L=beijing/O=f5ltm/OU=20100701/CN=B3400-R17-S20 -BEGIN CERTIFICATE- MIICTDCCAbWgAwIBAgIBADANBgkqhkiG9w0BAQUFADBsMQswCQYDVQQGEwJDTjEQ MA4GA1UECBMHYmVpamluZzEQMA4GA1UEBxMHYmVpamluZzEOMAwGA1UEChMFZjVs dG0 xETAPBgNVBAsTCDIwMTAwNzAxMRYwFAYDVQQDEw1CM
32、zQwMC1SMTctUzIwMB4X DTEwMDcwMTA1MjA1N1oXDTIwMDYyODA1MjA1N1owbDELMAkGA1UEBhMCQ04xEDAO BgNVBAgTB2JlaWppbmcxEDAOBgNVBAcTB2JlaWppbmcxDjAMBgNVBAoTBWY1bHRt MREwDwYDVQQLEwgyMDEwMDcwMTEWMBQGA1UEAxMNQjM0MDAtUjE3LVMyMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxy1oFb8B1wmBRUwJGwY1kCVlAlpqUMnH slOpA2aWNguADkI5P5cL
33、2KSnoQvdt/6pX1WjJDhipA4yEJbCkYpmO+Lj28rzVKs+ 5FEa+IRDYsA/B6jUs5rwlzB07TWx8SZY5kLNX3IOzegOBnCw5Sllrm2rEdc3GCG2 ciQGC14wlCkCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBq0yhPtxNdAfZlNgRw06cD X5B1lmZS/C+N12B8a5R9fpqaZ4VX5jbFZT/rxs8S/G9G6ch+b+RQHEW9L0D8yjc1 5l3Mii4eWH7mbjJBaJ7rDSRvQomYOIqIs+FZrXqmLdn75YNIc+wdrZcNiC6u
34、d1Le cue+/sO7PKCPa+iZVSbjgQ= -END CERTIFICATE-,接上頁,- Server certificate subject=/C=CN/ST=beijing/L=beijing/O=f5ltm/OU=20100701/CN=B3400-R17-S20 issuer=/C=CN/ST=beijing/L=beijing/O=f5ltm/OU=20100701/CN=B3400-R17-S20 - Acceptable client certificate CA names /C=-/ST=WA/L=Seattle/O=MyCompany/OU=12777748
35、28/CN=localhost.localdomain/emailAddress=rootlocalhost.localdomain /C=CN/ST=beijing/L=beijing/O=f5ltm/OU=20100701/CN=B3400-R17-S20 - SSL handshake has read 1040 bytes and written 1414 bytes - New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit Compression: zlib compression Expansion
36、: zlib compression SSL-Session: Protocol : TLSv1 Cipher : AES256-SHA Session-ID: 00DC03FFA492BE4C00A2D57043E5AFA6801FEE4E897483A60E464434039E4EE2 Session-ID-ctx: Master-Key: 8D0FF68C39573FE57B7018B9117F7FD04BEAF42033A5C3F2BBA0592BE022ED890E5AEA66F3473959D22B34DF12B42F0A Key-Arg : None Krb5 Principal
37、: None Compression: 1 (zlib compression) Start Time: 1278034050 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) - x2?O?M.?K-*,a.?0?Qh?gg?glllS?,看iqdump輸出的技巧,rootB3600-R18-S41:Active config # iqdump 61.61.61.200 3466:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certif
38、icate verify failed:s3_clnt.c:897: -第一行給出最終的SSL錯誤錯在哪！這很重要，例如上面信息說明，client提交證書后請求cert verify，但最終server認為verify出錯 （客戶端lgtmd上關于ltm的證書被刪除了-順延上面的ppt） - New, (NONE), Cipher is (NONE) SSL-Session: Protocol : TLSv1 Cipher : 0000 Session-ID: 1B7E30B22EF72147A34177B7DF5740B4123A0042EFDD94EA84C3C19FA9EB0AF7 Se
39、ssion-ID-ctx: Master-Key: Key-Arg : None Krb5 Principal: None Start Time: 1278042375 Timeout : 7200 (sec) Verify return code: 0 (ok) - 上面這一塊給出SSL的協商會話信息，如果這里的return code沒錯，往往意味著SSL握手過程沒錯，但不代表就真的SSL通信正常,看iqdump輸出的技巧-cont.,見備注 基于P62所述環境的輸出,思想:bgi3d作為SSL server端,gtmd作為ssl client端，從SSL握手驗證角度考慮證書驗證關系： GT
40、M自己驗證自己不用考慮根證問題,Some case,C713247,v10.1（ltm combo gtm）,不要將ltm中不存在的vs （即generic host）定義到gtm的server下，會導致一些其他的vs flapping. C681773,v10.1某種情形下同步觸發后會導致wideip文件出現亂字符，Enhotfix C708249 v10.1作為委派的NS record建立后，GUI不能點擊進去查看該記錄，顯示“Resolver returned no such record.” 已知問題，以后版本修復 SOL12062 不要在gtm的vs層面設置snmp monitor,SG gtm training 2011、7.7,tcpdump -ni 0.0:nnn s0 port 53 tcpdump -ni tmm0 s0 port 53 Tmm0可以抓取從tmm發給bind的包,
GTMEssentials_V1.5.2.ppt
