티스토리 툴바


'2012/02'에 해당되는 글 2건

  1. 2012/02/22 Being old car mania
  2. 2012/02/09 Cloud Networking (2)

Being old car mania

2012/02/22 22:19 from lifestyle
( younjin.jeong@gmail.com, 정윤진 ) 

많은 사람들은 가슴속에 가지고 싶은 것, 하고 싶은 것 하나쯤은 품고 산다.  돌이라도 씹어 먹을 것 같은 20대의 혈기에는 그에 걸맞는 아름다운 여자친구가 쟁취의 대상이 될 수도 있고, 즐기고 싶으나 금전적, 시간적인 여유가 부족해서 즐기지 못하는 어떠한 취미의 한 종류일 수도 있다. 나의 경우에는 보통 이런 저런 컴퓨팅 시스템의 조합을 통한 새로운 서비스의 디자인과 프로파일링이 그런 것이었는데, 최근에는 부쩍 차에 관심을 가지게 되면서 제목과 같은 부분에 취미가 생겨 버렸다. 

사나이의 로망, 포르쉐

 Image from: http://www.northwestautosalon.com/2010/11/fanatic-detail-paint-correction-leather-restoration-white-porsche-993-carrera-s/

사실 독일차를 새차로 구입하는 것을 보면, 잔고장도 없고 달리기도 좋고 새벽에 y00 속도 영역에서 즐기는 안정감, 80 미만에서의 무리하지 않고도 즐길 수 있는 아름다운 핸들링에 반해서인 경우가 많다. 물론 이 외에도 이성과의 만남을 위해 구입하는 경우도 있기는 하지만, 소개팅 한번 해 보지 않은 나같은 샌님에게는 여자사람을 만나는 것이 하늘의 별따기인 나의 인생과는 무관한 이유이기 때문에 뭐 그런건 접어두고. 

아무튼, 이렇게 저렇게 알아보다 보니 좀 오래되었지만 전자장비가 별로 없고, 뭔가 고쳐가면서, 공부해 가면서 탈 수 있는 재미가 있겠다 싶은 생각에 오래된 명차들에 관심을 가지게 되었다. 알아보다 보니, 이게 썩어도 준치라고 어떤차는 20년이 되어가는 주제에 아직도 몇천만원을 주어도 구하기가 힘들고, 그렇게 구하게 되더라도 수리비로 대체 얼마나 더 들어갈 지 모른다는 것이 매우 큰 난제임을 깨닫게 되었다. 

하지만 개인적으로 항상 주말에 차고에서 차를 조립하곤 하는 영상이 나오는 미국 영화를 보고 상당히 어릴적 부터 뽐뿌를 받아왔던 터라, 더 이상 미루게 되면 언제 한번 해 볼지 못해볼지 모르겠다는 생각에 최근 미친듯한 검색질을 통해, 다음과 같은 워너비 리스트를 만들게 되었다.  


1. Porsche 993. ( air-cooled ) 

Image from: http://www.mulhollandmotorsports.com/

Image from: http://www.mulhollandmotorsports.com/2010/11/10/porcshe-turbo/


Image from :  http://pattgregor.free.fr/index.php?showimage=673  

아시는 분들은 다 아는 포르쉐 993.  공냉식인 덕분에 이제는 해외에서 이사짐으로 들여오는 것도 불가능 하다는데, 그래서 그런지 통 돌아다니는 매물이 별로 없다. 쿨 매물을 찾으려 잠복한지 어언 한달인데, 좀처럼 나타나지 않는 듯. 
게다가 입양을 하려고 결심을 할때 적어도 엔진 및 변속기는 한번 들어내어 오버홀 정도는 고려해 주어야 하고 모든 부싱류 정도는 한번 갈아 줄 작정을 해야 그나마 "탈수 있지 않겠나" 싶다. 

남들이 보면 탈탈 거리는 엔진 소리에 겉멋만 잔뜩 들어보이는 이 오래된 차를 왜 사서 고생하려고 하냐고 하겠지만, 어차피 차라는게 개인적 기호가 크게 좌우되는 것이라 내가 좋다는데 무슨 상관이냐를 외쳐 주고 싶기는 하다. 하지만,  역시 관리가 안된 차들이 많고 그로인해 차 가격의 곱절은 족히 들어야 하고, 문제가 생길 때마다 받는 대단한 스트레스를 생각해 보면 그들의 말이 틀린 것도 아닐테다. 결국 차이는, 그러한 문제들을 해결해 나가는 과정을 즐기느냐 아니느냐 의 차이가 아니겠는가 싶다.  뭐 말은 이렇게 해도 언젠가는 장벽과 마주해 OTL 을 외칠지도 모르는 일. ㅎㅎ 



위의 영상은 공랭식 993 의 아름다운 엔진 사운드를 들려 준다. 하지만, 저 포르쉐는 포르쉐 본사에 의해 관리되는 것이므로, 저런 소리가 똑같이 날 거라고는 별로 기대하지 않는다.

 

오히려 위와 같은 사운드가 나지 않을까 싶은...

아무튼 좋은 차를 구할 수 있다면, 1 순위로 작업 해 보고 싶은 차량.. 


2. BMW E34 530i


Image from: http://www.bmwkatalog.cz/bmw-e34/

Image from: http://bimmerin.net/b5.php

이 두번째 차량은 조금 더 현실적인데, 단종된 년식은 993과 거의 비슷하다. 993 보다 훨씬 많은 ( 그래도 아반테 만큼 많지는 않다 ) 차량들이 존재하며, 국내에 매니아 층도 많고 동호회 활동도 활발하다. 그래도 역시 좋은 물건 구하기는 쉽지 않고, 차주의 사랑을 듬뿍 받은 축복받은 차량은 구하기 쉽지 않다. 

포르쉐와 마찬가지로 순정으로 복원하고자 한다면 얼마든지 정품을 구할 수 있으나, 가격이 만만치 않아 보인다. 시세는 보통 상태와 년식, 그리고 마일리지에 따라 500~1500 정도에 분포하는 것 같은데 일단 가져오면 역시 각종 부싱류 교환 및 오일 교환, 엔진 및 미션 정도는 작업한다고 미리 생각하는게 속이 편할 듯. 

게다가 이 차에 사용된 E60 엔진은 540과 함께 공유된 엔진을 사용하는데, Nikasil 이라 불리는 문제를 가지고 있는 차량이 많을 듯 하다. 이 문제는 품질이 떨어지는 연료, 즉 황이 많이 포함된 연료를 사용하는 경우 이 황이 실린더 벽을 갉아 여러가지 엔진 트러블을 야기하는 나름 유명한 문제로, 심한 경우 엔진 스왑을 각오해야 할 정도의 크리티컬한 문제이다. 다른 사이트에도 많이 이야기가 되었지만, 아무튼 차의 연식과 가격을 고려할 때 여러 주인이 사용한 히스토리 없는 E34 를 들일 경우 차 전체를 오버홀 해야 하는 극악 스런 문제가 발생할 수 있으므로 매우 주의해야 할 듯 하다. 아마 이러한 연료 문제가 없는 독일로 부터 엔진을 공수해 올 생각도 해야하지 않겠나, 뭐 그런 생각이 든다. 이 Nikasil 문제는 위키피디아에도 소개되었다.
 http://en.wikipedia.org/wiki/BMW_M60#The_Nikasil_problem




3. E39 530iS ( 1996 - 2003 ) 

Image from: http://forums.bimmerforums.com/forum/showthread.php?t=566720&page=2

얘는 E39 540i

Image From: http://forums.bimmerforums.com/forum/showthread.php?t=566720&page=2

E39 540

Image From: http://forums.bimmerforums.com/forum/showthread.php?t=566720&page=2

E39 540

Image From: http://forums.bimmerforums.com/forum/showthread.php?t=566720&page=2

Image From: http://forums.bimmerforums.com/forum/showthread.php?t=566720&page=2


아마도 위의 두대의 차량보다는 가장 현실적인 차가 아닐까 싶다. 이 차종의 경우에는 그래도 아직 국내에 매물이 많고, 감가상각이 진행 될 대로 되어서 매물을 구하는건 크게 어렵지 않다. 하지만 역시 문제는 차의 상태인데, 위의 사진은 거의 신품이라고 해도 믿을 정도의 극상의 상태로 볼 수 있다.  엔진과 미션 상태, 그리고 잘 정리된 정비 기록만 가지고 있는 차량을 구해서 실내 복원을 저렇게 해 보고 싶다. 

더군다나, 이 차량은 국내에서도 엄청나게 팔린 차종인 데다가 트러블이 발생과 처리에 대해 경험을 가진 미케닉이 많고, 힘들 경우 비싸긴 하지만 그나마 독일 차 중에 가장 잘 정비된 BMW 의 서비스를 이용하는 것이 가능하다. 따라서, E34 와 같이 오래된 차종 보다스크가 좀 덜하기 때문에, 복원 경험을 쌓기 좋은 최선의 선택이 아닐까 한다. 

주말에는 패밀리 세단으로, 주중에는 이른 아침 출근길과 늦은 퇴근을 고속도로로 즐기는 재미를 양껏 안겨줄 수 있지 않겠는가. 

국내에 잘 알려진 카 매니아 사이트 팀 테스트 드라이브의 마스터 권영주님도 작년에 한대 장만 하셨나 보다. 아래의 링크에서 글을 읽어 볼 수 있다. 
http://www.testdrive.or.kr/index.php?mid=boards&page=1&document_srl=1253338

뭐 사실, 저렴한 국산차 사서 마음껏 가지고 다녀도 괜찮긴 하지만, 성격상 기계나 컴퓨팅이나 인과 관계 분석을 통한 문제점 파악과 해결, 뭐 그런 일을 업으로 삼다보니 경제적인 능력만 충분하다면 언제든지 도전해 보고 싶은 것이 바로 이 차량 복원이다. 

돈없어서 타는 구닥다리 차가 아니라, 요즘에 이런 20년 즈음 되어가는 년식의 차량을 공도에서 가지고 다니는 분들이야 말로 진정 갑부가 아닌가 한다. 단순히 유지에만도 적지않은 비용과, 그 비용을 넘어선 관심이 필요한 시기의 차량이기 때문에, 기왕 탈거 그냥 차를 타는 재미만 말고 관리하는 방법, 고쳐가는 방법을 차곡차곡 배운다는 생각, 그리고 취미로 삼으면 이보다 더 좋은게 있을까 싶다. 


이보다 재미있고 돈 덜 드는 일이 많을텐데, 어쩌다가 이런 고약한 것에 마음을 빼앗기게 되었는지 모를일이다. 
아마 조만간, 저 세 대중 한대는 우리집 앞에 오일을 흘리며 주차되어있지 않을까 상상해 본다. 

( younjin.jeong@gmail.com, 정윤진 ) 
저작자 표시 비영리
Posted by YZ Cerberos 트랙백 0 : 댓글 0

Cloud Networking

2012/02/09 21:10 from System/Networks
( younjin.jeong@gmail.com, 정윤진 )


네트워킹에 대한 글은 참 오랜만에 써 보는 것 같다. 사실 그다지 잘 아는 분야도 아니거니와, 일반적인 L3 ip networking 이 거의 대부분의 사용성을 지배하는 한국에서는 너무 당연한 이야기들이 많아서 쓸 것이 없어 그랬지 않았나 싶기도 하다.

오늘 잠깐 생각해 볼 주제는, 클라우드 네트워킹에서 가장 중요한 '확장성'을 고려하게 될 때, 과연 어떻게 망을 구성해야 효과적일까 하는 것이다. 모두들 넌블러킹 스위칭에 대해서 이야기 하고 있지만, 실제 그 넌블러킹의 정체가 무언지, 또 그렇다면 어떤 장비를 어떻게 엮어야 그런 확장성을 이루어 낼 수 있는지에 대해서 디테일하게 이야기 해 보기란 쉽지 않은 일일것이다.

일반적으로 구성하는 ipSAN 또는 스토리지간 연결을 위한 내부 폐쇠망의 구성을 하는데 있어, 최소한 랙 500 대 이상을 확장 할 수 있어야 한다 라는 요구사항이 있을때, 이 구간의 연결 및 IP 정책을 어떻게 만들어 낼 것인가가 아마도 최대의 고민이 될 수 있을 것이다. 경력있는 네트워크 엔지니어는 이러한 경우 내부망을 위한 전용 백본을 구성하고, 이 백본에서 하위 Aggregation 스위치로 MLAG, 다시 ToR ( Top of Rack ) 스위치로의 MLAG 구성을 만드는 것이 일반적인 구성이 될 수 있겠다. 


MLAG ( Multi-chassis Link Aggregation )

 
Image from:  http://www.computer-room-design.com/Arista-Networks-7500-Series-Data-Center-Switch.asp 

흔히 MLAG 이라 불리는 이러한 기술은, 여러대의 스위치를 한대의 스위치로 묶어 L2 레벨의 사용성을 보장한다. 이러한 구성은 최근의 대부분의 벤더가 지원하지만, 특정 벤더별로 상위 스위치로 연결된 2 또는 그 이상의 trunk 된 회선을 동시에 사용하는 이른바 Multi-path 를 지원하거나 지원하지 않는 제품들이 있다. 또한, 이렇게 사용하게 될 때 보통 각 랙별로 별도의 분리된 네트워크를 사용하고자 하는 경우가 많은데, 이럴때 각 ToR 을 위한 VLAN 구성을 추가하게 된다면 이제 각 VLAN 별로 게이트웨이가 되는 IP 를 할당해 주어야 할 텐데, 여기서 또 한번 할당 할 수 있는 IP 수량에 대한 제약 사항이 발생하게 된다.   

이와는 별도로 ToR 의 이중화 구성에 대해서 궁금해 하시는 분들도 있겠지만, 현대의 대부분의 클라우드 시스템들은 랙 하나의 장애에 크게 구애받지 않는다. 따라서 Aggregation 또는 백본의 장애에 대해서만 MLAG 을 구현하고, ToR 은 랙 별로 하나만 두기 때문에 위의 그림에서는 ToR 스위치가 한대다. 물론, 비용을 보다 많이 사용 할 수 있다면 모든 구성에 이중화가 가능하겠다.

아무튼 원래 주제인 MLAG 으로 돌아가서, ToR 에서는 L2, Aggregation 에서 L3 를 구현하는 이러한 방법은 여러모로 확장에 제한을 받게 된다. 물론 이러한 확장의 제한이라는 것이, 보통 샤시 레벨의 제품군을 사용하게 된다면 수백개의 포트 단위까지는 충분히 허용이 가능하므로, 구성하려는 시스템의 규모에 따라 제약사항이 되지 않을 가능성이 있다. 아니, 지금까지는 보통 그래왔다.

게다가 샤시 레벨의 제품을 사용하지 않는 경우에도, Aggregation 의 구성에 Tier 를 적용함으로서 48포트 X 48포트의 구성을 하는 것도 가능하다. 최근의 몇몇 벤더에서는 업링크에 40G 를 지원하는 제품도 있으므로, 이러한 구성시 보다 여유로울 수 있겠다.

얼마 전 까지만 해도 나 역시 이러한 구성이 거의 유일한 해법이며, 넌블러킹 구성에 있어 이보다 좋은 다른 대안이 없는 것으로 생각하고 있었다. MLAG 구성에서 Multi-path 를 지원 할 수 있다면, 현존하는 가장 좋은 내부망 확장 방법이라고 생각 했었다.

 
하지만 최근, 일본의 Midokura ( www.midokura.com )의 Dan 과 Ryu 와 함께 일하게 되면서 새로 배운 것이 있는데, 바로 내부망에 라우팅 프로토콜인 BGP 를 사용하는 방법이다. 

사실 국내에서 네트워크 전문가가 아니라면 생소한 이 프로토콜은, 보통 AS라 불리는 별도의 망 단위간 네트워크에서 라우팅을 위해 사용된다. 국내에서 생소한 이유는, 보통 이 AS가 데이터센터에 입주한 고객에게 별도로 할당되는 경우가 매우 드물고, 따라서 고객이 데이터센터의 ISP 와의 연결에 Static 라우팅을 사용하는 경우가 대부분이기 때문이다. 실제 수년간 필드에서 잔뼈가 굵으신 엔지니어 분들 께서도 BGP 구성에 직접 참여하게 되면 먼지쌓인 책을 다시 살펴봐야 하는 경우가 허다 했다. 

어쨌든 이는 라우팅 프로토콜이기 때문에, 라우터 A 에서 라우터 Z 로 가기 위한 여러개의 경로를 동적으로 할당하는 것이 가능해 진다. 물론 이러한 목적을 위해 BGP 만 존재하는 것은 아니며, RIP, OSPF 등의 수많은 프로토콜이 존재한다. 그런데 왜 여기서 갑자기 BGP를 꺼내들었는가. 그 이유를 살펴 보자. 


1. 최근 데이터 센터 구성에 사용하는 24-48 포트 10G 스위치는 L3 기반인 경우가 많고, 이 L3 스위치들은 BGP 운용이 가능하다. 바꾸어 말하면, 10G 24-48 포트 라우터로 사용 할 수 있다.  

2. iBGP 를 사용하여 Backbone / Aggregation 을 클라우드 망으로 구성할 수 있다. 무슨 이야기인고 하니, 모든 스위치가 라우터로 동작 하므로, 어느 한 지점의 장애에 구애 받지 않게 된다.

3. ECMP 를 사용하여 수없이 발생하게 될 경로에 대한 최대한의 대역폭 사용이 가능해 진다.

4. 장애가 발생한 경우 그 전파가 매우 빠르고, 전체 망이 한꺼번에 다운될 확률이 낮아진다.

5. 각 랙에서 발생하는 L2 통신은 랙 내부로 고립되고, 이 랙에서 돌리는 각 VM의 상태가 백본 레벨로 전달 될 염려가 없다. 랙 장애는 랙 장애에 국한된다.

6. 일단 백본이 구성되고 나면, 어느 경로에든 ToR 을 원하는 형태로 가져다 붙일 수 있다.  따라서 진정한 Scale-out 이 사용 가능한 IP 대역이 떨어질 때 까지 확장 가능하다. 

위의 장점 이외에도, 다른 수많은 장점이 있을 수 있다고 본다. 물론 굳이 iBGP 가 아니라, 각 랙에 사설 AS 를 할당하여 백본과 eBGP를 구성하는 방법도 있을 수 있다. 어떠한 구성의 방법이 더 좋은지의 여부는 네트워크 벤더별로 다를 수 있으며, 경우에 따라 ECMP 를 원활하게 지원하지 않는 경우도 있으니 확인을 꼭 해 볼일이다. 


현재 일을 하고 있는 회사에서 국내에 Arista 를 배포하고 있어, 장비를 가져다가 테스트 해 볼 수 있었다.
테스트 환경은,

- Arista 7124SX   5대
- 일반 Quanta 서버 3대

였으며, 테스트를 위한 컨셉은 다음과 같다. 

iBGP Test Concept



그림은, 각 랙은 서로 다른 24bit 의 네트워크를 가지며, ToR 을 지나는 순간 iBGP 를 사용하여 다른 랙으로 라우팅 된다. 이때 ToR 회서는 각각의 백본에 연결되며, 이 서로 다른 라우팅 Path 에 모두 ECMP 를 적용하게 된다. 

컨셉이 이렇다면, 실제 백본의 할당은 다음과 같다. 

IP Allocation


 
172 네트워크는 관리를 위한 별도의 망이며, 구성된 모든 장치에 연결되어 있다. 실제 트래픽은 푸른색의 회선을 통해 실리게 된다. 이렇게 환경에 대한 구성이 끝났다면, 이제 실제 각 스위치를 설정한다. 

백본은 백본끼리 서로 동일하며, ToR 설정은 각각 모두 동일하기 때문에 샘플로 하나씩만 싣도록 한다.

먼저, Backbone #1 의 설정
....
...
..
interface Ethernet1
   no switchport
   ip address 10.100.100.18/30
!
interface Ethernet2
!
interface Ethernet3
....
..
!
interface Ethernet22
!
interface Ethernet23
   no switchport
   ip address 10.100.100.1/30
!
interface Ethernet24
   no switchport
   ip address 10.100.100.5/30
!
interface Management1
   ip address 172.17.17.91/24
!
ip route 0.0.0.0/0 Null0 255
!
ip routing
!
router bgp 100
   bgp log-neighbor-changes
   neighbor 10.100.100.2 remote-as 100
   neighbor 10.100.100.2 update-source Ethernet23
   neighbor 10.100.100.2 maximum-routes 12000 
   neighbor 10.100.100.6 remote-as 100
   neighbor 10.100.100.6 update-source Ethernet24
   neighbor 10.100.100.6 maximum-routes 12000 
   neighbor 10.100.100.17 remote-as 100
   neighbor 10.100.100.17 update-source Ethernet1
   neighbor 10.100.100.17 maximum-routes 12000 
   network 0.0.0.0/0
!
management telnet
   no shutdown
!
!
end

이제, ToR #1 의 설정을 살펴보자.
.....
...
.
vlan 10
!
interface Port-Channel10
   switchport access vlan 10
!
interface Ethernet1
   switchport access vlan 10
   channel-group 10 mode active
!
interface Ethernet2
   switchport access vlan 10
   channel-group 10 mode active
!
interface Ethernet3
   switchport access vlan 10
!
.....
...
..
!
interface Ethernet22
   switchport access vlan 10
!
interface Ethernet23
   no switchport
   ip address 10.100.100.2/30
!
interface Ethernet24
   no switchport
   ip address 10.100.100.14/30
!
interface Management1
   ip address 172.17.17.93/24
!
interface Vlan10
   ip address 10.1.1.254/24
!
ip routing
!
router bgp 100
   bgp log-neighbor-changes
   timers bgp 30 90
   maximum-paths 2 ecmp 2
   neighbor 10.100.100.1 remote-as 100
   neighbor 10.100.100.1 maximum-routes 12000
   neighbor 10.100.100.13 remote-as 100
   neighbor 10.100.100.13 maximum-routes 12000
   network 10.1.1.0/24
!
management telnet
   no shutdown
!
!
end

이렇게 설정하게 되면, 위의 다이어그램과 같이 원하는 대로 망이 동작하게 된다. 아래의 스크린샷은 각 스위치에 sflow 를 걸어두고, 서버 1대에서 다른 2개의 ToR 로 트래픽을 발생 시켰을 때 볼 수 있는 그림이다.

sflow when 2 paths from single server



네트워킹을 전문으로 하시는 분이라면 위의 null0 라우팅 부분을 의아하게 생각 하실 수 있겠다. 이는 이렇게 구성된 망이 폐쇠망이고 외부로 별도의 경로가 없기 때문에, 모든 ToR 에 default 라우팅을 전파하기 위해 별도로 구성된 설정으로 이해 해 주시면 된다. 또한, 경우에 따라 백본에 neighbor x.x.x.x route-reflect-client 를 구성하여 모든 ToR 에 다른 ToR 의 경로를 전파 할 수도 있겠다. 물론 여기서는 어쨌든 백본으로 모든 트래픽을 보내기 때문에, 백본에서 별도로 RR-client 설정을 넣어 주지는 않았다.

ToR 에서 살펴본 ip routing 정보. 
TOR-1#sh ip route 0.0.0.0/0
Codes: C - connected, S - static, K - kernel, 
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
       R - RIP, A - Aggregate

Gateway of last resort:
 B I    0.0.0.0/0 [200/0] via 10.100.100.1
                          via 10.100.100.13

이러한 스위치가 가지는 장점을 백분 활용함으로서 해 볼 수 있는 것들은 정말로 많이 있다.
기존에는 생각하지 못했던 방법, 보다 스케일링이 가능한 방법. 

네트워크 엔지니어만 알고 있어서 되는게 아니고, 서버 엔지니어라고 해서 네트워크를 모르면 안되는 것과 같은 이치이다. 한 구간만 생각한다면 이러한 룰이 나올 수 있을리 없다고 생각한다. 

최근 클라우드 아키텍팅에서의 트렌드는, 기존의 L2 + L3 구성을 버리고 모두 L3 를 사용하는 방법이다. 위의 설정은 단순히 이러한 구성 및 컨셉을 확인하기 위한 용도에 지나지 않으며, 서비스에 구성하기 위해서는 보다 나은 timer 설정등이 필요하게 될 것이다. 또한, 백본을 다중화 하는 방법도 충분히 실현이 가능하다. 


이 포스팅에 굳이 MLAG 구성의 그림을 넣지 않은 이유는, BGP 의 활용에 대해서 더 살펴보기 위함이었다. 필요하신 분들 께서는 구글에서 MLAG 이라는 검색어만 넣어도 수없이 많이 떠오르는 내용을 보실 수 있을 것이다. 


본 설정을 완료하기 위해 도움을 주신 분들이 계시다. 간단히 소개를 해 보자면, 

Dan Mihai Dumitriu ( CEO/CTO at Midokura )
Nishizawa, Satoshi ( Network expert at Midokura ) 
이정호 차장님 ( Arista Korea )

또한, 고생 해 준 우리 장비들에게도 쌩유. 

Arista 7124SX


 
네트워킹에 고민하고 계신 분들께 조금이나마 도움이 되었으면 하며, 혹시라도 가져가실때는 출처를 남겨 주시길.
조만간 eBGP 도 테스트 해 볼 예정. 

( younjin.jeong@gmail.com, 정윤진 ) 
저작자 표시 비영리
Posted by YZ Cerberos 트랙백 0 : 댓글 2