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 port | Adres sprzętowy sąsiada | Etykieta portu po tamtej stronie | Nazwa portu u nas | Pobór PoE |
|---|---|---|---|---|
| 2 | d0:21:f9:85:54:85 | D0:21:F9:85:54:87 | Port 2 | 0,00 W (zasilanie wyłączone) |
| 4 | 2c:33:11:80:7c:f8 | Gi0 | Port 4 | 10,80 W |
| 5 | 00:90:e8:62:bf:ed | 1 | Port 5 | 0,00 W (zasilanie wyłączone) |
| 14 | 8c:94:1f:fc:15:44 | Gi0 | Port 14 iot test | 9,70 W |
| 18 | 10:b3:d6:73:b3:5a | Gi0 | Port 18 | 13,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 portu | Ile wpisów | Co z niej odczytasz |
|---|---|---|
Gi0 | 3 | konwencję Cisco — port nazwany od rodzaju łącza, nie od numeru w obudowie |
1 | 1 | coś prostszego: urządzenie numeruje porty po kolei i nic do numeru nie dokłada |
D0:21:F9:85:54:87 | 1 | urzą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.
| Miejsce | Zasięg | Co stąd bierzesz | Czego tam nie ma |
|---|---|---|---|
| tabela portów | port | stan portu i pobór PoE na żywo | sąsiada |
| tabela sąsiadów | urządzenie | adres sprzętowy i etykietę portu po drugiej stronie | nazwy sąsiada |
| łącze nadrzędne | urządzenie | gotowe połączenie w górę, z nazwą i numerem portu | wszystkiego 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 polesystem_namebył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.