LTEでのユーザブラウジングの問題のトラブルシューティング

はじめに

このドキュメントでは、4Gネットワークでのユーザデータの参照に関する問題について説明します。

前提条件

これらのノードの機能に関する知識があることが推奨されます

1. Serving Packet Data Gateway(SPGW)

2.コントロールプレーンとユーザプレーンの分離(CUPS)

症状

テストとログ収集を開始する前に、次の説明を確認する必要があります。

1.チェックの問題は、パケットデータネットワーク(PDN)のデータタイプ：IPv4/IPv6/IPv4v6

2.問題が特定のアクセスポイント名(APN)に関連している可能性があるため、すべてのAPNに関する問題であることを確認します。

3. URLがエンタープライズURL/カスタマーアプリURLであるか、または通常のサービスURLであり、問題が特定のVPNにあるかどうかを確認します。

4.ブラウザから直接URLにアクセスする際、またはWebアプリ自体にアクセスする際に問題が発生するかどうかを確認します。

5.ハンドセットの再起動後やWeb URLの更新などの問題が断続的に発生しますか。それとも、問題が継続していて、ハンドセットの再起動後も問題が解決しないのでしょうか。

6.観察された拒絶理由と評価グループを確認します。

ログ収集/テスト

テストとログ収集に進む前に。

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

1.任意のPDNタイプの加入者のテストを開始します。

2. puttyセッションをログに記録し、冗長レベル5でサブスクライバの監視を開始して、このオプションを有効にします。

SPGW:
Press + for times then it collects the logs verbosity 5 logs then select next options
+++++
S,X,A,Y,56,26,33,34,19,37,35,88,89
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

3.これらのデバッグログを有効にして、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
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
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

4.モードを構成します。サブスクライバーのログモニターを有効にしてください

config
logging monitor msid <imsi>
end

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  ステップ4で開いた端末で

7.サブスクライバのロギングモニタを無効にします。

Config
no logging monitor msid <imsi>

8.このコマンドを実行して、サブスクライバのコールIDを取得し、puttyセッションもログに記録します。

Show subscriber full imsi <imsi>.  --> to get the call id
show logs callid <call_id>
show logs

9.コールIDが存在する場合、サブスクライバセッションログが収集されていなければ、再実行する必要があることは明らかです。

分析

1. DNS解決が成功したかどうかを確認します。これが成功した場合、DNSに問題はありません。

DNS解決トレース

2. サブスクライバレベルの統計情報をチェックして、パケットドロップを確認します。

SPGW/CP:
Show subscriber full imsi 
    
     
     
 
     
CUPS UP: 
    
show user-plane-only 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

3. show active chargingコマンドの出力でECS/ACSレベルのパケットドロップをチェックし、パケットドロップがないかどうかをチェックしてから、設定で設定されているアクションを確認します。

Show active-charging session full imsi 
     
       or 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    

4. UEとサーバ間でTCP接続が正常に確立されていることを確認します。

5.これらの手順のいずれかでドロップが観察されない場合、ノードに問題はありません。

パケットドロップ

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レベルでは、DPI設定（ルール定義、課金アクション、ルールベースを含む）を検証して、ブロック要因が存在するかどうかを判断することが重要です。ECSレベルではさまざまなタイプのドロップがあり、次のアクションは発生したドロップの特定のタイプによって異なります。

5.渡され、処理されないパケットサイズのMTUサイズ。

6.パケットがドロップされる中間パスの問題は、TCPダンプ/ユーザレベルのトレースから特定できます。

回復アクションプランは、問題のパターンによって異なるため、このタイプの問題では同じではありません。