キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
3745
閲覧回数
5
いいね!
1
コメント
yushimaz
Cisco Employee
Cisco Employee

はじめに

ACI に関しては、ACI How To というポータルサイトに情報を集約しています。 そのため、設定やトラブルシューティング等、ACI に関する情報収集はまず、ACI How To をご参照ください。

このコンテンツも Atomic Counter の基本 というタイトルで同様の内容が掲載されています。 

1. Atomic Counter とは

 

Configure Atomic Counter Policies に "This feature allows you to monitor the traffic drops/excess packets on your fabric." という記載があることからわかるように、これは ACI Fabric 内の packet drop/excess を調べるための機能です。

 

Atomic Counter には、OnDemand Atomic Counter と OnGoing Atomic Counter の 2 種類があります。

 

OnDemand Atomic Counter には、下記のような様々な種類があります。 Default では動作しておらず、監視を行いたい EP-EP, EP-EPG 等を手動で設定する必要があります。 設定は Tenant > Troubleshoot Policies > Atomic Counter and Latency Policies より行います。 設定方法は Configure Atomic Counter Policies に記載されているのでここでは省略します。

 

These types of on-demand atomic counter policies can be configured:

EP to EP
EP to EPG
EP to Ext
EPG to EP
EPG to EPG
EPG to IP
Ext to IP
IP to EPG
The meaning of each acronym is as follows:

EP - Endpoint
EPG - Endpoint Group
Ext - External Network
IP - IP address
Configure Atomic Counter Policies - Cisco

 

Screen Shot 2018-01-26 at 11.20.41.png

 

 

OnGoing Atomic Counter は、Traffic Map とも呼ばれる、Switch(TEP) 間の drop/excess を監視している機能です。 この機能は常に有効になっています。

Operations > Visualization > Atomic Counter で確認できます。

 

Screen Shot 2018-01-26 at 11.21.12.png

 

上記 Settings を Click すると、mode を変更することができます。

 

Screen Shot 2018-01-26 at 19.02.54.png

 

Mode には、path と trail の 2 種類があります。 path mode では、leaf 間の通信を、trail mode では、leaf 間だけでなく、どの spine を経由したのかまでを監視しています。

ただし、trail mode は、TEP 数が 64 以上になると自動的に path mode になります。

 

 

 

A breakdown of per-spine traffic is available only when the number of TEPs, leaf or VPC, is less than 64.

Cisco Application Centric Infrastructure Fundamentals - Troubleshooting [Cisco Application Policy Infrastructure Cont…

 

 

 

Traffic map の色がついている箇所を click すると、下記のような画面になります。 今回は、左 103 - 上 104 の交わっている箇所を click しています。

(元の画面に戻る場合、Back To Traffic Map を click します。)

Screen Shot 2018-01-26 at 11.23.13.png

 

上記は、Tx Node 103, Rx Node 104、つまり node103 から送信され、node104 で受信した packet になります。

直近 30 sec では、node103 から 11 packet を送信、node104 が 11 packet を受信したことを示しています。

もし、node103 から 11 packet 送信、node104 が 10 packet を受信した場合、Drop Pkts が 1 増加します。

もし、node103 から 10 packet 送信、node104 が 11 packet を受信した場合、Excess Pkts が 1 増加します。

上記は node103 tx pkts = node104 rx pkts のため、drop は 0 になっています。

 

 

2. 注意事項

 

Atomic Counter には、様々な注意事項があります。 特に、NTP を使用していない場合や Full mesh ではない構成では、正常に動作しないため、注意が必要です。

また、

Guideline/Restriction が下記に記載されています。

 

 

Atomic Counters Guidelines and Restrictions

• Use of atomic countersis notsupported when the endpoints are in different tenants or in different contexts (VRFs) within the same tenant.

• In pure layer 2 configurations where the IP address is not learned (the IP address is 0.0.0.0), endpoint-to-EPG and EPG-to-endpoint atomic counter policies are not supported. In these cases, endpoint-to-endpoint and EPG-to-EPG policies are supported. External policies are virtual routing and forwarding (VRF)-based, requiring learned IP addresses, and are supported.

• When the atomic counter source or destination is an endpoint, the endpoint must be dynamic and not static. Unlike a dynamic endpoint (fv:CEp), a static endpoint (fv:StCEp) does not have a child object (fv:RsCEpToPathEp) that is required by the atomic counter.

• In a transit topology, where leaf switches are not in full mesh with all spine switches, then leaf-to-leaf (TEP to TEP) counters do not work as expected.

• For leaf-to-leaf (TEP to TEP) atomic counters, once the number of tunnels increases the hardware limit, the system changes the mode from trail mode to path mode and the user is no longer presented with per-spine traffic.

• The atomic counter does not count spine proxy traffic.

• Packets dropped before entering the fabric or before being forwarded to a leaf port are ignored by atomic counters.

• Packets that are switched in the hypervisor (same Port Group and Host) are not counted.

• Atomic counters require an active fabric Network Time Protocol (NTP) policy.

• Atomic counters work for IPv6 sources and destinations but configuring source and destination IP addresses across IPv4 and IPv6 addresses is not allowed.

• An atomic counter policy configured with fvCEp as the source and/or destination counts only the traffic that is from/to the MAC and IP addresses that are present in the fvCEp managed objects (MOs). If the fvCEp MO has an empty IP address field, then all traffic to/from that MAC address would be counted regardless of the IP address. If the APIC has learned multiple IP addresses for an fvCEp, then traffic from only the one IPaddress in the fvCEp MO itself is counted as previously stated. In order to configure an atomic counter policy to/from a specific IPaddress, use the fvIp MO asthe source and/or destination.

• If there is an fvIp behind an fvCEp, you must add fvIP-based policies and not fvCEp-based policies.

 

Using the Cisco APIC Troubleshooting Tools (page 12)

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/troubleshooting/b_APIC_Troubleshooting/b_APIC_…

 

 

 

3. Class/MO 確認

 

Atomic Counter で使用している class を調べてみます。 Configure Atomic Counter Policies - Cisco の REST API の設定例から、dbgac... という class 名であることが推測できますが、念のため、APIC Postman の紹介 で紹介されている APIC Postman を用い、keyword に atomic を用い、class を検索してみます。 予想通り dbgac という class がたくさん表示されました。

Screen Shot 2018-01-26 at 14.46.30.png

 

次に、visore (https://[apic address]/visore.html) で、dbgac と入力し、関連 class を検索してみます。 (3.0 より前の version では、候補が表示されないため、visore で keyword を入れて class 検索を行うことはできません。)

dbgAcPath(Rx/Tx) とか、dbgAcTrail(Rx/Tx) という class が確認できます。

 

Screen Shot 2018-01-26 at 14.47.36.png

 

そこで、dbgAcPath を表示すると、下記のような出力が確認できます。 下記例では、1 つの object の出力のみですが、下の方へ scroll していくと、全部で 16 個の object が確認できます。 (Total objects shown: 16)

これは、srcNodeId 103, dstNodeId 105 の object になります。 上の出力例は src: 103, dst: 104 なので、それを検索してみます。

 

Screen Shot 2018-01-26 at 14.48.05.png

 

visore の画面を scroll して探しても良いのですが、tool 紹介の意味もかねて、今回は moquery を用いて class を表示してみます。

特に難しいことはなく、apic に ssh login して、moquery -c [class 名] と入力するだけです。

表示の都合上、-f option を使用し、src: 103, dst: 104 の node の出力のみ取得しています。

 

 

apic1# moquery -c dbgAcPath -f 'dbg.AcPath.dstNodeId=="104" and dbg.AcPath.srcNodeId=="103"'

Total Objects shown: 1

 

 

# dbg.AcPath

srcNodeId : 103

dstNodeId : 104

childAction :

dn : dbgs/ac/path-103-to-104

dropPkt : 0

dropPktPercentage : 0

dstNodeId2 : 0

excessPkt : 0

excessPktPercentage : 0

lcOwn : local

modTs : 2018-03-28T06:56:37.943+09:00

monPolDn : uni/fabric/monfab-default

pathType : nodeToNode

rn : path-103-to-104

rxPkt : 11

seqNo : 226686

skip : 0

srcNodeId2 : 0

status :

suspect : no

totDropPkt : 87909

totDropPktPercentage : 6

totExcessPkt : 1099

totExcessPktPercentage : 0

totRxPkt : 1227071

totTxPkt : 1313881

ts : 2018-01-26T14:56:50.846+09:00

txPkt : 11

 

 

apic1#

 

 

Traffic map と同じような出力が確認できました。

ちなみに、visore, moquery 共に、leaf switch に対して実行することも可能です。

https://[switch address]/visore.html で visore に、ssh で switch に login することで、moquery を実行することができます。

ただし、apic と switch は全く同じ object を持っているわけではないため、同じ class で検索しても見つからないことがあります。

dbgAcPath もその 1 つです。

 

 

 

fab3-leaf3# moquery -c dbgAcPath

No Mos found

fab3-leaf3#

 

 

これは、node103 tx, node104 rx の情報をそれぞれの leaf switch から取得し、その情報を元に作られたのが dbgAcPath の mo だからです。

dbgAcPathRx, dbgAcPathTx は、apic/switch 両方にあるので、node 103 で dbgAcPathTx を node 104 で dbgAcPathRx を取得してみます。

(src: 103, dst: 104 で filter しています。)

 

 

 

fab3-leaf3# moquery -c dbgAcPathTx -f 'dbg.AcPathTx.dstNodeId=="104" and dbg.AcPathTx.srcNodeId=="103"'

Total Objects shown: 2

 

 

# dbg.AcPathTx

srcNodeId : 103

dstNodeId : 104

admitB : 0

admitP : 0

admitTotB : 14472

admitTotP : 76

childAction :

dn : ndbgs/ac/og/b1/pathTx-103-to-104

dropB : 0

dropP : 0

dropTotB : 0

dropTotP : 0

dstNodeId2 : 0

firstCollTs : 2018-01-23T09:04:10.211+09:00

lastCollTs : 2018-01-26T14:56:10.309+09:00

lcOwn : local

modTs : 2018-03-28T06:55:55.642+09:00

pathDn :

pathType : nodeToNode

rn : pathTx-103-to-104

seqNo : 4673

srcNodeId2 : 0

status :

 

 

# dbg.AcPathTx

srcNodeId : 103

dstNodeId : 104

admitB : 3432

admitP : 11

admitTotB : 14562876

admitTotP : 49155

childAction :

dn : ndbgs/ac/og/b0/pathTx-103-to-104

dropB : 0

dropP : 0

dropTotB : 0

dropTotP : 0

dstNodeId2 : 0

firstCollTs : 2018-01-23T09:04:40.215+09:00

lastCollTs : 2018-01-26T14:56:40.313+09:00

lcOwn : local

modTs : 2018-03-28T06:56:25.646+09:00

pathDn :

pathType : nodeToNode

rn : pathTx-103-to-104

seqNo : 4673

srcNodeId2 : 0

status :

 

 

fab3-leaf3#

 

fab3-leaf4# moquery -c dbgAcPathRx -f 'dbg.AcPathRx.dstNodeId=="104" and dbg.AcPathRx.srcNodeId=="103"'

Total Objects shown: 2

 

 

# dbg.AcPathRx

srcNodeId : 103

dstNodeId : 104

admitB : 3432

admitP : 11

admitTotB : 14559636

admitTotP : 49144

childAction :

dn : ndbgs/ac/og/b0/pathRx-103-to-104

dropB : 0

dropP : 0

dropTotB : 0

dropTotP : 0

dstNodeId2 : 0

firstCollTs : 2018-01-23T09:04:40.333+09:00

lastCollTs : 2018-01-26T14:56:40.345+09:00

lcOwn : local

modTs : 2018-03-28T06:56:25.677+09:00

pathDn :

pathType : nodeToNode

rn : pathRx-103-to-104

seqNo : 4673

srcNodeId2 : 0

status :

 

 

# dbg.AcPathRx

srcNodeId : 103

dstNodeId : 104

admitB : 0

admitP : 0

admitTotB : 14472

admitTotP : 76

childAction :

dn : ndbgs/ac/og/b1/pathRx-103-to-104

dropB : 0

dropP : 0

dropTotB : 0

dropTotP : 0

dstNodeId2 : 0

firstCollTs : 2018-01-23T09:05:10.319+09:00

lastCollTs : 2018-01-26T14:56:10.341+09:00

lcOwn : local

modTs : 2018-03-28T06:55:55.673+09:00

pathDn :

pathType : nodeToNode

rn : pathRx-103-to-104

seqNo : 4672

srcNodeId2 : 0

status :

 

 

fab3-leaf4#

 

 

それぞれ、dn に b0, b1 という値を持つ object が表示されます。 (data の不整合が起きないよう、bank0, bank1 という 2 つの object を交互に使用しています。)

これは何回か同じ command を実行し、この object の片方が 30 秒ごとに更新されていくことからも確認できます。

14:56:10 に bank1 が、14:56:40 に bank0 が、14:57:10 に bank1 が、14:57:40 に bank0 が... のように 30 秒間の統計情報が順番に更新されます。

 

apic でも同様の出力が確認できますが、user がどちらの bank を使用しているか意識しなくても良いように、さらにもう 1 つ object があります。

moquery -d dbgs/ac/path-103-to-104/pathTx-103-to-104 のように、class ではなく、dn を指定すれば user は、常に最新の情報を取得することができます。

 

 

apic1# moquery -c dbgAcPathTx -f 'dbg.AcPathTx.dstNodeId=="104" and dbg.AcPathTx.srcNodeId=="103"'

Total Objects shown: 3

 

 

# dbg.AcPathTx

srcNodeId : 103

dstNodeId : 104

admitB : 0

admitP : 0

admitTotB : 14472

admitTotP : 76

childAction :

dn : topology/pod-1/node-103/ndbgs/ac/og/b1/pathTx-103-to-104

dropB : 0

dropP : 0

dropTotB : 0

dropTotP : 0

dstNodeId2 : 0

firstCollTs : 2018-01-23T09:04:10.211+09:00

lastCollTs : 2018-01-26T14:56:10.309+09:00

lcOwn : local

modTs : 2018-03-28T06:55:55.642+09:00

pathDn :

pathType : nodeToNode

rn : pathTx-103-to-104

seqNo : 4673

srcNodeId2 : 0

status :

 

 

# dbg.AcPathTx

srcNodeId : 103

dstNodeId : 104

admitB : 3432

admitP : 11

admitTotB : 14562876

admitTotP : 49155

childAction :

dn : topology/pod-1/node-103/ndbgs/ac/og/b0/pathTx-103-to-104

dropB : 0

dropP : 0

dropTotB : 0

dropTotP : 0

dstNodeId2 : 0

firstCollTs : 2018-01-23T09:04:40.215+09:00

lastCollTs : 2018-01-26T14:56:40.313+09:00

lcOwn : local

modTs : 2018-03-28T06:56:25.646+09:00

pathDn :

pathType : nodeToNode

rn : pathTx-103-to-104

seqNo : 4673

srcNodeId2 : 0

status :

 

 

# dbg.AcPathTx

srcNodeId : 103

dstNodeId : 104

admitB : 3432

admitP : 11

admitTotB : 14562876

admitTotP : 49155

childAction :

dn : dbgs/ac/path-103-to-104/pathTx-103-to-104

dropB : 0

dropP : 0

dropTotB : 0

dropTotP : 0

dstNodeId2 : 0

firstCollTs : 2018-01-23T09:04:40.215+09:00

lastCollTs : 2018-01-26T14:56:40.313+09:00

lcOwn : local

modTs : 2018-03-28T06:56:25.785+09:00

pathDn :

pathType : nodeToNode

rn : pathTx-103-to-104

seqNo : 4673

srcNodeId2 : 0

status :

 

 

apic1#

apic1# moquery -c dbgAcPathRx -f 'dbg.AcPathRx.dstNodeId=="104" and dbg.AcPathRx.srcNodeId=="103"'

Total Objects shown: 3

 

 

# dbg.AcPathRx

srcNodeId : 103

dstNodeId : 104

admitB : 3432

admitP : 11

admitTotB : 14559636

admitTotP : 49144

childAction :

dn : topology/pod-1/node-104/ndbgs/ac/og/b0/pathRx-103-to-104

dropB : 0

dropP : 0

dropTotB : 0

dropTotP : 0

dstNodeId2 : 0

firstCollTs : 2018-01-23T09:04:40.333+09:00

lastCollTs : 2018-01-26T14:56:40.345+09:00

lcOwn : local

modTs : 2018-03-28T06:56:25.677+09:00

pathDn :

pathType : nodeToNode

rn : pathRx-103-to-104

seqNo : 4673

srcNodeId2 : 0

status :

 

 

# dbg.AcPathRx

srcNodeId : 103

dstNodeId : 104

admitB : 0

admitP : 0

admitTotB : 14472

admitTotP : 76

childAction :

dn : topology/pod-1/node-104/ndbgs/ac/og/b1/pathRx-103-to-104

dropB : 0

dropP : 0

dropTotB : 0

dropTotP : 0

dstNodeId2 : 0

firstCollTs : 2018-01-23T09:05:10.319+09:00

lastCollTs : 2018-01-26T14:56:10.341+09:00

lcOwn : local

modTs : 2018-03-28T06:55:55.673+09:00

pathDn :

pathType : nodeToNode

rn : pathRx-103-to-104

seqNo : 4672

srcNodeId2 : 0

status :

 

 

# dbg.AcPathRx

srcNodeId : 103

dstNodeId : 104

admitB : 0

admitP : 0

admitTotB : 0

admitTotP : 0

childAction :

dn : dbgs/ac/path-103-to-104/pathRx-103-to-104

dropB : 3432

dropP : 11

dropTotB : 14559636

dropTotP : 49144

dstNodeId2 : 0

firstCollTs : 2018-01-23T09:04:40.333+09:00

lastCollTs : 2018-01-26T14:56:40.345+09:00

lcOwn : local

modTs : 2018-03-28T06:56:25.817+09:00

pathDn :

pathType : nodeToNode

rn : pathRx-103-to-104

seqNo : 4673

srcNodeId2 : 0

status :

 

 

apic1#

 

ちなみに、最初に取得した dbgAcPath は、この dbgAcPathTx, dbgAcPathRx を用いて計算しています。

基本的に、

dbgAcPathTx admitP = dbgAcPath txPkt

bgAcPathRx admitP = dbgAcPath rxPkt

になり、

dbgAcPath txPkt > dbgAcPath rxPkt の場合、drop に

dbgAcPath txPkt < dbgAcPath rxPkt の場合、excess になります。

 

つまり、APIC は、送信側 leaf の tx と受信側 leaf の rx を比較し drop/excess を判断していて、実際に packet を drop させて counter を増加させているわけではありません。 そのため、NTP の設定を行なっていない等、時刻が不正確な場合、各 leaf switch が統計情報を取得している時刻が異なってしまうため、計算結果にズレが生じ、drop/excess が頻繁に発生するようになります。 Atomic Counter の Fault で、drop/excess が交互に出力されるような場合、設定/構成に問題がある場合や、表示上の不具合である場合やほとんどで、実際に packet drop/excess が発生していることはほとんどありません。

 

 

# dbg.AcPath

srcNodeId : 103

dstNodeId : 104

childAction :

dn : dbgs/ac/path-103-to-104

dropPkt : 0

dropPktPercentage : 0

dstNodeId2 : 0

excessPkt : 0

excessPktPercentage : 0

lcOwn : local

modTs : 2018-03-28T06:56:37.943+09:00

monPolDn : uni/fabric/monfab-default

pathType : nodeToNode

rn : path-103-to-104

rxPkt : 11

seqNo : 226686

skip : 0

srcNodeId2 : 0

status :

suspect : no

totDropPkt : 87909

totDropPktPercentage : 6

totExcessPkt : 1099

totExcessPktPercentage : 0

totRxPkt : 1227071

totTxPkt : 1313881

ts : 2018-01-26T14:56:50.846+09:00

txPkt : 11

 

 

 

 

# dbg.AcPathTx

srcNodeId : 103

dstNodeId : 104

admitB : 3432

admitP : 11

admitTotB : 14562876

admitTotP : 49155

childAction :

dn : dbgs/ac/path-103-to-104/pathTx-103-to-104

dropB : 0

dropP : 0

dropTotB : 0

dropTotP : 0

dstNodeId2 : 0

firstCollTs : 2018-01-23T09:04:40.215+09:00

lastCollTs : 2018-01-26T14:56:40.313+09:00

lcOwn : local

modTs : 2018-03-28T06:56:25.785+09:00

pathDn :

pathType : nodeToNode

rn : pathTx-103-to-104

seqNo : 4673

srcNodeId2 : 0

status :

 

 

# dbg.AcPathRx

srcNodeId : 103

dstNodeId : 104

admitB : 3432

admitP : 11

admitTotB : 14559636

admitTotP : 49144

childAction :

dn : dbgs/ac/path-103-to-104/pathRx-103-to-104

dropB : 0

dropP : 0

dropTotB : 0

dropTotP : 0

dstNodeId2 : 0

firstCollTs : 2018-01-23T09:04:40.333+09:00

lastCollTs : 2018-01-26T14:56:40.345+09:00

lcOwn : local

modTs : 2018-03-28T06:56:25.817+09:00

pathDn :

pathType : nodeToNode

rn : pathRx-103-to-104

seqNo : 4673

srcNodeId2 : 0

status :

 

 

4. おまけ

 

switch が apic に atomic counter の情報を送っている log は、svc_ifc_dbgrelem.log で、apic がその情報を処理した log は、svc_ifc_dbgr.bin.log で確認できます。

(apic は、leaf から情報が遅延して送られてくることを考慮して、10 秒後に処理を行い dbgs/ac/path-103-to-104 の情報を更新します。)

 

fab3-leaf3# cat /var/log/dme/log/svc_ifc_dbgrelem.log | grep 14:56:40 | head -1

8938||18-01-26 14:56:40.313+09:00||ifc_dbgrelem||DBG4||co=doer:0:0:0x32a9f:1||AC: Sending Bank 0 Data to IFC||../dme/svc/dbgrelem/src/gen/ifc/app/./imp/timers/AcExportToIFCTimerCbImp.cc||350 bico 35.312

fab3-leaf3#

 

fab3-leaf4# cat /var/log/dme/log/svc_ifc_dbgrelem.log | grep 14:56:40 | head -1

9019||18-01-26 14:56:40.345+09:00||ifc_dbgrelem||DBG4||co=doer:0:0:0x3041b:1||AC: Sending Bank 0 Data to IFC||../dme/svc/dbgrelem/src/gen/ifc/app/./imp/timers/AcExportToIFCTimerCbImp.cc||350 bico 35.344

fab3-leaf4#

 

apic1# cat /var/log/dme/log/svc_ifc_dbgr.bin.log | grep 14:56:50 | grep DDBEAAGcAaAA=

5143||18-01-26 14:56:50.979+09:00||mit_update||INFO||co=doer:32:3:0x2142978:15,dn='"DDBEAAGcAaAA="'||MIT MODIFY InstanceId: 4058:1400309 MoLocal || control bits = 104||../common/src/framework/./core/mo/Changer.cc||733

apic1#

 

 

5. おまけ2

 

Fault Code name
F1545 fltDbgAcPathAOnGoingAtomicCounterDropsMajor
F1546 fltDbgAcPathAOnGoingAtomicCounterDropsMinor
F1547 fltDbgAcPathAOnGoingAtomicCounterExcessMajor
F1548 fltDbgAcPathAOnGoingAtomicCounterExcessMinor
F1549 fltDbgAcTrailOnGoingAtomicCounterTrailDropsMajor
F1550 fltDbgAcTrailOnGoingAtomicCounterTrailDropsMinor
F1551 fltDbgAcTrailOnGoingAtomicCounterTrailExcessMajor
F1552 fltDbgAcTrailOnGoingAtomicCounterTrailExcessMinor

 

上記は、Atomic Counter に関する Fault 一覧です。

Path となっている F1545-F1548 が path mode で Trail となっている F1549 - F1552 が trail mode の fault です。

Drops となっている F1545, F1546, F1549, F1550 が dbgAcPath の txPkt > rxPkt となっている場合で、Excess となっている F1547, F1548, F1551, F1552 が dbgAcPath の txPkt < rxPkt となっている場合です。

Major となっている F1545, F1547, F1549, F1551 が drop/excess rate が 5% 以上で、Minor となっている F1546, F1548, F1550, F1552 が drop/excess rate 1-4% の場合です。

コメント

ネットワーク初心者にもとても分かりやすいです。ありがとうございます。

Getting Started

検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう

シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします