지난 번, Proxy-arp에 이어서 이번 포스팅도 기존 6500 스위치에서 Nexus로 변경 후에 발생했었던 이슈에 대한 정리입니다.
이번 정리 내용은 Routing 프로토콜에 관한 부분입니다.
먼저 전체적인 간략한 구성을 보면 다음과 같습니다. 지난 번 구성과 거의 같지만, 다른 이슈이기 때문에 하단 구성이 다릅니다.
작업 전, 구성은 이렇습니다.
간략하게 OSPF 설정도 포함했습니다. 동일 네트워크 대역에 대해서 단순히 network 선언해서 현재 통신 중인 상태입니다.
그 상태에서 아래와 같이 6500스위치의 전원을 내리고 나니 아래와 같은 로그가 3750 스위치에서 발생을 하기 시작합니다.
저런 식의 로그가 지속적으로 올라오면서, 정상적으로 Neighbor를 맺지 못하고 있었습니다.
6500장비의 전원을 내리자마자, 바로 왜 저런 문제가 발생을 했을까요?
그것은 vPC 구성 시에, Routing Protocol에 의한 Neighbr 맺는 부분에 대해서 구성이 가능한 Design과 구성이 불가능한 Design이 존재하기 때문입니다. 이전 포스팅에서 간략하게 그 부분에 대해서도 정리가 되어 있긴 하지만, 전체적으로 다시 좀 더 자세하게 정리해서 포스팅 할 예정입니다.
여기서 간략하게 2줄로 정리를 하면,
• vPC Domain상에서 Layer 2 Port-channel을 통해서 Router와 Routing 연결을 하려고 할 경우에 neighbor를 맺을 때 vPC의
Peer들과의 neighbor를 직접 맺지 못하고, 각각의 Peer와 연결된 vPC Port로 분산되서 통신을 하기 때문에 정상적인 neighbor
을 맺을 수 없다.
그렇다면, 6500을 끄기 전에는 왜 저런 문제가 발생하지 않았을까요?
이미 기존 OSPF 구성에서는 DR, BDR이 6500 스위치였기 때문입니다. OSPF 구성 시에, DR과 BDR이 이미 존재할 경우에는 그보다 우선순위가 높은 스위치가 추가되더라도, DR과 BDR이 바뀌지 않기 떄문입니다. (OSPF Process를 재기동하지 않는 이상)
작업 시에, 전원을 내리면서 새롭게 DR과 BDR이 Nexus 스위치로 변경이 되면서 위와 같이 vPC에서 지원이 되지 않는 Layer 3 Design이 만들어 지면서 이상 로그가 발생을 한 것이었습니다.
그럼 저 문제점을 어떻게 해결을 해야 할 것인지요..
Cisco의 vPC관련 문서에서 vPC에서 Routing Protocol과 관련해서 지원되는 Design 중에 가장 권고하는 Design으로 변경을 했습니다. 그래서 구성은 아래와의 구성과 같이 변경 작업을 했습니다.
Nexus 스위치와 3750 스위치 간의 Link를 Layer 3 Interface로 변경을 하고, ospf를 point-to-point 직접 연결해서 Neighbor을 맺었습니다. 기타 다른 방식으로도 물론 연결이 가능하긴 합니다만, 이러한 Design을 가장 권고하고 있습니다.
기타 다른 구성 방식에 대한 부분은 위에서도 언급했지만, 다시 포스팅 할 예정입니다.
구성을 위와 같이 바꾸고 나서는 물론 지금 정상적으로 잘 운영되고 있습니다.
이 이슈는 Nexus로 전환하는 경우 이외에도 기존 Nexus 운용 중인 상황에서 Routing Protocol을 운영하는 장비를 추가로 붙이게 될 때도 고려해야 하는 이슈이기 때문에 구성을 잘 고려해서 선택해야 할 것 같습니다.
