DynagenでCCIEを目指す
INE Workbook Volume II lab 08
最終更新：
it_certification
-
view
採点結果
| トピック | 正誤 | 備考 |
| 1.1 Spanning-Tree Protocol | ○ | |
| 1.2 Layer 2 Connectivity | ○ | |
| 1.3 Spanning-Tree Protocol | ○ | |
| 1.4 Spanning-Tree Protocol | ○ | |
| 1.5 Multilink PPP over Frame Relay | × | 知識不足 |
| 2.1 OSPF | ○ | |
| 2.2 OSPF | ○ | |
| 2.3 RIP | ○ | |
| 2.4 Redistribution | ○ | |
| 2.5 Load Distribution | ○ | |
| 2.6 BGP Summarization | ○ | |
| 2.7 Next-Hop Processing | ○ | |
| 2.8 BGP Bestpath Selection | ○ | 問題文が複数の意味に読み取れましたが、模範解答の解答の可能性も考慮できたので正解とします。 |
| 2.9 BGP Filtering | ○ | |
| 3.1 OSFPv3 | ○ | |
| 3.2 IPv6 Default Routing | ○ | |
| 3.3 IPv6 Redistribution | ○ | |
| 5.1 Auto-RP | ○ | |
| 5.2 Multicast Distribution | ○ | |
| 5.3 Multicast Testng | ○ | |
| 5.4 Broadcast Distribution | ○ | |
| 6.1 Router Hardening | ○ | |
| 6.2 Traffic Filtering | ○ | |
| 6.3 Traffic Filtering | ○ | |
| 7.1 Default Gateway | × | 知識不足 |
| 7.2 Web Cachng | × | 問題文誤読 |
| 7.3 IP SLA | × | 知識不足 |
| 7.4 Gateway Redundancy | × | 知識不足 |
| 8.1 Frame Relay Traffic Shaping | ○ | 問題文が複数の意味に読み取れましたが、模範解答の解答の可能性も考慮できたので正解とします。 |
| 8.2 Queueing | × | 知識不足 |
| 8.3 Congestion Management | ○ | |
| 8.4 Congestion Avoidance | ○ |
所感
- BGPの問題文の意味が、4,5通りの意味に読み取れてしまいました。beyond, behindはどこから見てのbeyond, behindなのかによって意味が変わってしまうので、試験本番では必ずプロテクタに質問したいと思います。
1.5 Multilink PPP over Frame Relay
まとめ
以下の要領でMultilink Interfaceを定義する事ができます。(DLCIとVirtual-Templateの紐づけなどvol I学習済み分野については省略します)
interface Multilink1 ip address 174.XX.23.2 255.255.255.0 ppp multilink ppp multilink group 1 interface Virtual-Template1 no ip address ppp multilink ppp multilink group 1 ppp authentication chap
2.1 OSPF
受験テクニック
"OSPF type 1 authentication"という見慣れない表現が問題文中にありますが、オンラインドキュメントを検索すると、すぐにhitします。見慣れない表現を見たら、まずオンラインドキュメントを検索してみましょう。
なお、OSPF authentication typeについてまとめると以下の通りです。
なお、OSPF authentication typeについてまとめると以下の通りです。
| OSPF tyep 0 authentication | 認証なし |
| OSPF tyep 1 authentication | 平文認証 |
| OSPF tyep 2 authentication | MD5認証 |
5.4 Broadcast Distribution
受験テクニック
vol IではDNS requestによる確認方法を挙げていますが、IP SLAを利用したudp echoによる確認方法も可能です。R6に以下のようなIP SLAを定義します。
R6: ip sla 2 udp-echo 174.4.26.255 3434 control disable frequency 10 ip sla schedule 2 life forever start-time now
R1において、デバッグメッセージを有効にする事でパケットの到達確認を行います。
R6: Rack4R1(config)#access-list 100 permit udp any any eq 3434 Rack4R1(config)#exit Rack4R1# Nov 12 18:07:25.051: %SYS-5-CONFIG_I: Configured from console by console Rack4R1# Rack4R1# Rack4R1#debug ip packet detail 100 IP packet debugging is on (detailed) for access list 100 Rack4R1# Rack4R1# Nov 12 18:09:39.912: IP: tableid=0, s=174.4.26.6 (Serial0/1), d=174.4.1.255 (FastEthernet0/0.1001), routed via RIB Rack4R1# Nov 12 18:09:49.913: IP: tableid=0, s=174.4.26.6 (Serial0/1), d=174.4.1.255 (FastEthernet0/0.1001), routed via RIB Rack4R1#
7.3 IP SLA
まとめ
RTTに関するSLAを満たしているかどうか監視するためには、以下のようなthresholdを定義します。
ip sla 1 icmp-echo 115.0.0.1 source-interface Serial0/0/0 request-data-size 1250 threshold 330 timeout 500 frequency 5 ip sla schedule 1 life forever start-time now
thresholdを定義すると、以下のようにOK, Over threshold, NGの3種類のreturn codeを返すようになります。Over thresholdはレスポンスを確認できたもののRTTがthresholdを超過している事を意味します。
Rack4R6#show ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 1
Type of operation: icmp-echo
Latest RTT: 368 milliseconds
Latest operation start time: 18:44:50.135 UTC Sat Nov 12 2011
Track Objectを作成する際、thresholdの扱いはstateにするかreachabilityにするかで変わってきます。まとめると以下の通りです。
Rack4R6(config)#track 1 ip sla 1 ? reachability Reachability state Return code state Rack4R6(config)#track 1 ip sla 1
| return code | track status | |
| reachability | OK, Over threshold | Up |
| NG | Down | |
| status | OK | Up |
| Over threshold, NG | Down |
7.4 Gateway Redundancy
まとめ
HSRPv1, HSRPv2の違いについて理解していませんでした。両者の違いをまとめると以下の通りです。
| protocol | ip address | |
| HSRPv1 | udp 1985 | 224.0.0.2 |
| HSRPv2 | udp 1985 | 224.0.0.102 |
| VRRP | protocol number 112 | 224.0.0.18 |
| GLBP | udp 3222 | 224.0.0.102 |
8.2 Queueing
まとめ
問題文の指定は、"R1's traffic shaping queueu to hold 10 times the default amount of packets"です。
GTS(traffic-shapeコマンド)、CBWFQ(service-policyコマンド)などがありますが、それぞれbuffer size, packet lengthでqueueが管理されます。この問題は、デフォルトの10倍のpacketと指示されているので、CBWFQを使用するのが適切です。CBWFQのqueue sizeは1なので、解答は以下のようになります。(8.2のみではなく、8.1の解答も含みます)
GTS(traffic-shapeコマンド)、CBWFQ(service-policyコマンド)などがありますが、それぞれbuffer size, packet lengthでqueueが管理されます。この問題は、デフォルトの10倍のpacketと指示されているので、CBWFQを使用するのが適切です。CBWFQのqueue sizeは1なので、解答は以下のようになります。(8.2のみではなく、8.1の解答も含みます)
policy-map CBWFQ class class-default bandwidth percent 100 queue-limit 10 ! policy-map SHAPE class class-default shape average 128000 service-policy CBWFQ ! interface Serial 0/0/0 service-policy SHAPE
