NetDoc.pl — monitoring i utrzymanie sieci. Piszemy o sprzęcie, który sami uruchamiamy i mierzymy.

Sieć UniFi

Gdzie w danych UniFi
siedzi topologia

Szukasz sąsiada i znajdujesz w tabeli portów pole z „lldp" w nazwie, ustawione na prawie wszystkich portach. To flaga, a nie sąsiad. Prawdziwe połączenia leżą o piętro wyżej — i w trzecim miejscu jeszcze raz, inaczej.

Pole z „lldp" w nazwie to nie sąsiad

Chcesz wiedzieć, co jest wpięte w który port. Otwierasz tabelę portów, szukasz pola z „lldp" w nazwie i znajdujesz je od razu. Temat wygląda na załatwiony.

Znalazłeś lldpmed_enabled. To flaga konfiguracyjna. Mówi, że port ma włączone rozszerzenie protokołu, a nie kto siedzi po drugiej stronie kabla. Na naszym switchu 24-portowym stała na true na 22 portach z 26.

Ta liczba jest zdradliwa. 22 z 26 wygląda jak „prawie wszystko rozpoznane" i zachęca, żeby przestać szukać. Tymczasem w tabeli portów nie ma sąsiada — ani jednego pola z adresem czy nazwą urządzenia po drugiej stronie.

Tabela portów odpowiada za co innego: za stan portu i pobór mocy. To dane o naszym końcu kabla, nie o drugim.

Wszystkie liczby niżej pochodzą z pomiaru 6 września 2026, godz. 09:52–09:55, na działającej instalacji: brama UDM-Pro z UniFi OS 5.1.31 i UniFi Network 10.6.101, switch 24-portowy PoE (7.4.1.16850) i switch 5-portowy (2.1.6.762). Robiliśmy wyłącznie odczyty.

Sąsiedzi leżą o piętro wyżej, przy urządzeniu

Prawdziwa lista sąsiadów wisi przy urządzeniu, w osobnej tabeli, a nie przy porcie. Na naszym switchu 24-portowym miała 5 wpisów, przy 26 portach.

Oto wszystkie pięć wpisów, z poborem mocy dołożonym z tabeli portów:

Nasz portAdres sprzętowy sąsiadaEtykieta portu po tamtej stronieNazwa portu u nasPobór PoE
2d0:21:f9:85:54:85D0:21:F9:85:54:87Port 20,00 W (zasilanie wyłączone)
42c:33:11:80:7c:f8Gi0Port 410,80 W
500:90:e8:62:bf:ed1Port 50,00 W (zasilanie wyłączone)
148c:94:1f:fc:15:44Gi0Port 14 iot test9,70 W
1810:b3:d6:73:b3:5aGi0Port 1813,40 W

Pola nazywają się tak: numer naszego portu to local_port_idx, adres sąsiada to chassis_id, etykieta po tamtej stronie to port_id, a nazwa naszego portu to local_port_name.

Jedna kolumna udaje coś, czym nie jest. Nazwa portu u nas to etykieta wpisana ręcznie w kontrolerze, a nie informacja od sąsiada. Ktoś nazwał port Port 14 iot test i tak zostało. Sąsiad o tej nazwie nie wie i nigdy jej nie przysłał.

Ma to praktyczny skutek. Etykietę ktoś zmieni w każdą środę, numer portu zostaje. Połączenie w mapie opieraj więc na numerze.

Po czym poznasz, że masz właściwą tabelę

Wpisów jest mniej niż portów, a każdy ma wypełniony adres sprzętowy w polu chassis_id. Jeśli widzisz tyle wpisów, ile portów, i same wartości true albo false, patrzysz wciąż na tabelę portów.

Port 10 pobiera 3,70 W i nie ma sąsiada

Cztery porty naszego switcha pobierały moc. Trzy z nich mają wpis w tabeli sąsiadów. Port 10 nie ma żadnego, a pobiera 3,70 W.

Coś jest tam zasilane i się nie przedstawia. Powodów może być kilka i żadnego nie sprawdziliśmy. Ważny jest sam wniosek: brak wpisu nie znaczy „nic tam nie ma", tylko „nie wiemy, co tam jest".

Różnica między tymi dwoma zdaniami decyduje o tym, czy mapa kłamie. Port pusty i port z milczącym urządzeniem wyglądają w tabeli sąsiadów identycznie — nie ma ich tam obu.

Zbiory nie pokrywają się też w drugą stronę. Porty 2 i 5 mają sąsiada i pobierają 0,00 W. To nie brak odczytu, tylko zmierzone zero.

Powiedziały nam to trzy pola. poe_power miało 0.00, port_poe było prawdą, a poe_enable fałszem. Port potrafi więc zasilać, sąsiad jest podłączony, a zasilanie akurat na tym porcie jest wyłączone.

Tak wygląda trzeci rodzaj sąsiada: widoczny, podłączony i nieprzyjmujący prądu ze switcha, bo ma własny zasilacz. Pięć wpisów i cztery zasilane porty dają razem tylko trzy porty wspólne, więc żadne z tych dwóch źródeł nie mieści w sobie drugiego.

Nazwy sąsiada nie ma, a i tak wiesz, że to obcy sprzęt

Pole system_name było puste we wszystkich pięciu wpisach. To nie usterka jednego wpisu, tylko zachowanie wydania, które zmierzyliśmy.

Zostają Ci dwie rzeczy: adres sprzętowy sąsiada i etykieta jego portu. I właśnie etykieta mówi najwięcej, choć wygląda na drobiazg.

Etykieta portuIle wpisówCo z niej odczytasz
Gi03konwencję Cisco — port nazwany od rodzaju łącza, nie od numeru w obudowie
11coś prostszego: urządzenie numeruje porty po kolei i nic do numeru nie dokłada
D0:21:F9:85:54:871urządzenie, które nie nazywa portów wcale — w polu portu podaje adres sprzętowy samego gniazda

Teraz najmocniejszy wniosek z tego pomiaru. Wszystkie trzy porty z etykietą Gi0 pobierają PoE: 10,80 W, 9,70 W i 13,40 W. W switch UniFi wpięte są więc trzy obce urządzenia, zasilane tym samym kablem, którym się przedstawiają.

Rozpoznaliśmy je bez logowania się do nich. Nie znamy do nich hasła i nie mamy trasy do ich sieci zarządzającej. Wystarczyło jedno zapytanie do kontrolera, który nimi wcale nie zarządza.

To trzy osobne urządzenia, a nie jedno wpięte trzema kablami. Ich adresy różnią się już na pierwszych bajtach: 2c:33:11:80:7c:f8, 8c:94:1f:fc:15:44 i 10:b3:d6:73:b3:5a.

Konwencja to nie producent. Etykieta Gi0 mówi, w jakim stylu urządzenie nazywa swoje porty, i nic ponadto. Nazwę potwierdź po adresie sprzętowym, ze swojej listy urządzeń.

Wpis z portu 2 ma jeszcze jedną pułapkę. Adres w polu portu, D0:21:F9:85:54:87, różni się od adresu urządzenia d0:21:f9:85:54:85 ostatnim bajtem. Tak ma być: pierwszy wskazuje całe urządzenie, drugi konkretny port.

Groźniejsza jest druga różnica. Jedno pole przyszło małymi literami, drugie wielkimi, i tak podał je kontroler. Kto zestawia te adresy jako tekst, nie znajdzie pary tam, gdzie ona jest. Sprowadź oba do jednej wielkości liter, zanim je porównasz.

Po czym poznasz, że wyszło

Po rozwiązaniu adresów każdy z pięciu sąsiadów ma nazwę, którą sam podstawiłeś ze swojej listy urządzeń. Jeśli nazwa pojawia się sama z siebie, czytasz inne pole — na przykład łącze nadrzędne z następnego rozdziału.

Łącze nadrzędne dostajesz gotowe, razem z nazwą

Trzecie miejsce podaje gotowe połączenie, bez liczenia czegokolwiek. Nasz switch łączy się w górę z urządzeniem Brama-GW, na jego porcie 3.

Nazwa jest tu zastąpiona — nazwy własne naszych obiektów zamieniamy w tekście na neutralne. Numer portu i wszystko, co dalej, pochodzi wprost z pomiaru.

Numer portu jest tu po tamtej stronie, nie po naszej. To gniazdo w urządzeniu wyżej, do którego wpięty jest nasz switch. Pomylenie stron przesuwa całe połączenie o jedno urządzenie.

To jest najtańsza droga do drzewa połączeń. Każde urządzenie poza tym na szczycie wskazuje jedno urządzenie wyżej. Drzewo składa się z tych wskazań samo i nie musisz do tego parować adresów sprzętowych.

Tu jest różnica, która zaskakuje. Łącze nadrzędne podaje nazwę, a tabela sąsiadów jej nie podaje. Dwa opisy tego samego kabla, w jednej odpowiedzi, o różnej zawartości.

Łącze nadrzędne opisuje wyłącznie drogę w górę. Wszystko inne zostaje w tabeli sąsiadów: obcy sprzęt, urządzenie obok, cokolwiek, co tylko się przedstawia.

Po czym poznasz, że wyszło

Po złożeniu drzewa zostaje jeden korzeń, czyli jedno urządzenie bez łącza nadrzędnego. Jeśli korzenie są dwa, jedno z urządzeń nie podało łącza w górę. Sprawdź je osobno, zamiast dorabiać brakujące połączenie z domysłu.

Trzy miejsca, trzy zasięgi — przy budowaniu mapy

Te same połączenia opisane są w jednej odpowiedzi trzy razy, na trzech różnych poziomach. Kto weźmie jedno miejsce, dostanie niepełny obraz i tego nie zauważy.

MiejsceZasięgCo stąd bierzeszCzego tam nie ma
tabela portówportstan portu i pobór PoE na żywosąsiada
tabela sąsiadówurządzenieadres sprzętowy i etykietę portu po drugiej stronienazwy sąsiada
łącze nadrzędneurządzeniegotowe połączenie w górę, z nazwą i numerem portuwszystkiego poza drogą w górę

Zwróć uwagę na zasięg. Dwa dolne wiersze opisują całe urządzenie, a nie port. Szukanie ich przy porcie zawsze skończy się niczym, choć odpowiedź wygląda na kompletną.

Nasz switch pokazuje to na liczbach. Pięć wpisów sąsiadów, cztery porty z poborem mocy, wspólne tylko trzy. Mapa oparta na jednym źródle gubi więc to, co widać wyłącznie w drugim.

Praktycznie składasz to tak. Łącze nadrzędne daje szkielet, tabela sąsiadów dokłada połączenia, których w szkielecie nie ma, a tabela portów opisuje końcówki. Pobór PoE rozstrzyga przy tym, czy na porcie bez sąsiada coś faktycznie pracuje — jak na porcie 10 z jego 3,70 W.

Najkosztowniejszy błąd w tych danych nie daje żadnego objawu. Program, który czyta wyłącznie tabelę portów, kończy się kodem 200, przetwarza wszystkie 26 portów i rysuje mapę bez ani jednego połączenia. Wygląda na sprawny, bo nic w odpowiedzi nie mówi, że czegoś zabrakło.

Czego nie zmierzyliśmy

Jeden kontroler, jedno wydanie, jeden przebieg. To wystarcza, żeby pokazać pułapkę. Nie wystarcza, żeby mówić o wszystkich instalacjach.

  • Nazwa sąsiada w innym wydaniu. Mamy jeden pomiar, na kontrolerze w wydaniu 10.6.101, i w nim pole system_name było puste we wszystkich pięciu wpisach.
  • Urządzenie na porcie 10. Wiemy, że pobiera 3,70 W i nie ma wpisu w tabeli sąsiadów. Nie sprawdzaliśmy, co to za urządzenie ani dlaczego milczy.
  • Reszta portów switcha. Pięć wpisów i cztery zasilane porty nie opisują 26 portów. Pozostałych nie przechodziliśmy po kolei.
  • Baza wewnętrzna kontrolera. Czytaliśmy odpowiedzi na zapytania, a nie to, co kontroler trzyma u siebie. Nie zaglądaliśmy też po SSH do adoptowanych urządzeń.

Jak w ogóle dostać te dane — jednym zapytaniem i właściwym kontem — opisujemy w osobnym artykule. Tam jest pułapka wcześniejsza niż ta: konto Ubiquiti z logowaniem przez e-mail dostaje 403, więc do topologii nie dojdziesz w ogóle.