Циклы маршрутизации

Ещё надо учитывать, что примерно половина всего интернета маршрутизируется не с помощью BGP, а с помощью денег и всяких систем массажа трафика, которые "лучше" знают, куда слать пакеты. Они могут поглядывать на BGP, а могут и сами принимать решение.

Совет - направить маршрут в null. А где на реальном маршрутизатор взять gw null?

Картинка с семью маршрутизаторами очень напомнила неустойчивый замкнутый цикл, какие случаются в режиме хаоса во всяких системах вроде бильярда Синая. На множестве Мандельброта тоже можно увидеть похожие картинки, если траектории строить, а не просто "не уходит/уходит/как быстро уходит", только там циклы устойчивые.

Спасибо, интересно. Цикл это тот же блэк холл, но с лишней суетой перед смертью пакета))

В обычной жизни, цикл очень редко вызовет перегрузку оборудования, т.к. Трафик состоит из маленьких 40 байтных TCP SYN пакетов, если это не дос конечно.

Циклы чаще всего возникают из-за неправильной настройки, либо из-за того, что запрашиваемый адрес из-за аварии стал недоступен, но до него есть настроенная маршрутизация (статическая, как правило, либо залипший бгп). И как только это становится проблемой, тогда это начинают чинить, прописывают маршруты в null, но везде солому подстелить нельзя, поэтому проблема в текущей версии IP и протоколов маршрутизации (статика, бгп, оспф) останется.

Что касается анализа, то делать это на неподконтрольном участке сети, прямой путь игры в угадайку. Ну например мы трейсим/пингаем адрес, а он находится за натом + в цепочке маршрутизаторов, у этих маршрутизаторов непубличные адреса могут быть, трейсим может быть мы вполне реальный публичный адрес, который, возможно даже(а может и нет), принадлежит конкретному хосту, но по пути маршрутизаторы будут нам отвечать со своих 192.168.0.1, 1.1, 2.1 и неизвестно каких адресов, нат это все дело оттранслирует, и мы получим ответ от адреса из NAT-пула :) Конечно, так мы поймем, что кольцо есть, но между кем и кем - эта информация будет покрыта мраком. Это может относиться к слайдам 32 и 33.

Еще мы можем захотеть потрейсить адрес, который находится за устройствами, которые не отвечают на ttl-exceeded - мы не получим информации о петле; не уменьшают ttl при проходе через маршрутизатор - не будем знать, что кто-то маршрутизировал пакет между узлами; специально меняет ttl на статический или заведомо уменьшает или увеличивает - это вовсе будет ломать картину и покрывать все мраком(слайд 29-30), что в добавок может приводить к бесконечным петлям, но случайно такое редко делают; может проходить через устройство, которое не маршрутизатор, но меняет ttl, чтобы уберечь себя от петель - например это может быть прозрачный NAT в режиме бриджа, он может уменьшать ttl и отвечать, а может не отвечать. Да и еще много чего может быть, может быть маршрутизация на основе не адреса назначения, а на основе адреса источника (сорс роутинг)(слайд 32-33), а адрес источника или назначения может поменяться на NAT(или если его развернуть на 180 градусов - на балансировщике).

Вообще в моей практике было так, что пакет приходил из Интернета, попадал на пограничный маршрутизатор, там был маршрут статический на NAT, проходил через NAT, там адрес назначения менялся(трансляция была создана исходящим пакетом из ЛВС в Интернет перед этим), дальше маршрутизатор в ЛВС получал пакет, но сеть, куда он должен был отправить его, стала внезапно недоступна, выпала из bgp, но у него был адрес по умолчанию - в Интернет! Теперь тот же пакет попадал в NAT уже со стороны локальной сети, но адрес назначения у него оставался старым (адрес из NAT-пула), поэтому пограничный маршрутизатор снова его отправлял в NAT, и так пока по ttl не убивал кто-то пакет.

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

Представим себе путь адрес1 -> маршрутизатор1 -> маршрутизатор2 -> маршрутизатор3 -> адрес2, в другую сторону путь будет как адрес2 -> маршуризатор3 -> маршрутизатор4 -> маршрутизатор1 -> адрес1. У маршрутизатора2 и 4 будут еще и другие интерфейсы (не зря же они - маршрутизаторы), и допустим, если на адрес1 у маршрутизатора3 будет неверный маршрут (или маршрут через линк, где есть авария), то ответный пакет с ttl-exceeded адрес1 не получит, но трафик при этом будет ходить в обе стороны исправно. А если и ответ все же дойдет, то он будет с ip интерфейса, который будет отличаться от адресов на линках с маршрутизатор1 и 3. Входящий и исходящий трафик в Интернете очень редко (ну очень) проходят симметричный путь.

А что касается того, что основные петли у AntiDDOS и CDN – то это может объяснить балансировщиками и прочим аналогичным оборудованием, на который маршруты прописаны статически на одном пути, а на другом нету маршрута в null, как в моей истории выше.