네, 알겠습니다. 오늘 긴 시간 동안 진행했던 S32G GoldBox 두 대의 네트워크 연결 문제 해결 과정을 모두 정리하여, 마크다운 형식으로 상세하게 작성해 드리겠습니다.

---

S32G GoldBox 2대 네트워크 연결 문제 해결 및 성능 테스트 종합 보고서

1. 초기 목표 및 문제 상황

1.1. 목표

두 개의 S32G 보드(G3, G2)를 이더넷으로 연결하여, 802.1CB (FRER)와 같은 고급 네트워크 기능 및 기본적인 통신 성능을 테스트한다.

1.2. 초기 문제

두 보드를 물리적으로 연결하고 IP 주소를 할당했음에도 불구하고, 가장 기본적인 ping 통신조차 실패하는 현상이 지속적으로 발생했다.

• 주요 오류 메시지:
  • ping: connect: Network is unreachable
  • From ... icmp_seq=1 Destination Host Unreachable
• 의심 원인: 냉납과 같은 하드웨어 문제, 라우팅 및 방화벽 설정 오류, PFE 드라이버 오작동, OS 이미지 손상 등 다양한 가능성이 제기되었다.

2. 문제 해결 과정 (Troubleshooting)

문제의 원인을 명확히 파악하기 위해, 가장 복잡한 환경에서 시작하여 점차 단순화하고 변수를 통제하는 체계적인 디버깅을 진행했다.

2.1. 시도 1: PFE 하드웨어 브릿지 설정 (libfci_cli 사용)

• 방법: PFE의 하드웨어 스위칭 기능을 직접 제어하는 libfci_cli 유틸리티를 사용하여 L2 브릿지를 구성하고, hif0 인터페이스에 IP를 할당하여 통신을 시도했다.
• 결과:
  • libfci_cli 명령어 실행 시 Failed to connect to libfci_cli daemon. errno= 101 오류 발생.
  • ip addr add ... dev hif0 명령어 실행 시 Device "hif0" does not exist. 오류 발생.
• 분석: PFE 커널 드라이버(pfeng-slave)가 정상적으로 로드되지 않아, 리눅스 스택과 PFE 하드웨어를 연결하는 hif0 인터페이스 자체가 생성되지 않았다. 이는 PFE 기능 전체가 마비된 상태임을 의미한다.

2.2. 시도 2: 리눅스 소프트웨어 브릿지 설정 (brctl 사용)

• 방법: PFE 직접 제어를 포기하고, 리눅스 커널의 표준 기능인 소프트웨어 브릿지를 사용하여 물리 포트(pfe*sl)들을 묶어 통신을 시도했다.
• 결과: ping 실패. G3 보드의 ip route 결과에서 linkdown 플래그가 관찰되었다.
• 분석: linkdown 상태는 커널이 물리적 링크가 끊어졌다고 판단했음을 의미한다. 하지만 ethtool 명령어로 확인했을 때 G3 보드의 pfe0sl 포트는 Link detected: no, pfe1sl 포트는 Link detected: yes로 나타나, pfe0sl 포트 또는 관련 드라이버에 문제가 있음을 특정했다.

2.3. 시도 3: 정상 포트 조합 테스트 (GMAC eth0 활용)

• 방법: 문제가 있는 PFE 포트 대신, 독립적인 GMAC 컨트롤러에 연결된 eth0 포트를 사용하여 통신을 시도했다.
  1. G3(eth0) ↔ G2(eth0) 연결: ping 실패.
  2. G3(eth0) ↔ G2(pfe1sl) 교차 연결: ping 실패.
• 결과: 어떤 포트 조합을 사용하든 G3 보드가 포함된 통신은 모두 실패했다. 이 과정에서 G3 보드의 터미널에 EXT4-fs error ... checksumming directory block 과 같은 파일 시스템 손상 오류가 관찰되었다.
• 중간 결론: G3 보드의 OS 이미지 손상이 커널의 네트워킹 스택 전체에 영향을 미쳐 모든 종류의 이더넷 통신을 불가능하게 만들고 있다는 가설이 가장 유력해졌다.

2.4. 시도 4: QSPI 플래시 재기록 및 최종 검증

• 방법: 모든 문제의 근원으로 의심되는 G3 보드의 OS 손상을 해결하기 위해, U-Boot를 이용해 QSPI 플래시 전체를 GoldVIP 공식 이미지로 재기록했다.
• 결과: 성공. 플래시 재기록 후, G3 보드의 파일 시스템 오류 및 드라이버 오류가 모두 사라졌다.

2.5. 시도 5: 쿠버네티스(K3s) 간섭 확인 및 해결 (최종 원인 규명)

• 문제: 플래시 재기록 후에도 ping이 간헐적으로 실패하는 현상이 발생. iptables -L 명령어로 확인한 결과, K3s 에이전트가 자동으로 복잡한 방화벽 규칙을 생성하여 통신을 방해하고 있음이 확인되었다.
• 해결책:
  1. k3s-agent와 networking 등 관련 서비스를 모두 중지 (/etc/init.d/k3s-agent stop).
  2. iptables와 ip route 테이블을 수동으로 완전히 초기화.
  3. 이후 eth0 포트에 IP를 할당하자 마침내 양방향 ping 통신에 성공했다.

3. 최종 성능 및 기능 테스트 (eth0 포트 기반)

모든 장애물을 제거하고 안정적인 통신 경로를 확보한 후, eth0(GMAC) 포트의 성능을 종합적으로 측정했다.

3.1. iperf3 대역폭 측정

• TCP 단방향: 약 940 Mbits/sec에 근접하는 최대 성능 확인.
• UDP (900Mbps): 0%에 가까운 패킷 손실률과 낮은 Jitter 값을 확인하며 안정적인 데이터 스트리밍 능력 검증.
• TCP 양방향: 동시 송수신 시의 부하 처리 능력 확인.
• 소형 패킷 (PPS): 높은 초당 패킷 처리율을 확인하며 제어 메시지 처리 능력 검증.

3.2. ptp4l 시간 동기화 (802.1AS) 테스트

• 방법: linuxptp 패키지의 ptp4l 도구를 사용하여 한 보드를 마스터, 다른 보드를 슬레이브로 설정하고 L2 멀티캐스트 기반 시간 동기화를 시도.
• 결과: 성공. 슬레이브 측 로그에서 master offset 값이 수십 나노초(ns) 단위로 안정적으로 수렴하는 것을 확인했다.
• 의의: 이 성공은 ping(유니캐스트)뿐만 아니라 L2 멀티캐스트 통신까지 정상적으로 동작함을 증명했으며, 두 보드의 네트워크 하드웨어와 커널 스택이 완벽하게 정상임을 최종적으로 확인시켜 주었다.

4. 종합 결론

초기의 지속적인 통신 실패는 하드웨어 고장(냉납)이 아닌, 두 가지 소프트웨어 문제의 복합적인 작용 때문이었다.

1. G3 보드의 OS 이미지 손상: 파일 시스템 오류로 인해 PFE 및 GMAC 드라이버가 오작동하는 근본적인 원인을 제공했다. (→ QSPI 플래시 재기록으로 해결)
2. GoldVIP 기본 네트워크 서비스의 간섭: K3s(쿠버네티스)와 관련 서비스들이 부팅 시 자동으로 복잡한 iptables 방화벽 및 라우팅 규칙을 생성하여, 수동으로 구성한 테스트 네트워크의 통신을 차단했다. (→ 관련 서비스 중지 및 네트워크 설정 초기화로 해결)

모든 문제를 해결한 결과, 두 S32G 보드는 eth0 포트를 통해 기가비트 이더넷의 최대 성능에 가까운 안정적인 통신이 가능함을 확인했다. 비록 G3 보드의 PFE 드라이버 문제는 플래시 재기록 전까지 해결되지 않아 802.1CB와 같은 TSN 하드웨어 가속 기능은 테스트하지 못했지만, 체계적인 디버깅을 통해 문제의 원인을 정확히 규명하고 시스템의 기본 성능을 성공적으로 검증할 수 있었다.