ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Архивные статьи в категории ‘Программы’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Некоторое время назад мы начали вливаться в ряды тех кто начал постигать премудрости blockchain технологий.

Так 02.09.2017 начался наш новый проект bitname.ru. Данный проект стартовал с поддержки доменов в зоне .bit, которая предоставляется Namecoin.

Мы развернули несколько сервисов:

  • Whois
  • DNS сервер
  • Cтатистика сети

Whois

Вы можете воспользоваться штатной утилитой(UNIX) whois:
# whois -h whois.bitname.ru bitname.bit

* Для Windows надо будет скачивать программу whois отдельно.

Так же выполнив HTTP запрос: https://bitname.ru/whois.php?domain=bitname.bit

** с 30.04.2018 добавлена поддержка доменов в зонах .emc .coin .lib .bazar, которые предоставляет Emercoin.

DNS-сервер ns4chain

Вы можете указать сервера dns1.bitname.ru dns2.bitname.ru в настройках вашего DNS сервера как forwarder для зоны .bit.

Пример для BIND:


zone "bit" {
     type forward;
     forward only;
     forwarders {
          91.217.137.44;
          80.233.248.109;
     };
};

* Поддержку доменов в зонах .emc .coin .lib .bazar планируется добавить в ближайшем будущем.

Статистика

Статистика по использованию доменов в зонах .bit .emc .coin .lib .bazar вы можете найти в разделе «Разное» .

Список доменов с возможностью фильтрации доступен в разделе «Просмотр сайтов«.

P.S. Исходные коды whois и dns сервера доступны на github.

P.S.S. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

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

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Загрузка...
Отправить на почту Отправить на почту

Monit — это легковесная система мониторинга серверов, имеющая открытый исходный код. Monit устанавливается на сервер и обеспечивает возможность отправки уведомлений в случае обнаружения проблем. Кроме того, Monit может автономно выполнять определенное действие в качестве реакции на заданные события.

Программа имеет следующую функциональность:

  • Отслеживание состояния серверов (доступность, потребление ресурсов).
  • Мониторинг демонов (состояние, потребляемые ресурсы, количество child-process и многое другое).
  • Мониторинг сетевых сервисов (возможность подключения и корректность ответа).
  • Выполнение встроенных или собственных (с помощью скриптов) действий при достижении определенных событий.
  • Отправка уведомлений на Email или в централизованный web-интерфейс M/Monit.

Поддерживаются ОС GNU\Linux, FreeBSD, OpenBSD, Solaris, Mac OS X, AIX.

M/Monit — коммерческая надстройка над Monit, средство централизованного мониторинга, с помощью которого можно отслеживать состояние нескольких серверов с одного графического интерфейса. На официальном сайте доступна бесплатная версия с ограниченным функционалом.

Давно я, очень давно, хотел опробовать систему мониторинга monit, но все как-то руки не доходили.

Вот наконец настал сей момент. Действительно легкая, с хорошим функционалом, система.
Не буду распаляться о всех возможностях monit, т.к. в Инете инфы и так куча, остановлюсь на нескольких фичах:

  • на каждом хосте, где работает monit, есть возможность поднимать web-интерфейс для просмотра состояния системы и отслеживаемых ресурсах
  • возможность каждого хоста отправлять свои данные на другой хост через HTTP POST запрос с передачей XML

M/Monit как раз строится на последней фиче. Посмотрел M/Monit и понял две вещи:

  • идея одной страницы для всех хостов очень здравая, т.к. когда серверов десятки, то бегать по станицам каждого из них точно замучаешься
  • графики и прочее мне не нужны, т.к. для этого есть RRD, MRTG и т.п.

А мне нужна простая возможность окинуть взглядом состояние всех серверов с Monit.
Так я начал проект mmonit-free.subnets.ru, который решил выложить в общий доступ.

Получилась бесплатная и простая альтернатива M/Monit, которая обеспечивает отображение информации по всем серверам с установленным Monit в одном web-интерфейсе.
Уведомлениями о проблемах занимается сам Monit и потому в mmonit-free нет никаких баз данных и настроек.

Открыл, узрел последнюю информацию, осознал, закрыл. mmonit-free протестирован с Monit версии 5.25.0.

mmonit-free доступен на github: github.com/subnetsRU/mMonit-free

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

  • Скопируйте файлы проекта в директорию вашего HTTP сервера.
  • Отредактируйте файл config.php
  • Установите права на запись для папки collector/data для пользователя от которого запущен HTTP сервер.
  • В конфигурации monit укажите путь для отправки данных:
    • set mmonit http://ip-or-hostname-of-the-web-server/mMonit-free/collector/index.php

Пример указания коллектора в конфиге monitrc:

set mmonit http://mmonit-free.subnets.ru/collector/index.php
with timeout 15 seconds

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 2, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Специалисты обнаружили несколько новых уязвимостей в популярном протоколе NTP, который используется на бесчисленном количестве серверов в мире.

Природа брешей такова, что эксплуатировать их могут даже неподготовленные, начинающие хакеры.

Специалисты по информационной безопасности из корпорации Google обнаружили несколько критических уязвимостей в протоколе Network Time Protocol (NTP). Именно с его помощью в начале 2014 г.была проведенасамая мощная DDoS-атака в истории интернета.

«Новые уязвимости позволяют атакующему сформировать специальный пакет и, отправив его на целевую систему, вызвать переполнение буфера и далее выполнить в системе произвольный вредоносный код с привилегиями NTPD (фонового процесса, осуществляющего обмен данными по протоколу NTP)», — говорится в сообщении.

В этом случае, если NTPD имеет рут-права, злоумышленник получит корневой доступ к системе. Но даже если уровень прав гораздо ниже, хакеру ничто не мешает воспользоваться другими брешами в системе безопасности и поднять привилегии с их помощью.

Сложность ситуации в том, что протокол NTP используется на бесчисленном количестве серверов, роутеров и других сетевых устройств, подчеркивает Ars Technica. Кроме того, природа уязвимостей такова, что воспользоваться ими легко может даже неподготовленный, начинающий взломщик.

Специалисты рекомендуют системным администраторам срочно обновить NTPD до версии 4.2.8, выпущенной несколько дней назад. В ней найденные уязвимости были устранены. Эксперты отмечают, что информация о брешах размещена в свободном доступе в интернете, и уязвимости в настоящее время активно эксплуатируются хакерами.

Источник: http://www.cnews.ru/top/2014/12/22/beschislennoe_kolichestvo_serverov_mozhet_byt_atakovano_hakeramidiletantami_591140

Overview

The NTP Project ntpd version 4.2.7 and pervious versions allow attackers to overflow several buffers in a way that may allow malicious code to be executed. ntp-keygen prior to version 4.2.7p230 also uses a non-cryptographic random number generator when generating symmetric keys. These vulnerabilities affect ntpd acting as a server or client.

Description

The Network Time Protocol (NTP) provides networked systems with a way to synchronize time for various services and applications. The reference implementation produced by the NTP Project (ntp.org) contains several vulnerabilities.CWE-332: Insufficient Entropy in PRNG — CVE-2014-9293

If no authentication key is defined in the ntp.conf file, a cryptographically-weak default key is generated.

CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) — CVE-2014-9294

ntp-keygen before 4.2.7p230 uses a non-cryptographic random number generator with a weak seed to generate symmetric keys.

CWE-121: Stack Buffer Overflow — CVE-2014-9295

A remote unauthenticated attacker may craft special packets that trigger buffer overflows in the ntpd functionscrypto_recv() (when using autokey authentication), ctl_putdata(), and configure(). The resulting buffer overflows may be exploited to allow arbitrary malicious code to be executed with the privilege of the ntpd process.

CWE-389: Error Conditions, Return Values, Status Codes — CVE-2014-9296

A section of code in ntpd handling a rare error is missing a return statement, therefore processing did not stop when the error was encountered. This situation may be exploitable by an attacker.

The NTP Project provides more information about these issues in their security advisory.

The NTP Project implementation is widely used in operating system distributions and network products. These vulnerabilities affect ntpd acting as a server or client. CERT/CC is not aware of any public exploit of these vulnerabilities at this time.

The CVSS score below is based on the buffer overflow vulnerabilities (CVE-2014-9295).

Impact

The buffer overflow vulnerabilities in ntpd may allow a remote unauthenticated attacker to execute arbitrary malicious code with the privilege level of the ntpd process. The weak default key and non-cryptographic random number generator in ntp-keygen may allow an attacker to gain information regarding the integrity checking and authentication encryption schemes.

Solution

Apply an updateThese issues have been addressed in ntp-4.2.8. The update may be downloaded from ntp.org.
Restrict status queriesAs noted in the announcement for ntp-4.2.8:

The vulnerabilities listed below can be significantly mitigated by
following the BCP of putting

restrict default … noquery

in the ntp.conf file.  With the exception of:

receive(): missing return on error
References: Sec 2670 / CVE-2014-9296 / VU#852879

below (which is a limited-risk vulnerability), none of the recent
vulnerabilities listed below can be exploited if the source IP is
restricted from sending a ‘query’-class packet by your ntp.conf file.

 

Источник: http://www.kb.cert.org/vuls/id/852879

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Загрузка...
Отправить на почту Отправить на почту

Наткнулся на статью, т.к. сам частенько занимаюсь клонированием винтов, решил сохранить сей труд.

Итак сама статья:

Любой из нас хорошенько задумывается над тем, как правильно разбить HDD
при установке FreeBSD. Действительно, потом будет весьма проблематично
изменить размер патриции при необходимости. Проблема заключается в том,
что на жестком диске находятся, так называемые, слайсы, а уже в них
инкапсулированы партиции. Это не всегда так, потому что есть еще и
второй метод разметки HDD без слайсов, но в данной статье он не
рассматривается. Популярные программы для работы с разделами HDD, такие
как Partition Magic, Acronis могут удалить слайс,
скопировать/переместить его посекторно, но никак не заглянуть внутрь и
изменить размер той или иной партиции.

Итак, есть система (далее, система — это установленная ОС FreeBSD,
включающая в себя MBR, корневой раздел, SWAP, дополнительные разделы
/tmp, /var и т.д.) на жестком диске объемом 80 ГБ.

Задача: перенести систему на другой жесткий диск объемом 250 ГБ, увеличивая размеры
партиций пропорционально увеличению объема HDD. В нашем случае это
250-80=170 ГБ.

Вторая часть задачи: повторять эту процедуру автоматически, с определенным интервалом

(для создания резервной копии системы). В обоих случаях, нужно скопировать систему полностью, т.е. не
только файлы и каталоги, а и загрузочный сектор, загрузчик для сохранения возможности загрузки системы с полученной копии.

Для выполнения задачи воспользуемся утилиткой CloneHDD. Взять ее можно
здесь: http://sourceforge.net/projects/clonehdd Качаем дистрибутив последней версии и выполняем:

tar -zxvf clonehdd-2.0.3.tar.gz -C /home/user/

Можно сделать проще — установить из портов:

make install -C /usr/ports/sysutils/clonehdd

После установки мы видим грозное предупреждение о том, что запуская
clonehdd нужно семь раз отмерить а потом уже отрезать =)) Но все не так
страшно, как кажется: программа изначально рассчитана так, что данные на
исходном винте никогда и ни при каких условиях не подвергнутся записи.
Это сообщение больше относится к нашему новому, чистому винту. Поэтому,
если вы купили чистый винт и хотите на него переехать, то вряд ли
clonehdd чем то сможет навредить.

Работа с программой предельно проста. Для осуществления задуманного нам
нужно всего один раз запустить утилиту с нужными параметрами. Вот о
параметрах теперь поподробнее.

-src=[device] — Это исходный девайс на котором находится наша система.
Чтобы узнать имя текущего винта, нужно выполнить команду:

/sbin/mount

Мы увидим таблицу, в первой колонке которой указаны имена примонтированных
устройств. Вот, например:

/dev/ad0s1f

/dev/» это папка, в которой находятся все устройства, «ad0» это нужное нам имя самого винта,

«s1» слайс под номером 1, «f» имя партиции на слайсе.

Вывод: значение этому параметру присваиваем «ad0»

-dst=[device] Это девайс назначения. Именно сюда переедет ваша система.
Узнать его можно, например, командой:

cat /var/run/dmesg.boot

На экране появится список сообщений ядра при загрузке. Обычно, сообщения о
найденных винтах находятся в самом конце. Ни одна партиция не должна
быть примонтирована с этого винта, иначе CloneHDD выдасть ошибку.

-swap=[size in MB] Размер будущего раздела SWAP.

-freespace=[Required free space on dst partition] Если клонирование
производится на винт меньшего размера, на DST винте после клонирования
должен остаться небольшой кусочек свободного места, для того чтобы винт
небыл на 100% заполнен после клонирования. По умолчанию — это 100МБ.
Этим параметром его можно изменить.

-safe [Required safe mode for `dump`] Включает режим безопасного
копирования. В этом режиме сначала создается образ каждого раздела в
папке .snap, а потом делается перенос. В «небезопасном» режиме,
копирование производится на лету. Вся проблема в том что размер этого
образа равен размеру данных на разделе. А т.к. образ будет записан на
тот же раздел с которого производится копирование, на разделе долно быть
минимум 50% свободного места. Вернемся к параметру -safe. Если параметр
отсутствует, клонирование будет произведено в безопасном режиме если
достаточно свободного места или в небезопасном режиме если этого места
недостаточно. Если параметр задан, небезопасного копирования не будет, и
разделы с недостатком свободного места склонированы не будут.

-fstab=[Device name to write in fstab] После клонирования будет
сгенерирован файл /etc/fstab на полученном винте. Параметр задает Имя
девайса, который будет записан в этот файл. По умолчанию: девайс,
заданный параметром -src.

-force [Do not ask any questions] При выполнении второй части задачи,
утилита будет выполняться из cron’а и нам не нужны лишние вопросы, в
ходе выполнения программы. Данный параметр отключает интерактивный режим
и вопрос «Are you sure?» задаваться не будет.

Вернемся к нашей задаче. Мой исходный винт: ad0, новый винт: ad1.

srv# clonehdd -src=ad0 -dst=ad1 -swap=1024
Clone parameters:
Source partition: /dev/ad0
Dest partition: /dev/ad1
Swap size: 1024 MB
Safe dumping: Disabled
Free space on DST: 100 MB
Fstab device name: ad0

[OK] Found devices for clone procedure
[OK] DST partition is not in use

Source partition
/usr size: 64489MB, used: 10563MB
/var size: 4958MB, used: 144MB
/ size: 1483MB, used: 82MB
/tmp size: 1483MB, used: MB
Total: 72415 MB, used: 10790 MB

[OK] Device ad1 has enough free space
Wait 10 seconds before start: 10 9 8 7 6 5 4 3 2 1
[OK] Device /dev/ad1 made clean
[OK] New slice created

Destination device partitions:
SWAP size: 1024 MB
/ size 1588 MB
/tmp size 1588 MB
/var size 5306 MB
/usr size 69026 MB

[INF] Last partition were increased for 3 blocks
[OK] Partitions were created successfully

[OK] Partition /tmp was formatted successfully
Starting dump/restore procedure… [OK]

[OK] Partition /var was formatted successfully
Starting dump/restore procedure… [OK]

[OK] Partition /usr was formatted successfully
Starting dump/restore procedure… [OK]

[OK] Partition / was formatted successfully
Starting dump/restore procedure… [OK]

[OK] file /etc/fstab generated successfully

Видим сообщения об успешном клонировании. Теперь сделаем выполнение
задачи по расписанию: выполнять каждый день в 2 часа ночи клонирование
рабочего винта на запасной. Добавляем в файл /etc/crontab строку

0 2 * * * root clonehdd -src=ad0 -dst=ad1 -swap=1024 -force >/dev/null

Обратите внимание, что >/dev/null убивает не все сообщения. Только
обычные сообщения будут опущены. Все сообщения об ошибках отсылаются на
выход STDERR, не попадают на /dev/null и будут отправлены cron’ом по
почте системному администратору.

Автор: Bart Tapolsky, Оригинал тут

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 5, среднее: 4,40 из 5)
Загрузка...
Отправить на почту Отправить на почту

Рассмотрим пример настройки протокола BGP на оборудовании Cisco Systems.

В основном принципе настройка на Cisco ничем не отличается от настройки BGP на FreeBSD используя Quagga.

Для примера возьмем немного другую ситуацию чем в предыдущей статье, итак:

схема BGP

AS100 — наш номер ASки

5.5.0.0/20 — анонсируемый нами префикс (наш блок адресов)

AS200 — наш апстрим, который отдает нам full-view (полную таблицу маршрутов)

AS300 — наш privat peer (приватный пир), который отдает нам маршруты в свою AS и своего клиента AS400.

С чего начать ?

С настройки интерфейсов конечно.

GigabitEthernet3/0 — AS200
GigabitEthernet3/1 — AS300

Зайдите на router телнетом и перейдите в enable режим.

cisco# conf t
cisco(config)# interface GigabitEthernet3/0
cisco(config-if)# ip address 1.1.1.2 255.255.255.252
cisco(config-if)# interface GigabitEthernet3/1
cisco(config-if)# ip address 2.2.2.10 255.255.255.252
cisco(config-if)# exit

Добавим маршруты, сначала отправим туда, откуда не возвращаются :), маршруты в «серые сети»:


cisco(config)# ip route 10.0.0.0 255.0.0.0 Null0 254
cisco(config)# ip route 172.16.0.0 255.240.0.0 Null0 254
cisco(config)# ip route 192.168.0.0 255.255.0.0 Null0 254

Затем добавим маршрут на свой полный блок:


cisco(config)# ip route 5.5.0.0 255.255.240.0 Null0 254

Протокол BGP не будет анонсировать префикс, пока сам не узнает маршрут до него.
Именно для этого мы и создали этот маршрут, который будет присутствовать в таблице маршрутизации всегда.
Вы можете пророутить внутрь своей сети как полный блок (тогда маршрут в Null0 (нуль ноль) можно и не добавлять) так и его, побитые на подсети, части.  Например подсети по /21:

cisco(config)# ip route 5.5.0.0 255.255.248.0 10.0.0.2
cisco(config)# ip route 5.5.0.0 255.255.248.0 10.0.0.3

Где:

  • 10.0.0.2
  • 10.0.0.3

маршрутизаторы внутри сети. Ессно, что они должны быть доступны с маршрутизатора BGP.

Роутер всегда отправляет пакеты по маршруту с лучшим совпадением по маске, именно поэтому маршрут в Null0 и два маршрута, которые мы сделали выше, будут прекрасно сосуществовать и пакеты будут идти на хосты 10.0.0.2 и 10.0.0.3, т.к. у них более точное совпадение по маске.

Приступим к созданию необходимых route-map. Сначала начнем со всего «серого» (адресов и номеров AS).

Создадим необходимые prefix-list и as-path access-list.

Маршрут в default:
cisco(config)# ip prefix-list bogons description bogus nets
cisco(config)# ip prefix-list bogons seq 15 permit 0.0.0.0/8 le 32

Затем остальное:
cisco(config)# ip prefix-list bogons seq 20 permit 127.0.0.0/8 le 32
cisco(config)# ip prefix-list bogons seq 25 permit 192.0.2.0/24 le 32
cisco(config)# ip prefix-list bogons seq 30 permit 10.0.0.0/8 le 32
cisco(config)# ip prefix-list bogons seq 35 permit 172.16.0.0/12 le 32
cisco(config)# ip prefix-list bogons seq 40 permit 192.168.0.0/16 le 32
cisco(config)# ip prefix-list bogons seq 45 permit 169.254.0.0/16 le 32
cisco(config)# ip prefix-list bogons seq 50 permit 192.42.172.0/24 le 32
cisco(config)# ip prefix-list bogons seq 55 permit 198.18.0.0/15 le 32
cisco(config)# ip prefix-list bogons seq 60 permit 192.88.99.0/24 le 32
cisco(config)# ip prefix-list bogons seq 65 permit 224.0.0.0/4 le 32
cisco(config)# ip prefix-list bogons seq 70 permit 240.0.0.0/4 le 32

Теперь «серые» номера AS`ок:
cisco(config)# ip as-path access-list 1 permit _6451[2-9]_
cisco(config)# ip as-path access-list 1 permit _645[2-9][0-9]_
cisco(config)# ip as-path access-list 1 permit _64[6-9][0-9][0-9]_
cisco(config)# ip as-path access-list 1 permit _65[0-9][0-9][0-9]_

Создадим маршрутную карту на IN для AS200 (нашего апстрима).
Запрещаем маршруты с «серыми» номерами AS в as-path, то что матчит (разрешает (permit)) наш as-path access-list, то запрещает наша следующая маршрутная карта:

cisco(config)# route-map map-AS200-in deny 100
cisco(config-route-map)# description — filter private ASs
cisco(config-route-map)# match as-path 1
cisco(config-route-map)# exit

Теперь по маршруту по умолчанию и «серым» сетям, логика действия как и в пред. случае, запрещаем то что permit в prefix-list bogons:

cisco(config)# route-map map-AS200-in deny 110
cisco(config-route-map)# description — — filter bogons
cisco(config-route-map)# match ip address prefix-list bogons
cisco(config-route-map)# exit

Ну и последнее, т.к. мы хотим принимать от AS200 full-view (т.е. полную таблицу), то:

  • разрешаем все остальные маршруты
  • выставляем local-preference по умолчанию внутри своей AS

cisco(config)# route-map map-AS200-in permit 200
cisco(config-route-map)# description — permit any else, set default loc-pref
cisco(config-route-map)# set local-preference 100
cisco(config-route-map)# exit

Создадим маршрутную карту на OUT для AS200 (нашего апстрима). Эта маршрутная карта нужна нам для того, чтобы наша AS анонсировала только свой префикс. Если маршрутной карты на OUT не будет, то ваша AS будет анонсировать всем своим соседям все известные ей маршруты и вы, сами того не желая, дадите возможность прогонять через вас трафик.
Но прежде создадим префикс лист со своим префиксом:

cisco(config)# ip prefix-list own-prefixes permit 5.5.0.0/20

Вот теперь вернемся к маршрутке на OUT:

cisco(config)# route-map map-AS200-out permit 100
cisco(config-route-map)# description — permit our prefixes
cisco(config-route-map)# match ip address prefix-list own-prefixes
cisco(config-route-map)# exit

Т.к. в конце маршрутки по умолчанию идет неявный deny, то все остальные префиксы (маршруты) будут запрещены.

Настало время приступить к маршрутным картам для нашего private peer`а.
Т.к. от него мы собираемся получать только маршруты принадлежащие ему (AS300) и его клиенту (AS400), то будет проще, разрешим только необходимые префиксы, а все остальное запретим:

cisco(config)# ip prefix-list peer-prefixes permit 11.11.0.0/21
cisco(config)# ip prefix-list peer-prefixes permit 12.12.0.0/21

Теперь можно создать маршрутную карту на IN, в которой разрешим необходимые префиксы и поднимем loc-pref, на данные префиксы, чтобы маршруты полученные от этого пира имели приоритет над маршрутами к этим префиксам полученными от других апстримов/пиров:

cisco(config)# route-map map-AS300-in permit 100
cisco(config-route-map)# description — — permit peer prefix
cisco(config-route-map)# match ip address prefix-list peer-prefixes
cisco(config-route-map)# set local-preference 200
cisco(config-route-map)# exit

Ну и тут не обойдется без маршрутной карты на OUT:

cisco(config)# route-map map-AS300-out permit 100
cisco(config-route-map)# description — permit our prefixes
cisco(config-route-map)# match ip address prefix-list own-prefixes
cisco(config-route-map)# exit

Зачем мы создали две маршрутные карты на OUT с разными названиями, но с одинаковым содержимым ?
Ответ прост. Если, в последствии, нам нужно будет, например добавить community к своему маршруту или оглашать свой блок меньшими подсетями, то все равно придется делать разные маршрутные карты, вот поэтому сделаем это сразу, чтобы потом не изменять конфигурацию bgp, а просто подправить маршрутную карту.

Закончим подготовку перед настройкой BGP:

cisco(config)# ip classless
cisco(config)# ip routing
cisco(config)# ip subnet-zero

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

cisco(config)# router bgp 100
cisco(config-router)# no synchronization
cisco(config-router)# bgp log-neighbor-changes
cisco(config-router)# bgp deterministic-med

Объявим наш префикс:
cisco(config-router)# network 5.5.0.0 mask 255.255.240.0

Пропишем наего апстрима AS200:
cisco(config-router)# neighbor 1.1.1.1 remote-as 200
cisco(config-router)# neighbor 1.1.1.1 description AS200-upstream
cisco(config-router)# neighbor 1.1.1.1 send-community
cisco(config-router)# neighbor 1.1.1.1 version 4
cisco(config-router)# neighbor 1.1.1.1 soft-reconfiguration inbound
cisco(config-router)# neighbor 1.1.1.1 route-map map-AS200-in in
cisco(config-router)# neighbor 1.1.1.1 route-map map-AS200-out out

Пропишем нашего private peer`а:
cisco(config-router)# neighbor 2.2.2.9 remote-as 300
cisco(config-router)# neighbor 2.2.2.9 description AS300-private-peer
cisco(config-router)# neighbor 2.2.2.9 send-community
cisco(config-router)# neighbor 2.2.2.9 version 4
cisco(config-router)# neighbor 2.2.2.9 soft-reconfiguration inbound
cisco(config-router)# neighbor 2.2.2.9 route-map map-AS300-in in
cisco(config-router)# neighbor 2.2.2.9 route-map map-AS300-out out

Заканчиваем:
cisco(config-router)# distance bgp 180 200 200
cisco(config-router)# no auto-summary
cisco(config-router)# exit
cisco(config)# exit
cisco# wri

После запуска посмотрите, что все настроенные BGP сессии поднялись. Команда:
cisco# show ip bgp summary

Так же стоит взгянуть что именно мы огласили нашему апстриму:
cisco# show ip bgp neighbors 1.1.1.1 advertised-routes

И нашему private peer`у:
cisco# show ip bgp neighbors 2.2.2.9 advertised-routes

Можно взглянуть и что мы от них получили:
cisco# show ip bgp neighbors 1.1.1.1 received-routes
cisco# show ip bgp neighbors 2.2.2.9 received-routes

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


Заметка:
После каждого изменения route-map, в процессе работы, чтобы изменения вступили в силу необходимо оборвать (clear`нуть) BGP сессию с сосседом. Для того чтобы этого не делать и существует команда soft-reconfiguration inbound при настройке neighbor. Она заставляет роутер хранить маршруты полученные от соседа не только после обработки вашими route-map, но и до этого.
Тем самым вы не обрываете сессию с соседом, а роутер просто берет сохраненные у себя маршруты, которые пришли от соседа и сохранены в первозданном виде ДО обработки вашими route-map и снова прогоняет их через уже измененную route-map.
Например вы изменили route-map map-AS200-in, значит нуна клирнуть сессию с соседом IP-адрес 1.1.1.1.
cisco# clear ip bgp 1.1.1.1 soft in


Заметка:
Если вы хотите принимать от BGP соседа маршруты не более определенной маски, то необходимо создать prefix-list с указанием le или ge:

  • eq — Matches the exact prefix length
  • ge — Matches a prefix length that is equal to or greater than the configured prefix length
  • le — Matches a prefix length that is equal to or less than the configured prefix length

Например: принимать все маршруты с любым префиксом, но не более /24:
cisco(config)# ip prefix-list prefix-range seq 5 permit 0.0.0.0/0 le 24
cisco(config)# route-map peer-in permit 200
cisco(config-route-map)# match ip address prefix-list prefix-range


Полезные ссылки:

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

Автор: Николаев Дмитрий (virus (at) subnets.ru)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 14, среднее: 3,93 из 5)
Загрузка...
Отправить на почту Отправить на почту