NetWorkers

Frame-relay에서 자기 인터페이스로 핑('자핑'이라고도 한다)을 쏘면, 응답을 받을 수 없다 ?!
( 프레임릴레이 )


Ethernet (이더넷) 은 어떤가?

핑을 쏘자마자 거의 동시에 답변을 받을 수 있다.
그러나 Ethernet에서는 실제로 ICMP가 encapsulation되서 NIC 외부로 나가는 것이 아니다.
이게 무슨 말인지 알아보자.

Ethernet 은, Broadcast 환경을 지원한다.
모르는게 있으면 '모두 다 들어봐'는 브로드케스트를 날릴 수 있음을 의미한다.
(ex. ARP)
이때 다른 장비들과의 충돌을 감지할 수 있게 Loopback이 존재한다.

자신이 내보내는 데이터를 그대로 복사해두고, input 데이터를 비교해서 방금 자신이 내보낸
Data에 어떤 변경이 있는지 확인함으로써 충돌이 있었는지 감지하는 것이다.

Ethernet 에서 핑을 쏘면 바로 이 Loop를 통해 핑을 받게 된다.
Ethernet 에 있어서 자핑은 연결된 Link의 안전성을 판가름 하는 기준이 아니라,
장비 내부에서 Ethernet 인터페이스가 이상이 없는지만 체크해 줄 뿐이다.

ping data를 어떤 값으로 정해줘도, 40byte짜리 000000000000000~~~~ 값이 Loop를 통해
검증될 뿐이다.

그렇다면, Frame-relay는 왜 안되는 것인가 ?!

Ethernet 환경에서 주로 자기(own) 인터페이스의 응답을 받는 것이 익숙해져서,
Serial. 그것도 Frame-relay에서 응답을 받지 못하는 것이 의아할 지도 모른다.

Frame-relay는 NBMA 환경이다.
NB, 즉, Non-Broadcast 이다.
자신이 모른다고 해서 '다들어 봐'라고 다른 장비들을 부를 수 없다는 것이다.

그런데 MA, Multiple Access이다.
하나의 링크를 통해 여러 장비와 통신이 가능하다.
또 하나의 특징이 있다면, 매핑이 필요하다는 것이다.
(이에 대한 자세한 내용은 생략하도록 한다.)

핑을 쏘기 위해서 프레임 릴레이는 자신의 Frame-relay Mapping 정보를 찾아보게 되는데,
이때 자신의 인터페이스 ip가 맵핑되어 있지않다면 encapsulation failed 가 일어나게 된다.

Frame-relay는 무조건 맵핑 정보가 필요하기 때문에, 자기 인터페이스라고 하더라도,
맵핑 정보가 없다면 핑이 안된다.

왜 그럴까?

MA 환경을 지원하기 때문에, 하나의 링크에서 다수의 장비와 통신이 가능하다.
서브인터페이스를 만들 수도 있다.
당연히 unicast하게 통신하는 것은 보장된다.
하지만, NB(Non-Broadcast) 이기 때문에 자신이 모르는 네트워크를 호출할 수 있는 방법이 없다.
'명백한' 매핑정보가 없으면, 절대 보낼 수 없는 것이다.


아래와 같은 네트워크가 있다고 하자.

라우터1 Serial1/1                               라우터2 Serial1/1
(1.1.1.1) ---------------------------- (1.1.1.2)


R1의 DLCI는 102, R2의 DLCI는 201 이다.
서로를 맵핑 시켜주기 위해 R1과 R2에는 다음과 같이 매핑이 되어 있을 것이다.

R1 : frame-relay map ip 1.1.1.2 102   -> 1.1.1.2로 가려면 DLCI 값 102를 달고나가라.
R2 : frame-relay map ip 1.1.1.1 201   -> 1.1.1.1로 가려면 DLCI 값 201를 달고나가라.

서로 반대편 라우터에게 핑을 쏘면 당연히 ICMP reply (핑의 응답) 를 받을 수 있다.
ex. R1 에서 R2로 핑.


R1#p 1.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!


그러나 자핑은 안될 것이다.

R1#p 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....

debug ip packet을 하면 다음과 같은 에러메시지를 볼 수 있다.
*Feb 24 17:34:37.547: IP: s=1.1.1.1 (local), d=1.1.1.1 (Serial1/1), len 100, sending
*Feb 24 17:34:37.551: IP: s=1.1.1.1 (local), d=1.1.1.1 (Serial1/1), len 100, encapsulation failed

(재미있는 메시지이다. source와 destination이 동일하다.)
그보다 주목할 것은 encapsulation failed이다.

1.1.1.1로 가는 DLCI를 찾지 못했기 때문에 패킷을 encapsulation하지 못했다고 투정부리는 것이다.
자, 그럼 넣어주자.


R1 : frame-relay map ip 1.1.1.1 102   -> 1.1.1.1로 가려면 DLCI 값 102를 달고나가라.

이제 핑해보자.
*Feb 24 17:39:23.967: IP: tableid=0, s=1.1.1.1 (local), d=1.1.1.1 (Serial1/1), routed via RIB
라는 디버그 메시지와 함께 반가운 마침표를 볼 수 있다.

Serial1/1을 통해 패킷을 전송했다는 것이다.
어떻게 된 것일까.



1. 첫번째 단계

R1은 자신의 Frame-relay Mapping 테이블을 보고, 1.1.1.1을 뒤져보니, Serial1/1을 통해
DLCI 102 를 달고 나가라는 것을 확인했다.
그래서 ICMP request 패킷을 Frame-relay로 잘 encapsulation해서 Serial1/1로 내보낸다.


2. 두번째 단계

R2는 R1으로부터 패킷을 받았다.
사람이 보기엔 source와 destination이 동일한 우스꽝스러운 패킷이지만,
라우터는 destination만 보기 때문에 전혀 문제가 없다.

R2는 자신의 Frame-relay Mapping 테이블을 뒤져서
1.1.1.1 가기 위해 Serial1/1을 통해 DLCI  201을 달고 나가라는 것을 확인했다.
그래서 ICMP request 패킷을 Frame-relay로 잘 encapsulation해서 Serial1/1로 내보낸다.


3. 세번째 단계

R1은 방금 R2가 보낸 패킷을 보니, 자기 Interface 주소를 향한 ICMP request 였다.
그래서 여기에 대한 응답을 보내려고 한다.
request에 대한 reply는 당연히 보낸 라우터, 즉, 소스에게 보내줘야 한다.
ICMP request의 source 주소를 보니 1.1.1.1이다. - _-;;

R1은 source와 destination 주소를 바꾼다.
사실, 사람의 눈에는 둘다 같은 주소 (1.1.1.1)이라 전혀 바뀐게 없어보이지만,
이는 명백히 바뀐 주소이다.

이제 다시 1.1.1.1로 ICMP reply를 보낼 차례이다.
우습게도 다시 자신의 Frame-relay Mapping 테이블을 보니
Serial1/1을 통해 DLCI 102 를 달고 나가라는 것을 보고 R2에게 ICMP reply를 보낸다.


4. 네번째 단계

R2는 R1이 보낸 패킷의 destination이 1.1.1.1이다.
DLCI 201을 붙여 Serial1/1을 통해 전송해준다.





간략하게 정리해보자.
R1 ----------------------------------------------------------------- R2


ⓐ R1에서 source: 1.1.1.1 destination: 1.1.1.1로 ICMP request.
    매핑 테이블을 뒤져서 Serial1/1로 전송.

ⓑ R2에서 ICMP request를 받고, destination: 1.1.1.1임을 확인하고 R1에게 보내줌.

ⓒ R1에서 ICMP reply 받고, source와 destination을 바꿔서 source 주소 였던 1.1.1.1로 ICMP reply.
    매핑 테이블을 뒤져보니 Serial1/1로 보내야 함. 전송.

ⓓ R2에서 R1이 보낸 ICMP reply를 받고, destination: 1.1.1.1임을 확인하고 R1에게 보내줌.



이렇게 오가는 동안 응답시간은 2배로 늘어날 수 밖에 없다.
확인은 독자 여러분이 직접 ^^



 출처 : http://networkers.egloos.com/1453581