히포

과거에 기본적으로 리눅스의 이더넷 이름은 eth0, eth1 과 같이 eth를 prefix로 사용

• 리눅스 배포판들이 eth0과 같은 전통적인 ethernet naming을 버리고 현재 em1 또는 p2p1와 같은 이름 사용
• 과거 이더넷이 하나 뿐인 일반적인 PC 환경에서는 eth0 이든, em1 이든, p2p1 이든 네트워크를 쓸 수 있는 포트가 하나 밖에 없으니 문제 X
• 현재 라우터 뿐만 아니라 서버도 HA용으로 사용하거나 포트 bonding을 통해 여러 포트를 사용하는 네트워크를 구성
• 여러 포트를 사용할 때 사용하는 물리적 포트가 eth0인지, eth1 인지 구분하기 힘들면 관리에서 문제 발생 → 커널이 PCI bus를 읽는 순서에 따라 eth0 이 다음번 부팅 때에는 eth1 이 되기도 하는 등 문제가 많음

현재 이더넷 이름은 물리적인 순서를 지정하는 방식으로 사용 → em1과 p2p1

• 이더넷 이름에 물리적인 순서를 지정하는 방식으로 em1 형식과 p2p1 형식이 있음
  • em1은 온보드 이더넷 포트
  • p2p1은 PCI NIC
    
    
• p2p1에서 첫번째 숫자는 PCI 슬롯의 이름이고, 마지막 숫자는 해당 NIC의 포트 중에 첫번째 포트를 의미

ifconfig 명령어를 통해 network interface의 정보 확인

$ ifconfig
em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 110.45.211.60  netmask 255.255.255.128  broadcast 110.45.211.127
        inet6 fe80::e643:4bff:fe18:b550  prefixlen 64  scopeid 0x20<link>
        ether e4:43:4b:18:b5:50  txqueuelen 1000  (Ethernet)
        RX packets 318352  bytes 159830547 (152.4 MiB)
        RX errors 309  dropped 4864  overruns 0  frame 309
        TX packets 240498  bytes 41808200 (39.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 246  bytes 27053 (26.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 246  bytes 27053 (26.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ifconfig 명령어 카운터 의미

1.errors

• 에러가 발생한 모든 패킷 카운트
• 너무 긴(짧은) 프레임 에러, 링-버퍼 오버플로우 에러, CRC 에러, 프레임 정렬 에러, FIFO 오버런, 패킷 분실 등
• 아래 3개 overruns, dropped, frame 등을 모두 포함한 에러 카운터

2. overruns

• FIFO 오버런, 버퍼가 꽉차서 버린 패킷 카운트
• 이더넷이 처리할 수 없을 정도로 빠르게 자료가 오고감으로써 손실된 패킷의 갯수

3. dropped

• 의도하지 않는 패킷 카운트
• linux buffers에 공간이 없어서 버려진 패킷. "no space in linux buffers" 표현
• VLAN tags가 맞지 않거나 IPv6 설정이 없는데 IPv6 패킷이 들어왔을 때 버린 패킷들

4. frame

• 프레임 정렬 에러, 프레임 길이가 틀린 패킷 카운트
• 수신 프레임이 바이트 단위가 아닌 여분의 비트를 포함하는 패킷
• frame은 정렬되지 않은 프레임만 계산하므로 길이가 8로 나눌 수 없는 프레임을 의미
• 길이 때문에 유효한 프레임이 아니며 단순히 폐기됨

ethtool -S 명령어를 사용하여 error를 자세하게 확인

$ ethtool -S em1 | grep -i error
     rx_errors: 310
     tx_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 310
     rx_frame_errors: 0
     rx_fifo_errors: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     rx_length_errors: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_csum_offload_errors: 1

• ACL이나 보안 그룹(security group)으로 포트가 막혀 있는지, 열려있는지 확인하는 방법
• 보통은 ping 같은 명령어로 ICMP 패킷을 쏴보고 해당 서버가 살아있는지 먼저 확인
• ping으로는 살아 있는데, ssh 나 http 같은 건 안 되는 경우에, TCP 포트가 열려 있는 상태 확인
• /dev/의 built-in에 대해서 조금 더 자세한 내용 참고 URL : https://tldp.org/LDP/abs/html/devref1.html

1. tcping

• TCP SYN 패킷을 보내서 해당 포트가 열려 있는지 확인해주는 간단한 프로그램
• 서버의 네트웍 연결 상태를 확인할 때, ping 차단(ICMP차단)된 서버의 네트웍 상태를 TCP를 통해 특정 tcp포트 확인
• "telnet 서버주소 포트" 시도 후 'Escape character is "]"' 문자열이 보이는지 확인하여 연결 상태를 확인 가능
• tcping을 쓰게 되면, ping처럼 round-trip time을 출력
• TCP 연결 속도도 확인 가능
• TCP 연결은 최대한 빠르게 처리하기 때문에 latency를 좀 더 정확히 보려면 ping보다는 tcpping을 써야 함

• tcpping 명령어를 사용하기 위해서 tcping 패키지 설치 필요

  $ yum install -y tcping
  
  # 설치된 tcping 명령어 위치 확인
  $ which tcping
  /usr/bin/tcping

• tcping 명령어 사용 예시

  # Open된 포트에서 tcping을 통해 접속 확인
  $ tcping -t 5 www.daum.net 80
  www.daum.net port 80 open.
  
  # Close된 포트에서 tcping을 통해 접속 확인
  $ tcping -t 5 www.daum.net 8080
  www.daum.net port 8080 closed.

  
  
  

2. telnet <IP><PORT>

• 텔넷으로 IP, port를 명시하면 해당 서버에 저 포트가 열려 있는지 간단히 확인 가능
• 연결 → 서버 연결되면 명령어가 입력이 안되기에 Ctrl+']' 를 누르시면 텔넷 프롬프트가 출력
• 텔넷 프롬프트가 출력될 때 quit을 입력하여 종료

• telnet 명령어 사용 예시

  # Close된 포트에서 telnet 접속 요청
  $ telnet 127.0.0.1 10002
  Trying 127.0.0.1...
  telnet: Unable to connect to remote host: Connection refused
  
  # Open된 포트에서 telnet 접속 요청
  $ telnet 127.0.0.1 22
  Trying 127.0.0.1...
  Connected to 127.0.0.1.
  Escape character is '^]'.
  SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.1
  ^C^]
  telnet> quit
  Connection closed.

  
  
  

3. echo > /dev/tcp/<ip>/<port>

• bash의 built-in 기능

• /dev/tcp를 이용하면 wget이나 curl이 없어도 파일을 받아올 수 있음

• 포트가 열려 있는 경우라면, 아무 메시지가 나오지 않은 상태로 끝남

• echo $?을 통해 이전 명령어의 결과를 출력하면 0이 나옴

• 바로 전 실행 명령이 0이면 정상적으로 끝났다는 유닉스 세계의 메시지

  $ echo > /dev/tcp/127.0.0.1/22
  $ echo $?
  0

• 포트가 열려 있지 않은 경우에는 에러 메시지도 나오며, $?의 값이 1로 나옴 → 성공적으로 연결 X

  $ echo > /dev/tcp/127.0.0.1/10002
  bash: connect: 연결이 거부됨
  bash: /dev/tcp/127.0.0.1/10002: 연결이 거부됨
  $ echo $?
  1

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