Jeśli konfigurujesz urządzenia sieciowe Cisco, wprowadzone przez Ciebie jakiekolwiek zmiany nanoszone są do tzw. konfiguracji bieżącej, która to zapisywana/utrzymywana jest w pamięci RAM. A ponieważ jest to tzw. pamięć ulotna, to oznacza to, że po restarcie urządzenia, wszystko co wcześniej pokonfigurowaliśmy, szlak trafi…
Stąd w urządzeniach Cisco została wdrożona specjalna dodatkowa pamięć stała typu flash, nazywana NVRAM. „Dysk” ten jest w praktyce malutki, w obecnych urządzeniach często ma on rozmiar 255 KB. Także na pewno jest za mały, aby wrzucić tam film 🙂 Ale jednak na tyle duży, aby zmieścić tam plik tekstowy z konfiguracją urządzenia.
Pomysł wykorzystania tej pamięci NVRAM jest taki, iż urządzenie gdy się uruchamia, ma sobie wczytać do pamięci RAM konfigurację startową właśnie z pliku znajdującego się w tejże pamięci NVRAM.
Problem jednak jest w tym, że plik konfiguracyjny w pamięci NVRAM sam znikąd się nie pojawi, a więc wymaga to pewnej interakcji z naszej strony. Oznacza to, że po dokonaniu konfiguracji, i zweryfikowaniu jej prawidłowości, powinniśmy skopiować konfigurację jaką mamy aktualnie w RAM’ie, do NVRAMu. Do wykonania tego zadania służy polecenie:
copy running-config startup-config |
czyli: skopiuj konfigurację bieżącą do konfiguracji startowej.
I teraz po małych informacjach wstępnych, możemy przejść do meritum tegoż artykułu 🙂
Ojejku, wyskoczył mi błąd, że nie można zapisać pliku konfiguracyjnego, bo jest za mało miejsca w pamięci NVRAM…
W momencie wykonywania powyższego polecenia, może się okazać, że dostaniemy błąd, który wygląda na przykład jak poniższy:
% Warning: Saving this config to nvram may corrupt any network management or security files stored at the end of nvram. Continue? [no]: no % Configuration buffer full, can't add command: %Aborting Save. Compress the config.[OK] |
czy na przykład:
%SYS-4-NV_BLOCK_INITFAIL : Unable to initialize the geometry of nvram |
i temu podobne…
Powyższe błędy oznaczają, że niestety system operacyjny niemoże zapisać pliku konfiguracyjnego w pamięci NVRAM, co najprawdopodobniej oznacza, że rozmiar zapisywanego pliku konfiguracyjnego jest większy, niż rozmiar dostępnej/wolnej przestrzeni w pamięci NVRAM.
Można problem powyższy sprawdzić wykonując np. polecenie:
show file systems |
Możemy wtedy zobaczyć, jak wogóle jest duża pamięć NVRAM w naszym urządzeniu, jak również ile miejsca jest na niej wolnego. Poniżej na zdjęciu mały przykład wykonania powyższego polecenia:
Choć może się zdarzyć równie dobrze, że system uciążliwie twierdzi, że NVRAM jest uszkodzony, że jest coś z nim nie tak, i wtedy też często gęsto, problem wynika z pełnego zapełnienia pamięci NVRAM.
Gdybyśmy chcieli sprawdzić, co zabiera tyle miejsca w tejże pamięci NVRAM, to możemy z kolei wykorzystać na przykład polecenie:
dir nvram: |
Przykładowy wynik w/w polecenia:
I teraz powstaje pytanie: Co z tym fantem zrobić? Gdyż przecież wymienić/powiększyć tej pamięci, to trochę niezabardzo mam jak…
Można usunąć jakieś niepotrzebne pliki z tejże pamięci… Tylko tam w praktyce nie będzie czego usunąć, gdyż nie znajdziemy niczego czego co będzie duże i niepotrzebne…
W takim przypadku możemy zdecydować się na wykorzystanie innej możliwości jaką daje nam system Cisco IOS, tj. włączenie kompresji pliku konfiguracyjnego. Włączenia kompresji dokonujemy w trybie konfiguracji globalnej, poprzez wydanie polecenia:
service compress-config |
a następnie polecenia skopiowania konfiguracji bieżącej do konfiguracji startowej (wcześniejsze polecenie jeszcze niczego nie kompresuje, tylko wskazuje, że przy kolejnej próbie zmianie konfiguracji startowej, należy przez zapisaniem pliku w pamięci NVRAM go skompresować):
copy running-config startup-config |
Oczywiście, gdy urządzenie się uruchamia, konfiguracja jest dekompresowana i ładowana do pamięci RAM.
Na poniższym zdjęciu można zobaczyć przykład wykorzystania w/w poleceń:
I można na tym powyższym zdjęciu zauważyć, że plik konfiguracyjny, który wcześniej miał 1354 bajtów, po kompresji ma obecnie 891 bajtów.
Jako ciekawostka przy okazji: starszą wersją polecenia kopiującego konfigurację bieżącą do konfiguracji startowej, było polecenie:
write memory |
Może jest to i polecenie starsze, ale cały czas działające, a pisania jest znacznie mniej 😉
Mały przykład wykorzystania, zakładający zastosowanie najkrótszej formy tegoż polecenia (i widać, że tutaj także wykonywana jest kompresja):
W oprogramowaniu Cisco IOS w wersji 12.0 i wcześniejszych, konieczne było także dostosować rozmiar bufora przydzielonego dla działającej konfiguracji w pamięci RAM.
W skrócie w/w bufor, to obszar w pamięci RAM przeznaczony na potrzeby przechowywania pliku bieżącej konfiguracji.
Domyślnie rozmiar tego bufora to rozmiar równy wielkości pamięci NVRAM (co w sumie jest niby logiczne). I to może rodzić pewne oczywiste problemy, gdy włączymy kompresję konfiguracji startowej.
Czyli przykładowo: jeśli rozmiar NVRAM urządzenia wynosiłby 32KB, ale przechowywany w niej plik konfiguracji startowej po kompresji, tak naprawdę miał wielkość 40KB jeszcze przed skompresowaniem, to aby zmieścić się w RAM, rozmiar bufora powinien zostać zwiększony do co najmniej 40KB (oczywiście można, a nawet należałoby powiększyć do jeszcze większej wartości).
Aby dostosować rozmiar bufora przydzielonego dla działającej konfiguracji w pamięci RAM, nalezy wydać polecenie:
boot buffersize 64000 |
gdzie 64000, oznacza rozmiar bufora wynoszący 64KB.
Uwaga: Jeszcze raz dla przypomnienia – polecenie boot buffersize jest potrzebne tylko w oprogramowaniu Cisco IOS w wersji 12.0 i wcześniejszych. W Cisco IOS w wersjach powyższych, samo polecenie service compress-config rozwiązuje problem z wielkością pamięci NVRAM, a użytkownik nie musi już konfigurować bufora w RAM.
