숭늉이

1. Congestion Avoidance

Congestion Avoidance란 무엇인가?

- Qos의 혼잡 회피 메커니즘은 TCP 프로토콜이 네트워크 상에서 패켓 손실 후, 전송 속도를 줄이는 TCP 혼잡 제어 메커니즘을 기반으로 동작한다. 이 방법은 큐에 혼잡이 발생되기 이전에 미리 일부의 TCP 패켓을 드롭시켜 큐에 들어오는 TCP 트래픽의 양을 줄이게 만드는 것이다.

- 따라서 큐의 혼잡을 예방해 네트워크의 성능을 저하시키는 ‘Tail-Drop(테일 드롭)’과 ‘Global Synchronization(글로발 싱크로나이제이션)’ 현상이 발생하는 것을 미리 방지한다. 즉, 결과적으로 지연과 지터를 줄이는 역할을 수행하는 것이다.

Congestion으로 인한 Tail-Drop and Global Synchronization 현상 발생

- 혼잡은 적정 수준의 이상으로 큐에 패켓이 쌓여 있는 현상을 말한다. 이 현상은 주로 대량의 패켓이 들어오거나 과도한 쉐이핑으로 인하여 큐에 트래픽이 쌓여 있는 상태에서 발생된다. 이렇게 혼잡이 발생한 상황에서 패켓들이 계속 들어온다면 큐의 용량은 한계가 되어 부하될 것이다.

- 이때 큐의 용량을 초과하여 패켓들이 버려지는 현상을 ‘Tail-Drop(테일 드롭)’이라고 한다. 테일 드롭이 발생하면 해당 네트워크상에 있는 대부분의 시스템들은 성능이 저하되는 ‘Global Synchronization(글로발 싱크로나이제이션)’ 현상이 발생된다.

TCP Congestion에 대해서 알아 보도록 하자.

- 초기에는 TCP가 구현될 당시에는 패켓이 손실되거나 다른 이유로 인해 승인 패켓이 수신되지 않는 경우 RTO(Retransmission Timeout)만큼 기다렸다가 다시 전송을 시작하는 것이 거의 전부라고 할 만큼 혼잡 제어의 개념이 포함되지 않았다.

- 또한, 네트워크 전송 속도나 전송되는 정보의 양이 현재와는 비교할 수 없을 정도로 소량이기 때문에 필요성이 부각되지 않았다. 그러나 현재 인터넷 사용자가 증가되면서 인터넷상의 라우터들을 연결하는 링크의 속도 차이로 인하여 라우터 버퍼의 오버플로우가 발생하고, 이로 인한 패켓 손실이 급격하게 증가되었다.

- 예를 들면, 수신측에서 허용 용량만 송신쪽에서 전송한다면 혼잡을 발생하지 않으나, 그 반대 경우라면 혼잡이 발생되어 해당 패켓들이 폐기되는 현상이 발생될 것이다.

2. TCP Slow Start and TCP Congestion

TCP 연결이 초기화 됐을 때 현재의 연결로는 어느 정도의 전송 속도를 수용하는 부분은 예측하기 힘들다. 그렇다고 한번에 많은 패켓들이 전송했다가 혼잡 현상이 발생된다면, 더 큰 글로발 싱크로나이제이션 현상의 원인이 된다.

그렇기 때문에 현재 연결이 어느 정도의 전송 속도를 수용할 수 있는지를 파악하는 부분은 상당히 중요하다. 이 문제를 TCP Slow Start 알고리즘이 해결하였다.

- 위의 그림을 보면 TCP 연결이 된 이후, Sender는 초기 CWND(Congestion Window)를 ‘1’로 설정해 ‘패켓 ‘를 전송한다. ‘패켓 1’을 수신했다는 ACK를 Receiver로부터 수신하면, Sender는 CWND를 1 증가시키므로 2개의 패켓(패켓2,3)이 전송된다. 이 후 2개의 Receiver로부터 2개의 ACK를 수신하면 다시 CWND를 2 증가시키므로 4 개의 패켓(패켓 3,4,5,6)이 전송된다. 이와 같은 방식으로 ACK가 한 수신될 때마다 계속 윈도우 싸이즈를 1만큼 증가시키게 된다.

- 즉, ‘TCP Slow Start’ 동안 Sender는 하나의 ACK를 수신할 때마다 윈도우를 1 증가시키기 때문에 결과적으로 하나의 ACK를 수신할 때마다 2개의 추가적인 패켓을 전송할 수 있게 된다.

- ‘Slow’라는 말과는 달리 실제로 윈도우 싸이즈는 급속히 증가되게 된다. ‘Slow Start’ 상태에서의 윈도우는 지속적으로 계속 증가되는데, 윈도우의 크기가 임계값(ssthresh)과 같아지면 TCP 혼잡 회피가 시작된다. ‘Slow Start’와 달리 TCP 혼잡 회피 상태에서는 하나의 ACK는 혼잡 윈도우의 크기를 1씩 증가시킨다.

- 예를 들어, CWND의 값이 10인 상태에서 10개의 패켓이 안전하게 전송됐다는 승인 패켓을 수신하면, CWND의 값을 11로 증가시킨다. 여기서 중요한 점은 혼잡 회피에서의 CWND의 값은 ‘Slow Start’에 비해 훨씬 느린 속도로 증가한다는 것이다.

3. TCP Congestion Control Mechanism 

Sender의 상태가 ‘TCP Slow Start’ 상태이건, ‘TCP Congestion Avoidance’ 상태이건 간에 현재 연결이 유지되고 이를 통해 패켓들이 전송되는 한, 윈도우 싸이즈는 지속적으로 증가하고 언젠가는 혼잡으로 인한 패켓 손실이 발생된다. 이 문제를 해결하는 기능이 바로 TCP 혼잡 제어 메커니즘이다.

- TCP 프로토콜에서 패켓이 전달되는 과정을 쉽게 설명하면 처음 TCP 연결이 시작된 이후 전송을 시작할 때, 처음 윈도우 크기를 1로 설정해 전송을 시작하며, RTO(타임아웃)이 발생되기 전에 ACK를 수신할 경우에는 윈도우 싸이즈를 2배로 증가시킨 후 전송한다.

- 만일, 타임아웃이 발생될 때까지 ACK를 수신하지 못하면, ssthresh(임계값)을 윈도우 싸이즈의 반으로 설정하고, 윈도우 크기를 1로 재전송을 시작한다. 이후 윈도우 크기를 2배씩 증가시키다가 윈도우 크기가 ssthresh(임계값)보다 커지면 윈도우 크기를 1씩 증가시킨다.

TCP Sender가 RTO(타임아웃)이전에 ACK를 수신하면

- CWND가 Threshold 보다 큰 경우: CWND = CWND + 1

- CWND가 Threshold 보다 작은 경우 : CWND = CWND * 2

TCP Sender가 RTO(타임아웃)이전에 ACK를 수신하지 못하면

- Threshold = CWND / 2

- CWND = 1

4. Global Synchronization

Global Synchronization(글로발 싱크로나이제이션)는 혼잡 발생시 네트워크의 대표적인 불안 요소 중 하나이다.

- TCP가 동작 특성상 네트워크의 전송상태가 좋은 경우에는 트래픽을 많이 전송하고, 패켓 손실이 발생하면 전송하는 트래픽의 양을 줄여서 전송한다. 이 동작으로만 본다면 TCP는 상당히 체계적인 프로토콜이라 할 수 있지만, 바로 이런 TCP의 혼잡 제어 메커니즘 때문에 또 다른 문제를 야기시키게 된다.

- 한 예로, 일반적인 네트워크 환경에 라우터가 외부 네트워크와 연결되어 있고 내부에는 스위치 아래 호스트 PC들이 연결되어 있다. 모든 호스트 PC들은 라우터를 통해서 외부 네트워크와 연결되어 있다. 동시에 여러 PC들이 인터넷을 접속하게 되면 TCP의 동작 상황에 따라서 라우터의 출력 인터페이스 버퍼에는 여러 개의 TCP 플로우가 존재하게 된다.

- 이럴 경우 큐 싸이즈는 빠른 속도로 증가하게 되며, 이내 버퍼풀(Buffer Full)현상이 발생되어, 오버플로우가 발생된다. 그러면, 모든 TCP 플로우들은 버퍼풀(Buffer Fulll) 이후에 도착한 모든 패켓들은 ‘Tail-Drop’에 걸릴 것이고, 모든 호스트 PC들은 RTO(타임아웃)이 발생될 때까지 잃어버린 패켓들에 대한 ACK를 받지 못하게 된다.

- 결국, 모든 호스트 PC들은 자신의 전송 속도를 줄이게 되며, 즉 윈도우 싸이즈 크기를 1로 줄이며, 빠른 속도로 큐 싸이즈는 줄어들게 된다.

- 그러나 다시 ‘Slow Start’ 과정으로 인해 큐 싸이즈는 증가될 것이고, 오버플로우가 발생하며, 모든 TCP 플로우에 대해 동일한 반복 과정이 일어나게 된다.

- 이런 현상을 바로 ‘Global Synchronization(글로발 싱크로나이제이션)’이라고 하며, 트래픽 양의 급격한 몰림현상으로 인해 성능은 물론 네트워크 장비까지 불안정해지는 원인이 된다.

- 이를 해결 하는 방법에는 RED(Random Early Detect), WRED(Weighted Random Early Detect) 기능이 있다.

5. RED(Random Early Detect) Mechanism

RED 동작 과정에 대해서 알아보도록 하자.

- 평균 큐 싸이즈가 ‘TH_min’ 보다 작은 경우에는 어떠한 패켓도 버리지 않고 받아 들인다.

- 큐 싸이즈가 ‘TH_min’ 보다는 크지만, ‘TH_max’ 보다는 작은 경우 큐 싸이즈에 따라 특정한 확률값을 갖고 패켓을 버린다.

- 큐 싸이즈가 ‘TH_max’ 보다 큰 경우는 입력되는 모든 패켓은 버린다. 즉 혼잡의 정도가 심해질수록 많은 패켓을 버림으로써 입력되는 트래픽의 양을 줄이려는 방법이다.

- 일반적으로, ‘TH_max’ 값이 너무 작으면 패켓 드롭이 자주 발생되어 전체 성능에 심각한 영향을 끼칠수 있으며, ‘TH_max’ 이상에서 모든 입력되는 패켓을 버리는 동작이 오버플로우에 의한 결과와 동일하기 때문에 ‘TH_max’를 큐의 최대 크기와 같거나 가까운 값으로 설정을 하게 된다.

- 또한 ‘P(드롭 가능성)’의 값이 너무 작으면 패켓이 드롭되는 빈도가 낮아져 혼잡 제어 효과가 제대로 나타나지 않는다.

- 따라서, RED를 사용할 때는 ‘TH_min’, ‘TH_max’, ‘P(드롭 가능성)’의 변수값을 적절하게 설정해야 한다.

6. WRED(Weight Random Early Detect) Mechanism

WRED(Weight Random Early Detect)는 RED에서 중요 트래픽에 대해서 랜덤하게 드롭되는 것을 방지하기 위해 중요 트래픽에 가중치를 부여하여 그 문제를 해결한다. 즉, WRED는 하나, 또는 여러 개의 서로 다른 클래스 트래픽에 서로 다른 특성을 갖는 RED를 적용함으로써 혼잡 제어를 하는 것을 말한다. 여기서 서로 다른 특성을 갖는 RED란 ‘TH_min’, ‘TH_max’, ‘P(드롭 가능성)’ 값이 서로 다른 RED 패켓 드롭 확률을 말한다.

- 낮은 우선순위의 패켓, 또는 클래스에 대해서는 더욱 공격적인 패켓 드롭이 발생하며, 우선순위가 높은 패켓, 또는 클래스에 대해서는 보수적인 패켓 드롭이 발생된다.

- 위의 그림을 보면 A 는 낮은 우선순위를 갖고 있다. ‘TH_max’가 B 의 ‘TH_min’보다 크게 설정된 경우를 볼 수 있으나, A 의 ‘TH_max’가 B 의 ‘TH_min’보다 반드시 작거나 같아야 하는 조건을 줄 수도 있다. 비록 같은 클래스에 속한 패켓들이지만, 드롭 우선순위가 다르며, 서로 다른 RED가 적용된다.

- 위의 그림을 보면 큐에 10개의 패켓이 들어있는 상태에서 새로운 패켓이 들어왔을 경우 새로 들어온 패켓이 ‘파란색 점선’ 패켓이라면 랜덤하게 드롭이 되지만, ‘빨간색 실선’ 패켓이 들어오면 정상적인 서비스가 이루어 진다.

- 또한, 큐에 패켓이 30 이상 들어있는 상태에서는 ‘파란색 점선’ 패켓은 100% 드롭이 실시되며, 나머지의 여유 공간은 ‘빨강색 실선’ 패켓이 서비스된다.

- 즉, 중요한 트래픽을 ‘빨강색 실선’으로 정의하고, 중요하지 않는 트래픽을 ‘파란색 점선’으로 정의하여 서로 다른 우선순위를 부여함으로써 차별화된 서비스를 제공할 수 있게 된다.

1. Meter and Marker

Meter(미터)란 장비로 입력되어 분류된 트래픽 플로우를 측정하는 것을 말한다. 일반적으로 트래픽 플로우의 입력 속도를 이용해 대역폭을 측정하거나 버스트 정보를 측정하는데, Meter(미터)는 미리 약속된 트래픽 프로파일과 입력된 트래픽의 프로파일을 비교함으로써 초과여부를 결정한다. 그 결과에 따라서 Marker(마커)는 해당 패켓에 적절한 Marking(마킹)을 실시할 수 있다. Meter(미터)는 일반적으로 다음과 같은 경우에 수행된다.

- 미리 약속된 트래픽 프로파일을 만족하는 경우

- 일정한 범위 내에서 초과하는 경우

- 일정한 범위를 넣어서 초과하는 경우

- DiffServ Model에서는 미터를 수행할 때 Green, Yellow, Red로 구분하지만, Cisco에서는 Conform, Exceed, Violate로 구분된다.

- 위의 그림은 DiffServ Model에서 사용하고 있는 듀얼 토큰 바스킷 구조의 ‘sr-TCM’에 대한 동작을 나타내고 있다.

- 토큰이 떨어지는 속도로는 CIR를 사용하여, 입력된 패켓의 크기가 토큰 카운터의 Tc보다 작으면 Green Packet으로 마킹 된다.(Cisco에서는 Conform으로 처리)

- Tc보다 크지만 Te보다 작은 경우 Yellow Packet으로 마킹 된다.(Cisco에서는 Exceed로 처리)

- 만약, Te보다도 큰 경우에는 Red Packet으로 마크된다.(Cisco에서는 Violate로 처리)

2. Marking : IP Precedence

IP Precedence 필드

- DiffServ Model이 사용되기 이전에 QoS를 보장하기 위해 사용한 필드이며, IP Header에 ToS(Type of Service) 필드의 상위 3 Bit를 사용하여 표기한다.

- ‘0’부터 ‘7’까지의 숫자로 사용되거나, 문자로도 사용 가능하다. 숫자로 사용할 경우 큰 수일수록 우선순위가 높다는 의미를 갖고 있다.

- ‘0’의 값은 우선순위가 가장 낮은 BE(Best-Effort)를 말하며, ‘6~7’은 인터넷용과 네트워크용으로 예약되어 있는 값이며, 실제 가장 우선순위가 높은 것은 ‘5’값이다. (음성 트래픽은 ‘5’로 처리하는 것이 일반적이다.)

- 위의 그림을 보면, ToS 8 Bit 중 상위 3 Bit가 IP Precedence로 표기되는 것을 확인할 수 있다. IP Precedence 뒤에 4 Bit는 ToS 필드이며, 각 해당 비트마다 신뢰성, 처리량, 지연, 거리비용을 나타낸다.

- 마킹 설정을 할 때에는 MQC 구문과 ‘Route-map’ 구문을 이용하여 할 수 있다.

[MQC 3단계]

0. ACL

1. Class-map 분류

2. Policy-map 정책,마킹

3. Service-police 적용

3. Marking : DSCP

DSCP(Differentiated Service Code Point)필드

- 기존 IP 체계에 변화 없이 헤더 값에서 IP Precedence와 ToS필드가 사용했던 Bit를 대체하는 방법으로, 기존의 IP Precedence가 트래픽 플로우에 대해서 세부적인 컨트롤을 할 수 없었던 것을 부분을 보안하였다.

- IP Header의 ToS 8bit 중 6 Bit를 사용하여 DSCP 필드 값으로 전환된다.

- 패켓들은 최대 64개의 클래스로 구분되며, 필드 중 제일 마지막 6번째 Bit값이 ‘1’인 Bit는 실험 예약용으로 예약되어 있다. 그렇기 때문에 실제로는 32개의 표준 PHB(Per-Hop Behavior)가 클래스 사용될 수 있으며 4 가지 Type의 DSCP가 존재한다.

4. Traffic Shaping and Policing

Traffic shaping(쉐이핑)과 Policing(폴리싱)은 DiffServ Model의 Conditioner에서 담당하고 있으며, 트래픽 대역폭을 제어하는 대표적인 기능이다. 쉐이핑과 폴리싱은 모드 토크 버킷(Bc) 메커니즘을 사용하여 임계값을 초과한 트래픽에 대해서 어떻게 처리할 것인가를 결정하는 공통된 일을 수행하는 반면에, 쉐이핑은 버퍼링을 사용하여 지연을 발생시켜 해당 트래픽의 Drop율을 최소화를 하지만, 폴리싱은 버퍼링을 사용하지 않으면서 일정량의 대역폭이 초과되면 해당 트래픽을 Drop을 시켜버린다. 또한, 쉐이핑과 폴리싱을 사용함으로써 P2P 트래픽을 전체 대역폭의 20% 이하로 제한할 수 있으며, DoS 공격에 대비한 Ping 패켓을 전체 대역폭의 2%로 제한할 수도 있다.

토큰 버킷(Token Bucket)은 트래픽 쉐이핑과 폴리싱에서 사용하는 기본적인 알고리즘이다. 이 알고리즘은 차후 CAR(Commited Access Rate), 클래스 기반 폴리싱, FRTS(Frame-Relay Traffic Shaiping)에서 사용되어 진다. 토큰 버켓 알고리즘이 사용하는 변수 단위에 대해서 알아보도록 하자.

- CIR : Commited Information Rate, in bits per Second

- Bc : Conformed Burst Size, in bits, Be : Exceed Burst Size, in bits

- Tc : Time Interval

트래픽 쉐이핑 : 쉐이핑은 트래픽의 속도와 대역폭을 제한하는 기술로, 버퍼링을 사용해 제한 속도이상으로 들어오는 트래픽을 잠시 저장하였다가 나중에 서비스하는 방식을 말한다. 쉐이핑을 오늘날에 거의 대부분의 중요한 QoS를 해결하는 이슈가 되었으며, 특히 폴리싱으로 해결할 수 없는 Egress Blocking에 대한 지연이나, 패켓 손실 문제를 해결하였다. 쉐이핑은 어느 정도 버스트 트래픽을 수용할 수 있다는 점과 폴리싱에 비해 패켓 손실률을 줄이고, 전체적인 ‘ThroughPut’을 향상시킬 수 있다는 장점을 갖고 있다. 하지만, 버퍼링으로 인해 지연이 커질수 있으며, 큰 버퍼를 사용할 경우, Real Traffic에 영향을 줄 수 있는 단점을 갖고 있다. 라우터에서 구현할 시에는 주로 출력 인터페이스에 실시한다.

트래픽 폴리싱 : 폴리싱은 트래픽의 속도와 대역폭을 제한하는 기술로, 버퍼링을 사용하지 않으며, 제한 속도이상으로 들어오는 트래픽을 드랍시키는 서비스 방식이다. 폴리싱은 네트워크 자원 부족 문제를 해결하며, 효율적인 자원 사용을 할 수 있는 트래픽 엔지니어링을 지원한다. 원래 폴리싱은 주로 ISP 가입자별로 과금에 맞는 대역폭을 조절하는 방법으로 사용하였으나, 현재는 QoS 용도로 많이 사용된다. 폴리싱은 버퍼링을 하지 않기 때문에, 쉐이핑에 비해서 부하가 적으며, 라우터에서 구현할 시에는 주로 입력 인터페이스에 실시한다.

5. Traffic Shaping

초과된 트래픽(Exceed Traffic)에 대해 쉐이핑과 폴리싱의 처리 방법의 차이점을 보여주고 있다. 쉐이핑은 초과된 트래픽(Exceed Traffic)을 잠시 저장하기 위해 버퍼나 큐를 사용하기 때문에 주로 출력 쪽에서 구현하는 것이 일반적이다. 트래픽 쉐이핑이 필요한 경우는 다음과 같다.

- ISP에서 폴리싱을 적용했을 경우 문제점 : Frame-Relay 환경을 ISP로부터 256 Kbps의 CIR 서비스를 받는다면, 초당 256 Kbps까지는 전송 속도를 보장받는다는 것이다. 만약 이때 포트 속도 역시 256 Kbps라면 트래픽 쉐이핑을 실시할 필요성이 없다. 그러나, 만약 사용자 포트 속도가 T1이라면 이때는 트래픽 쉐이핑이 필요하다. 쉐이핑을 해주지 않으면 ISP측에서는 256 Kbps가 넘는 트래픽을 폐기시키거나, DE bit를 마킹하여 폴리싱을 할 수도 있다. 만약 폐기되는 트래픽이 음성이거나 TCP 트래픽일 경우 문제가 된다. 그래서 ISP측에서는 폴리싱을 하기 이전에 미리 허용된 범위에 맞게 조절해 보내기 위해서 사용자 라우터에서 트래픽 쉐이핑을 실시해야 한다.

- Egress Blocking 현상을 해결하기 위한 경우 : Frame-Relay WAN 구간 환경을 사용할 경우, 본사측의 회선이 T1이고 30개의 지사측의 회선이 128 Kbps일 때 동시에 30개의 지사측에서 본사측으로 트래픽을 전송할 때, 즉 한곳으로 트래픽이 몰릴 경우 혼잡이 발생된다. (128 Kbps X 30 > T1) 이런 경우 본사측의 회선의 용량이 부족하여 혼잡이 생기며, 이런 현상을 ‘Egress Blocking’이라고 하며, 트래픽 쉐이핑으로 이 문제를 해결할 수 있다. (Frame-Relay 구간의 쉐이핑을 FRTS라고 한다.)

6. FRTS(Frame-Relay Traffic Shaping) Command

FRTS(Frame-Relay Traffic Shaping) 구성은 다음과 같다.

- FRTS를 적용할 물리적인 인터페이스에 ‘frame-relay traffic-shaping’ Command를 사용하여 트래픽 쉐이핑을 시작해야 한다.

- ‘map-class’ 구문을 사용하여 CIR, Bc, Be, MinCIR 변수 값을 정의한다.

- 앞에서 정의한 ‘map-class’ 구문을 쉐이핑을 적용하고자 하는 인터페이스에서 ‘frame-relay class’ Command를 이용하여 적용을 실시한다.

- 위의 예제는 본사측 라우터 Frame-Relay 인터페이스에서 FRTS를 적용한 예제이다. 이때 FRTS에 필요한 변수 값은 다음과 같다.

- CIR = 64 Kbps, Tc = 125 ms, Be = 8000 bit

MQC 설정 방법은 다음과 같다.

Router(config)# class-map ANY

Router(config-cmap)# match any

Router(config-cmap)# policy-map FRTS

Router(config-pmap)# class ANY

Router(config-pmap-c)# shape average 64000 8000 4000

Router(config-pmap-c)# interface s 0/0.1 point-to-point/multipoint

Router(config-if)# service-policy output FRTS

1. Propagation Delay

‘Propagation Delay’라고 불리는 전달 지연은 특정 매체로 구성된 링크를 통해 한 비트를 전달하는데 소요되는 시간을 말한다. 예를 들면, 전철이 역을 빠져나가 다음 역까지 도착하는데 걸리는 시간을 말한다. 위의 그림을 보면서 전달지연의 특징을 알아보도록 하자.

- 전달 지연은 동일한 물리적인 링크에서 대역폭과 패켓의 길이와는 상관없이 동일한 지연 시간을 갖는다.

- 일반적으로 네트워크에서 전달 지연은 매우 희미하게 발생되므로 큰 문제는 되지 않지만, 물리적인 링크의 길이가 길면 길수록 비례적으로 전달 지연도 증가하기 때문에 문제가 될 수 있다.

- Copper 망, Optical 망은 진공 상태에서 빛의 속도(‘3.0 x 108 m/s’)의 70% 속도인 ‘2.1 x 108 m/s’를 사용한다.

- D 구간의 거리가 현재 1000 Km이므로 전달지연을 계산하면 ‘1,000,000 / (2.1 x 108) = 4.8 ms’ 시간이 나온다.

- 각 구간에서 전달 지연과 연속 지연을 비교하면 패켓의 크기에 의해서 연속 지연은 변하지만, 전달 지연은 동일한 것을 확인 할 수 있다.

2. Queuing Delay

‘Queuing Delay’라고 불리는 큐잉 지연은 패켓이 전송되기 전에 라우터 큐에 패켓이 대기하는 소요 시간을 말한다. 큐의 위치에 따라 Input Queue와 Output Queue로 구성되지만, Input Queue에 대한 지연은 작기 때문에, Output Queue 지연에 대한 부분을 처리한다. 또한, 큐잉 지연이 차지 하는 부분은 다른 지연에 비해 크기 때문에 QoS 구현 시 중요하다.

- 만약 56Kbps 대역 구간으로 Host에서 Server로 4개의 1500 Byte 패켓을 전송하게 되면, 첫 번째 패켓이 라우터 큐를 떠나는데 걸리는 시리얼화 시간은 ‘1500 x 8 / 56,000 = 214 ms’가 소요된다. 즉, 두 번째 패켓은 라우터의 큐에서 214 ms를 대기하고 난 이후 전송된다. 또한, 세 번째 패켓은 시리얼화 계산을 실시하면 428 ms, 네 번째 패켓은 642 ms를 큐에서 대기하고 있을 것이다.

- 만약, 100개의 1500 Byte 패켓을 전송하게 되면, 마지막 패켓의 큐잉 지연은 ’214 ms x 99 = 21,186 ms’가 된다. 또한, TCP 패켓이라면 재전송을 실시하여 더 많은 지연을 발생할 것이다.

- 적절한 길이의 큐는 패켓 손실을 해결하지만, 너무 긴 큐는 장시간 지연의 큰 원인이 되며, 큐잉 지연은 QoS 중에 가장 비중이 큰 부분 중 하나이다.

3. Forwarding Delay and Shaping Delay

‘Forwarding Delay’라고 불리는 포워딩 지연은 해당 패켓이 라우터 및 스위치에 인바운드 인터페이스로 들어와서, 라우팅 및 스위칭 프로세서에 의해 경로가 결정된 이후, 아웃바운드 인터페이스의 나가는 큐에 대기할 때까지 소요되는 시간을 말한다.

- 라우팅 및 스위칭 프로세서에 따라서 차이가 있으며, 일반적으로 스위치가 라우터에 비해 지연이 작다.

- 스위치는 ‘Store-and-Forward’ 방식보다는 ‘Cut-Through’으로 동작하여, 라우터보다 더 작은 포워딩 지연을 실시하며, 라우터 또한 ‘CEF(Cisco Express Forwarding)’ 방법을 이용하여 포워딩 지연을 작게 한다.

‘Shaping Delay’라고 불리는 쉐이핑 지연은 트래픽 쉐이핑 프로세서에 의해 지연되는 소요 시간을 말한다.

- 트래픽 쉐이핑을 사용하면 지연은 길어지지만, 계약된 대역폭을 초과하는 패켓에 대해서 Drop/Discard 현상을 해결할 수 있으며, 두 가지 형태로 사용할 수 있다.

- 일반적으로 출력 시 사용이 되며, 해당 데이터에 대해서 한도 대역이 초과되면 버퍼링을 실시한다.

- 첫 번째, 패켓들이 Drop되지만, 고속 전송되는 경우

- 두 번째, 패켓들이 Drop되지 않지만, 느리게 전송되는 경우

4. Jitter and Packet Loss

‘Jitter’란 어떤 신호가 네트워크를 통해 전송되면서 원래의 신호로부터 왜곡된 정보를 나타내는데 사용되는 값을 말한다. 즉, 지연의 편차라고 말한다.

- 네트워크 전송에서 패켓에 대한 어느 정도의 지연은 감수해야 한다. 동일한 시간의 네트워크 서비스에서 큰 문제는 되지 않는다.

- VoIP에서도 일정한 범위내의 동일한 지연은 큰 문제를 일으키지 않지만, 지연 값이 각각 다르면 VoIP와 같은 양방향 어플리케이션 서비스를 제공하는데 큰 문제점이 될 수 있다.

- 위의 그림을 보면 R1의 VoIP 전화기에서 R3의 VoIP 전화기로 보낸 음성 데이터가 처음에는 20 ms의 동일한 지연을 가지고 전송되고 있다가, ISP 구간을 지나면서 지연의 변화가 발생됐다면, 음성 신호가 왜곡되고, 음질은 떨어지게 될 것이다.

‘Packet Loss’란 패켓이 전달되는 과정에서 발생하는 패켓의 손실률을 말한다. 물론 하드웨어적인 불량으로도 패켓 손실 현상을 일어나지만, 하드웨어가 문제가 없다면, 패켓 손실은 보통 Congestion(혼잡 현상)에 의한 버퍼 오버플로우시 발생하거나, RED(Random Early Detection)에 의한 패켓 Drop 현상에 의해 발생된다.

- Congestion(혼잡 현상) : 서비스를 할 수 있는 적정 수준 이상으로 큐에 패켓이 쌓여 있는 상태

- TCP처럼 흐름 제어를 하는 트래픽 소스가 전송 속도를 증가 시키는 경우

- 라우팅 알고리즘 때문에 많은 트래픽이 증가되는 경우

- 라우팅 패스에 오류가 발생되어 다시 라우팅 되는 경우

- 공격자로부터의 공격으로 인한 트래픽 증가 현상 경우

5. InterServ Model

기본적으로 인터넷은 네트워크 트래픽을 하나의 Class로 취급하여 동일한 정책을 적용하는 Best-Effort 방식을 사용하고 있다. 그러나 IETF에서는 인터넷상의 QoS를 제공하기 위해서 InterServ Model과 DiffServ Model 2가지 구분되며 보다 향상된 QoS Model를 정의하였다. 다음은 InterServ Model(IETF 1633)에 대해서 알아보도록 하자.

- InterServ는 트래픽 플로우 단위로 End-to-End 개념의 QoS를 보장하며, 이때, RSVP(Reservation Setup Procotol) 시그널링 프로토콜을 사용하다.

- 대역폭과 전송 측면에서 확실한 수준의 서비스를 제공하며, 플로우의 큐잉 지연 시간에 대한 상한의 임계치를 규정하고, 큐잉 서비스에 따른 패켓의 손실이 없다.

- 송수신자 상호간에 모든 라우터가 해당 트래픽 플로우에 대해 사용자가 요구한 서비스를 보장하기 위해 필요한 대역폭 자원을 예약해야 한다.

- End-to-End QoS를 구현하기 위해 각각의 라우터들은 ‘RSVP PATH’와 ‘RSVP RESV’를 이용하여 예약된 자원을 확보한다. 만약, 자원 예약 거부 시에는 ‘RSVP ERROR’를 사용하여 연결을 종료한다.

- End-to-End로 모든 라우터로 통과하는 트래픽에 대해 플로우로 구분하여 연결 상태를 감시하기 때문에 라우터 오버헤드가 증가되는 단점을 갖고 있다.

- 즉, InterServ Model은 트래픽 흐림에 대해 미리 예약한 방식으로, 그 흐름들에 대해서 Quaranteed Service와 Controller Load Service를 제공한다.

6. RSVP Signaling

송수신 상호간에 라우터들은 RSVP 시그널링인 ‘PATH Message’, ‘RESV Message’, ‘ERROR Message’를 이용하여 자원 예약을 실시한다.

- R1에서 H.225 메시지에 전화번호와 H.245 정보를 담아서 수신측 라우터 R3에서 전달한다.

- 송수신측 라우터는 각각 VoIP에 필요한 56 Kbps 트래픽 요구사항이 담긴 PATH 메시지를 전달한다.

- 여기서, 전화 서비스는 양방향 서비스이기 때문에 송신측에서 전화를 했지만 양쪽에서 PATH 메시지를 교환한다.

- PATH 메시지를 수신한 송수신측 라우터는 각각 PATH에 담겨있는 트래픽 정보를 참조하여 자원을 예약하기 위해 RESV 메시지를 전달한다.

- 송수신측 라우터간에 RESV 메시지를 수신하면 서로 통화가 가능하게 된다.

- 만약, 서비스가 거부된 라우터가 있다면, RSVP ERROR 메시지를 송신측에 전달하여 예약을 종료한다.

- 설정 :

Router(config-if)# ip rsvp bandwidth [1-10000000 Reservable Bandwidth(KBPS)][1-10000000 Largest Reservable Flow(KBPS)]

Router(config-if)# fair-queue 64 256 32  최대 예약 가능한 플로우는 32개

Router(config-if)# ip rsvp bandwidth 1000 500  최대 1000Kbps 중 플로우당 500Kbps 예약 가능

- RSVP가 예약하는 단위인 플로우별로 트래픽을 관리하는 WFQ(Weight Fair Queue) 큐딩 시스템을 이용하여 동적인 플로우는 최대 256개이며, RSVP는 최대 32개로 제한되어 있다.

7. DiffServ Model

DiffServ Model은 패켓들을 비슷한 성질을 가진 클래스 단위(트래픽 타입)로 구분해서 중요한 클래스에 대해서는 가중치를 두어 서비스를 실시하는 방법이다. DiffServ는 IntServ에 비해 100% 보장된 서비스를 제공하지는 못하지만, 대규모 네트워크 환경에서 구현이 쉽고 확장성이 뛰어나기 때문에 현재 인터넷에서 가장 많이 사용하는 방법이다.

- 먼저 Classifier(분류자)로 들어오는 트래픽을 다양한 기준에 따라 여러 개의 클래스로 구분한다. 여기서 도착한 패켓들이 어떤 클래스 큐에 저장될 것인지 결정하며, 이때 입력된 트래픽들은 ACL에 의해 플로우 단위로 구분되며, 이와 동시에 플로우가 속하게 될 트래픽 클래스가 결정된다.

- 즉, 입력된 트래픽이 실제로 저장될 큐와 서비스(스케쥴링)되는 방식이 결정된다. Classifier(분류자)를 통과한 패켓들은 각 트래픽 플로우에 할당된 Meter(미터)에 의해서 특성을 측정 받는다.

- 측정된 결과는 사전에 약속한 QoS 트래픽 특성과 비교되며, 그 결과에 의해서 Maker(마커)에 의해서 우선순위 별로 마킹된다.

- 마킹된 패켓들은 컨디셔널를 지나면서 사전에 약속한 트래픽의 대역폭 특성에 맞도록 조정되며, 컨디셔널은 Delay(지연)을 이용해 대역폭을 조절하는 Shaping(쉐이핑), Policing(폴리싱)을 실시한다.

- 트래픽 컨디셔널은 경우에 따라서 흐름제어(Flow Control)도 처리할 수 있다. 컨디셔널을 통과한 패켓들은 Queuing(큐잉)을 거치며 분류자에서 결정된 자신의 클래스에 큐에 저장된다.

- 큐에 저장된 패켓들은 스케쥴링 과정을 통해 출력 링크로 보내진다.

8. Classifier

Classifier는 분류자로써 DiffServ Model에서 처음 과정으로 실시된다. 들어오는 트래픽을 일정한 기준에 의해 여러 개의 클래스로 구분하되 여러 종류로 나누어 복잡하게 처리하는 것이 아니라, 여러 종류의 패켓을 제한된 몇 개의 클래스로 분류를 실시한다. 즉, Classfier는 다양한 패켓들에 대해서 구분을 실시 한다.

- Classifier는 비슷한 특징을 갖고 있는 패켓들을 함께 처리함으로써 QoS의 구조를 단편화를 실시한다. 즉, 다양한 QoS 특징을 갖는 트래픽들을 각각 처리한다면, 어떠한 방법의 처리 기준이 있어야 한다.

- 일반적으로 4개의 클래스별로 구분되며, 클래스가 많이 질수록 복잡성은 커지나 서비스에 대한 질은 향상된다. 실제 2개에서 8개 까지 사용이 가능하지만, 4개 클래스 사용이 권장사항이다.

- Classifier는 Standard ACL, Extended ACL, Named ACL, Class-map를 이용하여 해당 패켓을 정의 및 구분을 실시한다.

- 예를 들어 ACL 111에 정의된 패켓들은 첫 번째 Queue로 보내고, ACL 112에 정의된 패켓들은 두 번째 Queue로 보내고, 나머지는 패켓들은 4번째 큐로 보내고자 할 때, 즉 큐잉 작업을 수행하기 위해서는 Classifier 작업이 필요하다. (차후 쉐이핑, 폴리싱에서도 적용)

- ACL를 이용할 뿐만 아니라, 정책 기반 라우팅(PBR)을 이용할 수도 있다.

9. Classifier Example

Router(config)# access-list 111 permint tcp eq 1720 any

Router(config)# access-list 112 permint udp any any range 16384 32767

Router(config)# access-list 113 permint tcp any any eq telnet

Router(config)# class-map VOICE-S

Router(config)# match access-group 111

Router(config)# class-map VOICE-T

Router(config)# match access-group 112

Router(config)# class-map VOICE-T

Router(config)# match access-group 112

Classifier은 입력된 트래픽 패켓을 미리 설정된 기준에 따라 몇 개의 클래스로 구분하여 복잡한 패켓 분류 작업을 단편화를 실시한다. 또한, 패켓의 송수신지 IP 주소, TCP/UDP, Port Number를 검사하여 클래스로 분류한다.

- match access-group 111 : TCP 포트번호 1720 여부 확인

- match access-group 112 : UDP 포트번호 16384 ~ 32767 여부 확인

- match access-group 113 : TCP 포트번호 23 여부 확인

1. MPLS VPN

VPN(Virtual Private Network, 가상 사설망)은 공용 인터넷을 다른 사용자와 분리된 독립적인 네트워크 환경처럼 사용 가능하도록 하는 기술이다.

- VPN 대표적인 기술로 Layer 3 계층에서 동작하는 IPSec(IP Security), Layer 2 계층에서 동작하는 L2TP(Layer 2 Tunneling Protocol), GRE(Generic Routing Encapsulation), L2F(Layer 2 Forwarding), PPTP가 있다. 이 기술들의 공통점은 공용 네트워크 가입자마다 독립적인 네트워크를 구성하고 데이터에 대한 비밀성(3DES, RSA 사용), 무결성(SHA 해싱 알고리즘)과 사용자 인증을 위해 다양한 암호화 알고리즘 및 터널 기술를 제공한다. 하지만 데이터에 대한 암호화 및 복호화, 터널 생성을 위한 오버헤드가 크고 VPN의 구성과 관리는 가입자가 담당하는 부분이라 사용자 입장에서 어려움이 있다.

- 그러나 MPLS Layer 2 VPN은 VPN 서비스를 Provider측에서 제공하기 때문에, 기존의 가입자는 보안 장비(CPE)를 별도로 구매할 필요 없으며 단지 Provider의 VPN 서비스를 사용하면 된다. VPN과 관련된 모든 운영, 관리는 Provider 측에서 실시하며, MPLS Layer 3 VPN은 기존의 네트워크 환경에 대한 큰 변화 없이 기존 환경에서도 운영 가능하기 때문에 장비가 지원된다면 바로 적용 가능한 기술이다.

- MPLS Layer 3 VPN은 RFC 2547 정의이며, Provider의 백본 네트워크를 이용해 가입자에게 VPN 서비스를 제공하는 방법과 기술에 대한 내용을 정의하고 있다. RFC 2547를 흔히 ‘MP-BGP(Multi Protocol BGP)’라고 하며, 이것은 MPLS와 BGP 기능을 이용해 MPLS Layer 3 VPN 서비스를 제공하기 때문이다.

2. MPLS VPN Terms

MPLS VPN에서 사용되는 라우터 용어와 기능

- CE(Customer Edge) : 가입자 네트워크의 게이트웨이로 사용되는 라우터이며, 실제 가입자들이 연결되어 있다. 기존 VPN 기능을 사용하면 바로 CE 라우터에 VPN 관련 기능이 구성되겠지만, MPLS VPN은 가입자 네트워크에 어떠한 설정도 요구하지 않기 때문에 가입자 입장에서 편리성을 제공한다. 모든 VPN 구현은 Provider 입장에서 구성한다. CE 라우터와 Provider의 연결은 Static, IGP, BGP를 이용하여 연결 가능하다.

- PE(Provider Edge) : Provider에 속한 라우터이며, CE 라우터가 연결되며 가입자마다 별도의 VRF가 구성되어 다른 가입자의 라우팅 정보가 다른 가입자의 VRF와 충돌되지 않도록 한다. 또한, 가입자 네트워크에 대한 FEC에 Label를 Binding하고 LDP, RSVP를 이용하여 가입자의 목적지 PE 라우터와 LSP를 생성한다. PE는 MPLS의 Ingress 라우터로서 가입자의 데이터 패켓을 해당 VRF에 할당하고 목적지 PE 라우터에 있는 VRF의 Label 정보를 패켓에 추가한다. 또한, 목적지 PE 라우터까지 도달하기 위한 Label를 추가하여 PE 라우터의 Loopback 정보에 대한 Label로서 목적지 PE 라우터까지 도달하는데 사용된다. 즉, PE 라우터는 원래의 데이터에 ‘접속하려는 가입자에 대한 Label’, ‘목적지 PE 라우터까지 가는데 사용되는 Label’이라는 2개의 Label를 할당한다. 목적지 네트워크의 PE 라우터는 Egress 라우터로서 도착한 MPLS 패켓에서 Label를 제거하여 IP 패켓으로 전환하여 가입자 CE 라우터에게 전송한다.

- P(Provider) : Provider 백본에 위치한 라우터이며, MPLS의 Ingress와 Egress 라우터 사이에 LSP 경로 상에 있는 라우터이다. 실제 VPN 패켓에 대해서는 무관하며 패켓에 첨부된 Label의 값을 통해 LFIB(Label Forwarding Information Base)를 검색한다. 검색 후 해당하는 정보를 찾으면 해당 Label로 Swap하여 목적지 네트워크로 가기 위한 인터페이스를 통해 스위칭 역할을 한다.

3. MPLS VPN Architecture

인터넷은 개방성을 추구한다. 그렇기 때문에 TCP/IP 기본 요구사항을 만족시키는 시스템은 특별한 제한 사항이 있지 않는 한 전 세계 모든 컴퓨터와 연결될 수 있다. 이렇게 개방형 인터넷을 사설 네트워크처럼 사용하기 위해서는 일반적으로 인터넷 트래픽이 VPN 사용자의 내부로 들어가서는 안되며, 다른 VPN 가입자의 트래픽도 경우에 따라서 선택적으로 받아들일 수 있어야 한다.

- VPN은 인터넷으로부터 독립성을 보장받아야 하며, 이를 위해서 IPSec을 이용한 VPN 기능은 해당 데이터에 대해서 암호화를 실시하여 외부로부터의 불법적인 도청 및 감정으로부터 보호를 하며, 출발지와 목적지간에 전용 터널을 이용하여 가입자 네트워크를 인터넷과 분리시켜 독립성을 제공한다. 대신 암호화 및 복호화 과정에서 오버헤드가 증가된다는 단점을 가지고 있다.

- MPLS VPN은 IPSec와 다르게 해당 데이터에 대해서 암호화를 실시 하지 않기 때문에, 암호화 및 복호화 과정에서 오버헤드가 일어나지 않는 장점을 가지고 있다. 대신, Label 4 Bytes가 일반 IP 패켓에 추가되지만, IPsec과 비교하면 아무런 문제도 되지 않는다.

- MPLS VPN은 가입자의 네트워크를 일반 트래픽과 분리시키기 위해서 가입자 전용의 라우팅 테이블을 별도로 생성한다. 또한, 인터넷 트래픽은 라우팅 테이블에 의해 움직이므로 라우팅 테이블 자체를 분리시켜 불필요한 라우팅 정보를 제거하며, 그리고 가입자의 네트워크에 대한 라우팅 정보만을 저장하여 일반 트래픽은 가입자 네트워크로 접근할 수 없게 된다.

- 가입자 전용의 라우팅 테이블을 VRF(Virtual Routing and Forwarding)이라 하며, 가입자가 접속되는 Provider 라우터에서 생성된다.

4. MPLS VPN Architecture

MPLS VPN은 VPN 서비스를 Provider가 담당하므로 같은 IP 주소를 사용하는 가입자를 담당할 수 있는 방법이 필요하다. 위의 그림은 동일한 서브넷을 사용하고 있는 가입자를 담당하고 있는 PE 라우터들이다.

- PE 라우터는 동일한 서브넷을 사용하고 있는 두 가입자를 담당하고 있다. 그렇기 때문에 각 가입자의 IP 주소를 기존의 주소와 다른 주소 체계로 인식하기 위해서 기존의 IPv4 가입자 주소를 VPN-IPv4 주소로 변환시킨다. VPN-IPv4 주소는 위의 그림처럼 172.16.1.0/24와 같은 IPv4 형태의 주소에 가입자마다 고유 번호를 붙여 만드는 새로운 주소 체계이다.

- 즉, 가입자의 IPv4 주소가 동일하여도 가입자마다 고유 번호가 추가되기 때문에, 전체 네트워크에서 가입자의 IP 주소는 유니크하며 가입자의 IP 주소 중첩문제를 해결할 수 있다.

- IPv4 주소를 VPN-IPv4 주소로 전환하기 위해 필요한 고유 번호는 6 Byte이며, IPv4 주소 앞에 추가된다. 추가되는 가입자 고유 번호를 RD(Route Distinguisher)라고 부르며 2가지 유형이 있다.

- AS Number : zz

16 Bit 크기의 AS 번호와 32 Bit 임의의 숫자로 구성된 고유 번호, Ex) 100:1. 200:1

- IP Address : zz

32 Bit의 IP 주소와 16 Bit 임의의 숫자로 구성된 고유 번호, Ex) 172.16.1.1 : 1, 172.16.2.1 : 2

- RD는 VRF 설정에서 중요한 부분이며, 만약 RD가 없다면 VPN에서 유일한 주소를 만들 수 없을 것이다.

5. MPLS VPN Switching

MPLS VPN 가입자 네트워크는 변화에 대한 즉각적인 조치가 필요하다. 예를 들어 네트워크 환경에 대한 장애 발생, 네트워크 확장문제 등이 여기에 포함되어 있다. 즉, 가입자 네트워크에 발생한 변화는 MPLS VPN에 속해 있는 네트워크간에 전송되어 VRF는 항상 최신 정보를 유지해야 한다. 이때, VRF간에 최신 정보는 IBGP를 통해 전달된다.

- MPLS VPN에서 IBGP는 특정 VRF에 해당하는 라우팅 정보를 수신했을 때 정책을 통해 해당 VRF로 보내는 일을 한다. 위의 그림을 보면 Customers A와 Customers B 가입자를 담당하고 있는 PE1는 각각의 VRF 라우팅 정보를 IBGP 속성 중 Community값을 이용하여 목적지 PE3에게 가입자마다 설정된 Route-Target의 값을 전송한다. PE3은 PE1으로부터 수신한 라우팅 정보를 VRF로 전송할 때 Community값을 이용하여 라우팅 정보를 해당 VRF에 등록시킬 것 인지 결정한다.

- 위의 그림을 보면 Customers A의 라우팅 정보는 ‘Community 100:1’값을 IBGP 네이버 PE3에게 전송된다. 이때, 목적지 PE3는 자신의 VRF 중 ‘Community 100:1’값을 허용하는 VRF 정보가 있는지 확인한다. PE3에는 Customers A가 있고 해당 VRF는 ‘Community 100:1’ 값을 달고 오는 라우팅 정보를 허용하도록 설정되어 있기 때문에, PE3은 PE1으로부터 전달된 Customers A의 라우팅 정보를 해당 VRF로 등록시킨다.

- MPLS VPN에서 사용되는 BGP Community 속성은 MP-BGP를 위한 Extended Community라고 한다. 그렇기 때문에 Community 설정을 할 때는 상대편 라우터에게 Extended Community를 전달한다고 명시해야 한다.

- MPLS VPN에서 IBGP 역할은 가입자 네트워크의 Prefix 정보와 넥스트-홉 정보 및 Prefix에 할당된 Label 정보를 전달한다. IBGP를 통해 전달받은 라우팅 정보는 가입자의 VRF로 등록되기 때문에 다른 PE에 연결되어 있는 VRF에 대한 정보를 갖게 된다. (MP-BGP에서 IBGP는 풀-메쉬, RR 구조를 갖는다.)

6. MPLS VPN Data Transfer

사용자의 데이터가 MPLS의 어떤 기능과 개념이 사용되어 목적지까지 전달

- PE는 가입자의 데이트를 전송할 때 두 개의 Label를 생성한다. 위의 그림을 보면 MPLS VPN 데이터 전송에 대한 과정을 보여주고 있다. 가입자 데이터가 CE1를 통해 PE1까지 전송되면 가입자 인터페이스에 설정된 VRF 정보를 검색한 후, 수신된 패켓은 목적지 주소에 대한 FEC와 Mapping된 Label을 패켓에 추가하기 때문에, 수신된 패켓의 목적지 주소가 172.16.1.0/24이므로 FEC에 대한 Label이 원래 패켓에 추가된다.

- PE1은 이 패켓을 바로 전송하지 않고 IBGP를 통해 학습한 넥스트-홉정보에 해당 하는 Label를 추가하여 PE1은 목적지 PE2의 Loopback 주소인 1.1.1.1이란 FEC에 Binding된 Label를 추가한다. 이 Label은 가입자의 VRF에 대한 Label과는 다르게 PE1이 목적지 PE2에 도달하기 위한 것이다. 즉, 원래 데이터 패켓은 해당 목적지 VRF의 FEC에 대한 ‘Inner Label’과 넥스트-홉으로 지정된 PE2 라우터에 도달하기 위한 ‘Outer Label’를 추가하기 때문에 8Byte가 증가된다.

- P는 VPN 트래픽에 대해서는 무관하며, PE1으로 수신한 패켓의 Label에 따라서 목적지 PE2로 갈수 있도록 적당한 Label로 스위칭하는 역할만 수행한다. P가 사용하는 Label은 Outer Label(Top Label)이며, 위의 그림에서 보면 원래 ‘5 Outer Label’만 ‘4 Label’로 Swap을 실시한다. Inter Label(Bottom Label)은 전송과정에서 사용하지 않으며 최종 목적지 PE2에 도달하면 사용된다.

- 최종 목적지 PE2는 일단 도착한 패켓에 Outer Label 제거를 실시하며, Inner Label를 검사하여 해당 패켓이 어느 VRF로 갈 것인지 결정한다. 즉, PE2는 ‘4 Label’를 첫 번째로 제거하고, ‘7 Inner Label’를 통해 해당 데이터가 VRF CE1으로 가야 하는 것을 확인한다.

7. MPLS VPN Configuration Steps

IGP, BGP 라우팅 프로토콜을 이용하여 내부 네트워크에 대해서 라우팅을 실시한다.

- MPLS VPN은 IGP를 통해 학습한 라우팅 정보를 바탕으로 한 기술이다. IGP를 통해 학습한 라우팅 테이블을 이용하여 연결된 PE들의 위치를 확인한다.

- Multi-Hop 환경의 IBGP를 통해 가입자의 라우팅 정보가 교환되므로 IGP 역할이 중요하다. 즉, MPLS VPN을 구현하기 이전에 IGP, BGP 설정이 올바르게 되야 한다.

MLPS 설정을 실시한다.

- MPLS VPN은 라우팅 정보를 교환하기 위해 IBGP를 구현하여 실제 데이터를 전송하기 위해 Label를 이용한다. MPLS 패켓은 LSP 경로를 이용하여 이동하는데, LSP는 LDP, RSVP-TE를 이용하여 생성되기 때문에 MPLS를 설정하여 PE Ingress, PE Egress 상호간에 LSP가 정상적으로 생성되는지 확인해야 한다.

MPLS VPN(PE-to-PE) 관련 설정을 실시한다.

- PE-to-PE에 대한 설정을 실시한다. MPLS VPN에 관련된 가입자마다 독립된 VRF 테이블을 생성하며 VRF 상호간에 라우팅 정보를 교환하기 위한 정책을 설정한다.

MPLS VPN(PE-to-CE) 관련 설정을 실시한다.

- 가입자마다 네트워크 환경이 다르므로 적절한 설정을 실시한다. 가입자 네트워크 환경이 Provider와 어떤 관계를 가지고 있는지에 따라서 PE의 설정이 다르게 된다. 즉, CE와 PE 상호간에 Static 관계에 있는 환경에서의 설정과 Dynamic 관계에 있는 설정이 다르게 된다.

MPLS VPN 동작 모니터링을 실시한다.

- MPLS VPN을 구성하기 위한 필요한 IOS를 검색하고, 장비 자체가 MPLS VPN을 지원하지 확인 절차가 필요하다. 또한, 관리자의 실수로 인한 설정 문제, 네트워크 환경에 대한 장애 문제 등을 해결하기 위해서 관리자는 MPLS 모니터링을 실시해야 한다.

1. IP Routing

기존의 IP Routing을 하기 위해서 RIP, IGRP, EIGRP, OSPF, BGP 라우팅 프로토콜을 이용하여 라우터에 라우팅 테이블을 구성하였다. 또한, IP Routing 기반에 데이터 전송은 해당 데이터의 목적지 주소를 라우팅 테이블을 참조하여 넥스트-홉에게 전달 및 포워딩 하는 방법이다. 이러한 동작을 각각의 라우터에서 반복적으로 동작하여 해당 목적지로 데이터 전송이 보장된다. 즉, 라우터는 해당 패켓이 도착하면, 라우팅 프로토콜로 학습한 경로 정보를 라우팅 테이블에서 참조하여, 넥스트-홉에게 전달한다.

2. MPLS(Multi Protocol Label Switching)

MPLS(Multi Protocol Label Switching)은 기존의 IP Routing 데이터 전송 방식과 다르게, 데이터의 목적지 IP 주소를 확인하는 대신 ‘Label’이라고 불리는 패켓에 더해진 식별자를 확인하여 목적지까지 데이터를 전달 및 포워딩을 실시한다. 또한, IP 주소가 어떤 Label를 사용할 것인지를 광고하게 된다. 각각의 라우터는 라우팅 테이블과 동시에 Label 테이블을 학습한다. 즉, MPLS에서는 기존의 라우터의 동작 방식에 새로운 ‘Label’ 정보를 광고 및 학습하는 동작 방식이라 정의할 수 있다.

- Multi Protocol 지원 : 다양한 네트워크 환경(Ethernet, ATM, Frame-Relay, Etc)에서 동작이 가능하다.

- Label Switching : 일반 데이터에 일정 크기의 헤더를 삽입하여, 이 헤더의 일부를 필드에 저장되어 있는 값을 이용하여 데이터를 스위칭 한다.

- MPLS : 패켓을 수신한 라우터는 먼저, 최초의 목적지 IP 주소와 Label 테이블을 참조하여 Label를 추가한다. Label 정보를 확인한 라우터는 포워딩을 반복적으로 실시하며, 목적지까지 데이터가 전송되었다면 Label를 삭제한다. 이처럼, MPLS 구성망에서 데이터가 목적지까지 포워딩되는 경로는 단일 경로로 인식할 수 있다.

3. MPLS Corner : Traffic Engineering

MPLS는 Label를 사용하여, 해당 데이터를 포워딩하는 동작을 최적화를 하는 것에 초점을 맞춰, 라우터 고속화를 목적으로한 기술이었다. 현재에는 Layer 3 스위치와 Layer 3 스위칭 기반으로 하드웨어 자체적으로 IP 패켓에 대해서 고속으로 포워딩이 가능하기 때문에, MPLS가 이 문제를 맡는 것은 중요하지 않게 되었다. 현재 MPLS는 다음과 같은 역할을 가지고 동작하게 된다.

- IGP 프로토콜을 이용하여 IP Routing을 할 경우, 목적지 IP 주소를 라우팅 테이블를 참조하여 해당 경로에 대해서 Metric을 측정하여 최적의 경로를 선택한다. 만약, 해당 트래픽들이 최적의 경로를 많이 사용하게 되면, 즉 어떠한 링크에 치우치는 것에 의해서 대역폭 부족 현상이 발생될 수 있다..

- Traffic Engineering : MPLS는 명시적인 경로를 미리 선정하여 최적의 경로의 대역폭 부족 현상을 해결하는 동시에 링크 효율도 높일 수 있게 된다.

4. MPLS Corner : MPLS VPN

기존 VPN은 적지 않은 과부화의 문제점을 나타내고 있는 반면에, MPLS VPN은 기존의 VPN 보다 과부화가 적으며 최적의 상태를 유지할 수 있는 장점을 가지고 있다.

- 공유 IP/MPLS 망을 구축하여, 사용자 별로 논리적으로 분리된 VPN망을 제공한다.

- 사용자측에서는 MPLS를 인식하는 일이 없기 때문에 기존 라우터를 그대로 사용하는 것이 가능하다.

- 서로 다른 사용자들은 동일한 IP 주소를 중복하여 사용해도 문제되지 않는다.

- 별도의 추가적인 VPN 장비가 필요 없는 고성능 VPN 서비스가 가능하다.

- 투지비용 및 유지비용이 저렴하다.

5. MPLS Terms

기본적으로 MPLS를 구성할 때 사용하는 MPLS 라우터 및 용어는 다음과 같다.

- Label : 일반 패켓 헤더에 덧붙여진 추가 정보를 뜻하며, 이 헤더 이름을 ‘Shim Header’라고 정의한다. MPLS에서는 Label에 저장된 값을 이용하여 스위칭을 실시한다.

- Label Switching : 데이터 전송이 아닌 데이터에 Label를 추가하고 여기에 포함된 값을 이용하여 Layer 2 기반에서 바로 스위칭 하는 방법을 말한다. 그리고 이 스위칭은 목적지까지 가기 위한 경로를 라우팅 테이블에서 참조하지 않으며, 그대신 Label의 값을 이용하여 Layer 2 스위칭을 실시한다.

- LER(Label Edge Router) : 사용자 및 가입자 네트워크가 연결된 라우터를 뜻한다. LER는 사용자 및 가입자 네트워크에서 들어오는 일반 패켓에 Label를 추가하여 MPLS 패켓으로 전환하는 역할을 맡고 있다.

- LSR(Label Switch Router) : MPLS Provider 네트워크의 백본에 연결되어 있는 라우터를 뜻한다. LER로부터 전달받은 MPLS 패켓에서 Label 정보를 확인하여 자신의 LFIB에서 순차적으로 검사한다.

- LSP(Label Switch Path) : MPLS를 구성한 라우터와 라우터 상호간에 생기는 경로를 뜻한다. MPLS 패켓은 바로 LSP 경로를 이용하여 전송된다.

- LDP(Label Dynamic Protocol) : MPLS를 구성한 라우터와 라우터 상호간에 LSP를 동적으로 생성하는 프로토콜을 뜻한다. 또한, 설정된 회선의 대역폭 사용률에 따라 자동으로 생성할 수 있다.

6. Label

Label이란 일반 패켓 헤더에 덧붙혀진 추가 정보를 뜻하며, 이 헤더 이름을 ‘Shim Header’라고 정의한다. MPLS에서는 Label에 저장된 값을 이용하여 L2 스위칭을 실시한다.

- ‘Shim Header’는 Ethernet이나 Point-to-Point Protocol 환경에서는 기존 데이터에 덧붙이며, Frame-Relay 환경에서는 DLCI Field에 저장, ATM 환경에서는 VCI, VPI에 저장된다.

- 위의 그림을 보면, Label은 L2 Header와 L3 Header 사이에 추가되며, 크기는 4 bytes를 사용한다. 또한, L3 Header 앞에 위치하고 잇기 때문에 프로세서에 의해서 Layer 3로 올라가기 이전에 처리된다.

- 기존 Ethernet 환경의 최대 프레임 싸이즈는 1500 Byte와 Tailer(FCS) 18 Byte를 합한 1518 Byte이다. 여기에다가 Label 4 Byte를 추가하면 1522 byte으로 증가 되기 때문에 패켓은 폐기될 것이다.

- 즉, Label이 추가된 프레임은 기존의 프레임에 4 Byte ‘Shim Header’가 추가된 것으로 MTU 싸이즈에 문제가 될 수 있기 때문에, ‘Shim Header’가 추가된 패켓은 폐기될 것이다.

- 4 Byte의 ‘Shim Header’가 추가 MPLS 패켓이 폐기 되는 것을 막기 위해서는 Ethernet Header의 Field 중 상위 프로토콜에 대한 값을 저장하고 있는 Type Field(2 Bytes)에 현재 프레임이 MPLS 패켓이라는 것을 인식해야 한다.

- Ethernet Header의 Type Field값이 0x8847로 저장되면, 라우터는 해당 데이터가 MPLS 패켓으로 인식하여 패켓을 폐기하지 않는다.

7. IP Routing and Label Switching

일반적으로 Switching은 네트워크 환경에서 Layer 2 데이터인 프레임을 전송하는 기술이며, Routing은 Layer 3 기반 데이터인 패켓을 전송하는 기술을 뜻한다. MPLS에서 사용하는 Label Switching은 Routing 방식의 데이터 전송이 아닌 데이터에 Label를 추가하여 여기에 포함된 값을 이용하여 Layer 2 기반에서 바로 스위칭을 하는 고속 스위칭 방식이다.

- IP Routing 기반 환경은 패켓이 라우터에 들어오면 목적지까지 갈 때 경로 상의 모든 라우터들은 해당 패켓의 목적지에 대한 최적의 경로를 라우팅 테이블을 참조하여 전달한다. 이때, 최적의 경로를 선정하는 일은 IGP 프로토콜들이 담당하고 있으며 전송 도중 일부 구간에 과부화 및 장애가 발생되면 사용 가능한 다른 경로를 통해 목적지까지 패켓 전달을 보장한다.

- 만약, R3 구간에 장애가 발생되면 해당 패켓은 R4를 전달되며, R3 경로와 R4 경로의 메트릭이 동일하면 균등 로드분산을 실시한다.

- MPLS Switching 기반 환경은 패켓이 목적지까지 가기 위해서 경로에 있는 모든 라우터가 반복적으로 라우팅 테이블을 확인하는 대신 Label의 값을 이용하여 Layer 2 스위칭을 실시하는 방식이다.

- LER 라우터는 들어오는 패켓에 Label를 추가하는 일을 하며, LSR 라우터들은 Label이 추가된 패켓을 목적지로 전송한다. 목적지 네트워크의 LER 라우터는 패켓에 추가된 Label를 삭제한 후 일반 IP 패켓을 목적지로 전송하는 것을 보장한다.

8. LER(Label Edge Router)

LER(Label Edge Router)은 사용자 및 가입자 네트워크를 연결한 라우터이다. LER은 사용자 및 가입자 네트워크에서 들어오는 패켓에 Label를 추가하여 MPLS 패켓으로 생성한다. 패켓에 Label를 붙일 때는 FEC(Forwarding Equivalence Class)라고 하는 목적지 주소에 할당된 Label의 값을 붙인다. 위의 그림은 FEC에 따라 각각 다른 Label를 할당하고, 들어오는 패켓의 목적지 주소에 따라 해당하는 Label를 추가하는 LER의 기능을 보여주고 있다.

- LER은 수신한 패켓의 목적지 주소를 IP Header를 이용해 해석한 후, 해당 FEC에 할당되어 있는 Label 값을 패켓에 추가한다. 위의 그림을 보면, 수신한 패켓의 목적지 주소가 192.168.1.0/24인 경우 LER은 이 FEC에 할당되어 있는 113001이란 Label을 패켓에 추가하여 전달한다. FEC에 Label을 추가한 것을 ‘Binding’이라 하며, LER은 Binding한 Label을 패켓에 추가하여 MPLS 패켓으로 전환시킨다. 위의 그림 경우는 하나의 Label을 추가하고 있지만, 차후 MPLS VPN에서는 두 개의 Label를 추가한다.

- 목적지 LER은 MPLS 패켓을 수신하면 Label를 제거하여 일반 IP 패켓으로 전환시킨다. Label이 제거된 일반 IP 패켓은 라우팅 테이블을 참조하여 목적지까지 데이터 전송을 보장한다. 목적지 LER은 패켓을 라우팅하기 때문에 Label를 추가해서 전달 될 필요 없기 때문에, PHP(Penultimate Hop Popping)기능을 이용하여 자신으로 패켓을 전달하기 전에 모든 Label를 제거하고 일반 IP 패켓으로 전달하도록 자신의 바로 앞에 위치해 있는 라우터에게 광고한다.(PHP 기능 : 예약 Label 1~15 중에 Label 3을 이용하여 Implicit-Null 값을 추가한 후 바로 전 라우터에게 전달하여 Label를 제거하여 일반 IP 패켓으로 전환)

- 패켓에 Label를 추가하는 기능을 Push라 하며, Igress 라우터에서 실시하며, 패켓에 Label를 삭제하는 기능을 Pop이라 하며, Egress 라우터에서 실시한다. 또한, Label를 교환하는 기능을 Swap이라고 한다.

9. LSR(Label Switch Router)

LSR(Label Switch Router)은 MPLS Provider 네트워크의 백본에 연결되어 있는 라우터를 뜻한다. LER로부터 전달받은 MPLS 패켓에서 Label 정보를 확인하여 자신의 LFIB 테이블에서 순차적으로 검사한다. 위의 그림을 보면 LFIB는 Incoming Label, Outgoing Label, 발신 인터페이스 정보를 저장하고 있다.

- LSR의 주요 기능은 추출한 Label을 이용하여 자신의 LFIB 테이블에서 일치하는 정보를 찾아서 해당하는 Incoming Label을 Outgoing Label로 교환(Swap)하고 발신 인터페이스로 출력한다. MPLS가 Layer 2 스위칭 기반이라고 하는 이유는 LSR에서 Layer 3의 라우팅을 거치지 않고 Label의 값을 이용하여 바로 스위칭을 하기 때문이다.

- 위의 그림을 보면 LSR이 해당 Label에 대해서 Push, Pop, Swap 기능을 보여주고 있다. 처음 LER은 들어오는 패켓에 대해 목적지 FEC에 해당하는 Label을 Push하여 MPLS 패켓으로 생성하고, 이 패켓을 LSR에 전달된다. LSR은 MPLS 패켓에서 Label을 추출한 이후 자신의 LFIB에서 해당 Label과 일치하는 정보를 찾아 새로운 Label으로 Swap을 실시한다.

- 이 과정은 모든 LSR에서 공통적으로 수행되며 결과적으로 최종 목적지 LER에 이르게 된다. 목적지 LER은 Top Label를 Pop한 이후에 IP 패켓에 대해 자신의 라우팅 테이블을 참조하여 최종 목적지로 데이터를 전송한다.

- Push : 패켓에 Label를 추가하는 기능

- Pop : 패켓에 Label를 삭제하는 기능

- Swap : Label를 교환하는 기능

10. LSP(Label Switch Path)

LSP(Label Switch Path)는 MPLS에서 Ingress와 Egress 라우터 사이에 생기는 경로를 뜻하며, MPLS 패켓은 LSP 경로를 따라서 전송된다. 위의 그림은 LSP 경로를 이용하여 MPLS 패켓이 목적지 라우터까지 전송되는걸 보여주고 있다.

- IGP 테이블(라우팅 테이블)에서 최적의 경로가 바로 LSP 경로로 선출된다.

- LSP 경로 생성에서 라우터는 상대방 Egress 라우터의 도달 가능성과 최적의 경로에 대한 정보를 IGP 테이블을 참조한다.

- 경우에 따라 왼쪽 LER 라우터를 Ingress 라우터로 오른쪽 라우터를 Egress 라우터로 하는 경로와 그 반대의 경우 각각 생성되는 LSP 경로는 달라질 수 있다.

- 라우터 상호간에 생성되는 LSP를 MPLS Tunnel이라고 정의하며, 이 MPLS Tunnel은 MPLS 패켓만 전송될 수 있다.

11. LDP(Label Distribution Protocol)

Ingress 라우터와 Egress 라우터 사이에서 생성되는 LSP를 동적으로 생성할 수 있으며, 이때 LDP(Label Distribution Protocol)을 사용한다. 또한. 설정된 회선의 대역폭을 사용률에 따라 자동적으로 생성할 수 있으며, 이때, Traffic Engineering을 위한 RSVP-TE, CR-LDP라는 Signaling 프로토콜을 사용하여 회선의 대역폭을 보다 효율적으로 할당하고 관리할 수 있게 LSP를 생성한다.

- LDP는 각각의 라우터 자신들이 갖고 있는 Label 정보를 네이버 라우터와 교환하며, 서로 알고 있는 Label 정보를 확인하고, LSP 경로를 생성하는 프로토콜이다. 즉, 라우터들은 라우팅 정보를 교환하여 라우팅 테이블을 생성하듯이, 자신의 Label 정보를 교환하여 최종적으로 목적지로 가기 위한 Label 테이블을 생성한다.

- LDP는 네이버를 찾기 위해 UDP를 사용하지만, 이후 TCP 전송 프로토콜을 사용한다.(TCP Port 646)

- Discovery Message : UDP를 사용하여 Hello 메시지를 멀티케스트를 하여, LDP를 실행하고 있는 네이버 라우터를 찾는 단계이다. 라우터는 Hello 메시지에 응답한 라우터와 LDP 연결을 갖는다.

- Adjacency Message : LDP를 실행하고 있는 네이버와 LDP와 관련된 여러 가지 초기 설정을 하는 단계이다. 이 단계에서는 Label 할당 방법, Keepalive 간격, 두 라우터 간에 사용되는 Label의 범위를 정의한다.

- Label Advertisement Message : Binding된 Label에 실질적인 정보를 교환하는 단계이다.

- Notification Message : LDP의 동작과 관련된 여러 가지 에러 메시지 내용을 담고 있다. LDP가 정상적으로 동작하지 않을 때 문제의 원인을 파악할 수 있다.

1. Frame Relay Overview

▶ 프레임 릴레이는 데이터를 전송하기 위한 과정을 정의하는 ITU-T, ANSI의 표준이다.

▶ 프레임 릴레이는 Layer 2 Protocol이면서, Virtual circuit을 사용하여 연결한다.

▶ Connection-oriented Service를 제공한다.

▶ 프레임 릴레이는 라우터와 서비스 제공업체의 로컬 액세스 스위칭 장비 사이의 연결 과정을 정의한다.

▶ 프레임 릴레이는 연결 식별자들을 단일 물리 전송 링크에서 많은 논리적인 가상회선들을 통계적으로 다중화하는 수단을 제공한다.

▶ 서비스 제공업체의 스위칭 장비는 연결 식별자를 출력 포트에 맵핑하는 테이블을 만든다.

2. Frame Relay Stack

•  Frame Relay 는 Data Link Layer에서 작동한다.

•  Frame Relay 는 Multiple Upper-Layer Protocol을 지원한다.

•  OSI 스택의 상위 계층에서부터 오는 정보를 캡슐화한다.

3. Frame Relay Terminology

프레임 릴레이 용어

•  Local Access Rate : Frame Relay Cloud 연결에서의 Clock Speed 를 말한다.

•  가상회선(VC) : 두 개의 네트워크 디바이스간의 통신을 보장하기 위해서 만들어지는 논리적인 회선. 가상회선은PVC or SVC가 될 수 있다.

•  PVC(Permanent Virtual Circuit) : 영구적으로 설정되는 가상회선

•  SVC(Switched Virtual Circuit) : 요구에 의해서 동적으로 설립되고 전송이 끝날 때 해제되는 가상회선. SVC는 데이터 전송이 가끔씩 일어나는 상황에서 사용된다.

•  DLCI(Data-Link Connection Identifier) : 라우터와 프레임릴레이 스위치 사이의 논리적인 회선을 식별하는 번호이다. 프레임 릴레이 스위치는 PVC를 만들기 위해서 라우터 쌍에 DLCI를 할당한다.

•  CIR(Common Information Rate) : Frame Relay Switch의 최소 보장 Transfer Rate이다. Service provider는 CIR 값을 넘어서는 Packet Burst를 허용한다. CIR를 넘어서는 Packet Burst는 유사시에 버려 질 수 있다.

•  Oversubscription : access line speed를 넘어서 Packet을 전송되는 것을 말한다.

4. Selecting a Frame Relay Topology

•  Star topology : hub-and-spoke 설정으로도 알려져 있는 것으로 가장 일반적인 프레임 릴레이 네트워크 토폴로지이다. 원격 사이트가 중앙 사이트에 연결되어 서비스 또는 응용을 제공한다. 이것은 최소의 PVC 개수를 필요로 하기 때문에 가장 저렴한 토폴로지이다.

•  Full-mesh topology : 모든 라우터는 모든 다른 목적지에 대해서 가상 회선을 가진다. 비용은 많이 들지만, 각 사이트에서 모든 다른 사이트로의 직접 연결이 제공되어서 예비 경로를 마련해 준다. 한 링크가 다운되었을 때, 라우터는 트래픽을 다른 사이트를 통해서 우회시킬 수 있다.

•  Partial-mesh topology : 모든 사이트들이 다른 모든 사이트로 직접 액세스할 수는 없다. 네트워크 트래픽 패턴에 따라서, 많은 데이터 트래픽 요구사항을 가지는 원격 사이트로 연결되는 추가적인 PVC를 만들 수 있다.

5. Reachability Issues with Routing Updates

Frame Relay issues

- Broadcast traffic은 모든 Active connection에 복제 되어야 한다.

- 프레임 릴레이가 단일 인터페이스에서 여러 PVC를 작동시키고 있다면, 주된 문제는 Split horizon이다.

6. Resolving Reachability Issues

- Split horizon이 발생시킨 Routing update 문제해결

•  네트워크를 Full Mesh topology로 구축한다.

•  Split horizon을 disable 시키는 것은 라우팅 루프 발생 확률이 높기 때문에 권장하는 방법은 아니다.

•  브로드캐스트 라우팅을 업데이트 하기 위해서는 서브인터페이스(subinterface)라고 부르는 논리적으로 할당된 인터페이스를 라우터에 설정해야 한다.

•  Subinterface는 하나의 Physical interface를 여러 개의 Logical interface로 나눈 것다.

•  한 subinterface에서 수신된 라우팅 업데이트들은 다른 서브인터페이스로 전송될 수 있다.

7. Frame Relay Address Mapping

- Frame Relay Provider로부터 DLCI 번호를 할당 받는다.

- 라우터가 원격지에 도착하기 위해서는 각 VC에 연관된 주소를 알아야 한다.

- DLCI는 각 VC를 식별한다.

- Network Addresses를 DLCI번호와 Mapping한다.

- Inverse ARP는 local DLCI와 remote 라우터의 IP 주소와 자동으로 맵핑한다.

8. Frame Relay Signaling

- LMI(Logical Management Interface) : Frame Relay Switch(DCE)와 Router(DTE)간의 Signaling 표준으로 두 디바이스간의 상태를 유지 및 관리한다. LMI Message에는 VC의 상태를 알리는 메시지, 데이터 흐름을 확인하는 Keep Alive Message, 멀티캐스트 메커니즘 등에 대한 지원을 포함한다.

- LMI 표준 3가지 (한가지를 선택해서 수동으로 설정해 주어야 한다.)

• ansi : ANSI 표준 T1.617 에 의해 정의된다.

• q933a : ITU-T 표준

• cisco : 시스코에 의해 정의된 LMI 타입

- 라우터가 LMI 정보를 수신하게 되면, VC는 다음 중 하나로 업데이트 된다.

•  Active : 연결이 활성화 되고 라우터가 데이터를 교환할 수 있다

•  Inactive : F/R 스위치에 대한 로컬 연결은 작동 중이지만, 라우터의 연결은 작동하지 않음

•  Deleted : F/R 스위치로부터 어떤 LMI도 수신하지 못했고, 서비스도 없다는 것을 가리킴

9. Frame Relay Inverse ARP and LMI Signaling

- 1단계 : 라우터는 CSU/DSU를 통해 프레임 릴레이 스위치와 연결된다.

- 2단계 : F/R이 인터페이스에 설정되면, 라우터는 상태 질문 메시지를 F/R 스위치에 전송한다. 메시지는 스위치에 라우터의 상태를 알려주고 라우터에 라우터의 VC의 연결 상태를 물어보게 된다.

- 3단계 : 라우터는 원격 라우터에 대한 PVC의 DLCI등 상태 메시지를 스위치에게 보냄

- 4단계 : 각 활성화된 DLCI에 대해서, 각 라우터는 자기를 소개하는 IARP 패킷을 전송

- 5단계 : 라우터가 IARP 메시지를 수신할 때, 로컬 DLCI와 원격지 IP로 맵 테이블을 만든다.

- 6단계 : 매 60초마다 라우터는 모든 활성화된 DLCI를 역 ARPA 메시지에 전송한다.

- 7단계 : 매 10초마다 라우터는 스위치와 LMI 정보를 교환한다.(Keepalive) 라우터는 F/R 스위치의 응답에 기초해서 각 DLCI 상태를 바꾼다.

10. How Service Providers Map Frame Relay DLCIs : Service Provider

- 스위치는 inbound DLCI 값을 확인한다.

- 스위치는 로컬 DLCI 값과 대비되는 원격지 DLCI의 값을 확인한다.

- 스위치는 이두 DLCI 값을 F/R header에 포함해서, 적당한 switch.slot.port로 프레임을 전송한다.

11. Service Provider Frame Relay-to-ATM Interworking

•  Frame Relay-to-ATM은 Frame Relay 와 ATM네트워크의 연속성을 제공한다.

•  현재의 Frame Relay 사용자를 위해 명시적으로 개발된 두 이행 동의는 Network Interworking (FRF.5)과 Service Interworking이다. (FRF.8).

•  FRF.5는 Frame Relay가 FRF.5를 지원하는 중간의 ATM 네트워크 위로 통신하는 사용자를 허락하는 네트워크 interworking 기능성을 제공한다.

•  Multiprotocol 캡슐로 봉하기와 다른 higher-layer 과정은 ATM 네트워크 위로 투명하게 수송된다.

12. Configuring a static Frame Relay Map

• protocol : IP, IPX, Appletalk 등 지원되는 프로토콜, 브리징, 논리적 링크 제어를 정의한다.

• Protocol-address : 목적지 라우터 인터페이스의 네트워크 계층 주소를 정의한다.

• DLCI : 원격 프로토콜 주소에 연결되기 위해 사용되는 로컬 DLCI를 정의한다.

• Broadcast : VC로 브로드캐스트와 멀티캐스트를 포워딩하는 옵션이다. 이것은 VC에서 동적인 라우팅 프로토콜을 허용한다.

• ietf | Cisco : IETF 또는 Cisco 캡슐화를 enable 한다.

• payload-compress packet-by-packet : STAC 방법을 이용해서 packet-by- packet payload 압축을 enable하는 옵션이다. 이것은 Cisco 전용 압축 방법이다.

• Point-to-Point (점대점) :

- 단일 서브인터페이스가 한 PVC를 다른 물리 인터페이스 또는 원격지 라우터의 서브인터페이스에 연결하도록 한다.

- 이 경우에 인터페이스는 동일한 서브넷에 있게 되고, 각 인터페이스는 단일

DLCI를 가지게 될 것이다.

- 각 점대점 연결은 독자적인 서브넷이다.

- 라우터가 점대점이고 전용선과 같이 작동하기 때문에 브로드캐스트는 문제가 없다.

- hub and spoke topologies에 적합하다.

• Multipoint(다중 지점) :

- 단일 서브인터페이스는 여러 PVC를 원격 라우터의 여러 물리 인터페이스 또는 서브인터페이스로 연결하는 데 사용된다.

- 이 경우에는 관계되는 인터페이스는 동일한 서브넷에 있게 되고, 각 인터페이스는 독자적인 DLCI를 가지게 될 것이다.

- 이 환경에서는 서브인터페이스는 NBMA 프레임 릴레이 인터페이스처럼 행동하기 때문에 브로드캐스트 트래픽은 split horizon 규칙에 해당된다.

- partial mesh and full mesh topologies에 적합하다.

13. Configuring Point-to-Point Subinterfaces

• 1단계 : 서브인터페이스를 만들고자 하는 인터페이스를 선택하고, 인터페이스 설정모드로 들어간다.

• 2단계 : 물리 인터페이스에 할당된 네트워크 계층 주소는 삭제하고 서브인터페이스 네트워크 계층 주소를 할당하는 것을 권고한다.

• 3단계 : Frame-Relay encapsulation을 설정한다.

• 4단계 : 다음 명령어를 이용해서 설정하고자 하는 서브인터페이스를 선택한다.

Router(config)#interface serial number. Subinterface-number {multipoint|point-to-point}

- number.subinterface-number는 서브인터페이스 번호이다. 마침표 앞의 수는

물리 인터페이스 번호이고 뒤의 수는 서브인터페이스 수이다.

- multipoint : ip를 라우팅하고 동일한 모든 라우터가 서브넷에 있기를 원한다면 선택

- point-to-point : 점대점 라우터의 각 쌍이 각자의 서브넷을 이루기를 원한다면 선택

• 5단계 : 서브인터페이스를 점대점이라고 설정했다면, 물리 인터페이스와 구분하기위해서 서브인터페이스에 대한 로컬 DLCI를 설정해야 한다.

Router(config-if)#frame-relay interface-dlci dlci-number

- dlci-number : 서브인터페이스와 링크된 로컬 DLCI 번호를 정의한다. 이것은 LMI로 유도된 PVC가 서브인터페이스에 링크될 수 있는 유일한 방법이다.

1. Configuring Frame-relay Subinterfaces

Central은 Branch2 Router와 point-to-point로 연결되어 있으며, 이를 위해 Subinterface와 독립적인 IP Subnet을 설정하고 있다. Point-to-point type의 Subinterface에서는 현재 이 interface에 배정된 DLCI Number가 무엇인지를 알려 주기 위해 다음과 같은 설정이 추가되었다.Central(config-subif)#frame-relay interface-dlci 102이외에 Central은 다른 Router와 partial Mesh 연결을 위한 Multipoint type의 subinterface를 구성하고 있다. Central과 Branch3, Branch4는 Frame-relay를 이용한 Partial Mesh 구조로 연결되어 있으면서, 하나의 IP Subnet을 공유하고 있는 형태이다. 또한 Central의 설정 정보를 보면 Inverse-arp를 사용하지 않고 Frame Map을 수동으로 지정하여 PVC의 연결 구조를 다음과 같이 정의하고 있다.

Central(config)#interface Serial0/0.3 multipoint

Central(config-subif)#ip address 10.18.0.1 255.255.255.0

Central(config-subif)#no frame-relay inverse-arp

Central(config-subif)#frame-relay map ip 10.18.0.3 103 broadcast

Central(config-subif)#frame-relay map ip 10.18.0.4 104 broadcast

2. Configuring Subinterfaces Example-Branch2

Branch2 또한 Central과 동일하게 point-to-point로 연결 하기 위한 Subinterface를 설정해야 한다. 만약 Branch2가 하나의 PVC만을 연결하는 Router로 생각하고 Major Interface에 Frame-relay관련 설정을 적용하면 Multipoint와 point-to-point 사이의 연결이 구성되므로 나중에 IP Layer에서 올바른 통신 상태를 유지 할 수 없게 된다. (Framerelay의 Default Interface type이 Multipoint이다.) 반드시 Frame-relay로 연결되는 두 Router사이의 Interface type을 동일하게 하는 것이 좋다.

3. Configuring Subinterfaces Example-Branch3

Frame-relay는 Connection-Oriented라는 속성을 가지고 있다. 이 속성의 의미는 L2 Layer에서 통신이 가능 하려면 반드시 상대방 Device와 가상 회선을 연결하고 있어야 한다는 의미이다. IP 관점에서는 Central-Branch3-Branch4가 같은 IP Subnet에 연결되어 있으나, Frame-relay Partial Mesh 구조 관점에서 보면 Branch3는 Branch4와 연결된 PVC를 가지고 있지 않다. 따라서 기본적인 개념에서 보면, Branch3는 Central과는 L2 연결 관계가 있어 통신이 가능하지만, L2 연결(PVC)을 가지고 있지 않은 Branch4와의 통신을 보장 할 수 없다. 하지만 Branch3의 Frame-relay MAP을 보면 Central과 연결된 하나의 PVC에 Central과 Branch4의 IP를 Mapping하여 통신이 가능하도록 설정하고 있다. 하지만 이 방법은 Unicast 방식의 통신에서는 문제가 없으나 Branch3에서 같은 IP Subnet에 존재하는 Device들을 대상으로 하는 Broadcast나 Multicast는 Central을 통해 Branch4로 전달 되지는 않을 것이다. 만약 Branch3와Branch4사이에서 같은 IP Subnet을 대상으로 하는 Broadcast와 Multicast가 가능 하려면 그 둘 사이에 PVC가 연결되어 있어야 한다. Unicast는 Frame-relay Map의 정보를 참조하여 전달 될 수 있으나, Broadcast와 Multicast 같은 경우에는 Router를 하나 이상 건너 전달 될 수 없는 규칙이 적용됨을 유의하자. 위 그림과 같이 IP Network의 관점에서는 같은 Subnet이지만 , L2 관점에서는 Partial Mesh 구조를 갖는 구조가 앞으로 우리가 자주 직면하게 될 Topology가 될 것이다.

*.참고

Frame-relay에서 IP 통신은 반드시 Frame-relay의 DLIC Number와 IP Address사이의 Mapping 관계가 있어야 한다. 이러한 Mapping 관계가 설정되려면 Frame-relay Interface에 반드시 IP Address와 Map 정보가 설정되어 있어야 한다. 예를 들어 특정 Interface에서 Self-ping test를 하고 싶다면 다음과 같이 설정해야 할 것이다.

Router(config-if)#ip address 10.1.1.1 255.255.255.0

Router(config-if)#frame-relay map ip 10.1.1.1 102

4. Frame Relay 동작 검증

- Interface의 상태 정보를 확인 한다.

------------------------------------------------------------------------------------------------------------------------

Router#show interface serial 0

Serial0 is up, line protocol is up

Hardware is CD2430 in sync mode

MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec, rely 255/255, load 1/255

Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec)

LMI enq sent 112971, LMI stat recvd 112971, LMI upd recvd 0, DTE LMI up

LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0

LMI DLCI 1023 LMI type is CISCO frame relay DTE

FR SVC disabled, LAPF state down

------------------------------------------------------------------------------------------------------------------------

- Frame-relay PVC의 상태 정보를 확인 한다.

------------------------------------------------------------------------------------------------------------------------

Router#show frame-relay pvc 110

PVC Statistics for interface Serial0 (Frame Relay DTE)

DLCI = 110, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

input pkts 14055 output pkts 32795 in bytes 1096228

out bytes 6216155 dropped pkts 0 in FECN pkts 0

in BECN pkts 0 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 32795 out bcast bytes 6216155

------------------------------------------------------------------------------------------------------------------------

Frame-relay 연결 상태를 확인 하는 대표적인 명령어이다. Frame-relay연결은 전용선과 달리 Interface의 물리적인 연결 상태 말고도 PVC와 같은 논리 회선의 연결 상태와 기타 IP 관련Issue들을 참조해야 한다. Frame-relay Interface의 연결 상태와 동작을 확인하기 위한 순서는 다음과 과 같다.

1.Interface의 연결 상태를 확인한다.

show interface 명령어를 이용하여 물리적인 연결 상태를 확인한다.

2.PVC의 상태 정보를 확인 한다.

show frame-relay pvc [dlci number]명령어를 이용하여 다음과 같은 PVC의 상태를 확인한다.

active – 정상

inactive – 상대방 Router의 Frame-relay 관련 구성 및 연결의 문제 발생.

delete – PVC 정보의 문제

3.Frame-relay MAP 정보를 확인한다.

show frame-relay map 명령어를 이용하여 PVC의 Local DLCI Number와 IP주소 사이의 Mapping 관계를 확인한다.

- Frame-relay MAP의 상태 정보를 확인 한다.

------------------------------------------------------------------------------------------------------------------------

Router#show frame-relay map

Serial0/0 (up): ip 160.1.21.1 dlci 201(0xC9,0x3090), static,

broadcast,

CISCO, status defined, active

Serial0/1 (up): ip 150.1.23.3 dlci 213(0xD5,0x3450), static,

broadcast,

CISCO, status defined, active

Serial0/2 (up): ip 150.1.43.3 dlci 214(0xD9,0x3500), Dynamic,

broadcast,

CISCO, status defined, active

------------------------------------------------------------------------------------------------------------------------

Show Frame-relay Map을 이용하여 확인 할 수 있는 정보는 다음과 같다.

◆ Frame-relay Interface가 올바르게 설정 되었더라도, Frame-relay Interface에 IP가 설정되어 있지 않으면 Frame-relay MAP에서 아무런 정보를 확인 할 수 없다.

◆ Frame-relay Network에서는 Frame-relay MAP에 등록되지 않은 IP와는 통신 할 수 없다.

◆ Self Ping Test를 원한다면 Interface의 Local IP와 DLCI Number의 Mapping 작업이 필요하다.

◆ PVC의 상태 정보는 다음과 같은 정보를 예상 할 수 있다.

Active -> PVC의 상태가 양호 하다는 의미이다. (통신 가능)

Inactive -> 주로 상대방 Router의 설정이 잘못된 경우를 나타낸다. (통신 불능)

Delete -> Frame-relay Switch 내부에서 PVC 정보를 확인 하지 못하는 경우이다. (통신불능)

5. PPP over Frame Relay 동작 확인

1. Show interface S0.198

• 물리 interface의 연결 상태 정보를 확인 한다. PPP Over Frame-relay 연결은 기본적으로 Frame-relay 연결이 정상적으로 동작된다는 보건을 전제하고 있다.

2. Show interface virtual-template1

• PPP 연결 시 필요한 관련 정보들을 참조하는 interface의 정보를 보여준다.

• Virtual-template interface는 항상 down 상태이다. 왜냐하면 이 interface는 PPP 연결에 필요한 정보를 제공하는 용도일 뿐이기 때문이다.

3.Show interface virtual-access1

• 실제 PPP Over Frame-relay 연결의 상태를 확인한다.

• virtual-access interface는 virtual-template interface에서 정의한 정보를 기반으로 생성되는 Memory상에서 특정한 Process 형태로만 존재하는 Interface이다. 따라서 별도로 virtualaccess interface 정보를 nvram에 저장 할 수도 없다.

• virtual-access interface는 관리자가 직접 Configuration 할 수 없는 interface이다.

• 만약 PPP over Frame-relay 연결상에 특별한 정책을 작용해야 한다면 virtual-template interface을 대상으로 적용한다.

1. Frame-relay Topology에서 IP 관련 Issue

Multipoint interface는 다수의 가상회선(VC)이 연결된 형태이다. 참고로 Frame-relay가 enable된 Serial Interface의 Default Type은 Multipoint임을 알아두자. RouterA와 Multipoint로 연결된 다른 Router들은 가상회선의 연결 관점에서 보면 Star Topology처럼 보이지만, IP관점에서 보면 하나의 IP Subnet을 공유하는Network에 연결된 형태이다. 따라서 IP Network의 구조와 L2 가상회선의 연결구조가 다른 상황에서 발생하는 다음과 같은 Issue들을 고려해야 한다.

• 각 Router들 사이에서 IP 통신이 원활하게 적용 될 수 있는가?

예를 들어 RouterB와 RouterC는 같은 IP Subnet에 존재하기는 하지만, 그들 사이에 L2 연결(가상회선) 관계가 없기에 통신이 가능하지 않다. 그러나 RouterA에서 특별한 설정을 추가하면 통신이 가능하다.(나중에 배움)

• 같은 Subnet에 연결된 Router들 사이에서 Broadcast를 교환 할 수 있는가?

Broadcast는 다른 Subnet에 전파되지 않는다. IP 관점에서는 같은 Subnet이지만 RouterB에서 전송된 Broadcast를 RouterA가 RouterC나 RouterD에게 전달하지는 않을 것이다.

• Routing Protocol에 따른 Split-Horizon issue들을 해결 할 수 있는가?

RIP이나 IGRP같은 Routing Protocol들은 Routing Loop을 방지하기 위해 특정 interface에서 학습한 경로 정보를 해당 interface를 통해 다시 전송하지 않겠다는 Rule이 있다. 그로 인해 RouterA는 RouterB에서 학습한 경로 정

보를 다른 Router들에게 알려 주지 못할 것이다.

• Routing Protocol에 따른 Update 정보 교환에 문제점은 없겠는가?

Topology에 특정 IGP Routing Protocol을 실행할 때 IGP Routing Protocol에 따라 조정해야 하는 Option들을 숙달해야만 원활한 통신이 가능 할 것이다. 결론적으로 Point-to-point 또는 Full Mesh로 구성된 frame-relay Network에서는 위에서 언급한 Issue들이 문제점이 되지는 않는다. 왜냐하면 Frame-relay에 연결된 각 노드들 사이에서 L2 연결 회선이 물리적으로 보장되기 때문이다. 따라서 위 그림과 같이 Multipoint로 연결된 Partial Topology에서의 문제를 해결하기 위해서는 특별한 Frame-relay option을 조정하여 사용하던가 아니면 point-to-point 또는 Full Mesh로 변환해야 한다.

Point-to-point interface는 하나의 물리적 interface에 하나의 가상회선(VC)이 연결된 형태이다. 참고로 기본적인 Point-to-point interface의 구성을 위해서는 반드시 Subinterface 구성을 해야 한다.

Point-to-point 환경에서는 하나의 물리 interface에 특정 가상회선(VC)을 지정하고 별도의 IP Subnet을 설정하므로 위 그림에서 언급한 Issue들에 관련한 특별한문제점들을 없다.

2. Frame Relay에서 Address Mapping

Frame Relay에서 IP 통신을 해야 하는 router들은 data 전송 전에 L2 주소와 L3주소를 반드시 Mapping하고 있어야 한다. Frame Relay에 연결된 router들은 자신의 Local DLCI Number와 next-hop router의 IP 주소를 수동 또는 자동으로 mapping하며 connection 정보의 일관성을 유지하기 위해 주기적인 inverse ARP를 수행한다.

- Inverse-ARP

Frame-relay에서 자신의 Local DLCI Number와 해당 PVC에 연결된 상대방 Device의 IP주소를 자동으로 Mapping하는 작업을 담당한다.(Default)

- Frame-relay MAP

Frame-relay에서 자신의 Local DLCI Number와 해당 PVC에 연결된 상대방 Device의 IP주소를 수동으로 Mapping 하는 작업을 담당한다. 이 방식은 다수의 PVC에서 관리자가 원하는 PVC만을 선택하여 사용하고자 할 때 유용하다.

3. Frame Relay Signaling

LMI는 router와 frame relay switch사이에서 connection을 관리 하기 위한 정보와 device사이에 상태 정보를 주고 받는 데 사용하는 표준 signaling이다. LMI는 Keepalive, Multicast, status등의 mechanism들이 포함되어 있다. 다음은 router와 frame relay switch사이에서 사용되는 대표적인 표준 LMI signaling 이다. 참고로 Cisco router들은 이러한 표준 signaling에 대해 autosensing하는 기능을 가지고 있다.

Cisco – (CISCO, StrataCom, Northern Telecom, DEC)에서 사용하는 표준

Ansi – AnnexD, ANSI에서 규약한 표준

Q933a – ITU-T에서 규약 

LMI는 기본적으로 PVC의 상태 정보를 다음과 같은 내용으로 라우터에게 알려 준다.

- Active state

PVC의 상태가 정상(active)이므로 router사이에 정보 교환이 가능 하다는 의미이다.

- Inactive state

Remote router의 frame relay connection 상태에 문제가 있음을 알려 준다.

- Deleted state

Router와 frame relay switch사이에 lmi 정보를 주고 잡지 못하는 상태를 알려준다. 이것은 frame realy와 router 또는 frame relay switch사이에 connection 문제가 발생한 경우의 상태 정보이다.

4. Frame Relay Inverse ARP and LMI Signaling

다음은 Frame relay에 router를 연결 한 경우에 살펴 볼 수 있는 초기 operation 과정을 설명한 것이다.

1. frame relay network에 router를 연결 한다.

Router의 interface는 frame relay를 지원하는 encapsulation이 설정되어야 하고 IP Address가 설정 되어 있어야 한다.

2. Frame relay configuration이 적용된 interface가 enable되면 router는 인접한 frame relay switch에게 PVC의 상태 정보를 문의(Status inquiry) 한다.

3. Frame relay switch가 router의 status inquiry message를 수신하면 PVC의 Local DLCI number와 상태 정보를 router에게 알려 준다.

4. 각 router들이 PVC의 active한 상태 정보를 수신하게 되면 자신의 Local DLCI number와 상대 router의 IP Address 정보를 mapping하기 위해 inverse ARP를 수행한다. 각 router는 자신의 IP 정보를 소개한다.

5. inverse ARP를 통해 상대 router의 ip Address정보를 획득하면 Frame relay map을 작성 한다. 만약 동적인 frame relay map을 작성 할 수 없는 상황에서는 관리자가 직접 수동으로 frame relay map을 작성 할 수도 있다.

6. 이후 매 60초마다 router들은 자신이 알고 있는 모든 active DLCI 정보를 확인 하기 위해 inverse ARP를 수행한다. 또한 매 10초마다 router와 frame relay switch사이에서 LMI 정보를 주고 받으며 PVC의 상태 정보를 확인 한다.( Keepalive )

5. Configuring Basic Frame Relay

Frame Relay network에 router를 연결하기 위한 구성 다음과 같다.

1.frame relay에 연결되는 라우터의 interface configuration mode로 진입 한다. 물론 interface는 frame relay에 연결된 interface여야 한다.

Router(config)# interface serial 0Router(config-if)#

2. Frame-relay Encapsulation type을 지정 한다.

Router(config-if)# encapsulation frame-relay [ cisco | ietf ]Frame relay의 encapsulation은

Cisco type과 ietf의 format이 다르다. Default는 cisco이다.

3. Frame-relay lmi-type 구성 IOS 11.2 이후에 버전들은 LMI-Type에 대해 autosense 기능을 제공하므로 특별한 Signal을 요구하지 않는 한 설정하지 않아도 된다.

4. bandwidth를 설정 한다. Frame Relay interface에서 설정하는 bandwidth는 frame relay network에서 적용되는 전송속도(CIR)를 지정한다.

Router(config-if)# bandwidth 64

5. 만약 inverse ARP가 disable되었다면 다음과 같은 command를 실행한다. 하지만 기본적으로 inverse ARP는 default로 enable되어 있다.

Router(config-if) frame-relay inverse-arp [protocol] [dlci]

- Protocol – router가 frame relay상 에서 지원하는 protocol을 선택 한다.

- dlci – inverse ARP message가 수행되는 local dlci number이다.

6. 만약 inverse ARP를 사용할 수 없는 상황이라면 다음과 같이 frame relay map을 구성한다.

예) frame-relay map ip 10.16.0.2 110 broadcast

broadcast option을 설정하지 않으면 해당 PVC에서 broadcast/multicast 교환을 하지 않는다. 만약 PVC구간에서 Routing 정보를 교환해야 한다면, 이 option을 반드시 설정해줘야 한다.

6. Frame Relay Sub-interface Type

Interface에 가상 회선이 연결되는 형식에 따라 Multipoint 또는 point-to-point방식이 있다.

- Multipoint

하나의 물리 Interface에 다수의 가상회선이 연결되는 것을 말한다. 이러한 형태의 interface는 Full Mesh 또는 Partial Mesh Network에서 사용한다. Multipoint에 연결된 가상회선들은 같은 subnet 을 공유하므로 IP관련

Issuee들을 주의해야 한다.

- Point-to-point

하나의 물리 interface에 하나의 가상회선으로만 Mapping하여 사용하는 방식이다. 주로 Star Topology에서 사용한다.

1. Frame Relay 개요

Frame Relay 이전에 packet switching network에서 가장 많이 사용되었던 기술은 X.25였다. 기존의 X.25에서는 가상회선 관리와 오류 제어 등이 3계층에서 처리되었기 때문에 Packet의 전달 과정에 발생하는 delay를 감수해야 했으나 x.25가 사용되던 당시에는 host system과 remote에 있는 단말기 사이에서의 통신을 주로 행하던 시기였으므로 x.25에서 감당해야 하는 traffic의 양이 많지 않아 큰 문제로 대두되지는 않았었다. 하지만 Network의 규모가 커지면서 다양한 작업 성격의 Traffic을 처리해야 하는 시점에서는 packet 전달의 overhead를 가지고 있는 x.25의 packet switching에는 한계가 있었다. 또한 과거보다 더 발전된 WAN의 물리적인 선로들로 인해 데이터의 고속 전송과 안정성이 확보되면서 Packet switching network에서 데이터의 전송 신뢰성을 위한 순서 제어나 저장 후

전송, 에러 복구 등의 처리 절차 등이 오히려 부담되는 요소들이 되었다. Frame Relay는 안정된 network을 기반으로 X.25가 가지고 있었던 그러한 overhead를 제거하여 만든 protocol이며 기존의 X.25의 패킷 전송 기술을 고속 데이터 통신에 적합하도록 개선한 방식이라고 이해하면 좋을 것이다.

Frame Relay는 하나의 회선에 여러 경로들을 논리적인 channel로 나누어 전송 할 수 있는 특징을 가지고 있으며 각각의 논리적인 channel을 ‘가상 회선’이라는 개념을 사용하여 구별하고 있다. 또한 이러한 가상 회선은 frame relay를 사용하는 가입자들에게는 전용선처럼 취급되어 제공된다.

2. Frame Relay Protocol Stack

Frame-Relay의 전송 서비스는 L2 Layer (프레임 모드 전달 서비스)에서 제공되며, Frame Relay Hearder에는 아래와 같은 정보들이 표현 될 수 있다.

1)Flag

 SDLC의 Flag 와 그 기능 은 같다.

2)Address 

이 Address는 Frame Relay의 이용자 Address를 표현하며 Data link connection identifier (DLCI)로소 언급되어 진다. DLCI(data link connection identifier)는 하나의 물리적 포트를 논리적으로 분할한 사용자 주소이다

3)Command/Response identifier bit(CR) 

비트는 Frame Relay Protocol에 의하여 사용되어 지지는 않으나 부가된 이용자들에 의하여 사용되어 질 수 있으며, Frame Relay이 망을 통하여 투명하게 전달된다. 종단 사용자간의 상위 프로토콜 계층에서 이 프레임이 명령 프레임인지 응답 프레임인지를 나타내기 위하여 사용된다. SVC로 사용하지 않으면 C/R은 필요 없다.

4)Extended address bits(EA)

10 비트 이상의 어드레스를 지원하기 위하여 Header field를 확장 시킬 수 있다. EA 비트는 현재 Octet이 전체 헤더 필드에서 마지막인지 아닌지를 가리킨다. 따라서 두 Octet 헤더에 대하여 EA 비트는 첫번째 Octet에서 0으로 설정되며, 두번째 Octet 에서 1로 설정한다. EA=0 : 주소 필드가 더 있음을 나타낸다. EA=1 : 주소 필드의 끝을 나타낸다.

5)Forward explicit congestion notification bit(FECN)

이 비트는 congestion 을 순방향의 이용자에게 알리기 위하여 망에 의하여 설정된다. 전방향 폭주 통지 비트라고 하며 망측에서 사용자에게 프레임의 진행 방향에 폭주가 있음을 알림으로써 사용자로 하여금 적절한 조치를 취할 수 있게 한다.

6)Backward explicit congestion nification bit (BECN)

이 비트는 congestion을 역방향의 이용자에게 알리기 위하여 망에 의하여 설정된다. 후 방향 폭주 통지 비트 라고 하며 망측에서 사용자에게 프레임의 진행 반대 방향에 폭주가 있을 가능성을 알림으로서 사용자로 하여금 적절한 조치를 취할 수 있게 한다.

7)Discard eligibility bit(DE)

이 비트는 congestion 상황과 관련되며 그 프레임을 처분하고 다른 프레임의 언급을 가리킨다. 이 비트는 망 또는이용자에 의하여 설정되어진다. 페기 허용 비트 라고 하며 망 폭주시에 다른 프레임에 우선하여 폐기되어 망의 폭주 관리에 유용하다. 속도가 CIR 초과된 프레임의 경우 DE=1로 세트되어 보내지며 폭주시 우선적으로 페기하고 송신측에 FECN을 보낸다

8) Information field

이 필드에 대한 최대값은 망에 종속되어 질것이나 프레임 릴레이 포럼은 최대1600 Octet 크기로 권고된다.

9)FCS

다항식 ( X + X + X + 1) 을 포함하는 두 Octet 필드를 포함한다.

3. Frame Relay 관련 기본 용어

다음은 Frame-relay와 관련된 용어이다.

- Local access rate

Frame Relay network에 접속하는 구간의 clock speed를 의미하는 용어이다. 즉 가입자의 router에서 WAN 사업자 의 Frame Relay Switch간에 접속 구간에 설정된 속도를 의미하는 것이다. 일반적으로 Frame Relay를 이용하여 데이터를 전송하는 경우에는 Frame Relay switched Network 내부에서 제공되는 전송 속도를 실제 전송 속도로 사용한다.

- Virtual circuit (VC)

Frame Relay를 통해 통신하는 두 device를 위해 Frame Relay network 내부에 논리적으로 들어 놓은 경로를 의미 한다. Packet switching Network은 사업자가 구축한 물리적인 network을 가입자들에 의해 공유 되는 특징으로 인해 Frame Relay switching network 안에서 각 가입자들의 통신 경로를 논리적인 channel들로 구분하고 있다.

- SVC (Switched Virtual Circuit)

두 노드 사이의 논리적인 경로가 고정되어 있지 않고 특정 노드들이 packet switching network에 연결 할 때마다 매번 별도의 논리적인 경로가 제공되는 가상 회선이다.

- PVC (Permanent Virtual Circuit)

두 모드 사이에 논리적인 경로가 고정되어 있는 가상 회선이다. 따라서 가입자마다 고유한 가상 회선 식별 번호가 제공된다. Frame Relay에서 주로 사용 하는 가상 회선의 서비스형태이며 최소 down 상태를 유지 한다.

- DLCI (Data link Connection identifier)

FR망에 서 각 PVC들을 구별하기 위한 식별 주소 – L2 주소의 개념으로 사용된다.

- LMI (Local Management Interface)

FR Switch와 Router사이에서 PVC의 상태 정보를 교환하기 위해 사용하는 Signal.

- FECN (Forward Explicit Congestion Notification)

FR망에서 폭주가 발생하면 Data를 수신 하는 Node에게 상황을 알려준다.

- BECN (Backward Explicit Congestion Notification)

FR망에서 폭주가 발생하면 Data를 송신 하는 Node의 전송률을 낮추게 한다.

- DE (Discard Eligibility)

FR망에서 폭주가 발생되면 가장 우선적으로 Drop되어야 하는 Frame에 설정한다.

- Frame-relay Inverse-arp

FR망에서 DLCI Number와 상위 Protocol 주소와의 Mapping을 위해 사용.

- Frame-relay map Table

DLCI Number와 상위 Protocol 주소와의 Mapping 관계를 관리하는 Table.

- Data-link connection identifier (DLCI)

일반적으로 DLCI number라고 한다. 이는 frame relay switch 네트워크에 만들어진 가상 회선들을 구별하기 위한 용도로 사용되며 만약 하나의 PVC에서 두 라우터가 통신한다면 가상 회선에서 각 라우터를 식별 할 수 있는 DLCI 번호가 배정될 것이다.

- CIR (Committed information rate)

Frame Relay switch가 허용하는 전송 속도를 의미하는데 좀더 구치적으로 표현한다면 CIR은 하나의 PVC에서 보장 할 수 있는 최소 bandwidth를 의미한다. 가입자는 Frame Relay Switching network을 통해 전송 할 수 있는 대역폭을 비용에 따라 다르게 전송 할 수 있으며 실제로 WAN에서 제공하는 실제 전송 속도를 CIR로 결정한다.

- inverse ARP (Address Resolution Protocol)

Frame Relay Network의 PVC상에서 라우터들은 자신의 local DLCI number와 상대 router의 IP를 자동으로 mapping 하는 작업을 수행하게 되는데 이를 inverse ARP라고 한다. 경우에 따라서는 수동Mapping도 가능하다.

- Local Management Interface (LMI)

LMI는 router와 frame relay switch사이에서 PVC의 상태 정보를 주고 받을 때 사용하는 표준 Protocol이다. Router는 frame relay network내부에 PVC의 상태 정보를 스스로가 직접적으로 인식 할 수 없기 때문에 항상 인접한 frame switch와 PVC의 상태 정보를 주기적으로 문의하여 가상 회선의 이상유무를 check 할 수 있다.

- Forward Explicit Congestion Notification (FECN)

Frame Relay Switch는 자신이 속한 network의 폭주 상태를 check 할 수 있으며 이러한 정보들을 router에게 알려주어 flow control을 할 수 있도록 한다. FECN은 Packet 도착지 router로 향하는 데이터 진행 방향의 폭주 상태를 알려 준다.

- Backward Explicit Congestion Notification (BECN)

BECN은 데이터 진행 방향의 반대 방향에서 폭주 상태가 있음을 알려 준다.

4. Frame Relay Topology

Frame-relay 다수의 사용자들이 물리적인 Network을 공유하지만, 실제로는 논리적인 가상회선으로 인해 구별되어 진다. 이것은 우리가 Ethernet switch에 연결된 Node들을 VLAN으로 나누는 작업과 같은 개념이다. 따라서 Frame-relay 사용자들은 다른 사용자들과 Network을 물리적으로 공유하고 있는지를 알 수가 없으며 오직 자신들에게 배정된 가상 회에 연결된 대상과 전용선을 사용하듯 통신 할 뿐이다. Frame-relay망에서 제공하는 가상회선은 Frame-relay Network에 연결된 가입자들이 자신들의 논리적인 Network 구축을 가능하게 한다. 가상 회선은 하나의 물리 Interface에서 다수가 연결 될 수 있으므로 별도의 물리적 회선과 serial interface의 추가 없이도 위 그림과 같은 Topology들을 구현 할 수 있다. 물론 추가되는 가상 회선당 사용료를 지불해야 한다. 가상회선은(VC) 개념은 WAN에서 L2 VPN을 지원 할 수 있는 능력을 제공한다. 따라서 가상 회선으로 연결된 L2 Network과 L3 Network의 구조가 달라 질 수 있다는 의미이다. Frame relay network을 기반으로 하는 router들은 하나의 물리적인 interface에 하나 이상의 PVC를 연결되는 경우가 많다. 따라서 Router는 하나의 물리적인 interface를 논리적인 interface로 나눠야 하는 경우가 발생하며 Router는 다음과 같은 대표적인 frame-relay topology중 하나에 속해 있다.

- Star Topology

hub and spoke topology라고도 하며 frame relay network에서 가장 흔하게 볼 수 있는 topology이다. 이러한 topology에서는 remote router들의 PVC들이 중앙의 router에 모두 연결되는 구조 이며 중앙에 router는 하나의 물리적인 interface에서 다수의 PVC를 연결 하는 상황이 되므로 중앙 라우터의 수행 능력이 좋아야 한다.

- Full-mesh topology

frame relay network에 연결된 모든 router들이 PVC로 연결 되어진 topology를 의미한다. 이러한 구조는 router들 사이의 연결이 이중화 되어 있는 관계로 redundancy 기능을 제공 할 수 있어 전체 network의 안정성을 제공 할 수는 있으나 PVC의 수만큼 비용이 추가되는 단점이 있다.

- Partial mesh

이 topology는 star topology와 mesh-topology가 혼합된 형태이다. 예를 들어 star topology를 사용하는 network에서 특정 router의 traffic을 분산 시키기 위해 새로운 PVC를 추가하여 새로운 router간의 경로를 만들 수도 있다.

이때 새로운 PVC가 추가되는 구간에 mesh topology가 만들어 지게 된다. Frame relay는 다른 용어로 NBMA(Non Broadcast Multiple Access) network이라고 한다. 이 의미는 Frame relay는 public network의 특성을 가지고 있기 때문에 여러 노드에 의해 공유되는 Network이다. 이는 매체를 공유하는 Ethernet network과 비슷하다고 볼 수 있다. Ethetnet network은 회선을 모든 노드들이 공유함과 동시에 특정 노드의 전송 신호에 모두가 귀를 기울이는broadcast network BMA(Broadcast Multiple Access) network이라고 한다. 하지만 frame relay는 공유망이라 할지라도 특정 노드들의 데이터 전송 신호가 다른 노드에 전달되지 않으며 각 노드들은 논리적인 가상회선을 통해 개개의 통신 경로를 가지고 있으므로 NBMA network이라 한다.

1. IOS Device에서 Interface 식별

IOS Device들 중에는 고정된 형식의 interface들과 Module 형식의 interface들이 있는데 근래에는 Module 형식의 IOS Device들이 주류이며, 실제 CCIE Lab에서 사용되어 지는 장치들 모두가 Module 형식의 장비이다. IOS Device에서 interface를 구성하는 작업은 실제 장비의 역할을 정의하는데 있어서 기본적이면서도 중요한 작업 단계이다. 또한 장비 구성의 많은 설정들이 interface에서 적용될 것이다. 비록 IOS Device들이 다양한 종류의 interface들을 지원하겠지만, 실제 우리가 상대하는 interface는 ethernet, serial, bri, atm 정도가 되겠으며, 이들 interface에 따른 L2 Protocol의 특징에 따라 설정되는 방법의 차이가 있을 뿐이다.

다음은 IOS Device에서 interface에 설정하는 일반적인 작업 단계들이다.

1.설정 대상이 되는 interface를 정확히 구별해야 한다. (port number 또는 IOS Device의 Slot, Module, port Number 순으로 식별한다.)

2.L2 주소와 속성을 정의 한다.

3.L3 주소와 속성을 정의한다.

4.L2 주소와 L3 주소 사이의 Mapping관계를 정의한다.

5.기타 option 정의(Routing, QOS, Security등) 위 작업 단계는 interface가 사용하는 L2 Protocol의 특성이 무엇이냐에 따라 반드시설정해 줘야 하는 Parameter (Manual 설정)들과 그렇지 않은 Parameter (Auto 설정)들이 있을 수 있다. 나중에 이 교재에서 소개하는 많은 예제와 실습을 통해 배우게 되겠지만 위의 interface 설정 단계들은 반드시 필요한 부분이며, 다만 그러한 설정들이 해당 interface에서 사용하는 L2 Protocol의 특성에 따라 , 또는 사용자의 선택에 따라 달라 진다는 것을 확인 할 것이다.

2. IOS Device의 Interface 설정

-------------------------------------------------------------------------------------------------------------------------

- 2-계층 Protocol 설정 하기

Router(config)#interface serial 0

Router(config-if)encapsulation ppp

- L3 Address 설정 하기

Router(config)#interface serial 0

Router(config-lf)ip address 10.1.1.1 255.255.255.0

- Bandwidth 설정 하기

Router(config)#interface serial 0

Router(config-lf)bandwidth 64

- Clock 설정 하기 (DCE Interface 설정)

Router(config)#interface serial 0

Router(config-lf)clock rate 64000

- Interface active 하기

Router(config)#interface serial 0

Router(config-lf)no shutdown

-------------------------------------------------------------------------------------------------------------------------

위 예제는 interface를 설정하는 기본적이고 공통적인 Option들을 보여 주고 있다.

• Interface에서 사용될 L2 Protocol (Encapsulation Type)을 정의한다. Interface의 종류에 따라 정의되는 L2 Protocol이 다르다. 특히 Serial interface는 PPP, HDLC,Frame-relay와 같은 L2 protocol을 사용하며, 그것들에 따른 option 설정들이 구성된다. Ethernet과 같은 경우에는 대부분 ARPA(Ethernet_II) type을 사용하므로 특별 encapsulation 형식을 선언해 주지 않아도 된다. 하지만 Ethernet Switch와 Trunk 연결을 하는 경우에는 ISL이나, dot1q와 같은 특별한 encapsulation 장식을 선언해야 한다.

• L3 주소를 정의한다. 일반적으로 대부분의 Network device들이 IP Network에 연결되어 있으므로 해당 interface에 IP Address를 정의한다.

• Bandwidth를 설정한다. Interface에 정의된 bandwidth는 실제 interface에 연결된 회선의 물리적인 속도와는 아무런 관련도, 영향도 없다. 다만 이 설정은 Routing Protocol의 path selection 작업과정에서 참조되는 Metric값으로 계산되므로 Network Topology를 참조 하여 주의 깊게 설정해야 한다.

• Clock을 설정한다.실제 환경에서는 회선을 제공하는 Service Provider가 clock을 책임지므로 clock을 설정 할 필요는 없다. 하지만 내부 실습 환경에서는 Clock을 책임 져야 하는 DCE 역할을 수행하는장비가 필요하다. 따라서 Clock을 책임지는 장비 쪽에서 이 설정을 구성하면 된다.

• Interface를 active 한다. 기본적으로 최초로 router를 설정하거나 부팅 하고 나면 모든 interface들이 기본적으로 shutdown된 것을 확인 할 수 있다. 이러한 interface들을 활성화 하기 위해 no shutdown 명령어를 실행한다. 또한 경우에 따라서는 interface를 reset해야 하는 상황에도 이 명령어를 실행한다.

3. Interface 상태 정보 검증

Interface상태 정보는 크게 두 가지 정보로 나눠 판단하는데, 첫 번째는 물리적인 연결 상태 정보인데 이것은 실제 회선의 전기적인 신호(Carrier)가 올바르게 교환되는지, 물리적인 connection 연결은 올바르게 설정 되었는지를 알 수 있다. 이 연결 상태가 올바르게 연결되어 있지 않다면 올바른 L2 연결 상태를 기대할 수 없을 것이다.

예) Serial is up  물리적 회선의 연결 상태

line protocol is up => L2 연결 상태

두 번째는 L2 레벨의 연결 상태이다. 이는 앞에서 이야기 했던 물리적인 연결 상태에 문제가 없는 상황에서만 의미 있는 정보이다. 이 연결 상태가 down으로 표시되면, 대부분 물리적인 연결 상태의 문제 보다는 구성 정보가 잘못 설정된 원인이 대부분이다.

예를 들어 다음과 같은 설정들이 불일치 할 때 문제가 발생한다.

- Encapsulation type

- 잘못된 인증 정보 설정 (PPP인증 option)

- DCE 장비에서 Clock Rate이 설정 되지 않은 경우

- 기타 L2 Options

위 두 가지 설정에 문제가 없더라도 통신이 되지 않는 경우가 있을 수 있다. 예를 들어 IP Address가 잘못 설정된 경우이다. 즉 L2 이상에 설정들이 잘못된 경우라면 위의 두 가지 정보만으로는 문제를 해결하지 못한다. 따라서 위 그림의 예제는 interface의 기본적이면서 중요한 연결 관계, 즉 L1과 L2상의 연결관계를 확인 할 때 사용된다.

4. Loopback Interface

Loopback interface는 일반적으로 관리용 또는 Router가 물리적으로 가지고 있지 않는 가상의 Network (interface)를 생성하는 경우에 자주 사용된다. 나중에 배우겠지만 loopback interface는 IGP Routing 환경에서 Router를 구별하기 위한 식별자로 사용되는데 이와 관련된 중요한 issue들이 소개될 것이다.

5. CDP 상태 정보 검증

CDP는 Cisco 전용 protocol로서 장비의 물리적인 연결 상태를 확인하는데 유용하다. CDP는 직접적으로 연결되어 있는 장비의 연결 상태만을 확인 할 수있으므로 한 장비에서 전체적인 장비의 연결 상태를 확인 하는 데는 한계가있다. CDP는 일부 서비스를 수행하는 장비에서 제공되지 않을 수도 있다. 예를 들어 Frame-relay switch 역할을 수행하는 router나 BRI interface처럼 Dialup 회선과 같은 구간에서는 이를 허용하지 않는다. 따라서 Frame-relay에 연결된 Router들 사이에서는 CDP를 이용하여 물리적인 연결 구조를 알 수 없으며, Dialup 구간에서는 CDP로 인한 주기적인 전화 걸기 동작을 방지하기 위해 CDP를 Disable 한다.Show cdp neighbor detail 명령어를 사용하면 위 그림에서 보이는 정보 외에 연결된 Device의 IP 정보들을 확인 할 수 있다.

6. Telnet Session 관리

- Telnet session 전환 key

-------------------------------------------------------------------------------------------------------

R1# <Ctrl-Shift-6>x

R1#sh session

Conn Host Address Byte Idle Conn Name

1 10.1.1.2 10.1.1.2 0 1

10.1.1.2

R1# resume 1

R1

-------------------------------------------------------------------------------------------------------

- Telnet Session 종료

-------------------------------------------------------------------------------------------------------

R1#disconnect

Closing connection to 10.3.3.2 [confirm]

R1#clear line 11

[confirm]

[OK]

-------------------------------------------------------------------------------------------------------

어떤 IOS Device에서 특정 Device로 Telnet 연결 후, 현재 연결된 telnet session을 끊지 않고 session을 전환하는 방법이 있다. 위 예제에서는 R1의 관리자가 R2로 telnet으로 연결 하고 다시 R1으로 Session을 복위하기 위해 <Ctrl + Shift +6>Key를 누른 후 ‘X’ key를 누른다. 그리고 현재 R1에서 연결한 telnet session의 정보를 확인 하기 위해서 show session 명령어를 실행하면 이전에 R2로 연결된 telnet session의 정보를 확인 할 수 있고, 필요하면 R2와의 session으로 다시 복귀가 가능하다.만약 이전에 연결된 session 정보를 제거하기 위해 disconnect 또는 Clear line

command를 사용한다.

6. Alias exec Command

Alias exec는 자주 사용되는 특정 IOS Command를 사용자가 지정하는 단축명령어로 정의하여 사용 할 때 유용하다. 예를 들어 alias exec i show ip rotue 를 설정했다면 이 후 콘솔에서 ‘i’만 실행하면 라우팅 테이블을 보여 주는 show ip route 명령어가 자동 실행된다. 이 명령어는 특정 장치에서 동일한 명령어를 반복해야 하는 사용자에게 편

의를 제공한다.

7. Configuration Register

Configuration register의 특징은 다음과 같다.

• Router 부팅 시에 IOS를 참조하는 방법과 기타 시스템 관련 Option들을 설정 정보들을 내장하고 있다.

• 16bit로 구성되어 16진수로 표현되는 값이다.

• 각 bit는 IOS Device의 시스템과 관련된 option들의 의미와 설정 값을 나타낸다.

• Nvram에 저장되며, 부팅 시 참조된다.

• 사용자가 특정한 용도에 맞도록 수정 할 수 도 있다.

• 기본값은 0x2102이다.

• 각 bit값의 의미를 모른 상태에서 임의로 값을 변경하지 말아야 한다.

Nvram에 저장되어 있는 Configuration register값은 각각의 의미를 지닌16bit로 구성되어 있고 16진수로 표현 된다. 예를 들어 router의 default configuration register값인0x2102 를 이진수로 변환하면 다음과 같은 값들이

표현된다. 예를 들어 위 그림의 표에서 6번 bit가 ‘1’로 설정되면 부팅 시 nvram을 참조하지 말라는 의미로 사용된다. 즉 부팅 시에 configuration 정보를 참조하지말고 초기 상태로 부팅하라는 의미이다. 이 값은 password recovery를 수행하는 경우에 변경되는 값이기도 한다. 이 중에 부팅 시에 가장 중요하게 참조되는 부분은 바로 boot field이다. boot field에서 표현하는 정보는 IOS Image의 참조 위치를 알려주는 정보이

며 다음과 같은 정보를 제공하고 있다.

Boot                                 Field Meaning

-------------------------------------------------------------------------------------------------------------------------

0x0 (0000)                         Stays at the system bootstrap prompt

0x1 (0001)                         Boots system image on EPROM

0x2-F (0010 ~ )                  Specifies a default netboot filename Enables boot

    system commands that override default netboot filename

Boot field의 Default값은 0x2(0010)이다. 이는 IOS Device가 부팅 시에 기본적으로 flash memory에서 IOS Image를 참조한다는 의미이다.