이번 글에서 다룰 Link-flap이 무어냐 묻는다면, Cable이나 SFP와 같은 물리적인 단계(Layer 1)에서 발생하는 장애로서 링크 상태가 Up과 Down을 빠르게 반복하는 장애 현상을 말한다.
Cisco Catalyst에서는 Link-flap errdisable의 trigger condition을 변경하고자 한다면 Config mode에서 일반 command(errdisable flap-setting cause link-flap {flap-count / max-flaps} [flap-count] time [seconds])를 입력하는 것이 전부이나, Cisco Nexus는 명령어가 다르다!
데이터 센터에 들어갈만큼 기능 많고, 성능 좋은, 비싼 장비. 가격이 높은 만큼 소비자들에게 매력적으로 느껴지게끔 더 까리하게(!) 보일려면 뭐랄까, 최신 트렌드인 programmable한 느낌을 줘야 할 것이기 때문이다.
Python 지원은 Catalyst에선 guestshell을 enable함으로써 가능하지만 Nexus에선 기본적으로 지원되는 것부터 그 차이점을 느낄 수 있을 텐데, 기본 기능마저 programmable한 느낌이 들도록 만들려면 어떻게 해야할까?
…아아, 이렇게까지 말했는데 Catalyst 장비들처럼 Interface에 직접 link-flap error-disable count [count] interval [seconds]를 입력하겠다니, 너무한 사람.
물론 저것만으로 충분하지만, 뭔가 있어보이는 느낌을 주려면 이미 우리 모두가 아는 EEM(Embedded Event Manager)을 사용하면 된다. Catalyst도 EEM이 지원되지만, 지금은 잠시 못 본 척 눈을 돌리자.
이 얼마나 절차지향적인가! EEM을 보면 절차지향적인 건 전부 Programmable한 기능처럼 보이지 않는가!?
[Cisco Catalyst IOS-XE]
Switch# show errdisable flap-values
ErrDisable Reason Flaps Time (sec)
----------------- ------ ----------
pagp-flap 3 30
dtp-flap 3 30
link-flap 5 10
[Cisco Nexus NXOS]
Switch# show event manager policy-state __ethpm_link_flap
Policy __ethpm_link_flap
Cfg count : 5
Cfg time interval : 10.000000 (seconds)
Hash default, Count 0코딩 지식이 있는 사람들은 알겠지만, 일반적으로 언더바(_)를 함수나 변수에 prefix로 붙인다는 것은 시스템 변수 또는 내부 처리(private)를 위함인 것을 알 수 있다. 이에 따라 Link-flap을 처리하는 default Trigger Event 이름은 system default임을 강조하기 위함인지 __ethpm_link_flap인 걸 확인할 수 있다.
Cisco 공식문서 중 하나의 내용을 보면 위와 같이 Catalyst(IOS-XE)의 default value와 동일하게 10초 내 5회 flap 발생 시 err-disable 상태에 빠지는 것처럼 작성되어 있으나, 실제로는 아래와 같이 조금…아주 많이 다르다.
Switch# show event manager policy-state __ethpm_link_flap
Policy __ethpm_link_flap
Cfg count : 30
Cfg time interval : 420.0 (seconds)
Hash Count Policy will trigger if
----------------------------------------------------------------
Eth1/1 0 30 more event(s) happen in 420.0 sec이는 NXOS System Management Configuration Guide에서도 확인이 가능한데, 위와 같이 default값이 420초(7분) 내 30회…단순 횟수 조건으로는 값을 너무 여유롭게 준 것 아닌가 싶다가도 전체 시간에 비하면 묘하게 빡빡한 느낌을 받게 되는 조건이라 할 수 있겠다.
이 __ethpm_link_flap이라는 EEM 정책의 ethpm은 아마 ethernet port manager 따위가 아닐까 싶지만, 지금은 넘어가도록 하자.
핵심은 앞서 말했던 Programmable한 방식으로, 우리가 EEM 정책에 손을 대고자 한다면 System적으로 선언된 Policy를 직접 수정하는 것이 아닌 Override(덮어쓰기)를 통해 기존 정책의 동작을 이어받으면서도 조건만 고치면 되는 것이다!
event manager applet ethport override __ethpm_link_flap
description “Overrides link flap policy.”
event policy-default count 2 time 1000
action 1.0 syslog priority warnings msg “Link is flapping.”상기 EEM 명령어를 한 줄씩 분석해보면 다음과 같다.
- __ethpm_link_flap EEM 정책을 ethport라는 명칭의 정책(applet)으로 override한다.
- ethport라는 명칭의 정책(applet)에 대한 description
- 해당 정책에 따른 Link-flap errdisable 조건을 1000초 내 2회로 변경
- logging에 warning(-4-) level의 메시지 Link is flapping을 남김
이중 description을 선언하는 2번과 action을 명시하는 4번은 생략 가능하니, 실제 동작에 필요한 건 override applet 선언과 event policy-default count [flap count] time [seconds] 뿐이다.
action 명시에 따라서는 문제가 발생한 interface를 err-disable 상태로 남겨두는 것이 아니라 일찌감치 shutdown해버릴 수 있다.
event manager applet ethport override __ethpm_link_flap
event policy-default count 2 time 1000
action 1 cli conf t
action 2 cli int eth1/1
action 3 cli shutdown상기 applet은 1000초 내 2회의 flapping을 탐지한 경우 eth1/1 인터페이스를 죽이는 것으로 보인다. 아직 테스트해보지 않았기도 하고, 상기에 링크해둔 Cisco 공식문서에서 발췌했음에도 얘네가 찐빠를 내서 직접 일부 내용을 수정해야 했다.
개인적으로 EEM이 재미난 기능이긴 한데, 예쁘게 한 곳에 정리된 문서가 좀처럼 보이지 않는 듯하다. 나중에 시간 나면 EEM 테스트 게시글도 작성해보고 싶다.
3줄 핵심
- NXOS에서 link flap error-disable 발생 조건 변경은 interface 레벨에서 link-flap error-disable count [count] interval [seconds] 설정해주면 된다.
- NXOS에서의 link flap error-disable 발생 default value는 420초에 30회이다.
- EEM으로 __ethpm_link_flap을 override하는 방법으로도 설정할 수 있다. (추가 확인이 필요하나, 1번에 적어둔 command가 EEM override 설정보다 앞서 적용되는 것으로 보인다.)
2026.01.29 수정
- interface 레벨에서 link-flap error-disable count command를 통한 설정이 가능하다는 부분 내용 추가
답글 남기기