Megas

оу, сори. можете перенести тему?

Не много запутался в приготовлении бутерброда. Есть микротик в качестве default gw для группы хостов. Есть также PC глубоко в интернете. Между этими двумя железками подняты 2 тунеля с разными приоритетами, со стороны PC через quagga ospf анонсируется роут 192.168.50.254/32 который брибит к lo0 на PC. То есть, если мы с микротика пинганем 192.168.50.254 пинг успешно пройдет. Теперь стоит задача сделать 192.168.50.254 шлюзом для выхода в мир некоторых хостов внутри сети которую рулит микротик. Вот тут как раз не совсем понимаю как это реализовается. На Linux мне было достаточно создать новую таблицу, в неё запихнуть default route и с помощью ip rule lovehost table newtable и трафик уходил по новому маршруту. А вот как правильно развернуть на микроте такой изврат?

tap0 is up ifindex 1612, MTU 1420 bytes, BW 0 Kbit <UP,BROADCAST,RUNNING,MULTICAST> Internet Address 10.91.0.1/24, Broadcast 10.91.0.255, Area 0.0.0.0 MTU mismatch detection:enabled Router ID EXT_IP, Network Type BROADCAST, Cost: 50 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) EXT_IP, Interface Address 10.91.0.1 Backup Designated Router (ID) 192.168.7.251, Interface Address 10.91.0.2 Saved Network-LSA sequence number 0x8000001c Multicast group memberships: OSPFAllRouters OSPFDesignatedRouters Timer intervals configured, Hello 4s, Dead 8s, Wait 8s, Retransmit 4 Hello due in 2.978s Neighbor Count is 1, Adjacent neighbor count is 1

Сейчас смотрю, роутер почему-то находится в backup, поднят всего один peer. cs(config-router)# do sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL 192.168.7.251 10 Full/Backup 7.734s 10.91.0.2 tap0:10.91.0.1 0 0 0 cs(config-router)# Не могу понять почему он в backup находится.

Да, mtu уже выровнял. Переключил на tap и все завелось. Но как-то все время использовал для point to point связку через static.key, но вот микротик похоже не умеет такое. Ну конечно отдельная тема что меняется c L3 на L2 тунели. Интересно как народ строит такие связки.

Может кто сможет подсказать, чуть скатился в сторону от сетей и не могу с первого подхода запустить. Есть сервер с OpenVPN, local port 8091 proto tcp-server dev tun8091 tun-mtu 1420 mssfix 1420 ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key dh /etc/openvpn/keys/dh2048.pem server 10.91.0.0 255.255.255.0 mode server client-config-dir ccd client-to-client keepalive 5 15 cipher AES-256-CBC # AES max-clients 100 user nobody group nogroup persist-key persist-tun log-append /var/log/openvpn/server.log verb 0 auth SHA1 На Mikrotik поднял клиента openvpn, подключено, все пингается. Дальше хочу завести ospf. На сервере где стоит openvpn server уже была quagga, просто добавил router ospf ospf router-id 192.168.99.1 redistribute connected route-map dst-nets network 10.91.0.0/24 area 0.0.0.0 neighbor 10.91.0.6 Вот выхлоп tcpdump: tcpdump -nei tun8091 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun8091, link-type RAW (Raw IP), capture size 65535 bytes 02:13:07.103529 ip: 10.91.0.1 > 224.0.0.5: OSPFv2, Hello, length 44 02:13:13.409409 ip: 10.91.0.6 > 224.0.0.5: OSPFv2, Hello, length 44 02:13:17.104381 ip: 10.91.0.1 > 224.0.0.5: OSPFv2, Hello, length 44 02:13:22.022899 ip: 10.91.0.6.47432 > 255.255.255.255.5678: UDP, length 109 02:13:23.411681 ip: 10.91.0.6 > 224.0.0.5: OSPFv2, Hello, length 44 02:13:27.104485 ip: 10.91.0.1 > 224.0.0.5: OSPFv2, Hello, length 44 Вот не пойму чего ему не хватает чтобы установить отношения.

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

Да просто возьмите подпись у всех кто засветится на ваших камерах, о том что они не против.

Да оО, клиент не обязан платить за не предоставленные услуги)

sla прописан? если sla нарушен, проблемы провайдера.

Из практики: когда у вас 20 аплинков и 30 сетей, вы можете менять анонсы сетей местами и принимать трафик на разные аплинки. Есть ситуации когда blackhole не возможен в простом варианте... увы такая политика. От сюда вариант только один, жонглирование входящим трафиком и вот тут как раз чем мельче побиты ваши сети и чем больше у вас аплинков, тем лучше вам жить.

https://habrahabr.ru/company/cbs/blog/276863/ -- Администрирование → ARP: Нюансы работы оборудования Cisco и интересные случаи. Часть 1 https://habrahabr.ru/company/cbs/blog/277251/ --- Администрирование → ARP: Нюансы работы оборудования Cisco и интересные случаи. Часть 2

Да, dnsdist оказался интересным, по показателям дает 800-1000 запросов в той же конфигурации, сейчас хочу наплодить docker с unbound и посмотреть по другому.

Народ, а может кто-то юзал такую связку: nginx в качестве балансировщика запросов, он кидает запросы на 3и сервера каждый из которых в контейнере unbound. При тестировании unbound напрямую дает порядка 400 запросов в секунду через dnsperf. Nginx запущен в однопоточном режиме, дает при тестах 450 запросов, запросы разливаются по всем 3ом серверам. Поднятие nginx до 8 потоков выдало всего 650 запросов и увы оказалось потолком, но при этом ресурсы сервера вполне свободные. Может кто может направить, как бы отловить узкое место в данной конфигурации или может кто-то пробовал у себя такую связку? Она выглядит более приятно чем отдельный процесс dns который может упасть или затупить.

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

Собственно сам того не ожидая столкнулся с очень интересной особенностью. Имеется managment сеть к примеру с пространством 192.168.0.0/16, все адреса находится в выделеном влане. Случайно прописал вот такую запись в /etc/network/interface на одном из серверов: auto lo:0 iface lo:0 inet static address 192.168.10.1 Вроде бы ничего такого, привязали к левый ип к loopback, ifconfig: lo:0 Link encap:Local Loopback inet addr:192.168.10.1 Mask:255.255.255.255 UP LOOPBACK RUNNING MTU:65536 Metric:1 Сервер подключен в центральный коммутатор 2мя шнурками в lacp и tagged прокинуто 2 влана: auto eth2 iface eth2 inet manual bond-master bond0 auto eth3 iface eth3 inet manual bond-master bond0 auto bond0 iface bond0 inet manual bond-mode 802.3ad bond-miimon 100 bond-downdelay 200 bond-updelay 200 bond-lacp-rate 1 bond-slaves none auto br20 iface br20 inet manual bridge_ports bond0.20 bridge_stp off bridge_maxwait 0 auto br30 iface br30 inet manual bridge_ports bond0.30 bridge_stp off bridge_maxwait 0 Перезагружаем все это дело у вуаля, весь managment на свичах валяется в хлам, часть коммутаторов весело рапортует: Aug 24 23:01:38 SW-3 /kernel: KERN_ARP_DUPLICATE_ADDR: duplicate IP address 192.168.8.81! sent from address: 00:25:90:a5:4d:ac (error count = 707) Aug 24 23:02:43 SW-3 /kernel: KERN_ARP_DUPLICATE_ADDR: duplicate IP address 192.168.8.81! sent from address: 00:25:90:a5:4d:ac (error count = 712) Aug 24 23:03:48 SW-3 /kernel: KERN_ARP_DUPLICATE_ADDR: duplicate IP address 192.168.8.81! sent from address: 00:25:90:a5:4d:ac (error count = 727) Таким образом получается, что мак адрес Lag интерфейса моего сервера устроил конфликт со многими mgmt интерфейсами коммутаторов сети, и это при том что адрес на сервере был указан на loopback интерфейсе, для меня выглядит как полный бред.. ОС Debian 8 Jessie.

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

NiTr0 , спасибо, но ситуация уже чуть проясняется, если передернуть bird то он нормально видит 2 default route: # birdc show route BIRD 1.6.0 ready. 0.0.0.0/0 via 192.168.8.250 on eth0 [rip1 2016-08-17 21:34:01] * (120/3) via 111.11.33.1 on eth3 [kernel1 2016-08-17 21:36:25] (10) 111.11.33.0/24 dev eth3 [direct1 2016-08-17 21:36:24] * (240) 192.168.8.0/24 dev eth0 [direct1 2016-08-17 21:34:01] * (240) но увы, после того как опустишь и поднимеш eth3, ситуация становится такой: birdc show route BIRD 1.6.0 ready. 0.0.0.0/0 via 192.168.8.250 on eth0 [rip1 2016-08-17 21:34:02] * (120/3) 111.11.33.0/24 dev eth3 [direct1 2016-08-17 21:37:57] * (240) 192.168.8.0/24 dev eth0 [direct1 2016-08-17 21:34:02] * (240) он не хочет изучать default из dhcp в системе.

Версия: ii bird 1.6.0-1 amd64 Internet Routing Daemon Моя проблема в том что птица ничего не знает о eth3 и 1G интерфейсе и все что на нем приходит, соотвественно она не знает что есть второй гейт и у его должна быть другая метрика. и как её решить не понятно. Пробовал отталкиваться от: https://habrahabr.ru/post/199478/ но там везде статика.

Добрый день всем. Раньше для резервирования домашнего интернета использовал quagga, которая долго трудилась и справлялась со своими задачами, но вот решил попробовать bird чтобы начать потихоньку его изучать и впоследствии применять в работе. Есть 2 домашних провайдера, 1 отдает внешний канал по Ethernet 1G через dhcp, другой обычный adsl, adsl роутер вещает свой default gw через rip2, меня такой порядок полностью устраивал. Quagga выглядела так: log stdout ! interface eth0 ipv6 nd suppress-ra ! interface eth1 ipv6 nd suppress-ra ! interface eth2 ipv6 nd suppress-ra ! interface lo ! interface tun0 ipv6 nd suppress-ra ! interface tun11 ipv6 nd suppress-ra ! router rip version 2 redistribute connected network 192.168.8.0/24 ! ip forwarding ! line vty ! Bird настроен пока так: timeformat base iso long; timeformat log iso long; timeformat protocol iso long; timeformat route iso long; log "/var/log/bird/bird.log" all; log stderr all; router id 192.168.7.254; protocol kernel { scan time 20; import none; export all; # Actually insert routes into the kernel routing table } protocol direct { interface "eth0", "eth3"; } protocol device { scan time 20; } debug protocols { routes, interfaces }; protocol rip { debug all; interface "eth0" { metric 2; mode multicast; }; import filter { print "importing"; accept; }; export filter { print "exporting"; accept; }; } В данной ситуации в системе видно что роут от adsl приходит на bird, когда выключает 1G eth0, то новый default gw на adsl прилетает становится через несколько секунд, но проблема в том что когда включаешь назад 1G c dhcp, то вот тут адрес на интерфейсе появляется, но вот роут не меняется. На сколько понимаю в голове, то bird должен получать информацию о всех маршрутах в системе и держать оба default gw в своей таблице машрутизации как это делала quagga чтобы в случае падение первого спокойно включать второй и возращать назад. Помогите правильно описать bird чтобы он случае и использовал роуты от eth3

Очень часто получаем: # fastnetmon ^CAssertion failed: (!posix::pthread_mutex_destroy(&m)), function ~mutex, file /usr/local/include/boost/thread/pthread/mutex.hpp, line 108. Abort (core dumped) root@netmon01:~ # после длительной работы

Мы столкнулись с рядом проблем при использовании glusterfs в качестве сторежджа для vm в proxmox, очень часто виртуалки не поднимались или глючи, как только меняешь сторедж сразу все становится нормально. Я помню момент когда gluster не поддерживался kvm, это было года 2 назад, потом появилась поддержка, но проблемы явно сохранились. По этому использовать glusterfs как сторедж не рекомендую, но может у кого-то есть другой опыт. Впечатления от ceph двоякие, как уже сказал были и взлеты и падения, благо на ssd дисках бэкап клиентских виртуалок пролетает за 12 часов на внешние стореджы и после этого сплю спокойно. Даже если ceph крякнется, просто переразверну виртуалки. Но, мы вывели форумулу для себя при которой у нас оптимальное количество OSD и нод, выше головы прыгать нет желания, по этому как только заполнили кластер, то строим просто другой. Примеров инсталяции ceph очень много, просто вы в них не вникали, но и проблем много, никто не готов тратится на InfiniBand и большие толстые хранилища. tokra правильно описал проблемы и требования. 10г это минимум что надо, потом обязательно точное время, лучше несколько штук, мы сейчас городим на базе gps датчиков 2 сервера точного времени в кластера, не хотим больше не от кого зависеть кроме воздуха. Что касается дисков, то при использовании sata или sas в больших обьемах их все же лучше подключать через raid контроллеры, тогда если сдохнет диск это будет больше контроллера, а не всего ceph кластера. Понятно что можно перекрутить кучу параметров, приоритетов, но по опыту скажу, в задницу, osd на raid через аппаратный контроллер, конфигурации raid по желанию, хоть 0, хоть 10, остальные конфигурации бесмысленны. Но прежде чем строить системы такого плана, ответьте себе на вопрос, какая у вас будет нагрузка, сколько iops вы хотите получить и сможете ли выделить 10г минимум сеточку, ибо на 1Г конечно можно, но не приятно до ужаса при объеме. Думал писал, похоже нет. Текущие показатели внутри виртуалки выглядят примерно как 120-200тыс iops на чтение, и порядка 15тыс iops на запись, порядка 800мегабайт чтение с диска виртуального на rdb пуле и порядка 300 на запись. Увы, ceph, ssd не любят линейные данные, только качественный random. SSD по 800гб сейчас порядка 15шт, планирую увеличить до 18шт. К сожалению пределы системы пока не поймал, но текущего хватает выше крыши, бэкапы главное идут без всяких тормозов, негатива от клиентов в сторону ceph и производительности не было еще, в отличии от внешнего хранилища и iscsi.

Являюсь тем кто построил и сапортит в данный момент 2 кластера и кучу разностных серверов, все на базе proxmox, сейчас over 500 клиентов которые приобретают услугу. К сожалению добиться качества получилось только используя ceph + intel ssd 800gb. Старое железо в том что числе схд на sas и ssd дисках где отдача идет по iscsi выдает такое количество проблем, что трудно представить. Вся проблема в том что до 100 клиентских VM проблем в обще нету, как только вы переходите эту цифру начинаются стуки. Для автора могу сказать такое: lsi контроллер локально, какой-то supermicro на 8 hotswap + 2 глухих кармана. Ставите туда 8 дисков sata обычных и делаете большой и толстый массив на базе контроллера. Для 20VM этого выше крыши. Если вам надо производительность, берете 2й сервер и вкидываете туда SSD, распределяете VM между этими двумя серверами и спитите спокойно. При желании берете 3й обычный сервак, без выпендрежа, вставляете пару дисков, поднимаете glusterfs на нем и отдаете на обе ноды где у вас VM, тем самым вы легко с простоем в пару секунд (время на перезапуск VM ) сможете мигрировать виртуалки между нодами. С помощью gluster миграция выглядит так: запускаем онлайн смену места хранения образа. после окончания миграции тушим VM на первой ноде. копируем конфиг VM на второу ноду. запускаем там эту VM мигрируем диск с glusterfs на основной storage. Все... простой только на выкл, вкл. Не надо городить кластера там где они не нужны, разбивайте машины между двумя независимыми нодами с различной производительностью дисковой подсистемы. Используйте локальное хранение работающих виртуальных дисков на аппаратных raid массивах. Создайте план по backup каждую ночь на выделенный сервер с glusterfs и спите спокойно.

Тариф Яровой, безлимитное прослушивание включено.

Подскажите плиз. Хостеры тоже в заднице?