OSPF for IPv6協議的NSSA區域擴展特性研究

于志泉 張久文

（蘭州大學 信息科學與工程學院，甘肅 蘭州 730000）

0 引言

在數據通信領域，OSPF（Open Shortest Path First-開放最短路徑優先）協議因其快速收斂、無自環等特性而廣泛使用，并存在適應IPv6的OSPF version3協議，同時OSPF協議擴展屬性NSSA（Not So Stubby Area）區域亦適配擴展。

1 NSSA區域簡述

NSSA區域允許引入自治系統外部路由，由ASBR發布Type7 LSA(NSSA-LSA)通告給本區域。當Type7 LSA到達NSSA的ABR時，由ABR將Type7 LSA轉換成Type5 LSA(AS-external-LSA)傳播到其他區域。

圖1 OSPFv3劃分區域典型組網圖

如圖1所示，整個OSPFv3組網被分為區域0、區域1和區域2。區域0是骨干區，區域1配置為NSSA區，區域0和區域1的區域間路由信息會發布到區域2，區域1引入的RIP路由生成的7類LSA在ABR1設備上進行7轉5后生成5類LSA發布到骨干區，區域2通過骨干區學到NSSA區域引入的外部路由。

2 現有協議下NSSA區域的問題

在實際網絡配置中會出現多個ABR鏈接NSSA區域及骨干區域的情況，這些ABR均具備7轉5能力，選取哪一個ABR來進行轉換？選取簡單的雙ABR情況進行分析。網絡拓撲如圖2所示：

圖2 雙ABR網絡拓撲

網絡配置：

在RT-A上引入靜態路由,查看RT-D上5類LSA，其source-id是3.3.3.3，而修改RT-B的router-id為3.3.3.4時，再次查看，其source-id是3.3.3.4，即優選router-id較大的來做7轉5轉換器。

基于用戶自定義網絡的需求，主流設備商提供了nssa區域的參數：

translate-always：指定ABR完成NSSA區域的7類LSA轉換為5類LSA。

translate-never：指定ABR不能將NSSA區域的7類LSA轉換為5類LSA。

圖3 hello報文中的options

如在RT-B（其router-id仍為2.2.2.2）area1下配置：nssa translatealways，查看RT-D上5類LSA的source-id，由 3.3.3.3變為 2.2.2.2。通過截取報文發現由RT-B發出的hello報文中options置上NTbit位，如圖3所示。

由RT-B發出的hello報文在維持鄰居的過程中發送給RT-D，RT-D就會選擇RT-B作為轉換器。如果將RT-B與RT-D間鏈路斷掉，此時只有選擇RT-C作為轉換器，查看RT-D上的5類LSA的source-id為 3.3.3.3。

在RT-C ospfv31 area1下配置：nssa translate-never，查看Router-D上的LSA，并不存在轉換得到的5類LSA，截取報文查看RT-B發出的hello報文的bit位并未變化。判斷7轉5角色時，如果配置translate-never參數，則區域不進行轉換處理。此時恢復RT-B與RTD間的鏈路，預料中應該選擇RT-B為轉換器，但在現有實現中：RTD并不存在相應前綴的5類LSA。這樣就存在:如果在配置過程中，誤將多ABR情況下的router-id較大的ABR上NSSA區域配置translate-never參數，且無ABR配置translate-always參數，就會出現上述情況下均未被選為轉換器的問題，進而出現存在路由但無法學到的問題。

3 解決方案

觀察hello報文的options，其占有24個bit位，因此可以仿效always參數在options添加bit位，稱之NEbit位，在配置translatenever參數后，將此標記置1，然后通過鄰居間交互的hello報文發給鄰居，告之已置上never參數無法成為7轉5轉換器，在進行轉換器選取時，將此ABR排除在外。

寫出偽代碼如下:

在配置處理中：

在收到攜帶NEbit的hello報文時，其源ABR不參與7轉5轉換器的選取，從而解決上述問題。我們按照上述偽代碼進行編碼、版本編譯后，可以驗證配置：

【RT-C-AREA-1】：Nssa translate-never

截取hello報文，其optinons的NEbit位已置上，且RT-D也能收到轉換后的5類LSA，從而驗證問題已解決。

4 總結

本文首先對IPv6下OSPF協議的NSSA區域進行簡述，然后提出現有協議實現中存在多個ABR情況且無ABR配置translate-always參數情況下，給router-id最大的ABR配置translate-never參數后，無法學到路由的問題，最后給出一種解決思路和驗證方案。

[1]J.Moy,R.Coltun.Request for Comments 5340:OSPF for IPv6[Z].July 2008.

[2]P.Murphy.Request for Comments 3101:The OSPF Not-So-Stubby Area（NSSA）Option[Z].January 2003.

[3]黃瑜岳，梁偉.基于IPv6的OSPFv3協議的研究和實現[J].常熟理工學院學報，2006.