Bonding시 변경된 eth0의 맥주소에 대해서..

mgfx의 이미지

현재 RHEL4updat3 사용잡니다.
외부 인터넷은 사용하지 않고 내부 네트워크만 이용하기때문에 대역폭증강을 위해 Bonding하려고 합니다..
eth0,eth1를 본딩할경우 본딩에사용할 맥주소를 eth1의 맥주소를 이용하려고 합니다..이유는 내부 네트웍에
eth0과 같은 맥주소가 있어 충돌이납니다 T.T
본딩하면 eth1의 맥주소로 Bond0,eth0,eth1 모두 같은 맥주소를 가지게 돼는데 문제는 eth0의 맥주소가 변경되는데...
이게 단순히 Bond0 때문에 스푸핑같이 임시로변경된건지 실제 eth0의 맥주소가 변경되는건지요?
eth0의 맥주소가 실제변경된거라면 해결방법도 부탁드립니다...

익명 사용자의 이미지

1. 이더넷 본딩은 이미 죽은 기술입니다.
10메가 100메가 랜카드이던 시절,하드웨어 안정성이 떨어지던 시절에 비해 지금은 거의 지나간 기술이죠.
만약 기가비트랜이상이라면 2Gbps 의 출력을 내기위해 시스템은 어디선가 2Gbps 이상의 입력을 받아야 합니다.보통은 디스크이거나 다른 경로의 넷트웍이겠죠.
그럼 단순히 4기가 이상의 커널 메모리 입출력이 보장되어야 힙니다. 그런데 보통은 커널-웹이든 ftp든 사용자응용-커널 과정을 거쳐 적어도 2번의 메모리복사 후 입출력이 진행되죠.게다가 모든 주변장치는 전기적으로 동시가 아니므로 예를들어 디스크를 읽고 있을 때 랜카드는 블락됩니다.
장치간의 스위칭에 소모되는 시간까지 + 하면 소프트웨어적 방법의 집중에 대한 효율은 낮습니다. 10기가 100 기가 시대가 눈앞으로 와 있는 시점에 미래가치가 있는 기술도 아니고요...
게다가 보통 작은 사무실에서 사용하는 저렴한 스위치는 8포트든 16포트든 시스템 버스가 1Gbps 밖에 안되는게 많죠.

2. 랜카드 맥어드레스는 변하지 않습니다.많은 인터넷 문답들이 변한다고 하는것 저도 압니다만 pc 에서 변경하는건 어디까지나 커널에 복사된 사본입니다.원본은 랜카드 비휘발 메모리에 있고 이건 특별한 과정으로만 변경할 수 있습니다.

3. 그럼에도 수많은 인터넷 답변들이 줄기차게 맥주소 바꾼다고 떠드는 이유는
첫째 스위치의 passive mac address learning 이라는 기능의 문제점
둘째 모든 tcp/ip 의 소스며 따라서 모든 os 및 스위칭커널에 기본구현된 RFC 규정 그 중 ARP 프로토콜의 문제점.
셋째 모든 장비 및 pc 에서 맥헤더이후의 프레임 끝까지를 커널이 만들고 이더넷 장치는 이 프레임을 전기클럭에 맞게 재생산할 뿐 데이타 검증은 하지 않는 문제점.

이상 3가지가 짬뽕되어 개나소나 맥주소 변조공격을 시도할 수 있기 때문에 인터넷 답변들이 그모양인 것이지 맥주소가 바뀌는게 아닙니다.
#### 현재 위 3 가지의 문제점에 대해 다양한 해결책이 있고 큰 기술이 아니라서 좀 신경쓰면 걱정 안해도 됩니다.####

4. 현재 랜에 맥주소 같은게 있다고 하셨는데
공장에서 사용하는 프로그램에 문제가 있는 제조상 오류가 아니라면(혹은 하나는 아주 구모델이어서 제조사가 맥주소를 재사용했을 경우는 들어본 적은 없지만 가능성은 있을 수도...) 그 컴퓨터의 커널 맥주소 사본을 누군가 혹은 악성 프로그램이 바꾼겁니다.보통은 윈도우 사용자들이 인터넷 글들을 보고 이것저것 바꾸기도 하므로 그것 자체로 악의가 있다고 단정하지는 마시고 함 살펴 보세요...

김정균의 이미지

gigabit bonding은 아직 10G/100G에 비해서 포트 비용이 월등하게 싸기 때문에 죽은 기술이라고 하기는 좀 그렇죠.

그리고 상황에 따라 10G bonding 환경도 필요할 수 있으니까요.

기술을 '죽었다, 유행이 지났다'고 표현하는 것은 좀 그렇지 않나싶습니다. 상황을 정확히 파악을 하고선 10G나 100G에 대한 것이 메리트가 있다면 권장하는 것이지 상황을 모르는 상태에서 그냥 그 기술은 이미 쓸모없는 기술이야라고 하는 것은 너무 극단적인 표현이 아닌가 싶습니다.

jacojang의 이미지

본딩을 꼭 대역폭 확보의 목적으로만 사용한다고 생각하시나 보군요.
실제로 스위치 이중화를 위한 목적으로 더 많이 사용합니다.

--------------------------------------------------
http://www.jacojang.com

익명 사용자의 이미지

이중화의 목적으로 본딩기술을 더 많이 사용하는게 현실이고 나는 본딩을 대역폭 확보의 목적으로만 보는게 아니냐...
시스코 매뉴얼에 있는 것 말고 이중화의 목적으로 스위치에서 채널본딩이 많이 사용되는 경우를 몇 개라도 예를 제시할 수 있는지요?
저는 국내 ISP 한 곳에 있었던 적이 있었지만 그런 기능이 적용된 경우를 본 적 없습니다.
채널본딩이 지원되는 스위치를 놓을만한,그리고 카탈이나 넥스서 상위기종에 거의 희박한 포트장애빈도에 대한 대비책으로 이중화까지 고려할 정도면 온도,먼지,습도, 자연재해까지 어느정도 고려된 전산실 환경이 선행되어야 하고 UPS 는 물론 자가발전기까지 갇추어진 환경을 그려볼 수 있겠지요.이건 대기업 전산실은 모르겠습니다만 일반적으로 ISP 에 준하는 환경일 것입니다.
사실상 대형장비는 첫째 파워문제가 제일 고려대상이고 그 다음이 온도,습도이며 전자부품 자체의 자연스런 수명단축현상으로 장비자체에 장애가 생긴다면 모듈이면 모듈 하나가 통째로, 아니면 슬롯 하나가 먼저 문제가 되지 모듈 내 회로기판에서 특정포트하나가 문제가된다...희박한 경우입니다.거꾸로 얘기하면 우선순위를 먼저 대비하고 그 정도 구축할 환경과 경제적 여건이 되면 스위치 자체를 한 대 더 놓아야지 채널본딩이라는 발상은 너무 작은 옷을 껴입은 거인에 비하고 싶군요.

김정균님의 답변에는 서로 다른 방향을 보는 시각차이니까 반론보다는 내쪽에서 보는 시각에 대해 부연설명을 하는게 낫겠네요.

우선 이 질문을 시작하신 분은 어디선가 이더넷본딩을 보시고 이리저리 만지시다가 여기 올리신걸 것입니다.
리눅스의 이더넷 본딩과 시스코의 채널본딩에 대해 구글링 키워드도 적절히 선택할 만한 상황이 아니라는 얘기죠.
나는 이런 분에게
"당신이 지금 고민하고 있는 이더넷본딩은 현재 광범위하게 사용되는 것도 아니고 앞으로도 그럴 가능성은 적으며 초보자가 그런 문서를 보고 기술을 적용한들 원리를 배울 수 있는게 아니므로 그 시간에 다른걸 먼저 하는게 좋겠군요..."
하는 뜻으로 '죽은 기술' 이라 표현한 것입니다.

어떤 전자공학도가 넷트웍장비에 관심이 있어서 FDDI 나 SONET 관련 문서를 맨 처음 시작하면서 질문을 하면 내가 만약 답변을 한다면
하나는 몇 년 전에 죽었고 하나는 몇 년 후면 죽을 것이므로 그걸 잡고 끙끙댈 시간에 이더넷을 보시요...
라고 말하겠습니다.여기에는 역시 시각차가 존재하겠죠.그러나 무턱대고 이런 표현을 하는게 아니고 현재 isp 망에 sonet 이 많고 라우터에 소넷 모듈이 많이 꽂혀 있는게 현실이지만 이왕 전자공학도가 빛<=>전기 통신의 최신 적용을 공부할 것이라면 미국과 유럽 일부지역에서 sonet 을 대체하고 있는 100기가 이더넷 ieee 문서를 보라고 권하고 싶은거죠.

현재 sonet 모듈앞에 앉은 사람의 질문에 소넷은 죽었다고 한다면 그건 동문서답이 되겠지요 마찬가지로 현재 이더넷 본딩으로 뭔가 서비스를 하고 있는데 에러가 나서 질문을 하는데 거기 대고 이더넷본딩은 죽은기술이라 했다면 문제가 있겠습니다만 질문자는 현재 본딩의 기술적 접근은 거의 없는 상태입니다.
요점은
인터넷에 보면 수많은 정보,문서가 있고 초보자는 그것들의 우선순위를 가려내는게 불가능한데도 불구하고 그 각각의 정보나 문서들이 작성시점에는 스스로 그러한 것을 언급할 수 없고 따라서 누군가는 중요도랄까 우선순위랄까 그런 얘기를 해야 하는데 문서가 혹은 작성자가 가지는 권위로 인해 어려울 때가 있으므로 한사람 정도는
그 문서는 죽었다 라고 해줘야 한다는 거죠.

이더넷 본딩을 볼 시간에 차라리 아무 랜카드나 드라이버 소스나 데이타시트를 보십시요.본딩드라이버는 장치드라이버와 커널사이에 넣는 또 하나의 드라이버에 불과하며 그것조차 정작 본딩관련 문서만 봐서는 속깊은 원리를 알 수 없죠.
ifconfig 명령으로 뭔가 해낸들 몇 일 지나면 하나의 암기사항에 지나지 않습니다.이런 종류의 단답에 매달릴 시간 없어요...

jacojang의 이미지

어느 ISP에 계셨는지 모르겠지만...

제가 말한 스위치 이중화를 잘못 이해 하셨군요...
스위치 내의 포트를 이중화 한다는게 아니라 스위치 자체를 Active - Backup 형태로 이중화 하는것을 말합니다.
대부분의 공공기관이나 대형 서비스에는 스위치및 모든 네트웍 장비를 이중화로 구성해놓습니다. 장애에 대비해서..

이경우 이더넷 포트를 본딩해서 각각의 스위치에 연결합니다.
몇일전에도 이렇게 해서 설치하고 왔는데요...-.-;

--------------------------------------------------
http://www.jacojang.com

익명 사용자의 이미지

ISP 는 현재도 아마 100개 조금 넘는다고 알고 있는데 누구나 다 아는 한통이나 데이콤은 아니고 그중에서 작은데였습니다.
그리고 이미 13년 쯤 지났죠...

세월이 지났고 컴퓨터 손놓고 있습니다만 아직도 그 100 개 중에는 KNIX 와 라인 한개만 달랑 연결된 업체도 많습니다.요즘은 이름이 바뀌었지만 한통이나 데이콤은 초기 국가 기간망 설치 업체였고 ISP 중에 공룡이죠.
예전에는 KNIX 가 아니라 한통이나 데이콤라인과 몇개의 연결을 갖느냐가 이슈였고 당시 시스코 7xxx,카탈6xxx,스리콤 중형 몇대,스리콤 소형 십몇대,임대서버와 사무실컴 백몇십대...그런 환경이었는데 스위치나 라우터장애는 한 건도 없었고 주로 서버장애가 문제죠.

포트이중화나 스위치 이중화나 어느 측면에서 보느냐의 차이지 같은겁니다.
메인 스위치 입장에서 보면 포트 이중화가 되는거고 메인스위치를 빠진 2개의 케이블이 그 다음 중형스위치에서 한개에 같이물리느냐 2개스위치로 따로 물리느냐의 관점에서 따로 물리면 스위치 경로 다중화가 되는거죠.내 입장에서는 같이 물리는 정도까지의 그림에서만 말했지만(그리고 리눅스의 이더넷 본딩에서는 주로 이것이 관심사고 이 경우 대역폭이 주요 관심사이지만)따로 물리는 것까지 얘기하게 되면 필요스위치수 + 이중화 정도 예비스위치가 설치되어야 합니다.

귀하의 말처럼 공공기관같은데는 그렇겠지요.
또 장비와 라인을 통째로 외주로 줘버리는 경우 예산만 맞으면 그 구성은 외주가 알아서 하는것이라 현장을 지킬 수 없은 외주 기사들이야 이런식으로 해놓는게 대비책이 되겠지요.

이것으로도 충분히 내가 요구한 '적용예' 는 되었습니다.
그러나 중소 ISP 조차 라인 한개만 달랑 가지고 있는 상황에서 ISP보다 작은 규모,리눅스의 이더넷본딩이 광범위하게 사용되는 기술인가를 논할만한 그런 곳에서 내부 넷트웍 장비를 이중화하는게 과연 몸에 맞는 선택인가...하는데는 의문이 있습니다.
솔직히 장비 이중화보다 훨씬 중요한 일이 많지만 업체가 잘 몰라서 장비 공급자의 영업전략을 그대로 수용한 경우가 중소업체에는 더 많지 않을까 하는 의문도 역시 있습니다.

이 글을 읽는 다른 사람을 위해 좀 엉뚱한 말을 하자면
내가 장비나 라인 설치기사 또는 설치업체 사장이라면 이렇게 견적을 넣을 것이고 업체에도 강력히 이런걸 권유하겠지만 반대로 내가 중소규모 전산실장이라면 스위치 이중화에 투자하지 않습니다.그 돈으로 데이타 삼중화 사중화에 투자하죠.
전원,냉방장치,방습에 먼저 투자가 되면 스위치장비 자체의 오류는 경우의 수가 적으며 만약 발생하면 24시간 관리자 상주할 경우는 케이블 빼서 딴데 꽂으면 되는 간단한 것이고 상주 관리자도 없는 소박한 곳이라면 장애공지 띄우고 사과하면 되는 것이지만
고객의 데이타유실이나 해킹 등의 보다 더 자주 일어나고 치명적이며 업무량이 많고 수시로 기술적 난이도가 얽히는 장애는 발생하면 99% 종단 서버에서 그것도 대부분 응용에서 발생하므로 나는 스위치의 경로 다중화를 위한 본딩은 우선순위 제외할겁니다.

현실적으로 여러가지 제약사항이 있는 전산실 내부에서 관리자가 보는 것과 장비 설치보수를 하는 사람이 밖에서 보는 것에는 시각차가 클 겁니다.
이 질문이 리눅스에서 이더넷본딩에 대한 작은 시작이었습니다만 내가 일을 너무크게 만든것 같군요.

trim703의 이미지

대기업 전산망 유지보수를 하고 있는 사람의 입장에서 소소하게 반박을 드리자면...

네트웍 삼사중화에 들어가는 투자비용을 데이터 삼사중화로 돌리는 게 낫다고 하셨는데 그 데이터 삼사중화란 것이 '네트웍 삼사중화'가 기반되지 않으면 보장될 수 없는 경우가 상당히 많습니다.전산실 상주 인력이 빈틈없이 모니터링할 수 있다는 전제 하에서도 네트웍 삼사중화를 취하지 않고는 극복이 불가능한 분야로 수 초 내지는 수십초 이내 페일오버를 이뤄내지 않으면 안 되는 분야가 있습니다. 바로 '고가용성(HA)'입니다. Symantec Veritas, SteelEye Lifekeeper, HP MC ServiceGuard, Red Hat Cluster Suite 등등의 소프트웨어들이 잘 알려져 있고 대부분의 이 고가용성 솔루션들은 기본적으로 클러스터 각 노드들에 에이전트 형태의 프로세스를 띄우고 각 노드 간 Heartbeat Check를 이더넷 네트웍을 통해 체크하도록 설계되어 있습니다. 이 핫빗 체크는 HA 노드들이 공통으로 바라보고 있는 데이터 영역의 무결성 보장을 위해 핵심적으로 보호되어야 하는 기능입니다.

고로 님이 펼치시는 논리가 합당하게 적용될 수 있는 영역(본딩이 중요시되지 않아도 되는 영역)은 종단 네트웍(고가용성 구성의 경우 클러스터 노드들이 분포되어 있는 사설 서브넷 전체를 일컬음)에서 데이터 처리가 다 끝나고 그것을 클라이언트로 실어 보내는 경로에 해당하는 '서비스망' 네트웍에 불과합니다. 참고로 그런 서비스망 네트웍 쪽에서만 장애가 발생하면 데이터 무결성은 별 영향을 안 받고 디버깅도 그리 어렵지 않아 일하는 사람의 입장에서는 그다지 피곤하지 않은 상황들이 대부분입니다. 원인이 비교적 빨리 나오니까요. 근데 클러스터 쪽은 장애가 나면 장애 포인트 찾기가 쉽지가 않아서... 핫빗 통신에 문제만 생기면 최악의 경우 클러스터 자체가 붕괴되어 전 노드들을 재기동해야 하는 상황이 연출되기도 합니다. 본딩이 죽은 기술이라는 발상을 떠올릴래야 떠올릴 수가 없네요.

김정균의 이미지

다른 시각이 있다는 것은 참 흥미로운 일이네요.

제가 이해한 바로는 처음 질문을 올린 분은, 서버의 내부 네트워크의 대역폭 확보를 위해서 bonding을 하고 싶다고 질문을 한 것으로 이해르 합니다. 만약 대역폭 증가를 위해 1G 포트를 10G로 변경을 하는 것은 만약 연결되어 있는 switch가 10G를 지원하지 않는다면 10G가 가능한 switch로 변경을 해야 할 것이고, 지원한다고 하더라도 1G 포트 하나 더 사용하는 것보다 10G 포트의 비용이 월등하게 높습니다.

이 환경이라면 2G로 충분한 대역폭을 확보를 할 수가 있다면 10G포트를 사용하는 것보다 1G 포트로 bonding을 하는 것이 월등하게 비용적/시간적/re-design 에 대한 매리트가 있겠죠.

IDC 구간에서야 이제 100G module로 bandwidth 처리를 하려고 하겠지만, 아직 end 단의 network에서는 10G도 보급이 많이 되어 있지 않은 것이 현실입니다.

그리고, 보통 switch 상에서는 bonding이라고 하지 않고 channeling 또는 link aggregation 이라고 하지 않나요? bonding을 unix/linux 계열에서 사용하는 용어로 알고 있었는데.. ^^; (windows는 timming이고..)

elflord의 이미지

익명님 글은 어느정도 이해가 갑니다만 요즘 네트워크 이중화는 특정 대규모 시스템만이 아니라 중규모 이상 시스템에서는 거의 기본이 되어가고 있습니다. 단순 Active-Standby만이 아니라 VSS, 스택등 으로 Active-Active구성으로엔트리만 넘어서서 미디움레인지까지만 가도 요즘 다 지원합니다.

제경우 요 몇년간 시스템 납품하는데 공공 기관 이외에 기업등에도 네트웍기기 2중화를 안한 경우가 오히려 손에 꼽을 정도로 적을 정도입니다. 리눅스 서버측 bonding은 여전히 필수기능이라고 봅니다.


===== ===== ===== ===== =====
그럼 이만 총총...[竹]
http://elflord.egloos.com

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.