CCIE.pl

Panowie,
mam taką przypadłość, po restarcie przełącznika do którego są podłączone kamery IP z PoE, zasilanie jest podawane wcześniej niż przełącznik jest gotowy to przełączania ramek. W efekcie, kamera nie otrzymuje adresu IP z serwera DHCP i nie ma z nią kontaktu. Wyjściem jest jej restart. Dodam, że kamera musi działać z DHCP - soft, konfigi itp.
Czy istnieje możliwość opóźnienia podania zasilania na porcie?
Urządzenie 2960-XR z IOS 15.2

Takie restarty przełącznika zdarzają się kiedy Panowie z utrzymania grzebią czasami z zasilaniem i jest to nieuniknione choć bardzo rzadkie. Kiedyś, w starszej wersji softu, można było stworzyć menu (komendą "menu") i przygotować kilka pozycji aby użytkownik miał dostęp do kilku wybranych komend, które mógłby wybrać z listy. Czy w tej wersji softu można uzyskać podobną funkcjonalność? Niestety, nie posiada on takiej komendy.
Dałbym możliwość dostępu do przełącznika i restartu interfejsów, podglądu stanu interfejsów itp.
Czy macie pomysł aby rozwiązać to w inny sposób?

Dzięki

Hej,
mamy - za pomoca skryptu EEM wykryj jakis specyficzny event/log po restarcie, wprowadz delay np. 2-3 minuty, a po tym delay wykonaj shut/no shut potrzebnych interfejsow.

Pozdruffka!

Miałem podobny problem, zrobiłem to tak:
porty pod kamery standartowo w konfiguracji startup w stanie shutdown
skrypt EMM - if uptime >1 min to no shut na portach kamer

Pzdr.

Tak z głupia franc zapytam - masz ustawiony na portach przełącznika ?

to nie głupia franc faktycznie, w stosie jeden z przełączników nie miał ustawionego portfast :/
nie jestem w stanie sprawdzić, czy problem dotyczył tylko tych urządzeń, które były wpięte do tego urządzenia czy również innych.
Na wszelki wypadek sprawdzę sobie konfigurację EEM.
Informacyjnie, dla potomnych - IOS 15.2(2), którego posiadam, nie posiada zaimplementowanego EEM, dopiero wersja 15.2(4) go posiada.
Dzięki za pomoc!

Spróbuj na dobry początek z portfast, bo miałem dokładnie coś takiego kiedyś z jakimś AP'kiem. Po otrzymaniu zasilania praktycznie od razu wysyłał DHCP Discover, a STP standardowo blokuje port na 30s. Po tym czasie port się odblokowywał, ale AP'ek już nie chciał adresu. W moim przypadku wystarczyło skonfigurować portfast i po problemie.

Pozdrawiam!

JD

judge dredd pisze:Spróbuj na dobry początek z portfast, bo miałem dokładnie coś takiego kiedyś z jakimś AP'kiem. Po otrzymaniu zasilania praktycznie od razu wysyłał DHCP Discover, a STP standardowo blokuje port na 30s. Po tym czasie port się odblokowywał, ale AP'ek już nie chciał adresu. W moim przypadku wystarczyło skonfigurować portfast i po problemie.

Pozdrawiam!

JD

portfast nie miał czasami wymogu uruchamiania tylko na portach podłączonych do urządzeń końcowych typu komputer?

Swoją drogą jak zaczynałem naukę po zakupie 2950 dwa dni szukałem czemu po włączeniu komputera internet jest dopiero po minucie, a switch skonfigurowany identycznie jak na jakimś blogu z kursem - dopiero wujek google nakierował na portfast i świat stał się łatwiejszy ( i internet szybciej dostępny ).

seba766 pisze: A czy APek nie jest urządzeniem końcowym?

Tu juz mozna polemizowac

Marek607 pisze: portfast nie miał czasami wymogu uruchamiania tylko na portach podłączonych do urządzeń końcowych typu komputer?

W opisanym przypadku (DHCP run dla AP) to AP był urządzeniem końcowym. I w wielu przypadkach będzie urządzeniem końcowym w kontekście STP. Chyba, że zrobisz gdzieś bridge'a z innym AP podłączonym do tego samego drzewka STP.
Portfast jako taki nie ma wymogu, żeby był uruchomiony na porcie urządzenia końcowego. W przypadku, gdyby jednak STP wykryło BPDU na porcie z portfastem, port straci tego portfasta i będzie zwykłym portem bridgowym (będzie musiał przejść przez normalny proces STP).