케이블을 뽑아봐야 링 이중화가 증명된다

링은 200 ms에 복구됐는데 HMI는 30초 동안 멈췄다

링크 여섯 군데를 뽑아봤는데 다섯 군데는 ping 한 개도 안 빠졌다. 나머지 하나, root 근처 판넬 스위치 두 대를 잇는 광 구간에서만 30초가 걸렸고 그동안 Area 2 faceplate는 전부 회색이었다.

원인은 예전 광 보수 때 끼워 넣고 그대로 둔 media converter였다. 그 포트가 half duplex로 잡히니 RSTP가 point-to-point 링크로 보지 않았고, point-to-point가 아니면 proposal/agreement가 동작하지 않는다. 결국 802.1D 타이머로 떨어져서 max age 20초에 forward delay 15초를 다 먹었다. Switch log에는 "topology change" 한 줄뿐이었다. 도면만 봐서는 절대 못 찾는다. 도면에는 선 하나로 그려져 있으니까.

시운전 때 링을 실제로 끊어봐야 하는 이유가 이거다. 링크 LED가 녹색이고 도면에 loop가 그려져 있다는 건 케이블 경로가 맞다는 뜻이지, 복구 시간이나 차단 포트, alternate path의 VLAN 전달, 끊긴 동안 SCADA 클라이언트가 어떻게 되는지에 대해서는 아무것도 말해주지 않는다.

기록에는 "Ethernet ring"이 아니라 방식 이름을 쓴다

방식마다 고장 모양이 거의 안 겹친다. 시운전 기록에 "링 이중화: 적용"이라고만 남기면 1년 뒤에는 아무 쓸모가 없다.

사람들이 제일 많이 오해하는 게 PRP다. 복구 시간이 0인 이유는 빠르게 복구해서가 아니라 복구할 게 없어서다. 두 LAN이 모든 프레임을 그대로 보내고 수신 측이 중복을 버린다. 뒤집어 말하면 PRP 망은 한쪽 LAN이 완전히 죽은 채로 몇 달을 돌아도 운전자 화면에는 아무 증상이 안 나온다. 설계가 PRP라면 시운전 산출물은 스톱워치 기록이 아니라 감시 중인 duplicate discard counter다.

링 도면에 반드시 들어가야 하는 것

링 포트와 일반 uplink 포트. Hostname, 관리 IP, firmware version, 판넬 위치. 어느 스위치가 root / MRM / ring master이고 어느 쪽이 예비인지. Trunk별 VLAN. HMI 서버, historian, PLC, remote I/O, engineering workstation의 연결 위치.

그리고 늘 빠져서 시험을 다시 하게 만드는 항목. 보호 링 경로 안에 있는 모든 unmanaged switch, media converter, wireless bridge, 장비 내장 switch다. 현장 HMI 하나 붙이려고 넣은 5포트 unmanaged switch는 BPDU를 조용히 삼킨다. 01:80:C2:00:00:00 예약 multicast는 원래 bridge가 소비해야 하는데 싼 장비들은 이걸 제각각 처리한다. 그런 장비 뒤쪽으로는 링 프로토콜이 아무것도 못 본다.

시험 순서

통신이 30초 끊겨도 되는 상태에서 한다. 실제로 30초가 나올 수 있기 때문이다. 진짜 operator client, SCADA server, controller, historian collector를 켜 둔 채로 한다. 노트북 하나 놓고 시험하면 ICMP에 대해 알게 될 뿐 시스템에 대해서는 알 수 없다.

1. Switch 시간부터 맞춘다. SCADA 서버가 쓰는 것과 같은 NTP source로. 시계가 4분씩 어긋난 스위치들의 로그를 비교하는 건 정전 시간 낭비다.
2. Managed switch 설정을 전부 백업하고 firmware version을 기록한다.
3. 정상 상태 topology를 남긴다. Blocked port, root bridge ID, MRM/client 역할. 캡처하거나 export해 둔다. 앞으로 스위치를 교체할 때마다 비교할 기준이 이거다.
4. 고정된 test station에서 PLC와 HMI 서버로 timestamp 붙은 ping을 계속 날린다.
5. 링크 하나를 끊는다. 손으로 뽑는다. Port를 shutdown 하면 안 된다. 지금 확인하려는 link-loss 검출 경로를 건너뛰게 된다.
6. 복구 시간을 두 가지로 기록한다. Switch log 기준 L2 convergence, 그리고 HMI에서 운전자가 본 공백 시간.
7. 링크를 다시 꽂고 두 번째 끊김이 있는지 본다. 설계가 어설픈 RSTP는 원래 경로로 되돌아올 때 아프다. 복귀도 topology change다.
8. 다른 위치에서 반복한다. Root나 MRM 바로 옆 링크도 포함한다. Root 근처 단선과 반대편 단선은 동작이 다르다.
9. 설계가 switch 고장까지 견딘다고 하면 영향이 작은 스위치 전원을 내려본다. 링크 단선과 스위치 사망은 같은 시험이 아니다.
10. Log가 buffer에 남아 있을 때 switch event log를 export한다.

운전자가 본 것을 잰다

이 시험에서 ping loss는 가장 약한 신호다. 그 위에 있는 프로토콜들이 timeout도 다르고 복구 비용도 다르기 때문이다.

OPC UA. 짧은 공백은 공짜지만 긴 공백은 subscription을 잡아먹는다. Server는 RevisedLifetimeCount × publishing interval 안에 PublishRequest가 안 오면 subscription을 지우고, Part 4는 그 lifetime이 keep-alive count의 3배 이상이어야 한다고 규정한다. Publishing interval 1초에 lifetime count 60이면 60초 여유가 있다. 250 ms에 lifetime 30이면 7.5초다. 이걸 넘기면 client가 monitored item을 전부 다시 만들어야 하는데, 2만 개짜리 subscription이면 여기서 faceplate 30초 정지가 나온다. 스위치 때문이 아니다.

Modbus TCP. 드라이버는 보통 timeout 1000 ms에 재시도 2~3회라 3초쯤이면 bad quality로 넘어간다. 더 고약한 건 반쯤 열린 socket이다. 상대에게 그 경로로는 더 이상 닿지 않는데도 client는 계속 그 TCP 연결에 쓰고 있고, Linux 기본 tcp_retries2면 스택이 포기할 때까지 대략 15분이 걸린다. 링은 200 ms에 복구됐지만 드라이버는 socket이 죽었다는 걸 통보받은 적이 없다. 다 돌아왔는데 장비 하나만 계속 bad로 남아 있으면 링이 아니라 socket을 보면 된다.

Historian. Store-and-forward 덕분에 trend는 나중에 채워지고 다음 날 아침에 보면 멀쩡해 보인다. 승인 전에 duplicate sample이 있는지, timestamp 기준이 collector 시간인지 장비 시간인지 확인한다.

그래서 결과는 운전자 언어로 쓴다. "RSTP 정상 복구"가 아니라 이렇게. "14:22:31 SW-03 port 7 탈거. Area 2 HMI bad quality 3~5초, 그동안 command button은 정상적으로 disable됨. OPC UA subscription 유지. Historian 4초 backfill, duplicate 없음. 14:31 복귀 시 추가로 2초 공백." 이래야 내년에 누가 보고 비교할 수 있다.

링을 깨뜨리는 네 가지

MAC 주소로 정해진 root bridge. 전부 priority 32768로 두면 MAC이 제일 낮은 장비가 root가 된다. 보통 제일 오래된 놈이고, 자주 제일 손이 안 닿는 판넬에 있다. 그걸 교체하는 순간 active topology가 옮겨간다. 의도한 root를 4096, 예비를 8192로 박아두고, 스위치를 교체할 때마다 실제 root를 다시 확인한다.

Access port를 switch 링크처럼 두는 것. Edge가 아닌 포트에 operator station, 프린터, 노트북이 물려 있으면 부팅할 때마다 topology change가 나고 링 전체 MAC table이 flush된다. Access port에는 edge/portfast를 주고, BPDU guard를 같이 건다. 안 그러면 "edge port"가 "loop 꽂기 좋은 자리"가 된다.

링 밖의 두 번째 경로. 정비용 switch, 잊고 안 뽑은 commissioning 패치 케이블, 사무망 uplink. 원래 링 프로토콜은 그 loop를 제어하지도, 끊지도 못한다. 직접 걸어서 확인하고 LLDP neighbor와 MAC address table로 대조한다. 임시 케이블은 최종 시험 전에 뽑는다. 후에가 아니다.

Alternate path에 VLAN이 빠진 것. L2는 복구되고 HMI도 되는데 historian이나 engineering traffic만 사라진다. 다음 교대 보고서 나올 때까지 아무도 모른다. SCADA가 실제로 쓰는 VLAN과 subnet을 각각 시험한다. 관리 VLAN이 살아 있다는 건 스위치에 접속할 수 있다는 것만 증명한다.

파일을 닫기 전에

설정 백업, firmware version, 역할과 priority 값, 정상 port state table, 시험한 단선 위치와 측정값, 빠른 복구를 지원하지 않는 장비 목록을 남긴다. 그리고 아무도 안 쓰는 한 장을 더 넣는다. 교체용 스위치를 live ring에 물리기 전에 해둘 설정 순서. 새벽 2시에 야간 근무자가 읽을 문서가 그거고, 그게 없으면 공장 초기값 priority 32768짜리 스위치를 그냥 꽂고 새 root bridge를 만들어 놓는다.