IEEE 표준 802.2는 LLC(Logical Link Control)를 802.3, 802.5 및 기타 네트워크에서 사용되는 데이터 링크 제어 레이어로 정의합니다.IBM은 원래 LLC를 IBM Token Ring 아키텍처의 하위 레이어로 설계했습니다.
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
LLC에 대한 기본적인 이해
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.
LLC 레이어는 연결 및 연결 지향 데이터 전송을 제공합니다.
연결 없는 데이터 전송은 일반적으로 LLC 유형 1 또는 LLC1이라고 합니다. 연결 없는 서비스에서는 데이터 링크나 링크 스테이션을 설정할 필요가 없습니다.SAP(Service Access Point)가 활성화되면 SAP는 연결 없는 서비스를 사용하는 원격 SAP에 정보를 보내고 받을 수 있습니다.연결 없는 서비스에는 모드 설정 명령(예: SABME)이 없으며 상태 정보를 유지할 필요가 없습니다.
연결 지향 데이터 전송을 LLC 유형 2(LLC2)라고 합니다. 연결 지향 서비스를 사용하려면 링크 스테이션을 설치해야 합니다.링크 스테이션이 설정되면 모드 설정 명령이 필요합니다.그런 다음 각 링크 스테이션은 링크 상태 정보를 유지 관리할 책임이 있습니다.
LLC2는 SNA(Systems Network Architecture)가 LAN 또는 가상 LAN을 통해 실행될 때마다 구현됩니다.LLC2는 프레임 릴레이로 직접 캡슐화됩니다.때로는 라우터가 LLC2 프레임을 단순히 전달하고 라우터가 LLC2 링크스테이션을 구현하는 경우도 있습니다.NetBIOS는 LLC도 사용합니다.NetBIOS는 LLC1을 사용하여 리소스를 찾습니다.그런 다음 LLC2 연결 지향 세션이 설정됩니다.
다음 기능 중 하나가 활성화되면 라우터는 LLC2 스택을 구현합니다.
DLSw(Data-Link Switching)(LAN에 연결)
로컬 ACK를 사용하는 RSRB(Remote Source-Route Bridging)
CIP(Channel Interface Processor)
고급 P2P 네트워킹(SNASwitching(SNASw))
SDLC(Synchronous Data Link Control)와 SDLLC(LCC Conversion) 간
LLC에 대한 기본적인 지식이 있으면 대부분의 문제를 격리하고 해결할 수 있습니다.유지 관리할 링크 상태 또는 세션이 없으므로 LLC1에서는 문제가 거의 발생하지 않습니다.
LLC2에서는 두 가지 유형의 문제가 발생할 수 있습니다.
설정되지 않은 세션
간헐적으로 실패한 설정된 세션
이러한 문제를 해결하려면 다음 주제에 대해 알아야 합니다.
LLC 프레임 형식
LLC2 모드 및 세션 설정
LLC2 비동기 균형 모드 작업
LLC2 오류 조건
이 섹션에서는 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바이트) | Control Field - Supervisory(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"로 설정된 폴링 비트 = "1"로 설정된 최종 비트 = "1" Z = "0" 또는 "1"로 설정된 폴링/최종 비트 |
LLC 프레임은 LPDU(LLC Protocol Data Unit)라고 하며 다음과 같이 포맷됩니다.
DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field (0 or more bytes)
DSAP(Destination Service Access Point)는 LPDU를 사용할 SAP를 식별합니다.DSAP는 다음과 같이 구성된 6개의 주소 비트, U(사용자 비트) 및 Individual/Group(I/G) 비트로 구성됩니다.
D-D-D-D-D-D-D-I/G
U 비트는 주소가 IEEE(1) 또는 사용자 정의(0)로 정의되는지 여부를 나타냅니다. I/G 비트는 SAP가 그룹 주소(1) 또는 개별 주소(0)인지 여부를 나타냅니다. 우리의 목적을 위해, 이 비트는 모두 중요하지 않다.DSAP가 LPDU의 목적지임을 알아야 합니다.흔한 것이 몇 번이고 있다.
SSAP(Source Service Access Point)는 LPDU를 시작한 SAP를 식별합니다.SSAP는 아래와 같이 6개의 주소 비트, 사용자 비트(U) 및 명령/응답(C/R) 비트로 구성됩니다.
S-S-S-S-S-S-U-C/R
U 비트는 주소가 IEEE(1) 또는 사용자 정의(0)로 정의되는지 여부를 나타냅니다. C/R 비트는 LPDU가 명령 또는 응답인지 여부를 나타냅니다.LPDU 프레임을 수신하면 C/R 비트는 SSAP의 일부로 간주되지 않습니다.따라서 SSAP는 일반적으로 가장 왼쪽에 있는 7비트로만 간주됩니다.
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 프레임을 사용하면 링크 스테이션 간에 정보(연결 지향)가 포함된 순차적으로 번호가 지정된 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 비트라고도 합니다.P/F 비트는 원격 링크 스테이션에서 이 비트 집합으로 응답을 보내도록 요청하기 위해 명령 LPDU에 설정됩니다.P 비트 집합과 함께 전송된 모든 명령에 대해 F 비트가 설정된 응답만 수신해야 합니다.오류 복구와 관련하여 P/F 비트를 사용하는 방법에 대한 다른 세부 정보가 있지만 이는 일반적인 규칙입니다.
감독 프레임은 감독 제어 기능을 수행합니다. 예를 들어 RR(I Frames) 승인, REJ(I frame) 재전송을 요청, RNR(temporary suspend) 요청 등이 있습니다.감독 프레임에는 정보 필드가 없습니다.따라서 감시 프레임은 전송 스테이션의 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를 프레임 거부(FRMR)와 혼동하지 마십시오.FRMR은 번호가 매겨지지 않은 프레임이며 항상 심각한 문제를 나타냅니다.
번호가 지정되지 않은 프레임은 링크 제어 기능(예: 모드 설정 명령 및 응답)을 제공합니다.경우에 따라 번호가 지정되지 않은 정보 프레임도 전송할 수 있습니다.번호가 지정되지 않은 프레임은 길이가 1바이트에 불과합니다.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)
링크 스테이션은 SABME 및 DISK 명령에 대한 응답으로 UA를 전송합니다.
B'01111'=SABME 명령(0x7F)
링크 스테이션은 비동기 밸런싱 모드에서 데이터 전송을 시작하기 위해 SABME를 전송합니다.SABME에 대한 올바른 응답은 UA입니다.스테이션에서 SABME 명령을 수신하면 스테이션은 NR 및 NS 카운트를 0으로 재설정합니다.전송 스테이션은 UA 응답을 수신할 때에도 동일하게 작동합니다.
B'10001'=FRMR 응답(0x87)
링크 스테이션은 다른 링크 스테이션에서 들어오는 LPDU의 오류를 보고하기 위해 프레임 거부 응답을 보냅니다.FRMR이 표시되면 FRMR을 전송하는 스테이션에서 복구할 수 없는 오류를 감지했습니다.그것은 오류의 원인이 아니다.FRMR 오류가 발생한 후 도착하는 모든 프레임은 DISK 또는 SABME가 수신될 때까지 무시됩니다.
FRMR 응답에는 FRMR 조건의 원인에 대한 정보가 포함됩니다.
바이트 0과 1은 프레임 거부를 일으킨 LPDU의 컨트롤 필드의 내용을 포함합니다.바이트 2 및 3은 각각 NS 및 NR 수를 포함합니다.바이트 4에는 다음과 같이 오류 유형을 식별하는 여러 비트가 포함되어 있습니다.
0-0-0-V-Z-Y-W-X
V 비트는 컨트롤 필드에 의해 전달된 NS 번호(바이트 0 및 1)가 잘못되었음을 나타냅니다.마지막 NS와 최대 수신 윈도우 크기를 더한 경우 NS가 유효하지 않습니다.이러한 상황이 발생하면 링크 스테이션은 FRMR 응답이 아닌 REJ LPDU를 전송합니다.
Z 비트는 컨트롤 필드가 전달하는 NR이 바이트 0과 1로 표시되어 있지만 이미 전송되었지만 승인되지 않은 다음 I 프레임 또는 I 프레임을 참조하지 않음을 나타냅니다.
참고: 동일한 NR 수를 여러 번 받는 것이 좋습니다.
NR 개수는 카운트가 이미 승인된 I 프레임을 참조하거나 카운트가 아직 전송되지 않은 프레임으로 건너뛰는 경우에만 유효하지 않습니다.전자가 이러한 유형의 오류의 가장 일반적인 예입니다.이러한 유형의 오류가 표시되면 대개 프레임이 순서가 맞지 않게 수신되었음을 의미하며, 프레임 순서가 잘못된 네트워크를 찾아야 합니다.전송 링크 스테이션이 해당 TV를 잘못 전송했을 가능성이 있지만 그럴 가능성은 거의 없습니다.
Y 비트는 수신된 LPDU의 I 필드 길이가 사용 가능한 버퍼 용량을 초과했음을 나타냅니다.이러한 상황이 발생하면 네트워크가 아니라 엔드 스테이션에서 문제를 찾아보십시오.
X 비트는 LPDU에 I 필드가 포함되었거나 5바이트가 포함되지 않은 FRMR 응답이 수신되었음을 나타냅니다.네트워크 문제가 아니라 엔드 스테이션 문제일 수 있습니다.
W 비트는 지원되지 않는 LPDU를 수신했음을 나타냅니다.이것은 종단 스테이션 문제입니다.
B'10111' XID 명령 또는 응답
링크 스테이션은 XID 명령을 사용하여 전송 노드의 특성을 전달하고 원격 링크 스테이션이 XID 응답으로 응답하도록 합니다.링크 스테이션은 SNA 형식을 비롯한 다양한 형식으로 XID를 보내고 받을 수 있습니다.
B'11100' TEST 명령 또는 응답
링크 스테이션은 TEST 명령을 전송하여 원격 링크 스테이션에서 가능한 한 빨리 TEST 응답으로 응답하도록 합니다.TEST 명령은 일반적으로 소스 경로 브리징 환경에서 경로 검색에 사용됩니다.
가치 | 번호가 지정되지 않은 프레임 |
---|---|
0x0F 또는 0x1F | 연결 끊기 모드(DM) 응답 |
0x43 또는 0x53 | 연결 끊기(DISK) 명령 |
0x63 또는 0x73 | UA(Unnumbered Acknowledgment) 응답 |
0x6F 또는 0x7F | SABME(Asynchronous Balanced Mode) 명령 설정 |
0x87 또는 0x97 | 프레임 거부(FRMR) 응답 |
0xAF 또는 0xBF | XID(Exchange Id) 명령 또는 응답 |
0xE3 또는 0xF3 | 테스트(TEST) 명령 또는 응답 |
가치 | 감독 프레임 |
---|---|
0x01 | 수신기 준비됨(RR) |
0x05 | 수신기 준비 안 됨(RNR) |
0x09 | 거부(REJ) |
가치 | 정보 프레임 |
---|---|
0bnnnnnnnnn0 | 정보 프레임(INFO) |
LLC2 작동에는 두 가지 모드가 있습니다.
비동기 균형 잡힌 모드 확장
비동기 연결 끊기 모드
ABME는 두 개의 링크 스테이션 간의 균형 잡힌 작동 모드입니다.균형 잡힌 모드는 어떤 스테이션에서 다른 링크 스테이션과 독립적으로 언제든지 명령을 전송할 수 있다는 사실을 의미합니다.비균형 모드에서 작동하는 SDLC와 비교해 보십시오.비균형 모드에서는 보조 스테이션에서 데이터를 전송하기 전에 기본 스테이션에서 폴링할 때까지 기다려야 합니다.균형 잡힌 모드 작동의 결과로, 기존 의미에서 LLC2 회로에서 폴링이 발생하지 않습니다.스테이션은 세션을 유지 관리하기 위해 keepalive를 전송하지만 SDLC에서와 같이 최적의 성능을 위해 이를 자주 전송할 필요는 없습니다.따라서 keepalive 타이머는 일반적으로 10초 이상 입니다.엔드 스테이션에서 오버헤드를 줄이기 위해 이 keepalive 타이머를 늘릴 수 있다는 점에 유의해야 합니다.keepalive 타이머를 늘리면 처리량 또는 응답 시간에 부정적인 영향을 주지 않습니다.
스테이션은 스테이션에서 SABME에 UA를 전송하거나 수신한 후에 ABME로 들어갑니다.ABME에서는 번호가 매겨진 정보 프레임을 보내고 받을 수 있습니다.
스테이션이 ABME를 종료하기 전후에 스테이션은 비동기 연결 해제 모드에 있습니다.ADM에서 링크는 논리적으로 분리됩니다.따라서 I 프레임이나 감독 프레임을 전송할 수 없습니다.스테이션은 다음 조건에서 ADM에 들어갈 수 있습니다.
DISK 명령 수신
linkstation이 활성화되었습니다.
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 ...
ASBM에서 작동하는 스테이션은 1차 또는 2차 스테이션에 대한 엄격한 감각이 없습니다.스테이션은 데이터를 전송하기 위해 폴링하거나 폴링할 필요가 없습니다.스테이션은 모든 스테이션에 비동기적으로 데이터를 전송할 수 있습니다.스테이션은 P2P 관계를 가지고 있습니다.
기본 및 보조 서버에 대한 엄격한 센스는 없지만 전송 스테이션에는 전송된 각 번호가 지정된 정보 프레임에 대해 수신 스테이션에서 확인 응답을 요청하는 링크 수준 응답이 필요합니다.스테이션은 미확인 프레임 수가 제한에 도달할 때까지 I 프레임을 다른 스테이션으로 계속 전송할 수 있습니다.이 숫자를 "윈도우 크기"라고 하며 일반적으로 기본값은 7입니다. 전송 스테이션이 중지되고 응답을 기다릴 필요가 없도록 대기 시간이 많은 회로의 윈도우 크기를 늘릴 수 있습니다.LLC가 로컬에서 승인되는 경우에는 일반적으로 필요하지 않습니다.전송 스테이션이 전송 창에 도달하면 스테이션은 폴링 비트를 설정하여 수신 스테이션에서 응답을 강제로 전송합니다.라우터에서 창 크기를 llc2 local-window라고 합니다.
수신 스테이션에는 특정 수의 I 프레임이 도착하거나 타이머가 만료될 때까지 확인을 보류하는 옵션이 있습니다.이러한 매개변수는 각각 N3 및 T2라고 합니다.이렇게 하면 하나의 RR 프레임으로 여러 프레임을 승인할 수 있으며, 또는 IP 프레임 위에 승인 메시지를 보낼 수 있습니다.Cisco는 N3 카운터 llc2 ack-max를 호출합니다.기본값 3은 라우터가 3개의 I 프레임을 수신할 때까지 또는 T2 타이머 또는 llc2 ack-delay-time이 만료될 때까지 라우터가 승인을 보류함을 나타냅니다.
파트너 스테이션을 고려하지 않고 스테이션에서 이러한 매개변수를 수정하면 응답 시간 및 처리량에 영향을 줄 수 있습니다.예를 들어, 전송 스테이션 local-window가 5로 설정되어 있고 수신 스테이션의 값이 ack-max에 7이고 ack-delay-time에 500밀리초이면 어떤 일이 발생하는지 생각해 보십시오.
이 경우 전송 스테이션은 5개의 프레임을 전송한 다음 확인 응답을 기다렸다가 계속합니다.수신자는 7개의 프레임이 수신될 때까지 승인을 보류하므로 500밀리초 지연 시간이 만료될 때까지 승인을 보내지 않습니다.수신 스테이션에서 ack-max 값을 낮추면 성능을 크게 향상시킬 수 있습니다.
또 다른 일반적인 LLC2 매개변수는 Ti 타이머라고 합니다.라우터가 이를 llc2 유휴 시간으로 호출합니다.Ti 타이머의 목적은 IP 프레임이 전송되지 않는 기간 동안 LLC2 세션을 활성 상태로 유지하는 것입니다.이 값을 낮추면 처리량과 성능을 개선할 수 없습니다.Ti 타이머가 만료되면 RR 프레임이 폴링 비트를 켜서 수신자로부터 응답을 발생시킵니다.스테이션에서 응답하지 않을 경우, llc2 n2에 의해 정의된 재시도 횟수가 만료될 때까지 LLC2 tpf 시간 이후에 스테이션이 재시도됩니다.그 때 세션이 중단됩니다.
유휴 시간을 늘려 LLC2 회로의 오버헤드 양을 줄이고 이를 로컬 ACK의 대안으로 조정할 수 있습니다.200개의 DSPU가 NCP에 연결된 예를 가정해보겠습니다.각 PU는 독립적인 LLC2 세션을 유지 관리합니다.각 유닛이 10초마다 keepalive를 전송하면 초당 20프레임의 오버헤드가 발생합니다.유휴 시간을 30초로 늘리면 오버헤드 프레임의 양이 초당 6.67프레임으로 줄어듭니다.이러한 접근 방법의 단점은 역들이 파트너에 연결할 수 없다는 사실을 확인하는 데 시간이 더 걸린다는 것입니다.하지만 당신의 상황에 따라, 이것은 좋은 것일 수 있습니다.
명령 | 기본값 | 설명 |
---|---|---|
llc2 ack-delay-time>/b> msec | 100 | ack-max 값에 도달하지 않은 경우 승인을 보내기 전에 응답을 기다리는 시간입니다. |
llc2 ack-최대 개수 | 3프레임 | 승인을 보내기 전에 받을 프레임 수입니다. |
llc2 유휴 시간 msec | 10000 | 유휴 기간 동안 폴링 간격 시간입니다. |
llc2 로컬 창 수 | 7 프레임 | 응답을 대기하기 전에 보낼 프레임 수입니다. |
LLC2 n2 카운트 | 8회 재시도 | 세션을 종료하기 전에 회신을 받지 않고 미승인 I 프레임 또는 폴링이 전송된 횟수입니다. |
llc2 t1 시간 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
양쪽 끝에 토큰 링 LAN이 있는 일반적인 DLSw+ 네트워크에서는 발신 토큰 링 인터페이스에서 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 매개변수 컨피그레이션은 FAP(DLSw1 라우터) 및 PC(DLSw2 라우터)에 대한 LLC2 매개변수와 일치해야 합니다. 중앙 사이트 DLSw+ 피어가 CIP 라우터에 있는 경우 컨피그레이션이 약간 다릅니다.
원격 DLSw+ 라우터 컨피그레이션은 변경되지 않습니다.그러나 중앙 사이트의 LLC2 세션은 IOS의 CIP와 LLC2 스택 사이에 있습니다.CIP는 메인프레임을 나타내고, 메인프레임에서 IOS로 향하는 LLC2 매개변수는 CIP의 LAN Token Ring(LAN 토큰 링)의 어댑터 아래에 구성됩니다. 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+에 연결되는 경우 LLC2 매개변수는 DLSW+ bridge-group 문에 다음과 같이 구성됩니다.
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 매개변수 컨피그레이션만 표시됩니다.
참고: 이더넷 0 인터페이스에서 LLC2를 구성할 수 있지만 이러한 매개변수는 아무런 영향을 미치지 않습니다.DLSw bridge-group LLC2는 Cisco IOS Software 릴리스 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 세션에서 발생하는 일부 오류는 정상적인 것으로 복구할 수 있습니다. 예를 들어, 간혹 누락된 프레임 또는 프레임 순서가 잘못되었습니다.일반적으로 REJ 및 재전송된 프레임이 생성됩니다.과도한 재전송은 정상적이지 않으며 원인을 파악하고 문제를 해결해야 합니다.삭제, 다중 경로, 정체 및 과도한 레이턴시로 인해 과도한 재전송이 발생할 수 있습니다.
LLC2의 일부 오류는 복구할 수 없으며 항상 세션 중단이 발생합니다.이러한 오류는 전용 프로토콜 위반입니다.스테이션에서 정의되지 않은 컨트롤 필드나 기타 잘못된 정보를 보낼 때 발생할 수 있습니다.이러한 프로토콜 위반은 스테이션에서 FRMR 응답을 전송할 수 있습니다.가해자가 아닌 메신저일 뿐이다.FRMR에는 FRMR이 전송되는 이유를 식별하는 정보가 포함되어 있습니다. 이는 일반적으로 스테이션에서 이미 인식한 I 프레임을 다시 전송하도록 다른 스테이션을 요청할 때 발생합니다.스테이션에서 프레임을 재전송할 수 없으므로(이미 삭제되었으므로) LLC 세션을 종료할 수밖에 없습니다.이러한 유형의 오류가 발생할 경우 프레임 순서가 잘못되었을 가능성이 높습니다.