Можно. Но в этом случае нужно брать от провайдеров не только default, но и какие-то «контрольные» префиксы. А вот их адекватный выбор (что бы по ним можно было увидеть проблему у провайдера) задачка не типовая и сильно завязана на топологию провайдера.
Это правильно. Так и делаем. Единственное, что маршрутизация, в отличии от IP SLA, сама по себе, не контролирует работу сервиса, а только достижимость хоста.
Ясно. Такое делаем. Я просто как-то не сразу понял, что под anycast имеется ввиду. Тут только один аспект в пользу IP SLA: сам маршрутизатор, по сути, живость сервиса контролирует, а не только достижимость хоста. Т.е. ловим падение демона, к примеру, или ошибку конфигурации без внешнего мониторинга.
А в остальном — согласен. Quagga на самом DNS и полный вперед.
Это с DHCP. А если DNS прописан в настройка Virtual-Template для PPPoE и настраивается по LCP? Либо два Vt и думать как их распределить равномерно. Либо менять конфиг Vt через равные интервалы времени. Либо опять же — уходить на DHCP.
Скажу больше. Это timeout. Более критичен threshold (который тоже неявно 5000мс). Так что все еще жестче! ))) Конечно это ошибка. Спасибо! Исправил и добавил в конфиг threshold 10
Имеется в виду per port? А трафик от одного и того же клиента куда пойдет?
Если мне не изменяет память, Cisco по умолчанию раскладывает per flow. Критерии отдельного flow: src ip + dst ip + src port + dst port. Так что, по идее, трафик нового запроса должен уйти на другой сервер (в пределах вероятности), так как flow другой. Но есть мнение, что Cisco не учитывает src port, так как в production замечены случаи, что запросы одного абонента стабильно попадали на один резолвер.
вы предлагаете клиенту подождать
По сути — да. Только threshold можно поправить, так что просто <=9 секунд. И тут, в комментариях ниже, что нужно присмотреться к версии IOS. Вроде бы можно и меньше, но ничего не могу сказать — у меня 9.
А «ответит некорректно» — это как?… домен гугла разделегируется
Например NXDOMAIN:
IPSLA operation id: 200
Latest RTT: 0 milliseconds
Latest operation start time: 20:20:02 UTC+7 Wed Aug 17 2016
Latest operation return code: DNS query error
Number of successes: 0
Number of failures: 11
Operation time to live: Forever
Конечно, тут основная идея, что мы выбираем неких «контрольный» домен и допускаем, что вероятность его сбоя или сбоя корневых серверов существенно ниже сбоя вашей инфраструктуры или ошибки конфигурации ваших инженеров. Например, DNS-ом у вас внезапно начал заниматься студен-практикант. )))) Тогда, если однажды Вы получите nxdomain вместо www.google.com, логично в первую очередь проверить, как там дела у студента и что он делает с кэшом, а потом звонить в гугол ))))
На EEM такое наверное можно сделать, но сложно. Для этого есть BGP Conditional Advertisment, который, конечно, надо описать в заметке (и на что мне уже указали выше). Там как раз можно написать route-map с анализом префиксов, next-hop для них и as-path, в зависимости от результата которого будут меняться анонсы. Конечно, для этого надо иметь от провайдера контрольный префикс. Т.е. вариант «берем только default» не прокатит. Возможно даже нужен full view.
Как правило, провайдеры имеют несколько стыков между собой или с пиринговыми площадками. На схеме, поэтому, сделан пир межу ними. Так что связанность не пропадает.
Как правило, провайдеры имеют несколько стыков между собой или с пиринговыми площадками. На схеме, поэтому, сделан пир межу ними. Так что связанность не пропадает.
Для красоты. Из регулярного выражения _state может быть и «Down» и «reset». Приводим в сообщении к «DOWN». Унифицированное сообщение в syslog, что бы упростить жизнь дежурной смене, например.
Это не «еще один» способ. Я бы сказал, что это ОСНОВНОЙ способ и я упомянул его в статье, но наверное надо было описать его подробней. Вот только он, действительно, не работает при неудачной конфигурации подсетей, когда их нельзя сагрегировать.
А в остальном — согласен. Quagga на самом DNS и полный вперед.
Скажу больше. Это timeout. Более критичен threshold (который тоже неявно 5000мс). Так что все еще жестче! ))) Конечно это ошибка. Спасибо! Исправил и добавил в конфиг
threshold 10Если мне не изменяет память, Cisco по умолчанию раскладывает per flow. Критерии отдельного flow: src ip + dst ip + src port + dst port. Так что, по идее, трафик нового запроса должен уйти на другой сервер (в пределах вероятности), так как flow другой. Но есть мнение, что Cisco не учитывает src port, так как в production замечены случаи, что запросы одного абонента стабильно попадали на один резолвер.
По сути — да. Только threshold можно поправить, так что просто <=9 секунд. И тут, в комментариях ниже, что нужно присмотреться к версии IOS. Вроде бы можно и меньше, но ничего не могу сказать — у меня 9.
Например NXDOMAIN:
Конечно, тут основная идея, что мы выбираем неких «контрольный» домен и допускаем, что вероятность его сбоя или сбоя корневых серверов существенно ниже сбоя вашей инфраструктуры или ошибки конфигурации ваших инженеров. Например, DNS-ом у вас внезапно начал заниматься студен-практикант. )))) Тогда, если однажды Вы получите nxdomain вместо www.google.com, логично в первую очередь проверить, как там дела у студента и что он делает с кэшом, а потом звонить в гугол ))))
Community — в идеальном мире идеальных провайдеров. В реальности все весьма печально и гибкостью политика многих операторов не отличается.