Prawidłowo wskazana cecha idealnie oddaje sens monitoringu Out-of-Band. W tej metodzie oprogramowanie nadzorujące urządzenia sieciowe korzysta z zupełnie oddzielnej, alternatywnej sieci komunikacyjnej, która działa niezależnie od sieci produkcyjnej, po której chodzą normalne dane użytkowników. Chodzi tu zwykle o osobną sieć zarządzającą: osobne porty konsolowe, porty zarządzające (np. Ethernet management), czasem osobne VLAN-y tylko do managementu albo nawet dedykowany modem LTE. Dzięki temu, nawet jeśli główna sieć ma awarię, jest zapętlona, przeciążona albo źle skonfigurowana, administrator nadal ma dostęp do przełączników, routerów czy firewalli i może je zdalnie diagnozować oraz naprawiać. Z mojego doświadczenia Out-of-Band to jedna z kluczowych dobrych praktyk w większych sieciach firmowych, data center czy u operatorów. Standardowo łączy się to z wykorzystaniem konsolowych serwerów terminali, osobnych switchy zarządzających i odseparowanych adresacji IP, często w połączeniu z VPN-em tylko do managementu. Takie rozwiązanie znacznie podnosi dostępność usług i zgodność z wymaganiami wysokiej niezawodności (HA) oraz zasadami bezpieczeństwa – np. odseparowanie płaszczyzny danych (data plane) od płaszczyzny zarządzania (management plane). W praktyce, jeśli np. ktoś źle skonfiguruje ACL na routerze i odetnie ruch w sieci produkcyjnej, przez Out-of-Band dalej możesz się na ten router zalogować i cofnąć zmiany. Właśnie ta niezależność kanału komunikacji jest najważniejszą, podręcznikową cechą monitoringu i zarządzania Out-of-Band.
W monitorowaniu i zarządzaniu siecią bardzo łatwo pomylić pojęcia In-Band i Out-of-Band, bo na pierwszy rzut oka wydają się podobne – oba przecież służą do nadzorowania tych samych urządzeń. Kluczowa różnica leży jednak w tym, jaką drogą idą komunikaty zarządzające. W podejściu In-Band oprogramowanie monitorujące korzysta z tej samej sieci, którą przesyłane są zwykłe dane użytkowników: ruch HTTP, pliki, poczta itp. Taki model jest tańszy i prostszy, ale ma jedną zasadniczą wadę – kiedy sieć produkcyjna padnie, monitoring też w praktyce „ślepnie”. Dlatego stwierdzenie, że Out-of-Band używa tej samej sieci co dane, jest typowym pomieszaniem definicji obu metod. Częsty błąd polega też na założeniu, że Out-of-Band musi być z założenia tańszy lub droższy. Cena nie jest cechą definicyjną tej metody. Owszem, w praktyce Out-of-Band zwykle wymaga dodatkowego sprzętu: osobnych portów zarządzających, konsolowych serwerów terminali, czasem osobnego okablowania czy nawet oddzielnego dostępu LTE, więc bywa droższy w wdrożeniu. Ale to tylko konsekwencja architektury, a nie jej definicja. Dlatego odpowiedź oparta wyłącznie na kryterium kosztu nie opisuje istoty zagadnienia. Kolejne mylne przekonanie to założenie, że przy Out-of-Band nie da się rozwiązać problemów przy awarii sieci monitorowanej. Jest dokładnie odwrotnie: właśnie po to się buduje niezależny kanał zarządzający, aby w razie awarii głównej sieci nadal mieć dostęp do urządzeń. To jest jedna z podstawowych dobrych praktyk w projektowaniu sieci o wysokiej dostępności i wynika z rozdzielenia płaszczyzny zarządzania od płaszczyzny przesyłania danych. Podsumowując, Out-of-Band zawsze oznacza wykorzystanie alternatywnej, odseparowanej sieci lub kanału komunikacyjnego do monitoringu i zarządzania, a nie tej samej infrastruktury, po której idzie ruch użytkowników ani nie polega na braku możliwości reakcji przy awarii – wręcz przeciwnie, ma tę reakcję ułatwić.