目錄

簡介

必要條件

需求

採用元件

慣例

背景資訊

LLC的實現

排除故障時必須瞭解的基本資訊

LLC幀格式

DSAP欄位

SSAP欄位

控制欄位

LLC控制欄位摘要

LLC2模式和會話建立

非同步平衡模式擴充模組(ABME)

非同步結束模式(ADM)

LLC2非同步平衡模式操作

LLC2可調引數

LLC2引數配置示例

LLC2錯誤條件

相關資訊

簡介

IEEE標準802.2將邏輯連結控制(LLC)定義為802.3、802.5和其他網路上使用的資料連結控制層。IBM最初將LLC設計為IBM權杖環架構中的子層。

必要條件

需求

思科建議您瞭解以下主題：

- 對LLC的基本理解

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

背景資訊

LLC層提供無連線和面向連線的資料傳輸。

無連線資料傳輸通常稱為LLC type 1或LLC1。無連線服務不要求您建立資料鏈路或鏈路站。啟用服務接入點(SAP)後，SAP可以向也使用無連線服務的遠端SAP傳送和接收資訊。無連線服務沒有任何模式設定命令（如SABME），並且不需要維護狀態資訊。

面向連線的資料傳輸稱為LLC type 2，或LLC2。面向連線的服務需要建立鏈路站。建立鏈路站時，需要設定模式命令。此後，每個鏈路站負責維護鏈路狀態資訊。

LLC的實現

每當系統網路架構(SNA)在LAN或虛擬LAN上執行時，都會實作LLC2。LLC2也直接封裝到幀中繼中。有時，路由器只傳遞LLC2幀，有時路由器實施LLC2鏈路站。NetBIOS也使用LLC。NetBIOS使用LLC1來定位資源。然後建立LLC2面向連線的會話。

啟用下列任一功能時，路由器會實作LLC2堆疊：

- 資料連結交換(DLSw)（連線到LAN）

- 使用本地ACK的遠端來源路由橋接(RSRB)

- 通道介面處理器(CIP)

- 進階對等網路(SNASwitching，SNASw)

- 同步資料連結控制(SDLC)到LCC轉換(SDLLC)

排除故障時必須瞭解的基本資訊

LLC的基本知識足以隔離並解決大多數問題。由於沒有要維護的鏈路狀態或會話，LLC1中很少出現問題。

在LLC2中，可能出現兩類問題：

1. 無法建立的作業階段

2. 間歇性失敗的已建立會話

為了解決這些問題，您需要瞭解以下主題：

- LLC幀格式

- LLC2模式和會話建立

- LLC2非同步平衡模式操作

- LLC2錯誤條件

LLC幀格式

本節提供有關LLC幀格式的資訊。

DSAP/SSAP

控制

目的地服務存取點（1位元組）

控制欄位 — 未編號（1位元組）

dddd ddxx

xxxx xx1x

xxxx xxx1

Dest. Addr.

IEEE Defined

Group Address

CCCC CC11

000F 1111

010P 0011

011F 0011

011P 1111

100F 0111

101z 1111

111z 0011

xx-xx

0F-1F

43-53

63-73

6F-7F

87-97

AF-BF

E3-F3

Unnumbered format

Disconnect Mode

Disconnect

Unnumbered Ack.

SABME

Frame Reject

XID

Test

來源服務存取點（1位元組）

控制欄位 — 監督（2位元組）

ssss ssxx

xxxx xx1x

xxxx xxx1

Source Address

IEEE defined

Response LPDU

CCCC CC01

0000 0001

0000 0101

0000 1001

xx-xx

01-xx

05-xx

09-xx

Supervisory Format

Receiver Ready

Receiver Not Ready

Reject

控制欄位 — 資訊幀（2位元組）

ssss sss0

xxxx

Information format

P =輪詢位設定為「1」 F =最終位設定為「1」 Z =輪詢/最終位設定為「0」或「1」

LLC幀稱為LLC協定資料單元(LPDU)，其格式如下所示：

DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field

(0 or more bytes)

DSAP欄位

目的地服務存取點(DSAP)會識別要為其提供LPDU的SAP。DSAP由六個地址位、使用者位(U)和個人/組(I/G)位組成，排列如下：

D-D-D-D-D-D-D-I/G

U位指示地址是由IEEE(1)定義還是由使用者定義(0)定義。 I/G位表示SAP是組地址(1)還是單個地址(0)。 就我們的目的而言，這兩個方面都不太重要。您真正需要知道的是，DSAP是LPDU的目標。一些常見的問題層出不窮。

SSAP欄位

來源服務存取點(SSAP)識別發出LPDU的SAP。SSAP由六個地址位、使用者位(U)和命令/響應(C/R)位組成，組織方式如下：

S-S-S-S-S-S-U-C/R

U位指示地址是由IEEE(1)定義還是由使用者定義(0)定義。 C/R位表示LPDU是命令還是響應。收到LPDU訊框時，C/R位不會視為SSAP的一部分。因此，SSAP通常被認為是最左邊的七個位。

控制欄位

LPDU控制欄位包含命令、響應和序列號資訊。您需要知道如何解碼控制欄位，以確定特定LLC2會話上發生的情況。然而，解碼資訊很容易獲得。

有三種型別的幀：

- I幀

- 監督框架

- 未編號的幀

雖然每種型別的控制欄位格式不同，但通過檢查控制欄位中的兩個位，您可以輕鬆區分它們。

X-X-X-X-X-X-X-0 = I Frame

X-X-X-X-X-X-0-1 = Supervisory Frame

X-X-X-X-X-X-1-1 = Unnumbered frame

接下來的幾節將介紹每種型別的控制欄位。

I幀

I幀允許您在鏈路站之間傳輸包含資訊（面向連線）的按順序編號的LPDU。I幀的格式包含NS和NR計數。NS計數是當前傳輸的LPDU的序列號（模128）。NR計數是傳送方預計接收的下一條LPDU I幀的序列號。要稍後為您提供幫助，請記住NR的意思是「下一個接收」。

NS-NS-NS-NS-NS-NS-NS-0-NR-NR-NR-NR-NR-NR-P/F

P/F位在命令LPDU中稱為P位，在響應LPDU中稱為F位。在命令LPDU中設定P/F位，以請求遠端鏈路站傳送設定了此位的響應。對於已設定P位的每個命令，必須只接收一個設定F位的響應。關於使用P/F位進行錯誤恢復還有其他一些詳細資訊，但這是一般規則。

監督框架

監督幀執行監督控制功能，例如，確認I幀(RR)、請求I幀的重新傳輸(REJ)以及請求I幀的臨時暫停(RNR)。監督幀不包含資訊欄位。因此，監控幀不會影響傳送站中的NS，因此不包含NS欄位。以下是監控框架的格式：

0-0-0-0-S-S-0-1-NR-NR-NR-NR-NR-NR-NR-P/F

「S」位指示監控幀的型別。

- B'00' =接收器就緒

站使用RR指示站已準備好接收，並包含將要到達的下一個I幀的NR計數。當站點傳送RR幀時，站點確認收到來自遠端站點（最多NR - 1）的編號I幀。

- B'01'=接收器未就緒

站點使用RNR來指示站點暫時沒有準備好接收。RNR還包含遵循相同規則RR的NR計數。RNR的瞬態週期並不總是指示網路問題。如果RNR持續，請在終端站中尋找擁塞。

- B'10'=拒絕

站使用REJ請求從NR計數中指示的數字開始重傳I幀LPDU。REJ不表示存在嚴重問題（表示可以恢復）。 如果您看到許多REJ命令，請在相反的方向查詢缺少（丟棄）的I幀。請勿將REJ與Frame reject(FRMR)混淆。FRMR是一個未編號的幀，總是表明存在嚴重問題。

未編號的幀

未編號幀提供鏈路控制功能，例如模式設定命令和響應。在某些情況下，還可以傳送未編號的資訊幀。未編號幀的長度只有一個位元組。它們不包含NR或NRS計數欄位。以下是未編號框架的格式：

M-M-M-P/F-M-M-1-1

「M」位指示未編號幀的型別。

- B'00011'=DM響應(0x1F)

鏈路站傳送DM響應以報告它處於非同步斷開模式。這意味著鏈路處於非活動狀態。如果鏈路站處於活動狀態並且突然開始傳送DM，則鏈路站可能已重置。

- B'01000'=DISK命令(0x53)

鏈路站傳送DISK以終止非同步平衡模式。DISK命令通知遠端鏈路站暫停操作。對DISK命令的正確響應是UA（如果工作站在ABM中）或DM（如果工作站在ADM中）。

- B'01100'=UA響應(0x73)

鏈路站傳送UA以響應SABME和DISK命令。

- B'01111'=SABME命令(0x7F)

鏈路站傳送SABME以啟動非同步平衡模式的資料傳輸。對SABME的正確反應是UA。當站收到SABME命令時，站將NR和NS計數重置為零。傳送站收到UA響應時也一樣。

- B'10001'=FRMR響應(0x87)

鏈路站傳送幀拒絕響應以報告從另一個鏈路站傳入LPDU中的錯誤。當您看到FRMR時，傳送FRMR的站台偵測到無法復原的錯誤。這不是錯誤的原因。在發生FRMR錯誤之後到達的任何幀都會被忽略，直到收到磁碟或SABME為止。

FRMR響應包含有關FRMR情況的原因的資訊。

位元組0和1包含導致幀拒絕的LPDU的控制欄位的內容。位元組2和3分別包含NS和NR計數。第4位元組包含多個位，用於識別錯誤型別，如下所示：

0-0-0-V-Z-Y-W-X

V位表示以位元組0和1為單位的控制欄位所攜帶的NS號無效。如果大於或等於上一個NS加上最大接收視窗大小，則NS無效。出現這種情況時，鏈路站會傳送REJ LPDU，而不是FRMR響應。

Z位表示控制欄位傳輸的NR以位元組0和1表示，它既不指下一個I幀，也不指已經傳輸但尚未確認的I幀。

注意：多次接收相同的NR計數完全正確。

只有當計數引用了已確認的I幀，或者計數向前跳至尚未傳輸的I幀時，NR計數才無效。前者是這種型別錯誤的最常見情況。當您看到這種型別的錯誤時，通常意味著幀是以無序方式接收的，您應該查詢傳送亂序幀的網路。傳送連結站可能傳送失敗，但可能性不大。

Y位表示收到的LPDU中I欄位的長度超過了可用的緩衝區容量。如果發生這種情況，請查詢終端站的問題，而不是網路的問題。

X位表示LPDU包含一個I欄位，但不得包含I欄位，或者接收到的FRMR響應不包含5個位元組。這似乎是終端站問題，而不是網路問題。

W位表示收到不受支援的LPDU。這是終端站問題。

- B'10111' XID命令或響應

鏈路站使用XID命令來傳送傳送節點的特性，並使遠端鏈路站以XID響應進行響應。鏈路站可以傳送和接收各種格式的XID，包括SNA格式。

- B'11100' TEST命令或響應

鏈路站傳送TEST命令以使遠端鏈路站儘快響應TEST響應。TEST命令通常用於在源路由橋接環境中發現路徑。

LLC控制欄位摘要

價值

未編號的幀

0x0F或0x1F

斷開模式(DM)響應

0x43或0x53

Disconnect(DISK)命令

0x63或0x73

未編號的確認(UA)響應

0x6F或0x7F

Set Asynchronous Balanced Mode(SABME)命令

0x87或0x97

幀拒絕(FRMR)響應

0xAF或0xBF

Exchange Id(XID)命令或回應

0xE3或0xF3

測試（測試）命令或響應

價值

監督框架

0x01

接收器就緒(RR)

0x05

接收器未就緒(RNR)

0x09

拒絕(REJ)

價值

資訊幀

0bnnnnn0

資訊幀(INFO)

LLC2模式和會話建立

LLC2有兩種工作模式：

- 非同步平衡模式擴充模組

- 非同步斷開模式

非同步平衡模式擴充模組(ABME)

ABME是在兩個連結站之間平衡運作的模式。平衡模式指的是，任一站點都可以隨時傳送命令，獨立於另一鏈路站點。請比較一下以非平衡模式運行的SDLC。在非平衡模式下，輔助站必須等待主站輪詢，然後才能傳送資料。由於平衡模式操作，傳統意義上的LLC2電路不會發生輪詢。站台確實會傳送keepalive以維持作業階段，但不需要經常傳送這些來達到最佳效能（如SDLC）。因此，keepalive計時器通常為10秒或更長。必須注意的是，終端站可以增加此keepalive計時器以減少開銷。增加保持連線計時器對吞吐量或響應時間沒有負面影響。

站在該站傳送或接收UA到SABME命令之後進入ABME。在ABME中，站台可以傳送和接收編號資訊幀。

非同步結束模式(ADM)

在站點終止ABME之前和之後，該站點處於非同步斷開模式。在ADM中，鏈路在邏輯上斷開；因此，無法傳送I幀或監督幀。在以下情況下，站點可以進入ADM:

- 收到DISK命令

- 連結站已啟用

- 收到DM響應

- 重試限制已用盡

以下是連結站啟動順序的範例：

To1 4000.0840.0001 8800.5a94.7d94 SABME F0F07F

To1 4000.0840.0001 8800.5a94.7d94 UA F0F173

To 1 4000.0840.00018800.5a94.7d94 RR nr=0 F0F001

To1 4000.0840.0001 8800.5a94.7d94 INFO nr=0 ns=0 F0F00000 ...

To1 4000.0840.0001 8800.5a94.7d94 RR nr=1 F0F101

To1 4000.0840.0001 8800.5a94.7d94 INFO nr=1 ns=1 F0F00202 ...

To1 4000.0840.0001 8800.5a94.7d94 RR nr=2 F0F101

To1 4000.0840.0001 8800.5a94.7d94 INFO nr=2 ns=2 F0F00000 ...

LLC2非同步平衡模式操作

在ASBM中運行的站對主站或輔站沒有嚴格的感知。站不需要輪詢或輪詢來傳輸資料。站點可以非同步向任何站點傳輸資料。站點具有點對點關係。

即使沒有嚴格意義上的主要和輔助，對於傳送的每個編號資訊幀，傳送站也需要一個稱作接收站確認資訊的鏈路級響應。站點可以繼續將I幀傳輸到另一個站點，直到未確認幀的數量達到限制。此數字稱為「視窗大小」，通常預設為7。對於存在大量延遲的電路，可以增加視窗大小，以避免傳送站停止並等待響應。這通常是不必要的，特別是在本地確認LLC的情況下。當傳送站到達傳送視窗時，站設定輪詢位元以強制接收站傳送響應。在路由器中，視窗大小稱為llc2 local-window。

接收站可以選擇在到達一定數量的I幀或計時器過期之前暫緩確認。這些引數分別稱為N3和T2。這樣，可以使用一個RR幀確認多個幀，或者在I幀頂部傳送確認。思科呼叫N3計數器llc2 ack-max。預設值為3表示路由器會一直保留確認，直到路由器收到三個I幀，或者T2計時器或llc2 ack-delay-time到期。

在不考慮夥伴站的情況下修改站上的這些引數會影響響應時間和吞吐量。例如，考慮如果傳送站本地視窗設定為5，而接收站的ack-max值為7,ack-delay-time值為500毫秒，將會發生什麼情況。

在這種情況下，傳送站傳送五個幀，然後等待確認再繼續。由於接收方在收到七幀之前會拒絕確認，因此在500毫秒延遲時間到期之前，不會傳送確認。如果降低接收站上的ack-max值，可以顯著提高效能。

另一個常見的LLC2引數稱為Ti計時器。路由器將其稱為llc2空閒時間。Ti計時器的用途是在沒有I幀傳輸期間保持LLC2會話處於活動狀態。如果降低此值，將無法提高吞吐量和效能。當Ti計時器到期時，在開啟輪詢位的情況下傳送RR幀，以便引起接收方的響應。如果站點沒有響應，則站點將在llc2 tpf-time之後重試，直到llc2 n2定義的重試次數過期。屆時，會話將關閉。

增加空閒時間以減少LLC2電路上的開銷量，您可以調整該空閒時間以替代本地ack。例如，200個DSPU連線到NCP。每個PU維護一個獨立的LLC2會話。如果每個路由器每10秒傳送一次keepalive，則每秒會產生20幀開銷。如果將空閒時間增加到30秒，開銷幀量將降低到每秒6.67幀。這種方法的缺點是車站需要更長時間才能發現其搭檔無法到達。但根據你的情況這可能是件好事

LLC2可調引數

指令

預設

說明

llc2 ack-delay-time>/b>毫秒

100

在未達到ack-max值時傳送確認之前等待響應的時間量。

llc2 ack-max計數

3幀

傳送確認之前要接收的幀數。

llc2 idle-time msec

10000

在空閒時間段內的兩次輪詢之間的時間量。

llc2 local-window count

7幀

等待響應之前要傳送的幀數。

llc2 n2計數

8次重試

在終止會話之前傳送未確認的I幀或輪詢而不收到回覆的次數。

llc2 t1-time msec

1000

在重新傳送I幀之前等待響應的時間量。此時間需要足夠大，以適應往返延遲。

llc2 tbuzy-time msec

9600

輪詢已傳送RNR的站之前等待的時間量。更改該值只是為了增加在清除狀態之前具有異常長、繁忙的時段的站的值。

llc2 tpf-time msec

1000

在重新傳送輪詢幀之前等待最終響應的時間量。

llc2 trej-time msec

3200

傳送REJ後等待正確幀的時間。

您可以使用show llc命令檢視以下引數的值：

ibu-7206#sh llc

LLC2 Connections: total of 1 connections

TokenRing3/0 DTE: 4001.68ff.0000 4000.0000.0001 04 04 state NORMAL

V(S)=5, V(R)=5, Last N(R)=5, Local window=8, Remote Window=127

akmax=3, n2=8, Next timer in 8076

xid-retry timer      0/60000   ack timer       0/1000

p timer              0/1000    idle timer   8076/10000

rej timer            0/3200    busy timer      0/9600

akdelay timer        0/100     txQ count       0/2000

LLC2引數配置示例

在典型的DLSw+網路中，在任一端都有令牌環LAN，LLC2引數的配置是在傳出令牌環介面上進行的。

有兩個獨立的LLC2會話。因此，請如下所示配置LLC2引數：

hostname dlsw1

!

source-bridge ring-group 100

!

dlsw local-peer ...

dlsw remote-peer ...

!

interface token-ring 0

source-bridge 10 1 100

llc2 tpf-timer 2000

llc2 n2 20

hostname dlsw2

!

source-bridge ring-group 100

!

dlsw local-peer ...

dlsw remote-peer ...

!

interface token-ring 0

source-bridge 20 1 100

llc2 tpf-timer 2000

llc2 n2 20

注意：這些撇清的配置僅顯示相關的LLC2引數配置。

LLC2引數配置必須將LLC2引數與FEP（到DLSw1路由器）和PC（到DLSw2路由器）匹配。 當中心站點DLSw+對等體在CIP路由器上時，配置略有不同。

遠端DLSw+路由器配置保持不變。但是，中心站點的LLC2會話在IOS中的CIP和LLC2堆疊之間。CIP代表主機，從主機到IOS的LLC2引數配置在LAN令牌環上的介面卡下（在CIP上）。 從IOS到大型機的LLC2引數在傳出介面上配置。即，介面通道x/2（用於CIP）和介面通道x/0（用於xCPA）。例如：

hostname dlsw1

!

source-bridge ring-group 100

!

dlsw local-peer ...

dlsw remote-peer ...

!

interface channel 0/2

llc2 tpf-timer 2000

llc2 n2 20

lan tokenring 0

source-bridge 10 1 100

adapter 0 4000.7513.0000

llc2 tpf-timer 2000

llc2 n2 20

注意：這些撇清的配置僅顯示相關的LLC2引數配置。

如果CIP路由器通過LAN連線到本地站，則只需要CIP介面卡下的LLC2引數。然後，LLC2引數將與PC的引數匹配。介面通道0/2下的任何LLC2引數均無效。

hostname rtr1

!

source-bridge ring-group 100

!

interface channel 0/2

lan tokenring 0

source-bridge 10 1 100

adapter 0 4000.7513.0000

llc2 tpf-timer 2000

llc2 n2 20

注意：這些撇清的配置僅顯示相關的LLC2引數配置。

如果裝置通過網橋組連線到DLSw+，則在DLSW+ bridge-group語句上配置LLC2引數，如下所示：

hostname dlsw2

!

dlsw local-peer ...

dlsw remote-peer

dlsw bridge-group 1 llc2 tpf-timer 2500 n2 20

!

interface ethernet 0

bridge-group 1

bridge 1 protocol ieee

注意：這些撇清的配置僅顯示相關的LLC2引數配置。

注意：雖然您可以在ethernet 0介面下配置LLC2，但這些引數沒有影響。DLSw bridge-group LLC2是Cisco IOS軟體版本11.3中的新功能。

將路由器配置為終端站（例如SNASw和DSPU）時，必須在傳出介面上配置LLC2引數。請注意，並非所有虛擬介面都支援LLC2引數的配置。例如：

注意：這些撇清的配置僅顯示相關的LLC2引數配置。

hostname snasw1

!

Interface fastethernet 0/0

llc2 tpf-timer 2000

llc2 n2 20

!

snasw cpname neta.snasw1

snasw port FASTETH0 FastEthernet0/0 conntype nohpr

LLC2錯誤條件

LLC2會話上的一些錯誤是正常的，可以恢復，例如偶爾丟失幀或幀順序錯誤。這通常導致REJ和重新傳輸幀。過度重新傳輸不正常，您必須確定原因並解決此問題。由於丟棄、多條路徑、擁塞和過度延遲，可能會發生過度重新傳輸。

LLC2中的某些錯誤無法恢復，且始終導致會話中斷。這些錯誤完全是違反協定的行為。當站台傳送未定義的控制欄位或其他錯誤資訊時，就可能會發生這種情況。這些協定違規可能導致站點傳送FRMR響應。負責傳送FRMR響應的站點很可能不是違規者，而只是信使。FRMR包含用於識別為什麼傳送FRMR的資訊，當一個站請求另一個站重新傳送它已經確認的I幀時，最常見的情況是傳送FRMR。由於站點無法重新傳輸該幀（因為它已丟棄該幀），因此它別無選擇，只能終止LLC會話。發生此類錯誤時，最可能的原因是幀順序有誤。

相關資訊

- 技術支援與文件 - Cisco Systems