필자가 다니던 대학교는 한 IP당 2.5MB/s의 속도 제한이 걸려 있었다. 이 글에서 이 속도 제한을 파훼하기 위해 시도해 봤던 방법들과 짧은 생각을 적어보려 한다.

교내 네트워크 상황

필자가 다니던 학교의 교내 네트워크는 몇가지 특이한 점이 있었다.

• 학교에 건물이 30개이고, 그 안에는 다시 6개 이상의 층이 있고, 다시 그 안에는 수십개의 강의실 또는 방이 존재한다. 그 중 일부는 전산 강의실이었으며, 전산 강의실에는 최소 25대에서 300대 이상의 컴퓨터가 존재한다.
• PC 1대에 1개의 공인 IP를 부여한다.
• 학교 이름으로 된 ASN을 가지고 있으며, /23, /24의 IP 블록이 대략 8개 정도 존재한다. 이 IP를 각 컴퓨터에 부여한다.
• 네트워크는 Full-duplex 1.2Gbps 회선으로 SKT와 피어링 되어있다.

즉, 수 많은 컴퓨터가 Full-Duplex 1.2Gbps (2.4Gbps) 회선을 나눠쓰고 있는 상황이다. 규모에 비해 조약한 회선으로 학교 전체를 버텨야 하는 상황인 것이다. 그래서 다음과 같은 정책이 걸려있다.

• 각 IP당 2.5MB/s (= 20mbps)의 속도 제한이 걸려있다.
• 교내 IP 끼리 통신할 때도 속도 제한이 적용 된다

이런 속도제한 정책이 있어도 네트워크 대역폭에 비해 컴퓨터 수가 많아서 평일 강의 시간에는 900KB/s의 속도만 나와도 잘 나오는 편이다.

교내 네트워크 뜯어보기

교내 네트워크 팀에게 물어보니 위에서 처럼 “교내 IP 끼리 속도 제한이 걸린다”라는 답을 얻었다. 그러나 이는 매우 이상하다. Edge에 있는 장비가 모두 L3 (IP 단위) 라우터던가 L2+ 급의 스위치여야 하기 때문이다. 이 모든것을 네트워크 팀이 관리 해야 한다. 심지어 각 호실마다 교내 네트워크 팀과 별개로 추가된 것이 있었다.

결국, 최소 L3 단에서 QoS가 걸려야 한다. 각 호실에 있는 L2까지 관리는 불가능 할 것이고, IP단위로 속도 제한이 걸리기 때문에 당연히 그럴것이다. 각 건물에는 Spine이 한 곳, 많아야 두곳에 존재한다. QoS가 걸리는 지점은 넓게 잡아야 이 Spine일 것이고, 좁을 경우 Uplink로 가는 백본쪽에만 존재할 것이다.

또한, 이것 저것 살펴보다가 “TCP 통신에서만 속도 제한이 걸린다”는 것을 알아냈다. 정책을 TCP 쪽에만 설정한 것 같았다. UDP에서는 TCP의 Retransmssion와 같은게 없어서 그렇게 했을것이라 어림짐작 했다. 굳이 TCP에만 정책을 걸 이유는 없을것 같기 때문이다.

결국 모든것을 정리하면 다음과 같았다:

• IP당 속도 제한 최소 L3단에 걸린다.
• 속도 제한 정책은 건물당 하나 있는 Spine 또는 상위 백본에서 시행된다.
• 정책은 TCP에만 적용된다 (= UDP에서는 적용되지 않는다)

IP당 속도 제한으로 벌어진 일

IP당 속도 제한은 교내 네트워크 사정상 어쩔 수 없다. 문제는 이 정책이 무선 네트워크(노트북)과 만났을 때이다. 학과 내에서 방학때 한 호실에서 모여 25명씩 웹·앱·백앤드 서버를 만드는 프로젝트를 실시 했다. 이때, 다들 개인 노트북을 이용해서 프로젝트를 진행했다.

이때, 학과내에 존재하는 공유기(IPTime)는 1개의 IP만 먹혀서 25개의 노트북이 20mbps의 속도 제한을 나눠 쓰게 됐다. 구글링 하는데만 시간이 어마무시하게 걸리게 됐다. 그래서 별도의 Bridge가 되는 공유기를 구매해서 각 노트북에 IP를 깔아주었다.

원할한 개발을 위해 학과내 2U 서버를 지원받아 CI/CD를 진행했다. 또한, 필요한 리소스들도 해당 서버에서 끌어왔다. 문제는 이 서버는 다른 층에 존재하여 다른 서브넷상에 속했다. 해당 서버가 있는 층은 117.*.*.* 대역을 사용했고, 프로젝트를 하던 강의실은 210.*.*.* 대역을 사용했다. 서브넷을 벗어나다 보니 게이트웨이까지 거슬러 올라가 속도제한이 발생했다.

25대의 노트북이 1개의 서버에 접속하는 형태가 되다 보니까, 서버의 반응성이 너무 떨어졌다. 그러나, 어쨋든 같은 건물 내이기 때문에 L2(Leaf)내에서 처리가 가능하다고 판단 했다.

L2로만 통신하려면 IP없이 MAC으로 바로 패킷을 쏠 수 있어야 한다. 즉, 같은 서브넷 그룹에 있거나 ARP 테이블에 별도로 항목을 추가하여 L2만으로 패킷이 흐르게 해야 한다. 이런 환경을 구성하기 위해서 10.0.*.* 대역을 구성하여 각 서버와 노트북 끼리는 직접 통신이 가능하게 구성했다.

방학때 프로젝트를 진행할 때만 사용했으며, 교내에 충분한 회선량이 남은것을 확인하고 진행 했습니다.

마지막으로, 외부 네트워크와의 속도를 올리기 위해 UDP를 사용했다. 교내 망 끼리는 사설 네트워크 구역을 나눠서 어떻게 저떻게 통신을 했다. 그러나 외부망과의 통신은 그렇게 할 수 없다. 당연한 말이지만, 라우팅이 안될것이기 때문이다.

이에, UDP를 통해서 외부망으로 통신을 했다. 초반에는 Tailscale을 이용해서 필자가 운영중인 Oracle Cloud VM과 연결해 통신했다. 각 컴퓨터에 필자의 Tailscale 계정을 사용하고, OCI VM을 Exit node로 설정해서 통신했다. 그러나, 이 방법은 보안상 위험하고, VPN 설정을 푸는것을 놓치면 여러 문제가 발생할 수 있었다.

이를 해결하기 위해, 위에 언급했던 교내 서버를 Gateway로 구성하였다. 해당 서버로 보내진 패킷은 UDP로 캡슐화 돼서 Oracle Cloud로 전달된다. 이를 통해 교내에서만 사용 가능한 네트워크 가속기를 만들수 있었다.

안정적인 Gateway를 만들기 위해 다음과 같은 사항이 고려됐다

• 들어온 패킷은 다시 외부로 빼줘야 한다. 즉, ip forwarding 옵션이 켜져야 한다.
• 낮은 오버헤드를 위해 Rust로 TUN 장치를 구성했다.
• Gateway로서 받은 패킷을 TUN으로 보내고, 이 패킷을 Rust에서 받아온다
• Rust에서 받은 패킷을 socket 통신을 통해 UDP로 외부로 보낸다

이런 방식을 통해서 25명이 답답함 없이 동시에 네트워크를 쓸 수 있는 환경을 만들었다.

주의해야 할 점은, 이런 구성은 충분한 고려후 만들어야 한다는 점이다. 충분한 준비 없이 이런 구성을 만든다면 오히려 교내 IP망과 충돌하여 문제가 발생할 수 있다. 또한, 교내 구성원에 피해를 끼치지 말아야 한다. 1.2Gbps를 혼자 독식한다면 문제가 발생 할 수 있다. 그러므로 가속기 내에도 속도 제한 정책을 적용해야 한다. 필자가 이 망을 사용할 때도, 구성원들이 없는 방학때 + 단축 근로제 (교직원들은 오후 2시에 퇴근) 중에만 속도 제한을 걸고 제한적으로 사용했다.

단상

학교 구성원 수와 PC수에 비해 교내 네트워크의 대역폭은 매우 부족하다. 근본적으로 이 대역폭을 늘릴 필요가 있다. 이 문제의 근본적인 이유가 대역폭 부족이기 때문이다.

직접 피어링을 해야하는 특수성 때문에 비용이 크게 발생해서 어쩔 수 없는 상황을 이해한다. 그럼에도 불구하고 IT의 중요성이 커지며 컴퓨터가 많이 쓰이게 되는 환경에 직면했기에 대역폭 확장은 풀어야 할 숙제이다.

그와 동시에 네트워크 장비의 최신화가 필요하다. 위에서 언급하진 않았지만 아직도 강의실의 L2는 100Mbps 급의 스위치가 대부분이다. 45대의 컴퓨터가 100Mbps L2 스위치 하나에 의존하고 있다. 벽면 랜선 스위치도 절반은 100Mbps급이다. 한시라도 빠르게 1Gbps급으로 교내 통신 인프라를 개선할 필요가 있다.

마지막으로, 교내 통신에서는 속도 제한 정책을 풀 필요가 있다. 일률적인 속도 제한 대신 QoS만 적용해도 될 것이다. 평일 오후 강의 시간에 인터넷 속도가 느린것은 모두가 이해한다. 그러나, 모두가 집에간 밤 10시 까지 2.5MB/s 속도 제한이 필요한지는 의문이다. QoS를 통해서 망이 혼잡한 상황에서는 최대 2.5MB/s로 속도 제한을 적용하고, 망이 원할할 때는 동적으로 8MB/s 또는 그 이상으로 속도 제한을 걸 수 있을것이라고 생각한다.