FreeBSD исполнилось 20 лет

Проект FreeBSD празднует двадцатилетие.
Днём рождения проекта считается 19 июня 1993 года.
В этот день на базе неофициального набора патчей к 386BSD был создан форк 4.3BSD, в рамках которого планировалось развивать быструю, стабильную и надёжную ОС для систем i386.
В качестве вариантов имени рассматривались FreeBSD, BSDFree86 и Free86BSD.
В итоге предпочтение было отдано варианту FreeBSD, который предложил Дэвид Гринман (David Greenman).
В ноябре 1993 года на основе 4.3BSD-Lite 'Net/2' и 386BSD 0.1 был выпущен первый релиз FreeBSD 1.0.

Точнее чем Майкл Лукас никто бы не сказал - "Like smog, spiders, and corn syrup, FreeBSD is all around you; you simply don't see it because FreeBSD just works."

Так и есть, BSD системы держали и продолжают держать самые критичные сервисы и приложения, но никто этого не замечает, потому что FreeBSD просто работает.

Восстановление файловой системы FreeBSD

Как поступать если FreeBSD после повреждения файловой системы загружается в single use mode.

Для начала запустить fsck_ufs для "грязных" слайсов

# fsck_ufs /dev/ad0s1d

Далее если ругнется на то что can't read disk label

и

# bsdlabel: /dev/ad0s1d: no valid label found

То

Сначала узнать адреса резервных копий суперблока.

# newfs -N <слайс>

Будет выведен список резервных копий суперблока.

И затем указать один из адресов копий суперблока программе восстановления

# fsck -o -b=<адрес одного из резервных суперблоков>  <слайс>

Осталось только оправить на перезагрузку

# init 6

После этого система пометит все слайсы как "clean" и продолжит загружаться в обычном режиме.

Cisco disaster recovery

Бывают ситуации когда загрузка маршрутизатора останавливается в ROMMON по той причине, что отсутствует прошивка.

Path MTU Discovery

Неочевидные нюансы Path MTU Discovery.

Суть технологии Path MTU discovery заключается в том, что при соединении двух хостов устанавливается параметр DF (don’t fragment), который запрещает фрагментацию пакетов.
Это приводит к тому, что узел, значение MTU которого меньше размера пакета, отклоняет передачу пакета и отправляет сообщение ICMP типа Destination is unreachable.
К сообщению об ошибке прилагается значение MTU узла.
Хост-отправитель уменьшает размер пакета и отсылает его заново.
Такая операция происходит до тех пор, пока пакет не будет достаточно мал, чтобы дойти до хоста-получателя без фрагментации.

Но, что произойдет если на маршрутизаторе, на интерфейсе отключена отправка таких ICMP сообщений (no ip unreachables)?
В таком случае хост-отправитель не будет знать, о том, что его пакет отброшен и не был доставлен до адресата.
И соединение просто не установится.

Отключение ICMP unreachables не усиливает безопасность, а просто ломает технологии вроде  Path MTU discovery и усложняет поиск проблем с маршрутизацией.

Примеры использования tcptraceroute

Все так или иначе использовали утилиту traceroute.
Особенно она помогает при вводе в строй новых маршрутизаторов.
Но бывают случаи когда фаерволлы отбрасывают ICMP пакеты и узнать трассу не представляется возможным.
Тогда в бой идет tcptraceroute.

Возьмем для примера хост, который блокирует наши ICMP.

[sinister@tier ~]$ traceroute -w2 -q1 -f 4 www.microsoft.com
traceroute to lb1.www.ms.akadns.net (64.4.11.42), 64 hops max, 52 byte packets
 4  bettong.itsinternet.net (213.133.168.25)  35.527 ms  36.508 ms  35.709 ms
 5  * * *
 6  * * *
 7  ge-3-0-0-0.nyc-64cb-1a.ntwk.msn.net (207.46.43.44)  121.663 ms
    207.46.45.238 (207.46.45.238)  166.674 ms *
 8  ge-5-3-0-0.bl2-64c-1b.ntwk.msn.net (207.46.46.187)  125.920 ms
    xe-4-0-1-0.bay-16c-1a.ntwk.msn.net (207.46.40.10)  190.023 ms
    ge-5-3-0-0.bl2-64c-1b.ntwk.msn.net (207.46.46.187)  127.381 ms
 9  10.22.40.9 (10.22.40.9)  190.100 ms
    xe-0-0-2-0.bay-96c-1a.ntwk.msn.net (207.46.33.74)  188.697 ms
    10.22.40.5 (10.22.40.5)  189.967 ms
10  * * xe-0-1-0-0.bay-96c-1b.ntwk.msn.net (207.46.40.229)  188.357 ms
11  * * 10.22.40.1 (10.22.40.1)  188.305 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *

Как видно результат не совсем тот, что ожидался.

А теперь что нам скажет tcptraceroute:

[sinister@tier ~]$ tcptraceroute -f 4 www.microsoft.com

Selected device fxp0, address 192.168.x.x, port 38510 for outgoing packets

Tracing the path to www.microsoft.com (64.4.11.42) on TCP port 80, 30 hops max

 4  bettong.itsinternet.net (213.133.168.25)  35.520 ms  35.316 ms  35.299 ms

 5  * * *

 6  ge-6-2-0-0.lts-64cb-1b.ntwk.msn.net (207.46.42.156)  52.480 ms  51.653 ms  52.011 ms

 7  207.46.45.238 (207.46.45.238)  126.775 ms  130.911 ms  127.942 ms

 8  ge-5-3-0-0.bl2-64c-1b.ntwk.msn.net (207.46.46.187)  124.992 ms  125.343 ms  129.014 ms

 9  xe-0-0-2-0.bay-96c-1a.ntwk.msn.net (207.46.33.74)  187.679 ms  188.217 ms  188.050 ms

10  xe-0-1-0-0.bay-96c-1b.ntwk.msn.net (207.46.40.229)  198.162 ms  188.878 ms  187.886 ms

11  10.22.40.1 (10.22.40.1)  187.464 ms  187.716 ms  188.000 ms

12  64.4.11.42 (64.4.11.42) [open]  187.054 ms  187.536 ms  187.790 ms

Цель была достигнута.

Логи cisco пишем в syslog

Сначала подключаемся к маршрутизатору и:
#logging source-interface vlan1
#logging 192.168.1.1   куда пересылать логи
#logging facility local7  указываем метку логирования, что бы потом можно было отлавливать через syslog
#logging trap debugging   здесь можно после слова trap задать, что именно хотите логировать

Идем в /etc/syslog.conf и добавляем:
local7.*                                        /var/log/cisco.log

Управление конфигурацией CISCO

Управление конфигурацией маршрутизаторов CISCO

Достаточно большая тема, но крайне необходимая.

Чтобы посмотреть текущую конфигурацию:
R# show running-config
Чтобы посмотреть сохраненную конфигурацию:
R#show startup-config
Сохранение текущей конфигурации:
R# write memory
Но это уже устаревшая команда, хотя для совместимости пока еще работает.
Более актуальный вариант:
R# copy running-config startup-config
или даже:
R# copy run start