OSPF 최대 메트릭: 분기를 제거하지 않고 트랜짓을 억제하기

두 사무실이 자체 트래픽과 아주 적은 다른 트래픽만 실어야 하는 분기를 통해 연결되어 있습니다. 분기는 두 사이트 모두로 가는 경로가 필요하고, 어느 사이트도 분기를 두 사이트 사이의 경로로 선호해서는 안 됩니다. 분기를 토폴로지에서 제거하면 트랜짓 문제는 해결되지만 요구 사항이 깨집니다. 분기는 여전히 두 사이트에 도달해야 하고 두 사이트도 여전히 분기에 도달해야 하기 때문입니다.

필요한 것은 라우팅 프로토콜에 표현된 선호도이며, 분기를 완전히 도달 가능하게 두면서 분기를 통과하는 모든 것에 대해 나쁜 선택으로 만드는 것입니다. 라우터가 보는 순서대로 문제를 따라가십시오.

피하고 싶은 경로에서 시작하기

토폴로지를 다이어그램이 보는 모습이 아니라 프로토콜이 보는 모습으로 그리십시오. 어떤 인터페이스가 인접 관계를 형성하는지, 어느 것이 같은 영역에 있는지, 그리고 분기가 선호된다면 그 인접 관계 중 어느 것이 두 사무실 사이의 트래픽을 실을지. 이는 세 가지 별개의 질문이며 다이어그램은 어느 것에도 신뢰할 만한 답을 주지 않습니다.

그다음 대체 경로를 찾으십시오. 사무실 사이의 유일한 경로가 분기를 지난다면 어떤 메트릭도 트래픽을 그곳에서 옮길 수 없습니다. 트래픽이 갈 곳이 없기 때문입니다. 중복성은 이 설계의 세부 사항이 아니라 전제 조건입니다. 서류상으로만 존재하는 두 번째 경로는 셈에 들지 않습니다.

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

이 세 가지 보기는 서로 다른 질문에 답합니다. 누가 인접한지, 어떤 인터페이스가 어떤 비용으로 참여하는지, 그리고 장치가 현재 어떤 경로를 선택하는지. 터널 배포는 네 번째를 더합니다. 다이어그램의 선은 그 위로 인접 관계가 형성되었다는 증거가 아니고, 형성된 인접 관계는 포워딩이 같은 경로를 따른다는 증거가 아닙니다. 터널 설계에서 이 간극이 가장 자주 드러납니다.

최대 메트릭이 광고하는 것

RFC 6987은 비-stub 링크를 최대 링크 메트릭으로 광고하는 라우터를 설명하며, 이 값은 0xffff로 정의됩니다. 라우터는 여전히 자신과 링크를 기술하지만, 범위의 맨 위로 값을 매기므로 다른 모든 라우터는 그를 지나는 경로를 비싸게 계산합니다.

이것은 router-LSA 변경이며 토폴로지 제거가 아닙니다. 구분이 중요합니다. router-LSA를 플러시하면 토폴로지 정보 자체가 철회되고, 라우터와 그 뒤의 프리픽스에 도달하는 데 필요한 관계도 철회될 수 있습니다. 광고를 유지하고 가격을 올리면 그 관계가 보존됩니다. 이것이 이 기법과 제거의 차이 전부입니다.

RFC 6987 메커니즘은 영역 유형이나 지정 라우터 선출과도 무관합니다. stub 영역은 영역 경계에서 링크 상태 광고의 한 범주를 차단하고, stub 라우터는 자신의 링크에 값을 매깁니다. 비슷한 단어지만 무관한 기계입니다.

도달 가능성은 남고 트랜짓은 남지 않는 이유

다른 라우터는 여전히 분기의 연결된 프리픽스로 가는 경로를 가집니다. 분기가 여전히 그것들을 광고하고 링크가 여전히 존재하기 때문입니다. 달라지는 것은 다른 곳으로 가는 도중 분기를 지나는 모든 경로의 총비용입니다. 프리픽스는 움직이지 않고 라우터를 건너는 가격만 바뀝니다.

출발지나 목적지가 분기 자체인 트래픽에는 비싼 링크가 여전히 유일하게 합리적인 경로에 있으므로 사용됩니다. 두 사무실 사이의 트래픽에는 이제 대체 경로가 비용에서 이기고, 분기는 토폴로지에서 사라지지 않은 채 포워딩 결정에서 빠집니다. 두 방향, 두 가지 다른 답이며 둘 다 메커니즘이 작동하고 있음을 보여줍니다.

이것이 가정이 아니라 검증해야 할 동작입니다. 분기가 생성하는 router-LSA를 보고, 그다음 분기 뒤의 목적지와 다른 사무실의 목적지에 대해 다른 라우터가 선택하는 경로를 보십시오. 두 답은 달라야 하며, 다르지 않다면 메트릭 변경이 생각하는 결정에 도달하지 못하는 것입니다.

마지막 경로 문제

같은 RFC는 이 기법이 사용을 금지하지 않는다고 분명히 밝힙니다. 대체 경로가 실패하면 라우터는 분기를 지나는 비싼 경로로 되돌아갑니다. 여전히 유효한 경로이고 프로토콜은 경로가 없는 것보다 비싼 경로를 선호하기 때문입니다.

그 폴백이 허용 가능한지는 배포 전에 답해야 할 정책 질문입니다. 작은 업링크의 분기가 갑자기 사무실 간 트래픽을 실으면 장애보다 나쁠 수 있고, 유지보수 창에서는 정확히 원하는 것일 수도 있습니다. 두 답 모두 정당하며 침묵은 그렇지 않습니다.

요구 사항이 선호가 아니라 엄격한 금지라면 메트릭 설계만으로는 그것을 만들어내지 못합니다. 의도에 맞는 포워딩 강제와, 트래픽이 그래도 도착할 경우를 위한 정의된 동작이 필요합니다. 경로를 사용 가능하다고 광고한 뒤 트래픽을 버리면 라우팅 루프보다 진단하기 어려운 블랙홀이 생깁니다.

OSPFv3의 경우 RFC는 R 비트를 트랜짓 참여를 배제하는 다른 방법으로 논의합니다. 최대 메트릭 기법과 같은 마지막 경로 동작을 상속한다고 가정하지 말고, 두 주소 체계 사이에서 같은 기능인 것처럼 설정을 복사하지 마십시오.

정상 및 장애 조건에서 증명하기

두 번 시험하십시오. 한 번은 두 경로가 모두 사용 가능한 상태에서, 한 번은 선호 경로를 제거한 상태에서. 첫 번째 시험은 선호가 작동함을 보여주고, 두 번째는 선호를 지킬 수 없을 때 네트워크가 무엇을 하는지 보여줍니다. 두 번째 시험을 건너뛰면 중요한 절반이 검증되지 않은 채 남습니다.

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

데이터베이스 보기는 광고된 메트릭을 보여주고, 경로 조회는 선택된 다음 홉을 보여주며, 추적은 패킷이 실제로 어디로 갔는지 보여줍니다. 이 셋이 일치하면 올바르게 보이는 구성이 아니라 검증된 설계를 가진 것입니다.

그다음 선호 경로를 복원하고 분기가 자기 트래픽만 실어 나르는 상태로 돌아오는지 확인하십시오. 복원 단계는 정리가 아니라 시험의 일부입니다. 다음 변경까지만 작동하는 설계는 설계가 아니기 때문입니다. 폴백을 포함한 두 결과를 모두 적어 두십시오. 두 번째가 누군가 새벽 세 시에 필요로 할 답이기 때문입니다.