Windows

Windows 7 IPv6 auto-assignment fix

For some reason, Microsoft decided that Windows 7 would autoconfigure IPv6 using a random identifier (not the MAC address / EUI-64) – they went on to decide that it would randomly assign temporary addresses which change constantly.  This is an admin nightmare, not to mention *awful* when it comes to assigning DNS.

So, here’s how to make Windows 7 behave as per every other OS…

1. Open up a Command Prompt in Administrator mode (right-click, run as administrator)

2. Run the following commands.  Each one should respond “Ok".  If you didn’t do step 1 correctly, it will say the command required elevation.

netsh interface ipv6 set privacy state=disabled store=active
netsh interface ipv6 set privacy state=disabled store=persistent
netsh interface ipv6 set global randomizeidentifiers=disabled store=active
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent

3. Exit the command prompt, and reboot.

Cisco ISATAP

Introduction

This example demonstrates ISATAP configuration on the head-end router and a simulated ISATAP client using a Cisco router.
Usually the client is a Windows PC with IPv6 enabled, initiating the tunnel. For testing and verification purposes, a Cisco router closest to the clients can act as a client.
For this, we are using ISATAP tunnel at the head-end and IPv6 over IPv4 manual tunnel at the client router. IPv6 unicast routing can be disabled on the client router, so that it will behave as a true client and install a default IPv6 static route towards the head-end.
Check feature navigator to verify head-end router image supports ISATAP tunnels.
Check feature navigator to verify simulated client router supports manually configured IPv6 over IPv4 tunnels.

Design

Configuration

Head-end router configuration

ipv6 unicast-routing

!

interface Loopback0

ip address 15.100.8.1 255.255.255.255

!

interface Tunnel1

no ip address

no ip redirects

ipv6 address 2001:DB8:CAFE:65::/64 eui-64 <<<Any /64 IPv6 address will work

no ipv6 nd ra suppress <<< IPv6 ra is suppressed by default on tunnel. Need to re-enable for client auto-configuration.

tunnel source Loopback0

tunnel mode ipv6ip isatap

Simulated ISATAP client on Cisco router

interface ethernet0

ip address 15.2.8.128 255.255.255.0

!

interface Tunnel1

no ip address

ipv6 address autoconfig

ipv6 enable

tunnel mode ipv6ip

tunnel source ethernet0

tunnel destination 15.100.8.1

 

Related show Commands

This section provides information you can use to confirm your configuration is working properly.

Certain show commands are supported by the Output Interpreter Tool (registered customers only), which allows you to view an analysis of show command output.

 

Show running-config

Client Tunnel1 should acquire IPv6 address prefix from head-end. Then client source IPv4 address is appended at the end. In this example, 15.2.8.128 => F02:880

show ipv6 interface tunnel1

IPv6 is enabled, link-local address is FE80::F02:880

No Virtual link-local address(es):

Stateless address autoconfig enabled

Global unicast address(es):

2001:DB8:CAFE:65::F02:880, subnet is 2001:DB8:CAFE:65::/64 [EUI/CAL/PRE] <<< Acquired IPv6 prefix and resultant IPv6 autoconfig address

valid lifetime 2591770 preferred lifetime 604570

Joined group address(es):

FF02::1

FF02::1:FF02:880

MTU is 1480 bytes

ICMP error messages limited to one every 100 milliseconds

ICMP redirects are enabled

ICMP unreachables are sent

ND DAD is enabled, number of DAD attempts: 1

ND reachable time is 30000 milliseconds (using 30000)

Default router is FE80::5EFE:F64:801 on Tunnel1 <<< ISATAP head-end as the default router with 0000:5EFE appended with head-end source IPv4

If IPv6 unicast-routing is disabled on the client router, it will also install a default static route pointing towards the ISATAP head-end router.

show ipv6 route

IPv6 Routing Table – default – 4 entries

Codes: C – Connected, L – Local, S – Static, U – Per-user Static route

B – BGP, R – RIP, I1 – ISIS L1, I2 – ISIS L2

IA – ISIS interarea, IS – ISIS summary, D – EIGRP, EX – EIGRP external

ND – Neighbor Discovery, l – LISP

O – OSPF Intra, OI – OSPF Inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2

ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2

S  ::/0 [2/0]

via FE80::5EFE:F64:801, Tunnel1

C 2001:DB8:CAFE:65::/64 [0/0]

via Tunnel1, directly connected

L 2001:DB8:CAFE:65::F02:880/128 [0/0]

via Tunnel1, receive

L FF00::/8 [0/0]

via Null0, receive

Head-end should be able to ping the client.

router#ping ipv6 2001:DB8:CAFE:65::F02:880

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:DB8:CAFE:65::F02:880, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms

深度分析DHCPV6協定，比較與DHCP的區別

深度分析DHCPV6協定，比較與DHCP的區別

一、DHCPV6產生的背景
隨著全球IPV4位址逐漸枯竭，IPV6應運而生，IPV6是將來地址的趨勢。位址轉變了，當然相應在IPV4上運用的協定也要轉變到IPV6中來，所以DHCPV4也要轉到DHCPV6中來。所以本文就引出了DHCP V6協定。IETF在2003年重新制定了針對IPV6的DHCP協定，即DHCPV6，對比V4，它增加了一些特有的功能，如支援有狀態和無狀態位址分配服務，支援臨時位址，非臨時位址以及首碼位址的分配等，後面將會更加具體比較二者在選項、用戶端與伺服器行為、消息類型的差異。

二、DHCP6交互資料詳細解析並分析與DHCPV4的區別

下面詳細解析DHCP6中各種消息資料的屬性、行為內容以及需要填充的欄位與選項。

Type（registry code）	From	To	How and when to use	Client behavior	Server behavior
Solicit (1)	客戶機	伺服器/中繼代理	客戶機給伺服器發送solicit消息，以便得到Ipv6位址，以及選項中所附帶的配置參數	建立solicit消息資料並將其發送給伺服器	1. 首先驗證solicit消息的有效性，若消息資料中沒有包含`client identifier`或者包含有`server identifier`選項，則該資料無效並捨棄； 2. 根據管理策略來驗證伺服器是否允許接收該資料; 3.若伺服器擁有可以分配的位址，則回發Advertise消息資料(狀態碼為成功)，否則回發狀態碼為` NoAddrsAvail `的Advertise消息資料。 4. 若socilit消息資料中包含有`rapid commit`選項，則返回一個Reply消息資料.
Advertise (2)	伺服器/中繼代理	客戶機	回應客戶機發送的solicit消息資料	1. 驗證Advertise消息資料的有效性: 若出現消息資料中不含有`server identifier`欄位和`client identifier`欄位, `client identifier`欄位中的DUID不匹配或者` transaction-id “欄位不匹配等情形，則該資料無效並捨棄; 若包含狀態碼選項值為,NoAddrsAvail `,同樣丟棄該資料; 2. 基於某種策略（後面將有詳細介紹）選取Advertise消息資料;	給客戶機發送advertise消息資料，資料中包含一些設置的欄位與選項
Request (3)	客戶機	伺服器/中繼代理	客戶機請求更多的配置參數	建立並發送request消息資料給伺服器	1. 首先驗證request消息的有效性：若消息中不包含`client identifier`選項`和server identifier`選項,，或者選項中的DUID內容與伺服器不匹配，則該資料無效並捨棄; 2.若無可用的位址分配，則返回一個狀態碼為` NoAddrsAvail `的Reply消息; 3.  若伺服器發現在IA選項中的位址首碼與自身不匹配，則返回一個狀態碼為`NotOnLink`的Reply消息資料; 4.建立一個Reply消息資料，其中包括客戶機所需要的位址以及其他參數配置資訊。
Confirm (4)	客戶機	伺服器/中繼代理	由於客戶機的狀態發生變化，發送confirm消息資料去確認是否之前的配置是否還適合	當客戶機出現以下情形時:重啟，客戶機改為有線連接，客戶機改變了無線接入點。此時客戶機需要發送confirm消息進行確認	1. 捨棄掉任何沒有包含`server identifier`和`client identifier`選項的消息資料; 2. 判斷消息資料中的IA選項中的位址是否與自己同屬一個鏈路，若是，返回一個狀態碼表示為為成功的Reply消息資料; 否則返回一個狀態碼為NotOnLink的消息資料；
Renew (5)	客戶機	伺服器/中繼代理	要求伺服器延長之前分配的租約以及升級其它的參數	建立並發送Renew消息資料	1.  捨棄掉任何沒有包含`server identifier`和`client identifier`選項，或者`server identifier`選項中的DUID與伺服器不匹配的消息資料; 2.  驗證消息保證中`IA`選項中位址是否與伺服器中的存儲資訊吻合，若沒找到對應資訊，則返回狀態碼為`NoBinding`的Reply消息資料; 3. 返回包含新的lifetime, T1/T2值的Reply消息資料給客戶機
Rebind (6)	客戶機	伺服器/中繼代理	要求伺服器延長之前分配的租約以及升級其它的參數，注意這個消息資料只有在之前客戶機發送的Renew消息資料沒得到伺服器回應後才產生	建立並發送Rebind消息資料	1.捨棄掉任何沒有包括`server identifier`和`client identifier`選項的Rebind消息資料; 2.若在伺服器中沒有找到與Rebind消息資料中的IA選項中吻合的位址，或者發現地址但不再適合本鏈路，則伺服器發回一個ilifetime置為0的Reply消息; 3. 若找到吻合的位址資訊，伺服器發回一個包含新的lifetime以及T1/T2值的Reply消息資料。
Reply (7)	伺服器/中繼代理	客戶機	當伺服器收到客戶機發送的Solicit(含rapid commit選項),Request, Renew以及Rebind消息時，產生Reply消息資料回應
Release (8)	客戶機	伺服器/中繼代理	客戶機發送Release消息資料告知伺服器自己所分配的一個或者多個位址不再使用時產生Release消息資料	建立並發送Release消息資料，值得注意的是，釋放掉的位址不能再使用，若沒有收到Reply回饋消息資料，則實現重傳。	1. 捨棄掉任何沒有包含`server identifier`和`client identifier`選項，或者`server identifier`選項中的DUID與伺服器不匹配的消息資料; 2. 伺服器從Release消息資料IA選項中的地址清單中找出有效的位址(即是由本伺服器之前分配的)，並將這些位址標記為available; 3. 返回一個Reply回饋消息資料;4.  伺服器保留分配資訊，以備下次直接將配置資訊賦給這台客戶機.
Decline (9)	客戶機	伺服器/中繼代理	客戶機發送Decline消息告知伺服器自己所分配的地址已經被本鏈路的其它主機佔用	建立並發送Decline消息資料,注意Decline消息資料的`IA`選項中一定含有被佔用的位址資訊	1. 捨棄掉任何沒有包含`server identifier`和`client identifier`選項，或者`server identifier`選項中的DUID與伺服器不匹配的消息資料; 2. 伺服器檢測Decline消息資料中IA選項資料告的位址，並將其刪除，然後在本地做標記，下次將不再分配給其它客戶機 3. 處理完位址後，返回帶有狀態碼的Reply消息
Reconfigure (10)	伺服器/中繼代理	客戶機	伺服器通過發送Reconfigure消息去告知客戶機，伺服器端出現新的配置參數或者某些參數已經更新，並觸發客戶機同伺服器共同去完成Renew/Reply和Information-request/Reply	1. 首先驗證消息資料的有效性：若消息資料不是單播傳給客戶機;沒有包含`server identifier`和`client identifier`,消息中沒有包含`Reconfigure message`選項，消息中包含`IA`選項並且`Reconfigure meaasge`選項的消息類型是` INFORMATION-REQUEST `,則將該消息資料捨棄;2.客戶機返回一個Renew或者Information-request消息資料	建立並發送Reconfigure消息資料，若在某個時間範圍內，沒有收到來自於客戶機的Renew或者Information-request消息，則伺服器重傳該消息資料
Information-request (11)	客戶機	伺服器/中繼代理	客戶機發送該消息資料給伺服器，僅僅為了得到配置參數，而不需要分配位址	建立並發送Information-request消息資料，若沒收到Reply回饋消息,則重傳消息資料	1. 驗證消息資料的有效性，若消息資料中包含`server identifier`並且選項中的DUID與本機伺服器不匹配,或者包含IA選項，則將該資料捨棄; 2.構造一個包含配置資訊的Reply消息資料併發送給客戶機
Relay-forward (12)
Relay-reply (13)

上表詳細列出了DHCP6消息資料的屬性以及行為內容，有幾個特別需要說明的地方是：

◆     對比，DHCP消息資料，DHCP6在中繼代理方面增加了消息資料，以及其它一些機制，這方面的知識將在後面還會比較到。

◆     在`IA_NA`選項中，定義了多種狀態碼，分別為：

Name	Code	description
Success	0	表示成功
UnspecFail	1	表示出現不知原因的失敗
NoAddrsAvail	2	表示伺服器沒有可用的位址去分配客戶機
NoBinding	3	表示伺服器沒有綁定客戶機資訊
NotOnLink	4	表示伺服器與客戶機的位址首碼不匹配，即二者不在同一鏈路上
UseMulticast	5	表示伺服器強制客戶機使用 All_DHCP_Relay_Agents_and_Servers多播位址去發送消息

 
 

 
 

 
 

 
 

 
 

 
 

 

◆在DHCP6中，客戶機去選取連接DHCP6伺服器是基於某種策略的，具體跟伺服器所返回消息資料中的`prefere option`有關，在這個選項中定義了伺服器參考值(server prefere value)，
它的最大值為255, 客戶機正是根據伺服器中的參考值不同選取目標伺服器的，具體策略如下：

●     若某個伺服器中的參考值為255，則它擁有最高優先順序;

●     若伺服器中的參考值正好相等，則根據對伺服器返回的配置參數的興趣而定;

●     客戶機甚至會選取某些儘管參考值較低但返回更匹配的配置參數的伺服器。 值得注意的是，在DHCP中，一般會選取最先返回配置參數的伺服器！

下表列出了DHCP6消息資料的填充欄位以及選項。

Type	Client	Server
Solicit (1)	填充`msg-type`, ` transaction-id `欄位，必須包含的選項有：` Client Identifier`,`IA-NA/TA`,可選的有:` Option Request`,` Reconfigure Accept `和`rapid commit`.另外還有注意，客戶機發送solicit消息時採用的是本地鏈路位址，而目的地址是" All_DHCP_Relay_Agents_and_Servers address"多播地址,即ff02::1:2	N/A
Advertise (2)	N/A	填充`msg-type`欄位，` transaction-id `欄位來自於客戶機發送的solicit消息資料中的相應欄位值。必須包含的選項有：`server identifier`, `client identifier`, `IA`選項(注意IA選項的數量由silicit消息資料中的`IA`選項而定)以及客戶機中的`optional request`選項中含有的一些選項。可選的有：` Preference `, ` Reconfigure Accept `, “
Request (3)	填充`msg-type`, ` transaction-id `欄位,必須包含的選項有：`server identifier`, `client identifier`, ` Option Request `,`IA-NA/TA`,可選的有：`Reconfigure Accept `以及其它選項，注意請求時的目的地址以及多播位址同solicit消息資料。	N/A
Confirm (4)	填充`msg-type`欄位，並產生` transaction-id `欄位內容，必須包含的選項有：`client identifier`, `IA`(對於IA_NA選項，應該設置T1,T2域，以及preferred-lifetime and valid-lifetime域)	N/A
Renew (5)	填充`msg-type`欄位，並產生` transaction-id `欄位內容，必須包含的選項有：`client identifier`, `server identifier`, `IA`, ` Option Request `以及其他可選項	N/A
Rebind (6)	填充`msg-type`欄位，並產生` transaction-id `欄位內容，必須包含的選項內容有：`client identifier`, `IA`, `option request`	N/A
	N/A	1.   若是對solicit消息資料(包含`rapid commit`選項)的回復：必須填充欄位`msg-type`和` transaction-id `欄位（來自於solicit消息資料），必須包含的選項有：server identifier`, `client identifier`, `IA`以及request消息資料中所請求的參數選項, `rapid commit`。2.   若是對Request消息資料的回復：必須填充欄位`msg-type`和` transaction-id `欄位（來自於request消息資料）,必須包含的選項有:`server identifier`, `client identifier`, `IA`以及request消息資料中所請求的參數選項;3.   若是對Confirm消息的回復：填充`msg-type`欄位，` transaction-id`欄位來自於客戶機發送的solicit消息資料中的相應欄位值。必須包含的選項有:`server identifier`, `client identifier`, `status code`4.   若是對Renew消息的回復：填充`msg-type`欄位，` transaction-id `欄位來自於客戶機發送的solicit消息資料中的相應欄位值。必須填充的選項有：`server identifier`, `client identifier`,,`IA` 5.   若是對Rebind消息的回復：填充`msg-type`欄位，` transaction-id `欄位來自於客戶機發送的solicit消息資料中的相應欄位值。必須填充的選項有：`server identifier`, `client identifier`,,`IA` 6.   若是對Release消息的回復：填充`msg-type`欄位，` transaction-id`欄位來自於客戶機發送的solicit消息資料中的相應欄位值。必須填充的選項有：`server identifier`, `client identifier`, `IA`(包含狀態碼選項) 7.   若是對Decline消息的回復：填充`msg-type`欄位，` transaction-id `欄位來自於客戶機發送的solicit消息資料中的相應欄位值。必須填充的選項是：`server identifier`, `client identifier`, `IA`(包含狀態碼選項)
Release (8)	填充`msg-type`欄位，並產生` transaction-id `欄位內容,必須包含的選項有：`client identifier`, `server identifier`, `IA`	N/A
Decline (9)	填充`msg-type`欄位，並產生` transaction-id `欄位內容,,必須包含的選項有: `client identifier`, `server identifier`, `IA`	N/A
Reconfigure (10)	N/A	填充`msg-type`欄位，並將` transaction-id `設置成0；必須包含的選項有:`server identifier`, `Reconfigure message`, `IA`, `Option request`則是可選的,其他的選項則都不能使用
Information-request (11)	填充`msg-type`欄位，並產生` transaction-id `欄位內容,必須包含的選項有：`option request`, `client identifier`	N/A
Relay-forward (12)
Relay-reply (13)

從實際資料進行比較DHCPV4和DHCPV6的區別，下面兩張圖第一張對應的是正常情況下獲取IPv4位址的過程示意圖，從圖可以看出，用戶端首先利用0.0.0.0位址發送一個一個廣播discover消息，接著多個伺服器響應併發回了可供客戶機使用的位址(參照offer消息)，然後客戶機從中選擇某台伺服器並向其發送request消息，最後被選中的伺服器返回ACK確認消息，這樣就完成了對客戶機的位址分配。具體DHCPV4工作分析請見：《深度分析DHCP工作原理》一文。第二張，客戶機利用本地鏈路位址發送一個solicit廣播消息(廣播位址是ff02::1:2), 之後一台伺服器提供了advertise消息，並將IP位址以及客戶機所需要的配置參數資訊返回，然後客戶機發送一個request消息，主要從伺服器端索取自己所需要的請求參數資訊，最後伺服器回應請求。

DHCP獲取IP地址過程

DHCP6獲取IPV6地址過程

從上面的DHCPV4和DHCP6兩個資料交互過程，可以清楚的看出兩者的差異。

當然今天在這裡分析的只是DHCP6協定的冰山一角，在後面的文章中還會陸續給出DHCPV6協定的更深的內容，希望繼續關注。

Cisco IOS DHCP SERVICE ISSUE

採用DHCP服務的常見問題

架設DHCP服務器可以為客戶端自動分配IP位址、子網路遮罩、預設匣道、DNS服務器等網絡參數，簡化了
網絡配置，提高了管理效率。但在DHCP服務的管理上存在一些問題
常見的有：
·DHCP Server的冒充
·DHCP Server的DOS攻擊，如DHCP耗竭攻擊
·某些用戶隨便指定IP地址，造成IP地址衝突
1、DHCP Server的冒充
由於DHCP服務器和客戶端之間沒有認證機制，所以如果在網絡上隨意添加一臺DHCP服務器，它
就可以為客戶端分配IP位址以及其他網絡參數。只要讓該DHCP服務器分配錯誤的IP位址和其他網絡參
數，那就會對網絡造成非常大的危害。
2、DHCP Server的拒絕服務攻擊
通常DHCP服務器通過檢查客戶端發送的DHCP請求資料中的CHADDR欄位來判斷客戶端的MAC
地址。正常情況下該CHADDR欄位和發送請求資料的客戶端真實的MAC位址是相同的。
攻擊者可以利用偽造MAC的方式發送DHCP請求，但這種攻擊可以使用Cisco 交換機的安全特
性來防止。（Port Security）可以限制每個埠只使用唯一的MAC位址。但是如果攻擊者不
修改DHCP請求資料的源MAC地址，而是修改DHCP資料中的CHADDR欄位來實施攻擊，那端口安全特性
就不起作用了。
由於DHCP服務器認為不同的CHADDR值表示請求來自不同的客戶端，所以攻擊者可以通過大量發
送偽造CHADDR的DHCP請求，導致DHCP服務器上的位址集區被耗盡，從而無法為其他正常用戶提供網
絡地址，這是一種DHCP耗竭攻擊。DHCP耗竭攻擊可以是純粹的DOS攻擊，也可以與偽造的DHCP服
務器配合使用。當正常的DHCP服務器癱瘓時，攻擊者就可以建立偽造的DHCP服務器來為局域網中的客
戶端提供位址，使它們將資訊轉發給準備截取的惡意計算機。
甚至即使DHCP請求資料的源MAC位址和CHADDR欄位都是正確的，但由於DHCP請求資料是廣
播資料，如果大量發送的話也會耗盡網絡帶寬，形成另一種拒絕服務攻擊。
3、客戶端隨意指定IP地址
客戶端並非一定要使用DHCP服務，它可以通過靜態指定的方式來設置IP位址。如果隨便指定的話，
將會大大提高網絡IP地址衝突的可能性。

二、DHCP Snooping技術介紹

DHCP監聽（DHCP Snooping）是一種DHCP安全特性。Cisco交換機支持在每個VLAN上啟用
DHCP監聽特性。通過這種特性，交換機能夠攔截第二層VLAN域內的所有DHCP資料。
DHCP監聽將交換機埠劃分為兩類
非信任埠：通常為連接終端設備的埠，如PC，網絡列印機等
信任埠：連接合法DHCP服務器的埠或者連接匯聚交換機的上行埠
通過開啟DHCP監聽特性，交換機限制用戶埠（非信任埠）只能夠發送DHCP請求，丟棄來自
用戶埠的所有其它DHCP資料，例如DHCP Offer資料等。而且，並非所有來自用戶埠的DHCP請求
都被允許通過，交換機還會比較DHCP 請求資料的（資料表頭裏的）來源MAC地址和（資料內容裏的）
DHCP客戶機的硬體位址（即CHADDR欄位），只有這兩者相同的請求資料才會被轉發，否則將被丟棄。
這樣就防止了DHCP耗竭攻擊。
信任埠可以接收所有的DHCP資料。通過只將交換機連接到合法DHCP服務器的埠設置為信任端
口，其他埠設置為非信任埠，就可以防止用戶偽造DHCP服務器來攻擊網絡。
DHCP監聽特性還可以對埠的DHCP資料進行限速。通過在每個非信任埠下進行限速，將可以阻
止合法DHCP請求資料的廣播攻擊。
DHCP監聽還有一個非常重要的作用就是建立一張DHCP監聽綁定表（DHCP Snooping Binding）。一
旦一個連接在非信任埠的客戶端獲得一個合法的DHCP Offer，交換機就會自動在DHCP監聽綁定表裏
添加一個綁定條目，內容包括了該非信任埠的客戶端IP位址、MAC位址、埠號、VLAN編號、租期等信
息。如：
Switch#show ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
—————— ————— ———- ————- —- —————-
00:0F:1F:C5:10:08 192.168.10.131 682463 dhcp-snooping 10 FastEthernet0/1
這張DHCP監聽綁定表為進一步部署IP源防護（IPSG）和動態ARP檢測（DAI）提供了依據。
說明：
I. 非信任埠只允許客戶端的DHCP請求資料通過，這裏只是相對於DHCP資料來說的。其他非
DHCP資料還是可以正常轉發的。這就表示客戶端可以以靜態指定IP位址的方式通過非信任埠接入網絡。
由於靜態客戶端不會發送DHCP資料，所以DHCP監聽綁定表裏也不會有該靜態客戶端的記錄。
信任埠的客戶端資訊不會被記錄到DHCP監聽綁定表裏。如果有一客戶端連接到了一個信任埠，
即使它是通過正常的DHCP方式獲得IP位址，DHCP監聽綁定表裏也不有該客戶端的記錄。
如果要求客戶端只能以動態獲得IP的方式接入網絡，則必須借助於IPSG和DAI技術。
II.交換機為了獲得高速轉發，通常只檢查資料的二層表頭，獲得目標MAC地址後直接轉發，不會去
檢查資料的內容。而DHCP監聽本質上就是開啟交換機對DHCP資料的內容部分的檢查，DHCP資料不再
只是被檢查訊框表頭了。
III. DHCP監聽綁定表不僅用於防禦DHCP攻擊，還為後續的IPSG和DAI技術提供動態數據庫支援。
IV. DHCP監聽綁定表裏的Lease列就是每個客戶端對應的DHCP租約時間。當客戶端離開網絡後，該
條目並不會立即消失。當客戶端再次接入網絡，重新發起DHCP請求以後，相應的條目內容就會被更新。
如上面的000F.1FC5.1008這個客戶端原本插在Fa0/1埠，現在插在Fa0/3埠，相應的記錄在它再
次發送DHCP請求並獲得位址後會更新為：
Switch#show ip dhcp snooping binding
MacAddress 　　　　　IpAddress　　Lease(sec) 　　Type 　　VLAN 　　　Interface
—————— 　　　————— 　　———- 　　————-　　 —- 　　—————-
00:0F:1F:C5:10:08 192.168.10.131 　691023 　　dhcp-snooping 10 　　FastEthernet0/3
V.當交換機收到一個DHCPDECLINE或DHCPRELEASE廣播資料，並且資料頭的源MAC地址存在
於DHCP監聽綁定表的一個條目中。但是資料的實際接收埠與綁定表條目中的埠欄位不一致時，該資料將被丟棄。
DHCPRELEASE 資料：此資料是客戶端主動釋放IP 位址（如Windows 客戶端使用ipconfig/release），
當DHCP服務器收到此資料後就可以收回IP位址，分配給其他的客戶端了
DHCPDECLINE資料：當客戶端發現DHCP服務器分配給它的IP位址無法使用（如IP位址發生衝突）
時，將發出此資料讓DHCP服務器禁止使用這次分配的IP位址。

VI. DHCP監聽綁定表中的條目可以手工添加。
VII. DHCP監聽綁定表在設備重啟後會丟失，需要重新綁定，但可以通過設置將綁定表保存在flash
或者tftp/ftp服務器上，待設備重啟後直接讀取，而不需要客戶端再次進行綁定
VIII. 當前主流的Cisco交換機基本都支援DHCP Snooping功能。

三、DHCP Option 82

當DHCP服務器和客戶端不在同一個子網內時，客戶端要想從DHCP服務器上分配到IP地址，就必
須由DHCP中繼代理（DHCP Relay Agent）來轉發DHCP請求包。DHCP中繼代理將客戶端的DHCP資料
轉發到DHCP服務器之前，可以插入一些選項資訊，以便DHCP服務器能更精確的得知客戶端的資訊，
從而能更靈活的按相應的策略分配IP位址和其他參數。這個選項被稱為：DHCP relay agent information
option（中繼代理資訊選項），選項號為82，故又稱為option 82，相關標準文檔為RFC3046。Option 82是
對DHCP選項的擴展應用。
選項82只是一種應用擴展，是否攜帶選項82並不會影響DHCP原有的應用。另外還要看DHCP服務
器是否支持選項82。不支持選項82的DHCP服務器接收到插入了選項82的資料，或者支持選項82的
DHCP服務器接收到了沒有插入選項82的資料，這兩種情況都不會對原有的基本的DHCP服務造成影響。
要想支援選項82帶來的擴展應用，則DHCP服務器本身必須支持選項82以及收到的DHCP資料必須被
插入選項82資訊。
從非信任埠收到DHCP請求資料，不管DHCP服務器和客戶端是否處於同一子網，開啟了DHCP
監聽功能的Cisco交換機都可以選擇是否對其插入選項82資訊。默認情況下，交換機將對從非信任埠接
收到的DHCP請求資料插入選項82資訊。
當一臺開啟DHCP監聽的分配層交換機和一臺插入了選項82資訊的邊界(存取層)交換機（接入交換機）相連時：
如果邊界交換機是連接到分配層交換機的信任埠，那麽匯聚交換機會接收從信任埠收到的插入選
項82的DHCP資料資訊，但是分配層交換機不會為這些資訊建立DHCP監聽綁定表條目。
如果邊界交換機是連接到分配層交換機的非信任埠，那麽分配層交換機會丟棄從該非信任埠收到的
插入了選項82的DHCP資料資訊。

但在IOS 12.2（25）SE版本之後，分配層交換機可以通過在全域模式下
配置一條ip dhcp snooping information allow-untrusted命令。這樣匯聚交換機就會接收從邊界交換機發來的
插入選項82的DHCP資料資訊，並且也為這些資訊建立DHCP監聽綁定表條目。
在配置分配層交換機下聯口時，將根據從邊界交換機發送過來的數據能否被信任而設置為信任或者非
信任埠。

四、DHCP Snooping的配置

Switch(config)#ip dhcp snooping
//全域命令；打開DHCP Snooping功能
Switch(config)#ip dhcp snooping vlan 10
//全域命令；設置DHCP Snooping功能將作用於哪些VLAN
Switch(config)#ip dhcp snooping verify mac-address
//全域命令；
//檢測非信任埠收到的DHCP請求資料的源MAC和CHADDR欄位是否相同，以防止DHCP耗竭攻擊
//該功能默認即為開啟
Switch(config-if)#ip dhcp snooping trust
//介面級命令；配置介面為DHCP監聽特性的信任介面
//所有介面默認為非信任介面
Switch(config-if)#ip dhcp snooping limit rate 15
//介面級命令；限制非信任埠的DHCP資料速率為每秒15個包；
//如果不配該語句，默認即為每秒15個包，但show ip dhcp snooping的結果裏將不列出沒有該語句的埠
//可選速率範圍為1-2048
建議：在配置了埠的DHCP資料限速之後，最好配置以下兩條命令
Switch(config)#errdisable recovery cause dhcp-rate-limit
//使由於DHCP資料限速原因而被禁用的埠能自動從err-disable狀態恢復
Switch(config)#errdisable recovery interval 30
//設置恢復時間；埠被置為err-disable狀態後，經過30秒時間才能恢復
Switch(config)#ip dhcp snooping information option
//全域命令；設置交換機是否為非信任埠收到的DHCP資料插入Option 82
//默認即為開啟狀態
Switch(config)#ip dhcp snooping information option allow-untrusted
//全域命令；設置匯聚交換機將接收從非信任埠收到的接入交換機發來的帶有選項82的DHCP資料
Switch#ip dhcp snooping binding 000f.1fc5.1008 vlan 10 192.168.10.131 interface fa0/2 expiry 692000
//特權模式命令；手工添加一條DHCP監聽綁定條目；expiry為時間值，即為監聽綁定表中的lease（租期）
Switch(config)#ip dhcp snooping database flash:dhcp_snooping.db
//全域命令；將DHCP監聽綁定表保存在flash中，檔案名為dhcp_snooping.db
Switch(config)#ip dhcp snooping database tftp://192.168.2.5/Switch/dhcp_snooping.db
//全域命令；將DHCP監聽綁定表保存到tftp服務器；192.168.2.5為tftp服務器地址，必須事先確定可達。
//URL中的Switch是tftp服務器下一個文件夾；保存後的檔案名為dhcp_snooping.db
說明：當更改保存位置後會立即執行"寫"操作。
Switch(config)#ip dhcp snooping database write-delay 30
//全域命令；指DHCP監聽綁定表發生更新後，等待30秒，再寫入檔；
//默認為300秒；可選範圍為15-86400秒
Switch(config)#ip dhcp snooping database timeout 60
//全域命令；指DHCP監聽綁定表嘗試寫入操作失敗後，重新嘗試寫入操作，直到60秒後停止嘗試。
//默認為300秒；可選範圍為0-86400秒
說明：實際上當DHCP監聽綁定表發生改變時會先等待write-delay的時間，然後執行寫入操作，如果寫
入操作失敗（比如tftp服務器不可達），接著就等待timeout的時間，在此時間段內不斷重試。在timeout
時間過後，停止寫入嘗試。但由於監聽綁定表已經發生了改變，因此重新開始等待write-delay時間執行寫
入操作……不斷循環，直到寫入操作成功。
Switch#renew ip dhcp snooping database flash:dhcp_snooping.db
//特權級命令；立即從保存好的數據庫文件中讀取DHCP監聽綁定表。

五、顯示DHCP Snooping的狀態

Switch#show ip dhcp snooping
//顯示當前DHCP監聽的各選項和各埠的配置情況
Switch#show ip dhcp snooping binding
//顯示當前的DHCP監聽綁定表
Switch#show ip dhcp snooping database
//顯示DHCP監聽綁定數據庫的相關信息
Switch#show ip dhcp snooping statistics
//顯示DHCP監聽的工作統計
Switch#clear ip dhcp snooping binding
//清除DHCP監聽綁定表；
//註意：本命令無法對單一條目進行清除，只能清除所有條目
Switch#clear ip dhcp snooping database statistics
//清空DHCP監聽綁定數據庫的計數器
Switch#clear ip dhcp snooping statistics
//清空DHCP監聽的工作統計計數器

六、DHCP Snooping的實例

1、單交換機（DHCP服務器和DHCP客戶端位於同一VLAN）

環境：Windows2003 DHCP服務器和客戶端都位於vlan 10；服務器接在fa0/1，客戶端接在fa0/2
2960交換機相關配置：
ip dhcp snooping vlan 10
ip dhcp snooping
!
interface FastEthernet0/1
description : Connect to Win2003 DHCP Server
switchport access vlan 10
switchport mode access
spanning-tree portfast
ip dhcp snooping trust
!
interface FastEthernet0/2
description : Connect to DHCP Client
switchport access vlan 10
switchport mode access
spanning-tree portfast
ip dhcp snooping limit rate 15
說明：本例中交換機對於客戶端的DHCP 請求資料將插入選項82 資訊；也可以通過配置no ip dhcp
snooping information option命令選擇不插入選項82資訊。兩種情況都可以。
客戶端埠推薦配置spanning-tree portfast命令，使得該埠不參與生成數計算，節省埠啟動時間，
防止可能因為埠啟動時間過長導致客戶端得不到IP地址。
開啟DHCP監聽特性的vlan並不需要該vlan的三層介面被創建。

2、單交換機（DHCP服務器和DHCP客戶端位於同一VLAN）

環境：Cisco IOS DHCP服務器（2821路由器）和PC客戶端都位於vlan 10；路由器接在交換機的fa0/1，
客戶端接在fa0/2
Windows2003
DHCP Server DHCP Client
2960
CiscoIOS
DHCP Server
2960 DHCP Client
2960交換機相關配置：
ip dhcp snooping vlan 10
ip dhcp snooping
!
interface FastEthernet0/1
description : Connect to IOS DHCP Server C2821_Gi0/0
switchport access vlan 10
switchport mode access
spanning-tree portfast
ip dhcp snooping trust
!
interface FastEthernet0/2
description : Connect to DHCP Client
switchport access vlan 10
switchport mode access
spanning-tree portfast
ip dhcp snooping limit rate 15

2821路由器相關配置：
ip dhcp excluded-address 192.168.10.1 192.168.10.2
!
ip dhcp pool test
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
lease 8
!
interface GigabitEthernet0/0
description : Connect to C2960_Fa0/1
ip dhcp relay information trusted
ip address 192.168.10.2 255.255.255.0
說明：
I、需要註意的是路由器連接到交換機的埠需要配置ip dhcp relay information trusted，否則客戶端將
無法得到IP地址。
這是因為交換機配置了（默認情況）ip dhcp snooping information option，此時交換機會在客戶端發出
的DHCP請求資料中插入選項82資訊。另一方面由於DHCP服務器（這裏指Cisco IOS DHCP服務器）與
客戶端處於同一個VLAN中，所以請求實際上並沒有經過DHCP中繼代理。
對於Cisco IOS DHCP服務器來說，如果它收到的DHCP請求被插入了選項82資訊，那麽它會認為
這是一個從DHCP中繼代理過來的請求資料，但是它檢查了該資料的giaddr欄位卻發現是0.0.0.0，而不
是一個有效的IP位址（DHCP請求資料中的giaddr欄位是該資料經過的第一個DHCP中繼代理的IP位址，
具體請參考DHCP資料格式），因此該資料被認為"非法"，所以將被丟棄。可以參考路由器上的DHCP
的debug過程。
Cisco IOS裏有一個命令，專門用來處理這類DHCP請求資料：ip dhcp relay information trusted（介面
命令）或者ip dhcp relay information trust-all（全域命令，對所有路由器介面都有效）；這兩條命令的作用
就是允許被插入了選項82資訊，但其giaddr欄位為0.0.0.0的DHCP請求資料通過。
II、如果交換機不插入選項82資訊，即配置了no ip dhcp relay information trusted，那麽就不會出現客
戶端無法得到IP位址的情況，路由器也不需要配置ip dhcp relay information trusted命令。
III、Windows DHCP服務器應該沒有檢查這類DHCP請求的機制，所以上一個實例中不論交換機是否
插入選項82資訊，客戶端總是可以得到IP位址。

3、單交換機（DHCP服務器和DHCP客戶端位於不同VLAN）

環境：Cisco IOS DHCP服務器（2821路由器）的IP地址為192.168.2.2，位於vlan 2；DHCP客戶端位於
vlan 10；交換機為3560，路由器接在fa0/1，客戶端接在fa0/2
3560交換機相關配置：
ip routing
！
ip dhcp snooping vlan 2,10
ip dhcp snooping
!
interface FastEthernet0/1
description : Connect to IOS DHCP Server C2821_Gi0/0
switchport access vlan 2
switchport mode access
spanning-tree portfast
ip dhcp snooping trust
!
interface FastEthernet0/2
description : Connect to DHCP Client
switchport access vlan 10
switchport mode access
spanning-tree portfast
ip dhcp snooping limit rate 15
!
interface Vlan2
ip address 192.168.2.1 255.255.255.0
!
interface Vlan10
ip address 192.168.10.1 255.255.255.0
ip helper-address 192.168.2.2
CiscoIOS
DHCP Server
3560 DHCP Client

2821路由器相關配置：
no ip routing
!
ip dhcp excluded-address 192.168.10.1 192.168.10.2
!
ip dhcp pool test
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
lease 8
!
interface GigabitEthernet0/0
description : Connect to C3560_Fa0/1
ip address 192.168.2.2 255.255.255.0
!
ip default-gateway 192.168.2.1
說明：本例中的路由器不需要配置ip dhcp relay information trusted命令，因為從交換機過來的DHCP請求
經過了中繼代理，其資料中的giaddr欄位為192.168.10.1，而不是0.0.0.0，是默認正常的DHCP請求資料。

4、多交換機環境（DHCP服務器和DHCP客戶端位於不同VLAN）

環境：2611路由器作為DHCP服務器，IP地址為192.168.2.2，位於vlan 2；PC位於vlan 10；
路由器接在3560的Gi0/2，PC接2960的fa0/1口，兩交換機互連口都是gi0/1
3560交換機相關配置：
ip routing
！
interface GigabitEthernet0/1
description : Connect to C2960_Gi0/1
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet0/2
description : Connect to IOS DHCP Server C2611_Gi0/0
switchport access vlan 2
switchport mode access
spanning-tree portfast
!
interface Vlan2
ip address 192.168.2.1 255.255.255.0
!
PC
CIisco IOS 3560 2960
DHCP Server
interface Vlan10
ip address 192.168.10.1 255.255.255.0
ip helper-address 192.168.2.2
ip dhcp relay information trusted

2960交換機相關配置：
ip dhcp snooping vlan 10
ip dhcp snooping
interface FastEthernet0/1
description : Connect to PC
switchport access vlan 10
switchport mode access
spanning-tree portfast
ip dhcp snooping limit rate 15
！
interface GigabitEthernet0/1
description : Connect to C3560_Gi0/1
switchport mode trunk
ip dhcp snooping trust

2611路由器相關配置：
no ip routing
!
ip dhcp excluded-address 192.168.10.1 192.168.10.2
!
ip dhcp pool test
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
lease 8
!
interface GigabitEthernet0/0
description : Connect to C3560_Gi0/2
ip address 192.168.2.2 255.255.255.0
!
ip default-gateway 192.168.2.1
說明：本例中3560沒有開啟DHCP監聽功能，2960開啟了該功能。需要註意的是int vlan 10需要配置ip
dhcp relay information trusted，理由如同實例2。

5、多交換機環境（DHCP服務器和DHCP客戶端位於同一VLAN）
環境：3560交換機自身作為DHCP服務器；PC1和PC2都位於vlan 10；
PC1接3560的fa0/1口，PC2接2960的fa0/1口；兩交換機互連口都是gi0/1
3560交換機相關配置：
ip dhcp excluded-address 192.168.10.1
!
ip dhcp pool test
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
lease 8
!
ip dhcp snooping vlan 10
ip dhcp snooping information option allow-untrusted
ip dhcp snooping
!
interface FastEthernet0/1
description : Connect to PC1
switchport access vlan 10
switchport mode access
spanning-tree portfast
ip dhcp snooping limit rate 15
!
interface GigabitEthernet0/1
description : Connect to C2960_Gi0/1
switchport trunk encapsulation dot1q
switchport mode trunk
ip dhcp snooping limit rate 360
2960交換機相關配置：
ip dhcp snooping vlan 10
ip dhcp snooping
interface FastEthernet0/1
description : Connect to PC2
switchport access vlan 10
switchport mode access
spanning-tree portfast
ip dhcp snooping limit rate 15
PC1
PC2
3560
2960
！
interface GigabitEthernet0/1
description : Connect to C3560_Gi0/1
switchport mode trunk
ip dhcp snooping trust
說明：本例中3560和2960同時開啟了DHCP監聽功能。從2960過來的DHCP請求資料是已經被插入了選
項82資訊，如果將3560的Gi0/1設置為信任埠，那麽插入了82選項的DHCP請求資料是允許通過的，
但不會為其建立DHCP監聽綁定表。即3560上只有PC1的綁定條目，而沒有PC2的綁定條目。
如果此時同時部署DAI，IPSG，由於2960不支援這兩項功能，對於3560來說，從2960上過來的數
據可能存在IP欺騙和ARP欺騙等攻擊，是不安全的。另一方面，由於3560沒有PC2的綁定條目，而DAI
和IPSG必須依賴DHCP監聽綁定表。因此如果需要在3560上再部署DAI或者IPSG，就不能將3560的
Gi0/1設置為信任埠。
但是將3560的Gi0/1口設置為非信任埠以後，默認情況下，非信任埠將會丟棄收到的插入了82
選項的DHCP請求資料。而從2960過來的DHCP請求資料又正好是被插入了選項82資訊的。因此必須配
置ip dhcp snooping information option allow-untrusted命令，否則3560將丟棄這些DHCP請求資料，接在
2960上的PC2將得不到IP地址。只有配置了該命令以後，3560才會接收從2960發送的插入了選項82的
DHCP資料，並為這些資訊建立綁定條目。
3560下聯的Gi0/1口由於是非信任埠，默認限速為每秒15個DHCP請求資料，如果2960上的所有
PC都同時發起DHCP請求，可能此埠會被errdisable掉。這裏假設2960為24口，因此簡單的設置限速
為24*15=360。
2960上聯的Gi0/1口必須被配置為信任埠，否則將丟棄從3560過來的DHCP應答資料，PC2將無
法得到IP地址。
C3560#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10
DHCP snooping is operational on following VLANs:
10
DHCP snooping is configured on the following L3 Interfaces:
Insertion of option 82 is enabled
circuit-id format: vlan-mod-port
remote-id format: MAC
Option 82 on untrusted port is allowed
Verification of hwaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:
Interface 　　　　　　Trusted 　　　Rate limit (pps)
———————— 　　——-　　　 —————-
FastEthernet0/1 　　　　no 　　　　　　15
GigabitEthernet0/1 　　　no 　　　　　　360

C3560#show ip dhcp snooping binding
MacAddress 　　　IpAddress　　 Lease(sec) 　　Type　　　 VLAN 　　　Interface
—————— 　　—————　　 ———- 　　————- 　　—-　　 ——————–
00:0F:1F:C5:10:08 192.168.10.2 　685618 　dhcp-snooping 　10 　　　FastEthernet0/1
00:0B:DB:08:21:E0 192.168.10.3 　688023 　dhcp-snooping 　10 　　　GigabitEthernet0/1

C2960#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10
Insertion of option 82 is enabled
circuit-id format: vlan-mod-port
remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Interface 　　　　　　Trusted 　　　Rate limit (pps)
———————— 　　——- 　　　　—————-
FastEthernet0/1 　　　　no 　　　　　　　15
GigabitEthernet0/1 　　　yes 　　　　　unlimited

C2960#show ip dhcp snooping binding
MacAddress 　　IpAddress 　　Lease(sec) 　　Type 　　VLAN I　　nterface
—————— 　————— 　　———- 　　————-　　—- 　　——————–
00:0B:DB:08:21:E0 192.168.10.3 688023 　dhcp-snooping 　10　　 FastEthernet0/1

6、多交換機環境（DHCP服務器和DHCP客戶端位於同一VLAN）

環境：4503交換機自身作為DHCP服務器；PC1和PC2都位於vlan 10；
PC1接4503的gi2/1口，PC2接3560的fa0/1口；兩交換機互連口是4503 gi1/1 — 3560 gi0/1
4503交換機相關配置：
ip dhcp excluded-address 192.168.10.1
!
ip dhcp pool test
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
lease 8
!
ip dhcp snooping vlan 10
ip dhcp snooping
!
interface GigabitEthernet2/1
PC1
PC2
4503
3560
description : Connect to PC1
switchport access vlan 10
switchport mode access
spanning-tree portfast
ip dhcp snooping limit rate 15
!
interface GigabitEthernet1/1
description : Connect to C3560_Gi0/1
switchport trunk encapsulation dot1q
switchport mode trunk
ip dhcp snooping trust

3560交換機相關配置：
ip dhcp snooping vlan 10
ip dhcp snooping
interface FastEthernet0/1
description : Connect to PC2
switchport access vlan 10
switchport mode access
spanning-tree portfast
ip dhcp snooping limit rate 15
！
interface GigabitEthernet0/1
description : Connect to C4503_Gi1/1
switchport trunk encapsulation dot1q
switchport mode trunk
ip dhcp snooping trust
說明：本例中4503和3560同時開啟了DHCP監聽功能。由於4503的下聯口被設置為信任埠，所以從
3560過來的DHCP請求資料即使已經被插入了選項82資訊，也允許通過的，但不會為其建立DHCP監聽
綁定表。所以4503上只有PC1的綁定條目，而沒有PC2的綁定條目。
作為接入層交換機的3560支持DAI，IPSG，如果同時配置這兩項功能，那麽有理由相信從3560過
來的數據是已經經過檢驗的安全數據，因此將4503的下聯口設置為信任埠是可行的。另外，4503沒有
PC2的綁定條目，也減少了系統運行時所需的內存空間。
C4503#show ip dhcp snooping binding
MacAddress 　　I　pAddress 　　Lease(sec) 　　Type 　　　VLAN 　　Interface
—————— 　　—————　　 ———- 　　————-　 　—- 　　——————–
00:0F:1F:C5:10:08 192.168.10.2 　685618 　dhcp-snooping 　10 　　GigabitEthernet2/1
C3560#show ip dhcp snooping binding
MacAddress 　　　　　IpAddress 　Lease(sec) 　　Type　　 　　VLAN　　　 Interface
—————— 　　　————— 　　———- 　　————- 　　　—- 　　——————–
00:0B:DB:08:21:E0 192.168.10.3 　　688023 　　dhcp-snooping 　10 　　FastEthernet0/1

Cisco IOS Error Message解釋

2月2日

Cisco IOS Error Message解釋

        三不五時要對cisco的網路設備做debug及troubleshooting…看了一堆的log message,一般人常不瞭到底怎麼看.下面是這些麻煩的log的解釋.

錯誤消息格式

    系統錯誤消息格式如下：
　　
    %Facility – subfacility – Severity – Mnemonic ： Message Text
　　
    Facility 它指出錯誤消息涉及的設備名。該值可以是協定、硬體設備或者系統軟體模組。　　
    Subfacility 它僅與通道介面處理器(CIP)卡有關。　　
    Severity 它是一個範圍在0到7之間的數字。數字的值越小，嚴重程度越高。　　
    Mnemonic 唯一標識錯誤消息的單值代碼。該代碼通常可以暗示錯誤的類型。　　
    Message Text 它是錯誤消息的簡短描述，其中包括涉及的路由器硬體和軟體資訊。

 
 

　　下面是一些錯誤消息的示例。用戶可以查閱CCO ISO文檔的系統錯誤消息一節，以查找這些錯誤消息的說明。

    %DUAL-3-SIA：Route 171.155.148.192/26 stuck-in-active state in IP-EIGP 211. Cleaning up　　

    %LANCE-3-OWNERR: Unit 0, buffer ownership error

　　需要注意的是，並不是所有的消息都涉及到故障或者問題的狀況。某些消息顯示的是狀態方面的資訊。例如，

    以下消息僅表明ISDN  BRI 0介面與特定的遠端資料連接。

    %ISDN-6-CONNECT: Interface BRI0 is now connected to 95551212

　　
 

    Traceback Report

    某些與路由器內部錯誤相關的錯誤消息包含了traceback資訊。在向Cisco TAC報告錯誤時，應在錯誤描述中加入這些資訊。

    錯誤消息和事件資訊的日誌

    根據錯誤消息的重要性和有效性，Cisco錯誤消息可以被記錄到以下位置：

　　控制臺
　　虛擬終端
　  Syslog伺服器
　　內部緩衝區

　　
 

    logging on命令使日誌消息的輸出到上述位置。對於Syslog伺服器，必須使用下述全局配置命令指明伺服器的IP位址：

  　logging ip-address

　　通過反覆使用這一命令，可以建立一個伺服器的列表。在管理大型網路時，通常需要設置syslog server。

　　
 

    logging buffered命令用於將日誌資訊發送到內部緩衝區。緩衝區的大小必須在4096位元組以上。

    預設值根據系統平臺的不同而不同。用戶需要選擇適合環境的緩衝區大小。如果緩衝區太小，新的消息將會覆蓋舊的消息。

    有可能會導致問題。但是，如果緩衝區大小過大將會浪費系統緩存。

    no logging buffered命令將禁止消息被寫入內部緩存。

　　用戶可以使用show logging命令顯示內部緩衝區的內容。如果用戶需要某一時間段的資訊，首先使用NTP或者手工設置時鐘，

    具體操作為：
　　YH-Router#clock set 11:37:00 December 2000
　　YH-Router#sh clock
　　11:37:03.596 PST Fri Dec 11 2000

　　日誌消息的時間戳和調試資訊可以使用以下全局配置命令：
　　YH-Router (config)#service timestamps log datetime
　　YH-Router (config)#service timestamps debug datetime

　　terminal monitor命令將在當前終端上顯示調試時的日誌資訊。該命令不是一個配置命令。相反，它可以通過telnet

    到路由器時在命令行方式下使用。

　　在大多數情況下，用戶可能需要顯示某一級別的日誌資訊。因此，日誌資訊被分為八個不同的級別，

    按照重要程度由高到低排列如下：
　　 Emergencies
　　 Alerts
　　 Critical
　　 Errors
　　 Warnings
　　 Notifications
　　 Informational
　　 Debugging

　　例如，需要在控制臺上顯示嚴重程度等於或者大於警告(Warning)的所有日誌資訊，可以使用下述全局配置命令：
　　logging console warning

　　類似的，將某種類型的日誌資訊發送到當前的終端時，使用
　　logging monitor level

　　或者將資訊發送到Syslog伺服器時使用
　　logging trap level

　　與terminal monitor命令不同，logging monitor命令是路由器配置的一部分。前一種命令不允許在不同的安全級別下執行。

　　需要注意的是，將日誌記錄到不同的位置時，系統開銷變化很大。將日誌記錄到控制臺的開銷比較大，

    然而將日誌記錄到虛擬終端時開銷較小。使用Syslog伺服器時開銷更小。系統開銷最小的日誌寫入方式是寫入內部緩衝區。

核心轉儲(Core Dump)

    為了查找路由器崩潰的原因，我們可以使用許多命令來獲取有效的資訊。其中我們已經講解了show stacks命令的用法。

    核心轉儲是系統記憶體映象的拷貝，它可以被寫入到TFTP伺服器中。從這個二進位檔中，我們可以獲得與路由器崩潰或者

    嚴重誤操作相關的資訊，通過這些資訊可以排除可能的故障。

　　下麵的配置命令將核心轉儲寫入到命令中IP位址對應的TFTP伺服器上：
　　exception dump ip-address

　　write core命令通常用於路由器發生嚴重的誤操作但是沒有完全崩潰時，保存核心映射。

　　只有運行IOS v 9.0或更高版本的伺服器才可以使用核心轉儲。但是，需要注意的是，在使用核心轉儲時，

    最好獲取有經驗的工程師或者Cisco TAC的支持。

    結束語

    要順利地診斷並排除網路故障，網路工程技術人員必須掌握兩種基本的技能。首先是對網路技術和協議要有清楚的理解，

    它是診斷與排除網路故障的基礎。沒有適當的知識和經驗，故障診斷與排除工具比如路由器診斷命令和網路分析儀都不能

    發揮其作用。

　　網路工程技術人員必須掌握的第二種技能是將所掌握的知識以有條理的方式應用於診斷和排除網路故障的過程中。

    本文雖然只闡述了一些診斷的命令，但需要強調的是：故障診斷與排除是一種結構化的方法。許多工程技術人員認為故障

    診斷與排除計畫不如研究和應用技術本身重要。事實上，正確的計畫在故障診斷與排除過程中往往起決定性的作用。

    在故障排除過程中，一個偶然的行為可能使故障得以順利解決，但是它不能替代結構化的故障診斷與排除方法。

　　網路故障的排除是一項系統工程，應該經過定義問題、搜集事實、基於事實考慮可能性、建立行動計畫、實施計畫、

    觀察結果和迴圈過程等步驟，這一過程就如同軟體發展過程的瀑布模型，其重要性是不言而喻的。

IPv6 介面識別元

IPv6 介面識別元

IPv6 interface identifiers

IPv6 位址的最後 64 個位元，是 IPv6 位址的 64 位元首碼的專用介面識別元。介面識別元有下列幾種決定方式：

• RFC 2373 表示所有使用首碼 001 到 111 的單點傳送位址，必須同時使用從 Extended Unique Identifier (EUI)-64 位址衍生出來的 64 位元介面 ID。
  
• RFC 3041 會描述的隨機產生的介面識別元，會隨著時間變更來提供匿名層次。
  
• 自動設定非自動式位址 (例如，透過 DHCPv6) 時指派的介面識別元。目前正在定義 DHCPv6 標準。Windows Server 2003 系列及 Windows XP 的 IPv6 通訊協定不支援可以設定狀況的位址設定或 DHCPv6。
  
• 手動設定的介面識別元。
  

EUI-64 address-based interface identifiers

64 位元 EUI-64 位址是由 Institute of Electrical and Electronic Engineers (IEEE) 定義。EUI-64 位址是指派給網路介面卡或是衍生自 IEEE802 位址。

IEEE 802 addresses

網路介面卡的傳統介面識別元使用的 48 位元位址稱做 IEEE 802 位址。這個位址中包含一個 24 位元的公司 ID (又稱做製造商 ID) 和一個 24 位元的延伸識別元 (又稱做介面板識別元)。裡面有專門指派給每個網路介面卡及的公司 ID 以及組合時專門指派給每個網路介面卡的介面板識別元，形成全球唯一的 48 位元位址。這個 48 位元位址又稱做實體、硬體或媒體存取控制 (MAC) 位址。

IEEE 802 位址中定義了下列位元：

• 萬用/本機 (U/L)
  U/L 位元是第一個位元組的第 7 個位元，可以決定這個位址是以萬用或本機方式管理。如果 U/L 位元設定為 0，表示 IEEE 是透過設計專用公司 ID 來管理這個位址。如果 U/L 位元設定為 1，表示是以本機方式來管理這個位址。網路系統管理員覆蓋了製造位址，並且指定了不同的位址。
  
• 個別/群組 (I/G)
  I/G 位元是第一個位元組的低階位元，可以決定這個位址是個別位址 (單點傳送) 還是群組位址 (多點傳送)。如果設定為 0，表示這個位址是單點傳送位址。如果設定為 1，表示這個位址是多點傳送位址。
  

一般 802.x 網路介面卡位址的 U/L 及 I/G 位元都設定為 0，對應以萬用方式管理的單點傳送 MAC 位址。

(note: ICND COURSE UG/IL BITS IS WRONG)

IEEE EUI-64 addresses

IEEE EUI-64 位址代表網路介面位址設定的新標準。公司 ID 的長度仍然是 24 個位元，但是延伸識別元是 40 個位元，為網路介面卡製造商建立較大的位址空間。EUI-64 位址使用與 IEEE 802 位址相同方式的 U/L 及 I/G 位元。

Mapping IEEE 802 addresses to EUI-64 addresses

若要根據 IEEE 802 位址來建立 EUI-64 位址，必須將 16 個位元的 11111111 11111110 (0xFFFE) 插入到公司 ID 及延伸識別元之間的 IEEE 802 位址中。下圖說明 IEEE 802 位址如何轉換到 EUI-64 位址。

Mapping EUI-64 addresses to IPv6 interface identifiers

若要取得 IPv6 單點傳送位址的 64 位元介面，必須在 EUI-64 位址中補充 U/L 位元 (若是 1，設定為 0；若是 0，設定為 1)。下圖說明如何轉換以萬用方式管理的單點傳送 EUI-64 位址。

若要從 IEEE 802 位址取得 IPv6 介面識別元，您必須先將 IEEE 802 位址對應到 EUI-64 位址，再來補充 U/L 位元。下圖說明如何轉換以萬用方式管理的單點傳送 IEEE 802 位址。

IEEE 802 address conversion example

主機有 Ethernet MAC 位址 00-AA-00-3F-2A-1C。首先，它在第 3 和第 4 個位元組之間插入 FF-FE，產生 00-AA-00-FF-FE-3F-2A-1C，轉換成 EUI-64 格式。接著，在第 1 個位元組中補充第 7 個位元 U/L。二進位格式的第 1 個位元組是 00000000。補充第 7 個位元後，就成為 00000010 (0x02)。最後的結果是 02-AA-00-FF-FE-3F-2A-1C，轉換成冒號十六進位表示法後就成為介面識別元 2AA:FF:FE3F:2A1C。最後，對應到網路介面卡 (搭配 MAC 位址 00-AA-00-3F-2A-1C) 的連結本機位址是 FE80::2AA:FF:FE3F:2A1C。

附註

• 補充 U/L 位元時，如果 EUI-64 位址是以萬用方式管理，請將 0x2 新增到第 1 個位元組。
  

 

 

 

 

 

 

 

 

Some unofficial notes on IPv6 prefixes and address

Updated: 2006-06-18
Created: 2003-12-18

Addressing information from many sources, like:

• IPv6 Bogon List.
  
• draft-ietf-ipv6-deprecate-site-local-02.
  
• IANA ipv6-tla-assignments
  
• RFC 2928
  
• RFC 2373
  
• RFC 2374
  

General note on unicast addresses: the first 16 bits are the TLA, the next 8 bits must be zero, then 24 bits of NLA (48 bits total), 16 bits of SLA (64 bits total), and 64 bits for the interface.

Also, there are issues on internet-wide routes and the length of prefixes. Someone has written some recommendations which illustrate what is expected to be routeable.

The table below is exhaustive.

IPv6 unicast and anycast address ranges
Prefix	Up to	Notes
0000::/8	00ff::/8	Reserved
0000::0/128	0000::0/128	node local: unspecified address
0000::1/128	0000::1/128	node local: localhost
0000::0000:0000:0000/96	0000::0000:ffff:ffff/96	IPv4 compatible
0000::ffff:0000:0000/96	0000::ffff:ffff:ffff/96	IPv4 mapped
0100::/8	01ff::/8	unassigned
0200::/7	03ff::/7	NSAP
0400::/7	05ff::/7	IPX (obsolete)
0600::/7	06ff::/7	unassigned
0800::/5	0fff::/5	unassigned
1000::/4	1fff::/4	unassigned
2000::/3	3fff::/3	aggregatable global
2000:0000::/16	2000:ffff::/16	reserved
2001:0000:0000:/32	2001:0000:ffff:/32	Teredo, non Microsoft (official)
2001:0001::/32	2001:ffff::/32	sub TLAs
2001:0000::/23	2001:01ff::/23	sub TLAs: IANA
2001:0200::/23	2001:03ff::/23	sub TLAs: APNIC
2001:0400::/23	2001:04ff::/23	sub TLAs: ARIN
2001:0600::/23	2001:07ff::/23	sub TLAs: RIPE NCC
2001:0800::/23	2001:09ff::/23	sub TLAs: RIPE NCC
2001:0a00::/23	2001:0bff::/23	sub TLAs: RIPE NCC
2001:0c00::/23	2001:0dff::/23	sub TLAs: APNIC. Among these 2001:0db8::/32 is reserved for example addresses, and will not be allocated.
2001:0e00::/23	2001:0fff::/23	sub TLAs: APNIC
2001:1200::/23	2001:13ff::/23	sub TLAs: LACNIC
2001:1400::/23	2001:15ff::/23	sub TLAs: RIPE NCC
2001:1600::/23	2001:17ff::/23	sub TLAs: RIPE NCC
2001:1800::/23	2001:19ff::/23	sub TLAs: ARIN
2002:0000::/16	2002:ffff::/16	6to4
3ffe:0000::/16	3ffe:ffff::/16	6bone pseudo TLAs
3ffe:831f:0000:/32	3ffe:831f:ffff:/32	Teredo, Microsoft (experimental)
3fff:0000::/16	3fff:ffff::/16	reserved
4000::/3	5fff::/3	unassigned
6000::/3	7fff::/3	unassigned
8000::/3	9fff::/3	unassigned
a000::/3	bfff::/3	unassigned
c000::/3	dfff::/3	unassigned
e000::/4	efff::/4	unassigned
f000::/5	f7ff::/5	unassigned
f800::/6	f9ff::/6	unassigned
fa00::/7	fbff::/7	unassigned
fc00::/7	fdff::/7	unique local
fe00::/9	fe7f::/9	unassigned
fe80::/9	feff::/9	local
fe80:0000::/10	febf:0000::/10	link local
fec0:0000::/10	feff:0000::/10	site local (deprecated)

The multicast table below is exhaustive, except that any ranges not described in the fourth hex digit are reserved.

IPv6 multicast address ranges
Prefix	Up to	Notes
ff00::/8	ffff::/8	multicast
ff00::/12	ff0f::/12	well known
ff01::/16	ff01::/16	well known link local
ff02::/16	ff02::/16	well known site local
ff02:0:0:0:0:1:ff00::/104	ff02:0:0:0:0:1:ffff::/104	well known solicited-node
ff05::/16	ff05::/16	well known site local
ff08::/16	ff08::/16	well known organization local
ff0e::/16	ff0e::/16	well known global
ff10::/12	ff1f::/12	transient
ff11::/16	ff11::/16	transient link local
ff12::/16	ff12::/16	transient site local
ff15::/16	ff15::/16	transient site local
ff18::/16	ff18::/16	transient organization local
ff1e::/16	ff1e::/16	transient global
ff20::/12	ff2f::/12	unassigned
ff30::/12	ff3f::/12	RFC 3306 prefix based multicast
ff30:0000:0000:0000:0000:0000::/96	ff30:0000:0000:0000:0000:0000::/96	RFC 3306 source-specific multicast
ff70::/12	ff7f::/12	RFC 3956 embedded-RP multicast
ff40::/10	ffff::/10	unassigned

Special interface numbers in anycast addresses.

IPv6 unicast/anycast interfaces
Suffix	Notes
*:0000	Nearest router
*:fff7:ffff:ffff:ff80-ffff	Reserved anycast addresses (EUI-64)
*:fff7:ffff:ffff:fffe	Mobile IPv6 home-agents (EUI-64)
*:ffff:ffff:ffff:ff80-ffff	Reserved anycast addresses (non EUI-64)
*:ffff:ffff:ffff:fffe	Mobile IPv6 home-agents (non EUI-64)
fe80::c171:3a50	Nearest 6to4 gateway (193.113.58.80)

IPv6 multicast interfaces

Info from RFC 2375.

IPv6 multicast interfaces (group ids)
Suffix	Notes
ff0?::0000	reserved
ff0?::0100	VMTP Managers Group
ff0?::0101	Network Time Protocol (NTP)
ff0?::0102	SGI-Dogfight
ff0?::0103	Rwhod
ff0?::0104	VNP
ff0?::0105	Artificial Horizons – Aviator
ff0?::0106	NSS – Name Service Server
ff0?::0107	AUDIONEWS – Audio News Multicast
ff0?::0108	SUN NIS+ Information Service
ff0?::0109	MTP Multicast Transport Protocol
ff0?::010A	IETF-1-LOW-AUDIO
ff0?::010B	IETF-1-AUDIO
ff0?::010C	IETF-1-VIDEO
ff0?::010D	IETF-2-LOW-AUDIO
ff0?::010E	IETF-2-AUDIO
ff0?::010F	IETF-2-VIDEO
ff0?::0110	MUSIC-SERVICE
ff0?::0111	SEANET-TELEMETRY
ff0?::0112	SEANET-IMAGE
ff0?::0113	MLOADD
ff0?::0114	any private experiment
ff0?::0115	DVMRP on MOSPF
ff0?::0116	SVRLOC
ff0?::0117	XINGTV
ff0?::0118	microsoft-ds
ff0?::0119	nbc-pro
ff0?::011a	nbc-pfn
ff0?::011b	lmsc-calren-1
ff0?::011c	lmsc-calren-2
ff0?::011d	lmsc-calren-3
ff0?::011e	lmsc-calren-4
ff0?::011f	ampr-info
ff0?::0120	mtrace
ff0?::0121	RSVP-encap-1
ff0?::0122	RSVP-encap-2
ff0?::0123	SVRLOC-DA
ff0?::0124	rln-server
ff0?::0125	proshare-mc
ff0?::0126	dantz
ff0?::0127	cisco-rp-announce
ff0?::0128	cisco-rp-discovery
ff0?::0129	gatekeeper
ff0?::012a	iberiagames
ff0?::0201	“rwho" Group (BSD) (unofficial)
ff0?::0202	SUN RPC PMAPPROC_CALLIT
ff0?::0002:0000-7ffd	Multimedia Conference Calls
ff0?::0002:7ffe	SAPv1 Announcements
ff0?::0002:7fff	SAPv0 Announcements (deprecated)
ff0?::0002:8000-8fff	SAP Dynamic Assignments
ff02::0001	all nodes
ff02::0002	all routers
ff02::0004	DVRMP routers
ff02::0005	OSPFUGP
ff02::0006	OSPFIGP designated routers
ff02::0007	ST routers
ff02::0008	ST hosts
ff02::0009	RIP routers
ff02::000a	EIGRP routers
ff02::000b	mobile agents
ff02::000d	PIM routers
ff02::000e	RSVP encapsulation
ff02::0001:0001	Link name
ff05::0002	all routers
ff05::0001:0003	all DHCP servers
ff05::0001:0004	all DHCP relays
ff05::0001:1000-13ff	service location

Sh ip processes command

show processes Command
router#show processes
CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0%
PID Q Ty PC Runtime(ms) Invoked uSecs Stacks TTY Process
1 C sp 602F3AF0 0 1627 0 2600/3000 0 Load Meter
2 L we 60C5BE00 4 136 29 5572/6000 0 CEF Scanner
3 L st 602D90F8 1676 837 2002 5740/6000 0 Check heaps
4 C we 602D08F8 0 1 0 5568/6000 0 Chunk Manager
5 C we 602DF0E8 0 1 0 5592/6000 0 Pool Manager
6 M st 60251E38 0 2 0 5560/6000 0 Timers
7 M we 600D4940 0 2 0 5568/6000 0 Serial Backgroun
8 M we 6034B718 0 1 0 2584/3000 0 OIR Handler
9 M we 603FA3C8 0 1 0 5612/6000 0 IPC Zone Manager
10 M we 603FA1A0 0 8124 0 5488/6000 0 IPC Periodic Tim
11 M we 603FA220 0 9 0 4884/6000 0 IPC Seat Manager
12 L we 60406818 124 2003 61 5300/6000 0 ARP Input
13 M we 60581638 0 1 0 5760/6000 0 HC Counter Timer
14 M we 605E3D00 0 2 0 5564/6000 0 DDR Timers
15 M we 605FC6B8 0 2 011568/12000 0 Dialer event
注釋
關鍵字 解釋
CPU utilization for five seconds CPU在最後5秒鐘的使用率
one minute CPU在最後1分鐘的使用率
five minutes CPU在最後5分鐘的使用率
PID程序號碼
Q 程序號碼優先順序和程序號碼的狀態：
K（沒有優先順序，程序號碼被殺了），
D（沒有優先順序，程序號碼癱了），
X（沒有優先順序, 程序號碼中斷了），
C（緊急優先順序），
H（高優先順序），
M（中優先順序），
L（低優先順序）
Ty Ty當前的處理狀態：
*（cpu正在處理），
E (程序號碼正在等待一個重要動作),
S (程序號碼休眠),
rd (程序號碼已經在運行),
we (程序號碼等待一個重要動作),
sa (程序號碼等待一個指定的絕對時間的產生),
si (程序號碼等待一個指定的時間間隔),
sp (程序號碼等待一個指定的週期性的時間間隔),
st (程序號碼等待一個時間終止),
hg (程序號碼縣置),
xx (程序號碼死亡.).
PC 當程序號碼持續放棄CPU時程式計數註冊器的內容. 這個地方寫的是記憶體的位址用以代表程序號碼開始執行寫一次佔用的CP值0代表正在運行
Runtime (ms) 使用CPU累計時間 (毫秒)
Invoked 程序號碼的建立起程序號碼運行在CPU的總時間
uSecs 每次程序號碼使用平均cpu時間 (毫秒級)
Stacks 堆疊空間使用狀況. 斜線右邊的數字(/)表示總的堆疊空間。 左邊的數字代表空間利用率的最低水準線.
TTY 控制台設備相關的程序號碼.0代表程序號碼不是被控制台和通訊器相關的主系統主控台
Process 程序號碼的名字.程序號碼的名字不需要是唯一的 (一個程序號碼的幾分拷貝可以同時是啟動狀態的). 但是程序號碼id號必須是唯一的。

 

 

如何監視nat流量+如何看CPU使用率+看DHCP流量+暫停EIGRP LEARNING NEIGHBOR + ROUTER自動重開機
一.監視NAT網路流量 :
show ip nat translation
二 . 監視cpu使用率
show process cpu
三 . 監視DHCP流量
show ip accounting
! (前題must 貼accounting 的規則在最多內部流量的端口)
四 . 停止router運行 eigrp 禁止該界面收送Hello封包 , 阻止形成鄰居關係 ,界面將不會再傳送EIGRP資訊

router eigrp AS編號
passive-interface serial 端口編號

開啟router運行 eigrp 啟動該界面收送Hello封包 ,形成緊居關係 ,界面將繼續再傳送路徑資訊
router eigrp AS編號
no passive-interface serial 端口編號
五 . router定時重開
router> enable
router# reload at hh:mm dd(1~31) MM(1~12)

CPU utilization for five seconds: 63%/50%; one minute: 58%; five minutes: 58%

PID Runtime(ms) Invoked uSecs    5Sec   1Min   5Min TTY Process

 1        4976     54773     90    0.00% 0.00% 0.00%  0 Load Meter

 2       3788      670   5653    1.71% 0.22% 0.15% 130 Virtual Exec

24        3592       632   5683    0.00% 0.04% 0.09% 131 Virtual Exec

25   101868424 30627416   3326    8.76% 9.04% 10.41%   0 IP Input

 

CPU utilization for five seconds: 63%/50%

50%是指由於Interrupt switching 導致的CPU utilization, 所謂的Interrupt switching 也就是指所有除了process switching 的交換方式，例如fast switching, optimum switching, cef switching….所產生的CPU負載

Average utilization due to interrupts, during last five seconds

63%指的是最近5秒的CPU utilization總和，包括(interrupts + processes）

Average total utilization during last five seconds (interrupts + processes)

用63%-50%=13%， 這13%是基本由於process switching導致的CPU消耗，理解Cisco 路由器交換方式的人都知道，有一些流量路由器是必須使用process switching,例如icmp,也就ping, snmp等都是必須使用process switching

通常看來，如果打開了cef switching但是process switching部分的cpu utilization（63%-50%=13%）非常高，很可能目前情況不太正常，，因為如果打開cef的話，基本上除了icmp, snmp等類型的包外，都應該採用cef switching，但這部分差值由誰導致的，就要看show process cpu了， 從上面的例子可以看出來：

PID Runtime(ms) Invoked uSecs    5Sec   1Min   5Min TTY Process

25   101868424 30627416   3326   8.76% 9.04% 10.41%   0 IP Input

由於此路由器已經打開了cef，但為什麼還有這麼多的IP Input流量是通過process switching處理呢？

 

使用show interface state可以看到每個介面不同swiching方式產生的流量，如果某個介面的process部分很高，那很可能問題就出在這個埠。

 

Router#show interfaces stat

 

FastEthernet0/0

Switching path    Pkts In   Chars In   Pkts Out Chars Out

 Processor   
7995038
553590227 
8470311
629922225

Route cache   
42017034 3042361084   47856422 3952941601

 Total   
50012072 3595951311   56326733 287896530

 

FastEthernet1/0

 Switching path    Pkts In   Chars In   Pkts Out Chars Out

    Processor    1478297 178528355    1007368 101120880

 

     Route cache   46470310 3666895196   40629605 2756450367

 
    Total   47948607 3845423551   41636973 2857571247

 

使用show ip traffic命令來確認到底是那一種流量過大。

 

從下例中可以看出， 幾個不太正常的地：

 

1.在ICMP中有321413 unreachable，2263321 echo reply，很明顯路由器回應的ICMP太多了，如果每隔幾秒都有數量增加，建議在介面狀態下關掉IMCP redirects, unreachable以及echo reply，這些只會增加CPU負擔。

 

interface xxxx

 

no ip redirects

no ip unreachables

 

2.在UDP statistics中:

 

Rcvd: 7112 total, 0 checksum errors, 21093 no port

大量的no port就不太正常了，一般都是由於某些hacker軟體掃描埠造成的， 如果每隔幾秒都有數量增加，建議關掉proxy-arp

 

interface xxx

no ip proxy-arp

 

3. 在IP statistics，有89518 bad hop count，這一般是由於TTL過期導致的，如果每隔幾秒都有大量計數增加，很明顯，網路中存在routing loop，儘快檢查你的資料配置

 

或是詢問你的ISP怎麼給你做的路由。

 

Router#show ip traffic

 

IP statistics:

 

Rcvd: 190022549 total, 13327 local destination

 

         2 format errors, 0 checksum errors, 89518 bad hop count

         0 unknown protocol, 0 not a gateway

         0 security failures, 0 bad options, 0 with options

Opts: 0 end, 0 nop, 0 basic security, 0 loose source route

         0 timestamp, 0 extended security, 0 record route

         0 stream ID, 0 strict source route, 0 alert, 0 cipso, 0 ump

         0 other

Frags: 0 reassembled, 0 timeouts, 0 couldn’t reassemble

 

         6583 fragmented, 0 couldn’t fragment

Bcast: 2433 received, 77 sent

Mcast: 0 received, 0 sent

Sent: 100452 generated, 99773529 forwarded

Drop: 430 encapsulation failed, 1479 unresolved, 0 no adjacency

         3606 no route, 0 unicast RPF, 0 forced drop

 

ICMP statistics:

 

Rcvd: 0 format errors, 0 checksum errors, 0 redirects, 321413 unreachable

 

        2281 echo, 0 echo reply, 0 mask requests, 0 mask replies, 0 quench

        0 parameter, 0 timestamp, 0 info request, 0 other

        0 irdp solicitations, 0 irdp advertisements

Sent: 0 redirects, 4 unreachable, 0 echo, 2263321 echo reply

        0 mask requests, 0 mask replies, 0 quench, 0 timestamp

        0 info reply, 89517 time exceeded, 0 parameter problem

        0 irdp solicitations, 0 irdp advertisements

UDP statistics:

Rcvd: 7112 total, 0 checksum errors, 21093 no port

Sent: 5883 total, 0 forwarded broadcasts

 

TCP statistics:

Rcvd: 3935 total, 0 checksum errors, 4 no port

Sent: 2788 total

IPv6 tunnel over IPv4

IPV4 HEADER FIELD

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Version| IHL |Type of Service| Total Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identification |Flags| Fragment Offset |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Time to Live |
Protocol 41
| Header Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Destination Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Options | Padding |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| IPv6 header and payload …
/

+——-+——-+——-+——-+——-+——+——+

Source: RFC 3056, Connection of IPv6 Domains via IPv4 Clouds

IPv6 over IPV4 TUNNEL

IPV6 REF01

[IPV6 Intrduction]