Когда астрофизик Эдвин Хаббл почти сто лет назад определил, что Вселенная равномерно расширяется во всех направлениях, это открытие стало настоящим сюрпризом. Потом, в середине 1990-х, выяснилась ещё одна неожиданная вещь: оказывается, Вселенная расширяется всё быстрее, то есть с ускорением. Причиной этого посчитали отталкивающие свойства вещества, названного «тёмной энергией».

Теперь c помощью космического телескопа Хаббла астрофизики НАСА определили, что Вселенная расширяется быстрее, чем ожидалось . Как трактовать это открытие, пока неясно, но постоянную Хаббла придётся пересмотреть.

«Это неожиданное открытие может оказаться важным ключом к пониманию того, что из себя представляет 95% массы Вселенной, которая не излучает свет, в том числе тёмная энергия, тёмная материя и тёмное излучение (dark radiation)», - пояснил ведущий автор исследования и нобелевский лауреат Адам Рисс (Adam Riess) из Института исследований космоса с помощью космического телескопа и университета Джонса Хопкинса.

Так называемое «тёмное излучение», о котором говорит нобелевский лауреат, - вероятно, одна из гипотетических форм тёмной энергии.

Учёные предлагают несколько объяснений происходящему. Возможно, тёмная энергия расталкивает галактики сильнее, чем ожидалось. Или ранний космос может содержать новый тип элементарных частиц, именуемых «тёмным излучением» (dark radiation), то есть в формулу расширения Вселенной после Большого взрыва следует добавить больше энергии от тёмной радиации.

Третий вариант - что тёмная материя, невидимая форма материи, которая составляет большую часть массы нашей Вселенной, обладает некими странными, неожиданными характеристиками. В конце концов, теория гравитации Эйнштейна может быть неполной.

Адам Рисс с коллегами разработали новую технику оценки скорости расширения Вселенной в 2005 году. Инновационная техника позволяет лучше определить расстояние до дальних галактик.

Метод состоит из трёх шагов, которые показаны на схеме. Он предусматривает поиск галактик со сверхновыми типа Ia и звёздами цефеидами. Цифеиды пульсируют в точной зависимости от своей инстинной светимости, что можно сравнить с их видимой светимостью для точной оценки расстояния. Сверхновые класса типа Ia, в свою очередь, образуются в результате взрывов белых карликов и достаточно ярки для наблюдения с относительно большого расстояния.

За десять лет учёные измерили примерно 2400 цефеид в 19 галактиках, оценили их видимую яркость, точно измерили истинную яркость и рассчитали расстояние примерно до 300 сверхновых типа Iа в дальних галактиках.

До настоящего времени наиболее надёжная оценка постоянной Хаббла составляла 67,80 ± 0,77 (км/с)/Мпк, то есть в современную эпоху две галактики, разделённые расстоянием в 1 мегапарсек, в среднем разлетаются со скоростью ~68 км/с.

Согласно новым измерениям, постоянная Хаббла составляет 73,2 (км/с)/Мпк, то есть две галактики, разделённые расстоянием в 1 мегапарсек, в среднем разлетаются со скоростью ~73 км/с.

Предложенный способ более точный, чем предыдущие методы: скорость расширения определяется с погрешностью 2,4%. Но даже с учётом этой погрешности новая постоянная Хаббла существенно больше, чем старая.

Результаты десятилетнего исследования будут опубликованы в ближайшем номере The Astrophysical Journal .

Расчёт истинного значения постоянной Хаббла - непростая задача. Например, анализ послесвечения от Большого взрыва, проведённый аппаратом Wilkinson Microwave Anisotropy Probe (WMAP) и результаты наблюдений спутниковой миссией Planck Европейского космического агентства дали противоположные результаты: по предсказанной траектории, скорость расширения Вселенной сейчас должна быть на 5% и 9% меньше, чем полученное значение постоянной Хаббла.

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

«Мы настолько мало знаем о тёмных частях Вселенной, что очень важно измерить, с какой силой они притягивались и отталкивались на протяжении космической истории», - сказал Лукас Макри (Lucas Macri), один из авторов научной работы.

До запуска телескопа Хаббла оценки скорости расширения Вселенной отличались на два порядка. Измерения в конце 1990-х помогли уменьшить погрешность до 10%. Сейчас учёные из группы Supernova H0 for the Equation of State (SH0ES) работают над новыми методами расчёта, которые снизят погрешность до 1%.

Время нужно только для того, чтобы всё не происходило одновременно.
- Альберт Эйнштейн

Вы можете решить заняться наблюдением за квазарами, поскольку это очень яркие объекты, которые хорошо видно на больших расстояниях . Однако окружение, в котором они находятся, и источники переменных характеристик (например, гравитационное микролинзирование), отличаются у удалённых и у более близких к нам квазаров.

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

У этих объектов очень хорошо изучена временная шкала, согласно которой они становятся ярче, затухают и исчезают.

Так что, если мы обнаружим удалённую сверхновую с сильным красным смещением, её световая кривая должна быть вытянутой по шкале времени. Что же происходит в реальности? Есть ли такие сверхновые?

Хотите – верьте, хотите – нет, но таких нашлось полно! Первая – сверхновая, удаляющаяся от нас со скоростью почти в 50% от скорости света – появилась в 1996 году ! Затем ещё одна , и ещё, и сегодня у нас их целая толпа , и мы однозначно видим замедление времени у этих далёких галактик!

Красная линия – предсказание без замедления, синяя – с замедлением. Так что это на самом деле происходит!

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

Так что, наблюдая за очень удалёнными объектами, вы не только видите их в прошлом, отдалённом на миллиарды лет, вы видите их в замедленном движении! И пока вы размышляете об этом, знайте, что некто в миллиардах световых лет от нас может видеть, как вы размышляете об этом гораздо дольше!

Failover — по русски это резервирование интернет-каналов, переключение в случае падения основного интернет-канала на резервный.

Итак у нас есть Микротик, к нему подключены 2 провайдера (ISP1 и ISP2), и ваша сеть, необходимо при падении основного интернет-канала автоматически переключиться на резервный.

1. Способ, failover делается маршрутами, все что вам надо сделать это прописать два маршрута один к ISP1 и второй к ISP2, выбрав в пункте «Check Gateway» ping или arp. По-моему для большинства случаев больше подойдет пинг. Таким же образом прописываете маршрут ко второму провайдеру. Мне удобнее всего настраивать микротик используя Winbox, маршруты прописываются в меню IP-Routes.

Если в Distance одному провайдеру прописать например 1 а второму 2, то микротик будет автоматически балансировать нагрузку, при полной загрузке первого провайдера новые запросы пойдут ко второму.

Этот способ имеет некоторые ограничения:

— Если один из провайдеров дает вам динамический IP и настройки приходят по DHCP, то вы не сможете прописать маршрут указав имя интерфейса, вам придется вписать в поле «Gateway» ip шлюза.
— Иногда бывают ситуации когда шлюз провайдера работает, а узлы за ним недоступны, Микротик будет считать маршрут рабочим, переключения не произойдет, и интернет работать не будет.

2-й Вариант Failover на Микротике лишенный недостатков первого способа.

В Микротик встроен Netwatch, (находится в меню Tools). Вкратце эта утилита позволяет пинговать какой-либо ip и выполнять команды если меняется доступность ip адреса, в Up — вписываем команды которые выполняются когда ip стал нова доступен, в Down соответственно вписываем команды которые надо выполнить когда ip стал недоступен.

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

Да, предварительно нужно задать комментарии для маршрутов. Мне удобнее всего настраивать Микротик через Winbox, для задания комментария маршруту заходим в IP-Routes, откроется окно со списком маршрутом, кружком обведена кнопка задания комментария, выделяем нужный маршрут, жмем на кнопку, вписываем комментарий для маршрута, жмем ок.

На картинке видно работу скрипта, маршрут к провайдеру ISP2 (У меня это Utel) не активен, он серого цвета, а маршрут к ISP1 (у меня Stels) активен. Ниже можно увидеть маршрут с комментарием Stels88, это нужно чтоб пинги к 8.8.4.4 который мы используем в скриптах шли только с ISP1, это нужно для контроля работоспособности ISP1, пинги идут -все впорядке, если ответов на пинги нет, то надо переключаться на ISP2. Как это делается видно на картинке ниже:

В раздел UP пишем:

/ip route set disabled=no
/ip route set disabled=yes

В раздел Down пишем:

/ip route set disabled=yes
/ip route set disabled=no

Для того чтоб схема корректно работало, нужно разрешить пинговать этот ip только с ISP1, для этого желательно добавить правило в IP-Firewall запрещающее доступ к 8.8.4.4 с ISP2, и прописать статический маршрут к 8.8.4.4 через шлюз ISP1 (в штатном режиме так сделать не получится если ISP1 выдает динамический ip и придется писать скрипт, который будет определять ip шлюза и прописывать маршрут).

Спонсор статьи:

Самоучитель по MikroTik – теория и практика в видеоформате.

По видеокурсу « » вы научитесь настраивать маршрутизатор с нуля для целей небольшого офиса. В основе курса лежит официальная программа MikroTik Certified Network Associate, но она значительно расширена, особенно в части закрепления знаний на практике. В курс входит 162 видеоурока и 45 лабораторных работ, объединенных в техническое задание. Если что-то непонятно, то можно задавать вопросы автору курса. Первые 25 уроков можно посмотреть бесплатно, форма заказа есть на

> Резервирование каналов на Mikrotik без скриптов

Mikrotik. Failover. Load Balancing

Когда у меня встала необходимость разобраться, как сделать failover или load balancing, имея два и более каналов в мир, я нашел множество статей и инструкций, в которых описывались рабочие конфигурации. Но почти нигде не нашел разъяснения, как все работает, и описания отличий разных вариантов. Хочу исправить эту несправедливость и собрать простейшие варианты построения failover и load balancing конфигураций в одной статье.

Итак, у нас есть роутер, который соединяет нашу локальную сеть и два канала в интернет (основной ISP1 и резервный ISP2).

Давайте рассмотрим что же мы можем сделать:

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

Простейшее резервирование каналов

Простейший failover можно настроить, используя приоритет маршрута (distance у mikrotik/cisco, metric в linux/windows), а так же механизм проверки доступности шлюза - check-gateway.

В приведенной ниже конфигурации весь интернет трафик по умолчанию ходит через 10.100.1.254 (ISP1). Но как только адрес 10.100.1.254 станет недоступным (а маршрут через него неактивным) - трафик пойдет через 10.200.1.254 (ISP2).

конфигурация: простейший failover

# Настроим сети провайдеров:





###Обеспечение резервирования каналов традиционным способом###
# укажем 2 default gateway с разными приоритетами
/ip route add dst-address=0.0.0.0/0 gateway=10.100.1.254 distance=1 check-gateway=ping
/ip route add dst-address=0.0.0.0/0 gateway=10.200.1.254 distance=2 check-gateway=ping

Check-gateway=ping для mikrotik обрабатывается так:
Периодически (каждые 10 секунд) шлюз проверяется отсылкой на него ICMP пакета (ping). Потерянным пакет считается, если он не вернулся в течении 10 секунд. После двух потерянных пакетов шлюз считается недоступным. После получения ответа от шлюза он становится доступным и счетчик потерянных пакетов сбрасывается.

Обеспечение failover с более глубоким анализом канала.

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

Я знаю два варианта решения этой инженерной задачи. Первый и самый распространенный - использовать скрипты, но так как в этой статье мы скрипты не трогаем, остановимся подробнее на втором. Он подразумевает не совсем корректное использование параметра scope, но поможет нам прощупать канал провайдера глубже, чем до шлюза.
Принцип прост:
Вместо традиционного указания default gateway=шлюз провайдера, мы скажем роутеру что default gateway это какой-то из всегда_доступных_узлов (например 8.8.8.8 или 8.8.4.4) и он в свою очередь доступен через шлюз провайдера.

конфигурация: failover с более глубоким анализом канала

# Настроим сети провайдеров:
/ip address add address=10.100.1.1/24 interface=ISP1
/ip address add address=10.200.1.1/24 interface=ISP2
# Настроим локальный интерфейс
/ip address add address=10.1.1.1/24 interface=LAN
# скроем за NAT все что выходит из локальной сети
/ip firewall nat add src-address=10.1.1.0/24 action=masquerade chain=srcnat
###Обеспечение failover c более глубоким анализом канала###
#с помощью параметра scope укажем рекурсивные пути к узлам 8.8.8.8 и 8.8.4.4
/ip route add dst-address=8.8.8.8 gateway=10.100.1.254 scope=10
/ip route add dst-address=8.8.4.4 gateway=10.200.1.254 scope=10
# укажем 2 default gateway через узлы путь к которым указан рекурсивно
/ip route add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=1 check-gateway=ping
/ip route add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 check-gateway=ping

Теперь разберем, что происходит чуть подробнее:
Хитрость в том, что шлюз провайдера не знает о том, что 8.8.8.8 или 8.8.4.4 - это роутер и направит трафик по обычному пути.
Наш mikrotik считает, что по умолчанию весь интернет трафик нужно отправлять на 8.8.8.8, который напрямую не виден, но через 10.100.1.254 доступен. А если пинг на 8.8.8.8 пропадает (напомню что путь к нему у нас жестко указан через шлюз от ISP1) то mikrotik начнет слать весь интернет трафик на 8.8.4.4, а точнее на рекурсивно определенный 10.200.1.254 (ISP2).

Д оброе время суток. Замарочился я на днях организацией отказоустойчивости своего CCR1036-8G-2S+. Перелопатил много материала в интернете, но большинство из них мне не подходило. И тут я наткнулся на полезную которая целиком и полностью подходит для решения моих задач. Изложенная ниже настройка 100% рабочий вариант.

Мы уже рассматривали вариант подключения двух провайдеров Интернет к одному маршрутизатору, под управлением операционной системы Mikrotik RouterOS . Однако, это был самый простой вариант. Который не всегда может подойти в тех или иных условиях. Поэтому сегодня, мы возьмем ряд конкретных примеров настройки маршрутизатора с условием подключения к двум провайдерам, и более подробно остановимся на некоторых нюансах настройки Firewall, NAT, маршрутизации и балансировки нагрузки или использования второго канала в качестве резервного.

И так как дальнейший рассказ будет с конкретными примерами, то и начнем его с конкретных условий. У нас есть 2 провайдера. Связь с обоими устанавливается посредством протокола PPPoE. Как настроить соединение с провайдером, подробно описано в этой статье, поэтому этот процесс мы пропустим. Обозначив лишь то, что провайдер №1 у нас подключен к порту Ether1, и имя его PPPoE подключения - ISP1. Провайдер №2, подключен к порту Ether2 и имеет имя PPPoE подключения - ISP2.

Единственный момент, это то, что мы в дальнейшем, будем самостоятельно создавать правила маршрутизации, поэтому при создании подключений к провайдерам, необходимо убрать галочку с пункта Add Default Route на вкладке Dial Out для PPPoE соединения.

NAT

Чтобы наша сеть правильно работала и имела доступ в интернет, нам необходимо настроить NAT. Для этого открываем раздел IP -> Firewall, переходим на вкладку NAT и кнопкой “+”, добавляем новое правило.

На вкладке General, цепучку Chain выбираем scrnat. Значение поля Out. Interface, в данном случае, мы оставляем не заполненным, так как у нас два провайдера, и соответственно 2 разных интерфейса.

Затем на вкладке Action, в качестве параметра для поля Action, ставим значение masquerade.

Сохраняем правило кнопкой OK. Настройку NAT, можно считать законченной.

Firewall

Следующий наш шаг, это настройка функции Firewall, которая призвана защитить нашу локальную сеть.

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

Если у вас есть в этом разделе какие либо правила, то их следует сперва удалить.

Новые правила, можно добавлять нажатием кнопки “+”, после чего, например для правила разрешающего ping - chain=input protocol=icmp action=accept, на вкладке General, мы выбираем цепочку Chain - input, а протокол Protocol - icmp.

После чего, на вкладке Action, в качестве параметра для поля Action, выбираем acept.

Это действие, необходимо повторить порядка 14 раз, для четырнадцати разных правил.
Разрешаем Ping

chain=input protocol=icmp action=accept

chain=forward protocol=icmp action=accept

Разрешаем установленные соединения

chain=input connection-state=established action=accept

chain=forward connection-state=established action=accept

Разрешаем родственные соединени я

chain=input connection-state=related action=accept

chain=forward connection-state=related action=accept

Запрещаем не удачные соединения

Chain=input connection-state=invalid action=drop

chain=forward connection-state=invalid action=drop

Разрешаем соединения по протоколу UDP

chain=input protocol=udp action=accept

chain=forward protocol=udp action=accept

Открываем доступ в Интернет для нашей локальной сети. Для тех, у кого префикс локальной сети, отличается от 192.168.0.0/24, поставить вместо этого, свои адрес.

chain=forward src-address=192.168.0.0/24 action=accept

Разрешаем доступ к роутеру, только из локальной сети, как и выше - 192.168.0.0/24 стоит заменить своим адресом.

chain=input src-address=192.168.0.0/24 action=accept

И в конце, запрещаем все остальное

chain=input action=drop

chain=forward action=drop

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

ip firewall filter add chain=input protocol=icmp action=accept

ip firewall filter add chain=forward protocol=icmp action=accept

ip firewall filter add chain=input connection-state=established action=accept

ip firewall filter add chain=forward connection-state=established action=accept

ip firewall filter add chain=input connection-state=related action=accept

ip firewall filter add chain=forward connection-state=related action=accept

ip firewall filter add chain=input connection-state=invalid action=drop

ip firewall filter add chain=forward connection-state=invalid action=drop

ip firewall filter add chain=input protocol=udp action=accept

ip firewall filter add chain=forward protocol=udp action=accept

ip firewall filter add chain=forward src-address=192.168.0.0/24 action=accept

ip firewall filter add chain=input src-address=192.168.0.0/24 action=accept

ip firewall filter add chain=input action=drop

ip firewall filter add chain=forward action=drop

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

Routing
Последним, но одним из самых важных действий, осталось создание маршрутов. Начнем с того, что пометим наши соединения с провайдером. Это необходимо для того, чтобы все пришедшие на интерфейс того или иного провайдера запросы, уходили именно на его интерфейс. Это довольно критично в том случае, если у нас за NAT, есть какие либо ресурсы, к которым необходимо обеспечить доступ из глобальной сети Интернет. Например web-сервер или почтовый сервер и т.д. О том как организовать работу таких сервисов, мы уже рассматривали в статье Расширенные настройки Mikrotik RouterOS : перенаправление портов - dstna t.

Для этого, нам необходимо создать два отдельных правила, для каждого провайдера в разделе IP -> Firewall на вкладке Mangle.

На вкладке General, выбираем цепочку Chain как forward, а в качестве In.Interface выбираем интерфейс PPPoE подключения первого провайдера ISP1.

А на вкладке Action, в качестве параметра Action, выбираем mark connection и в появившемся ниже поле New Connection Mark, вписываем имя метки для этого соединения, например ISP1-con.

То же самое, повторяем для второго провайдера. Только в качестве In.Interface выбираем ISP2, а в поле New Connection Mark, вписываем метку для второго соединения ISP2-con.

Теперь, чтобы отправить ответ на пришедший запрос через интерфейс того же провайдера, нам необходимо создать еще 2 правила, которые будут помечать маршруты.

Здесь же, создаем новое правило в котором в качестве цепочки Chain, выбираем значение prerouting, в поле Scr.Address вписываем префикс нашей локальной сети 192.168.0.0/24, а Cjnnection Mark выбираем метку соединения нашего первого провайдера ISP1-con.

Переходим на вкладку Action и в поле Action, выбираем mark routing, а в появившемся ниже поле New Routing Mark, присваиваем метку для маршрута этого провайдера, например ISP1-rt.

Точно такое же привило, создаем и для второго соединения. Только, соответственно, в качестве Connection Mark выбираем ISP2-con, а в качестве New Routing Mark, вписываем ISP2-rt.

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

Например у провайдера №2 - ISP2 есть локальные ресурсы имеющие диапазон адресов 181.132.84.0/22. А через провайдера №1, пинг к игровым серверам онлайн игр, гораздо меньше. И мы знаем что IP адреса этих серверов 90.231.6.37 и 142.0.93.168.

Переходим на вкладку Address Lists раздела IP -> Firewall. И по одному добавляем эти IP адреса или подсети целиком, с именами to-ISP1 или to-ISP2, в зависимости от того, через какого провайдера должно быть обращение к этим ресурсам.

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

А на вкладке Action, Action - mark routing, New Routing Mark - ISP1-rt.

Повторяем тоже самое, для списка адресов второго провайдера. Но соответственно в качестве Dst.Address List, указываем список адресов для второго провайдера to-ISP2. А в качестве метки для маршрута New Routing Mark - ISP2-rt.

И приступаем к самой основной части настройки маршрутизации - созданию статических правил маршрутизации в разделе IP -> Routes.

Если каналы наших обоих провайдеров, практически равны, то добавляем вот такой маршрут: но вкладке General, окна создания маршрута, для Dst.Address пишем 0.0.0.0/0, а в качестве Getway выбираем интерфейсы наших провайдеров ISP1 и ISP2. Все остальные параметры, оставляем без изменений.

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

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

Первый Dst.Address - 0.0.0.0/0, Gateway - ISP1.

А второй Dst.Address - 0.0.0.0/0, Gateway - ISP2, Distance - 2.

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

Первый будет иметь Dst.Address - 0.0.0.0/0, Gateway - ISP1, Routing Mark - ISP1-rt, а второй, соответственно Dst.Address - 0.0.0.0/0, Gateway - ISP2, Routing Mark - ISP2-rt

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