記一次Cisco企業高級組網中不正確配置PBR引起的環路排錯

嗨，各位。很久沒了，最近忙的一塌糊塗，做爲一個勤奮好學的網工，我要把實戰中遇到的問題記錄下來，同時分享給各位。這次的文檔分享，是上個月的一次項目實戰中記錄下來的PBR-策略路由排錯。具體的配置不會一一記錄，可是會寫個大概配置。

畢竟都是有幾年的網工經驗了，基礎的不會就別看了，我都嫌棄！！！

很少說，咱們先上一張圖，圖的背景就很少介紹了，反正能夠給你們保證的是所有均爲實實在在的真機。

PS：圖進行了和諧，還有不少設備均進行了刪減，作網工永遠要記住一件事情，信息安全！！！！

圖中設備清單以下：（僅列舉網絡設備）

S5700-52TP-LI-接入層交換機

AR2204-路由C

cisco-3750核心路由A-istack部署

cisco-3750路由B

cisco-3750GW設備

主機F-windows2008-r2-64bit

Juniper-SSG320-FWD

IPS設備-hillstone-SG2560-旁掛

軟件環境：軟件版本不一一列舉，均是通過歲月認證的穩定IOS。

說下局部需求；

1.主機F的流量必須經過PBR扔到路由C上，而後通過FWD訪問ISP公網資源。並僅容許在一條線路上實現，不得經過上下游設備使流量通過路由C。

2.主機F的流量經過FW-D設備進行DIP的映射策略配置（切記，這裏不是MIP也不是VIP），此次文檔不會介紹此需求如何實現，後期會進行補充。

備註：獲得甲方的需求時，目測很是的奇葩。故想了個辦法，核心網絡起動態-OSPF+auth-key認證、重發布直連和靜態、邊界正常接入宣告便可。路由設備間所有互聯ping便可。

這裏呢，再說明下爲何個人標題是「記一次不正確的配置PBR致使的環路呢？」，由於我在這次實施過程中確實由於本身的問題，致使了整個施工卡了近十分鐘，十分鐘對於一個資深工程師已經算是極大的事故了，因此我認爲這真的應該拿出來好好的嘲諷本身一番。

我大概描述下流量的正確走向，以下圖：

我簡單的列出下PBR的相關配置：

核心路由A：

ip access-list extended add113

 permit ip 172.16.113.0 0.0.0.255 any log

route-map PBR-Global permit 10

 match ip address 113

 set ip next-hop 172.16.106.18

rack1_3750X2_isp_core#show route-map 輸出以下：

route-map PBR-Global, permit, sequence 10

  Match clauses:

    ip address (access-lists): 113 

  Set clauses:

    ip next-hop 172.16.106.18

  Policy routing matches: 56 packets, 5630 bytes

路由B：

ip access-list extended add113

 permit ip 172.16.113.0 0.0.0.255 any log

route-map PBR permit 15

 match ip address add113

 set ip next-hop 172.16.106.34

route-map ARPBR permit 15

 match ip address add113

 set ip next-hop 172.16.106.34【故障發生點，後面詳細介紹】

route-map PBR, permit, sequence 15

  Match clauses:

    ip address (access-lists): add113

  Set clauses:

    ip next-hop 172.16.106.34

route-map ARPBR, permit, sequence 15

  Match clauses:

    ip address (access-lists): add113 

  Set clauses:

    ip next-hop 172.16.106.34【故障發生點，下面詳細介紹】

  Policy routing matches: 13 packets, 1378 byte

路由C：

acl number 3002  

 rule 5 permit ip source 172.16.113.0 0.0.0.255 logging

traffic classifier PBR operator or

 if-match acl 3002

traffic behavior PBR

 statistic enable                         

 redirect ip-nexthop 172.16.106.33

traffic policy PBR

 classifier PBR behavior PBR

接口掛載圖省略，太簡單的配置不想贅述，若是不會，請自行看書學習。

主機F，路由跟蹤測試圖以下：

結論：環在了34-33中間，回頭檢查visio圖，從新觀察流量走向，故障發生描述以下圖。

中間我思考十分鐘的時間，這裏就省略了。畢竟太尷尬了，

故障判斷：

問題出如今路由B上，在覈心路由A過來的流量，進方向掛載PBR，流量指向路由C正常過去了，路由C將流量回指回來後，出現路由B再次把流量指回路由C。判斷路由C到路由B直連鏈路，PBR配置有問題。

檢查發現：

route-map ARPBR, permit, sequence 15

  Match clauses:

    ip address (access-lists): add113 

  Set clauses:

    ip next-hop 172.16.106.34【故障發生點】

  Policy routing matches: 13 packets, 1378 byte

將next-hop 修改成FW-D的直連linkip地址，至此故障獲得解決，以下圖展現。

結論，PBR下一跳填寫錯誤致使出現環路。

來一一家二級運營商的網工分享，齊家、提高、積累、正心。我是一個認真的草根網絡工程師，沒有任何認證。