LabHub
배우기 러닝패스 코스

CCA — 실리움 인증 어소시에이트 · BGP 사고 조사: 경로를 배웠는데 왜 못 갈까 · 퀴즈

퀴즈: 경로 광고와 실제 전달의 증거

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. Cilium localASN은 65001, FRR local AS는 65002인데 Cilium peerASN이 65003이다. 가장 좁은 수정은?

    1. 해당 피어의 peerASN을 65002로 맞추고 주소와 sourceInterface는 보존한다
    2. 노드 PodCIDR을 65003과 같은 숫자로 바꾸고 광고를 다시 생성한다
    3. 서비스 VIP를 삭제해 FRR이 다른 AS로 연결을 다시 시작하게 한다
    4. FRR에 기본 경로를 추가해 BGP OPEN의 AS 검사를 우회한다
  2. rib 라우터에는 PodCIDR의 유효한 BGP 최선 경로가 있지만 FIB에는 연결망만 있다. 실습에서 이 비교를 유지하는 이유는?

    1. BGP 연결을 유지하려면 모든 외부 라우터에서 커널 경로를 꺼야 하기 때문이다
    2. 경로 학습과 커널 전달 경로 설치가 별개의 단계임을 정상 전달 라우터와 비교하기 때문이다
    3. PodCIDR 광고는 서비스 VIP와 달리 원래 실제 패킷 전달에 사용할 수 없기 때문이다
    4. 커널 경로가 없는 상태에서도 HTTP 200이 보장되므로 서비스 장애만 검사하기 때문이다
  3. selected와 excluded 서비스가 같은 정상 Pod를 가리키며 서로 다른 VIP를 받았다. 선택 광고의 성공을 증명할 관측은?

    1. 두 서비스의 status에 IP가 있으므로 외부 라우터의 경로 관측은 생략한다
    2. selected가 200이면 excluded에 기본 경로를 넣고 같이 성공하도록 고친다
    3. selected /32와 200을 확인하고 excluded 경로 부재·연결 실패도 함께 확인한다
    4. Pod IP에 직접 접속해 200이면 두 서비스의 광고 선택자는 모두 올바르다고 판단한다
  4. cca-withdraw 광고를 삭제한 뒤 피어는 Established이고 목적지 RIB/FIB가 사라졌다. cca-retire 서비스 UID와 정상 Pod는 유지된다. 맞는 해석은?

    1. 서비스가 삭제됐으므로 경로가 사라졌고, 같은 이름으로 다시 만들면 같은 서비스다
    2. BGP 세션이 끊겼으므로 Established 출력은 의미가 없고 무조건 재시작해야 한다
    3. BGP가 서버의 HTTP 프로세스를 중단시켰으므로 애플리케이션 배포를 롤백해야 한다
    4. 서버·피어를 유지하면서 광고 철회의 전달 영향을 분리한 상태이며 실제 요청도 대조해야 한다
  5. 커널 JSON에서 VIP 목적지가 203.0.113.10으로 표시됐다. 과제의 /32 경로인지 판단할 때 맞는 방법은?

    1. IP/CIDR를 정규화하고 BGP 프로토콜·다음 홉·장치까지 함께 대조한다
    2. 문자열에 /32가 없으므로 BGP 학습 여부와 관계없이 잘못된 경로로 처리한다
    3. IP 숫자만 일치하면 정적 경로·기본 경로·다른 장치도 같은 답으로 처리한다
    4. FIB 표시가 간결하면 RIB와 실제 요청은 확인하지 않고 자동으로 통과시킨다
  6. 보고서 작성 뒤 서버 Pod가 재생성되어 IP는 같지만 UID가 바뀌었다. 보고서를 그대로 제출해도 될까?

    1. IP가 같으면 같은 실행이므로 이전 요청 식별자를 모든 비교에 재사용해도 된다
    2. 현재 신원과 초기 환경 보존 조건을 확인하고 새 관측을 해야 하며 낡은 UID를 재사용하면 안 된다
    3. HTTP 출력에 200이 한 번 있으면 Pod UID나 서비스 설정의 변경은 고려하지 않아도 된다
    4. JSON의 UID 문자열만 새 값으로 바꾸면 실제 경로와 요청을 관측할 필요가 없어진다