Subnets.ru blog

Пишу заметочку себе, но м.б. кому нить ещё пригодится.

История

Сижу, конфигурю себе джуник, никого не трогаю 🙂

Закончил делать конфиг, выполняю:

virus@juniper# commit check

и… и получаю сей конфуз:

error: init: write failed: No space left on device
error: configuration check-out failed: daemon file propagation failed

или такой вариант конфуза:

virus@juniper# commit check

error: init: write failed: Unknown error: 0
error: init: write failed: No space left on device
error: write failure for file ttys
error: configuration check-out failed: daemon file propagation failed

Почесав репу 🙂 полез смотреть, что же у меня там со свободным местом то происходит:

virus@juniper# run show system storage

Filesystem              Size       Used      Avail  Capacity   Mounted on
/dev/ad0s1a             885M       142M       672M       17%  /
devfs                   1.0K       1.0K         0B      100%  /dev
devfs                   1.0K       1.0K         0B      100%  /dev/
/dev/md0                 30M        30M         0B      100%  /packages/mnt/jbase
/dev/md1                179M       179M         0B      100%  /packages/mnt/jkernel-9.4R1.8
/dev/md2                 31M        31M         0B      100%  /packages/mnt/jpfe-M7i-9.4R1.8
/dev/md3                4.8M       4.8M         0B      100%  /packages/mnt/jdocs-9.4R1.8
/dev/md4                 48M        48M         0B      100%  /packages/mnt/jroute-9.4R1.8
/dev/md5                 32M        32M         0B      100%  /packages/mnt/jpfe-common-9.4R1.8
/dev/md6                2.0G       8.0K       1.8G        0%  /tmp
/dev/md7                2.0G       2.0G    -160.8M      109%  /mfs
/dev/ad0s1e              98M        26K        90M        0%  /config
procfs                  4.0K       4.0K         0B      100%  /proc
/dev/ad1s1f              34G       470M        31G        1%  /var

мдаааа…. подумал я, минус 160 метров это круто……

начал поиски, куда же все место подевалось ? и нашел таки куда:

virus@juniper# run file list detail /mfs/var/lpdfd/

/mfs/var/lpdfd/:
total 4120268
-rw-r-----  1 root  wheel      24576 May 7  12:16 __db.001
-rw-r-----  1 root  wheel      49152 May 7  12:16 __db.002
-rw-r-----  1 root  wheel     270336 May 7  12:16 __db.003
-rw-r-----  1 root  wheel    1146880 May 7  12:16 __db.004
-rw-r-----  1 root  wheel     475136 May 7  12:16 __db.005
-rw-r-----  1 root  wheel      49152 May 7  12:16 __db.006
-rw-r-----  1 root  wheel         25 May 7  12:17 __db.register
-rw-------  1 root  wheel          4 May 7  12:16 __db.rep.egen
-rw-------  1 root  wheel          4 May 7  12:16 __db.rep.gen
-rw-r-----  1 root  wheel   10485760 May 7  18:41 log.0000000001
-rw-r-----  1 root  wheel   10485760 May 8  01:15 log.0000000002
-rw-r-----  1 root  wheel   10485760 May 8  07:49 log.0000000003
-rw-r-----  1 root  wheel   10485760 May 8  14:23 log.0000000004
-rw-r-----  1 root  wheel   10485760 May 8  20:57 log.0000000005
-rw-r-----  1 root  wheel   10485760 May 9  03:31 log.0000000006
-rw-r-----  1 root  wheel   10485760 May 9  10:05 log.0000000007
-rw-r-----  1 root  wheel   10485760 May 9  16:39 log.0000000008
-rw-r-----  1 root  wheel   10485760 May 9  23:13 log.0000000009
-rw-r-----  1 root  wheel   10485760 May 10 05:47 log.0000000010
-rw-r-----  1 root  wheel   10485760 May 10 12:20 log.0000000011
-rw-r-----  1 root  wheel   10485760 May 10 18:54 log.0000000012
-rw-r-----  1 root  wheel   10485760 May 11 01:28 log.0000000013
-rw-r-----  1 root  wheel   10485760 May 11 08:02 log.0000000014
.................................................................
-rw-r-----  1 root  wheel   10485760 Jun 28 11:29 log.0000000190
-rw-r-----  1 root  wheel   10485760 Jun 28 18:03 log.0000000191
-rw-r-----  1 root  wheel   10485760 Jun 29 00:37 log.0000000192
-rw-r-----  1 root  wheel   10485760 Jun 29 07:11 log.0000000193
-rw-r-----  1 root  wheel   10485760 Jun 29 13:45 log.0000000194
-rw-r-----  1 root  wheel   10485760 Jun 29 20:19 log.0000000195
-rw-r-----  1 root  wheel   10485760 Jun 30 02:53 log.0000000196
-rw-r-----  1 root  wheel   10485760 Jun 30 09:26 log.0000000197
-rw-r-----  1 root  wheel   10485760 Jun 30 16:00 log.0000000198
-rw-r-----  1 root  wheel   10485760 Jun 30 22:34 log.0000000199
-rw-r-----  1 root  wheel   10485760 Jul 1  05:08 log.0000000200
-rw-r-----  1 root  wheel   10485760 Sep 17 15:53 log.0000000201
-rw-r-----  1 root  wheel     131072 May 7  12:16 lpdfd.db

Я ессно сократил вывод, иначе много места займет :), вообщем файлов с log.0000000001 по log.0000000201 включительно.

Полез в Google, долго рылся в кучи всяких линков ниочем прежде чем найти всего одну путную ссылку, в которой чел рассказывал хоть о чем то похожем.

Почитал что люди пишут, посмотрел на версию софта на этом маршрутизаторе:

virus@juniper> show version

Hostname: juniper
Model: m7i
JUNOS Base OS boot [9.4R1.8]
JUNOS Base OS Software Suite [9.4R1.8]
JUNOS Kernel Software Suite [9.4R1.8]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.4R1.8]
JUNOS Packet Forwarding Engine Support (M7i/M10i) [9.4R1.8]
JUNOS Online Documentation [9.4R1.8]
JUNOS Voice Services Container package [9.4R1.8]
JUNOS Services AACL Container package [9.4R1.8]
JUNOS Services LL-PDF Container package [9.4R1.8]
JUNOS AppId Services [9.4R1.8]
JUNOS IDP Services [9.4R1.8]
JUNOS Routing Software Suite [9.4R1.8]

пробуем удалить:
virus@juniper# run file delete /mfs/var/lpdfd/log.0000000201

и ессно хрен там:

rm: /mfs/var/lpdfd/log.0000000201: Permission denied

Стало понятно что я не удалю файлы из под своего аккаунта и нуна войти под root.

Консольный кабель подключен к COM порту и я полез через него, набрав в консоле, своей любимой OS FreeBSD, команду:
cu -l /dev/cuad0

Ну что ж, под root`ом я вошел, пробуем удалить файл снова:

root@juniper% cd /mfs/var/lpdfd/
root@juniper% rm log.0000000201

Отлично ! Файл спокойно удалился. Таким образом я потер все остальные файлы с логами, оставив тока с 10-к.

Смотрим что у нас там с местом ?

root@juniper% df -h

Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a    885M    142M    672M    17%    /
devfs          1.0K    1.0K      0B   100%    /dev
devfs          1.0K    1.0K      0B   100%    /dev/
/dev/md0        30M     30M      0B   100%    /packages/mnt/jbase
/dev/md1       179M    179M      0B   100%    /packages/mnt/jkernel-9.4R1.8
/dev/md2        31M     31M      0B   100%    /packages/mnt/jpfe-M7i-9.4R1.8
/dev/md3       4.8M    4.8M      0B   100%    /packages/mnt/jdocs-9.4R1.8
/dev/md4        48M     48M      0B   100%    /packages/mnt/jroute-9.4R1.8
/dev/md5        32M     32M      0B   100%    /packages/mnt/jpfe-common-9.4R1.8
/dev/md6       2.0G    8.0K    1.8G     0%    /tmp
/dev/md7       2.0G    100M    1.7G     5%    /mfs
/dev/ad0s1e     98M     26K     90M     0%    /config
procfs         4.0K    4.0K      0B   100%    /proc
/dev/ad1s1f     34G    470M     31G     1%    /var

С местом у нас теперь все путем ! Ну что ж, пробую откоммитить, для этого захожу в CLI:
root@juniper% cli
и чекаем конфиг:
root@juniper> commit check
и наконец получаем искомое:
configuration check succeeds

Ссылки

• gossamer-threads.com

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Как всегда начнем статью со слов благодарности тем, кто на нее откликнется, оставит комментарии и свои взгляды на решение проблемы. ))

Проблема или задача: мониторинг трафика провайдера на наличие ddos атак как со стороны своих абонентов и так и на них. Статья носит теоретический характер, практическая реализация зависит от каждого конкретного провайдера.

Немного теории здесь и здесь.

Мы не будем разбивать по типам атак,  для нашей задачи это не так важно.

Учет трафика в сети провайдера в основном работает по следующей схеме — данные с оборудования о трафике абонента попадают на коллектор (в нашем случае используется netflow), где эти данные и обрабатываются.  Наша задача как раз и состоит в анализе этого трафика. Предлагаются следующие характеристики для анализа трафика:

— ip адрес;

— протокол;

— количество пакетов в потоке;

— количество байт в потоке.

Дальше просто анализируем количество потоков для одного ip адреса. Порог срабатывания в каждой сети и для каждого абонента может быть разный, опытным путем установили следующие значения: если из 1000000 потоков содержится более 10000 одинаковых записей, то скорее всего у клиента сетевая проблема (вероятно компьютер абонента заражен вирусом и участвует в атаке). Далее действия могут быть разными, пишем, звоним абоненту или сразу блокируем, все зависит от правил во взаимоотношении с клиентами. При количестве одинаковых потоков более 100000 проблема на сети провайдера будет видна невооруженным взглядом (конечно это будет зависеть от производительности оборудования).

Статья основана на собственном опыте, если у кого-то есть свои «выкладки», то будет интересно на них посмотреть.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор:  zaikini

Juniper: BGP load balancing on 2 links (same ISP)

На одном из маршрутизаторов Juniper появился второй физический линк на того же апстрима, т.к. первый линк уже сильно нагружен. Что по итогу получилось ?

А получилось что мы имеем два линка в одну и ту же ASку (два физических линка и две BGP сессии) и трафик может распределяться по 2 линкам неравномерно.

В своей предыдущей статье «Настройка протокола BGP на оборудовании Juniper» я уже затрагивал тему лоад балансинга, но там load balance применяется ко всем апстримам, а тут у меня появилась немного другая задача, сделать балансинг только на двух этих линках. (уточню, что речь идет ТОЛЬКО про исходящий трафик из моей AS)

Для примера будем считать, что у апстрима номер автономной системы AS100.

Итак начнем, войдем в режим конфигурации:

root@juniper> configure

Как известно, что практический любой вопрос можно решить как минимум двумя способами, подумав, я решил балансить трафик исходя из as-path, поэтому создадим «AS path regular expression «:

[edit]
root@juniper# set policy-options as-path as100 «100.*»

что означает, что путь должен начинаться с AS номер 100, а что там будет дальше нам все равно, главное что мы обозначили что он идет именно через нашего апстрима.

Далее создадим полиси (в терминах cisco «маршрутную карту» — route-map):

[edit]
root@juniper# set policy-options policy-statement load-balance-as100 from as-path as100
[edit]
root@juniper# set policy-options policy-statement load-balance-as100 then load-balance per-packet

в которой мы и указали созданный выше as-path как параметр для матча (совпадение as-path в маршруте)

Ну и осталось применить это к таблице маршрутизации — forwarding-table:

[edit]
root@juniper# set routing-options forwarding-table export load-balance-as100

Проверим все ли в порядке:

[edit]
root@juniper# commit check

Если в ответ вы получили сообщение:

configuration check succeeds

значит ошибок в конфигурации нет и вы можете применять её на маршрутизаторе.

Сделаем это и добавим комментарий к этому конфигу:

[edit]
root@juniper# commit comment «Load balance AS100»

После применения данных изменений на моем маршрутизаторе исходящий трафик в двух линках выровнялся и начал ходить почти одинаково.

Разница конечно будет, не ждите 100% одинаковости трафика по каналам, но в общем целом она перестала различаться в разы и составляет 10-20 Мбит/с.

За балансинг входящего к вам трафик уже отвечает ваш апстрим, но для него это же исходящий трафик 😉

Ссылки:

• Configuring the Load-Balance Per-Packet Action
• Defining AS Path Regular Expressions
• Defining Routing Policies
• Настройка протокола BGP на оборудовании Juniper

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)