《GTMEssentials_V1.5.2.ppt》由會(huì)員分享，可在線閱讀，更多相關(guān)《GTMEssentials_V1.5.2.ppt（83頁珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。
1、GTM Essentials,Prepared and presented by: LinJing V1.5.2 ,Updates,Updates,說明,該P(yáng)PT適合對(duì)GTM/LTM已經(jīng)有一定基礎(chǔ)同學(xué) 如無GTM知識(shí)，建議首先閱讀metoo的GTM安裝指南-V2.0bible啊，下面連接是v1.0 請(qǐng)到 錯(cuò)別字請(qǐng)自行糾正 本文不是bible，F(xiàn)5軟件日新月異，可能部分內(nèi)容需基于指定版本 問題請(qǐng)?jiān)谔酉轮赋霾⒂懻?，感謝,GTM關(guān)鍵點(diǎn),GTM中的對(duì)象關(guān)系 Listener決策策略 證書交換機(jī)制 Add new GTM to sync group八步法 iquery結(jié)構(gòu)關(guān)系 gtmd、big3d的選
2、舉 部分重要算法 Monitor及path metric collection 私有地址server情形下的NAT處理 Named.conf,zone,wideip.conf,persistence的同步 ZoneRunner ;,ZoneRunner & BIND,由于使用動(dòng)態(tài)更新方式控制zone，所以不要輕易嘗試手工編輯zone文件 Wideip,zonerunner界面的配置修改，并不會(huì)立即同步到對(duì)應(yīng)的zone文件中 這些變化臨時(shí)存在于/var/named/config/namedb下對(duì)應(yīng)zone的jnl文件中 BIND 的named.conf文件存放于/var/named/config
3、目錄下，zonerunner界面也可以編輯 F5的BIND默認(rèn)不提供遞歸功能,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,日志檢查及排錯(cuò),Gtm日志保存在/var/log/gtm中 當(dāng)需深入排錯(cuò)時(shí)，可以打開gtmd的一些高級(jí)日志 GTM.QueryLogging = enable /default disable GTM.DebugProbeLogging=enable /default disable Log.GTM.Level = debug /default notice Log.Big3d.Level = debug /defualt notic,日志檢查及排錯(cuò),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),日志檢查及排錯(cuò),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),日志檢查及排錯(cuò),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被發(fā)現(xiàn)，如果有此日志說明gtm自己沒有被加入到server中,日志檢查及排錯(cuò),Iqdump peer_ipaddress sync_group_name 不跟sync_group_name只能看到基本的心跳和server統(tǒng)計(jì)信息，無法看到vs信息 Dig或nslookup得到類似AUTHORITY: 2的flag，意味著結(jié)果是由BIND給出。,日志檢查及排錯(cuò),某個(gè)object由哪個(gè)big3
14、d負(fù)責(zé)探測(cè)是可能不斷變化的，這在某種情形下或許會(huì)導(dǎo)致server狀態(tài)的flapping 在1500平臺(tái)上，Big3d，gtmd競(jìng)爭(zhēng)20%的CPU資源，因此大量的path探測(cè)可能會(huì)導(dǎo)致性能問題，可以關(guān)閉GTM上的big3d對(duì)path的探測(cè)功能，在加gtm到server的時(shí)候有iquery option，關(guān)閉path探測(cè)即可,日志檢查及排錯(cuò),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,日志檢查及排錯(cuò),wideip層面選擇GA，GA所要選擇的pool變紅，但是該pool里的某個(gè)算法可以實(shí)現(xiàn)解析出一個(gè)IP地址，測(cè)試GTM依然會(huì)選擇該P(yáng)OOL。 例如pool里的算法是fall back ip/retu
16、rn to dns. 因此如果要在WIDEIP層面做GA，應(yīng)該不容許 pool層面總是可以得到結(jié)果 的情況出現(xiàn)。 Pool中算法選擇none是控制算法跳過或跳躍到下一個(gè)可用pool的好方法。,Topology, ,Topology都miss的情況下 (注意備注),如果wideip層面的top算法都failed，則行為如下（V9.3.1 wideip下有2個(gè)pool）： 1.選擇第一個(gè)可用的pool 2.按照被選擇的pool里所設(shè)定的算法來作為pool間的算法，例如pool中是的第一算法是RR，則在POOL間輪詢。 3。如果被選擇pool的第一算法failed，則使用第二算法，因此類推。 4。如
17、果被選擇pool的算法所決定的最終算法是return to dns 則意味著這個(gè)pool不可用，此時(shí)return to到wideip上，而不是真正的BIND，即又會(huì)回到wideip層面選取下一個(gè)可用pool并按照該pool設(shè)定的算法執(zhí)行，如果這個(gè)pool的算法最終又是return to dns，就會(huì)真正的return to BIND.,與排錯(cuò)相關(guān)的更多資源,GTM配置關(guān)鍵點(diǎn)及排錯(cuò)總結(jié).pptx 這篇文檔在給channel 的資料U盤上有 超超的GTM 2 days training - v2.pptx GTM部署模型方案討論 ,關(guān)于開GTM CASE,NSE雖然通過wideip.conf可以大
18、體復(fù)現(xiàn)一個(gè)網(wǎng)絡(luò)結(jié)構(gòu)，但是這往往不全面，提供全面清晰的GTM 網(wǎng)絡(luò)結(jié)構(gòu)圖往往非常有助于解決問題 L3的服務(wù)，記得一定先自我仔細(xì)排查并搜集有效的信息及證據(jù)，準(zhǔn)確描述問題現(xiàn)象及時(shí)間是關(guān)鍵 提供gtmd的debug及gtmd的probe debug日志信息往往更有效 Askf5,devcentral,擁有很多優(yōu)秀的資源，常規(guī)問題或許別人已經(jīng)見過 出現(xiàn)問題前做過什么，往往會(huì)有驚奇發(fā)現(xiàn) 相互理解更能快速解決問題,CASE-cert troubleshooting-clue,Iquery通信正常時(shí)候，gtmd,big3d之間的SSL過程： 以GTM和LTM為例，gtm要用其gtmd主動(dòng)發(fā)起一個(gè)SSL到LTM
19、上的big3d的協(xié)商，此過程中，GTM作為ssl的client端，ltm作為ssl的server端。這是一個(gè)雙向SSL認(rèn)證過程： GTM(gtmd)ssl client-LTM(big3d)ssl server 那么： 1.Gtmd發(fā)client hello 2.big3d響應(yīng)server hello 并發(fā)送服務(wù)端cert （httpd證書），cert request（攜帶可接受的CA-從client.crt中讀?。┙ogtmd 3.Gtmd得到big3d發(fā)來的證書后，用其server.crt來校驗(yàn)big3d發(fā)來的證書。并看big3d發(fā)來的可接受CA中是否有自己device cert所對(duì)應(yīng)的CA
20、。然后gtmd發(fā)送客戶端cert（httpd證書）給big3d，并發(fā)送cert verify申請(qǐng) 4.big3d端檢驗(yàn)gtmd發(fā)來的客戶端證書并做hash校驗(yàn) 如果一切OK，則通過,正常時(shí)模擬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端發(fā)出的證書信息 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-,正常時(shí)模擬iquery 連接Cont.,- Server certificate -服務(wù)端證書信息及其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 -服務(wù)端發(fā)出的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?. -握手通過后傳出的壓縮報(bào)文,CASE1：cert troubleshooting -clue,環(huán)境：一個(gè)GTM，一個(gè)LTM，bigip_add同步證書后，應(yīng)該在GTM的server.crt里有GTM+LTM的證書，在LTM的client.crt里有GTM+LTM的證書 確認(rèn)證書同步?jīng)]錯(cuò)，iquery正確，LTM也綠色 在GTM的trusted server certificate中刪掉LTM的證書，然后重啟LTM的big3d，使iquery重連。 在GTM上openssl發(fā)起連接測(cè)試，得到下頁結(jié)果,在gtm-server.crt中刪除ltmcert測(cè)試,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錯(cuò)誤錯(cuò)在哪！這很重要，例如上面信息說明，client提交證書后請(qǐng)求cert verify，但最終server認(rèn)為verify出錯(cuò) （客戶端lgtmd上關(guān)于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的協(xié)商會(huì)話信息，如果這里的return code沒錯(cuò)，往往意味著SSL握手過程沒錯(cuò)，但不代表就真的SSL通信正常,看iqdump輸出的技巧-cont.,見備注 基于P62所述環(huán)境的輸出,思想:bgi3d作為SSL server端,gtmd作為ssl client端，從SSL握手驗(yàn)證角度考慮證書驗(yàn)證關(guān)系： GT
40、M自己驗(yàn)證自己不用考慮根證問題,Some case,C713247,v10.1（ltm combo gtm）,不要將ltm中不存在的vs （即generic host）定義到gtm的server下，會(huì)導(dǎo)致一些其他的vs flapping. C681773,v10.1某種情形下同步觸發(fā)后會(huì)導(dǎo)致wideip文件出現(xiàn)亂字符，Enhotfix C708249 v10.1作為委派的NS record建立后，GUI不能點(diǎn)擊進(jìn)去查看該記錄，顯示“Resolver returned no such record.” 已知問題，以后版本修復(fù) SOL12062 不要在gtm的vs層面設(shè)置snmp monitor,SG gtm training 2011、7.7,tcpdump -ni 0.0:nnn s0 port 53 tcpdump -ni tmm0 s0 port 53 Tmm0可以抓取從tmm發(fā)給bind的包,
GTMEssentials_V1.5.2.ppt
