7609開啟DHCP snooping后不更新DHCP binding table

來源:本站原創 網絡技術 超過1,116 views圍觀 1條評論

硬件平臺

CISCO7609-S

      1   24   CEF720 24 port 1000mb SFP                WS-X6724-SFP
      5    2   Route Switch Processor 720  (Active)     RSP720-3C-GE
      6    2   Route Switch Processor 720  (Hot)        RSP720-3C-GE
      9   48   48-port 10/100/1000 RJ45  EtherModule    WS-X6148A-GE-TX
    

軟件版本

IOS 12.2(33)SRE3

案例介紹

7609開啟DHCP snooping和DAI,7609在收到DHCP ACK包后不建立或刷新binding表項,造成DAI告警,終端斷網。

問題分析思路

  1. 確定DAI告警中的IP/MAC是攻擊還是合法的:

    產生DAI告警的原因是ARP報文(請求和回復)中源IP/MAC對不在DHCP binding表中,ARP報文同時被丟棄。客戶反映,log中顯示的這些IP/MAC對都是合法的,故問題的原因在于,沒有binding表項。
  2. 確定7609收到相應DHCP ACK報文時是否會更新binding表:

    客戶設定的租約時間是30天,在客戶的環境中很難看到DHCP binding表項刷新的現象,所以讓客戶建立一個測試vlan,租約時間為1min。話機連上2960時可以獲取IP,同時7609上能夠生成binding表項,但是表項age會一直老化到0,持續一段時間后消失,隨后出現DAI告警log。過一段時間后,話機會重新獲取IP,7609上表項會重新出現。
  3. 將7609上DHCP snooping和DAI配置刪除,在2960上開啟DHCP snooping和snooping debug。在2960上每到租約時間一半,會收到DHCP ACK并更新binding表項。

    7609上此時開啟DHCP snooping,但不開啟DAI,無DHCP binding表項。開啟debug,能看到DHCP request但沒有ACK,說明7609沒有收到ACK或收到沒有對其進行處理。

    ELAM能夠抓到ACK包,說明7609收到了但是沒有處理。

    讓話機重新獲取IP,在這個過程中,server回復的ACK目的IP為7609上的網關(DHCP relay ip),7609能夠生成binding表項。

    話機獲取IP后,到達租約時間的一半,會向DHCP server單播request來更新租約,server回復單播ACK。但是7609 DHCP snooping沒有處理這類ACK報文。

  4. 搭lab重現:

    如下拓撲下,7609作為DHCP relay,能夠更新binding表

    DHCP server  --------- 7609 ------- 2960 ------- IP phone

    如下拓撲,當7609-2收到的ACK是mpls包,便不會更新binding表。說明問題和MPLS有關。

    DHCP  server----- 7609-1 ------ MPLS ------- 7609-2 ------- 2960 ------- IP phone
  5. 配置命令mls mpls recir-agg強制帶有aggregation lable的包recirculate,問題解決。

    或應用包含 “default-class”的policy-map在7609-2連7609-1的接口上,這類policy-map有side effect disable VPN CAM,同樣能夠解決問題。

沒有應用以上workaround時,netdr抓包結果表明上CPU的包仍然帶有MPLS label:

——- dump of incoming inband packet ——-

interface Gi1/1, routine  process_rx_packet_inline, timestamp 16:57:22.515
dbus info: src_vlan 0x3FD(1021),  src_indx 0x0(0), len 0x15E(350)   bpdu 0, index_dir 0,  flood 0, dont_lrn 0, dest_indx 0x7E05(32261)    <<<<< index 0x7E05為CPU   08020401 03FD0000  00000001 5E000000 FE000554 0E000040 00000000 7E052000 
destmac 00.23.04.0E.E3.40,  srcmac 00.23.04.17.F5.C0, protocol 8847       <<<<< MPLS
layer 3 data: 00065BFE 45000148  00410000 FF1153C2 0A4B3164 14F11602               00430044 0134BEF5 02010600 C81D8791 00000000 14F11602               14F11602 00000000 00000064 00000001 000043FD 7AC5

應用以上的workaround,vpn-cam空了:

PE1-sp#show  mls vpn-cam 0 511
TYCHO  Sindex VPN RAM: Dumping entries 0 -> 511
Key:  * => Set, - => Clear

Index  MPLS Label   VPN    COS 
=====+============+======+=====

PE1#show  mls cef mpls labels 100

Codes:  + - Push label, - - Pop Label          * -  Swap Label, E - exp1
Index   Local         Label                    Out i/f
        Label         Op
2151    100 (EOS)     (-)                      recirc   <<<<<<

Netdr的抓包結果說明上CPU的包是pure IP了:

——- dump of incoming inband packet ——-

interface NULL, routine  process_rx_packet_inline, timestamp 17:13:22.651
dbus info: src_vlan 0x3F9(1017),  src_indx 0x0(0), len 0x15A(346)   bpdu 0, index_dir 0,  flood 0, dont_lrn 0, dest_indx  0x7E05(32261)        <<<<<<   BD020C01 03F90000  00000001 5A000000 00110544 2E000043 00000000 7E052000 
destmac 00.23.04.0E.E3.40,  srcmac 00.00.00.00.00.00, protocol 0800   <<<< IP packet
protocol ip: version 0x04, hlen  0x05, tos 0x00, totlen 328, identifier 94   df 0, mf 0, fo 0, ttl  254, src 10.75.49.100, dst 20.241.22.2     udp src 67,  dst 68 len 308 checksum 0xA6E9

問題總結

當forwarding engine收到aggregate label,L2 ASIC查找VPN CAM確定vrf #。隨后去掉MPLS label,將IP頭交L3 ASIC做三層查找。

在L3 ASIC中會進行兩個并行的查找:ACL TCAM查找和FIB TCAM查找。ACL TCAM查找返回一個指向CPU的index,FIB TCAM返回的信息是下一跳和rewrite信息。由于ACL TCAM返回結果的優先級更高,所以包不會被rewrite而原封不動的轉給CPU做處理,即包含MPLS包頭。

Dhcp snooping code并不解mpls包,所以dhcp binding表項不會被更新。

配置mls mpls recir-agg disable VPN CAM從而強制帶有aggregation label的包recirculate。或應用了包含“match-any”或“default-class”的policy-map,有一個side effect會disable VPN CAM。這樣,由于VPN CAM被disable了,MPLS包會在forwarding engine中進行兩次查找。第一次查找后會將MPLS label彈出,并再次進入forwarding engine做第二次查找,查找的結果是redirect to CPU。此時DHCP snooping code便能夠識別這個包,成功更新DHCP database。

經驗總結

找到表象的內在原因:DAI是由于沒有binding表項,則去查沒有binding條目的原因。

將問題簡化,在7609上僅保留DHCP snooping配置,去掉DAI。

相關命令

  • Show ip dhcp snooping
  • Show ip dhcp snooping binding
  • Debug ip dhcp snooping H.H.H

 

 

原文  http://www.cisco.com/cisco/web/support/CN/111/1117/1117748_7609NotRefreshDhcpDatabaseCaseStudy.html

文章出自:CCIE那點事 http://www.qdxgqk.live/ 版權所有。本站文章除注明出處外,皆為作者原創文章,可自由引用,但請注明來源。 禁止全文轉載。
本文鏈接:http://www.qdxgqk.live/?p=3303轉載請注明轉自CCIE那點事
如果喜歡:點此訂閱本站
  • 相關文章
  • 為您推薦
  • 各種觀點
? 7609開啟DHCP snooping后不更新DHCP binding table:目前有1 條留言
  1. 沙發
    話題:

    你好,你參與了話題#網絡技術#,點擊http://t.cn/zTEvbmn 查看更多精彩!

    2013-07-10 下午 6:04
發表評論

您必須 [ 登錄 ] 才能發表留言!

?
?
萌宠夺宝游戏