Согласен, есть такая вероятность, однако, даже если прилетит ext-2 по OSPF, то у меня в routing tables административное расстояние для OSPF остается по умолчанию — 110 и данный машрут проиграет статическим default-route.
Но, в целом с замечанием согласен.
У меня в 6-й ветке, все прекрасно фильтруется.
Собственно в решении оно именно так и используется.
Нет, правда, если интересно, попробуйте собрать стенд и проверить.
Как раз позволит другим магазинам видеть сервер ревизии и Wi-Fi Printer, т.к. оно разрешает установку маршрута в Routing-Table из OSPF-Database любого адреса из пула 192.168.3.0/24 с префиксом /32.
Возможно, но я предпочел фильтровать все, для запрета. Т.к. не вижу никакого смысла разрешать хоть какую-нибудь сеть, т.к. все равно в данном дизайне мне ненужно чтобы маршрутизаторы в магазинах получали по OSPF хоть какой-то маршрут.
Вернее, получать они его в OSPF-database все равно будут, т.к. это Link-state-protocol, но мне не нужно чтобы маршруты из OSPF Database устанавливались в Routing-table.
Хмм, у меня прекрасно работает и добавляется.
Интересную заметку Вам выдает роутер:
Note that internal RIP filtering is done using prefix lists [and internal (intra-area) OSPF filtering is not supported yet]
У Вас, случаем ospf-in не используется в роли prefix-lists для фильтрации маршрутов в роутере RIP?
Дело в том, что протокол RIP действительно не поддерживает типы ospf-маршрутов. Т.к. он не имеет никакого понятия о логике работы OSPF, при этом прекрасно умеет работать с Prefix-lists
Добрый вечер! Только сейчас увидел Ваш комментарий.
Не совсем понял, что именно Вы имели ввиду, под использованием DNS-имен.
И как 53-й порт поможет отыскать местонахождение принтера.
Терминал у Вас GPON или EPON?
Если GPON то, работать будет на нормальных скоростях. При EPON и уровне сигнала >30,96, могут быть проблемы со скоростью (у GPON есть FEC, который за счет избыточного трафика улучшает надежность), так-же очень вероятно что модем может перестать видеть OLT.
Такой уровень может быть как раз из-за грязи, но белее вероятно что он из-за топологии, когда выше по линии стоят множество оптических делителей — которые вносят затухания.
Ну, микроскоп с собой могут и не носить. А вот "чистилки" для патчкордов, да и для проходных адаптеров тоже. Делают очистку и уровень становится лучше.
Просто при построении PON сети, уровень сигнала в конечных участках разнится и зачастую несколько dB играют роль.
Бывали случаи, когда абонент снимал оптически терминал (модем) и вытирал патчкорд об штанину. Естественно, после таких манипуляций подключенный обратно модем мог бы работать с более худшим уровнем сигнала. А бывало так, что подключаем новый патчкорд и все равно плохо. Т.к. в проходном адаптере была грязь и новый патчкорд пачкался, тогда выручал микроскоп.
В общем, порою вещь очень и очень полезная.
Да, проблема реальная. Зачастую при построении PON сетей, сталкиваемся с тем, что у того или иного абонента значительно хуже уровень сигнала чем у соседей. Это может привести либо к потерям скорости, либо к полному отказу работы.
Приезжают монтажники, чистят соединители и все начинает работать.
Грязь, большой загиб волокна, довольно частые причина ухудшения уровня сигнала.
Спасибо за интерес к статье.
Мне как раз таки не хотелось, чтобы на роутере запускалось много скриптов с низким интервалом. Так-же не очень хотелось создавать много переменных. Если я правильно понял Вас, то по-идее, для каждого магазина будем хранить в памяти 7 результатов последних пингов, а для 12 магазинов это 84 переменные. Мне кажется — многовато.
Собственно, для заказчика сейчас идеальное время реакции… И наиболее важно в отличии от обычного OSPF, что именно тестируется качество канала связи.
Чуть позже, я думаю, напишу статью о том, как именно поставляется и резервируется сам интернет, а не связь между магазинами. Там, я как раз использую глобальные переменные, но немного для других целей.
Получается, что у меня 3 канала в интернет. Хотя из трех каналов, по факту, два от одного провайдера, с одинаковым выходом с мир (от провайдера) и политикой нарезки скорости. Но, для клиента, эти 2 канала абослютно независимы друг от друга физически. Балансировки нет.
Я не совсем понял, что именно у Вас переехало на Mail.ru?
Учетка, которая используется маршрутизатором для отправки e-mail? (В моем случае Яндекс)
Или учетка на которую маршрутизатор шлет письма? (В моем случае Gmail)
Спасибо за проявленный интерес к статье.
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. Который я использую и в магазинах, и в центральном офисе. Может, кому-то будет интересно и пригодится.
Почту отправляю через учетку заведенную на Яндексе. Письма отправляю на gmail. C отображение кодировок проблем нет. Единственный момент, это некорректное отображение при чтении письма с gmail через почтовый клиент HTC Sense.
Через клиент gmail все отображение корректно.
Но, в целом с замечанием согласен.
У меня в 6-й ветке, все прекрасно фильтруется.
Собственно в решении оно именно так и используется.
Нет, правда, если интересно, попробуйте собрать стенд и проверить.
Как раз позволит другим магазинам видеть сервер ревизии и Wi-Fi Printer, т.к. оно разрешает установку маршрута в Routing-Table из OSPF-Database любого адреса из пула 192.168.3.0/24 с префиксом /32.
Вернее, получать они его в OSPF-database все равно будут, т.к. это Link-state-protocol, но мне не нужно чтобы маршруты из OSPF Database устанавливались в Routing-table.
Интересную заметку Вам выдает роутер:
У Вас, случаем ospf-in не используется в роли prefix-lists для фильтрации маршрутов в роутере RIP?
Дело в том, что протокол RIP действительно не поддерживает типы ospf-маршрутов. Т.к. он не имеет никакого понятия о логике работы OSPF, при этом прекрасно умеет работать с Prefix-lists
Не совсем понял, что именно Вы имели ввиду, под использованием DNS-имен.
И как 53-й порт поможет отыскать местонахождение принтера.
Если GPON то, работать будет на нормальных скоростях. При EPON и уровне сигнала >30,96, могут быть проблемы со скоростью (у GPON есть FEC, который за счет избыточного трафика улучшает надежность), так-же очень вероятно что модем может перестать видеть OLT.
Такой уровень может быть как раз из-за грязи, но белее вероятно что он из-за топологии, когда выше по линии стоят множество оптических делителей — которые вносят затухания.
Просто при построении PON сети, уровень сигнала в конечных участках разнится и зачастую несколько dB играют роль.
Бывали случаи, когда абонент снимал оптически терминал (модем) и вытирал патчкорд об штанину. Естественно, после таких манипуляций подключенный обратно модем мог бы работать с более худшим уровнем сигнала. А бывало так, что подключаем новый патчкорд и все равно плохо. Т.к. в проходном адаптере была грязь и новый патчкорд пачкался, тогда выручал микроскоп.
В общем, порою вещь очень и очень полезная.
Приезжают монтажники, чистят соединители и все начинает работать.
Грязь, большой загиб волокна, довольно частые причина ухудшения уровня сигнала.
Мне как раз таки не хотелось, чтобы на роутере запускалось много скриптов с низким интервалом. Так-же не очень хотелось создавать много переменных. Если я правильно понял Вас, то по-идее, для каждого магазина будем хранить в памяти 7 результатов последних пингов, а для 12 магазинов это 84 переменные. Мне кажется — многовато.
Собственно, для заказчика сейчас идеальное время реакции… И наиболее важно в отличии от обычного OSPF, что именно тестируется качество канала связи.
Чуть позже, я думаю, напишу статью о том, как именно поставляется и резервируется сам интернет, а не связь между магазинами. Там, я как раз использую глобальные переменные, но немного для других целей.
Получается, что у меня 3 канала в интернет. Хотя из трех каналов, по факту, два от одного провайдера, с одинаковым выходом с мир (от провайдера) и политикой нарезки скорости. Но, для клиента, эти 2 канала абослютно независимы друг от друга физически. Балансировки нет.
Учетка, которая используется маршрутизатором для отправки e-mail? (В моем случае Яндекс)
Или учетка на которую маршрутизатор шлет письма? (В моем случае Gmail)
1. Что именно Вы имеете ввиду под l2-сегментом? То, что дает провайдер? Или то, что для маршрутизации между магазинами я использую прямой l2-сегмент и роутинг идет напрямую на IP-адреса интерфейсов без внутренних туннелей?
У меня были мысли, создать внутренние туннели. Действительно, тогда было бы удобнее отслеживать падение магазинов. Так-же, это помогло бы решить проблему с непроходимостью OSPF. Но, мне не хотелось делать лишние инкапсуляции при передачи данных между магазинам по основным каналам. Поэтому, я решил отказаться от внутреннего туннелирования. Да и отследить проблему падения магазина помогает скрипт в магазине, на случай если он отвалится. В случае, если отвалится один из приходящих каналов от ISP-1 в офисе, то соответственно отвалится один из каналов в интернет (идущих через ISP-1). В таком случае, письмо с уведомлением о падении интернет канала придет из главного офиса. Магазины в таком случае, будут молча работать через второй внутренний канал от ISP-1.
Плюс в таблице маршрутизации линки, которые не работают будут с АД равным = 110,120,130 соответственно от рабочих 10,20,30.
По пунктам 2 и 3. Я полностью с Вами согласен насчет того, что через OSPF было бы правильнее. Но, так как, мне еще нужно было брать интернет в магазинах из центрального офиса (от ISP-1), то я остановился на статической маршрутизации и только скриптах.
А вот это было решающим.
Но, хочу сказать, что в данном проекте я все равно поднял OSPF, но использую ее не для связи между магазинами, а для другой цели, о чем кратко упомянул в статье:
Хочу посвятить этой теме отдельную небольшую статью в будущем.
Так-же, думаю описать в статье свои изменения в скрипте пользователя magnitudo. Который я использую и в магазинах, и в центральном офисе. Может, кому-то будет интересно и пригодится.
Через клиент gmail все отображение корректно.