nxos_ssh의 NAPALM get_optics, QSFP-100G-CWDM4 모듈에서 lane 1 DOM만 반환함
Nexus 9000 패브릭 두 곳의 모니터링에 포트별 광 텔레메트리를 넣는 중입니다. 수집은 NAPALM을 거치고, 주로 쓰는 getter는 get_optics()입니다.
- Nexus 9000 leaf/spine 페어
- 패브릭 링크의 QSFP-100G-CWDM4 모듈
- nxos_ssh 드라이버를 쓰는 NAPALM, SSH 전송, NX-API는 아직 안 켬
4레인 100G 모듈에서 getter가 정확히 채널 하나만 돌려줍니다:
>>> pprint(dev.get_optics()['Ethernet1/49'])
{'physical_channels': {'channel': [{'index': 0,
'state': {'input_power': {'instant': ...},
'output_power': {'instant': ...},
'laser_bias_current': {'instant': ...}}}]}}스위치 자체에는 분명히 데이터가 있습니다 - show interface transceiver details는 네 레인 전부의 Rx power, Tx power, bias current를 찍어줍니다 - 그러니 플랫폼보다는 파서 쪽 문제로 보입니다.
확인해본 것:
- 폴링하는 모든 QSFP-100G-CWDM4 포트에서 결과 동일 - 특정 모듈 하나의 문제는 아님
- SFP+ 포트는 정상적으로 돌아옴 - 보고할 레인이 하나뿐이니 당연함
- 드라이버의 옵틱 파싱 코드를 읽어보니 첫 번째 DOM 블록만 계속 집히는 것으로 보임
NX-OS에서 NAPALM으로 레인별 DOM을 실제로 수집하시는 분 계신가요, 아니면 다들 결국 스위치 출력을 직접 긁어내시나요?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
정확히 NAPALM 버전이 뭔가요, 그리고 그 leaf들은 어느 NX-OS 트레인인가요? nxos_ssh의 옵틱 코드는 한 번 이상 다시 짜였고, 스위치의 트랜시버 출력도 트레인마다 포맷이 똑같지 않아서, 버그라고 부르기 전에 둘 다 중요합니다.
직접 파서를 짜러 가시기 전에 해볼 만한 게 하나 있습니다 - SFP+ 포트 하나에 get_optics()를 호출해서 그 구조를 CWDM4 것과 나란히 놓아보세요. 둘 다 같은 뼈대로 나오고 값만 다르다면, 드라이버가 텍스트를 잘 훑고 있고 그냥 처음 매칭된 블록 뒤에서 포기하는 겁니다. 모양 자체가 다르다면, QSFP 포트에서는 레인별 섹션에 아예 도달을 못 하는 겁니다. 이 둘은 고치는 방법이 다르고, SFP+ 출력이 둘을 구분하는 가장 싼 방법입니다.
두 수집기 다 PyPI 최신 릴리스고, leaf와 spine 모두 같은 NX-OS 트레인입니다. 그러니 어디를 가리키든 똑같은 게 돌아옵니다 - 특정 장비 하나의 문제가 아닙니다.
요청하신 SFP+ 비교도 해봤습니다. 두 경우 다 뼈대는 같습니다 - index 0에 원소 하나짜리 physical_channels.channel, 값 세 개 다 채워져 있습니다. 1레인 모듈에는 맞는 답이고 CWDM4에는 틀린 답이죠. 그러니 파서가 출력의 레인별 부분을 못 찾는 게 아니라, 블록 하나에 매칭해서 채우고 거기서 멈추는 겁니다. 코드를 읽어봤을 때도 그렇게 보였는데, 제가 잘못 읽은 게 아니라는 걸 누가 확인해주길 바랐습니다.
이건 여러분 쪽 문제라기보다 드라이버의 공백입니다. nxos_ssh에 옵틱 파싱을 다시 짠 오픈 PR이 있습니다 - 훑기가 index 0에서 멈추는 대신 모든 레인이 physical_channels.channel 아래 자기만의 원소로 돌아오고, 각 원소가 자기 Rx 레벨, Tx 레벨, laser bias current를 갖습니다. 같이 딸려오는 픽스처가 4레인 QSFP-100G-CWDM4로 만들어져 있어서, 정확히 여러분 모듈을 대상으로 작성된 겁니다. 저는 랩 장비에서만 돌려봤으니, 운영 수집기에 대한 추천이라기보다 시도해볼 만한 것 정도로 받아들이세요.
설치 가능한 릴리스에 들어오기 전까지는, 100G 포트에 대해서는 getter를 건너뛰고
show interface transceiver details를 직접 파싱한 다음 각 레인을 모니터링에 별도 시리즈로 밀어넣는 게 현실적인 방법입니다. 직접 관리할 코드는 조금 늘지만, 신호의 4분의 3을 버리는 건 멈추게 됩니다.어느 쪽으로 가시든 레인별로 알람을 거세요. CWDM4에서 레인 하나가 열화되면 lane 1만 보고 있을 경우 전혀 드러나지 않으면서도 링크 전체를 끌어내릴 수 있습니다.
레인별 가시성은 Nexus에서 사람들 생각보다 더 중요합니다.
저희는 QSFP-100G-SR4-S를 4x25G로 쪼갠 Nexus 9000에서 Cloud Scale 결함에 걸린 적이 있습니다. 25G 포트 네 개 중 하나만 필요했고 나머지 셋은 계속 닫아뒀는데, 정작 필요했던 그 하나가 절대 링크되지 않았습니다. 거기서 빠져나온 방법은 서브인터페이스 네 개 전부를 - 각각에
no shutdown을 걸어 - 먼저 그룹째로 올려서 lane 1이 자리잡게 한 다음, 예비 세 개를 다시 닫는 거였습니다. 그러는 동안 그룹 전체에서 FEC도 동일하게 맞추세요 - 레인 하나에 다른 설정이 걸려 있으면 그 레인에만 얌전히 머물러주지 않습니다.요점은, 대시보드에 lane 1만 있으면 100G 포트가 하는 일의 대부분을 못 보고 있다는 겁니다. 추가 파싱을 직접 관리할 가치가 있습니다.