クイズ：経路広告とパケット転送の証拠

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

• 해당 피어의 peerASN을 65002로 맞추고 주소와 sourceInterface는 보존한다
• 노드 PodCIDR을 65003과 같은 숫자로 바꾸고 광고를 다시 생성한다
• 서비스 VIP를 삭제해 FRR이 다른 AS로 연결을 다시 시작하게 한다
• FRR에 기본 경로를 추가해 BGP OPEN의 AS 검사를 우회한다

rib 라우터에는 PodCIDR의 유효한 BGP 최선 경로가 있지만 FIB에는 연결망만 있다. 실습에서 이 비교를 유지하는 이유는?

• BGP 연결을 유지하려면 모든 외부 라우터에서 커널 경로를 꺼야 하기 때문이다
• 경로 학습과 커널 전달 경로 설치가 별개의 단계임을 정상 전달 라우터와 비교하기 때문이다
• PodCIDR 광고는 서비스 VIP와 달리 원래 실제 패킷 전달에 사용할 수 없기 때문이다
• 커널 경로가 없는 상태에서도 HTTP 200이 보장되므로 서비스 장애만 검사하기 때문이다

selected와 excluded 서비스가 같은 정상 Pod를 가리키며 서로 다른 VIP를 받았다. 선택 광고의 성공을 증명할 관측은?

• 두 서비스의 status에 IP가 있으므로 외부 라우터의 경로 관측은 생략한다
• selected가 200이면 excluded에 기본 경로를 넣고 같이 성공하도록 고친다
• selected /32와 200을 확인하고 excluded 경로 부재·연결 실패도 함께 확인한다
• Pod IP에 직접 접속해 200이면 두 서비스의 광고 선택자는 모두 올바르다고 판단한다

cca-withdraw 광고를 삭제한 뒤 피어는 Established이고 목적지 RIB/FIB가 사라졌다. cca-retire 서비스 UID와 정상 Pod는 유지된다. 맞는 해석은?

• 서비스가 삭제됐으므로 경로가 사라졌고, 같은 이름으로 다시 만들면 같은 서비스다
• BGP 세션이 끊겼으므로 Established 출력은 의미가 없고 무조건 재시작해야 한다
• BGP가 서버의 HTTP 프로세스를 중단시켰으므로 애플리케이션 배포를 롤백해야 한다
• 서버·피어를 유지하면서 광고 철회의 전달 영향을 분리한 상태이며 실제 요청도 대조해야 한다

커널 JSON에서 VIP 목적지가 203.0.113.10으로 표시됐다. 과제의 /32 경로인지 판단할 때 맞는 방법은?

• IP/CIDR를 정규화하고 BGP 프로토콜·다음 홉·장치까지 함께 대조한다
• 문자열에 /32가 없으므로 BGP 학습 여부와 관계없이 잘못된 경로로 처리한다
• IP 숫자만 일치하면 정적 경로·기본 경로·다른 장치도 같은 답으로 처리한다
• FIB 표시가 간결하면 RIB와 실제 요청은 확인하지 않고 자동으로 통과시킨다

보고서 작성 뒤 서버 Pod가 재생성되어 IP는 같지만 UID가 바뀌었다. 보고서를 그대로 제출해도 될까?

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