Telefony na niektórych przełącznikach nie mogą zakończyć procesu DHCP

tło

Mam serwer Windows DHCP (Server 2008 R2), który podaje adresy dla kilku zakresów. Jeden z tych zakresów dotyczy niektórych telefonów IP Mitel. Telefony są skonfigurowane do korzystania z opcji dhcp 125 w celu uzyskania informacji o konfiguracji. Kiedy telefon się uruchamia, nie wie, z którego vlan korzystać, więc otrzymuje tylko domyślny (nieoznaczony) vlan z dowolnego portu, do którego jest podłączony. Serwer dhcp daje odpowiedź zawierającą informacje o opcji 125, a telefon jest w stanie odczytać, jakiego vlan powinien użyć z tej odpowiedzi. Następnie telefon zwalnia swój pierwotny adres i prosi o nową dzierżawę dhcp przy użyciu poprawnego znacznika vlan. Telefony zwykle mają również komputery podłączone do portu tranzytowego. Pakiety z komputerów nigdy nie są oznaczane, więc komputery pozostaną na oryginalnym (nieoznaczonym) vlan dla portu. To działało dla nas od lat.

Problem i objawy

Gdzieś w ciągu ostatnich kilku tygodni coś się zmieniło i nie jestem pewien co. Telefony będą działać, dopóki się nie uruchomią ponownie, co oznacza, że ​​żądania odnowienia dhcp muszą zostać poprawnie przetworzone. Telefony podłączone do niektórych przełączników mogą nawet przetrwać restart. Telefony podłączone do innych przełączników nie zakończą jednak procesu po ponownym uruchomieniu. Wszystkie nasze telefony używają PoE, które jest wspierane przez UPS, więc minęło dużo czasu, odkąd wszystkie zostały zrestartowane. Oznacza to, że nie mam pojęcia, kiedy problem pojawił się po raz pierwszy. Wiem tylko, że jeden telefon zawiódł się, gdy uruchomił się wczoraj, a podczas rozwiązywania problemów dzisiaj resetujemy tę szafę przełącznika. Teraz żaden z telefonów na tym przełączniku nie działa (na szczęście wciąż jest to niewielka liczba). Wiem również, że wszystko działało pod koniec stycznia,

Gdy patrzę, jak telefon się uruchamia, widzę, że z powodzeniem otrzymuje pierwszy adres. Następnie z powodzeniem odczytuje informacje o opcji 125, ustawia prawidłowy znacznik vlan i zwalnia pierwotną dzierżawę adresu IP. Jest nawet w stanie odbierać i akceptować ofertę na poprawnym vlan z serwera . Jednak tam wszystko się kończy. Na ekranie telefonu pojawia się komunikat „ DHCP: Offer 2 ACC”, ale serwer DHCP systemu Windows nie zarejestrował dzierżawy i telefon nigdy się nie rusza. Mogę tylko zgadywać, że pakiet ZAPYTANIE DHCP nigdy nie dociera do serwera Windows, więc telefon czeka na ostatnie potwierdzenie z systemu Windows, że kontynuacja jest w porządku.

Obejście

W końcu udało mi się ponownie uruchomić telefon. Aby to zrobić, musiałem najpierw odłączyć komputer. Następnie ustawiłem port przełącznika telefonu na niezaznaczony na vlan telefonu, bez członkostwa w vlan na PC. Telefon uruchomi się teraz poprawnie. W tym momencie mogę przywrócić konfigurację portu przełącznika z powrotem tam, gdzie powinien, i dopóki nikt nie próbuje zadzwonić pod ten numer, gdy resetuję port, telefon nigdy nie traci rytmu. Następnie mogę ponownie podłączyć komputer. Oczywiście nie jest to idealny proces, jednak ponieważ telefony tak rzadko uruchamiają się ponownie, będę mógł użyć go, aby zachęcić ludzi do pracy, dopóki nie znajdę głównej przyczyny. Biura są teraz zamknięte na tydzień, więc ten problem będzie faktycznie mógł siedzieć w weekend (nie mam kluczy do poszczególnych biur, w których znajdują się telefony).

Ten telefon, który naprawiłem, to telefon serwisowy w serwerowni, podłączony bezpośrednio do naszego głównego przełącznika. Możliwe, że problemem jest problem z routingiem lub przetwarzaniem tagów na przełączniku głównym, tak że obejście nie będzie skuteczne w odległych biurach, w których pakiety są najpierw przekazywane (oznaczane przez) inne przełączniki, ale będę bardzo zaskoczony jeśli tak się stanie, biorąc pod uwagę, że wiem, że musi poprawnie przetwarzać odnowienia protokołu dhcp i rzeczywiste rozmowy telefoniczne.

Dziwne jest to, że pozostawienie portu oznaczonego na komputerze PC vlan oznacza, że ​​telefon zamiast tego wyświetla komunikat „ DHCP: Offer 1 ACC”. Muszę całkowicie usunąć ten vlan, aby to się udało.

Uwaga: potwierdziłem, że obejście jest skuteczne w odległych budynkach. To prowadzi mnie do podejrzeń, że moje urządzenia w jakiś sposób nie są przypisane do właściwego vlan. Fakt, że doświadczyłem problemu na moim przełączniku głównym i że zdarzyło się to w kilku miejscach w sieci w tym samym czasie, wskazuje, że problem może stanowić przełącznik główny. Nie mając nic konkretnego do obejrzenia, planuję okno konserwacji pod koniec tygodnia w celu ponownego uruchomienia przełącznika. Mogę również zaktualizować oprogramowanie wewnętrzne.

Środowisko

Nasz główny przełącznik to HP 5406zl. Ten przełącznik obsługuje routing między sieciami Vlan. Serwer DHCP systemu Windows jest podłączony bezpośrednio do przełącznika. Przełączniki punktów końcowych są podłączone do przełącznika głównego za pomocą światłowodowych SFP, a te porty są oznaczone dla wszystkich sieci na obu końcach. Przełącznik główny konfiguruje każdy vlan za pomocą ip helper-addressustawienia, które wskazuje go na nasz serwer DHCP, oraz dhcp relay-option 82 replacelinii, dzięki której serwer dhcp będzie wiedział, jakiego zakresu użyć. Te konfiguracje i konfiguracje portów na przełącznikach punktów końcowych nie zmieniły się przez co najmniej 16 miesięcy. W tym czasie mieliśmy inne resetowania przełączników i telefonów.

Większość naszych przełączników końcowych to HP 2530. Wygląda na to, że te przełączniki działają poprawnie (telefony na 3 różnych modelach 2530 uruchomiły się dzisiaj poprawnie). Starsze przełączniki mają problemy. Mamy jeden stary 3Com 4200 i jeden 4210, które nie będą działać. Telefon serwisowy podłączony bezpośrednio do wspomnianego wcześniej przełącznika głównego również nie działałby.

Pytanie

W tym momencie przypuszczam, że aktualizacja systemu Windows na serwerze dhcp zmieniła zachowanie, ale nie widzę, jak to zrobić. Być może przełącznik główny nie obsługuje poprawnie tego pakietu ŻĄDANIA, ale jestem pewien, że nic się tam nie zmieniło i nie wyjaśnia, dlaczego działają tylko niektóre przełączniki punktu końcowego. Jak mogę rozwiązać ten problem?

Aktualizacja:

Oto fragment dziennika dhcp z uszkodzonego telefonu:

10,03 / 06 / 15,12: 40: 40, Przypisz, 10.1.2.158,, 08000F197844,, 3189088995,0 ,,, 11,03 / 06 / 15,12: 40: 40, Odnów, 10.1.2.158, , 08000F197844,, 3189088995,0 ,,, 12,03 / 06 / 15,12: 40: 41, Release, 10.1.2.158,, 08000F197844,, 3189088995,0 ,,, 15,03 / 06 / 15,12: 40: 45, NACK, 10.1.2.154,, 08000F197844,, 0,6 ,,, 15,03 / 06 / 15,12: 40: 45, NACK, 10.1.2.154,, 08000F197844,, 0,6 ,,,

Adresy 10.xxx to vlan na PC (ten wybór poprzedza mnie w tym miejscu). Na początku telefony powinny otrzymać taki adres, więc jest to oczekiwane. Jednak po komunikacie o wydaniu spodziewam się również znaleźć ofertę na adres z zakresu 192.168.16.x, ponieważ widzę w telefonie, że oferta została zaakceptowana (chyba że źle interpretuję „ACC”). Interesujące jest to, że nigdy nie widziałem, aby serwer próbował wydać taki adres, nawet jeśli telefon myśli, że go otrzymał.

Zastanawiałem się nad pomysłem, że w sieci istnieje nieuczciwy serwer dhcp (podaje adres przed serwerem Windows, ale bez opcji dhcp wymaganych przez telefon do kontynuacji), ale to nie wyjaśnia, dlaczego telefony działają wtedy i tylko wtedy, gdy Całkowicie usuwam każdą ścieżkę do PC vlan. I tak będę go testować rano, podłączając laptopa do zestawu portów dla telefonu VLAN, ale jeśli ktoś w międzyczasie ma lepsze wytłumaczenie, chciałbym to usłyszeć.

Oto kopia konfiguracji przełącznika:

http://pastebin.com/veXjCRXu

Rozwiązałem problem dzisiaj, usuwając tag vlan dla telefonu vlan na porcie łączącym się z naszym serwerem dhcp. To dla mnie bardzo dziwne, że to zadziałało, ponieważ inne systemy, które używają podobnego schematu (aka: SSID Wi-Fi przy użyciu 802.1q) wymagają tagu lub klienci nie mogą uzyskać adresów. Działało, więc nie będę wyglądał zbyt ostro, ale chciałbym zobaczyć odpowiedzi z teoriami, dlaczego tak jest.

Należy rozważyć uruchomienie przechwytywania pakietów po obu stronach problematycznych przełączników, a następnie przejrzenie tego w Wireshark. Dzięki temu dowiesz się 1) czy ruch jest przechwytywany przez nieuczciwy serwer DHCP (na podstawie adresu MAC) i 2) czy coś się psuje lub upuszcza (np. Może potrzebujesz przekaźnika DHCP). Może to wymagać dublowania portów lub 3com może obsługiwać przechwytywanie bezpośrednio na przełączniku.

Jeśli okaże się, że ten problem pojawia się ponownie, możesz sprawdzić rozmiar swojego zakresu DHCP i liczbę używanych dzierżaw. Jeśli stare dzierżawy DHCP nie zostaną zniszczone, serwer może myśleć, że w puli nie ma żadnych adresów i nie może przypisać nowych adresów. Jest to prawdą, nawet jeśli w vlan nie ma żadnych urządzeń. Jeśli zakres DHCP wynosi 7 dni, może upłynąć 7 dni, zanim będziesz mógł uzyskać nową dzierżawę. Podobnie zmiana konfiguracji rozwiązałaby problem, ponieważ pojawiłby się nowy zakres adresów, który mógłby zostać usunięty, lub mógłby opróżnić dzierżawę w zależności od zmian konfiguracji. Sugerowałbym ustawienie czasu najmu na coś bardzo niskiego, na przykład godzinę dla tego zakresu, jeśli tak jest.