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

Кратко о BIRD:

 The BIRD project aims to develop a fully functional dynamic IP routing daemon.

 - Both IPv4 and IPv6
 - Multiple routing tables
 - BGP
 - RIP
 - OSPF
 - Static routes
 - Inter-table protocol
 - Command-line interface
 - Soft reconfiguration
 - Powerful language for route filtering

 WWW: http://bird.network.cz/

 Пользователи FreeBSD могут найти демоны BIRD в портах:
    IPv4 версия: /usr/ports/net/bird
    IPv6 версия: /usr/ports/net/bird6

С момента размещения статьи Используем BIRD для создания «пограничного» маршрутизатора размещенную zaikini, я все мечтал найти время и уделить его изучению и пробам BIRD.

О демоне BIRD народ хорошо отзывается, да и многие IX`ы держат свои Route Server`а именно на этом демоне.

И вот наконец мне предоставилась такая возможность. Для одного проекта понадобилось автоматом генерить blackhole маршруты для BGP и тут я вспомнил что как раз давно хотел попробовать BIRD.

Поднял на тестовом стенде из тройки виртуальных машин:

• FreeBSD 9.1 + BIRD 1.3.11
• FreeBSD 8.4 + BIRD 1.3.11
• FreeBSD 7.2 + BIRD 1.3.2
• FreeBSD 7.2 + BIRD 1.3.11

Погонял BGP и OSPF в различных конфигурациях и схемах — понравилось. Даже больше скажу — очень понравилось. Есть конечно в BIRD некоторые вещи пока не совсем мне понятные или как это сказать не до конца логичные, НО в целом абалденный демон. Респект и уважуха разработчикам BIRD.

Итоговый «приговор» по BIRD: must have.

До сего момента мы работали на Quagga, но она иногда реально достает своими непонятными приколами, когда после реконфига чего либо помогает тока рестарт демонов дабы эти изменения наконец сказались.

Рестарт bgpd и о чудо ! Все непонятки устраняются и все работает как и положено. Но сейчас не об этом речь 🙂

Вообщем пересели мы на BIRD. Что дальше ? А дальше, как это водится, понадобился Looking Glass для BIRD`а, не всегда ж есть желание/возможность лазать в консоль 🙂

Погуглил… нагуглил только sileht/bird-lg и ulg—universal-looking-glass — оба написаны на python.

Попытки найти нечто подобное лукинг глассу для Cisco/Quagga/Juniper и на PHP мне не удалось.

«Ну что ж… Толи лыжи, толи … получается что нету… значит надо написать самому.» — сказал я и приступил к реализации :).

Через некоторое время первая версия LG на PHP была готова и протестирована.

Пока из функционала было реализовано самое необходимое — возможность посмотреть маршрут, пингать и трасернуть.

Потом я подумал о том, что скорее всего я не один такой, кто не хочет/может пользоваться LG на питоне, так же о (похоже) единственно существующем варианте LG для BIRD`а, а так же о том что сам пользуюсь бесплатным ПО, которое пишут и выкладывают другие и … и решил что нужно так же поделиться с общественностью своей разработкой.

Итак представляю вам свой труд и новый проект в рамках проекта Subnets.ru: BIRD Looking Glass на PHP.

Для работы LG вам необходимо:

• установленный и запущенный BIRD
• web сервер (аля apache)
• PHP5: модуль для apache и CLI версия

Более детально написано в README и ошибках, которые, если чего то не хватает, вам будет выдавать web интерфейс LG после его установки.

Я не смотрю на свои возможности через «розовые очки», я больше сис.админ чем программист, но все же кое что напрограммить и я могу 🙂

Лично я свою первоочередную задачу (наличие хоть какого LG для BIRD на PHP) решил. Возможно сей «продукт» поможет и вам.

Это явно не последняя версия этого LG, как снова дойдут руки — буду допиливать функционал далее, благо дело мыслей много, а желаний (как это обычно и бывает) ещё больше :).

В LG встроен механизм проверки наличия новой версии, поэтому если таковая появится, то те кто установит и будет использовать узнают об этом зайдя на главную страницу своего LG.

Надо ли пояснять, что для функционирования сего механизма сервер с LG должен иметь доступ к Инету, а если быть точнее то к URL`у http://bird-lg.subnets.ru/.

Работа LG проверена под OS FreeBSD, если у вас другая ось то вы как раз проверите сами.

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

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

В продолжении статьи PPPoE сервер на встроенном в FreeBSD демоне pppoed рассмотрим ситуацию с LCP и LQR.

Немного теории:

LCP — сокращение от Link Control Protocol — протокол управления соединением.

LCP является частью протокола Point-to-Point.
При установлении соединения PPP передающее и принимающее устройство обмениваются пакетами LCP для уточнения специфической информации, которая потребуется при передаче данных.
Согласование параметров соединения проводится в форме переговоров.
LCP протокол осуществляет:

• проверку идентификации соединяемых устройств и, вследствие этого разрешает или отклоняет установку соединения
• определение приемлемого размера кадров для передачи MTU и приёма — MRU
• ограничение по ширине канала
• шифрование аутентификации соединения
• сжатие данных
• обнаружение петель маршрутизации
• проверку синтаксиса и поиск ошибок в конфигурации
• разрыв соединения, если какое-либо значение превышает заданный параметр

Устройства не могут передавать данные друг другу по сети прежде чем LCP пакеты не определят доступность устанавливаемого соединения.

LQR — Link Quality Report так же является частью протокола Point-to-Point и нужен для оценки состояния и качества связи PPP.

Если вы используете демон pppoed под FreeBSD, то в логах /var/log/ppp.log вам могут встречаться такие строки:

Apr 5 12:16:41 vpn-01 ppp[3951]: tun1: Warning: lqr_RecvEcho: Got sig 0x22c61241, not 0x594e4f54 !

 .... 

Apr 5 12:17:01 vpn-01 ppp[3951]: tun1: Phase: deflink: ** Too many LCP ECHO packets lost **

Первая строка говорит о том что lqr.magic в полученном пакете не верен.

Вторая строка появится после того как вы 5-ть раз увидете по данному туннелю первую строчку и затем данный туннель будет отключен принудительно.

Затем юзер реконнектнется и все повторится с начала…. и так до бесконечности.

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

 

Что же с этим делать ?

Вариантов несколько:

1. отключить LQR совсем
2. позвонить пользователю и сказать что его роутер не годен для работы в вашей сети
3. ковырять и править исходники ppp

Отключать LQR совсем не вариант, т.к. тогда зависший туннель точно никогда не отвалится, а это не есть гуд. Предлагать пользователю сменить роутер равнозначно предложить ему сменить провайдера.

Получается что остается один вариант —  ковырять исходники ppp и нужно сделать так, чтобы  не было реагирования на состав меджика.

Для FreeBSD 8.2 это будет происходить так:

Идем в сорцы /usr/src/usr.sbin/ppp/ и находим в этой папке файл lqr.c.
Правим его, diff можно увидеть тут. А именно просто комментарим тот IF, который проверяет меджик, выводит нам сообщение и не увеличивает каунтер полученных LCP пакетов.

Затем делаем make и после чего в /usr/obj/usr/src/usr.sbin/ppp появится вновь собранный файл ppp.
Теперь наша задача плавно перевести пользователей на вновь собранный демон, т.к. тупо заменить им текущий может и не получится в виду того, что на каждый PPPoE туннель создается отдельный процесс:

97011 ?? Ss 0:03,33 /usr/sbin/ppp -direct pppoe

и фря может отказать вам в замене файла.

То у нас три варианта:

• перезапустить сервер
• убить все процессы ppp
• вызывать новый ppp только при новых подключениях

Действуем по последнему варианту, т.к. это позволит плавно перевести пользователй, ведь рано или поздно все переподключатся и мы сможем заменить старый /usr/sbin/ppp.

Берем новый ppp и копируем в /usr/sbin/ppp.new.

Не забудьте выставить владельца и права на новый файл так же как это было у старого:

-r-sr-x---  1 root  network  412608 26 Apr 13:14 /usr/sbin/ppp

# chmod 4550 /usr/sbin/ppp.new
# chgrp network /usr/sbin/ppp.new

Затем убиваем все процессы pppoed и стартуем их снова, но чуть изменив строку запуска:

# /usr/libexec/pppoed -a vpn-01 -p "*" -e "/usr/sbin/ppp.new -direct pppoe" em1

Что при подключении пользователя запустит уже не /usr/sbin/ppp, а /usr/sbin/ppp.new.

После того как все готово можно посмотреть как подключаются пользователи и убедиться в том, что Warning: lqr_RecvEcho более не появляется, а пользователи, которые из-за этого отваливались, более не отваливаются.

Как только процессов ppp не останется, мы сможем заменить старый новым и вернуть строку запуска pppoed к прежней.

Ещё одно полезное дополнение для pppoed это дополнить информацию в его логах.

По дефотлу подключение клиента в /var/log/pppoed.log выглядит так:

Apr 5 09:34:19 vpn-01 pppoed[58768]: Listening as provider * 

Apr 5 09:34:19 vpn-01 pppoed[58904]: Offering to .:exec-58904 as access concentrator vpn-01 

Apr 5 09:34:19 vpn-01 pppoed[58904]: adding to .:exec-58904 as offered service vpn-01 

Apr 5 09:34:19 vpn-01 pppoed[58904]: Received NGM_PPPOE_SESSIONID (hook "^C") 

Apr 5 09:34:19 vpn-01 pppoed[58904]: Received NGM_PPPOE_SUCCESS (hook "exec-58904") 

Apr 5 09:34:19 vpn-01 pppoed[58904]: Executing: exec /usr/sbin/ppp -direct pppoe

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

Apr 5 09:00:52 vpn-01 pppoed[73025]: Offering to .:exec-73025 as access concentrator vpn-01 at [vlan65] 

Apr 5 09:00:52 vpn-01 pppoed[73025]: adding to .:exec-73025 as offered service vpn-01 at [vlan65] 

Apr 5 09:00:52 vpn-01 pppoed[73025]: Received NGM_PPPOE_SESSIONID (hook "ü ÿÿÿ^?") [40:4a:03:a8:e3:a0] at [vlan65] 

Apr 5 09:00:52 vpn-01 pppoed[73025]: Received NGM_PPPOE_SUCCESS (hook "exec-73025") [40:4a:03:a8:e3:a0] at [vlan65] 

Apr 5 09:00:52 vpn-01 pppoed[73025]: Executing: exec /usr/sbin/ppp -direct pppoe for .:exec-73025: [40:4a:03:a8:e3:a0] at [vlan65]

Так становится более понятнее о том к какому клиенту относятся строчки в логе и за каким интерфейсом сервера расположен клиент.

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

Авторы: Николаев Дмитрий (virus (at) subnets.ru) и Панфилов Алексей (lehis (at) subnets.ru)

Продолжим обустройство нашей AS5350 и VoIP сети 🙂

Задача

Автоматизация управления VoIP dialpeer’ами на Cisco AS5350.

Решение

Протокол snmp уже используется для отображения картины загрузки потоков (OID: 1.3.6.1.4.1.9.10.19.1.1.9.1.3.номер_слота.номер_порта), то было принято решение управлять по этому же протоколу. Воспользовавшись гуглом и  SNMP Object Navigator, были найдены нужные OID’ы:

Для работы с AS5350 по протоколу snmp воспользуемся утилитами snmpwalk и snmpset из пакета net-snmp.

Получить все диалпиры:

# snmpwalk -v1 -c RO-community -O n 192.168.68.3 .1.3.6.1.2.1.10.21.1.2.1.1.5

.1.3.6.1.2.1.10.21.1.2.1.1.5.11.244 = STRING: «(0072)?84990088048»
.1.3.6.1.2.1.10.21.1.2.1.1.5.12.243 = STRING: «84950003211»
.1.3.6.1.2.1.10.21.1.2.1.1.5.13.195 = STRING: «(0072)?84950003220»

….

.1.3.6.1.2.1.10.21.1.2.1.1.5.246.196 = STRING: «0003217»

Например, нас интересует номер 84950003211, поэтому разберем строку вывода для этого номера поподробнее:

.1.3.6.1.2.1.10.21.1.2.1.1.5.12.243 = STRING: «84950003211», где 12 — номер дилапира на Cisco, 243 — индекс интерфейса по snmp (ifIndex)

Далее, для выключения диалпира нам нужно на него передать команду shutdown, что можно сделать по протоколу snmp при помощи OID 1.3.6.1.2.1.2.2.1.7.ifIndex:

# snmpset -v1 -c WR-community 192.168.68.3 1.3.6.1.2.1.2.2.1.7.243 i 2

.1.3.6.1.2.1.2.2.1.7.243 = INTEGER: down(2)

для его включения:

# snmpset -v1 -c WR-community 192.168.68.3 1.3.6.1.2.1.2.2.1.7.243 i 1

.1.3.6.1.2.1.2.2.1.7.243 = INTEGER: up(1)

Принципиально наша задача решена. Как и на чем ее накодить — оставляем выбор за вами.

 

Перечислю несколько полезных OID’ов ([rw] — OID используется и для чтения и для записи):

• 1.3.6.1.2.1.10.21.1.2.1.1.4.DialpeerNumber.ifIndex — destination pattern
• 1.3.6.1.2.1.10.21.1.2.1.1.5.DialpeerNumber.ifIndex — answer address
• 1.3.6.1.2.1.2.2.1.7.ifIndex [rw] — Состояние интерфейса

1:up
2:down

• 1.3.6.1.4.1.9.9.63.1.2.4.1.5.ifIndex [rw] — huntstop

1:true

2:false

• 1.3.6.1.4.1.9.9.63.1.2.4.1.4.ifIndex [rw] — preference
• 1.3.6.1.4.1.9.9.63.1.2.4.1.2.ifIndex [rw] — max-conn
• 1.3.6.1.4.1.9.9.63.1.2.3.1.4.ifIndex [rw] — session target
• 1.3.6.1.4.1.9.9.63.1.2.3.1.1.ifIndex [rw] — session protocol

1:other
2:cisco
3:sdp
4:sip
5:multicast

• 1.3.6.1.4.1.9.9.63.1.2.3.1.6.ifIndex [rw] — fax rate

1:none
2:voiceRate
3:fax2400
4:fax4800
5:fax7200
6:fax9600
7:fax14400
8:fax12000

• 1.3.6.1.4.1.9.9.63.1.2.3.1.5.ifIndex [rw] — codec

1:g729r8000
2:g729Ar8000
3:g726r16000
4:g726r24000
5:g726r32000
6:g711ulawr64000
7:g711Alawr64000
8:g728r16000
9:g723r6300
10:g723r5300
11:gsmr13200
12:g729Br8000
13:g729ABr8000
14:g723Ar6300
15:g723Ar5300
16:g729IETFr8000
17:gsmeEr12200
18:clearChannel
19:g726r40000
20:llcc
21:gsmAmrNb

Если используется voice-class codec для задания группы кодеков, то OID вернет первый кодек из группы.

 

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

Автор:  Панфилов Алексей (lehis (at) subnets.ru)

В продолжении предыдущей статьи Juniper и Policy-based routing ( PBR ) появилась задача когда необходимо чтобы маршруты из таблицы inet.2 (mBGP) попадали не только в нее, но и в таблицу inet.0 (eBGP).

Расскажу и покажу как это сделали мы.

Дано

• MX80 (JUNOS 10.4R1.9)
• апстрим с двумя BGP сессиями eBGP и mBGP

Задача

Импортировать маршруты принимаемые в сессии mBGP (роутинг таблица inet.2) в таблицу сессии eBGP (таблица inet.0).

Реализация

Состояние ДО изменений:

Для примера возьмем маршрут до подсети 11.11.11.192/28.
Посмотрим текущий маршрут до этой подсети:

juniper-MX80> show route terse 11.11.11.192
inet.2: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

Видим что данный маршрут находится только в таблице inet.2, это то мы и будем «исправлять».

Приступим. Как и в случае с PBR нам поможет механизм rib-groups.
Создадим rib группы:

routing-options {
    rib-groups {
        bgp-multicast-rg {
            export-rib inet.2;
            import-rib [ inet.2 inet.0 ];
        }
        bgp-unicast-rg {
            export-rib inet.0;
            import-rib inet.0;
        }
    }
}

Мы создали две rib группы: одну для unicast, другую для multicast. В rib группе multicast в import-rib мы указали, что принимаемые маршруты нужно импортировать и в таблицу inet.0.

Теперь опишем эти rib группы в protocols bgp:

protocols {
    bgp {
        family inet {
            unicast {
                rib-group bgp-unicast-rg;
            }
            multicast {
                rib-group bgp-multicast-rg;
            }
        }
    }
}

Ну и сами BGP пиры, один eBGP, другой mBGP:

protocols {
    bgp {
        log-updown;
        local-as 65000;
        group ebgp {
            type external;
            no-advertise-peer-as;
            neighbor 10.10.10.229 {
                description eBGP_peer;
                import bgp-import;
                family inet {
                    unicast;
                }
                export bgp-export;
                peer-as 65500;
            }
        }
        group mbgp {
            type external;
            no-advertise-peer-as;
            neighbor 20.20.20.209 {
                description mBGP_peer;
                import bgp-mcast-import;
                family inet {
                    multicast;
                }
                export bgp-mcast-export;
                peer-as 65500;
            }
        }
    }
}

После commit`а смотрим появился ли маршрут в таблице inet.0:

juniper-MX80> show route terse 11.11.11.192

inet.0: 51 destinations, 51 routes (44 active, 0 holddown, 7 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

inet.2: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 11.11.11.192/28  B 170        100            >20.20.20.209   65500 I

А вот теперь мы видим что наш маршрут присутствует в двух таблицах, что нам и было надо.

Ссылки

• Interdomain multicast routing: practical Juniper Networks and Cisco systems
• rib-group

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

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

 

Я уже писал об использовании PBR на оборудовании Cisco, а в этой статье мы будем это делать на Juniper.

PBR предоставляет механизм реализации пересылки (forwarding)/ маршрутизации (routing) пакетов данных, основанный на политике, представляющей собой набор правил, определенной администраторами сети. Это предоставляет более гибкий механизм для обработки пакетов на маршрутизаторах, дополняя существующий механизм, предоставленный протоколами маршрутизации.

Дано

• ISP#1 (10.0.0.1/30), подключение по BGP
• ISP#2, подключение по BGP
• Juniper MX240

Задача

Настроить BGP сессии с двумя ISP`ами, а так же обеспечить работу статически пророученную на нас ISP#1 небольшую реальную подсеть, для примера скажем это будет 128.1.1.0/24.

Реализация

Если не применить PBR политику к статически пророученной ISP#1 подсети, то при передаче пакетов будут использовать маршруты, которые были получены по BGP от двух ISP`ов и пакеты от реальной подсети ISP#1 могут уходить в канал через ISP#2, что в большинстве случаях работать не будет, в виду того что ISP#2 не выпустит чужие подсети через свою инфрастуктуру или вы получите не симметричную трассу. К сожалению мы по своей работе сталкиваемся с провами, которые не осуществляют фильтрацию чужих подсетей, что развязывает руки DDoS`ерам… когда при атаках они подделывают SRC адреса. Я искренне надеюсь, что ты (читатель) осуществляешь фильтрацию перед тем как «выплюнуть» пакет из своей сети в свой внешний канал.

Немного теории по названиям роут таблиц в Junos`е:

JUNOS default routing tables Name

• inet.0 — IPv4 unicast routes. BGP, IS-IS, OSPF, and RIP store their routing information in this table and use the routes in this table when advertising routes to their neighbors. Configured static routes are also stored in this table.
• inet.1 — Multicast forwarding cache. DVMRP and PIM store their routing information in this table.
• inet.2 — Used by MBGP to provide reverse path forwarding (RPF) checks.
• inet.3 — Traffic engineering paths. Stores path and label information.
• inet6.0 — IPv6 unicast routes.
• iso.0 — ISO routes for IS-IS.
• mpls.0 — MPLS label-switched path (LSP) next hops.

 

В реализации задачи нам поможет механизм rib-groups:

rib-groups group-name {
     import-policy [ policy-names ];
     import-rib [ routing-table-names ];
     export-rib routing-table-name;
}

А так же interface-routes:

interface-routes {
     rib-group group-name;
}

Приступим к настойке и для начала создадим rib группу, в конфиге получим:

root@mx240# show routing-options
interface-routes {
    rib-group inet isp1-static-group;
}
rib-groups {
    isp1-static-group {
        import-rib [ inet.0 isp1-static.inet.0 ];
    }
}

Затем создадим routing-instance isp1-static в которой и укажем default на ISP#1:

root@mx240# show routing-instances
isp1-static {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 10.0.0.1;
        }
    }
}

Теперь нам надо как то match`ить пакеты где source адресом выступает статически пророученная подсеть реальников 128.1.1.0/24 и перенапралять их в routing-instance isp1-static.
В этом нам поможет firewall filter:

root@mx240# show firewall filter isp1-static-subnets
term match {
    from {
        source-address {
            128.1.1.0/24;
        }
    }
    then {
        routing-instance isp1-static;
    }
}
term default {
    then accept;
}

Этим мы добиваемся того, что пакеты из подсети 128.1.1.0/24 будут маршрутизироватся по таблице isp1-static, а все остальные подсети будут использовать таблицу по умолчанию inet.

Что нам осталось сделать ?
Осталось применить наш filter на Layer-3 интерфейсе роутера откуда у нас поступают пакеты от клиентов с source адресом этой подсети.
В моем примере это vlan 3, т.к. именно за данным интерфейсом находится ещё один роутер, для клиентов в подсети 128.1.1.0/24:

root@mx240# show routing-options static
route 128.1.1.0/24 {
    next-hop 172.16.1.2;
    retain;
}

Применим filter:

root@mx240# show interfaces irb
unit 3 {
    family inet {
        filter {
            input isp1-static-subnets;
        }
        address 172.16.1.3/29;
    }
}

Все приготовления сделаны, теперь можно commit`ить конфигурацию и проверять её работу.
Посмотрим маршруты в созданной нами routing-instance isp1-static:

root@mx240> show route table isp1-static.inet.0
isp1-static.inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 1d 18:51:33
                    > to 10.0.0.1 via irb.800
....skiped....

Как мы можем видеть наш default в данной таблице присутствует и таким образом все пакеты с SRC-адресом из подсети 128.1.1.0/24 будут отправлены через интерфейс на ISP#1 10.0.0.1.

Ссылки

• Creating Routing Table Groups
• Configuring How Interface Routes Are Imported into Routing Tables
• Demystifying Juniper’s rib-groups
• Juniper PBR (сохраненная копия)

 

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

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