Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
В поле «Написать комментарий» справа есть «html-теги». Один из перечисленных
Скорее всего, что-то типа
Вопрос не совсем по теме, есть ли симуляторы juniper под vmware, для тренировки так сказать?
<img src="" />
Вставка изображения, в атрибуте src нужно указывать полный путь к изображению. Возможно выравнивание картинки атрибутом align.
Скорее всего, что-то типа
src="" align="center"
Вопрос не совсем по теме, есть ли симуляторы juniper под vmware, для тренировки так сказать?
Есть виртуалка Junos OS 12.1R1.9 (более менее последняя) вот здесь
rutracker.org/forum/viewtopic.php?t=4061726
Но в каком виде все это работает — если честно, без понятия! )
Кстати, не работает align почему-то. Ставил и center и middle…
rutracker.org/forum/viewtopic.php?t=4061726
Но в каком виде все это работает — если честно, без понятия! )
Кстати, не работает align почему-то. Ставил и center и middle…
Для тренировки: habrahabr.ru/post/111172/, образ ОС — rutracker.org/forum/viewtopic.php?t=2419674.
Уважаемый автор, хотел бы обратиться к Вам с просьбой проверки материала перед публикацией.
1.
я уже не говорю, что NAT вероятно либо statis, либо destination. Во-вторых «отдает страничку обоим внешним интерфейсам» — вообще не понятно.
2.
С чего бы? Другое дело пользователь сервиса, он отправлял запрос на адрес 1.2.3.4, а получил ответ от 5.6.7.8. Не все приложения нормально это переваривают.
3. И самое главное. Трафик возвращается от сервера к клиенту, на основании чего маршрутизатор должен или сделает вывод об обработке пакета той или иной таблицей маршрутизации?
1.
На шлюзе поднят source NAT, который отдает страничку обоим внешним интерфейсам.
я уже не говорю, что NAT вероятно либо statis, либо destination. Во-вторых «отдает страничку обоим внешним интерфейсам» — вообще не понятно.
2.
если основным шлюзом у нас является ISP1, то веб-запросы из сети ISP2 приходят к нам на сервер и уходят через основной шлюз в сеть к ISP1, который это дело, понятное дело, блочит.
С чего бы? Другое дело пользователь сервиса, он отправлял запрос на адрес 1.2.3.4, а получил ответ от 5.6.7.8. Не все приложения нормально это переваривают.
3. И самое главное. Трафик возвращается от сервера к клиенту, на основании чего маршрутизатор должен или сделает вывод об обработке пакета той или иной таблицей маршрутизации?
Хорошо.
1. Если я скажу, что на каждом интерфейсе внешнем поднят source NAT — так станет понятнее? Или в чем вопрос?
2. Я описал нормальную ситуацию среди нормальных провайдеров. Не цепляйтесь к словам, коллега.
3. В данном случае маршрутизатору не из чего выбирать. Он всегда обязан обработать входящие пакеты соответствующей таблицей маршрутизации. Соответственно, на одном внешнем интерфейсе она одна, на другом — другая. Здесь нет балансировки, т.к. задачи такой не стоит.
1. Если я скажу, что на каждом интерфейсе внешнем поднят source NAT — так станет понятнее? Или в чем вопрос?
2. Я описал нормальную ситуацию среди нормальных провайдеров. Не цепляйтесь к словам, коллега.
3. В данном случае маршрутизатору не из чего выбирать. Он всегда обязан обработать входящие пакеты соответствующей таблицей маршрутизации. Соответственно, на одном внешнем интерфейсе она одна, на другом — другая. Здесь нет балансировки, т.к. задачи такой не стоит.
Не понял, а как обратный пакет от веб-сервера будет отправлен в интерфейс ISP2? На основании чего?
Шлюзу прилетает пакет от веб-сервера. Веб-сервер находится в дефолтном VRF. Почему он вдруг отправит его в другой VRF?
Шлюзу прилетает пакет от веб-сервера. Веб-сервер находится в дефолтном VRF. Почему он вдруг отправит его в другой VRF?
2.
Если правильно понял, Вы хотите сказать, что если провайдер 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. Как этот пакет обрабатывает маршрутизатор (какому провайдеру будет отправлен и почему)?
если основным шлюзом у нас является 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. Как этот пакет обрабатывает маршрутизатор (какому провайдеру будет отправлен и почему)?
Если честно, я не в курсе, как в деталях работает эта схема, но она работает, это проверено.
По факту она делает следующее: все, что приходит с ISP2 — уходит в него же. Все, что приходит с ISP1, тоже уходит в него же.
Короче, с какого внешнего интерфейса пакет пришел — в тот он и уйдет. Это реально удобно.
По факту она делает следующее: все, что приходит с ISP2 — уходит в него же. Все, что приходит с ISP1, тоже уходит в него же.
Короче, с какого внешнего интерфейса пакет пришел — в тот он и уйдет. Это реально удобно.
Не есть хорошо писать про то, что сами не знаете как работает :)
> который это дело, понятное дело, блочит.
Совсем не понятно, почему это он должен блочить. Симметричный трафик в интернете нормальное явление, корневые и провайдерские роутеры самостоятельно считают наиболее оптимальные для себя маршруты. Соотвественно маловероятно, что пакет который был отправлен с одного континента в другой (из одной AS в другую, значительно удаленную) вернрется тем же путем.
> который это дело, понятное дело, блочит.
Совсем не понятно, почему это он должен блочить. Симметричный трафик в интернете нормальное явление, корневые и провайдерские роутеры самостоятельно считают наиболее оптимальные для себя маршруты. Соотвественно маловероятно, что пакет который был отправлен с одного континента в другой (из одной AS в другую, значительно удаленную) вернрется тем же путем.
Совсем не понятно, почему это он должен блочить.
Это же очевидно. Вот есть клиент с PA блоком адресов, выданным данным провайдером. Есть PE роутер, который анонсирует соседям маршрут на этот PA префикс. Префикс не может засветиться в какой-нибудь другой точке Сети, или у другого провайдера, он всегда в одном месте. Потому провайдер делает совершенно правильно, когда включает RPF проверку на PE. Она сработает и дропнет пакет только если клиент что-то неправильно настроит (с этими настройками у него все равно ничего работать не будет, так как обратка улетит неизвестно куда), либо если клиент активно кого-то атакует (тем более имеет смысл блокировать). Третий вариант — «клиенту принадлежат два PA блока от разных провайдеров, и исходящие пакеты могут улетать не в ту сторону» вряд ли часто рассматривается, и думаю, для того, чтобы провайдер не блокировал такие пакеты, надо доказать ему факт владения этой подсетью.
А кому требуется слать пакеты с одним и тем же source сразу нескольким провайдерам, тот покупает PI блок. Все так делают.
celebrate, это действительно очень плохо, когда вы создаете микроскопический пост про жалкие 6 команд, и не можете объяснить, что они делают. Хуже — то, что вы настроили это у себя в боевой инфраструктуре, не разобравшись в них. Да, я тоже не понял, что вы наворотили. Просто статический маршрут для ECMP что ли? Обычно NAT отрабатывает после роутинга, то есть проблемы очень даже будут, если провайдеры осуществляют RPF проверку.
В соседней ветке речь пошла про PI AS, соотвественно, мой комментарий именно про эти условия.
Прошу прощения, выразился не точно.
Прошу прощения, выразился не точно.
На самом деле, даже при PI AS нужно заранее договориться, кто кому какие сети отдает. В таких условиях тоже имеет смысл включать RPF для ентерпрайз клиента, который не может анонсировать чужие префиксы и не станет пускать через себя транзитный трафик.
Уже бывали факапы масштабом со всю страну — когда провайдер не догадался фильтровать анонсы от клиента, а клиент сильно укорачивал AS PATH. По аналогии, какой смысл НЕ фильтровать приходящие от клиента пакеты?
Уже бывали факапы масштабом со всю страну — когда провайдер не догадался фильтровать анонсы от клиента, а клиент сильно укорачивал AS PATH. По аналогии, какой смысл НЕ фильтровать приходящие от клиента пакеты?
3. Это кстаит и есть точная формулировка вопроса на который должна была ответить статья. На сколько я знаю наиболее правильным решением будет являтся анонс собсвтенной AS по BGP и загрузкой full view от обоих провайдеров.
А что это даст? Где гарантия, что маршрут к клиенту во 2 случае будет лучше через ISP2, чем через ISP1?
Самый простой вариант — 2 ip-адреса на сервере. Один интерфейс шлюза (к ISP1) натит на первый адрес веб-сервера, а второй интерфейс (к ISP2) — на второй адрес. И policy-based routing направляет траффик с source 2 адресом веб-сервера на интерфейс к ISP2.
Про full view и его необходимость (вернее, как раз отсутствие необходимости) отлично расписано тут
Самый простой вариант — 2 ip-адреса на сервере. Один интерфейс шлюза (к ISP1) натит на первый адрес веб-сервера, а второй интерфейс (к ISP2) — на второй адрес. И policy-based routing направляет траффик с source 2 адресом веб-сервера на интерфейс к ISP2.
Про full view и его необходимость (вернее, как раз отсутствие необходимости) отлично расписано тут
Ну да, гарантий на обратный маршрут это всё равно не даст…
Но если натить два интерффейса на разных провайдеров (тут нам и as своя не нужна), встает вопрос о том каким образом обеспечивать доступность для клиента? Допустим это веб-сервер, придется делать dns round robin, что тоже не является хорошим решением.
Но если натить два интерффейса на разных провайдеров (тут нам и as своя не нужна), встает вопрос о том каким образом обеспечивать доступность для клиента? Допустим это веб-сервер, придется делать dns round robin, что тоже не является хорошим решением.
Где гарантия, что маршрут к клиенту во 2 случае будет лучше через ISP2, чем через ISP1?
Никакой гарантии, но в среднем по больнице пакеты будут ходить по наиболее короткому AS PATH, и можно сделать хоть какой-то load-sharing, не полагаясь на DNS.
В любом случае — будет иметься фейловер без разрыва соединений в пределах пары минут. В предложенном вами сценарии при падении одного из провайдерских каналов все клиенты, прицепившиеся к его адресу, будут довольно долго тупить.
А не подскажет ли кто, как это же самое делается в обычном Линуксе?
Есть такой мануальчик: Linux Advanced Routing & Traffic Control HOWTO
На русском языке например здесь:
dog-simpson.blogspot.ru/2009/03/linux-advanced-routing-traffic-control.html
На русском языке например здесь:
dog-simpson.blogspot.ru/2009/03/linux-advanced-routing-traffic-control.html
Хей-хо, товарищи.
Я тут наткнулся на решение схожей задачи на 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.
Я тут наткнулся на решение схожей задачи на 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.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Устранение ассиметричной маршрутизации в Juniper SRX