엔터프라이즈 IP 네트워크연결정보관리시스템설계및구현 김은희 0, 최미정 1, 주홍택 2, 홍원기 1 0, 1 포항공과대학교컴퓨터공학과, 2 계명대학교컴퓨터공학과 Design and Implementation of Enterprise IP Network Connectivity Information Management System Eun-Hee Kim 0, Mi-Jung Choi 1, Hong-Taek Ju 2, James W. K. Hong 1 0, 1 Dept. of Computer Science and Engineering, POSTECH, 2 Dept. of Computer Engineering, Keimyung University della@postech.ac.kr, mjchoi@postech.ac.kr, juht@kmu.ac.kr, jwkhong@postech.ac.kr 요약현재대부분의엔터프라이즈 IP 네트워크의구성도의작성및유지는수작업에의존하고있어시간이지난후에는장비의추가, 삭제가제대로반영되지않아실제네트워크구성과달라지게된다. 이는전체네트워크장비와네트워크상태를파악하는것을불가능하게하여결국은관리자의네트워크관리를어렵게하는원인이된다. 효율적인네트워크관리를위해서는관리하는네트워크장비간의물리적인연결정보를추출하여네트워크구성도를자동적으로생성하는시스템이필요하다. 본논문에서는 에이전트를탑재하고있는네트워크장비의 MIB 정보를통하여연결정보를파악하고이것을바탕으로네트워크구성도를생성하는시스템을제안하고자한다. 본논문에서는네트워크장비검색및장비간물리적연결정보를알아내는상세한알고리즘을제시하고, 제시한알고리즘을기반으로네트워크구성도를생성하는시스템을설계, 구현한다. 개발한시스템을 POSTECH 네트워크의구성도생성에적용하여알고리즘의효율성을검증하였다. 1. 서론현재는네트워크중심의컴퓨팅시대로정보의공유와교환이네트워크를중심으로이루어지고있다. 대부분의기업, 학교, 공공기관등은갈수록빠른네트워크를요구하는시대에발맞춰수백대또는수천대의스위치나라우터를연결하여고속 LAN 을구축하고다양한네트워크서비스를제공하고있다. 따라서네트워크에문제가발생하면서비스를제공하지못하는결과를야기하므로, 네트워크문제를빠르게파악하고신속하게처리하는것이필요하다. 네트워크에문제가발생했을때, 네트워크상태와구성을실시간으로파악하고있다면문제가생긴지점을정확하고신속하게파악하여빠른대처를할수있다. 이런빠른대처를위해서는관리하는네트워크의물리적인네트워크연결상태가반영된네트워크구성도가필수적이다 [1]. 그러나, 대부분의엔터프라이즈네트워크구성도의 작성및유지는수작업에의존하고있어변경된네트워크의구성이네트워크구성도에실시간으로반영되기어렵다. 실제네트워크구성과수작업으로작성한네트워크구성도의불일치는네트워크관리를어렵게하는주요원인이된다 [2]. 따라서, 본논문에서는네트워크의연결정보관리를효율적으로수행할수있는시스템개발을목표로한다. 이시스템은관리하고자하는네트워크장비를자동으로검색하여장비들간의포트별연결정보를알아내어네트워크구성도를생성하는기능을제공해야한다. 본논문의구성은다음과같다. 2 장에서는본논문과관련된연구를소개하고, 3 장에서는시스템개발에대한요구사항들을정의하고, 4 장에서는연결정보를찾아내고네트워크구성도를생성하는알고리즘과시스템전체구조에대해서설명한다. 5 장에서는 4 장에서의설계를바탕으로시스템을구현하고, 구현한시스템을 POSTECH 네트워크에 본연구는 2007 년도두뇌한국 21 사업과정보통신부및정보통신연구진흥원의대학 IT 연구센터지원사업의연구결과로수행되었음 (IITA-2006-(C1090-0603-0045)) 1
적용하여네트워크구성도를생성한결과를보여준다. 마지막으로 6 장에서는연구내용을정리하고향후연구방향을제시한다. 2. 관련연구이장에서는네트워크장비의연결정보를파악하기위한 MIB (Management Information Base)[3] 에대해서알아보고, 개발하고자하는시스템과비슷한기능을제공하는기존시스템에대해서알아본다. 2.1. MIB 현재대부분의네트워크장비는 (Simple Network Management Protocol) 에이전트를탑재하여관리기능을제공한다. 관리기능은관리정보인 MIB 을정의하여조작함으로써제공된다. 이장에서는본논문에서사용하는관리정보 MIB 을알아본다. 2.1.1. Bridge MIB 장비의각포트별연결정보매칭을파악하기위해 Bridge MIB[3] 을사용한다. 전달되는패킷헤더의목적지 MAC address 를보고다음노드로전달해주는것이 bridge 기능이며, Layer 2 장비들의네트워크동작을나타내주는것이 bridge MIB 의역할이다. Bridge MIB 은다섯개의그룹으로구성되어있으며본논문에서사용되는두개의그룹에대한설명은아래와같다. dot1dbase Group 포트수, 포트타입, 포트주소와같은 Bridge 의기본정보를제공한다. 이그룹중에서 Bridge 와연결된모든포트에관한일반적인정보를가진 dot1dbaseporttable 을이용한다. dot1dtp Group Transparent bridge 기능에관한관리객체를포함한그룹이다. Transparent bridge 기능은학습을통하여라우팅테이블을만들고이테이블을기반으로프레임을전달한다. 각포트에연결되어있는다른장비의 MAC address 를각포트로들어오는 MAC 프레임을보고알아내어학습하고, 그결과는전달테이블로관리한다. 2.1.2. MIB-II 의 Address Translation 그룹멀티레이어스위치인경우설정에따라 Layer 2 나 Layer 3 를선택하여서비스를제공하게된다. Layer 2 인경우는 Bridge MIB 을이용하여포트별연결정보를알아내지만, Layer 3 으로동작하는경우에는 iftable 의 MAC address 가대부분동일한기본 MAC address 로설정되어 MAC address 로포트를구분할수없다. 이때는주소변환테이블을이용하여패킷을전달하기때문에아래의 MIB-II 의 at 그룹중 attable 을이용한다. at (Address-Translation) Group IP address 와 MAC address 간의매핑테이블로 구성되며장비의인터페이스별로 IP 주소와 MAC 주소를검색할수있다. 2.2. 관련시스템본논문에서구현한시스템과비슷한기능을제공하는제품으로 AdventNet 의 OpUtils Switch Port Mapper [4], CISCO Network Assistant[5], IBM Netcool/Precision[6] 이있다. AdventNet 의제품은각스위치의포트별상태를파악하는것에는유용하게쓰이지만전체네트워크의스위치간연결정보는파악할수없다. CISCO 제품은 CISCO 장비에대해서만네트워크구성도를작성한다. IBM 제품은 Layer 2 와 3 장비에대해서네트워크구성도를작성하지만이들이연결정보를취득하는방법에대해서공개하지않고있어그방법을알수없다. [1] 논문에서도표준 정보만을이용하여 2 계층의연결정보를찾아네트워크토폴로지를생성하였다. 그러나하나의 subnet 에서만동작하는단점이있다. 따라서, 본논문에서는네트워크장비검색및장비간연결정보를알아내는방법을 MIB 을이용한상세한알고리즘을제시하고제시한알고리즘을따라시스템을구현한후, POSTECH 네트워크에실제적용하여알고리즘을검증하는것을목표로한다. 3. 시스템요구사항본논문에서제안하는시스템은네트워크장비의연결정보를알아내어네트워크구성도를생성한다. 네트워크연결정보관리를위한요구사항은다음과같다. Discovery 기능관리대상인장비를자동으로검색하여 IP address 별장비목록을작성해야한다. 또한, 하나의장비에여러개의 IP address 가할당되어있을수있으므로하나의대표 IP 로그룹핑해서장비목록이작성되어야한다. Map 을통한연결정보관리기능각포트별장비간의연결정보를확인할수있어야하며, 장비의포트별사용여부 (enable/ disable) 를색으로구분하여관리자가효율적으로장비를관리할수있도록한다. 장비구성관리기능장비의추가, 삭제및장비의구성정보를변경하는기능이있어야하며, 포트의연결정보를변경할수있는기능이제공되어야한다. 데이터베이스관리및백업기능주기적으로장비의존재여부및구성정보에대한값을가져와관리정보데이터베이스에최신정보를유지하여정확한정보를제공해야한다. 관리자에의해변경된구성정보가데이터베이스에저장됨과동시에실제장비의구성정보에도즉시적용되어야한다. 2
쉬운사용자인터페이스기능네트워크구성요소들간의연결정보및구성정보를언제어디서나쉽게접근하여관리하도록웹기반의사용자인터페이스를제공해야한다. 또한, 시스템이전반적으로사용하기쉽고단순하게구성되어야한다. 4. 시스템설계이장에서는 3 장의요구사항을바탕으로네트워크연결구성정보관리시스템을설계한다. 먼저연결구성도를생성하기위한포트별 IP 매칭알고리즘을설명하고, 이알고리즘에근거한전체시스템구조를제시한다. 4.1. 포트별 IP 매칭알고리즘네트워크의연결구성도를생성하기위한포트별 IP 매칭알고리즘의전체순서도는그림 1 과같다. 그림 1. 포트별 IP 매칭알고리즘 단계 1: 관리장비를자동으로검색하기위해엔터프라이즈네트워크의관리대역 IP address 범위를외부로부터입력받는다. 단계 2: 입력받은모든 IP address 로 에이전트의탑재여부및관리대상장비에해당되는지알아내기위하여각장비의 sysservices 정보를요청하는 메시지를보내어응답하는장비에대해서만관리장비목록에추가한다. sysservices 는 7 비트코드로해석되는값으로각비트는 OSI 의각레이어를의미하며, 이값을기반으로관리대상장비로분류하게된다. 응답받은 sysservices 가 2, 3 의값을가지면 L2 스위치 며, 6 이면 L3 스위치, 78 이면 멀티레이어스위치 로판단하며이에해당되는 IP address 및 sysservices 정보를저장하여결과목록을작성한다. 단계 3: 하나의장비에여러개의 IP address 가할당될수있으므로동일한장비는대표 IP address 로그룹핑해서관리대상목록을작성한다. 장비의시스템정보중 sysdescr, sysobjectid, sysname, syslocation 이모두같으면동일한장비로판단한다. 단계 4: 각장비포트별연결정보를알아내기위해 포트매칭에필요한장비의 Interface 및 Bridge MIB, attable 의정보를가져와저장한다. 단계 5: 장비목록에저장된 IP address 순서대로장비의포트별 MAC address 를읽어와다른장비의 Bridge MIB 과 attable 의정보를비교해서동일한 address 가검출되면물리적으로연결되어있는것으로판단하고연결정보를저장한다. 이알고리즘은관리자의필요해의해즉시수행되거나, 관리자가설정한주기에의해반복수행됨으로네트워크장비의연결정보를최신정보로유지한다. 4.2. 네트워크장비별정보수집알고리즘포트별연결정보매칭을위해장비별로필요한정보를수집한다. 장비리스트에서 IP address 를순서대로추출해서추출한 IP address 에해당되는장비에서필요한정보를가져와저장한다. 먼저, 장비의 sysservices 가 78 인경우, Layer 3 에서동작하는장비로설정되어동작할수있으므로추가적으로장비의 MIB-II 정보중 attable 을저장한다. 다음으로, 장비의 MIB-II 정보중 iftable 의인터페이스값이현재동작중인포트만의미있으므로 ifadminstatus 와 ifoperstatus 의값이모두 up(1) 인상태의장비에대해서만 ifdescr 이 VLAN[6] 으로시작되는 String 을읽어와앞의 VLAN 을제외한값만저장한다. 다음으로, Bridge-MIB 에속하는 2 개의테이블인 dot1dbaseporttable 과 dot1dtpfdbtable 값을읽어와서저장한다. Bridge MIB 의테이블에서특정 index 의값을읽기위해서 Community String Indexing[7] 이라는문법을사용한다. VLAN 별로장비의포트에관한정보를읽어오는이유는 VLAN 별로 Bridge 기능이제공, 관리되기때문이다. dot1dtpfdbaddress Dot1dTpFdbPort dot1dtpfdbstatus 00.00.0C.07.AC.01 12 learned(3) 00.0B.60.AC.3A.8A 11 learned(3) 00.0B.60.AC.3E.4A 12 learned(3) 표 1. dot1dtpfdbtable 을 public@1 로읽은결과 표 1 은 community string 을 public@1 으로하여얻은 dot1tpfdtable 값이고이결과로 11, 12 번포트가 VLAN1 으로그룹되어있는것을알수있다. 새로운패킷헤더의목적지 address 가표 1 의 00.00.0C.07.AC.01 와같다면 12 번포트로전달된다. 12 번포트로 MAC address 가 00.00.0C.07.AC.01 와 00.0B.60.AC.3E.4A 을가진패킷이전달되어학습되었음을알수있다. 4.3. 네트워크장비의포트별 IP 매핑알고리즘그림 2 는 4.2 장에서추출한정보를바탕으로각장비의포트별연결정보를생성하는알고리즘이다. 먼저, Device LIST 의각장비 IP address 의 iftable 에서 enable 되어있는포트에대해서만 MAC address 를 3
읽어온다. 다음으로읽어온 MAC address와 Bridge Table 또는 attable의 MAC address에동일한값이 있는지비교한다. 동일한값이있으면 iftable에서 읽어온 IP address(source IP address) 와포트번호에 매칭되는 IP address(destination IP address) 와포트 번호를 데이터베이스의 Connectivity 테이블에 저장한다. 모든 장비에 대해서 이 알고리즘을 수행하면, 모든 장비의 연결 정보가 검출되어 저장된다. 장비정보수집기 (Device Information Collector) 장비그룹퍼에의해작성된 IP address 목록을순서대로입력받아포트별 IP 매칭을위해필요한 MIB 정보인 MIB-II 의 iftable 과 Bridge-MIB 의 dot1dbaseporttable, dot1dtpfdbtable 을각각의장비에요청하여저장한다. 또한, Layer 3 로동작하는스위치에대해서 MIB-II 의 attable 을가져와저장한다. 연결정보작성자 (Connectivity Mapper) 장비별연결정보를생성하기위한모듈로장비간실제물리적인연결정보를파악하는기능을수행한다. 이모듈의실행후, 최종적으로장비간포트별연결정보목록을얻게된다. 구성관리자 (Configuration Manager) 실제관리장비목록에서장비를선택하게되면선택된장비에대해 IP address 를입력받아, 선택된장비의구체적인정보와포트의사용여부상태등을확인할수있으며커뮤니티변경및포트의사용여부의변경, 대표 IP address 의변경을하는기능을제공한다. User Interface (Web-Browser) 그림 2. 장비포트별연결정보생성순서도 저장된연결정보를순서대로읽어와맵을생성할때, 먼저 Source IP address 장비의포트번호와 Destination IP address 장비의포트번호를읽어오고, 반대로읽어온 Destination IP address 장비의포트번호에 Source IP address 장비의포트번호가연결되어있는지검색한다. 두값이동일할때에만물리적으로서로연결되었다고한다. 이와같이두장비간의포트별연결정보는각장비가상대장비에대해포트별연결정보가서로일치한것에대해서만물리적인맵을생성하게된다. 4.4. 시스템구조그림 3 은웹기반의포트별연결정보관리시스템의구조이다. 각주요모듈의기능은아래와같다. 이외에도연결정보저장을위해데이터베이스가사용되며주요한모듈중하나이다. 장비스캐너 (Device Scanner) 외부로부터입력받은 IP address 범위내에있는 에이전트를탑재한장비를검색하는모듈로수행한후에실제관리대상이되는장비의 IP 목록을얻게된다. 장비그룹퍼 (Device Grouper) 라우팅기능을제공하는장비인경우하나의장비에여러개의 IP address 가할당되어있을수있으므로중복되는장비를하나의대표 IP 로그룹핑한다. 이모듈을수행한후에하나의장비에하나의대표 IP 가매핑된실제관리대상장비목록을얻게된다. HTTP Web Server List of Agents List of Device attable, iftable, BasePort, Bridge Table Connectivity Table IP Address range Agents (router, switch) Available IP Address Available IP Address Device Scanner IP Address & Agent Checker Checker Device Grouper Configuration Manager Device Information Collector Connectivity Mapper 그림 3. 전체시스템구조 Agent 5. 구현이장에서는 4 장의설계구조를바탕으로구현한시스템을 POSTECH 네트워크에적용하여네트워크구성도를생성한것에대하여살펴본다. 개발환경으로하드웨어는 CPU 2.4GHz, 1GB 메모리를사용했으며, 소프트웨어환경은윈도우 2000 운영체제하에, 톰캣서버와오라클데이터베이스를이용하여자바언어로구현했으며, AdventNet 에서제공하는 API[9] 를사용했다. POSTECH 네트워크대역인 141.223.1.1 부터 141.223.255.255 에대해서스캐닝을하여네트워크 MIB Agent MIB 4
장비만추출하여동일한장비를하나의 IP address 로묶기위한기능을수행한다. 그림 4 의화면은장비스캐닝이후, 하나의대표 IP 로그룹핑했을때의결과이다. 그림 4. 장비그룹핑수행후결과화면 여러개의 IP address 가할당된장비에대해서만 IPGROUP 의펼침목록메뉴가나타나며이목록에서장비에할당된 IP address 를확인할수있다. 관리자가원하는 IP address 로설정해서장비관리를수행할수있다. 이리스트에서장비삭제도가능하다. 그림 5. 네트워크의포트별연결정보화면 그림 5 는장비간포트별연결정보를확인할수있는화면으로연결정보화면은윈도우탐색기형식으로구성되어각장비의대표 IP address 를기준으로포트별연결정보를트리구조로보여준다. 그림 5 는 141.223.254.148 에연결된모든장비리스트를보여주는것으로, 화면에서첫번째대괄호안의숫자는연결된상대장비의포트를의미하고두번째대괄호의숫자는상대장비와연결된자신의장비의포트를의미한다. 즉, [40][11]141.223.254.148 의의미는 141.223.254.1 의 40 번포트와 141.223.254.148 장비의 11 번포트가연결되었음을나타낸다. 이포트매칭정보가실제 POSTECH 전산소에서제공하는정보와일치한다. 또한트리의특정장비의 IP address 를선택했을때, 장비의상세정보가오른쪽화면에나타난다. 그림 5 는 141.223.254.148 의장비에관한상세정보인시스템정보및각포트별장비의상태및 MAC address 정보를보여준다. POSTECH 내의 600 여대의네트워크장비를 discover 하는데약 14 분, 동일장비를그룹핑하는데약 3 분, 필요한 MIB 정보를수집하는데약 82 분, 장비간연결정보를생성하는데약 61 분의시간이소요된다. 6. 결론및향후과제본논문에서는네트워크연결정보구성관리를효율적으로수행할수있도록네트워크장비간의물리적인연결정보를알아내는시스템을개발하였다. 본논문에서우리는포트별 IP 매칭알고리즘을제안하고그에따른요구사항을분석하고, 시스템설계, 구현하여네트워크구성도를생성하는방법을제시하였다. 네트워크장비검색및장비간연결정보를알아내는알고리즘을제시했다는점과제시한알고리즘을기반으로시스템을구현한후, POSTECH 네트워크에적용하여알고리즘을검증함으로써실제네트워크관리에도움을주는시스템을설계및구현했다는점에의의를둔다. 향후과제로네트워크의규모가커져장비의수가늘어나도적정시간내에장비를검색할수있는 scalability 보장에관한연구가이루어져야한다. 또한, 장비를검색함에있어서전체네트워크에대한탐색이므로빠른시간내에장비검색이이루어지도록 performance 를향상시키는연구가이루어져야한다. 참고문헌 [1] Bruce Lowekamp, David R. O Hallaron, Thomas R. Gross, Topology Discovery for Large Ethernet Networks, SIGCOMM, pp. 237~248, Aug. 2001. [2] 박윤규, 웹기반의네트워크트래픽모니터링시스템의자동구성및재구성기법, Masters Thesis, POSTECH GSIT, 2000. [3] E. Decker, Definitions of Managed Objects for Bridges, IETF, RFC 1493, Jul. 1993. [4] AdventNet Inc., Switch Port Mapper Tool, http://manageengine.adventnet.com/products/oputils/switc h-port-mapper.html, Refer Jan. 2007. [5] Cisco, Network Assistant Feature, http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ cna/v4_0/gsg4_1/gsg_en/feature.htm, Refer Jan. 2007. [6] IBM, Netcool/Precision for IP Networks, http://www-306.ibm.com/software/tivoli/products/netcoolprecision-ip/index.html, Refer Jan. 2007. [7] Cisco, Community String Indexing, http://www.cisco.com/warp/public/477//camsnmp40 367.html, Refer Jan. 2007. [8] Cisco, How To Get Dynamic CAM Entries (CAM Table) for Catalyst Switches Using, http://www.cisco.com/warp/public/477//cam_snmp. html, Refer Jan. 2007. [9] AdventNet Inc, AdventNet API, http://snmp.adventnet.com/help/snmpapi/snmpv1/, Refer Jan. 2007. 5