SNMP 기반의엔터프라이즈 IP 네트워크연결정보관리시스템 이성주 0, Suman Pandy 1, 최미정 1, 홍원기 1 포항공과대학교정보통신대학원 0, 포항공과대학교컴퓨터공학과 1 {forstar, suman, mjchoi, jwkhong}@postech.ac.kr 요 약 엔터프라이즈 IP 네트워크관리를효율적으로제공하고 IP 네트워크내의결함원인과위치를탐지하기위하여, 네트워크연결정보를유지하는것은필수적이다. 최근 10 년간엔터프라이즈네트워크구성도를자동으로탐지하는방법에대한연구가많이이루어졌다. 본논문에서우리는기존의네트워크구성도탐색메커니즘들의다양한문제점에대하여알아보고, L2/L3/L4/L7 스위치, 라우터, 프린터, 호스트와같은다양한장치들과이러한장치들간의물리적인링크를탐색하기위한 SNMP 기반의시스템을제안한다. 본논문에서제시한시스템을통해탐색된네트워크연결정보들을그래프나트리와같은형태로보임으로써사용자에게직관적인네트워크토폴로지정보를제공한다. 또한네트워크구성도를물리적인연결상태뿐아니라 VLAN 과 Subnet 과같은논리적인구성도를탐색하는방법에대해서도논의함으로써네트워크의다양한연결정보를제공하는방법을제시한다. 1. 서론현재네트워크관리시스템은자원관리, 서버관리, 결함모니터링, 결함원인분석, 네트워크부하조정, 바이러스예방등의다양한관리기능들을포함한다. 네트워크전체에대해서이런관리기능을효율적이고직관적으로보여주기위해서는네트워크구성과장비들의연결정보들을한눈에보기위한도구들을필요로한다. 네트워크연결정보를자동으로생성하기위한기존연구들은 ping, icmp echo 요청, SNMP 등의방법을사용하여진행되어왔다. 이러한기존연구들은다음과같은이슈들이존재한다. - 네트워크는다양한제조사들의장비들로구성되며, 각장비는각각의고유한 private MIB 을가지고있다. SNMP 기반으로네트워크연결정보를탐색하기위해서는네트워크를구성하는각장비의 private MIB 을알아야한다. 그러나이를모두알고적용하는것은쉽지않다. IETF 에서는물리적인구성 MIB[8] 을소개하였지만 CISCO 장비만이이를지원하고있다. 그러므로 SNMP 기반의네트워크구성탐색방법에있어서 private MIB 에의존하지않고표준 MIB 정보를기반으로연결정보를생성하는방안이마련되어야한다. - 현재 LAN 환경에서보안과불필요한네트워크트래픽감소를목적으로 VLAN 을설정하여많이사용하고있다. 네트워크연결정보를구성함에있어서물리적인연결정보뿐만아니라논리적인연결정보인 VLAN 에대한연결정보도 본연구는두뇌한국 21 과지식경제부및정보통신연구진흥원의대학 IT 연구센터지원사업의연구결과로수행되었음 " (IITA- 2008-C1090-0801-0045) 관리자에게는네트워크구성설정을위해필요한자료이다. 그러나기존의연구에서는 VLAN 탐색에대한부분이제대로논의되지않았다. - 기존의네트워크연결정보탐색에대한연구는레이어 2 와레이어 3 각레이어별네트워크구성도를탐색하는방법에대해진행되었다. 그러나레이어 2 와레이어 3 장비간의상호연결정보제공에대해서는연구가충분히이루어지지않았다. 따라서본논문에서는이러한주요이슈들에대하여다루고있다. 네트워크구성도는네트워크내의요소들 ( 링크, 노드등 ) 간의물리적이거나논리적인상호연결들을반영하는두가지로분류될수있다. 물리적인네트워크구성은각장비들이전달매체를통해장비포트별로연결되어있는것이고, 논리적인구성은 subnet 과 VLAN 과같은논리적인세그먼트들로나뉘어진네트워크의다른추상화계층이다. 또한네트워크연결정보탐색은인터넷이나백본망레벨의탐색과 LAN 이나 enterprise 조직망레벨의구성탐색으로분류될수있다. 본논문에서는이중 enterprise 레벨의 LAN 구성탐색메커니즘만을목표로하고있다. 본논문의 SNMP 기반의엔터프라이즈 IP 네트워크의연결정보를탐색하여자동으로토폴로지맵을생성하는방법에대한알고리즘을설계하고연결정보관리시스템을구현하는방안에대해서제시한다. 본논문의구성은다음과같다. 2 장에서는네트워크연결정보탐색에대한기존의연구에대해알아보고 3 장에서는시스템아키텍쳐와알고리즘을정의한다. 4 장에서는시스템을설계하고구현하며,
5 장에서는구현된시스템을테스트하고그결과를분석한다. 마지막으로 6 장에서는결론을맺는다. 2. 관련연구 이장에서는관련연구로네트워크연결정보탐색에대한기존의연구에대해알아본다. 네트워크구성탐색방법은네트워크의출현이래광범위하게연구되어왔다. 구성탐색에관한다수의흥미로운메커니즘들은 ping, trace route, SNMP, network traffic 기반의추론기술등을 토대로연구되었다 [9]. 각제조사들이만든다양한장비들로구성된네트워크의연결정보를 SNMP 기반으로제공하기에는몇가지문제점들이있다. RFC 2922 에서는표준화된 PTOPO-MIB[8] 을정의하고있지만대부분의장비들이이를지원하지않아널리적용되지못하고있다. 표 1 에서는우리가제안하는시스템과기존의시스템에대한비교를보여준다. 기법 지원하는장비타입 Subnet / Inter Subnet 연결정보 성능 VLAN 복잡도 Discovering Internet Topology(1999)[1] Ping / Broadcast Ping / Traceroute / Zone transfer DSN server / SNMP / Subnet Guessing Algorithm Router / 호스트 Subnet Guessing 알고리즘사용 Inter Subnet 연결언급없음 SNMP, ping, echo 등의성능비교 (SNMP 가가장좋은성능, Echo 는시간이오래걸림 ) 언급없음 많은트래픽발생 표 1. 기존연구비교 Topology Discovery in Heterogeneous IP Networks: The NetINventory System(2004)[2] SNMP(ICMP Spoofing Heuristics) 라우터 / L2 스위치 / 호스트 Inter Subnet 연결정의를위해 subnet 정보사용 ICMP spoofing 과 AFT 테이블계산에많은시간소요 VLAN 고려, 단매우복잡한공식에의한 VLAN 탐색 ICMP 패킷전송시인터벌전송으로적당한트래픽발생 Topology Discovery for Large Ethernet Networks SMU(2001)[3] A Complete IP Network Topology Discovery Solution Constella(2007)[4] SNMP 기반의엔터프라이즈 IP 네트워크연결정보관리시스템 SNMP SNMP(Ping) Only SNMP L2 장비, 허브, Dumb Devices Subnet 정보사용없음 탐색소요시간에대한결과없음 ( 기탐색된네트워크에대한연결탐색시간만제시 ) 언급없음 적은트래픽발생 라우터 / L3 / L2 스위치 / 호스트 / 프린터 Intelligent Subnet Guessing 알고리즘사용 탐색된노드수가적어서성능비교어려움 언급없음 탐색하는노드수에비례하는트래픽발생 라우터 / L2,L3,L4,L7 스위치 / 프린터 / 호스트 Subnet/ Inter Subnet 연결정보사용 7000 개이상의다수의노드탐색수월 VLAN 탐색방법제시 매우적은트래픽 ( 적은수의 SNMP query 를통해 MIB 정보수집, Spoofing 또는 Ping 기법사용안함 ) 탐색하기위한기존의연구에서는 ping, icmp, trace route, SNMP 등의다양한기술들을조합하는방법제안하였다 [1]. 이러한방법들은규모가작거나크게복잡하지않은네트워크내에서장비타입에대한세부사항에대한언급없이레이어 3 의장비들만을탐색하는것이대부분이었다. [2] 에서는레이어 2 와레이어 3 계층의장비들을탐색하며, 네트워크구성도탐색을위한혼합된방법을제시하였다. 이방법은 spoofed ICMP 요청을네트워크노드로보내고, 그들의알고리즘을이용하여각노드들의 AFT(Address Forwarding Table) 을만든다. 이것은효율적이지만 spoofed ICMP 패킷을보내는데있어엄청난트래픽을생산하는단점이있다. 현재의대부분네트워크설정에서 spoofed ICMP 패킷은블록화되기때문에 spoofed ICMP 로부터데이터를수집하여 AFT 테이블을 만드는것은비현실적이다. 이알고리즘은완성된 AFT 를필요로한다. 완성된 AFT 테이블을만들기위해서는다수의 spoofed 패킷들을생산하고, 데이터베이스내의연결정보의부하를야기한다. 이러한과정은자원을집중시키고시간을소비하게된다. 불완전한 AFT 테이블의경우연결정보를찾기위해 heuristics 을사용하게되는데본논문에서는이에대해논하지않았다. [3] 에서는 [2] 와는반대의접근방법을제안하는데, 여기서는 AFT 를만들지않고 spoofed ICMP 패킷을사용한다. 하지만여기서는노드간의연결정보를찾는데어떻게불완전한 AFT 가사용되는지증명하였다. 본논문은 [3] 의개념을확장하여네트워크내의 L2 장비들의연결정보를계산하는데기존의개념을이용하였다. 본논문은다양한측면에서주목할만하다. 본
논문에서는탐색시스템의구현부분을연구하고, 어떤 식으로 SNMP Bridge MIB을 사용하여 AFT테이블을만들것인지서술한다 [12]. 일반적인 구성탐색을위하여표준 MIB을사용하며, Cisco와 같은 제조사의 VLAN의 탐색과 같은 특정한 기능을위하여사설 MIB을사용한다. 본 논문의 탐색 알고리즘은 Subnet 레벨의 탐색과이를시각적으로표현하는방법에대해서도 논하고있다. 여기서는완전한 MIB 객체와정교한 SNMP 아키텍처를이용한알고리즘을제공한다. 비록 IP 등의 L3계층과 MAC과같은 L2계층의 구성도를 탐색하는 방법에 대한 많은 연구가 이루어졌지만 L2계층과 L3계층을서로연결하는 부분에 대한 세부적인 연구는 없었다. 본 논문에서는 이에 대한 완성된 시스템과 뷰를 제안한다. 네트워크구성도탐색기능을제공하는 HP사의 Open view나 IBM사의Tivoli, 그리고 AdventNet사의 OpManager와같은대부분의최신의툴에서좋은 네트워크뷰를제공하는것은또다른문제이다. 본 논문에서는네트워크에대하여 VLAN이나 Subnet 그리고 Graph뷰와같은다양한뷰를제공한다. Graph뷰의복잡성을최소화하기위하여 Graph뷰는 L3계층만을보여준다. Graph뷰내에서 L2계층의 노드나스위치에대해보고싶다면, 해당노드에 마우스를 클릭함으로써 Tree뷰로 전환하여 구성도를 볼 수 있다. 스위치들은 또 다른 스위치나끝단의호스트들과서로연결되어있기 때문에 네트워크의 끝단까지의 구성도는 Tree형태로 보여지게 된다. 스위치들은L2레벨의 구성도를 탐색하는데 사용되는 브리지 MIB을 지원한다. 브리지 MIB은 spanning tree protocol을 지원한다. 그러므로 L2계층과 네트워크 끝단의 구성을표현하는데는 Tree뷰가가장적합하다. 이를 통해노드들을전개하거나네트워크계층을보기 위한기능들을제공받는다. 3. 디자인 이장에서는본논문에서제안하고있는연결관리정보시스템의아키텍처에대해서설명하고, 연결정보를탐색하기위한 SNMP MIB 정보에대해서알아본다. 마지막으로연결정보탐색알고리즘에대해서자세히설명한다. 3.1. 시스템아키텍처그림 1 에서보듯이네트워크구성도탐색시스템은세가지메인모듈로이루어진다. 첫번째모듈은다양한입력과뷰를담당하는 Web Interface 모듈이다. 프로그램에입력해야하는구성정보들로는네트워크구성도를유지하는데필요한데이터베이스정보와게이트웨이 IP 주소를포함하는네트워크정보, SNMP community string, 그리고한 AS 에서탐색해야하는 IP 주소범위와 SNMP 포트와같은설정정보들이있다. 탐색을시작하기위해서는기본적인입력절차가필요하다. 이렇게입력된정보들은장비들을탐색하고연결정보를찾는탐색모듈로보내진다. 또한 Web Interface 모듈에서는 Administrator 가특정노드에대한 customizing 을하고자할때필요한정보입력을담당한다. 기본적인 Administrator customization 기능은노드의위치나제조사정보, 그리고타입등을변경하는것이다. 또한이모듈에서는탐색된네트워크구성도에대하여그래프나트리형태의다양한사용자인터페이스뷰를제공한다. 그림 1. 시스템아키텍쳐 Node Discovery 모듈은웹인터페이스모듈로부터정보를받아네트워크내의노드들을탐색한다. 여기서는 3.3 장에서설명할 Next hop discover 메커니즘을사용하여탐색을한다. 새로운노드를찾은후에그노드와연관된 MIB 정보는 Data Loader 를이용하여데이터베이스에저장한다. Node Discovery 모듈은다양한기능들을지원하는내부의작은모듈들을포함한다. 탐색된노드의 SNMP 지원여부를확인하는 SNMP support finder 나 Cisco 사의장비에대하여브리지 MIB 을불러오는 community string indexer 와같은다양한내부모듈들이 Node Discovery 모듈을지원한다 [5]. 만약동일장비에다수의 IP 주소가있다면 group finder 가이러한 IP 주소들을한개의장비로그룹화하며, device type identifier 는장비의타입을결정하고, net to media 모듈은더많은장비들과그들의연결정보를탐색하는것을지원한다. 일단노드들이탐색되고관련된 MIB 정보들을
MIB MIBII (REF-1213- MIB) 표 2. MIB 정보 MIB Object system sysservices system sysdescr iftable ifindex iftable ifdescr iftable ifphyaddress ip ipforwarding ip iproutetable iproutnexthop ip iproutetable iprouttype ip ipaddrtable ipadentaddr ip ipaddrtable ipadentnetmask ip ipnettomediatable ipnettomedianetaddress ip ipnettomediatable ipnettomediaphysaddress CISCO-VTP-MIB vtpvlanstate dot1dbrige dot1dbase dot1dbaseporttable dot1dbaseportentry dot1dbaseport dot1dbrige dot1dbase dot1dbaseporttable BRIDGE-MIB for dot1dbaseportentry dot1dbaseportifindex Cisco switch dot1dbrige dot1dtp dot1dtpfdbtable (modify the mib dot1dtpfdbentry dot1dtpfdbaddress name) dot1dbrige dot1dtp dot1dtpfdbtable dot1dtpfdbentry dot1dtpfdbport dot1dbrige dot1dtp dot1dtpfdbtable dot1dtpfdbentry dot1dtpfdbstatus qbridgemib qbridgemibobject do1qvlan Q-BRIDGE-MIB do1qportvlantable do1qportvlanentry dot1qpvid dot1dbrige dot1dstp dot1dstpporttable dot1dstpportentry dot1dstpport dot1dbrige dot1dstp dot1dstpporttable BRIDGE-MIB for dot1dstpportentry dot1dstpportstate other vendor dot1dbrige dot1dstp dot1dstpporttable devices except dot1dstpportentry dot1dstpportdesignatedroot CISCO dot1dbrige dot1dstp dot1dstpporttable dot1dstpportentry dot1dstpportdesignatedbridge dot1dbrige dot1dstp dot1dstpporttable dot1dstpportentry dot1dstpportdesignatedport 불러오면, Connectivity Discovery 모듈에서관련 MIB 정보들을사용하여장비들간의연결정보를탐색하게된다. 여기서필요한네가지기본알고리즘은 3.4 장에서자세하게설명한다. 3.2. SNMP MIB 본논문에서제안하는탐색메커니즘은 SNMP 에기반한다. 표 2 에서는본논문의탐색알고리즘을지원하는모든 SNMP MIB 에대하여설명하고있다. 본논문에서는연결정보를얻기위해 RFC1213-MIB[11], BRIDGE-MIB[12], Q- BRIDGE-MIB[13] 과같은표준 MIB 과 Cisco 스위치의 VLAN 과관련된정보를위한 CISCO- VTP-MIB 과같은 private MIB 정보를이용하였다. 데이터베이스내의모든필드들은표 2 에서설명하는 MIB 에대응한다. 각각의탐색된장비에는 singleton class identifier 를사용하여유일한 identifier 를생성한다. 우리의프로그램은단하나의 identifier class 의인스턴스를가지고있으며이 class 는각각의새로운노드에대하여유일한키를생성하는역할을한다. 한장비가다중 IP 주소를가질수있기때문에 IP 주소는 identifier 로취급하지않는다. 새로운장비를탐색하자마자그장비가 SNMP 를지원하는지확인하기위해 SNMP GET 메시지를보내고, 지원할경우표 2 에서언급했던모든 MIB 정보를수집하고그정보를데이터베이스의해당테이블에저장한다. 일단모든장비에대한정보를데이터베이스에업데이트하면그림 1 의 Connectivity Discovery 모듈에서연결 정보를찾기시작하고, ConnectivityTable 을생성한다. 3.3. 탐색알고리즘이장에서는장비를탐색하고탐색된장비에대한연결정보를찾기위해사용된알고리즘에대하여설명한다. 그림 2은본논문에서제안하는탐색시스템에대한전체흐름도를보여준다. 탐색알고리즘이동작을시작하면 Input Network Info 모듈은게이트웨이 IP, SNMP community string 또는비밀번호, SNMP 포트그리고탐색범위의제한등의정보를입력받는다. 입력받은정보는게이트웨이노드로부터도달가능한모든 next hop 노드를찾기위해게이트웨이 IP 주소의 iproutnexthop MIB정보를가져오는 Discover Device using the findresourcewithnexthopmechanism(r) 모듈로보내진다. 만약새로운노드가 iproutnexthop 테이블에있다면그노드의 MIB 정보를데이터베이스로부터불러온다. 이모듈은 iproutnexthop 테이블의도움으로연결된장비들을탐색하고, next available hop으로이동하기위해이테이블정보를이용한다. 동일한과정이연결정보를찾기위해반복되며, 이과정은 iproutnexthop 테이블에더이상 next hop에대한 entry가없을때까지진행된다. 일단 Discover Device using the findresourcewithnexthopmechanism(r) 모듈이장비탐색을마치면 Discover Device using the findresourcefromnettomedia() 모듈로제어권이이동한다. 이모듈에서는 nettomedia 테이블을이용하여장비를탐색하는데, 여기에 Discover Device using the findresourcewithnexthopmechanism(r) 모듈에서탐색된모든장비들을저장하며, 각장비의 SNMP 지원여부를알기위해 SNMP GET 메시지를보낸다. 만약그장비가 SNMP 를지원한다면, 3.2장에서설명한 MIB 정보를 SNMP 에이전트로부터읽어와서해당데이터베이스에저장한다. 일단모든장비가탐색되면제어는탐색된장비타입을라우터, L2/L3/L4/L7 스위치, 프린터, 그리고네트워크터미널노드등으로분류하는 Discover Device Type 모듈로넘어간다. 모든장비에대한타입을결정한후, 각장비에대한연결성을확인하는 connectivity function 이호출된다. Find L2 level connectivity findconnectionbetweenswitchtoswitch() and findconnectionbetweenswitchtorouter() 모듈은스위치와스위치또는스위치와라우터사이의연결정보를찾는일을수행하고 Find L3 level connectivity findconnectionbetweenroutertorouter() and findconnectionbetweenotherdevicewithswitchandrouter () 모듈은라우터와라우터또는스위치와다른그외다른장비간의연결정보를찾는다. 그림 2 모듈의수행알고리즘에대해서는다음각장에서자세히설명한다.
RV Set of resources already discovered from algorithm 1 N RV NetToMediaTable set for RV stored in database. R New resource Run loop on each element of RV Retrieve N RV for each RV Run loop on each element of N RV R= element of N RV If(getSynonymGroupElement(R) is equal to null) LoadMIBForNode(R, C) 그림 2. 시스템흐름도 3.3.1. Discover Devices 이모듈은게이트웨이 IP 주소, SNMP community string, port, IP 의범위등의설정정보를입력받아장비를탐색하는역할을수행한다. 알고리즘 1 과 2 는장비를탐색하는데사용되고, 알고리즘 3 은탐색된장비의 MIB 정보를데이터베이스에저장하는데사용된다. 데이터베이스의구조와그에해당하는 MIB 정보는 3.2 장에서이미논의되었다. 알고리즘 1 에서는 iproutnexthop MIB 을이용하여장비를탐색하며여기서는게이트웨이 IP 주소를입력받는다. Algorithm 1: findresourcewithnexthopmechanism (R) R- Gateway IP address RS - Set of Resource, RV - Set of Resource visited NR - Set of iproutnexthop, retrieved by snmpget. loadmibfornode(r) RS = RS.push(R) Run loop on each element of RS R=RS.pop If (!RV.contains(R)) RV.add(R) NR=getNextHop(R) Run loop on each element of NR R NR =NR.next() If(getSynonymGroupElement(RNR)==NULL) RS=RS.add(R NR ) loadmibfornode(r NR, C) 알고리즘 2 에서는알고리즘 1 에서이미탐색된장비들의 ipnettomediatable 을이용하여더많은리소스 (R) 를찾는다. ipnettomediatable 은도달가능한장비들의리스트를제공하는캐시역할을한다. Algorithm 2: findresourcefromnettomedia() 알고리즘 3 은알고리즘 1 과 2 로부터호출된다. 이알고리즘은데이터베이스로부터장비 R 에관련된 system, iftable, iproutetable, ipaddrtable, ipnettomediatable, vtpvlanstate, dot1dbridge 과같은모든 MIB 정보를불러온다. IP 주소, forwarding info, sysservice, sysdesc 와같은장비의일반적인정보는데이터베이스의 IPTable 에저장된다. Next hop 에대한정보는 RouteTable 에저장되고다중 subnet 을위한다중 IP 주소를가진라우터나스위치의다중주소정보는 AddressTable 에저장된다. 스위치나라우터의 port 정보와같은인터페이스정보는 InterfaceTable 에저장된다. 장비들간의연결정보를탐색할때에는 Bridge MIB 을지원하는장비들간의인터페이스연결정보역시탐색하게된다. 각노드로부터도달가능한장비들의리스트는 NetToMediaTable 에저장되며, 이는 IP 주소와같은물리적인주소로대응된다. 모든 L2 장비의 Bridge MIB 정보는 BridgeMibTable 에저장된다. VlanTable 은선택적인테이블이다. 만약네트워크가 Cisco 사가아닌다른장비들로구성되었다면, VLAN 및 VLAN 과관련된확장트리를계산하는데이테이블을사용할수있다. Algorithm 3: loadmibfornode (R, C) R is the newly discovered device C is community String If R does not exist in Database database.store (SNMPLoadMIBforIPtable ()) database.store (SNMPLoadMIBforRoutTable ()) database.store (SNMPLoadMIBforAddressTable ()) database.store (SNMPLoadMIBforInterfaceTable ()) database.store (SNMPLoadMIBforNetToMediaTable () ) database.store (SNMPLoadBridgeMib ()) database.store (SNMPLoadVlan ()) 3.3.2. 다중 IP 장비탐색새로운장비를탐색할때, 어떤장비는그것이속한다중 subnet 과연관된다중 IP 주소를가질수있다. 그러한장비의다중 IP 주소는 AddressTable 에저장되며, 이러한정보를얻기위해 ipaddrtable 라는 MIB 정보가사용된다. 새로운 IP 주소가탐색되었을때, 이미탐색된장비가다른 IP 주소를가지고있을수있는데, 이러한상태를확인하기위해서알고리즘 1 과 2 의 getsynonymgroupelement 라는함수를호출한다. 이함수는새롭게탐색된 IP 주소가없을경우
null 값을리턴한다. 3.3.3. Discover Device Type 이모듈은네트워크내의장비들의타입을탐색한다. 여기서는 sysservice MIB object 를사용하여이것을 7bit 의 string 으로변환한다. 각각의 bit 는 OSI 7 네트워크모델의 7 가지계층으로대응된다. 예를들어어떤장비가 sysservices 값이 78(1001110) 이라고할때, 2 번째 /3 번째 /4 번째 /7 번째 bit 이 1 로셋팅되게됨으로이장비는이러한 4 가지계층의서비스를제공하는 L7 스위치임을의미한다. 이러한알고리즘은데이터베이스내에저장된 dot1dbridge, iftable, Printer MIB 정보에도사용된다. 이방법은장비가 Layer 2 에서 port to port 연결정보를지원하는지확인하기위해서사용된다. 이러한장비들은스위치로분류된다. Iftable MIB 정보는 L3 장비가다중인터페이스에서동일한 MAC 주소를가지도록구성되어있는지결정하는데사용되고, Printer MIB 은해당장비가프린터인지를확인하는데사용된다. 3.3.4. Discover Connectivity 이장에서는데이터베이스에저장된 MIB 정보를사용하여연결정보를탐색하는알고리즘에대하여설명한다. 알고리즘 4 는 Layer 2 장비들간의연결정보를계산한다. 이알고리즘을통해찾아낸연결정보는 ConnectivityTable 에저장된다. InterfaceTable 로부터대응하는인터페이스의 MAC 주소를얻을수있으며, ConnectivityTable 의인터페이스와인터페이스간의대응을저장한다. 이것은순전히 L2 장비에서 L2 장비로의연결탐색알고리즘이다. Algorithm 4: findconnectionbetweenswitchtoswitchs Set of L2 and L3, L4 and L7 switches with Bridge MIB support SV- Switches Visited I i List of Interface for Switch S i For each pair of the Switches S i and S j For each pair of I im and I jn If BridgeMIB of S i and S j has the physical address I im and I jn of each other Set the connectivity between S i and S j for Interface I im and I jn Store the connectivity information in ConnectivityTable 알고리즘 5 는 L2 장비와 L3 장비간의연결정보를계산한다. L3 장비는 sysservice 에서 Layer3 을지원하며, Bridge MIB 은제공하지않고다중인터페이스를위해동일한 MAC 주소를가지도록구성된다. L3 장비에대해서는 Bridge MIB 을갖고있지않기때문에 L2 장비로부터 L3 장비로의인터페이스 ( 포트 ) 연결정보는저장하지만, L3 장비로부터 L2 장비로의인터페이스연결정보는 저장할수없다. Algorithm 5: findconnectionbetweenswitchtorouter S Set of Switch I S List of Interface of Switch S R List of Routers RM List of Mac address of Router R For each S Find I S of S for which the mapping was not found. For each I S For each R If RM is found in BridgeMIB of I S Set the connectivity between R and S for Interface I S 알고리즘 6 은 L3 장비와 L3 장비간의연결정보를탐색하는알고리즘이다. 여기서는 ConnectivityTable 의인터페이스와인터페이스간의연결 ( 포트연결 ) 정보없이연결정보를저장한다. Algorithm 6: findconnectionbetweenroutertorouter R - List of Routers For each pair of Router R I and R J Check if the connectivity information exists in ConnectivityTable If connectivity does not exist. Check the NextHopTable to get the connectivity Set the connectivity between R I and R J 알고리즘 7 은스위치, 라우터이외의터미널장비들의연결정보를탐색하는알고리즘이며 ipnettomediatable MIB 으로부터입력을받은 NetToMediaTable 을이용한다. 여기서얻은연결정보는인터페이스와인터페이스간의연결정보와같은 L2 정보를가지지않는다. 이연결정보는 ConnectivityTable 에저장된다. 알고리즘 4, 5, 6, 7 이모두실행되고난뒤, 사용자에게네트워크연결뷰를제공하기위해그래프를만드는데사용되는최종 ConnectivityTable 을얻을수있다. 그래프를만드는데사용된방법은 4.1 장에서설명한다. Algorithm 7: findconnectionbetweenotherdevicewithswitchandrouter A - All devices in ConnectivityTable i.e. the devices already visited A Set of all the Devices not in ConnectivityTable Retrieve subnet of the devices in A Create subsets A S1, A S2, A S3 based on the subnet id. For each subnet S I Create mapping of the devices in A SI with the Switch A J Store the mapping information in ConnectivityTable. 3.3.5. Discover Subnet 특정 IP 주소의 subnet 을계산하기위해데이터베이스의 AddressTable 에저장된 ipadentnetmask MIB 정보를이용한다. 예를들어 192.168.5.10 과같은장비의 IP 주소와 ipadentnetmask 로부터 255.255.255.0 과같은 subnet
mask를가지고있다면, IP 주소와 subnet mask를 bit wise AND 연산을 통해 네트워크 주소 (subnet 주소 ) 인 192.168.5.0를얻을수있다. 이방법을 통해모든장비의 subnet 주소를찾을수있다. 일단모든장비의 subnet 주소를찾은후, 일치하는 subnet끼리 분류할 수 있다. 그리고나서 이 장비들간의연결정보를찾고, subnet 구성도를 보여줄수있다. Subnet 내부의연결정보를찾기 위하여한개이상의 subnet에속하는장비들을 걸러내면 subnet 내부연결정보를찾게되고, 네트워크 구성도에 보여줄 수 있다. 그러므로 이러한 단계의 추상화는 사용자로 하여금 네트워크에 대한 subnet 기반의 논리적 뷰를 제공한다. 3.3.6. Discover VLAN 각각의 VLAN 은 VLAN identifier 로구분된다. 네트워크가 VLAN 을지원하고패킷들이그네트워크로전달된다면, VLAN identifier 태그가패킷에붙게된다. VLAN 을인지하는브리지는 VLAN 태그가달린프레임을인식하고, 해당패킷을정확하게전달한다. 각각의 VLAN 은그들만의 spanning tree 를가질수있거나, 제조사의구현방법에따른모든 VLAN 과연관된 single spanning tree 가질수있다. Cisco 사는다중 VLAN 을위한다중 spanning tree 를지원한다. 본논문에서는비록표준 MIB 에기반하는 VLAN 을지원하는 vendor neutral solution 과함께 Cisco 장비의 VLAN 연결정보를찾는방법을제시한다. Cisco 스위치의 VLAN 을찾는것은 community string indexing[7] 에근거한다. 각각의 VLAN 에대하여세분화된인스턴스를갖는 MIB 정보에접근하기위하여 community string indexing 을사용한다. 그다음해당스위치에유효한특정 VLAN 을찾는다. CISCO-VTP-MIB[14] 으로부터 vtpvlanstate object 를사용하는스위치의유효한 VLAN 을찾을수있다. vtpvlanname 이나다른 object 대신에 vtpvlanstate object 를사용하는이유는한번의 SNMP 동작으로유효한 VLAN 의 index number 를결정할수있기때문이다. 각각의 VLAN 에서 community string indexing 을사용하거나, dot1dtpfdbaddress MIB 정보를가지고 SNMP 쿼리를하여 community name 의 suffix 에 @vlanid 를더함으로써 dot1dtpfdbaddress 로부터 MAC 주소를얻을수있다. 각각의 VLAN 에대해 Bridge MIB 을찾아낸후 VLAN 의장비들의 spanning tree 를만들고, 네트워크구성도에서이를 tree 뷰로보여준다. 만약장비가 Cisco 사설 MIB 을지원하지않을경우에모든 VLAN 에연관된하나의 spanning tree 가있는 IETF 의표준 MIB 에기반하는해결책을제시한다. 이를위해 BRIDGE-MIB(RFC 1493)[12] 과 Q-BRIDGE-MIB(RFC 2674)[13] 을사용한다. 먼저, 탐색하고자하는범위를결정하고, 범위내에서 3.3.1 장에서설명한 nexthop 메커니즘을사용하는 IP 주소와같은 Virtual Bridge LAN 을목표로한다. 다음으로장비의타입을결정하고, L2 와 L3 장비의 Bridge MIB 정보를가져온다. STP(spanning tree protocol) 정보는 BRIDGE-MIB 의 dot1dstpporttable 에저장된다. 각행의 dot1dstpporttable 변수를체크하고, port 상태가비활성화된엔트리는제외시킨다. 또한 dot1qportvlantable 의연관된엔트리로부터 dot1qpvid 를가져옴으로써선택된 port 와관련된 VLAN 을추려낸다. 이렇게얻은정보들로, 각각의 VLAN identifier 와 port identifier 의조합에서내부테이블인 VLANTable 을만들어낼수있다. 또한 Bridge 주소, port identifier, VLAN identifier, 지정된 root, 지정된 bridge, 지정된 port 와같은정보를저장하여 VLAN spanning tree 를생성하는데사용한다. 알고리즘 8 에서는 VLAN spanning tree 를생성하는방법을설명한다. VLAN spanning tree 를생성하기위해서는 VLAN 의그룹엔트리를현재의엔트리로선택하고, bridge 주소와현재엔트리의지정된 bridge 주소가일치하지않을경우, 이 bridge 주소를 spanning tree 의지정된 bridge 의 child 로한다. 그리고이엔트리의 port id 를이 bridge 의 exit port 로표시하고, 지정된 bridge 의 port id 를지정된 bridge 의 entry port 로표시한다. 만약 bridge 주소와현재엔트리의지정된 bridge 주소가일치할경우 next unvisited 엔트리를현재의엔트리로선택한다. Spanning tree 는 VLAN identifier 의모든엔트리를방문하게되면생성된다. Algorithm 8: CunstructSpanningTreeForVlan V - vlan identifier VS - Set of entries from VLAN table for each vlan V T - tree type data structure. The nodes of the tree is an entry of VS For each entry in VS If the bridge address and the designated bridge address of the current entry are not same Set the bridge address as the child of the designated bridge address of the spanning tree T Mark the interface id of this entry as the exit port on this bridge Mark the designated bridge port id as the entry port of the designated bridge 4. 구현 개발환경으로하드웨어는 CPU 2.80GHz Intel Pentium 4, 512MB RAM 을사용하였으며, 소프트웨어는 MS Windows XP 운영체제하에 JAVA 1.5 버전과 tomcat 5.5 웹서버를사용하였으며, 데이터저장을위하여 Oracle 데이터베이스 10g Express Edition 을사용하였다. SNMP library 로는 AdventNet Java APIs[10] 를사용하였으며, 네트워크구성도를그래프형태로보여주기위하여수학적인그래프객체를제공하는공개 Java graph library 인
JgraphT[6] 를사용하여구현하였다. 4.1. Network MAP View 이장에서는본논문에서제안하는시스템의결과출력방식에대하여자세히논한다. 이시스템에서는 List View, Tree View, Graph View, VLAN View 의네가지메인메뉴를제공한다. Tree View 와 Graph View 는각각 Device View, All Device View, Subnet View 의세가지서브메뉴를갖는다. 또한 VLAN View 는 Switch VLAN, VLAN Switch 의두가지서브메뉴를갖는다. List View 에서는탐색된장비들을라우터, 스위치, 프린터, 노드등의카테고리리스트형태로보여준다. 리스트내의각장비를클릭하면해당장비의세부속성에대한내용을볼수있다. Graph View 와 Tree View 에서는네트워크의장비들과연결정보를 Graph 와 Tree 형태로보여준다. Graph View 는 L3 계층의장비의연결정보를보여주는데사용되고, Tree View 는 L2 계층의장비를보여주는데사용된다. 그림 4 는 subnet 의 Tree View 를보여준다. 각각의장비를더블클릭하면각장비별로 IP 주소, sysservices, 전달정보, system description, 다른네트워크계층지원여부, 장비가속한다중 subnet, 인터페이스세부내용, 인터페이스연결정보등의속성정보들을볼수있다. 가장좌측의프레임은네트워크내의모든 subnet 과 subnet 내의장비의수를리스트형태로표시하며, 중간프레임은 subnet 의장비들사이의연결정보를 Tree 형태로보여준다. 우측의프레임은선택된장비의다양한정보들을보여준다. Subnet View 는 administrator 가네트워크의 subnet 계층의논리적형태를알고자할때유용하다. 그림 5. VLAN View 그림 3. 포항공대네트워크의 Graph/Tree View 그림 3 은 L3 장비의 Graph View 와 L2 장비의 Tree View 를보여준다. 좌측의프레임에는 L3 계층의장비들을 Graph 형태로보여주고있으며, 우측의프레임에는 L2 계층장비의연결정보를 Tree 형태로보여주고있다. 우측그래프의각노드를더블클릭하면각노드에연결된 L2 장비들에대하여 Tree 형태로보여준다. 그림 4. Subnet 의 Tree View 그림 5 는네트워크를 VLAN 별로구분하여보여주는 VLAN View 이다. 가장좌측의프레임은네트워크내의모든 VLAN 을리스트형태로표시하며, 중간프레임은해당 VLAN 에속하는모든장비들을보여준다. 우측의프레임에서는 VLAN 내의장비들간의연결정보를 Tree 형태로보여준다. 5. 테스트및결과 이장에서는본논문에서개발한시스템을포항공과대학교와고려대학교서창캠퍼스의서로다른두엔터프라이즈네트워크에적용하여테스트한결과를분석한다. 먼저고려대학교네트워크에대하여 14 개의라우터, 29 개의스위치, 42 개의 subnet 과 28 개의 VLAN 등총 2019 개의장비를탐색하였다. 포항공과대학교네트워크에대해서도동일하게적용하여 76 개의 L3 스위치, 522 개의 L2 스위치, 8 개의라우터, 5 개의 L4 스위치, 208 개의 subnet, 149 개의 VLAN 등총 7495 개의장비를탐색하였다. 여기서는다중 community string 을이용하여서로다른네트워크조건에서수차례테스트하였다. 표 3 은포항공대의네트워크에대해각기능모듈별로수행시간의결과를나타낸다. 여기서는 1 개의 thread 를사용하였을경우와 10 개의 thread 를
사용하였을경우각각의결과를보여준다. 본논문에서는총소요시간의대부분을 findresourcefromnettomedia 모듈이차지하기때문에이모듈에는 thread 메커니즘을사용하였다. SNMP-GET 요청에대한 Time out 은 5초로지정하였으며, NetToMediaTable로부터라우터와스위치정보를불러와서테이블내의각장비에대해 SNMP-GET메시지를보낼때, 만약해당장비가 SNMP를지원하지않는경우 5초이후에응답을받게되므로결국이과정에서많은시간이소요되었다. 실험에서 findresourcefromnettomediatable 모듈은총 7495 개의장비중 7496개의장비를탐색하였다. Scalability 테스트는 linear한형태를보인다. 탐색되는장비의수가증가할수록장비를탐색하는데걸리는소요시간도선형적으로증가하였다. 이러한경향은그림 7의 POSTECH 표 3. 각모듈별수행시간 테스트결과와그림 7 의고려대테스트결과를통해확인할수있다. 그림 6 에서는총 7000 개의장비를탐색하는데소요되는시간을 100 개의장비단위로기록하였다. 앞서표 1 에서, 본논문에서제안하는시스템과기존의연구에대한비교를하였다. 여기서는기존의테스트결과와본시스템의테스트결과에대해비교한다. 기존연구 [1] 의테스트결과에따르면 SNMP 를이용하였을경우 139 개의라우터, 93 개의 subnet 등총 602 개의장비를탐색하는데 193 분이소요되었으며, DNS zone transfer/traceroute 방식을사용한경우에는 155 개의라우터및 622 개의 subnet 등총 7367 개의장비를탐색하는데 2880 분이소요되었다. 그림 7 에서보여주듯이본논문에서제안하는시스템에서는 598 개의스위치, Function Details Using 1 thread Using 10 threads Time in hours Time in % Time in hours Time in % findresourcewithnexthop Mechanism discovers and load MIB for 40 devices 0:16:21 2.51% 0:16:21 12.54% findresourcefrom NetToMediaTable discovers and load MIB for 7455 devices 10:21:52 95.47% 1:40:52 77.35% FindResourceType calculates resource types for all 7495 devices 0:00:34 0.09% 0:00:34 0.43% CalculateSubnet calculates subnet for all 7495 devices 0:00:40 0.10% 0:00:40 0.51% findconnectionbetween find connections among 522 L2 and 76 L3 SwitchToSwitch switches 0:10:38 1.63% 0:10:38 8.15% findconnectionbetween find connection between 522 L2, 76 L3 SwitchToRouter switches with 8 Routers 0:00:57 0.15% 0:00:57 0.73% findconnectionbetween RouterToRouter find connection among 8 routers 0:00:12 0.03% 0:00:12 0.15% findconnectionbetweenother DeviceWithSwitchAndRouter find the connection of the rest 6889 hosts with the routers and switches 0:00:10 0.03% 0:00:10 0.13% Total time total time taken 10:51:24 100% 2:10:24 100% 8 개의라우터, 5 개의레이어 4 스위치, 208 개의 Subnet, 그리고 149 개의 VLAN 을탐색하는데 100 분이소요되었다. 기존의다른연구 [2] 를보면 243 개의라우터및스위치, 1363 개의노드, 72 개의 subnet 을탐색하는데 42 분이소요되었다. 우리의시스템으로비슷한장비를탐색하는데에는약 60 분가량이소요되었다. 그이유는장비별로다양한속성값을보여주고, VLAN 을계산하고, 장비별타입을찾는것과같은다양한기능들을제공하기위한정보처리시간이소요되기때문이다. 이와비슷하게우리의결과와기존연구 [3] 를비교해보면, 기존의연구에서는최대네트워크크기가단지 2000 개의 host 와 50 개의 bridge 에불과하여 2000 개의노드에대하여연결정보를탐색하는데 25 초의시간이소요되었으며, 50 개의 bridge 에대해서는 25 초의시간이소요된데반해, 우리의시스템에서는표 3 에서알수있듯이 598 개의라우터및스위치를탐색하는데 11 분이채걸리지않았고, 7495 개의장비들간의연결정보를찾는데 30 초의 시간이소요되었다. 라우터와스위치사이의연결정보를찾는시간이조금더소요되는데그이유는우리의시스템에서는인터페이스와인터페이스간의연결정보탐색을하고, 이러한정보를구성도에표시하고자하였기때문이다. 기존의연구 [4] 에서는각각의네트워크에대하여총탐색시간에대해명시하지않았다. 대신에노드탐색하는데걸린시간을그래프로보여주었다. 이알고리즘에따르면최초 25개의장비를탐색하는데 5초가소요되었으며, 더많은장비를탐색할수록소요시간은차츰증가하였다. 본논문에서제안하는알고리즘은장비의수에대해일관된성능을보인다. 기존의연구들은작은네트워크를대상으로하였지만우리는 7495개의장비를탐색할뿐만아니라각노드와링크에대해다양한속성정보들도탐색하였다. 결과적으로본논문에서제안하는시스템이기존의연구 [1, 2, 3, 4] 에비해서더나은기능들을제공하고, 더욱안정적이라할수있을것이다.
Time taken for discovery in minutes Time taken for discovery in minutes 900 800 700 600 500 400 300 200 100 0 0 1000 2000 3000 4000 5000 6000 7000 Num ber of Devices 그림 6. Thread 를적용한 Postech 망탐색 160 140 120 100 80 60 40 20 0 0 500 1000 1657 Number of Devices 그림 7. Thread 를적용한고려대망탐색 6. 결론및향후과제 1 thread 5 threads 10 threads 20 threads 1 thread 5 threads 10 threads 20 threads 그동안자동화된네트워크연결정보탐색에대한많은연구가행해져왔음에도불구하고, 기존의연구들은대부분네트워크뷰에대한논리적이거나물리적인계층의추상화가아닌 ping, spoofed icmp echo 요청등을이용하여단순히네트워크연결구성정보를탐색하는것으로여겨져왔다. 더욱이현재의네트워크에서는 spoofed icmp 패킷은여러가지보안의이유로 block 되어, ping 이네트워크내에서지원되지않는노드들이많이있다. 본논문에서는 L2/L3 계층의구성탐색방법과그것들을어떻게서로혼합하여연결정보를보여줄수방안에대해서도설명하였다. 본논문에서는라우터, L2/L3/L4/L7 스위치, 프린터, host 등다양한타입의장비를탐색하는방법과 Subnet View, List View, Graph View, Tree View, VLAN View 등다양한연결정보를제공함으로써사용자로하여금물리적 / 논리적인뷰를볼수있게하였다. 또한본논문에서는 SNMP 기반의네트워크구성탐색시스템을구현하였으며, 다양한테스트를통하여이시스템이다수의장비들을탐색하는데효율적임을보였다. 향후과제로, 더많은네트워크관리기능을제공하기위하여 network weather map 이나다른네트워크성능 monitoring tool 과우리의시스템을연계하는연구가이루어져야한다. 또한 link capacity 나 mean delay 등더많은연결정보특성을고려하고, 네트워크의증가 패턴을찾는데도움이되는시간의흐름에따른네트워크구성의변화에대한다양한분석이필요할것이다. 6. 참고문헌 [1] R.Siamwalla, R. Sharma, and S. Keshav, Discovering internet topology discovering Internet Topology, http://www.cs.cornell.edu/skeshav/papers/discovery.pdf, July 1998. [2] Yuri Breitbart, Minos Garofalakis, Member, IEEE, Ben Jai, Cliff Martin, Rajeev Rastogi, and Avi Silberschatz Topology Discovery in Heterogeneous IP Networks: The NetInventory System, IEEE/ACM Transactions on networking, vol. 12, no. 3, June 2004, pp. 401~414. [3] B. Lowekamp, D. R. O Hallaron, and T. R. Gross, Topology discovey for large Ethernet networks, in Proc. of ACM SIGCOMM, 2001, pp. 237~248. [4] Fawad Nazir, Tallat Hussain Tarar, Faran Javed Chawla, Hiroki Suguri, Hafiz Farooq Ahmad, Arshad Ali, Constella: A Complete IP Network Topology Discovery Solution, In the Proc. of APNOMS, Oct. 2007, pp. 425-436. [5] How To Get Dynamic CAM Entries (CAM Table) for Catalyst Switches Using SNMP, http://www.cisco.com/warp/public/477/snmp/cam_snmp. html. [6] JGraphT implementation and source code, http://jgrapht.sourceforge.net/. [7] SNMP community String indexing, http://www.cisco.com/warp/public/477/snmp/camsnmp40 367.html. [8] Bierman and K. Jones, Physical topology MIB, IETF, Internet RFC-2922, Sept. 2000. [9] N. Duf_eld, F. L. Presti, V. Paxson, and D. Towsley, Network loss tomography using striped unicast probes, IEEE/ACM Transactions on Networking, vol. 14, no. 4, 2006, pp. 697~710. [10] Advent Net API, http://snmp.adventnet.com/. [11] K. McCloghrie, M. Rose, RFC 1213 - Management Information Base for Network Management of TCP/IPbased internets: MIB-II, March 1991. [12] E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie, RFC 1493-Bridge MIB, July 1993. [13] E. Bell, A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie, RFC 2694 Q- BRIDGE-MIB, August 1999. [14] CISCO-VTP-MIB, http://tools.cisco.com/support/snmp/do/browsemib.do?lo cal=en&mibname=cisco-vtp-mib [15] J. Case, M. Fedor,M. Schoffstall, and J. Davin, A simple network management protocol (SNMP), IETF, Internet RFC-1157, May 1990. [16] D. Passmore, and J. Freeman, The Virtual LAN Technology Report, http://www.3com.com/nsc/200374.html, March 1997. [17] IEEE 802.1Q, IEEE Standard for Local and Metropolitan Area Networks: Virtual Bridge Local Area Networks, 1998. [18] Benoit Donnet, Timur friedman, Internt Topology Discovery: a survey, IEEE Communications Surveys & Tutorials, 4th Quarter, vol. 9, no. 4, 2007, pp.56-69.