案例名稱：? ?? 《幀中繼故障排除》 技術范圍： ??? 幀中繼 技術關鍵詞： ??? 幀中繼協議、frame-relay 案例描述： ??? 還清楚記得我單位上幀中繼那條線路，所遇到的問題:為什么協議up了，pvc都是active的，但總是ping不通對端，是不是版本又有bug了？ 實際上，善良技術人員們，真的沒有必要所有的問題都自己扛！讓我們看看，在哪些情況下我們可以理直氣壯的判定我們的路由器沒有問題，讓電信去檢查線路路由吧！ 鑒于我們的路由器在室外總是做dte設備使用，本文只針對dte接口進行分析。 故障排除步驟：

解決思路：

1. 配置：

對于幀中繼協議，當路由器做為dte端時，配置其實很簡單，只需要封裝幀中繼，配置ip地址（當然，lmi的類型請與對端dce接口保持一致）。如果使用了子接口，那么就得事先知道電信局分配的dlci號并配置在子接口上（否則會被默認是分配給主口的）。如果手動配置了靜態map映射，則當出現pvc狀態為active但又ping不通對端時，請首先懷疑map映射配置錯誤。 對應的典型配置： interface serial0/0 physical-layer sync encapsulation frame-relay frame-relay lmi-type ansi ip address <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />1.0.0.1 255.0.0.0 exit <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

?

interface serial0/0.1 point-to-point frame-relay interface-dlci 20 exit ip address 2.0.0.1 255.0.0.0 exit

2. 協議up：

要使協議up，大家都知道會先看物理信號是否都up了，v35，v24是否調對了，但是，如果這些都正常的情況下，幀中繼協議還是沒有up，此時該怎么辦呢？ 此時可以用debug fra lmi來進行調試，看看lmi協議報文是否交互正常，如果lmi報文只發不收，那么在你排除了線路上的問題后，多半就是因為兩端lmi協議報文配置不一致了，此時可在本端換lmi協議類型試試（frame-relay lmi-type q933a / ansi / lmi），如果在你換到某個類型時突然發現有收有發，那么恭喜您，終于配對了！如此正常交互三次后，協議自然就up了。 如果您硬說lmi報文一直正常交互，協議就是不up，那么只能說您很不幸，路由器可能是在打瞌睡或者犯傻了，沒有辦法，只有施以暴力了，將相應的接口shut，no shut一次就好了（在物理信號全up時，幀中繼協議shut，no shut后默認是up的，等它up后發現lmi交互一直正常，自然不會再犯傻又down掉）。

3. pvc狀態：

其實這一步有點多余，pvc狀態可不是我們所能控制的，它取決于電信幀中繼交換機上的配置。 如果在接口上手動配置了dlci號，則pvc狀態可能有四種：delete，static，inactive，active。Delete狀態說明此dlci號只是手動配置在本端接口上，而電信局根本沒有給您提供這條pvc，為無效pvc；狀態為static則表示本端接口上配置了no keeplive命令，dte－dce間不再交互lmi報文來通告pvc的狀態；狀態為inactive則表示電信端雖然給您提供了這條pvc，但卻不可用；為active則表示電信端給您提供了這條pvc，且pvc有可能可用。 這里需要簡單介紹一下pvc狀態為inactive和active的含義。對于幀中繼網絡，一條pvc是有多個pvc段組成的（dte－dte間為一條pvc，dte－dce，dce－dce間為一個pvc段）。舉個例子：RA—RB—RC—RD，RA—RB間的dlci號為20，RB－RC間的dlci號為30，RC－RD間的dlci號為40，則RA和RD間的這條pvc是由pvc段20，30，40組成的，對于RA而言， RA上顯示的pvc 20的狀態，其實只表示pvc段30，40是否可用，并不能表示這條pvc是否可用；同樣，RD上顯示的pvc 40的狀態，也只表示pvc段20，30是否可用，同樣不能表示RA和RD間的這條pvc是否可用，這就可用解釋為什么很多時候我們看到dte設備上顯示的pvc狀態為active卻還是ping不通的現象。（有點難懂哈，多看幾遍！） 很多人以為幀中繼交換機上的路由沒有配置正確的話，我們路由器上所看到的pvc狀態就是inactive的，如果pvc狀態為active了，那么電信的路由配置肯定沒有問題，其實不然，幀中繼交換機路由配置錯誤可能引起的現象是多種多樣的，這里我先舉一個例子，以后遇到經典的再補上：

幀中繼交換機路由錯誤可能引起的現象

之一：本端pvc為active，有對端的動態map映射？但ping不通對端

實例環境：

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />?

其中36B和RC被模擬成幀中繼交換機。R2692和36b間dlci號100，36b和RC間dlci號為200，RC和RB間dlci號為300。在此，我們正確配置36b上的路由，RC上s0/0口的路由也正確配置，僅RC上s3/0口上的路由配置錯誤，此時出現的現象就是在2692上看到本端pvc 100的狀態為active的，且可能有對端的動態map映射，但無法ping通對端。

實例配置：

R2692:

interface serial0/0 ?physical-layer sync ?encapsulation frame-relay ?frame-relay lmi-type ansi ?ip address 1.0.0.1 255.0.0.0 ?exit 36b：

frame-relay switching

?

interface serial0/0 ?physical-layer sync ?clock rate 128000 ?encapsulation frame-relay ?frame-relay lmi-type ansi ?frame-relay intf-type dce ?frame-relay route 100 interface serial0/1 200 ?exit

?

interface serial0/1 ?physical-layer sync ?clock rate 2000000 ?encapsulation frame-relay ?frame-relay lmi-type ansi ?frame-relay intf-type nni ?frame-relay route 200 interface serial0/0 100 ?exit RC:

frame-relay switching

?

interface serial0/0 ?physical-layer sync ?encapsulation frame-relay ?frame-relay lmi-type ansi ?frame-relay intf-type nni ?frame-relay route 200 interface serial3/0 300 ?exit

?

interface serial3/0 ?physical-layer sync ?encapsulation frame-relay ?frame-relay lmi-type ansi ?frame-relay intf-type dce ?frame-relay route 300 interface serial0/0 150? （錯誤路由） ?exit RB:

interface serial2/0 ?physical-layer sync ?clock rate 2000000 ?encapsulation frame-relay ?frame-relay lmi-type ansi ?ip address 1.0.0.5 255.0.0.0 ?exit

實例表現形式：

R2692:

1.?????? 接口協議up； 2.?????? 接口pvc狀態為active； 3.?????? 有動態學到的map映射？如果開始幀中繼交換機路由配置正確，2692上已經學到了動態map映射，此時改變幀中繼交換機的配置，則已經學到的動態map映射也不會掉（但若接口down了map映射就掉了且無法再自動學到），這樣就可能造成一種接口up，pvc為active，且動態學到了map映射的假相，遇到這種情況可將接口shut，no shut一次，就可判斷出是否真的可動態學到map映射。

小結

對于幀中繼協議，配置得越簡單，越容易定位出問題所在，很多人喜歡在接口上配置dlci號，配置map映射，以為這樣更保險，其實往往使得其反，這些配置對于網絡穩定根本不會有特殊作用，而出了問題反而影響問題的定位。 一般而言，如果是使用的主口，在封裝幀中繼協議后只需要配置ip地址（pvc號可通過lmi協議自動獲得，map映射可通過InARP協議自動生成）；如果使用子口，就在子口上配置所用的dlci號（否則自動獲得的dlci號默認加在主口上）。 基本上，如果您這樣配置好協議后，協議能up，接口收發正常，那么再不通的話，問題多半不是出在我們的路由器上。 如果協議可學到動態map映射，但仍無法ping通對端時，可用debug fra log命令查看數據流向，看是否由于別的原因導致數據流向出錯。 另外，如果您非要堅持手動配置map映射，請不要忘了帶上broadcast參數，否則在使用動態路由時您又會手足無措了。

轉載于:https://blog.51cto.com/10233/36504

總結

以上是生活随笔為你收集整理的帧中继故障排除的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。