特定Web URL的使用者資料瀏覽問題疑難解答
簡介
本檔案介紹所有統一資源定位器(URL)在4G網路上的使用者資料瀏覽問題。
必要條件
思科建議您瞭解以下節點的功能：
- 服務封包資料閘道(SPGW)
- 控制與使用者平面分離(CUPS)
症狀的確定
注意：在開始測試和日誌收集之前，必須驗證這些詳細資訊。
1.檢查哪種資料型別是問題：IPv4/IPv6/IPv4v6
2.檢查問題是否與任何特定接入點名稱(APN)或所有APN有關，因為此問題可能與特定APN有關。
3.檢查問題是否針對特定的Web URL或多個URL。
4.檢查URL是企業URL/客戶應用URL還是某個常規服務URL，同時檢查問題是否與特定VPN有關。
5.檢查直接從瀏覽器訪問URL時或訪問Web應用本身時是否出現問題。
6.檢查問題是否在性質上是間歇性的（如重新啟動聽筒或刷新Web URL後開始工作），或者問題是否一致，即使重新啟動聽筒後也無法工作。
7.檢查觀察到的拒收原因以及哪個評級組。
日誌收集/測試
注意：對於此類問題，您必須對有問題的使用者IMSI執行即時線上故障排除，您必須相應地收集日誌/跟蹤。
繼續測試和日誌收集之前：
Flush the subscriber from the node and also clear browsing history/database from testing user handset so that it can freshly attach
clear subscriber imsi <IMSI number> ------------------ to be executed in the node to clear the subscriber
- 首先使用一種PDP型別（例如IPv4）進行測試，您可以在其中發現問題。
- 啟用這些調試日誌並記錄putty會話。確保會話不能終止（按Tab/每隔幾分鐘輸入一次，這樣會話就不會終止）。
On SPGW:
logging filter active facility sessmgr level debug
logging filter active facility acsmgr level debug
logging filter active facility npumgr-acl level debug
logging filter active facility firewall level debug
logging filter active facility vpn level debug
logging filter active facility vpnmgr level debug
logging active ---------------- to enable the logging
after 5 mins
no logging active ---------------- to disable the logging
On CP:
logging filter active facility sessmgr level debug
logging filter active facility sxdemux level debug
logging filter active facility firewall level debug
logging filter active facility vpn level debug
logging filter active facility vpnmgr level debug
logging active ---------------- to enable the logging
after 5 mins
no logging active ---------------- to disable the logging
On UP:
logging filter active facility sessmgr level debug
logging filter active facility sxdemux level debug
logging filter active facility npumgr-acl level debug
logging filter active facility firewall level debug
logging filter active facility vpn level debug
logging filter active facility vpnmgr level debug
logging active ---------------- to enable the logging
no logging active ---------------- to disable the logging
Note :: These logging has to be enabled for short time depending on the CPU utilization because it
increase the utilization so while enabling logging need to keep a watch on CPU
3.導航到配置模式，然後為訂戶啟用日誌記錄監視器。
config
logging monitor msid <imsi>
end
4.開啟另一台終端，記錄putty會話，然後開始使用詳細程度5監視使用者並啟用以下選項：
SPGW:
Press + for times then it collects the logs verbosity 5 logs then select next options
+++++
X, A, Y, 19, 33, 34, 35, 22, 26, 75
Once option 75 is pressed then select 3,4,8 then press esc
CUPS::
on CP:
monitor subscriber imsi <IMSI> +++++ S, X,A,Y,56,26,33,34,19,37,35,88,89
on UP:
monitor subscriber imsi <IMSI> +++++ S,X,A,Y,56,26,33,34,19,37,35,88,89
5.連線訂閱者並連續瀏覽URL 3到5分鐘，瀏覽時多次執行這些命令並記錄同一條的putty會話。
ON SPGW/SAEGW:
show subscriber full imsi <>
show active-charging session full imsi <>
show subscriber pgw-only full imsi <>
show subscriber sgw-only full imsi <>
show subscribers data-rate summary imsi <>
show ims-authorization sessions full imsi <>
show subscribers debug-info msid <>
On CP node:
Show subscriber full imsi <imsi>
Show active-charging session full imsi <imsi>
show subscribers pgw-only full imsi <>
show subscribers sgw-only full imsi <>
show session subsystem facility sessmgr instance <> verbose
show logs
On UP node:
show sub user-plane-only full callid <>
show sub user-plane-only callid <> urr full all
show sub user-plane-only callid <> far full all
show sub user-plane-only callid <> pdr full all
show subscribers user-plane-only callid <> far all
show subscribers user-plane-only callid <> far
show subs data-rate call <callid>
show subscribers user-plane-only flows
show user-plane-service statistics all
show user-plane-service statistic rulebase name <rulebase_name>
6.瀏覽5分鐘後，執行 no logging active 在步驟3中開啟的另一個終端中。
7.禁用訂閱伺服器的日誌記錄監視器。
Config
no logging monitor msid <imsi>
end
8.不要停止mon sub並使其運行，直到您收集完編號跟蹤為止，但請關注CPU。
9.執行此命令以獲取訂戶的呼叫方ID，並記錄此呼叫的putty會話。
Show subscriber full imsi <imsi>. -à get the call id
show logs callid <call_id>
show logs
如果來電者ID存在，那麼使用者會話日誌顯然已收集，如果沒有，則需要再次運行該日誌。
已執行故障排除
- 對Web URL伺服器IP地址執行ping操作並檢查是否存在任何丟包情況。
ping
------------ from Gi context
--- ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 12160ms. >.>>>> There are packet drops, now we need to check were it is dropping
2.執行 traceroute 並檢查是否存在任何可達性問題。
traceroutesrc
Ex: traceroute 10.52.5.49 src 10.203.144.8
3.檢查使用者統計資訊，以便檢查資料包丟棄情況。
Show subscriber full imsi
input pkts: 455 output pkts: 474
input bytes: 75227 output bytes: 103267
input bytes dropped: 0 output bytes dropped: 0
input pkts dropped: 0 output pkts dropped: 0
input pkts dropped due to lorc : 0 output pkts dropped due to lorc : 0
input bytes dropped due to lorc : 0
in packet dropped suspended state: 0 out packet dropped suspended state: 0
in bytes dropped suspended state: 0 out bytes dropped suspended state: 0
in packet dropped sgw restoration state: 0 out packet dropped sgw restoration state: 0
in bytes dropped sgw restoration state: 0 out bytes dropped sgw restoration state: 0
pk rate from user(bps): 18547 pk rate to user(bps): 25330
ave rate from user(bps): 6182 ave rate to user(bps): 8443
sust rate from user(bps): 5687 sust rate to user(bps): 7768
pk rate from user(pps): 13 pk rate to user(pps): 14
ave rate from user(pps): 4 ave rate to user(pps): 4
sust rate from user(pps): 4 sust rate to user(pps): 4
link online/active percent: 92
ipv4 bad hdr: 0 ipv4 ttl exceeded: 0
ipv4 fragments sent: 0 ipv4 could not fragment: 0
ipv4 input acl drop: 0 ipv4 output acl drop: 0
ipv4 bad length trim: 0
ipv6 input acl drop: 0 ipv6 output acl drop: 0
ipv4 input css down drop: 0 ipv4 output css down drop: 0
ipv4 input css down drop: 0 ipv4 output css down drop: 0
ipv4 output xoff pkts drop: 0 ipv4 output xoff bytes drop: 0
ipv6 output xoff pkts drop: 0 ipv6 output xoff bytes drop: 0
ipv6 input ehrpd-access drop: 0 ipv6 output ehrpd-access drop: 0
input pkts dropped (0 mbr): 0 output pkts dropped (0 mbr): 0
ip source violations: 0 ipv4 output no-flow drop: 0
ipv6 egress filtered: 0
ipv4 proxy-dns redirect: 0 ipv4 proxy-dns pass-thru: 0
ipv4 proxy-dns drop: 0
ipv4 proxy-dns redirect tcp connection: 0
ipv6 bad hdr: 0 ipv6 bad length trim: 0
ip source violations no acct: 0
ip source violations ignored: 0
dormancy total: 0 handoff total: 0
ipv4 icmp packets dropped: 0
APN AMBR Input Pkts Drop: 0 APN AMBR Output Pkts Drop: 0
APN AMBR Input Bytes Drop: 0 APN AMBR Output Bytes Drop: 0
APN AMBR UE Overload Input Pkts Drop: 0 APN AMBR UE Overload Output Pkts Drop: 0
APN AMBR UE Overload Input Bytes Drop: 0 APN AMBR UE Overload Output Bytes Drop: 0
Access-flows:0
Num Auxiliary A10s:0
4.檢查show active charging輸出以瞭解訂戶流量影響。
Show active-charging session full imsi <imsi num>
PP Dropped Packets: 0
CC Dropped Uplink Packets: 0 CC Dropped Uplink Bytes: 0
CC Dropped Downlink Packets: 0 CC Dropped Downlink Bytes: 0
5.檢查show active charging命令輸出，以瞭解ECS/ACS級資料包丟棄情況，並檢查是否存在任何資料包丟棄。然後在配置中檢查所配置的操作。
Show active-charging session full imsior show sub user-plane-only full callid <>
Ruledef Name Pkts-Down Bytes-Down Pkts-Up Bytes-Up Hits Match-Bypassed
-------------------- ---------- ---------- ---------- ---------- ---------- --------------
dns_free_covid 4 428 4 340 8 0
icmpv6 0 0 5 1423 5 0
ip-pkts 479 103670 432 74488 764 429
6.檢查DNS解析是否成功。如果成功，則DNS沒有問題。
7.檢查使用者裝置(UE)與伺服器之間的TCP連線是否成功建立。
8.如果在上述任何步驟中均未觀察到丟包，則節點中不存在任何問題。
封包捨棄
1.檢查訂戶版本統計資訊，以確定您是否遇到類似於此處所示的丟包情況。
Total Dropped Packets : 132329995
Total Dropped Packet Bytes: 14250717212
Total PP Dropped Packets : 0
Total PP Dropped Packet Bytes: 0
R7Gx Rule-Matching Failure Stats:
Total Dropped Packets : 871921
Total Dropped Packet Bytes : 86859232
P2P random drop stats:
Total Dropped Packets : 0
Total Dropped Packet Bytes : 0
2.檢查show subscriber輸出中觀察到的故障百分比。如果封包捨棄率小於1%，這很可能是僥倖，而且沒有影響。
input pkts: 455 output pkts: 474
input bytes: 75227 output bytes: 103267
input bytes dropped: 0 output bytes dropped: 0
input pkts dropped: 0 output pkts dropped: 0
3.如果您注意到RX評級組中的資料包丟棄和ITC資料包丟棄，則這很可能是由於頻寬問題和使用者包過期造成的。
ITC Packets Drop: 47235019
4.在增強計費服務(ECS)級別，您必須檢查/驗證ECS配置，以瞭解如何定義規則/計費操作/規則庫，以及您是否具有任何阻塞因素。在ECS級別有不同型別的丟棄，根據型別的丟棄，您需要繼續執行下一個行動計畫。
5.正在傳遞但未處理的封包大小的MTU大小。
6.從TCP轉儲/使用者級跟蹤可以識別資料包被丟棄的中間路徑問題。
對於此類問題，恢復行動計畫是不相同的，因為它根據問題的模式而有所不同。
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
1.0 |
27-Jun-2023 |
初始版本 |
意見