[CISCO 보안 아카데미 1기 Part.2] 20일차 정리(PIMv2 BSR, Anycast RP, IGMP, MBGP)

---

PIMv2 BSR

PIMv2 BSR Overview

• single Bootstrap Router가 선출됨 (BSR)
  • 다수의 BSR 후보가 설정될 수 있음
    • 이는 현재 선출된 BSR에 결함이 발생했을 경우 백업을 제공
  • C-PR은 BSR로 C-PR announcement를 전송
    • C-PR announcement는 유니캐스트로 전송됨
    • BSR은 RP-set에 모든 C-PR announcement를 저장
  • BSR은 모든 라우터를 향해 주기적으로 BSR 메시지를 전송
    • BSR 메시지는 전반적인 RP-set과 BSR의 주소 포함
    • 메시지는 BSR로부터 hop-by-hop으로 네트워크 전체에 Flooding됨
  • 모든 라우터는 RP-set으로부터 RP를 선택
    • 모든 라우터는 동일한 선택 알고리즘을 사용
    • 같은 RP를 선택
• BSR은 Admin-Scoping과 함께 사용될 수 없음

PIMv2 BSR Fundamentals

• Candidate RPs
  • BSR을 향해 PIMv2 C-RP 메시지를 유니캐스트로 전송
    • BSR 메시지를 통해 BSR의 IP 주소 학습
    • 매 rp-announce-interval마다 전송 (기본 60초)
  • C-RP 메시지는 아래의 내용을 포함
    • Group Range (기본 224.0.0.0/4)
    • 후보 RP 주소
    • Holdtime = 3 * (rp-announce-interval)
  • 전역 설정 명령어로 설정됨

    ip pim rp-candidate (intfc) (group-list acl)

• Bootstrap router (BSR)
  • C-RP 메시지 수신
    • 모든 C-RP 메시지 허용 및 저장
    • holdtimes와 함께 Group-to-RP Mapping Cache에 저장
  • BSR 메시지 발생
    • 모든 PIM-Router 그룹 (224.0.0.13)으로 멀티캐스트 (TTL=1로 전송)
    • 모든 인터페이스로 전송되고 hop-by-hop으로 전파됨
    • 매 60초마다 또는 변화가 감지될 때 전송
  • BSR 메시지는 아래의 내용을 포함
    • BSR의 Group-to-RP Mapping Cache의 내용
    • 활성화된 BSR의 IP 주소

• Candidate bootstrap router (C-BSR)

  • 가장 높은 priority의 C-BSR이 선출됨

    • C-BSR의 IP 주소는 tie-breaker로 사용됨(가장 높은 IP 주소가 이김)

  • 활성화 BSR은 대기상태가 될 것

    • 더 높은 BSR priority의 라우터가 강제로 새로이 선출됨

  • 전역 설정 명령어로 설정됨

    ip pim bsr-candidate (intfc) (hash-length) (priority) (pri)

    • (intfc) > IP 주소 결정
    • (hash-length) > RP 선택 hash mask 길이 설정
    • (pri) > C-BSR priority 설정 (기본 = 0)

• All PIMv2 Routers
  • BSR 메시지 수신
    • local Group-to-RP Mapping Cache에 저장
    • 활성화 BSR 주소를 결정하는 데에 정보 사용
  • Hash 알고리즘을 사용하여 RP 선택
    • local Group-to-RP Mapping Cache에서 선택
    • 모든 라우터는 같은 선택 알고리즘을 사용하여 같은 RP를 선택
    • group range 전체에 걸쳐 RP-load balancing 허용

---

Anycast RP's

Anycast RP

• 이점
  • 신속한 RP Failover
    • 유니캐스트 후 몇 초 이내에 Converge
  • No Dense Mode Fallback
    • RP 주소가 정적으로 정의되기 때문
• 단점
  • 더 많은 설정
    • 모든 라우터에서 정적 RP 정의를 해 주어야 함
  • MSDP 요구
    • 오직 RP 라우터에서만 필요

Anycast RP Configuration

Anycast RP Tips

• Anycast RP/Router-ID 충돌 회피
  • Anycast RP 주소가 Router-ID로 사용되지 않도록 루프백 주소를 반드시 보장해야 함
    • OSPF와 BGP를 망치게 될 것
  • Router-ID와 충돌을 피하는 법
    • Anycast RP 주소를 가장 낮은 IP 주소로 설정
    • Anycast IP 주소에 대해 루프백에 secondary IP 주소를 사용
    • OSPF와 BGP에서 router-id 명령어를 사용하여 Router-ID를 정적으로 설정

Anycast LAB

• MSDP peer를 맺을 때, pim rp-address는 서로 같은 주소를 사용
  • 해당 LAB에서는 loopback의 second 주소 사용
• msdp peer 명령어에 작성할 주소는 각 라우터의 Router-ID
  • 해당 LAB에서는 loopback의 첫 주소 사용

---

IP Multicasting at Layer 2

Layer 2 Multicast Addressing

• IP Multicast MAC Address Mapping

• 특정 멀티캐스트 주소를 사용한다고 선언할 경우, 그 주소와 MAC 주소가 겹치는 멀티캐스트 주소는 사용하면 안 됨
  • MAC 주소가 겹치기에 전송하는 정보가 원치 않는 장비로 전송될 수 있음

IGMP

• host들이 라우터에 그룹 멤버십에 대해 말해주는 방법
• 라우터가 직접 연결된 host들에 그룹 멤버십 요청
• RFC 1112는 IGMP의 첫 번째 버전 지정
• RFC 2236은 IGMP의 현재 버전 지정
• IGMPv3 향상
• 유닉스 시스템, PC, MAC에서 지원

IGMPv2

• RFC 2236
  • Group-specific query
    • 라우터는 해당 서브넷의 그룹 데이터 전달 중지 이전에 멤버가 없다는 것을 확인하기 위해 Group-specific query를 전송
  • Leave Group message
    • 호스트는 그룹을 떠날 때나 그룹의 마지막 멤버가 되었을 때 leave 메시지 전송
  • Querier 선출 메커니즘
    • multi-access 네트워크에서 IGMP Querier 라우터는 가장 낮은 IP 주소를 기반으로 선출됨 (오직 Querier 라우터만이 Query를 던짐)
  • Query-Interval Response Time
    • General Query들은 host에게 Query에 응답해야 하는 최대 시간을 호스트에게 알려주는 Max Response Time을 지정

• Joining a Group

• Queier Election

• Maintaining a Group

• Leaving a Group

IGMPv3

• RFC 3376
  • Include/Exclude Source List 추가
    • 그룹에 대하여 전송하는 호스트의 특정 서브넷에 대해서만 Listen하겠다고 활성화 가능
    • 새로운 IPMulticastListen API 필요(새로운 IGMPv3 스택 필요)
    • App들이 IGMPv3 Include/Exclude을 사용하기 위해 재작성되어야 함
  • 새로운 멤버십 Report 주소
    • 224.0.0.22 (All-IGMPv3-Routers)
    • 모든 IGMPv3 호스트들은 이 주소로 report 전송
    • 모든 IGMPv3 라우터들은 해당 주소로 listen
    • 호스트들은 해당 주소로 listen이나 repond 작업 하지 않음
  • No Report Suppression
    • 연결된 모든 호스트들이 Query에 응답
    • 넓은 범위에서 Response Interval은 조정될 수 있음

L2 Multicast Frame Switching

• 문제: Layer 2 Flooding of Multicast Frames
• 일반적인 L2 스위치는 멀티캐스트 트래픽을 알 수 없는 트래픽이나 브로드캐스트 트래픽으로 간주하여 모든 포트로 프레임을 flooding함
• 정적 항목은 가끔 어느 포트가 어떤 멀티캐스트 트래픽 그룹을 받아야 할지 지정하도록 설정할 수 있음
• 이러한 항목들의 동적 설정은 사용자 관리를 줄일 수 있음

• Solution 1: IGMP Snooping
• 스위치가 IGMP를 인식하게 됨
• IGMP 패킷이 NMP 또는 특별한 HW ASICs에 의해 가로채어짐
• 스위치는 어느 포트가 어떤 트래픽을 원하는지 결정하는 IGMP 메시지의 내용을 검사해야 함
  • IGMP membership report
  • IGMP leave message
• 스위치에 대한 영향
  • 모든 Layer 2 멀티캐스트 패킷을 처리해야 함
  • 멀티캐스트 트래픽 부하로 인해 부하가 증가
  • throughput을 유지하기 위해 특별한 HW가 필요
  • L3 스위치가 아닌 이상 높은 용량의 데이터를 전송할 때 CPU Meltdown 발생

• Solution 2: CGMP-Cisco Group Multicast Protocol
• 스위치와 라우터 모두에서 동작
• 라우터가 CGMP 멀티캐스트 패킷을 스위치로 well known 멀티캐스트 MAC 주소로 전송
  • 0100.0cdd.dddd
• CGMP 패킷은 아래의 내용을 포함
  • Type field - Join or Leave
  • IGMP Client의 MAC 주소
  • 그룹 멀티캐스트 주소
• 스위치는 특정 멀티캐스트 MAC 주소에 대한 항목을 추가할지 제거할지 CGMP 패킷 정보를 이용

요약

• IGMP Snooping
  • Layer 3를 인식하는 ASIC가 있는 스위치
    • 높은 처리량 성능 유지
    • 스위치의 cost 증가
  • Layer 3를 인식하는 ASIC가 없는 스위치
    • 심각한 성능 감소
• CGMP
  • Cisco 라우터와 스위치 요구
  • low-cost 스위치에서 구현 가능

---

Multiprotocol BGP

MBGP

• RFC 2283에 정의
• 다른 타입의 경로를 전달할 수 있음
  • IPv4 Unicast
  • IPv4 Multicast
  • IPv6 Unicast
• 같은 BGP 세션에서 전송될 수 있음
• 멀티캐스트 상태 정보를 전파하지 않음
  • 여전히 Distribution Tree를 형성하기 위해 PIM 필요
• 같은 경로 선택과 확인 규칙
  • AS-Path, LocalPref, MED

---

LAB

---

PIM Protocol Extensions

Source Specific Multicast(SSM)

• Source Tree만 사용
• RP 필요없음
• MSDP 필요없음
• 처음부터 Src에 대한 정보를 Client가 처음부터 알게 하거나 Last Hop Router가 Src에 대한 정보를 알고 있도록 설정하면 됨
• (*,G) 테이블 생성되지 않음
  • (S,G) 테이블로만 통신
• Last-Hop Router가 (S,G)로 Source를 향해 바로 Join하기 때문

Bidirectional (Bidir) PIM

• 멀티캐스트 트래픽을 전부 RP쪽으로 향하게 한 후 처리하는 방식
• Designated Forwarder 필요
• (*,G) 테이블만 사용