'layer 3'에 해당되는 글 2건

  1. 2013.02.27 Nexus 스위치로 전환 시, 이슈 - 2 (1)
  2. 2013.02.06 Nexus - NX-OS 정리 Part 18(vPC:Loop Prevention/Layer3) (1)

지난 번, Proxy-arp에 이어서 이번 포스팅도 기존 6500 스위치에서 Nexus로 변경 후에 발생했었던 이슈에 대한 정리입니다.

이번 정리 내용은 Routing 프로토콜에 관한 부분입니다.

 

 먼저 전체적인 간략한 구성을 보면 다음과 같습니다. 지난 번 구성과 거의 같지만, 다른 이슈이기 때문에 하단 구성이 다릅니다.

 

 

 

작업 전, 구성은 이렇습니다.

간략하게 OSPF 설정도 포함했습니다. 동일 네트워크 대역에 대해서 단순히 network 선언해서 현재 통신 중인 상태입니다.

그 상태에서 아래와 같이 6500스위치의 전원을 내리고 나니 아래와 같은 로그가 3750 스위치에서 발생을 하기 시작합니다.

 

 

저런 식의 로그가 지속적으로 올라오면서, 정상적으로 Neighbor를 맺지 못하고 있었습니다.

 

6500장비의 전원을 내리자마자, 바로 왜 저런 문제가 발생을 했을까요?

 

 그것은 vPC 구성 시에, Routing Protocol에 의한 Neighbr 맺는 부분에 대해서 구성이 가능한 Design과 구성이 불가능한 Design이 존재하기 때문입니다. 이전 포스팅에서 간략하게 그 부분에 대해서도 정리가 되어 있긴 하지만, 전체적으로 다시 좀 더 자세하게 정리해서 포스팅 할 예정입니다.

 

여기서 간략하게 2줄로 정리를 하면,

 

• vPC Domain상에서 Layer 2 Port-channel을 통해서 RouterRouting 연결을 하려고 할 경우에 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을 운영하는 장비를 추가로 붙이게 될 때도 고려해야 하는 이슈이기 때문에 구성을 잘 고려해서 선택해야 할 것 같습니다.

Posted by 네떡지기

이번에 포스팅을 하면서... 이번에 올려야 하나.. 또 좀 더 정리를 해야 하나... 하다가..

쪼개더라도.. 역시.. 그냥 올리는게 나을 거 같다는 생각으로 올려봅니다..

요즘 조금 몸과 마음이 힘든 상태인지라.. 더 정리가 잘 안되는듯.. 한건.. 아마도 핑계겠지요... ^^;


vPC check (Loop Prevention)

• vPC 에서 vPC Member Port로 들어온 PacketPeer-link를 통해서 다시 vPC Member Port로 전송이 될 경우에, 동일한 Packet이 중복되어서 목적지에 도달하고, 동일한 Source Mac-Address에 대해서 서로 다른 Port에서 Learning하게 되어 Loop가 발생할 수 있다.

이처럼 Peer-link를 통해서 들어온 PacketvPC Member Port를 통해서 나가는 경우에 발생할 수 있는 문제점들로 인해서,

  vPCControl Plane 대신에 Data Plane을 통해서 Loop를 회피한다. CPU를 사용하지 않고, vPC Peer-link port가 있는 Hardware

  모든 Logic이 구현되어 있어서 Peer-link들어오는 PacketvPC가 동작 중인 Port를 통해서 나가지 않도록 Egress Port ASICs

  서 모두 Drop 시킨다.  이것을 VPC check’라고 하며, 모든 Traffic(Layer 2, Layer 3, Unicast, multicast, broadcast, flooded )에 대

  해서 적용된다.  물론, Peer-link를 통하더라도 vPC가 동작하지 않는 Port로는 정상적으로 Packet이 전송 된다

 , vPC Member PortDown될 경우 예외적으로 vPC peer DeviceMember Port상태와 vPC Loop avoidance logic을 재 프로그

  램하여 peer-link가 최적의 복구를 위한 백업 경로로써 사용이 된다

 

 

 

 

 

 

vPC Layer 3 Designs

• Layer 3 DevicevPC를 사용하여, vPC Domain에 연결하는 것은 구성은  vPC loop avoidance rule 때문에 지원되지 않는다.

• Laver 3 DevicevPCDomain에 연결하고자 할 때에는 Layer 3 link로 각각의 vPC Peer Device에 연결해야 합니다.

vPC Domain상에서 Layer 2 Port-channel을 통해서 RouterRouting 연결을 하려고 할 경우에 neighbor를 맺을 때 vPCPeer 

  과의 neighbor를 직접 맺지 못하고, 각각의 Peer와 연결된 vPC Port로 분산되서 통신을 하기 때문에 정상적인 neighbor을 맺을 수

  없다.  따라서, vPC Domain에서는 해당 vPC가 동작 중인 vPC PortRouting Protocol이 동작 중인 장비를 연결하면 안된다.

• vPC DomainLayer 3 Device를 연결하는 것은,  Layer 3 Device에서 HSRP addressStatic route를 하는 구성은 가능하다.

만약 RoutedBridged Traffic을 동시에 운용하기 위해서는 Routed  Traffic 위한 개별 layer 3 LinkBridged Traffic를 위한

  Layer 2 Port-Channel별도의 Link구성해야 한다

 

 

 

Posted by 네떡지기

티스토리 툴바