This document explains about how to collect useful logs for QoS troubleshooting. Please be careful because this document has been written based on test environment. So, it might not be applicable for production network.   1. Topology on the document The traffic generator keep sending frames with frame size L2 125bytes@10000pps as above directing arrow.   10000pps * (125*8) = 10000000bps(=10Mbps)   Based on above calculation, the R1 receives 10Mbps traffic on Gi0/2 and then it will be shaped as 5Mbps traffic by QoS and transferred via Gi0/1   2. Useful logs for QoS troubleshooting     Here are minimum sets of useful show commands for QoS troubleshooting. If you are using specific platform which doing QoS by hardware, you need to collect more platform-dependent show commands.   show policy-map interface # show hqf interface # show interface # show tech show logging # : Please collect 3-5 times during passing traffic   3. Relevant information   In this section, here are some important points when collecting logs which are described on above Chapter 2. If you don't collect these information, the QoS intvestigation will be difficult by TAC engineer.   1) Detail of traffic Information by QoS     You need to understand what kind of traffic is passing on the router and is treated by QoS. In case of CBWFQ, I would like to recommend to collect the traffic information on each flow like following.。   Traffic#1 for Class#1 : IP L2 100bytes frame (10Mbps/10000pps) Traffic#2 for Class#2 : TCP L2 50bytes frame (5Mbps/10000pps) Traffic#3 for Class#3 : UDP L2 100bytes frame (5Mbps/50000pps) Type of protocol (IP/TCP/UDP), Packet Size(L2 or L3), Bit per seconds(bps), Packets per seconds(pps). These kind of information are needed when TAC engineer start to investigate the issue of QoS. If there is no information like above, TAC engineer does not understand whether the traffic on a network leads the QoS problem.   2) Additional Information for narrowing issue   Following information would be helpful to move forward. - certain version has the problem, but some other versions have no problem. - the problem disappears by changing some parameter of QoS configuration   ex.) changing queue-limit from 64 packets to 256 packets - the problem disappears by changing characteristic of traffic.   ex.) Frame size from 64 bytes to 1500bytes   3) Configure load-interval 30   Please configure "load-interval 30" on the interface which has the QoS configuration because it accelerates to compute the throughput on that interface.   Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#int <interface> Router(config-if)#load-interval 30   4) Should collect the logs during passing traffic This is most important thing. Almost customer already understood the "show policy-map interface" is commonly needed for QoS troubleshooting. However, sometimes the logs are collected when there is no passing traffic on the router. Please make sure if there is passing traffic before collecting logs.   5) Packet Capture   Packet capture file which causes the QoS problem. I would like to recommend to collect 2 packet captures as below. 1) capture the traffic before doing QoS (=incoming traffic) 2) capture the traffic after doing QoS (=outgoing traffic) Sometimes, TAC engineer need to check how the traffic are treated by QoS, that's why both captures are desired.   4. Often-opened cases   1) drops due to bursty traffic Our IOS implemented HQF framework since 12.4(20)T. After that, Tc on Shaping has been changed from 25msec to 4msec. Therefore, the HQF improves the accuracy of QoS, but on the other hand, it drops more than before against bursty traffic pattern. So, we receives some cases which relates to those issues by bursty traffic from the customer who upgraded from pre-HQF version to HQF version.  If you encounter this issue after upgrading from old version to HQF version, please make sure if the issue is resolved by adjusting Tc as 25msec by changing Bc/Be values.   2) due to overflowing queue-limit   In case of Shaping, some packets are placed in queue-limit to wait for given token when receiving burst traffc. On this situation, we can assume the default queue-limit (64 packets) will not be enough. And the drops happens by overflowing queue-limit. If you face this situation, you can see the drop by overflowing queue-limit from following "total drops" which is bold highlighted. And the output indicates that queue-depth is 64, it means the queue-limit is full and tail drops are happening.   Router#show policy-map int GigabitEthernet0 Service-policy output: Shape Class-map: class-default (match-any) 84880256 packets, 127320118758 bytes 30 second offered rate 83539000 bps, drop rate 13087000 bps Match: any Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 64/32749/0 (pkts output/bytes output) 84847504/127270998258 shape (average) cir 10000000, bc 40000, be 40000 target shape rate 10000000     To avoid this drops by overflowing queue-limit, please consider to increase the value of queue-limit like below. Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#policy-map Shape Router(config-pmap)#class class-default Router(config-pmap-c)#queue-limit 128   3) About Delay   We sometimes receive a query where the customer is facing the delay on certain class which "bandwidth" configured. I would like to say, the bandwidth does not guarantee the delay of the traffic. Its function is to reserve the configured bandwidth when happening congestion. If the delay is happening on PQ class, it should be opened to TAC as service request. Please understand the meaning/function of the commands when you face the issue.   5. In conclusion I mentioned above, Chapter3 1) adjusting Tc by changing Bc/Be and 2) changing queue-limit against burst traffic. Both are not QoS problem. Those are tuning technique when using QoS. Before opening the service request to TAC, please tune the parameters of QoS by yourself if your problem could be tuning issue. Even after trying to tune, please contact TAC if you need to address the issue.   Related Information Original Document:https://supportforums.cisco.com/ja/document/12021346 Author: Takashi Higashimura Posted on June 1, 2014 ... View more

本ドキュメントは OSPF fast hello 使用時に予め理解しておくべき内容及びトラブルシューティングの方法を記載します。   1. 本ドキュメントのネットワーク構成 2. OSPF設定   R1 interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Ethernet0/0 ip address 10.1.2.1 255.255.255.0 ip ospf dead-interval minimal hello-multiplier 4 ! router ospf 1 router-id 1.1.1.1 network 10.1.2.1 0.0.0.0 area 0 ! R2 interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Ethernet0/0 ip address 10.1.2.2 255.255.255.0 ip ospf dead-interval minimal hello-multiplier 4 ! router ospf 1 router-id 2.2.2.2 network 10.1.2.2 0.0.0.0 area 0 ! 上記の通り、R1/R2 では ip ospf dead-interval minimal hello-multiplier 4 の設定により、holdtime 1秒内に250msec毎に4回Helloを送信する設定となります。 この場合、1秒間 Hello が受信できなければ、OSPF neighbor down となります。   3. OSPFネイバーダウンの確認   OSPF Fast Hellos を使っていない場合と同様に Holdtime (1秒) の間、Hello が受信できない場合は下記メッセージのように Dead timer expired で表示されます。 R2# *Jun 17 13:50:50.295 JST: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired   4. Dead timer expired の理由   Fast hellos を設定している場合の Dead timer expired となる理由としては一時的な CPU 負荷の上昇があります。 しかしながら、1秒という短い間でCPU負荷がスパイクする場合には show ログからの確認も困難であり、show process cpu history 表示で1秒という短い時間でのCPU負荷のスパイクを捉えることはできません。 IOSの実装では、割り込み処理や OSPF よりも優先度の高い処理がある場合は、OSPF の処理は保留され、先に優先度の高いプロセスが処理されます。また、一つのプロセスがデフォルトで最大 200msec の間、CPUリソースを占有することができるため、単純に計算すると OSPF よりも高い優先度のプロセス処理が 5つ 以上続くような場合が発生した時には OSPF Hello の送受処理が1秒間できず、Dead timer expired でネイバーダウンに至ります。 前述の通り、show ログから CPU 負荷の上昇について捉えることは困難ですが OSPF Hello の送受に影響が出ていることは debug ログから判断が可能です。 考えられる方法としては下記 3つ の方法があります。 1) debug ip ospf hello の送受間隔 R2# *Jun 17 14:09:17.593 JST: OSPF-1 HELLO Et0/0: Rcv hello from 1.1.1.1 area 0 10.1.2.1 *Jun 17 14:09:17.837 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2 *Jun 17 14:09:17.846 JST: OSPF-1 HELLO Et0/0: Rcv hello from 1.1.1.1 area 0 10.1.2.1 *Jun 17 14:09:18.085 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2 *Jun 17 14:09:18.094 JST: OSPF-1 HELLO Et0/0: Rcv hello from 1.1.1.1 area 0 10.1.2.1   通常は上記のように 250msec 間隔で OSPF Hello を送受しています。   R2# *Jun 17 14:10:59.261 JST: OSPF-1 HELLO Et0/0: Rcv hello from 1.1.1.1 area 0 10.1.2.1 *Jun 17 14:10:59.310 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2 *Jun 17 14:10:59.493 JST: OSPF-1 HELLO Et0/0: Rcv hello from 1.1.1.1 area 0 10.1.2.1 *Jun 17 14:10:59.559 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2 *Jun 17 14:10:59.798 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2 *Jun 17 14:11:00.034 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2 *Jun 17 14:11:00.285 JST: OSPF-1 HELLO Et0/0: Send hello to 224.0.0.5 area 0 from 10.1.2.2 *Jun 17 14:11:00.497 JST: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired   上記 Dead timer expired となったタイミングの debug を見ると、DOWN の直前に Send hello が続いているものの Rcv hello が見えていないのが分かります。 これには下記2つの理由が考えられます。 自ルータの一時的なCPU高負荷により OSPF Hello の受信処理が1秒以上できなかった 対向ルータの一時的なCPU後負荷により対向ルータが OSPF Hello を1秒以上送信できなかった 上記のいずれかを判断するためには、OSPF Hello をやり取りしているリンクのパケットキャプチャを取得し、キャプチャ上では定期的に送信されてきている Hello が debug 上で見えないということであれば、自ルータの一時的な高負荷と判断できます。 2) show ip ospf neighbor を連続して取得 R262#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/BDR 871 msec 10.1.2.1 Ethernet0/0 R262#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/BDR 585 msec 10.1.2.1 Ethernet0/0 R262#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/BDR 900 msec 10.1.2.1 Ethernet0/0 今回の設定では、250msec 間隔で Hello を受信するため、上記 show ip ospf neighbor の Dead Time は通常 750msec を下回ることはありません。 上記のように連続して show ip ospf neighbor を取得し、上記 "585 msec" のように 750msec を下回っているような状況が定常的に見えるようであれば、一時的なCPU高負荷により OSPF neighbor down が発生しやすい状況にあると言えます。   5. 回避策及び対策   OSPF Fast Hello はプロセス処理のため、前述の IOS のプロセス処理の実装から一時的な CPU高負荷によって DOWN が発生することは避けることができないものとなります。 そのため、設定時には予めCPU高負荷には DOWN する可能性があることを考慮の上、設計/設定する必要があります。 OSPF Fast Hello の代わりに BFD を使うことを検討することは一つの対策として考えられます。BFD は IOS の実装において優先して扱われるようになっているため、OSPF Fast Hello と比較した場合、一時的な CPU高負荷により DOWN する可能性が低くなります。   6. 最後に   前述の通り、OSPF Fast Hellos のトラブルシューティングでは 1sec 未満での一時的なCPU高負荷を捉えることは難しく、上記のように debug やキャプチャを取得して CPU高負荷 の影響が考えられるか否かを判断する必要があります。 実環境においては debug 及びキャプチャを取得するのが容易でない場合があるため、そのような場合は Fast Hellos を止め、OSPF holdtime 4秒/Hello 1秒 などによる設定変更による切り分けが必要となります。 以上   ... View more

  本ドキュメントは下記リファレンスに記載されている DHCP Static Mapping 設定時のトラブルシューティングについて記載します。 Configuring DHCP Static Mapping DHCP Static Mapping では、マッピングファイルを作成しておくことで静的にIPアドレスを端末に割り当てることができ、その方法としては下記のいずれかの情報をもとにマッピングを行います。 MACアドレス DHCP Client Identifier (Option61) 使用している OS などにより、DHCP からのアドレス自動取得とした際、DHCP Client Identifier を送信するものと、送信しないものがあり、マッピングファイルを作成した際に意図したアドレス割り当てができないといったケースがあるため、それを解決する方法を解説します。 注意 : 下記は端末に Linux を想定して説明しておりますが、Linux の設定/操作についての詳細は Linux のマニュアルや解説本を参照してください。 1. 本ドキュメントのネットワーク構成 R1 : Cisco892J 15.2(4)M4 PC : CentOS 5.8   2．DHCP サーバ/クライアント設定 下記が DHCPサーバ(R1) の設定と、クライアント(PC) の設定になります。 DHCP サーバでは flash:static-bindings をマッピングファイルとして作成しています。 R1 running-config ip dhcp pool pool1 origin file flash:static-bindings default-router 192.168.1.1 ! interface GigabitEthernet0 ip address 192.168.1.1 255.255.255.0 duplex auto speed auto ! flash:static-bindings *time* Jun 17 2014 07:52 AM !IP address Type Hardware address Lease expiration 192.168.1.100 id 01.0050.56a5.5d9d Infinite *end* 上記マッピングファイルでは "id" とあることから、DHCP Client Identifier を使って割り当てるように設定されています。 また、通常 DHCP Client Identifier は "01." + MAC address となります。"01" は Hardware Type を示しており、Ethernet の場合は "01" になります。詳しくは RFC2132 を参照ください。 PC /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 ONBOOT=yes BOOTPROTO=static HWADDR=00:50:56:a5:5d:9d 3. DHCP 割り当ての確認方法 PC 上で ifdown/ifup を行い、 eth0 で DHCP Discover を送信します。 # ifdown eth0 # ifup eth0 R1 上で debug を有効にして、DHCP での割り当てを確認します。 R1#debug ip dhcp server packet detail DHCP server packet detail debugging is on. R1#debug ip dhcp server event DHCP server event debugging is on. Jun 17 10:06:47.385 JST: DHCPD: client's VPN is . Jun 17 10:06:47.385 JST: DHCPD: No option 125 Jun 17 10:06:47.385 JST: DHCPD: Sending notification of DISCOVER: Jun 17 10:06:47.385 JST: DHCPD: htype 1 chaddr 0050.56a5.5d9d Jun 17 10:06:47.385 JST: DHCPD: remote id 020a0000010f190f00000000 Jun 17 10:06:47.385 JST: DHCPD: circuit id 00000000 Jun 17 10:06:47.385 JST: DHCPD: DHCPDISCOVER received from client 0050.56a5.5d9d on interface GigabitEthernet0. Jun 17 10:06:47.389 JST: DHCPD: Seeing if there is an internally specified pool class: Jun 17 10:06:47.389 JST: DHCPD: htype 1 chaddr 0050.56a5.5d9d Jun 17 10:06:47.389 JST: DHCPD: remote id 020a0000010f190f00000000 Jun 17 10:06:47.389 JST: DHCPD: circuit id 00000000 Jun 17 10:06:47.389 JST: DHCPD: there is no address pool for 192.168.1.1. 上記太字の部分で "from client" に続いて PC の MACアドレス が確認できます。ここは前述の DHCP Client Identifier を送信してきている場合には、"01.0050.56a5.5d9d" と表示されるべきですが、PCから DHCP Client Identifier が送信されていないために静的に割り当てを行うことができず、最下行で見えるように "there is no address pool" という風にマッチングするものがなく、静的に割り当てできない結果となっています。 4. 解決方法 上記の解決方法としては、2つあります。 1) DHCP サーバ側のマッピングファイルを id から MAC 判別へ変更する flash:static-bindings *time* Jun 17 2014 07:52 AM !IP address Type Hardware address Lease expiration 192.168.1.100 1 0050.56a5.5d9d Infinite *end* 上記の通り、static-bindings ファイルの内容を変更します。変更点は下記2点です。 Type を "id" から "1" へ変更 Hardware address の先頭 "01." を除き、MACアドレスのみに変更 上記ファイルの変更を反映させるため、下記方法にて一旦 DHCP サーバを停止し、再開する必要があります。 R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#no service dhcp R1(config)#service dhcp R1(config)#end 上記ファイル変更後の debug は下記となり、静的に 192.168.1.100 を割り当てられていることが確認できる。 Jun 17 10:26:07.756 JST: DHCPD: client's VPN is . Jun 17 10:26:07.756 JST: DHCPD: No option 125 Jun 17 10:26:07.756 JST: DHCPD: Sending notification of DISCOVER: Jun 17 10:26:07.756 JST: DHCPD: htype 1 chaddr 0050.56a5.5d9d Jun 17 10:26:07.756 JST: DHCPD: remote id 020a0000010f190f00000000 Jun 17 10:26:07.756 JST: DHCPD: circuit id 00000000 Jun 17 10:26:07.756 JST: DHCPD: DHCPDISCOVER received from client 0050.56a5.5d9d on interface GigabitEthernet0. Jun 17 10:26:07.756 JST: DHCPD: Seeing if there is an internally specified pool class: Jun 17 10:26:07.756 JST: DHCPD: htype 1 chaddr 0050.56a5.5d9d Jun 17 10:26:07.756 JST: DHCPD: remote id 020a0000010f190f00000000 Jun 17 10:26:07.756 JST: DHCPD: circuit id 00000000 Jun 17 10:26:07.756 JST: DHCPD: Found Manual/Static binding Jun 17 10:26:07.756 JST: DHCPD: Sending DHCPOFFER to client 0050.56a5.5d9d (192.168.1.100). Jun 17 10:26:07.756 JST: DHCPD: no option 125 Jun 17 10:26:07.756 JST: DHCPD: creating ARP entry (192.168.1.100, 0050.56a5.5d9d, vrf default). Jun 17 10:26:07.756 JST: DHCPD: unicasting BOOTREPLY to client 0050.56a5.5d9d (192.168.1.100). Jun 17 10:26:07.756 JST: DHCPD: client's VPN is . Jun 17 10:26:07.756 JST: DHCPD: No option 125 Jun 17 10:26:07.756 JST: DHCPD: DHCPREQUEST received from client 0050.56a5.5d9d. Jun 17 10:26:07.756 JST: DHCPD: Sending notification of ASSIGNMENT: Jun 17 10:26:07.756 JST: DHCPD: address 192.168.1.100 mask 255.0.0.0 Jun 17 10:26:07.756 JST: DHCPD: htype 1 chaddr 0050.56a5.5d9d Jun 17 10:26:07.756 JST: DHCPD: lease time remaining (secs) = 4294967295 Jun 17 10:26:07.756 JST: DHCPD: Can't find any hostname to update Jun 17 10:26:07.756 JST: DHCPD: Sending DHCPACK to client 0050.56a5.5d9d (192.168.1.100). Jun 17 10:26:07.756 JST: DHCPD: no option 125 Jun 17 10:26:07.756 JST: DHCPD: ARP entry exists (192.168.1.100, 0050.56a5.5d9d). Jun 17 10:26:07.756 JST: DHCPD: unicasting BOOTREPLY to client 0050.56a5.5d9d (192.168.1.100).   2) PC から DHCP Client Identifier を送信するように設定する PC 上で /etc/dhclient.conf に send dhcp-client-identifier を下記のように追加する。(場合によってはファイル自体が無い場合があるため、その場合はファイルを作成する) /etc/dhclient.conf interface "eth0" { send dhcp-client-identifier = hardware; } PC 上で下記コマンドにより一旦アドレスをリリースし、再度取得をする。 # dhclient -r eth0 # dhclient eth0 上記 PC から DHCP Client Identifier を送信するように設定変更後の R1 での debug は下記の通りです。 Jun 17 09:05:26.238 JST: DHCPD: client's VPN is . Jun 17 09:05:26.238 JST: DHCPD: No option 125 Jun 17 09:05:26.238 JST: DHCPD: Sending notification of DISCOVER: Jun 17 09:05:26.238 JST: DHCPD: htype 1 chaddr 0050.56a5.5d9d Jun 17 09:05:26.238 JST: DHCPD: remote id 020a0000010f190f00000000 Jun 17 09:05:26.238 JST: DHCPD: circuit id 00000000 Jun 17 09:05:26.238 JST: DHCPD: DHCPDISCOVER received from client 0100.5056.a55d.9d on interface GigabitEthernet0. Jun 17 09:05:26.238 JST: DHCPD: Seeing if there is an internally specified pool class: Jun 17 09:05:26.238 JST: DHCPD: htype 1 chaddr 0050.56a5.5d9d Jun 17 09:05:26.238 JST: DHCPD: remote id 020a0000010f190f00000000 Jun 17 09:05:26.238 JST: DHCPD: circuit id 00000000 Jun 17 09:05:26.238 JST: DHCPD: Found Manual/Static binding Jun 17 09:05:26.238 JST: DHCPD: Sending DHCPOFFER to client 0100.5056.a55d.9d (192.168.1.100). Jun 17 09:05:26.238 JST: DHCPD: no option 125 Jun 17 09:05:26.238 JST: DHCPD: creating ARP entry (192.168.1.100, 0050.56a5.5d9d, vrf default). Jun 17 09:05:26.238 JST: DHCPD: unicasting BOOTREPLY to client 0050.56a5.5d9d (192.168.1.100). Jun 17 09:05:26.238 JST: DHCPD: client's VPN is . Jun 17 09:05:26.238 JST: DHCPD: No option 125 Jun 17 09:05:26.238 JST: DHCPD: DHCPREQUEST received from client 0100.5056.a55d.9d. Jun 17 09:05:26.238 JST: DHCPD: Sending notification of ASSIGNMENT: Jun 17 09:05:26.238 JST: DHCPD: address 192.168.1.00 mask 255.0.0.0 Jun 17 09:05:26.238 JST: DHCPD: htype 1 chaddr 0050.56a5.5d9d Jun 17 09:05:26.238 JST: DHCPD: lease time remaining (secs) = 4294967295 Jun 17 09:05:26.238 JST: DHCPD: Can't find any hostname to update Jun 17 09:05:26.238 JST: DHCPD: Sending DHCPACK to client 0100.5056.a55d.9d (192.168.1.100). Jun 17 09:05:26.238 JST: DHCPD: no option 125 Jun 17 09:05:26.238 JST: DHCPD: ARP entry exists (1.90.90.90, 0050.56a5.5d9d). Jun 17 09:05:26.238 JST: DHCPD: unicasting BOOTREPLY to client 0050.56a5.5d9d (192.168.1.100). 5. 最後に 前述の通り、DHCP Static Mapping を使う場合には、端末側で DHCP Client Identifier を送信する設定になっているかどうかを事前に把握しておく必要があります。 また、DHCP Client Identifier を送信してきているか否かは、下記 debug の箇所で想定が可能です。 Jun 17 09:05:26.238 JST: DHCPD: DHCPDISCOVER received from client 0100.5056.a55d.9d on interface GigabitEthernet0. 上記太字部分のように、MAC アドレスと一致しない場合には Client Identifier を送信してきていると考えることができます。しかしながら、Client Identifier を明示的に変更することができるため、MACアドレスと全く同じ ID とした場合には、上記 debug では判断できないことに注意してください。 PC(端末)の設定が確認できないような状況では、DHCP サーバ上で受信している DHCP Discovery のパケットをキャプチャして DHCP Client Identifier (Option 61) が付与されているかどうかを確認してください。 以上   ... View more

VRF NAT において、Outside 側で VRF NAT はサポートされていません。 ... View more

OSPF fast hello は障害時の検知を早くするために有効な機能ですが、その性質を正しく理解しておく必要があります。 下記に知っておくべき事項や対策や代替方法について記載します。 ... View more

本ドキュメントでは、QoS の問題を解析するにあたり調査に必要なログの取得方法を説明します。 また、本ドキュメントでは検証環境での解析方法をメインとしており、実環境での解析においては必ずしも有効でない場合がございますが、予めご了承ください。   1. 本ドキュメントのネットワーク構成 L2 125bytes の Frame を 10000pps で測定器から矢印の方向で送出。   10000pps * (125*8) = 10000000bps(=10Mbps)   上記計算式の通り、10Mbps のトラフィックとなり R１ の Gi0/2 で受信、Gi0/1 で送信されますが、Gi0/1 で 5Mbps のシェーピングを設定しています。   2. 取得ログ   QoS の設定や機種により、取得するコマンドが異なってくる場合はございますが、最低限必要なものは下記となります。   show policy-map interface ※ show hqf interface ※ show interface ※ show tech show logging ※ : トラフィックを流している状態で複数回3-5回程度取得   3. 解析にあたり必要な事（ログ取得の注意含む)   前述の項目2.で記載しているログを取得する際の注意点となります。下記が実施されていない場合は、QoS の調査は困難となります。   1) QoS制御されるトラフィックの情報   どのようなトラフィックを流していて、QoS がうまく動作していないかを把握/整理する。 CBFWQ などで、複数の Class にそれぞれ 3つのトラフィックを流している場合は下記のような形で整理する。   Traffic#1 for Class#1 : IP L2 100bytes frame (10Mbps/10000pps) Traffic#2 for Class#2 : TCP L2 50bytes frame (5Mbps/10000pps) Traffic#3 for Class#3 : UDP L2 100bytes frame (5Mbps/50000pps)   プロトコル種別(IP/TCP/UDP)、パケットサイズ(L2 or L3 なのかも重要)、トラフィック量(bps)、パケット量(pps) の情報は調査を行う上で必要な情報となります。無い場合は、そのトラフィックが破棄されるべきものか否かの判断ができません。   2) 切り分け情報   下記の情報があると解析が非常にスムーズに進む場合があります。   - あるバージョンでは正常に QoS 制御されるが、このバージョンだと制御がおかしい (具体的なバージョン境界が分かると非常に有力な情報) - QoS の設定を変更してみたら、QoS 制御の問題が解消された (どのように設定を変更したか確認する) - トラフィック特性を変更したら問題が解消された (Frame サイズを 64bytes -> 1500bytes に変更など)   3) load-interval 30 の設定 下記は設定方法です。 Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#int <interface> Router(config-if)#load-interval 30   4) トラフィックを流している状態でログを取得   これが解析にあたり、最も重要なポイントとなります。弊社 IOS を使っていただいているユーザ様には QoS の確認は show policy-map interface という認識を持っていただいているのですが、事象が発生するトラフィックが流れている状態でログを取得することが重要です。   5) パケットキャプチャ   事象が発生するトラフィックのパケットキャプチャ。QoS 制御前と制御後の両方があると良い。   4. よくある事例   1) バーストトラフィックによる破棄   弊社 IOS では 12.4(20)T 以降で、HQF という QoS 実装になり、Shaping でそれまで Tc 25msec だったものが 4msec へと変更が行われました。 そのため、QoS 制御の粒度が上がった一方でバーストトラフィックを落としてしまう事例が報告されております。 特に HQF 以前から HQF へバージョンアップした場合に報告される事例が多いです。   12.4(20)T より前のバージョンから、HQF 実装の IOS へバージョンアップをした場合には、Tc が変更された影響かどうかは下記のように Bc/Be 値の調整で Tc 値を 4msec -> 25msec へと変更し、従来と同じ値とすることでバースト特性を持ったトラフィックの破棄が解消されるかご確認ください。   2) queue-limit の超過による破棄   Shaping などで Bc 値を越えたことにより次のトークンを待って処理される場合などには、queue-limit にパケットが溜まることなります。 この場合、一時的なバーストにより多くの short frame(or short packet) が来た場合にdefault の 64packets で不足すると破棄されます。   この場合には下記太字部分でのカウントが増加することにより、queue-limit での破棄と推測することが可能です。下記の場合では queue limit 64 packets で、queue depth 64 となっているため、キューが不足していることが確認できます。   Router#show policy-map int GigabitEthernet0 Service-policy output: Shape Class-map: class-default (match-any) 84880256 packets, 127320118758 bytes 30 second offered rate 83539000 bps, drop rate 13087000 bps Match: any Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 64/32749/0 (pkts output/bytes output) 84847504/127270998258 shape (average) cir 10000000, bc 40000, be 40000 target shape rate 10000000   破棄への対策としては queue-limit 値を変更することで可能です。 Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#policy-map Shape Router(config-pmap)#class class-default Router(config-pmap-c)#queue-limit 128   3) 遅延について   bandwidth 設定を行っているクラスで遅延が発生しますというお問い合わせがたまにありますが、bandwidth では輻輳時の帯域確保が目的であって遅延を保障するものではございません。そのため、遅延についての議論は PQ(Priority Queuing) クラスであれば可能ですが、bandwidth などすることに意味がありません。 それは QoS をデザインする段階でも理解すべき点となり、その設定がどのような役割を担っているかを把握し何を問題とすべきかを考えることが重要です。   5. 最後に   項目3での上記 1) では Bc/Be の変更による Tc の調整、2) ではバーストトラフィックに対する queue-limit の調整、となり両者とも QoS ではチューニングの範疇となり IOS の不具合などではございません。"あれ？QoS 制御おかしいんじゃないか？" と思った場合にも、まずはトラフィックの特性を理解し、パラメータの変更(=チューニング)で回避可能かをご確認ください。 ... View more

  EPC(Embedded Packet Capture)の使い方について紹介しています。 ... View more