[Routing] 라우팅 오류 및 네트워크 장애 해결 방안

 

1. 라우팅 누락으로 인한 장애

 네트워크 경로를 추가한 후, 특정 대역의 서비스가 불가능한 상태가 발생할 수 있다. 여러 가지 원인이 있을 수 있지만, 라우팅 누락이 주요 원인일 수 있다.

 

 예를 들어, 10.10.10.0/24 대역에 대한 라우팅이 R2에서 잘못 설정되어 루핑이 발생하는 경우를 들 수 있다. 보통 R1, R2, R3의 네트워크 담당자가 다를 경우, 전체 라우팅 구조를 제대로 이해하지 못한 채 이런 문제가 발생할 수 있다. 이 문제를 진단하는 방법으로, 라우터에서 Traceroute 테스트를 수행하면 루핑 현상을 확인할 수 있다. 또한 서버나 클라이언트 PC에서 #netstat -an 명령어를 통해 TCP 3-way handshake가 성립되지 않음을 확인할 수 있다. 이를 통해 장애 원인을 파악할 수 있다.

 

2. 재배열로 인한 서비스 지연

 다중 경로를 이용해 로드 밸런싱을 구현할 경우, 특정 인터페이스의 혼잡으로 인해 서비스 지연이나 심각한 장애가 발생할 수 있다. 특히 시간에 민감한 서비스나 인증 관련 서비스에서 문제가 발생할 수 있으며, UDP와 같은 프로토콜을 사용하는 서비스에서는 단편화와 패킷 재배열(Reordering)로 인해 장애가 발생할 수 있다.

 

 이러한 문제는 동적 라우팅을 사용한 로드 밸런싱에서 더욱 두드러질 수 있다. 혼잡이 발생한 네트워크에서의 로드 밸런싱은 서비스 성능에 심각한 영향을 미칠 수 있기 때문에, 특정 서비스에 대해서는 정적 라우팅을 사용하여 다중 경로를 조정하는 방안이 유효하다. 이를 통해 로드 밸런싱 문제를 해결하고 서비스의 안정성을 확보할 수 있다.

 

3. 비대칭 경로로 인한 서비스 장애

 비대칭 경로는 패킷이 전달되는 경로와 수신되는 경로가 일치하지 않는 경우 발생하는 장애이다. 이러한 문제는 다중 경로를 사용하는 네트워크 환경에서 방화벽과 관련해 발생할 수 있다.

 

 대부분의 비대칭 경로는 통신에 큰 문제를 일으키지 않지만, 보안 장비인 방화벽을 경유하는 경우에는 문제가 발생할 수 있다. 예를 들어, 클라이언트가 방화벽을 통해 서버에 연결되고, 서버 측 네트워크는 다른 경로를 통해 클라이언트와 통신하는 경우이다.

 

 이 상황에서는 클라이언트에서 보내는 TCP SYN 패킷이 서버에 도달하고, 서버는 SYN 상태로 응답한다. 그러나 서버에서 보내는 SYN-ACK 패킷이 비대칭 경로를 통해 클라이언트에 전달되며, 클라이언트는 ACK 패킷을 방화벽을 통해 보내게 된다. 이때, 방화벽에서 ACK 패킷을 차단하게 되어 서버는 여전히 SYN 상태에 머물게 된다. 결과적으로 TCP 3-way handshake가 완료되지 않아 서비스 장애가 발생한다.

 

4. 정적 라우팅에서 다음 홉 경로의 인터페이스 사용에 따른 과부하 장애

 방화벽이나 IPS가 네트워크 장비 사이에 위치한 데이터 센터 네트워크에서는 동적 라우팅보다는 정적 라우팅이 일반적으로 사용된다. 정적 라우팅은 장비의 CPU 사용을 최소화하고, 직관적으로 관리할 수 있는 장점이 있다.

 

 하지만, 정적 라우팅에서 문제가 발생할 수 있는 경우가 있다. 예를 들어, 다음 홉 경로를 브로드캐스트 인터페이스(이더넷 인터페이스 등)로 설정할 경우 과부하가 발생할 수 있다.

 

(1) 문제 설명

 M_BB와 S_BB 트래픽이 IPS를 통해 로드 밸런싱을 위해 구성된 네트워크에서, M_BB_1의 링크가 다운되었을 때 S_BB_1의 라우팅 테이블에서 라우팅 항목이 사라지지 않는 문제가 발생했다. 이를 해결하기 위해, 물리적 인터페이스가 다운될 때 라우팅 테이블을 갱신할 수 있도록 "연결된 인터페이스(connected interface)"를 설정하는 방법이 사용되었다. 그러나, 설정 변경 후 S_BB의 Giga-Ethernet 2번 모듈 재부팅과 함께 CPU 사용률이 급증하는 문제가 발생했다.

 

(2) 원인과 해결 방안

 정적 라우팅에서 브로드캐스트 인터페이스를 사용할 경우, 해당 인터페이스가 업 상태일 때만 경로가 라우팅 테이블에 존재한다. 예를 들어, M_BB의 인터페이스가 다운되더라도 S_BB의 디폴트 라우팅은 라우팅 테이블에 계속 존재한다. 이는 재귀 루트(Recursive route)를 통해 다음 홉(예: 10.10.6.1)을 포함한 경로가 슈퍼넷(Super-Net) 10.0.0.0/8로 존재하기 때문에 발생한다. 이로 인해 라우팅 테이블에서 10.0.0.0/8 경로가 유효한 경로로 인식되고, 패킷이 백본을 통해 방화벽 쪽으로 포워딩된다.

 

 문제는 이더넷과 같은 브로드캐스트 환경에서 "연결된 인터페이스"로 다음 홉을 지정하는 경우, 라우터가 해당 인터페이스를 통해 연결된 모든 호스트를 고려하려 하며 ARP 요청을 발생시키게 된다. 이로 인해 라우팅 테이블에 있는 모든 목적지에 대해 ARP 프로세스가 발생하고, 이로 인해 CPU 과부하와 ARP 캐시의 급증이 발생한다. 결국, 메모리 할당 실패로 이어지며, 정적 라우팅의 안정성을 확보하기 어려운 상황이 발생한다.

 

해결 방안으로는, "ip route 0.0.0.0 0.0.0.0 10.10.6.1 gi2/1"와 같이 다음 홉에 IP 주소와 인터페이스를 동시에 설정하여 ARP 프로세스를 제한하는 방법이 있다. 이를 통해 불필요한 ARP 요청을 방지하고, 과부하 문제를 해결할 수 있다. 브로드캐스트 인터페이스에서 정적 라우팅을 설정할 때는 "Floating Static Routing" 방식으로 설정하지 않는 것이 좋다.

 

5. 재귀 루트의 이해

 재귀 루트(Route Recursive)는 라우팅 테이블에서 발생할 수 있는 중요한 문제로, 특히 정적 라우팅에서 나타날 수 있다. 모든 라우팅 테이블은 가장 긴 프리픽스 매칭 방식에 따라 경로를 찾기 때문에, 라우팅 테이블을 참조할 때 이 점을 반드시 고려해야 한다.

 

- 문제 설명

 예를 들어, R1의 serial 3/2 인터페이스를 셧다운하면, 플러딩 정적 루트를 통해 R1과 R2의 최적 경로는 제거되어야 한다. 그런데 192.168.20.X에 대한 다음 홉이 라우팅 테이블에 등록되어야 하는 상황에서도, 실제로는 10.10.10.2의 다음 홉이 R1에서 제거되지 않는다.

 

 이 문제는 재귀 라우팅이 발생하기 때문이다. 정적 라우트들은 종종 다음 홉으로 다른 라우터를 지정하는데, 이 경우 라우터는 그 다음 홉을 통해 경로를 찾으려고 시도하면서 라우팅 테이블에 계속 존재하게 된다.

 

- 원인

 R1은 ISP 라우터로 정적 디폴트 루트를 설정하고 있다. 172.31.10.0/24와 같은 네트워크에 대해, 다음 홉인 10.10.10.2를 사용하여 패킷을 전송할 수 있다고 판단한다. 이 과정에서 10.10.10.2로 향하는 재귀적 경로가 라우팅 테이블에 계속 유지되기 때문에, 실제로 플러딩 정적 루트는 라우팅 테이블에 등록되지 않는다.

 

- 해결 방안

 

• 다음 홉을 설정할 때 해당 인터페이스를 정적 라우팅에 함께 포함시킨다.
• 즉, 다음 홉 IP 주소와 해당 인터페이스를 동시에 지정하여, 그 인터페이스를 통해서만 다음 홉에 도달할 수 있도록 한다.
• 이를 통해 플러딩 정적 루트가 라우팅 테이블에 등록되지 않고, 올바른 경로만 유지되도록 한다.

 

 예시로, ip route 172.31.10.0 255.255.255.0 10.10.10.2 GigabitEthernet0/1과 같이 설정하면, 10.10.10.2가 연결된 인터페이스를 통해서만 이 경로가 활성화되며, 라우팅 테이블의 재귀적 경로 문제가 해결된다.

ip route 172.31.10.0 255.255.255.0 serial3/2 10.10.10.2 ip route 172.31.10.0 255.255.255.0 serial3/3 192.168.20.2 250