히포

LACP 로드 밸런싱

• LACP로 설정된 채널 그룹의 이중화된 링크를 통해 트래픽을 로드 밸런싱하는 과정에서 순차적으로 전송되는 프레임이 목적지에서는 도착 순서가 뒤바뀌는 현상이 발생할 수 있음
• 로드 밸런싱은 프레임의 전송 시점에 적용되는 기술로, 양방향으로 동작 X
• 장비간의 로드 밸런싱 방식의 차이에 따라 패킷을 수신하는 장비에서 재배열과 부하 쏠림 현상(링크의 부하 비율이 균등하지 않고 한쪽으로 몰리는 현상)이 발생할 수 있음
• 어그리게이션을 통한 로드 밸런싱은 관리자의 서비스에 따른 로드 밸런싱 파라미터 설정에 상당히 의존적임

• 두 개의 링크를 하나의 채널로 설정하고 이를 로드 밸런싱하는 경우 뒤바뀌는 현상 예시
  1. 큰 크기의 프레임은 첫 번째 링크로 전송
  2. 두 번째 상대적으로 적은 크기의 프레임은 두 번째 링크로 전송
  3. 도착지에서의 순서는 두번째 프레임이 첫번째 전송한 프레임보다 먼저 도달함
  4. 전송 받은 서버는 첫번째 프레임과 두번째 프레임의 순서를 재배열을 수행

• 802.3ad 표준에는 어떤 링크를 사용할 것인가에 대한 결정에 대한 언급은 없지만 링크에 가중치를 부여하는 방식을 설명
  1. 어그리게이션된 링크에서 재배열을 방지하면서 적절하게 트래픽 부하를 분산할 수 있는 로드 밸런싱 방안을 고려
  2. IEEE 표준에 어그리게이션된 물리적 링크 간 완벽한 로드 밸런싱에 관한 사항이지만 로드 밸런싱 비율이 보장돼 있지 않기 때문에 장비 제조사별로 각기 다른 로드 밸런싱 알고리즘을 적용
  3. 목적지 MAC 주소 기반의 로드 밸런싱 수행의 경우 특정 목적지로 전송되는 프레임은 어그리게이션된 다수의 링크 중 하나의 링크만 사용해 전송
  4. 트래픽이 폭주해 링크가 포화 상태에 이르면 링크 대역폭에 수용되지 못한 오버플로우(Overflow)된 프레임은 다른 링크로 전환되지 않고 폐기됨 → 프레임 손실 발생

• 로드 밸런싱을 위해 사용되는 파라미터를 목적지 MAC 주소 외에 다른 방식으로 변경해야 함
  1. 분배기가 다중 링크에 프레임을 전송할 때 전송할 물리적 링크를 결정해야하는 과정에서 수행
  2. 분배기가 로드 밸런싱을 위해 사용하는 기본적인 알고리즘은 목적지 MAC 주소를 변수로 하는 해시(Hash) 알고리즘
  3. 재배열 문제와 로드 밸런싱을 위해 가장 많이 사용하는 방법이 L2 계층의 주소인 MAC 주소를 사용하는 방법
  4. 정교한 로드 밸런싱을 하기 위해 시스코의 경우 L3 계층의 파라미터(IP주소), L4 계층의 파라미터(Port 번호)를 로드 밸런싱 알고리즘 연산의 변수로 사용
     
     
     

본딩 모드 알고리즘

• 라운드 로빈(mode 0; Round-Robin)은 기계적으로 NIC을 돌려쓰기 때문에 트래픽간 편차가 클 경우 부하 분산이 어려움
• mode 2(balance-xor) 혹은 mode 4(LACP)를 추천
• mode 2는 송신만 부하분산이 되고 XOR 스타일상 부하가 한쪽으로 몰릴 가능성이 있어서 성능으로만 보면 mode 4(LACP)를 선택하시는게 좋음 → 단, mode 4(LACP)는 연결될 스위치가 802.3ad 설정이 되어있어야 함

1. mode 0 : Round-Robin

• 전송 가능한 슬레이브 처음부터 끝까지 순차적으로 전송
• mode 0 (Round-Robin)모드는 부하분산과 failover를 제공
• active-active → 슬레이브 수의 배수대로 대역폭을 확장 가능
• 스위치에서 지원한다면 hashing 없이 load balancing 가능

2. mode 1: Active-backup

• bond에서 하나의 슬레이브만 활성화하고, 다른 슬레이브는 standby 상태로 대기
• 활성 중인 슬레이브가 fail 된 경우 standby 슬레이브가 활성화
• 대역폭은 활성화된 슬레이브의 대역폭을 가짐
• Active로 설정할 포트를 primary로 직접 설정하지 않으면 failback 되지 않음

3. mode 2 : balance-xor (load balancing + failover)

• mode 0과 비슷하지만 xor연산을 이용하여 목적지 Mac과 근원지 Mac을 이용하여 분배
• fault tolerance 와 load balancing 을 위한 XOR으로 설정
• 인터페이스가 slave 네트워크 카드들의 하나에 대한 Mac address 로imcoming request의 Mac address를 연결하는 방식

4. mode 3 : broadcast (failover)

• 모든 슬레이브 인터페이스로 전송
• failover를 제공 (mirror)
• 하나의 슬레이브만큼 대역폭을 갖음
• 특별한 상황에서 사용
• 특별한 경우는 랜카드가 절대로, 절대로 죽어서는 안되고 패킷이 절대로 절대로 없어지면 안되는 서버에 사용
• 스위치의 지원이 필요 X

5. mode 4 / LACP : 802.3ad (link aggregation)

• switch 에 aggregation group을 생성 필요
• switch 가 802.3ad 를 지원 필요
• 같은 속도와 duplex 설정을 공유하는 aggregation group을 만들어야함
• 송/수신은 active aggregator 안에서 모든 슬레이브에서 수행
• 이론상 슬레이브 수만큼의 배수대로 대역폭을 확장 가능

6. mode 5 : balance-tlb

• 스위치의 지원이 필요 X
• 특별한 지원이 OS 자체적으로 구동가능한 방법으로 각 링크의 현재 로드에 따라 보내는 데이터는 분산되어 전송
• 데이터의 수신은 현재 slave쪽으로만 가게되며 해당 slave가 fail시 다른 slave가 MAC주소를 넘겨받아 수신
• 데이터를 보낼 때에 드라이버가 MAC address를 링크의 것으로 바꿔 보내지만 받을 때에는 그냥 남겨둠

7. mode 6: balance-alb

• mode 4 즉 802.3ad 를 스위치가 지원하지 않는다면 이 모드인 mode 6를 사용
• 스위치의 지원이 필요 X
• mode 5와 같이 동작하지만 데이터 수신 시에서 load-balancing을 하는데 두개의 링크에서 ARP negotiation을 통하여 동작
• MAC 주소 트릭을 이용하여 데이터를 보내고 받을 때에 load-balancing을 하게됨

스위치 지원이 필요한 모드와 자체 가능한 모드

1. Require switch supports modes (스위치의 지원이 필요한 모드)

1. mode 0 (balance-rr) → 트래픽은 hashing 없이 load balancing됨
2. mode 4 (802.3ad) → 기본적으로 해당 모드는 스위치에서 지원 off 되어 있음 → 스위치쪽에 LACP를 활성화 해줘야함
3. mode 2 (balance-xor) → 받는 쪽의 receiver에 의하여 트래픽은 hashed되고 balancing 됨

2. Generic modes (switch의 지원없이도 kernel과 driver를 통해 자체적 구동이 가능)

1. mode 3 (broadcast)
2. mode 5 (balance-tlb)
3. mode 6 (balance-alb)
   
   
   

부하분산은 기본적으로 해쉬값

1. xmit_hash_policy 옵션치 0 혹은 layer2

• 데폴트값으로 MAC어드레스만 가지고 해쉬값을 생성

2. xmit_hash_policy 옵션치 1 혹은 layer3+4

• IP와 포트값을 가지고 해쉬값을 생성
• 주의점은 이 알고리즘의 경우 802.3ad에 대응하지 않음

3. xmit_hash_policy 옵션치 2 혹은 layer2+3

• MAC어드레스와 IP값을 가지고 해쉬값을 생성
• 본딩모드 4를 고르시고 xmit_hash_policy는 2를 선택하실경우 일반적으로 가장 고른 부하분산이 가능

참고 URL : https://louie0.tistory.com/124
참고 URL : https://m.blog.naver.com/PostView.nhn?isHttpsRedirect=true&blogId=hymne&logNo=221042702409

• 이더넷 네트워크에서 추가 장비의 구매 없이 또는 장비의 업그레이드 없이 물리적 대역폭과 회선의 이중화 구성을 가능하도록 하는 기술
• 네트워크 장비 간에만 구성될 수 있는 것이 아니라 네트워크 장비와 서버의 랜카드 사이에도 적용 가능한 기술
• 네트워크 장비와의 병렬적 링크 연결을 위해 서버에서는 하나의 랜카드에 다수의 인터페이스가 포함되어 있는 쿼드(Quad) 또는 옥탈(Octal) 랜카드(NIC)를 사용
• 스패닝 트리 동작의 관점에서 보면 LACP(Link Aggregation Control Protocol)로 구성된 최대 8개(제조사마다 차이)의 물리적 회선은 하나의 논리적 회선으로 간주되기 때문에 루핑(Loop) 구조도 형성되지 않음
• LACP는 IEEE 802.3ad로 표준화된 기술

LACP(IEEE 802.3ad)

• 1990년대 중반에 대부분의 스위치 제조사들이 스위치 간의 대역폭을 확대시키는 방안으로 독자적인 링크 어그리게이션(Link Aggregation) 방법을 사용
• 스위치들 마다 독자적인 링크 어그리게이션(Link Aggregation) 방법을 사용함으로 호환성에 문제 발생
• 호환성 문제를 해결하기 위해 IEEE 802.3 그룹은 1997년 11월 회합에서 상호 호환성을 제공할 수 있는 링크 계층의 표준을 만들기 위해 연구 그룹을 구성
• 표준 그룹에서 채택한 표준화 기술은 대부분 시스코의 100Mbps 패스트 이더 채널 기술을 도입해 정비
• LACP의 구조는 패스트 이더 채널와 일부 특징을 제외하고는 매우 유사
• 2000년에는 802.3ad에 기가 인터넷(1Gbps)을 수용
• 현재 거의 모든 제조사가 자신의 네트워크 장비에 링크 어그리게이션(Link Aggregation)을 위해 802.3ad LACP 표준을 사용

LACP 동작 모드

• LACP로 설정된 인터페이스 모드

  1. 능동모드(Active Mode)

     • 능동 모드로 설정된 인터페이스는 상대방 인터페이스로 LACP 설정을 협상하기 위해 LACP 협상 패킷인 LACP 데이터 유닛(LACPDU; LACP Data Unit)을 정기적으로 전송
     • 정기적 주기는 빠른 주기와 느린 주기의 설정
     • 빠른(fast time) 주기인 경우는 매초의 값을 갖음
     • 느린(slow time) 주기인 경우는 30초의 값을 갖음
       

  2. 수동 모드(Passive Mode)

     • 수동 모드로 설정되는 포트는 상대방이 전송하는 LACP 데이터 유닛(LACPDU; LACP Data Unit)를 수신해 현상이 성공될 때만 링크를 채널화함
     • LCAP 설정 시에는 반드시 두 장비 중 한대는 능동모드로 설정되어야함
     • LACP 데이터 유닛(LACPDU; LACP Data Unit) 프레임은 목적지 주소로 01-80-C2-00-00-02의 멀티캐스트 주소와 이더타입 0X8809를 사용해 이더넷 프레임으로 캡슐화함

• 능동모드(Active)와 수동모드(Passive)의 차이
  1. LACP 연결 성립시에 누가 협상요청을 보내느냐의 차이
  2. Active일 경우 LACP 협상요청을 보낼 수 있고, Passive일 경우 받기만 가능
  3. Passive일 경우 상대가 요청할 경우에만 LACP모드로 동작

• 양쪽 노드 모두 Active/Passive 중 하나를 고를 수 있으므로, 나올 수 있는 조합은 3가지
  1. Active / Active → 어느 쪽이든 협상요청을 할 수 있으므로 LACP로 동작
  2. Active / Passive → 한 쪽이 협상요청을 하고, 다른 쪽이 받아들이므로 LACP로 동작
  3. Passive / Passive → 아무도 협상요청을 하지 않으므로, LACP로 동작하지 않음

LACP 설정 시 제약 사항

• 두 스위치 간에 채널을 설정하려면 최소한 한쪽 스위치가 반드시 능동 모드로 동작해야함
• 양쪽이 모두 수동 모드로 설정되는 경우는 채널 설정이 불가능함
• 링크에 LACP 채널을 구성하려면 같은 채널 그룹으로 설정되는 인터페이스의 제약사항
  1. 동일한 물리적 링크 속도
  2. 동일한 VLAN 번호(VLAN-ID)
  3. 스패닝 트리 설정을 갖고 전이중(Full-Duplex) 모드로 동작
  4. 점대점(Point to Point) 링크로 구성

링크 어그리게이션(Link Aggregation) 아키텍처 모델

• 링크 어그리게이션(Link Aggregation)은 다수의 MAC 프레임을 수집 통합 → 분배 → 상위 계층으로 전달
• 링크 어그리게이션 서브레이어(Link Aggregation Sublayer)는 LLC 계층과 MAC 계층 사이에 위치함
• LAN에서 네트워크 자원을 효율적으로 활용하려고 데이터 링크 계층의 기능을 LLC 계층과 MAC 계층으로 나눠 처리 → 링크 어그리게이션(Link Aggregation)는 MAC과 LLC 계층 사이에 존재
  

  

물리적 포트의 어그리게이터 바인딩(Aggregator binding)

• 실질적으로 물리적 포트를 논리적 링크인 채널로 묶는 것은 어그리게이션 제어(Aggregation Control)에 의해 수행됨 → 채널 묶는 것은 수동 설정이거나 자동의 LACP에서 수행
• 어그리게이션 제어(Aggregation Control)가 임의의 링크를 어그리게이션(Aggregation)할지 결정하면 어그리게이션될 물리적 링크가 논리적 링크인 어그리게이터(Aggregator)로 바인딩(binding)됨
• 물리적 링크가 어그리게이션되어 논리적 링크가 생성되면 프레임 분배와 수집 처리가 시작됨
• 어그리게이션 제어(Aggregation Control)의 수행을 위해 링크 분배기(Distributor) 이전에 링크 수집기(Collector)가 활성화 되어야함, 만약 활성화 되지 못하면 불필요한 프레임 유실이 발생함

어그리게이터의 주소 할당

• 어그리게이션된 논리적 인터페이스인 채널 포트는 채널된 물리적 포트 멤버 중 가장 낮은 물리적 주소를 갖는 인터페이스의 MAC 주소를 어그리게이션된 채널 포트의 논리적 주소로 사용
• 물리적 인터페이스에 할당된 주소가 있음에도 불구하고 논리적 어그리게이션 인터페이스인 채널 포트를 위해 주소를 할당하는 데 대한 부담감을 덜기 위한 방법

• 호스트(컴퓨터)가 멀티캐스트 그룹 구성원을 인접한 라우터로에게 알리는 프로토콜
• IGMP는 TCP/IP 프로토콜 집합이 동적 멀티캐스팅을 수행하기 위해 사용하는 표준 프로토콜
• 특정 그룹에 속하는 모든 호스트에 메시지를 전송하는 방식을 멀티캐스팅(Multicasting) → 필요한 라우팅 알고리즘을 멀티캐스트 라우팅(Multicast Routing)
• IGMP 프로토콜은 여러 호스트(수신자)에게 채널이 효과적으로 전송되게 하기 위해, 멀티캐스트 네트워크를 기반으로 구성되는 IPTV 서비스에 많이 사용

IGMP의 위치

• IGMP 프로토콜과 ICMP 프로토콜 등은 데이터 전송용 프로토콜이 아니고 이벤트 또는 변화를 알리는데 사용되는 프로토콜
  

  

IGMP 동작 과정

1. 그룹 멤버쉽 조사 (monitoring)
   • 멤버쉽 질의 메시지를 보내서 응답을 기다림
   • 일정 횟수 이상 응답 없으면 라우터는 해당 호스트를 그룹에서 탈퇴 시킴

2. 그룹 가입 (Joining)
   • 그룹에 가입하고자 하는 요청을 라우터에 보고

3. 멤버쉽 연속 (member continuation)
   • 계속해서 유지하기 원하는 보고 메시지

4. 그룹 탈퇴 (Leaving)
   • 호스트가 해당 그룹의 멀티캐스트 트래픽을 원치 않으면 leave 메시지 전송
     

     

IGMP 패킷 구성

호스트 측면에서 IGMP 프로토콜 사용

• 멀티캐스트 데이터의 수신을 원하는 호스트들이 IGMP를 사용하여 라우터에게 요청
• 멀티캐스트 데이터를 더 이상 수신을 원하지 않으면 그만 전송하라 중지 요청
• 호스트들은 멀티캐스트 그룹에 가입/탈퇴한다고 라우터에게 요청하는 용도

라우터 측면에서 IGMP 프로토콜 사용

• 라우터는 IGMP를 통하여 멀티캐스트 그룹에 가입한 호스트들을 감시하게 됨 → 주기적으로 멀티캐스트 그룹에 가입한 호스트들에게 IGMP 패킷을 사용하여 질의하는 용도.
• 멀티캐스트 그룹 멤버들은 SHOW IP IGMP GROUP를 통하여 확인 가능
• Expires 시간내에 호스트로부터 IGMP 패킷을 수신하지 못한다면 삭제됨
• 라우터가 감시하지 않을 시 아래와 같은 일이 발생 가능
  1. 한 호스트가 멀티캐스트를 이용하여 파일을 다운로드 하는 중에 전력이 차단되서 PC 전원이 차단된다면 호스트는 멀티캐스트 그룹의 탈퇴 메시지를 전송 X
  2. 라우터는 위 내용을 모르고 계속 가입되어 있는줄 착각하고 멀티캐스트 패킷을 지속하여 전송
  3. 쓸데없이 대역폭 낭비와 라우터 자원의 낭비를 발생
  4. 라우터는 IGMP를 통하여 멀티캐스트 그룹에 가입한 호스트들을 감시하는 역활을 수행해야함

IGMP 메시지의 전송

• IGMP는 IP 프로토콜과 동등한 계층의 기능을 수행
• 데이터링크계층으로 보내지지 않고, IP 패킷에 캡슐화되어 보내짐
• IGMP 메시지는 IP 프로토콜의 데이터로 처리되기 때문에 IP 패킷의 헤더에 실려서 계층 2 프로토콜로 전달됨
  

  

IGMP 취약점

• IGMP 프로토콜의 구조는 매우 단순하며 별도의 인증 과정을 거쳐 가입(Join) 하는 기능을 제공 X → 보안 면에서 매우 취약하다는 단점 有
• 공격자가 정상적인 사용자인 것처럼 IGMP 메시지를 위조하여 IGMP 전송
  1. IPTV 서비스 상의 프리미엄 채널을 가로채어 시청
  2. 현재 시청하고 있지 않는 여러 개의 채널을 요청해서 네트워크 내에 있는 모든 채널의 품질을 저하
• ICMP와 마찬가지로 디도스 공격에 이용될 수 있음

IGMP 기타 기능

1. IGMP Snooping
   • 라우터와 호스트 사이에 있는 스위치가 IGMP 메시지들을 들을 수 있게 하는 기능

2. IGMP Querier Election
   • 동일 LAN에 여러 멀티캐스트 라우터가 있으면, IPv4 주소 중 가장 낮은 주소를 갖는 라우터가 Querier 역할 집중

• ARP 프로토콜은 한국어로 주소 결정 프로토콜이라고 함
• IP 주소를 MAC 주소와 매칭 시키기 위한 프로토콜
• MAC 주소 → 물리적 네트워크 주소는 이더넷 또는 토큰링의 48 비트 네트워크 카드(NIC) 주소
• ARP를 사용 이유는 로컬 네트워크(LAN, Local Area Network)에서 단말과 단말 간 통신을 하기 위해 IP 주소와 함께 MAC 주소를 이용
• IP 주소를 MAC Address와 매칭하여 목적지 IP의 단말이 소유한 MAC 주소를 향해 제대로 찾아가기 위함
• IP 주소를 MAC 주소로 매칭해야하는 이유를 알기위해서는 LAN(Local Address Network)과 MAC 주소에 대해 이해 필요

LAN(Local Address Network)

• 근거리 통신망, 로컬 영역 네트워크(영어: local area network, LAN),
• 네트워크 매체를 이용하여 집, 사무실, 학교 등의 건물과 같은 가까운 지역을 한데 묶는 컴퓨터 네트워크
• 아무리 큰 규모의 네트워크일지라도 같은 IP 대역을 공유한다면 근거리 네트워크임
• LAN은 ARP Request가 미치는 영역 → APR Request Packet이 전달되기만 한다면 LAN이라봄
• 같은 IP 대역을 공유하는 LAN에서 단말간 통신을 하기 위해선 사용자는 IP 주소를 목적지로 지정하지만 실제로는 MAC 주소를 이용해 목적지를 찾음. → IP 주소와 MAC 주소를 매칭하기 위해 ARP가 사용

• 아래 그림) 중앙에 하나의 L2 Switch를 두고 컴퓨터들을 연결하여 LAN(192.168.1.0/24)을 구성
  1. PC0(192.168.1.1)이 PC1(192.168.1.2)와 통신을 하기 위해서 사용자는 목적지를 192.168.1.2로 지정
  2. LAN 구성에서 통신을 하는 경우 실제 목적지는 PC1의 IP 주소와 함께 MAC 주소를 목적지로 지정하고 전달
     

     

MAC 주소

• 데이터 링크 계층에서 통신을 위한 네트워크 인터페이스에 할당된 고유 식별자로 Network Interface Card(NIC)를 가진 단말이라면 공장에서 출고될 때 부여되고 평생 사용하는 고유한 주소를 의미
• LAN(Local Address Network)에서 목적지와 통신하기 위한 실질적인 주소 → MAC 주소
• 네트워크 장비 혹은 컴퓨터가 갖는 Network Interface Card마다 MAC 주소를 가짐
• LAN(Local Address Network, Layer 2)에서는 IP 주소를 MAC 주소에 매칭하여 통신

• MAC Address 확인 (ipconfig /all 명령어)
  

  

MAC 주소가 필요 이유

1. 주소 이동 예시 → 논리적 주소인 IP 주소와 물리적 주소인 MAC주소의 관계가 행정적 주소와 물리적 주소와 같음

1. '서울특별시 광진구 화양동 43'에서 '성남시 분당구 야탑동 24'으로 이동한다고 가정
2. 화양동을 출발하여 남쪽으로 내려감
3. 성남으로 가기 위해 잠실대교를 건너 송파구의 석촌동, 문정동을 지나면 복정동으로 향하는 도로를 지나감
4. 성남시 수정구 복정동에 도착한 후에 분당구 야탑동으로 이동하려면 중원구 성남동을 지나가야함
5. 성남동을 지나 드디어 야탑동에 도착
6. 야탑동에 도착하니 야탑동 24가 어디인지 써있는 표시 없어, 주변의 지형지물을 통해 야탑동 24의 위치 찾아냄
7. 야탑동 24이 친구 집이라면 친구에게 전화해 "한국전자부품연구원 위에 보면 야탑천이 시작되는 곳에 있어"라는 질문으로 위치 정보를 얻을 수 있음
8. 야탑동 24라는 행정적 주소는 제도에 따라 변할 수 있지만 야탑천이 시작되는 곳이라는 물리적인 주소는 결코 변하지 않음
   

   

2. LAN(192.168.1.0/24)의 구성 예시 → IP는 변경, MAC은 불변하는 틍징을 가지고 통신

• IP 주소는 끊임없이 변화함
• MAC 주소 체계가 없는 상황을 가정하고 IP 주소만 있는 상황에서 PC0 사용자가 자신의 IP를 192.168.1.2로 바꾼다면 PC0와 PC1 모두 192.168.1.2 IP를 갖게 될 것이고 원래 IP 192.168.1.2 주인이 누군지 알수 없음
• 고유한 정보인 MAC 주소는 웬만해서는 변경되지 않음 → MAC 주소를 사용하여 전달하는 것이 확실
• 인터넷 상에서 IP 주소 없이 변화하지 않는 고유한 주소인 MAC 주소를 사용하여 라우팅을 한다면, 각 고유한 주소를 라우팅 테이블에 일일이 입력하다간 라우터가 다운됨 → 라우팅 테이블에 등록될 숫자가 매우 많아짐
• IP 주소는 연속성을 갖기 때문에 IP 주소 다수를 한 줄로 지정해줄 수 있으니 편리
  

  

ARP에 대한 설명

• 단말간 통신에서 양쪽 단말은 IP를 이용하여 목적지를 지정하지만 실제 데이터 이동을 위해 MAC 주소를 함께 이용
• 통신을 위해 필요한 것이 Address Resolution Protocol(ARP) → IP 주소와 MAC 주소를 일대일 매칭하여 LAN(Layer 2)에서 목적지를 제대로 찾아갈 수 있도록 함
• ARP 테이블(ARP Table)은 IP 주소와 MAC 주소를 일대일 대응하여 테이블로 정리하고 목적지 IP에 맞는 목적지 MAC 주소로 전달 → IP 주소와 MAC 주소를 일대일 매칭시킨 정보를 정리해둔 Table

1. PC0의 ARP Table

• PC0의 ARP Table에 다른 PC들의 IP 주소와 함께 MAC 주소가 일대일 매칭되어 관리
• 사용자가 데이터를 보내기 위해 목적지 IP 주소를 지정한다면 PC0은 ARP Table에 있는 MAC 주소를 보고 해당 MAC 주소의 소유 PC로 전달
  

  

2. 스위치의 MAC 주소 Table

• 중간에서 데이터를 전달하는 스위치 또한 자신의 Port에 연결된 PC들의 MAC 주소 정보를 가짐
• 어느 Port에서 어느 PC의 MAC 주소가 올라오는지 알아야 PC에게서 전달받은 데이터를 전달할 때 목적지 MAC 주소를 올바르게 지정 가능
• 스위치의 MAC Table은 PC0에서 PC 1,2,3으로 Ping 명령을 실시한 후의 결과 → LAN에서의 통신은 MAC 주소를 이용
  

  

ARP Table 생성 과정

• IP 주소와 MAC 주소가 구비되어있다 하더라도 다른 PC의 IP 주소와 MAC 주소를 모르면 데이터를 전달 X
• ARP Table을 생성하여 다른 PC들에 대한 주소 정보를 확보하는 것이 필요
• ARP는 이더넷 통신에 없어서는 안 될 매우 중요한 요소이며 네트워크 트러블 슈팅의 기본
• PC 0,1,2,3뿐만 아니라 모든 단말들은 자신만의 Routing Table이 있어 자신이 보내려는 패킷의 목적지 IP가 자신이 소속된 IP 대역인지 아닌지 알 수 있음

• ARP Table 순차적으로 설명
  1. PC0(192.168.1.1)은 PC 2(192.168.1.3)에게 데이터를 전달하려고 함 → Routing table을 보니 자신(PC0)과 PC2가 같은 LAN에 속한다는 것을 암
  2. PC0는 Broadcast(FF:FF:FF:FF:FF:FF)인 ARP Request(Who has 192.168.1.3? Tell 192.168.1.1)를 전송 → PC1,PC2,PC3에 전달
  3. ARP Request의 목표인 PC2가 반응하여 ARP Response(PC2의 MAC 주소)를 응답
  4. PC0(192.168.1.1)은 PC2가 보낸 ARP Reponse를 받고 ARP Table에 PC2의 IP와 MAC 주소를 기록
  5. PC0가 PC2에 데이터를 보내려 목적지 IP를 192.168.1.3으로 지정하면 자연스레 ARP Table을 보고 PC2의 MAC 주소를 목표로 전달
     

     

참고 URL : https://aws-hyoh.tistory.com/entry/ARP-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

unknown unicast 발생 원인

• 답 : 라우터와 스위치간의 서로 다른 aging time으로 unknown unicast 발생

라우터와 pc 같에 통신을 통한 설명

• 시스코 라우터의 기본 ARP mac address table에 저장되어 있는 시간은 4시간.
• 스위치는 기본 ARP mac address table 남아있는 시간은 5분 → 5분안에 다시 통신하지 않으면 Mac Table에 Mac 주소가 사라짐
• 라우터가 PC와 3시간 전에 통신을 했다고 가정하면 라우터에는 PC Mac 주소가 ARP mac address table에 남아 있음
• 라우터는 PC의 Mac 주소를 가지고 있기에 다시 통신을 하려고 시도하는 경우 ARP 발생시키지 않고 Unicast로 통신하려고 함
• 하지만 스위치는 PC의 Mac 주소를 모르므로 switch의 기본성질인 Flooding(Mac 주소 모르면 자기 자신을 제외하고 모두 뿌림)을 하게됨
• 스위치가 Mac 주소를 몰라 자신을 제외한 다른 서버에 Flooding을 함으로써 unknown unicast frame이 발생 → 많은 트래픽을 발생하여 성능에 문제 발생

  라우터(Router)<------------>스위치(Switch)<------------>PC

  
  
  

unknown unicast를 보완하기 위한 방법

1.자주 사용하는 mac 주소는 스위치에 static으로 설정

• Mac주소를 고정하여서 ARP Mac address Table에 기록 → Mac주소가 변경되면 해당 내용 삭제 필요

  SW1(config)#mac-address-table static [맥주소] vlan 1 interface fastethernet 0/x

  
  
  

2.스위치의 aging time out 시간을 설정으로 조절

• second에 원하는 시간을 입력 → 초 단위
• 0으로 설정하면 무한대 → 추천 X

  sw1(config)#mac-address-table aging-time [second] vlan 1

Null Routing (Blackhole Routing)이란

• 특정 IP 또는 특정 대역에서 과도한 스캐닝이나 공격시도가 감지된다면 해당 IP 또는 대역을 차단할 수 있는데, 이때마다 일일이 access list를 지우고 다시 설정하는 작업은 번거로운 일임
• access list보다 CPU 부하가 적으면서도 손쉽게 필터링이 가능한 Null Routing을 사용
• 특정 목적지IP 또는 IP대역에 대해 특정한 인터페이스로 라우팅 테이블을 강제로 지정 → 특정패킷이 라우터 내부로 들어올 수는 있지만 나갈 수는 없도록 하는 것으로 내부적으로 패킷을 필터링하는 것이 아니라 패킷을 Null 0 인터페이스로 포워딩하는 개념
• blackhole filtering이라고도 함 → Null이라는 가상의 interface로 보내는것을 blackhole로 보내는 것과 비슷
• 특정한 IP또는 IP대역에 대해서 null이라는 가상의 interface로 보냄
• Null Interface는 특정주소를 목적지로 하는 트래픽을 차단(혹은 폐기)하기 위해서 사용
• Null Interface는 ACL 과는 달리 라우터의 CPU 소모율(CPU 부하)이 낮기 때문에 효과적으로 라우터의 부하를 줄이는 방법
• Null Interface는 Routing Loop를 방지하는데 도움을 줌
  
  
  

Null Routing 사용 이유

• ACL보다 Router에 부하가 덜하고, 설정이 편리하단 점에선 ACL보단 편리함
• Null Routing은 Dest IP나 IP대역에 대해서 막는건 쉽지만, 기능적으로 제한적임
• Null Routing과 달리 ACL은 패킷에대해 포트나 Source IP, Dest IP에 대해 유연하게 제어가 가능
• 네트워크대역에 대해 심각하게 IP스캔을 하거나 스팸을 뿌리는 IP가 보일 경우 Null Routing으로 차단 필요
• 공격자는 대부분 차단된 것을 확인 후에는 더 이상의 시도를 하지 않게 되고 때때로 자동화된 스캔 프로그램을 실행해 두었는지 차단되고 있음에도 불구하고 계속시도를 하는 경우도 있음 → 공격한 패킷은 Null0으로 이동하기에 CPU 부하 X
• Null Routing이란 소스 IP에 대한 라우팅이 아니라 목적지 IP에 대한 라우팅이므로 공격자의 IP를 Null0으로 설정하였을 경우 공격자의 요청(소스:공격자, 목적지:내부서버)은 라우터를 통과하여 서버까지 전달되지만 서버에서의 응답(소스:내부서버, 목적지:공격자)이 blackhole처럼 Null0로 보내어져 사라지게 함 → 패킷 부하 X

• Null Routing 참고 사항
  • 공격자의 소스 IP를 차단하려면 access list를 사용해야함
  • Null Routing은 포트까지 제어할 수 있는 L4가 아니라 IP나 IP대역을 차단하는 L3
  • Null Routing은 특정한 포트를 차단할 수는 없음으로, 특정 포트를 차단하기 위해서는 extended access list 사용 필요
    
    
    

Null Routing 사용 형식

• static routing을 이용하여 특정한 목적지 IP 또는 대역을 Null0라는(유닉스의 /dev/null과 유사) 가상의 쓰레기(garbage) 인터페이스에 강제적으로 보냄으로써 트래픽을 차단하는 방식
• 라우터에서는 패킷이 필터링 될 때마다 해당 패킷의 소스 IP로 icmp unreachable messages를 발송 → 서비스 거부 공격이 이루어지고 있을 경우 필터링 되는 패킷으로 인하여 라우터에서 많은 icmp 패킷이 유발 (라우터에 과부하를 유발)
• Null0 인터페이스에서 반응하지 않도록 no ip unreachables 설정 → 포트스캔이나 IP스캔의 결과를 지연시키거나 보이지 않도록 하는 효과

• Null Routing 사용 형식

  interface Null0
  no ip unreachables
  !
  ip route <dest to drop> <mask> Null0

• sender.com에서 receiver.com으로 telnet 접속을 시도
  1. 라우터 내부에는 receiver.com이라는 서버가 없거나 다운되어 연결할 수 없기 때문에 라우터에서 대신 icmp로 응답
  2. "no ip unreachables” 설정 후에는 라우터에서 반응 X
  3. ip unreachables를 반드시 사용하여야 할 특별한 이유가 있다면 “ip icmp rate-limit unreachable”을 이용하여 응답하는 비율을 제한

     sender.com.31504 > receiver.com.23: S
     router > sender.com:icmp: host receiver.com unreachables

• Null Routing을 이용하여 231.1.1.1 IP를 차단

  1. static routing이므로 mask 적용 시 access list에서 사용하는 wildcard mask를 쓰지 않도록 주의 필요

     interface Null0
     no ip unreachables
     !
     ip route 231.1.1.1 255.255.255.255 Null0

  2. wildcard mask를 사용하여 231.1.1.0/24 대역을 차단

     Router(config)#ip route 231.1.1.0 255.255.255.0 Null0

  3. 설정한 내용을 해제하려면 설정내용 앞에 no가 필요

패킷트레이스 Null Routing 사용 예시

• Null Routing 명령어 구조

  router(config)# ip route [dest ip | network] [subnet mask] null0

• Null Routing 설정하지 않고 203.235.222.3 -------> 192.168.10.1으로 ping 테스트 (정상)
  

  

• Null Routing 설정 (203.235.222.0/24 대역 차단) → -------> 192.168.10.1으로 ping 테스트 (일정 시간 초과하면 차단)

  # 양식
  R1(config)# ip route 203.235.222.0 255.255.255.0 null0

  

참고 URL : https://www.linux.co.kr/bbs/board.php?bo_table=lecture&wr_id=2601
참고 URL : https://secdata.tistory.com/18

• 링 버퍼(Ring Buffer)는 원형 큐로 약간의 개량해서 사용
• 링 버퍼는 가변적인 데이터를 처리
• 기본적으로 네트워크의 처리 단위 : 1/1000 초
• 기본적으로 CPU의 처리 단위 : 1/1000000 초 이하
• 네트워크와 CPU는 처리 속도가 수 백에서 수 만 배 차이 발생
• 네트워크의 통신에서 패킷의 크기가 고정되어 있으면 프로그램이 쉽지만 필요 없는 데이터까지 입/출력에 포함되어 있어서 네트워크의 성능을 떨어짐
• 가변적인 크기를 가진 패킷을 사용하는데 가변 크기를 가진 패킷을 저장하기 위해 링 버퍼(Ring Buffer)라는 자료구조를 사용
• 링 버퍼(Ring Buffer)는 분해된 패킷을 합치거나 완성되지 않은 자투리 패킷을 완전한 패킷으로 만들 수 있는데 편리
• 링 버퍼(Ring Buffer)는 Byte 단위로 저장할 공간만 있으면 동작함.
• FIFO 기반의 일반적인 선형 큐의 메모리가 꽉 차게되면 Overflow가 발생 하지만 링 버퍼(Ring Buffer)는 head와 tail이 붙어 있는 형태의 큐를 구성으로 dropped 되어 유실되는 packet을 방지 가능

Network Ring Buffer Size 설정

• Ring Buffer는 네트워크 카드의 버퍼 공간
• 스위치에서 서버로 전달된 패킷의 전달 과정
  1. 네트워크 카드 내 Ring Buffer 에 보관 (NIC 카드 → Ring Buffer)
  2. 커널의 Socket RCV Buffer로 이동 (Ring Buffer → Socket RCV Buffer)
  3. User Application의 read 함수를 통해 전달 (Socket RCV Buffer → Application의 read()가 값 읽음)

• Kernel의 Socket RCV Buffer가 여유가 있더라도 Ring Buffer Size가 작다면 중간 병목(bottleneck)이 발생 → Ring Buffer는 가능하다면 Maximum 값으로 설정해주는 것이 권장
• 리눅스에서는 패킷 송수신시 1계층 물리적 케이블을 통하여 NIC로 packet이 수신 되면 가장 먼저 Ring Buffer 라는 영역에 보관한 뒤에 처리
  

  

• Linux 상에서 NIC의 Ring Buffer(Current, Maximum) 값은 ethtool -g 명령어를 통해 확인 가능
  1. eth1 maximum으로 처리 가능한 ring buffer size는 4096임
  2. eth1 Current으로 처리 가능한 ring buffer size는 512으로 설정
  3. 리눅스 상에서packet 의 drop 과 error 를 줄이기 위해서 maximum 과 Current 동일하게 설정하는 것이 좋음

     # interface의 경우 최대 값이 4,096이지만 현재 설정 값은 512
     $ ethtool -g em1
     Ring parameters for em1:
     Pre-set maximums:
     RX:             4096
     RX Mini:        0
     RX Jumbo:       0
     TX:             4096
     Current hardware settings:
     RX:             512
     RX Mini:        0
     RX Jumbo:       0
     TX:             512

• ethtool -G 명령어에 해당 파라미터를 maximum 값과 동일하게 설정 한뒤 설정 값을 변경

  # ethtool -G 명령어를 통해 ring buffer를 최대 값으로 설정
  $ ethtool -G em1 rx 4096
  $ ethtool -G em1 tx 4096
  
  # 변경된 ring buffer 내용 확인
  $ ethtool -g em1
  Ring parameters for em1:
  Pre-set maximums:
  RX:             4096
  RX Mini:        0
  RX Jumbo:       0
  TX:             4096
  Current hardware settings:
  RX:             4096
  RX Mini:        0
  RX Jumbo:       0
  TX:             4096

  
  
  

Network Ring Buffer Size 확대 영구적으로 등록

• 대부분의 Linux 설정과 같이 명령어는 현재 메모리 상의 값을 변경하기 때문에 재부팅 시에는 이전 값으로 원복됨
• 영구적으로 변경하기 위해서는 Network script 내 해당 Interface에 관련 설정 값을 추가해주는 것이 필요

• 아래와 같이 스크립트 파일 내 ETHTOOL_OPTS 옵션을 추가한 후 해당 설정 값을 입력 → rx/tx의 최대 값을 확인 후 작성 필요

  $ cat /etc/sysconfig/network-scripts/ifcfg-em1
  TYPE=Ethernet
  BOOTPROTO=static
  DEFROUTE=yes
  NAME=em1
  DEVICE=em1
  ONBOOT=yes
  IPADDR=1.255.156.21
  NETMASK=255.255.255.224
  GATEWAY=1.255.156.1
  ETHTOOL_OPTS="-G ${DEVICE} rx 4096 ; -G {$DEVICE} tx 4096"

• 재부팅시에 Network Ring Buffer Size 확대 명령어 실행 → rc-local.service 사용

  $ vi /etc/rc.local
  # 아래의 값이 등록
  ethtool -G eth1 rx 4096
  ethtool -G eth1 tx 4096

  
  
  

※ 참고 사항 → rc-local.service를 실행하는 방법

# rc-local.service를 실행할 수 있는 환경 적용
$ echo -e "\n[Install]\nWantedBy=multi-user.target" >> /usr/lib/systemd/system/rc-local.service
$ chmod u+x /etc/rc.d/rc.local

 # rc-local.service 실행
/bin/systemctl daemon-reload
/bin/systemctl restart rc-local.service
/bin/systemctl enable rc-local.service

$ echo -e "rc-local.service가 rebooting에도 실행되는 지 확인"
/bin/systemctl list-unit-files | grep rc.local

※ 패킷 전송 및 수신 에 관련된 버퍼 참고 사항

• Little's law에 의해 동일한 부하에서 응답시간 또는 지연시간이 낮을 수록 시스템 처리량이 높아짐
• 정해진 자원 내에서 시스템 성능을 높이기 위해 튜너들이 어플리케이션이나 SQL의 응답시간을 줄이는 노력을 하게 되는 것
• 성능 개선의 핵심은 응답시간을 낮추는 것
• 기존 Little's Law 법측을 활용하여 시스템의 성능 이론에도 동일하게 적용
• Little's law의 규칙을 기반으로 성능을 향상하려고 한다면, 낮은 response time을 만드는 것이 최우선임 → "Low response time makes high throughput"

시스템의 성능 측정 Little's law

1. Active users -> 실제 사용자 수
2. TPS : 초당 트랜잭션(Transactions per Second)
3. Response time -> 응답 시간

   Active users = TPS * Response time

   

시스템의 성능 측정 Little's law의 이해

• 1명의 사용자가 시스템에 요청을 보낼 때 응답이 1초에 처리 → 초당 처리건수(TPS)는 1건
• 초당 처리건수(TPS)가 1건이면 2명이 요청하였을 때 응답 시간은 2초가 발생
• 1명이 요청을 보낼 때 응답이 0.5초에 처리 → 초당 처리 건수(TPS)는 2건
• 2명이 요청을 보낼 때 응답이 0.5초에 처리 → 초당 처리 건수(TPS)는 4건
  
  
  

TPS(초당 트랜잭션)와 Response 계산

• 시스템 처리량(TPS을 계산하는 공식으로 변환 → 시스템 처리량은 사용자 수에 비례하고, 응답시간에 반비례

  TPS = Active users / Response time

• 응답시간(Response)으로 계산하는 공식으로 변환 → 응답시간은 사용자 수에 비례하고 시스템 처리량에 반비례

  Response time = Active users / TPS

  
  
  

스토리지 성능 컨셉에 맞게 변환

• Thread → I/O 부하를 일으키는 주체
• Latency(지연시간) → 스토리지의 응답시간
• IOPS(Input Output Operations per Second) → 초당 입출력 오퍼레이션 건수로 스토리지의 처리량

  IOPS = Threads / Latency

  
  
  

※ 기존 Little's law (리틀의 법칙) 개념

• Little's law (리틀의 법칙)는 고정 시스템에서 고객의 장기 평균 수가, 장기 평균 유효 도착률에 고객이 시스템에서 소비하는 평균 시간을 곱한 것
• John Little이 정리한 법칙으로 Little's Law의 규칙

  # L -> 상점에 있는 평균 고객 수
  # λ(람다) -> 대기열에 있는 사람 수
  # W -> 상점에 머무르는 시간
  L = λ W