Системное администрирование
Сетевые технологии
Комментарии 25
0
В поле «Написать комментарий» справа есть «html-теги». Один из перечисленных
<img src="" />

Вставка изображения, в атрибуте src нужно указывать полный путь к изображению. Возможно выравнивание картинки атрибутом align.

Скорее всего, что-то типа
src="" align="center"

Вопрос не совсем по теме, есть ли симуляторы juniper под vmware, для тренировки так сказать?
0
Есть виртуалка Junos OS 12.1R1.9 (более менее последняя) вот здесь
rutracker.org/forum/viewtopic.php?t=4061726
Но в каком виде все это работает — если честно, без понятия! )

Кстати, не работает align почему-то. Ставил и center и middle…
0
Junos OS 9.3 — ужасно древняя и страшно глючная, не надо ее ставить!
0
Уважаемый автор, хотел бы обратиться к Вам с просьбой проверки материала перед публикацией.

1.
На шлюзе поднят source NAT, который отдает страничку обоим внешним интерфейсам.


я уже не говорю, что NAT вероятно либо statis, либо destination. Во-вторых «отдает страничку обоим внешним интерфейсам» — вообще не понятно.

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


С чего бы? Другое дело пользователь сервиса, он отправлял запрос на адрес 1.2.3.4, а получил ответ от 5.6.7.8. Не все приложения нормально это переваривают.

3. И самое главное. Трафик возвращается от сервера к клиенту, на основании чего маршрутизатор должен или сделает вывод об обработке пакета той или иной таблицей маршрутизации?
0
Хорошо.
1. Если я скажу, что на каждом интерфейсе внешнем поднят source NAT — так станет понятнее? Или в чем вопрос?
2. Я описал нормальную ситуацию среди нормальных провайдеров. Не цепляйтесь к словам, коллега.
3. В данном случае маршрутизатору не из чего выбирать. Он всегда обязан обработать входящие пакеты соответствующей таблицей маршрутизации. Соответственно, на одном внешнем интерфейсе она одна, на другом — другая. Здесь нет балансировки, т.к. задачи такой не стоит.
0
Не понял, а как обратный пакет от веб-сервера будет отправлен в интерфейс ISP2? На основании чего?
Шлюзу прилетает пакет от веб-сервера. Веб-сервер находится в дефолтном VRF. Почему он вдруг отправит его в другой VRF?
0
По идее статья и должна была ответить на этот вопрос. Но о policy routing ни слова, а главное на основании чего маршрутизировать?
0
2.
если основным шлюзом у нас является ISP1, то веб-запросы из сети ISP2 приходят к нам на сервер и уходят через основной шлюз в сеть к ISP1, который это дело, понятное дело, блочит.

Я описал нормальную ситуацию среди нормальных провайдеров.


Если правильно понял, Вы хотите сказать, что если провайдер ISP1 выдал нам адрес 1.2.3.4 и получил на вход трафик с источником 5.6.7.8, то такой трафик будет заблокирован? Если так, то это ситуация с домопровайдерами, а не нормальными провайдерами.

3. Представьте ситуацию. Клиент (IP 20.20.20.20) отправляет запрос на сервер и, допустим, приходит через ISP1. Сервер обрабатывает запрос и отправляет ответ на 20.20.20.20. Этот пакет получает маршрутизатор. Какому провайдеру будет отправлен пакет и почему? А потом клиент 30.30.30.30 также запрашивает информацию у сервера, но приходит через ISP2. Сервер отправляет ответ на 30.30.30.30. Как этот пакет обрабатывает маршрутизатор (какому провайдеру будет отправлен и почему)?
-1
Если честно, я не в курсе, как в деталях работает эта схема, но она работает, это проверено.
По факту она делает следующее: все, что приходит с ISP2 — уходит в него же. Все, что приходит с ISP1, тоже уходит в него же.
Короче, с какого внешнего интерфейса пакет пришел — в тот он и уйдет. Это реально удобно.
0
Не есть хорошо писать про то, что сами не знаете как работает :)

> который это дело, понятное дело, блочит.
Совсем не понятно, почему это он должен блочить. Симметричный трафик в интернете нормальное явление, корневые и провайдерские роутеры самостоятельно считают наиболее оптимальные для себя маршруты. Соотвественно маловероятно, что пакет который был отправлен с одного континента в другой (из одной AS в другую, значительно удаленную) вернрется тем же путем.
0
Совсем не понятно, почему это он должен блочить.

Это же очевидно. Вот есть клиент с PA блоком адресов, выданным данным провайдером. Есть PE роутер, который анонсирует соседям маршрут на этот PA префикс. Префикс не может засветиться в какой-нибудь другой точке Сети, или у другого провайдера, он всегда в одном месте. Потому провайдер делает совершенно правильно, когда включает RPF проверку на PE. Она сработает и дропнет пакет только если клиент что-то неправильно настроит (с этими настройками у него все равно ничего работать не будет, так как обратка улетит неизвестно куда), либо если клиент активно кого-то атакует (тем более имеет смысл блокировать). Третий вариант — «клиенту принадлежат два PA блока от разных провайдеров, и исходящие пакеты могут улетать не в ту сторону» вряд ли часто рассматривается, и думаю, для того, чтобы провайдер не блокировал такие пакеты, надо доказать ему факт владения этой подсетью.

А кому требуется слать пакеты с одним и тем же source сразу нескольким провайдерам, тот покупает PI блок. Все так делают.

celebrate, это действительно очень плохо, когда вы создаете микроскопический пост про жалкие 6 команд, и не можете объяснить, что они делают. Хуже — то, что вы настроили это у себя в боевой инфраструктуре, не разобравшись в них. Да, я тоже не понял, что вы наворотили. Просто статический маршрут для ECMP что ли? Обычно NAT отрабатывает после роутинга, то есть проблемы очень даже будут, если провайдеры осуществляют RPF проверку.
0
В соседней ветке речь пошла про PI AS, соотвественно, мой комментарий именно про эти условия.
Прошу прощения, выразился не точно.
0
На самом деле, даже при PI AS нужно заранее договориться, кто кому какие сети отдает. В таких условиях тоже имеет смысл включать RPF для ентерпрайз клиента, который не может анонсировать чужие префиксы и не станет пускать через себя транзитный трафик.
Уже бывали факапы масштабом со всю страну — когда провайдер не догадался фильтровать анонсы от клиента, а клиент сильно укорачивал AS PATH. По аналогии, какой смысл НЕ фильтровать приходящие от клиента пакеты?
0
3. Это кстаит и есть точная формулировка вопроса на который должна была ответить статья. На сколько я знаю наиболее правильным решением будет являтся анонс собсвтенной AS по BGP и загрузкой full view от обоих провайдеров.
0
А что это даст? Где гарантия, что маршрут к клиенту во 2 случае будет лучше через ISP2, чем через ISP1?
Самый простой вариант — 2 ip-адреса на сервере. Один интерфейс шлюза (к ISP1) натит на первый адрес веб-сервера, а второй интерфейс (к ISP2) — на второй адрес. И policy-based routing направляет траффик с source 2 адресом веб-сервера на интерфейс к ISP2.
Про full view и его необходимость (вернее, как раз отсутствие необходимости) отлично расписано тут
0
Ну да, гарантий на обратный маршрут это всё равно не даст…
Но если натить два интерффейса на разных провайдеров (тут нам и as своя не нужна), встает вопрос о том каким образом обеспечивать доступность для клиента? Допустим это веб-сервер, придется делать dns round robin, что тоже не является хорошим решением.
0
Где гарантия, что маршрут к клиенту во 2 случае будет лучше через ISP2, чем через ISP1?

Никакой гарантии, но в среднем по больнице пакеты будут ходить по наиболее короткому AS PATH, и можно сделать хоть какой-то load-sharing, не полагаясь на DNS.
В любом случае — будет иметься фейловер без разрыва соединений в пределах пары минут. В предложенном вами сценарии при падении одного из провайдерских каналов все клиенты, прицепившиеся к его адресу, будут довольно долго тупить.
0
Про фейловер в течение пары минут не понял, если честно. Что имелось ввиду?
0
По моим экспериментам, если отказал один из линков, то апдейт разойдется полностью максимум за пару минут. Реально — быстрее. Без необходимости переустанавливать сессии, тем более — с другим адресом.
0
Хей-хо, товарищи.
Я тут наткнулся на решение схожей задачи на Cisco (выпустить людей, находящихся в VRF, в интернет), и, думаю, оно нам может немного помочь.

На Cisco это решается так:
1. Создаём маршрут по умолчанию для VRFа, который будет брать next-hop из глобальной таблицы адресов. Это указывается словом global в конце команды ip route…
2. Включаем NAT обычным образом, указав в конце команды ip nat inside… ключевые слова VRF xxx. Тогда (ход конём!) внутренние адреса (inside local) берутся из VRF xxx, а интерфейс, куда будет натиться (inside global) берётся из глобальной таблицы.
Когда трафик возвращается назад, NAT отрабатывает раньше роутинга и помещает пакеты в нужный интерфейс (и VRF соответственно).

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