Comments 14
Почту отправляю через учетку заведенную на Яндексе. Письма отправляю на gmail. C отображение кодировок проблем нет. Единственный момент, это некорректное отображение при чтении письма с gmail через почтовый клиент HTC Sense.
Через клиент gmail все отображение корректно.
Через клиент gmail все отображение корректно.
Очень обстоятельно вы подошли к статье…
1) Но зачем Вам нужен l2-сегмент с отсутствующими преимуществами l2? Может лучше просто в gre или ipip запихнуть? Это такой стандартный костыль, который уже давно не костыль т.к помогает отслеживать состояние соединения с удалённым офисом.
2) Проблемы с OSPF(если они действительно есть в нынешних версиях, т.к. за последние 3 года их не встречал) в Вашем случае неважны, т.к. у Вас должна быть одна Area и в принципе пофиг на авторизацию в тунельных интерфейсах.
3) OSPF на этих объёмах Вам бы ничего не сократил, т.к. без нетвоча и скриптов он нормально не работает, т.к. ориентируется только на физическое состояние линка, а не на доступность адресов. Но OSPF всё-равно более правильный вариант решения этой проблемы — понять это можно только попробовав и вникнув.
1) Но зачем Вам нужен l2-сегмент с отсутствующими преимуществами l2? Может лучше просто в gre или ipip запихнуть? Это такой стандартный костыль, который уже давно не костыль т.к помогает отслеживать состояние соединения с удалённым офисом.
2) Проблемы с OSPF(если они действительно есть в нынешних версиях, т.к. за последние 3 года их не встречал) в Вашем случае неважны, т.к. у Вас должна быть одна Area и в принципе пофиг на авторизацию в тунельных интерфейсах.
3) OSPF на этих объёмах Вам бы ничего не сократил, т.к. без нетвоча и скриптов он нормально не работает, т.к. ориентируется только на физическое состояние линка, а не на доступность адресов. Но OSPF всё-равно более правильный вариант решения этой проблемы — понять это можно только попробовав и вникнув.
Спасибо за проявленный интерес к статье.
1. Что именно Вы имеете ввиду под l2-сегментом? То, что дает провайдер? Или то, что для маршрутизации между магазинами я использую прямой l2-сегмент и роутинг идет напрямую на IP-адреса интерфейсов без внутренних туннелей?
У меня были мысли, создать внутренние туннели. Действительно, тогда было бы удобнее отслеживать падение магазинов. Так-же, это помогло бы решить проблему с непроходимостью OSPF. Но, мне не хотелось делать лишние инкапсуляции при передачи данных между магазинам по основным каналам. Поэтому, я решил отказаться от внутреннего туннелирования. Да и отследить проблему падения магазина помогает скрипт в магазине, на случай если он отвалится. В случае, если отвалится один из приходящих каналов от ISP-1 в офисе, то соответственно отвалится один из каналов в интернет (идущих через ISP-1). В таком случае, письмо с уведомлением о падении интернет канала придет из главного офиса. Магазины в таком случае, будут молча работать через второй внутренний канал от ISP-1.
Плюс в таблице маршрутизации линки, которые не работают будут с АД равным = 110,120,130 соответственно от рабочих 10,20,30.
По пунктам 2 и 3. Я полностью с Вами согласен насчет того, что через OSPF было бы правильнее. Но, так как, мне еще нужно было брать интернет в магазинах из центрального офиса (от ISP-1), то я остановился на статической маршрутизации и только скриптах.
Но, хочу сказать, что в данном проекте я все равно поднял OSPF, но использую ее не для связи между магазинами, а для другой цели, о чем кратко упомянул в статье:
Так-же, думаю описать в статье свои изменения в скрипте пользователя magnitudo. Который я использую и в магазинах, и в центральном офисе. Может, кому-то будет интересно и пригодится.
1. Что именно Вы имеете ввиду под l2-сегментом? То, что дает провайдер? Или то, что для маршрутизации между магазинами я использую прямой l2-сегмент и роутинг идет напрямую на IP-адреса интерфейсов без внутренних туннелей?
У меня были мысли, создать внутренние туннели. Действительно, тогда было бы удобнее отслеживать падение магазинов. Так-же, это помогло бы решить проблему с непроходимостью OSPF. Но, мне не хотелось делать лишние инкапсуляции при передачи данных между магазинам по основным каналам. Поэтому, я решил отказаться от внутреннего туннелирования. Да и отследить проблему падения магазина помогает скрипт в магазине, на случай если он отвалится. В случае, если отвалится один из приходящих каналов от ISP-1 в офисе, то соответственно отвалится один из каналов в интернет (идущих через ISP-1). В таком случае, письмо с уведомлением о падении интернет канала придет из главного офиса. Магазины в таком случае, будут молча работать через второй внутренний канал от ISP-1.
Плюс в таблице маршрутизации линки, которые не работают будут с АД равным = 110,120,130 соответственно от рабочих 10,20,30.
По пунктам 2 и 3. Я полностью с Вами согласен насчет того, что через OSPF было бы правильнее. Но, так как, мне еще нужно было брать интернет в магазинах из центрального офиса (от ISP-1), то я остановился на статической маршрутизации и только скриптах.
т.к. без нетвоча и скриптов он нормально не работает, т.к. ориентируется только на физическое состояние линка, а не на доступность адресовА вот это было решающим.
Но, хочу сказать, что в данном проекте я все равно поднял OSPF, но использую ее не для связи между магазинами, а для другой цели, о чем кратко упомянул в статье:
Как я ловил Wi-Fi принтер, гуляющий по магазинам через OSPF.Хочу посвятить этой теме отдельную небольшую статью в будущем.
Так-же, думаю описать в статье свои изменения в скрипте пользователя magnitudo. Который я использую и в магазинах, и в центральном офисе. Может, кому-то будет интересно и пригодится.
Можно было запускать пинги параллельно в разных скриптах по расписанию и передавать результат по каждому пингу в глобальную переменную.
Или еще десяток секунд можно сократить, храня в памяти результаты 7 последних пингов.
Скрипт, запускаемый раз в секунду, будет пинговать лишь 1 раз, класть результат в глобальную переменную, при этом сдвигая прошлые результаты назад. Ну обычная такая очередь.
А скрипт с логикой, который теперь тоже можно раз в секунду запускать, будет просто смотреть на результаты последних 7 пингов, а не пинговать каждый раз по 7 раз.
Время реакции наверное до 2-4 секунд уменьшится.
Скрипт, запускаемый раз в секунду, будет пинговать лишь 1 раз, класть результат в глобальную переменную, при этом сдвигая прошлые результаты назад. Ну обычная такая очередь.
А скрипт с логикой, который теперь тоже можно раз в секунду запускать, будет просто смотреть на результаты последних 7 пингов, а не пинговать каждый раз по 7 раз.
Время реакции наверное до 2-4 секунд уменьшится.
Спасибо за интерес к статье.
Мне как раз таки не хотелось, чтобы на роутере запускалось много скриптов с низким интервалом. Так-же не очень хотелось создавать много переменных. Если я правильно понял Вас, то по-идее, для каждого магазина будем хранить в памяти 7 результатов последних пингов, а для 12 магазинов это 84 переменные. Мне кажется — многовато.
Собственно, для заказчика сейчас идеальное время реакции… И наиболее важно в отличии от обычного OSPF, что именно тестируется качество канала связи.
Чуть позже, я думаю, напишу статью о том, как именно поставляется и резервируется сам интернет, а не связь между магазинами. Там, я как раз использую глобальные переменные, но немного для других целей.
Получается, что у меня 3 канала в интернет. Хотя из трех каналов, по факту, два от одного провайдера, с одинаковым выходом с мир (от провайдера) и политикой нарезки скорости. Но, для клиента, эти 2 канала абослютно независимы друг от друга физически. Балансировки нет.
Мне как раз таки не хотелось, чтобы на роутере запускалось много скриптов с низким интервалом. Так-же не очень хотелось создавать много переменных. Если я правильно понял Вас, то по-идее, для каждого магазина будем хранить в памяти 7 результатов последних пингов, а для 12 магазинов это 84 переменные. Мне кажется — многовато.
Собственно, для заказчика сейчас идеальное время реакции… И наиболее важно в отличии от обычного OSPF, что именно тестируется качество канала связи.
Чуть позже, я думаю, напишу статью о том, как именно поставляется и резервируется сам интернет, а не связь между магазинами. Там, я как раз использую глобальные переменные, но немного для других целей.
Получается, что у меня 3 канала в интернет. Хотя из трех каналов, по факту, два от одного провайдера, с одинаковым выходом с мир (от провайдера) и политикой нарезки скорости. Но, для клиента, эти 2 канала абослютно независимы друг от друга физически. Балансировки нет.
для каждого магазина будем хранить в памяти 7 результатов последних пингов, а для 12 магазинов это 84 переменные. Мне кажется — многовато.Можно использовать массивы.
А почему 100 переменных в памяти — много? Только если в плане удобства их использования.
Может массив массивов (не уверен, что это работает, сам не пробовал), будет 1 переменная, но например 1 магазин уже не так просто добавить/убрать, не накосячив с выходом за границы и т.д.
Sign up to leave a comment.
Резервирование внутренних и внешних каналов связи, статическая маршрутизация, корпоративная сеть на MikroTik