이번 포스팅은 ACI Bug Report 관련 내용입니다.

 

지난 포스팅(http://zigispace.net/957) 에 이어서, ACI OS Upgrade 중에 발생할 수 있는 Bug Report(CSCvb94260)입니다.

2.1미만의 버전에서 발생할 수 있다고 하기 때문에 2.1이상의 버전에서 더 상위 버전으로의 Upgrade에는 발생하지 않을 수 있습니다.

 

이 버그에 대한 증상은

 1. APIC 업그레이드 중에 먼저 진행된 APIC은 정상적으로 Upgrade가 완료되었으나, 이후에 업그레이드 되는 APIC의 상태가 75%에서 멈춰있게 됩니다.  이 경우 75%에서 멈춰있는 APIC에서 확인 할 때, 정상적으로 완료된 APIC의 정보가 기존 버전으로 표기

 

 2. 모든 APIC이 정상적으로 업그레이드가 되고, fully fit 상태까지 되었으나 각 장비에서 acidiag로 확인 시에는 local APIC에 대한 버전만 최신 버전이고 다른 APIC은 기존 버전으로 표기

 

상태를 확인해보면, APIC 2번기가 정상적으로 Upgrade된 상태에서 APIC 3번기가 Stuck이 걸려있을 때,

APIC 2번에서는 2번기 상태를 보면 정상적으로 Upgrade가 되어 있고

APIC 3번기에서 2번기를 상태를 보면, 기존 OS이고 time stamp도 정상적으로 업그레이드 된 시간보다 더 이후 시간으로 체크되어 있음.

 

apic2# acidiag avread | egrep "id=2.*version" | cut -d ' ' -f 7-10,20-21
appliance id=2 version=2.2(2k) lm(t):2(2017-07-25T11:24:01.244+10:00)

apic3# acidiag avread | egrep "id=2.*version" | cut -d ' ' -f 7-10,20-21
appliance id=2 version=2.0(2f) lm(t):2(2017-07-25T11:40:02.248+10:00)

 

2.1 이상에서는 해당 버그가 없기 때문에 2.1 미만의 버전에서만 발생합니다.

 

해당 버그가 발현될 경우에는

위의 예의 APIC 3에서 APIC 2의 정보를 정상적으로 가져오지 못한 상태가 되는 데,

APIC 2에서 "acidiag restart mgmt"를 통해서 APIC에 서비스를 재기동하면

APIC 3에서 APIC 2에 대한 정보가 업데이트 되면서, 정상적으로 Upgrade를 진행 할 수 있습니다.

 

 

 

Posted by 네떡지기

이번 포스팅은 Cisco ACI의 Bug Report (CSCvb42851)에 대한 공유입니다.

 

 

ACI 모드의 Spine과 Leaf의 특정 Process(stats_manager)에서의 Memory Leak에 대한 Bug 입니다 .

Memory Leak으로 인한 장비 자체가 Reload되는 Bug 입니다.

 

일시적인 해결 방법으로는 장비를 재기동하는 것으로 일시적으로 해소되지만,

근본적인 원인 해결은 Memory Leak 문제가 해결된 2.1(2g) 이상으로 OS Upgrade가 필요로 합니다.

 

현재 메모리 상태를 확인하기 위해서는 다음과 같이 확인이 가능합니다.

 

ZIGI_leaf1#ps aux| grep stats_manager| grep-v grep
root 8869 2.3 1.6 1884628 263536?Ss 2017 844:25/isan/bin/stats_manager

 

빨간색으로 표기되는 값이 VSZ(Virtual memory SiZe)이고, 파란색으로 표기된 값이 RSS(Resident Set Size)입니다.

VSZ는 프로세스의 가상 메모리의 크기를 나타내면, RSS를 프로세스가 사용하는 물리 메모리 크기를 나타내게 되는 데,

프로세스에서 메모리가 정상적으로 반환되지 않고 Memory Leak이 발생하는 경우에는 VSZ 값이 증가하게 됩니다.

이 값이 4,194,304에 도달하기 전에 장비가 재기동 되기 때문에 해당 메모리 사이즈 근처로 가기 전에 조치를 취해야 합니다.

 

실제 GUI의 Inventory에서 확인 가능한 stats_manager의 값은 RSS에 대한 값이기 때문에 정확한 값을 확인하기 위해서는

CLI에서 확인해야 합니다.

 

그리고, stats_manager의 해당 값으로 가지 않더라도 stats_manager 프로세스에서의 Memory Leak으로 인해서 전체 메모리

사용량이 올라가면서 메모리가 소진되면, Kernel Panic이 발생할 수도 있습니다.

전체 메모리 사용량은 다음과 같이 확인이 가능합니다.

 

ZIGI_leaf1#show system resources
Load average:1 minute:1.34 5 minutes:1.46 15 minutes:1.51
Processes:608 total, 1 running
CPU states:6.9%user, 3.0%kernel, 90.1%idle
Memory usage:24500980K total, 12353268K used, 12147712K free
Current memory status:OK

 

참고로 만약에 이 Bug로 장비가 재기동된 경우에 장비의 reset-reason을 확인하면 다음과 같이 나오게 됩니다.

ZIGI_leaf1#show system reset-reason
***************module reset reason(1)***********
0)At 2018-02-24T 13:00:00.312+09:00
Reason:reset-triggered-due-to-ha-policy-of-reset
Service:stats_manager hap reset
Version:12.0(2h)

 

Posted by 네떡지기

이번 포스팅은 얼마 전에 진행한 네트워크 전문가 따라잡기 커뮤니티에서 진행한 멘토링 행사에서 했던,

무엇이든 물어보세요! 라는 세션에 대한 정리 자료입니다.

사전에 커뮤니티 회원 분들에게 다양한 질문을 받아서 정리하고, 당일 멘토들의 다양한 답변을 정리해 보았습니다.

비슷한 궁금증이 있는 분들에게 조금이나마 도움이 될 수 있었으면 합니다.

 

 

Posted by 네떡지기

 

개인적인 업무상으로 필요로해서 기존에 가지고 있던 자료에서 약간 수정해서 급조해서 만든 명령어 비교 리스트입니다.

후다닥 만든거라서 부족한게 많을 듯 싶지만, 혹시라도 필요하신 분들이 있으실 듯 싶어서 공유합니다. ^^;

추가하면 좋을 부분이라든가 틀린 부분은 가차없이 알려주시면 감사하겠습니다.

 


 

시스코 / 익스트림 / 한드림넷 명령어 리스트

by 네떡지기(http://ThePlmingSpace.tistory.com)

시스코

익스트림

한드림넷

설명

show ver show ver show version

OS 버전

show switch show system system-info

System정보 확인

show run show config show run / write terminal

Configration 표시

show interface show port [no] show interface switchport

포트 정보 확인

show interface status
show interface [if] show port [if] [util/packet] show interface [if]

인터페이스 세부 정보

show arp show iparp show ip arp

arp 정보 표시

show mac-address show fdb show mac-table [IFNAME]

MAC Address를 출력

show vlan show vlan show vlan

VLAN정보 표시

show spanning-tree show vlan show spanning-tree pvstp

spanning-tree 정보 표시

show spanning-tree vlan show "Default" show spanning-tree pvstp

특정 

show ip int brief show vlan show ip int brief

VLAN에 할당된 IP정보 표시

show cdp  show edp show cdp neighbor [detail]

인접 장비 정보 표시

show cdp neighbor [detail] show edp port all [detail]

인접한 장비 정보 표시

show process cpu top show system cpu-load

CPU 정보 표시

show cpu-monitoring
show memory show memory show system memory

Memory 정보 표시

show tech show tech show tech-support 

Show Tech

show log show log show syslog

log 정보 표시

show env fan show fan sh system fan

장비 Fan 정보 표시

show env power show power sh system psu 

장비 Power 정보표시

show env temperature show temperature sh system temperature

장비 온도 표시

writer memory save write [memory]

설정 저장

erase startup unconfigure switch all factory-default

설정 초기화

show inline-power  show inline-power info port [if] show poe

PoE 정보 표시

    show system uptime

시스템 Uptime

 

 

 

시스코_익스트림_한드림넷_명령어리스트.pdf

 

 

Posted by 네떡지기

신규 공인대역을 BGP에 올린 이후에 해외에서도 접속이 되기 위해서는 각 ISP에 해외망 연동을 위한 필터 해제를 해야 한다.

각 해외망 연동을 위해서 보내기 위한 사업자 메일 주소는 다음과 같다.

 

KT : ipnoc@kt.com

LG : infonoc@lguplus.co.kr

SKB : noc@skbroadband.com

 

요청 시에는 간단하게

 

필터를 해제할 대역과 AS번호 정도만 주면 최대 2주이내에 필터가 해제된다.

 

p.s : 기존 LG의 infonoc@lgdacm.com, infonoc@lgtel.co.kr 에서 lguplus.co.kr로 변경되었다.
        기존 KT의 nw@kornet.com 에서 ipnoc@kt.com 으로 변경되었다. (2013.09.09 확인)

 

 

 

※ 각 ISP별 연락처

  - KT : 857-2200

  - LG U+ : 2089-0535

  - SKBB : 6266-6767

 

☆ LG쪽은 기본 정책이 국내연동도 Prefix List로 차단되어 있다고 한다.

    따라서, BGP 올린 후에 LG쪽에 요청해서 Prefix List Filter 해제 요청을 해당 대역에 대해서 해야 국내 연동도 가능.

Posted by 네떡지기

 

오랜만에 포스팅을 위한 글을 작성하게 되었다.

매주 1개씩 작성하려고 했었는 데, 이래 저래 치이다 보니 역시 쉽사리 잘 되지를 않는다.

하지만, 조금이라도 더 정신차려서 공부하는 겸 정리하는 겸 올릴 수 있도록 해야겠다.

 

오늘은 IP SLAEEM을 이용한 작업 예 내용입니다.

 

아래의 왼쪽의 구성도가 본사와 지사 간의 현재 구성인 것을, 신규 장비를 도입하면서 이중화 구성으로 변경을 하기 위해서

오른쪽 구성도와 같이 변경하려고 합니다.

 

 

 

현재의 제약사항과 구성 상황은 아래와 같습니다.

 

  ○ 방화벽 간의 Sync 불가 / VRRP 구성 불가

  ○ L4 구성 불가 (FWLB 불가)

  ○ 현재의 모든 Routing은 Static으로 구성되어 있다.

  ○ 본사 MR, BR에서는 지사에서 오는 HOST에 대해서 NAT를 수행하고,

      방화벽에서는 본사에서 지사로 가는 HOST에 대해 NAT를 수행한다.

 

  이 상태에서 이중화 구성을 어떻게 해야 정상적으로 문제가 되지 않을 수 있을까에 대한 부분이 이 작업에서 필요한 사항이었다.  변경 구성의 1번기 장비들을 Active로, 2번기 장비들을 Standby로 해서 이중화를 구성 했을 때 구간별 장애가 발생하였을 때 정상적으로 감지를 해서 Standby쪽으로 트래픽이 이동해서 정상적인 동작을 할 수 있을까?

 

 방화벽을 기준으로 상단의 본사 MR, BR측과 하단의 본사 R1,R2 측에서 구간 장애를 감시해서 Active쪽의 트래픽을 Standby쪽으로 변경해야 할텐데, 여기서는 상단의 MR, BR측에서만 살펴보려고 합니다.

 (어차피 한 쪽 구성을 하면 나머지도 유사하게 구성을 하면 되겠죠? )

 

우선 문제점을 살펴보면..

 

 

위의 그림과 같이, ① ~ ④ 중에 하나라도 장애가 발생할 경우에, Active로 가는 경로는 사용할 수 없게 됩니다.

따라서,  ① 구간의 문제가 발생하였을 때 본사 R1에서는 이를 감지해서 R2를 통해서 트래픽이 가도록 변경을 해야합니다.

본사 구간에서의 장비 문제 발생은 어차피 본사에서 라우팅을 수동으로 변경하는 등의 삽질(?)을 할 수도 있겠죠? ^^;

(물론 이러한 라우팅 변경은 자동화를 해야합니다. 아래의 본 예제와 유사하게 설정하면 됩니다.)

 

 하지만, 지사에서 보내오는 트래픽 경로는 본사 내부의 Active 경로의 문제 발생을 모르기 때문에 Bandwidth가 높은 본사 MR로 보내게 되고, 본사 MR에서는 해당 트래픽을 본사 R1으로 보낼 수 없기 때문에 정상적인 통신이 안되게 됩니다.

따라서, 지사에서 본사로 오는 경로도 Backup 경로를 통해서 올 수 있도록 자동화 해줘야 합니다.

 

 이제까지는 아래의 설정을 하기 위한 사설이었고, 이제부터 본 포스팅의 진짜 내용입니다.

위의 상황을 맞추기 위해서 아래와 같이 작업을 진행하려고 합니다.

 

  ※ 본사MR에서는 내부 구간(어느 구간이든 상관이 없이) 본사R1까지 가는 경로의 모든 경우의 수)의 장애 발생 시

      지사와 연결된 메인회선(512K) 대신에 백업회선(256K)로 트래픽을 받을 수 있게 해야 합니다

 

 물론 자동으로 감지해서, 경로 변경까지 자동으로 되야 합니다. 그래서 본사 MR에서 IP SLA와 EEM을 사용해서 이를 아래와 같이 구현해 보았습니다.

 

 I

 

ip sla 7

    icmp-echo 10.10.10.1

    delay up 60

ip sla schedule 7 life forever start-time now

 

track 10  ip sla 7 reachability

 

event manager applet TRACK_DOWN

 event track 10 state down

 action 1 syslog msg “Internal Link Fail"

 action 2 cli command "enable"

 action 3 cli command "conf t"

 action 4 cli command "int s0"

 action 5 cli command "shut"

 action 6 syslog msg “External Port Down"

 

event manager applet TRACK_UP

 event track 10 state up

 action 1 syslog msg “Internal Link Success"

 action 2 cli command "enable"

 action 3 cli command "conf t"

 action 4 cli command "int s0"

 action 5 cli command "no shut"

 action 6 syslog msg “External Port UP"

 

 

우선 IP SLA를 이용해서, 본사 R1의 IP까지의 ICMP를 체크하고. 본사MR에서 Active 상의 경로의 끝인 본사 R1의 IP를 체크하여 중간 구간상의 어떤 장애가 발생하더라도 감지를 할 수 있게 됩니다. 한 구간이라도 문제 발생 시에는 어차피 통신이 되지 않기 때문입니다.

 

 그리고 EEM을 이용해서 SLA로 설정한 Track 이벤트를 감지합니다. 만약 10.10.10.1까지의 통신이 안되는 순간이 발생하면, 이를 감지해서 track에서는 Down 이벤트를 발생하게 되고, 다시 정상적으로 통신이 되면 Up 이벤트를 발생하게 됩니다.

 EEM에서는 SLA에서 설정한 Track의 이러한 이벤트로 Active 구간 장애 발생 시, 지사와 연결된 Serial 포트를 강제로 Shutdown 합니다. 그러면 지사에서는 해당 경로로 통신이 안되기 때문에 자연스럽게 백업회선(256K)를 통해서 데이터를 보내오게 됩ㄴ다.  그리고 다시 내부 구간이 복구가 되게 되면, 다시 Serial 포트를 Up시켜야 하지만 문제가 완전히 처리되지 않은 상태에서 Up/Down이 발생하게 되면 해당 포트도 계속 Up/Down이 발생하게 되므로 Up시킬 때는 delay up 60 이라는 옵션을 통해서 60초정도 지연시킨 후에 Up 이벤트를 발생시킵니다.

 

 주저리 주저리 이상한 얘기를 많이 썼지만, 결국 장애가 발생할 수 있는 종단까지의 구간을 주기적으로 점검해서 문제 발생 시에, 반대편 Serial을 Shutdown 시키는 것을 IP SLA와 EEM을 이용해서 자동화하는 부분이었습니다.

 

 다음에는 좀 더 정리된 포스팅을 해야겠다는 생각을 유난히 많이하게 된 이번 포스팅이었습니다.

 

 

 

 

Posted by 네떡지기

이번에 부서에 신입이 들어왔는데.. (네트워크 파트는 아닙니다만.. )
파트별로 교육시키는게 있어서.... 만든 자료입니다.
네트워크 파트가 아니어서 간략하게 만들어보았습니다.
9일중에.. 제가 맡은 2일중에 하루짜리..자료입니다.

Posted by 네떡지기
Virtual Host 
   - 물리적인 서버에 여러 개의 웹 서비스를 통신에 운영하는 것.
    ① IP 기반
        하나의 서버에 다수의 IP를 할당하여, IP별로 서비스를 나누어서 운영.

    ② Domain Name 기반
        서버의 IP에 서로 다른 Domain을 할당하고, Web Server에서 HTTP Header에서 어떤 Host로 요청한지 확인하여
        요청한 Domain Name을 기반으로 서비스를 나누어서 운영.
        
    ③ Port 기반
        동일 서버의 동일 Domain에 서로 다른 Port로 서비스를 할당하여 서비스를 운영.


 




Teaming / Bonding
   - 물리적인 다수개의 네트워크 카드를 논리적인 1개의 네트워크 카드로 묶어서, 이중화로 구성. 
   - Failover,Load Balance,Trunk 의 기능을 구현 가능.
   - 결국, 물리적인 네트워크 카드에서 장애가 발생하더라도 다른 네트워크 카드로 서비스 가능함.
 
Clustering
   - 동일 서비스에 대해서 서버를 이중화하고, (서버 간의 Health Check) 두 대의 서버를 논리적으로 묶어서 이중화 구성.
   - 서비스 동작 중인 서버나, 해당 서버와 연결된 네트워크 장비 장애 시 백업 서버로 서비스를 자동으로 전환하여 운영.





Keep Alive
  - 연결된 하나의 TCP Session으로 다수의 Request를 처리할 수 있게 접속을 유지(Persistence Connection)하게 함.
  - 접속이 유지되지 않으면, 하나의 접속에 대해서 하나의 Request만 처리할 수 있게 되므로 Server에서는 실 서비스 제공이
   아닌 TCP Session을 맺는 데 싱기는 과부하로 인한 성능 저하가 발생하기 때문이다. 
    ☞ 단, 모든 웹서버에서 활성화할 필요가 있는 것은 아니고, 웹서버에서 제공하는 서비스에 따라 Keep Alive를 설정 여부와
       유지 시간을 정해야한다.


---------------------------------------------------------------------------------------
NRC와 함께하는 Live 네트워크에서 서버쪽 살짝 보다가... 생각난거 짧게 몇 개 정리해봅니다..
Posted by 네떡지기
[펌] http://pcmsj.egloos.com/1356269


Introduction
이 문서는 Proxy Address Resolution Protocol(ARP)에 대해서 설명합니다. Proxy ARP 기술은 라우터 자신이 가지고 있는 ARP 테이블 또는 라우팅 테이블을 이용하여 호스트가 ARP를 요구할 시 대신 알려주는 기술입니다. 어떻게 보면 속이는 것이죠. 실제 목적지는 아니지만 그런 척 해서 받은 ARP request를 발생지로 응답하는 기술이기에 이 기술을 Proxy ARP라 합니다. Proxy ARP는 같은 서브넷에 존재하는 호스트를 원격지 호스트 또는 Default Gateway로 가는데 라우팅 설정없이 보낼 수 있습니다. Proxy ARP : RFC1027

Prerequisites
Requirements
선수조건으로 ARP와 Ethernet 환경의 이해가 요구됩니다.
Components Used
이 문서에서 사용된 소프트웨어와 하드웨어 버전은 다음과 같습니다.
  - Cisco IOS Software Reases 12.2(10b)
  - Cisco 2500 Series Routers
이 문서에서 제출된 정보들은 렙 환경을 통해 만들어 졌으며 각 장비들의 설정은 기본 구성값을 갖습니다. 만약 당신이 실제 네트워크 안에서 여기서 소개할 명령들을 구현할 시에는 먼저 각 명령들의 이해가 필요합니다.
Conventions
이 문서에서 설명되고 있는것이 불충분하다면 Cisco Technical Tips Conventions 을 참고하세요.

How Does Proxy ARP Work?
밑에 나오는 예제는 어떻게 proxy ARP가 운용되는지를 보여줍니다.






서브넷 A의 호스트 A(172.16.10.100)가 서브넷 B의 호스트 D(172.16.20.200)에게 패킷을 던질려고 합니다. 상위 그림에서 보이는 것처럼 호스트 A는 /16 서브넷 길이를 갖습니다. 그리하여 호스트 A는 자신이 172.16.0.0 네트워크에 물려 있는것으로 생각하여 호스트 D로 가기 위해 ARP를 요구하는 패킷을 발생합니다. ARP의 이유는 호스트 D로 가기위해선, 호스트 A는 호스트 D의 MAC 주소가 필요하기 때문입니다.
발생된 브로드캐스트 ARP 요구는 다음과 같습니다.

Sender's MAC Address

Sender's IP Address

Target MAC Address

Target IP Address

00-00-0c-94-36-aa

172.16.10.100

00-00-00-00-00-00

172.16.20.200


상위의 ARP 요청 패킷은 다시 이더넷 프레임으로 encapsulated되고 목적지 주소를 FFFF.FFFF.FFFF로 뿌리기 시작합니다. ARP 요청을 뿌리긴 하지만 호스트 D(172.16.20.200)에 닿을 수 없습니다. 왜냐하면 서브넷 A의 라우터 역시 요청 패킷을 받긴 하지만 기본적으로 브로드캐스트는 넘기지 않고 또 라우터 자신도 모르기때문입니다.
허나 서브넷 A의 라우터가 호스트 D(172.16.20.200)의 주소를 알고 있다면 라우터는 자신의 MAC 주소를 아래와 같이 호스트 A에게 알려 줍니다.

Sender's MAC Address

Sender's IP Address

Target MAC Address

Target IP Address

00-00-0c-94-36-ab

172.16.20.200

00-00-0c-94-36-aa

172.16.10.100


상위와 같이 호스트 A에게 Proxy ARP로 응답하며 Proxy ARP 응답 패킷은 이더넷 프레임 안에서 encapsulated 되어 발생지를 자신으로 목적지를 호스트 A의 MAC 주소로 보냅니다. 항상 ARP의 응답은 유니캐스트로 발생된 호스트에게 응답합니다.
ARP 응답을 받은 후의 호스트 A의 ARP 테이블은 다음과 같습니다.

IP address

MAC Address

172.16.20.200

00-00-0c-94-36-ab


지금부터 호스트 A는 호스트 D(172.16.20.200)으로 가기위해서 목적지 MAC 주소를 00-00-0c-94-36-ab로 넘길 것입니다. 또한 서브넷 A의 라우터는 받은 패킷을 자신이 알고있는데로 호스트 D에게 던질 것입니다.

시스코 라우터는 디폴트로 이 기능이 Enable되어 있으며 다음 명령으로 Disable합니다.
if)#no ip proxy-arp

Note : 호스트 B(172.16.10.200/24)의 경우에 호스트 D로 패킷을 던질려고 할 경우 호스트 B는 자신의 서브넷과 호스트 D의 서브넷이 다르다는 것을 알기 때문에 자신의 라우팅 테이블에서 해당 루트로 가기위한 루트를 찾을 것입니다. 만약 디폴트 루트가 자기 자신의 인터페이스 또는 같은 IP 주소를 갖을 경우, 호스트 A와 동일한 처리를 MAC 주소를 얻기 위해 행할 것입니다.

Advantages of Proxy ARP
Proxy ARP 기능을 이용하여 같은 네트워크 안에서 라우팅 처리 없이 쉽게 라우터를 붙일 수 있습니다. 호스트 또한 디폴트 게이트웨이를 설정하지 않습니다.

Disadvantages of Proxy ARP
  - ARP 트래픽이 증가합니다.
  - 호스트의, IP-to-MAC 주소를 매핑하기 위한 큰 범위의 ARP 테이블이 필요합니다.
  - 보안에 문제가 있습니다. 목적지로 가기위해서 ARP를 사용하기 때문에 내가 해당 목적지니 나에게 보내라는 식의 스프핑이 가능합니다.
  - 만약 ARP가 돌지 않는다면 네트워크는 침묵을 유지할 것입니다.
  - 모든 네트워크 토폴로지에서 사용되는 것은 아닙니다.


[펌] http://pcmsj.egloos.com/1356269
Posted by 네떡지기
아래 내용은 stemki님의 블로그 펌자료입니다.  - http://stemki.tistory.com/14
  - 참조 설정 방법 링크 - http://neonis.tistory.com/9

------------------------------------------------------------------------------------------------
[Teaming ]

1. AFT (Adapter Fault Tolerance) => 이중화 (active/standby)                       [Fault Tolerance 장애 방지]

 

1) Default Mode / Mode를 설정하지 않으면 기본적으로 AFT Mode가 된다.

2) AFT는 서버와 스위치 사이의 추가 백업 연결을 안전하게 지원한다.

따라서 어댑터(NIC) 또는 케이블 그리고 스위치 포트 장애발생해도 네트워크 연결성을 유지할 수 있다.

 

3) AFT는 주 어댑터와 하나 이상의 백업 또는 보조 어댑터를 사용해서 구현되며 정상 작동 중에는 백업 어댑터가 대기 Mode에 있다.

주 어댑터에 연결되지 않는 장애가 발생한 경우에는 자동으로 보조 어댑터에 연결된다.

이후 장애가 복구되면 주 어댑터로 넘어가게 된다.

4) AFT를 사용하려면 하나 이상의 PRO/100 또는 PRO/1000 서버 어댑터가 팀에 있어야 하고 모든 어댑터가 같은 스위치나 허브연결되어 있어야 한다.

 

<참고>

1) AFT 팀을 사용하려면 스위치가 팀 구성용으로 설정되어 있지 않고 STP가 OFF 되어 있어야 한다.

2) AFT 팀에서는 Intel PRO/100 어댑터와 Intel PRO/1000 어댑터를 함께 사용할 수 있다.


2. SFT (Switch Fault Tolerance)

 

1) SFT 팀을 사용하면 팀을 구성하는 두 어댑터를 제각기 다른 스위치에 연결할 수 있다.

 

2) SFT는 다음 위치에서 발생하는 장애를 감지할 수 있다.

a) 팀을 구성하는 어댑터               

b) 팀을 구성하는 어댑터를 해당 스위치에 연결하는 케이블

c) 어댑터에 연결된 스위치(링크가 손실된 경우)

 

3) SFT 팀에서 한 어댑터는 주 어댑터이고 다른 어댑터는 보조 어댑터이다.

정상 작동 중에는 보조 어댑터가 대기 Mode에 있다.

대기 Mode에서 어댑터는 사용하지 않도록 설정된 상태로 장애 조치가 발생할 때까지 대기하고 네트워크 트래픽을 송수신하지 않는다.

주 어댑터의 연결이 손실되면 보조 어댑터가 자동으로 연결된다.

4) SFT Mode에서 팀을 구성하는 두 개의 어댑터는 서로 다른 속도에서 작동한다.

 

<참고>

SFT 팀을 사용하려면 스위치가 팀 구성용으로 설정되어 있지 않고 STP가 ON 되어 있어야 한다.



3. ALB (Adaptive Load Balancing) =>
RLB(default)를 포함

업로드는 하나의 지정된 포트에서만 다운로드는 다른 포트에서만 진행하게 된다.
다시 말해 UP/DOWN 용도를 포트 별로 명확히 구분한다는 것이다.


RLB
(Receive Load Balancing) => UP/DOWN LINK 노는 현상 해결

ALB 설정 시 UP/DOWN 링크의 불균형한 사용률을 개선하기 위해 로드밸런싱 하여 트래픽을 분산시킨다.

1) 팀은 스위치 설정 없이 송수신 로드 균형을 조정하는 2-8개의 어댑터로 구성 된다.
(하나 이상의 Intel 서버 어댑터 포함 필요하다.)

팀 구성원 간의 혼합 속도/이중 Mode 설정을 지원하고 fail-over 기능을 포함한다.

ALB 팀을 사용하려면 스위치가 팀을 지원하도록 STP OFF 되어 있어야 한다.

 

RLB가 사용(default)되는 경우 사용 중인 어댑터 중에서 속도가 가장 빠른 모든 어댑터가 IPv4 수신 트래픽의 로드 균형을 조정하며 주 어댑터가 임의의 프로토콜을 사용하여 트래픽을 수신한다.

RLB가 사용되지 않는 ALB 팀의 경우에는 주 어댑터만 트래픽을 수신한다.

 

<참고>

a) ALB 팀을 사용하려면 스위치가 팀 구성용으로 설정되어 있지 않고 STP가 OFF 되어 있어야 한다.

b) NetBEUI 나 일부 IPX* 트래픽과 같이 경로 지정이 불가능한 프로토콜의 경우에는 ALB가 균형을 조정하지 않는다.

c) 속도가 다른 어댑터로 구성된 ALB 팀을 만들 수도 있습니다.

로드의 균형은 어댑터 성능과 채널 대역폭에 따라 조정된다.



4. FEC/Link Aggregation/802.3ad: static mode

=> Intel Link Aggregation, Cisco Fast EtherChannel* 기술 또는 정적 802.3ad(FEC 또는 FEC/LA/802.3ad: static)

 

1) 팀은 데이터 송수신을 동시에 처리하는 2-8개의 10/100 어댑터로 구성되며, fail-over Load-Balancing을 포함한다.

Intel Link Aggregation, Cisco FEC 또는 정적 802.3ad를 지원하는 스위치가 필요하다.

모든 팀 구성원의 속도/이중 Mode 설정이 일치해야 하며, 스위치의 STPOFF 되어 있어야 한다. 또한 스위치의 aggregation 요구 사항을 준수해야 한다.

 

2) FEC(Fast EtherChannel)는 Cisco에서 스위치간 처리량을 높이기 위해 개발한 성능 기술이다.

이 Mode는 다음 스위치와 함께 사용할 수 있다.

 

1)     PAgP 프로토콜을 사용하는 Cisco FEC 가능 스위치

2)     Intel의 Link Aggregation 가능 스위치

3)     기타 정적 802.3ad 가능 스위치

 

<참고>

FEC 팀을 사용하려면 스위치가 FEC 팀 구성용으로 설정되어 있고 STP가 OFF 되어 있어야 한다.



5. GEC/Link Aggregation/802.3ad: static mode

=> FEC(GEC 또는 GEC/LA/802.3ad: static)에 해당하는 Gigabit

 

1) Intel PRO/1000 또는 동급 어댑터가 필요하고 Intel Link Aggregation, Cisco GEC 또는 정적 802.3ad를 지원하는 스위치도 필요하다. STP OFF 되어 있어야 한다. 다른 요구 사항은 FEC와 비슷하다.

 

2) GEC(Gigabit EtherChannel)는 Cisco에서 스위치간 처리량을 높이기 위해 개발한 성능 기술이다.

 

이 Mode는 다음 스위치와 함께 사용할 수 있습니다.

1) PAgP 프로토콜을 사용하는 Cisco GEC 가능 스위치

2) Intel의 Link Aggregation 가능 스위치

3) 기타 정적 802.3ad 가능 스위치


 

FEC & GEC/Link Aggregation/802.3ad: static mode

1) 전송 속도는 단일 주소(사양 당)에 대한 어댑터 기본 속도를 초과할 수 없다.

2) 팀은 2 - 8개의 어댑터로 구성될 수 있지만 스위치 기능과 일치해야 한다.

3) 정적 Link Aggregation에 맞게 구성된 어댑터 팀은 내결함성과 로드 균형 조정의 장점도 제공한다.

4) 이 Mode에서는 주 어댑터를 설정할 필요가 없다.

 

<참고>

GEC 팀을 사용하려면 스위치가 GEC 팀 구성용으로 설정되어 있고 STP가 OFF 되어 있어야 한다.

 

6. IEEE 802.3ad: dynamic mode => 대역폭 확장

 

< IEEE 802.3ad는 보통 Link Aggregation Control Protocol(LACP)라고 하며 cisco 에서 만든 기술로서 우리가 알고 있는 etherchannel을 지원할 수 있게 하는 표준 규약이다. 만약 이 기능을 지원하지 않는 스위치라면 etherchannel도 당연히 되지 않는다. >

 

1) Mode Cisco FEC 방법에 통합된 기술에 대한 IEEE 표준이다.

동적 802.3ad 팀에 대한 iANS 지원은 FEC GEC 팀에 대한 지원과 비슷하다.

IEEE 802.3ad Dynamic Link Aggregation은 일반적으로 Link Aggregation의 장점뿐 아니라 자동 구성, 빠른 구성/재구성, 결정적 동작과 같은 장점도 제공한다.

팀은 데이터 송수신을 동시에 처리하는 2-8개 어댑터로 구성된다.
집계 그룹은 같은 속도와 전이중 Mode를 지닌 구성원만 포함한다. 내결함성과 로드 균형 조정을 포함한다.

IEEE 802.3ad 동적 표준을 지원하거나 적어도 Intel Link Aggregation 또는 Cisco FEC를 지원하는 스위치가 필요하다.

Intel Link Aggregation 또는 Cisco FEC를 지원하는 스위치를 사용하면 팀은 802.3ad 정적 Mode로 작동한다.

STP는 꺼져 있어야 하며, 스위치의 aggregation 요구 사항을 준수해야 한다.

 

* 팀은 하나의 기존 인터페이스와 VLAN 지원 기능을 추가하는 하나의 Intel 어댑터로 구성된다.
그러나 이 Mode에는 Intel 서버 어댑터가 필요하지 않다. VLAN을 사용하도록 설정해야 한다.

 

 

2) 팀은 2-8개의 어댑터로 구성될 수 있으며 서버 당 최대 두 개의 IEEE 802.3ad 동적 팀을 만들 수 있다.
반드시 802.3ad 스위치를 사용해야 합니다.
동적 Mode에서는 집계가 스위치 간에 이동할 수 있다.

IEEE 802.3ad에 맞게 구성된 어댑터 팀은 내결함성과 로드 균형 조정의 장점도 제공한다.

802.3ad에서는 모든 프로토콜의 로드 균형이 조정될 수 있다.

 

동적 Mode는 복수 집계자(Aggregator)를 지원하는데, 집계자는 같은 스위치에서 다른 속도로 형성(속도 기반 팀)되거나 복수 스위치를 사용하여 형성(약간의 스위치간 중복성 제공)된다.

팀은 한 번에 하나씩만 활성화된다.

<참고>

a) IEEE 802.3ad 팀을 사용하려면 스위치가 IEEE 802.3ad(Link Aggregation) 팀 구성용으로 설정되어 있고 STP가 OFF 되어 있어야 한다.

b) 선택한 집계자는 집계 팀에 있는 모든 어댑터의 링크가 사라질 때까지 남아 있다.

c) 일부 스위치의 경우 동축케이블 어댑터와 광 케이블 어댑터는 IEEE 802.3ad 구성에서 같은 집계자에 속할 수 없다.

시스템에 동축케이블 어댑터와 광 케이블 어댑터가 설치된 경우 스위치는 한 집계자에서는 동축케이블 어댑터를, 다른 집계자에서 광 케이블 기반 어댑터를 구성할 수 있다.

이 경우 시스템에서 동축케이블 어댑터만 사용하거나 광 케이블 기반 어댑터만 사용해야 성능이 최적화된다.

d) 여러 스위치가 사용되는 경우에는 같은 스위치에 연결된 모든 팀 구성원이 같은 속도로 작동해야 한다.


7. SLA

LACP처럼 여러 NIC를 합쳐서 대역을 늘릴 수 있다.
NIC
과 스위치 포트 fail over 만 지원하지만 스위치 자체에 대한 failover 은 불가하다.

(팀으로 구성되는 것은 하나의 스위치에 다 모여 있어야 하기 때문이다.)
Cisco
전용이라 다른 회사에서는 지원하지 않는다.


8. MVT (Multi-Vendor Teaming)

MVT를 사용하면 Intel 어댑터와 Intel 제품이 아닌 어댑터로 구성된 팀을 만들 수 있습니다.
Windows
기반 컴퓨터를 사용할 경우에는 Intel PROSet에 나타나는 어댑터가 팀에 포함될 수 있습니다.

 

< MVT 설계 고려 사항 >

MVT를 활성화하려면 팀에 주 어댑터로 지정된 Intel 서버 어댑터가 하나 이상 있어야 합니다.

다중 공급업체 팀은 VLAN을 제외한 모든 팀 모드로 만들 수 있습니다.

MVT의 모든 구성원은 일반 기능 집합(최소 공통 분모)에서 작동해야 합니다.

Posted by 네떡지기

티스토리 툴바