Comments 25
В поле «Написать комментарий» справа есть «html-теги». Один из перечисленных
Скорее всего, что-то типа
Вопрос не совсем по теме, есть ли симуляторы juniper под vmware, для тренировки так сказать?
<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…
rutracker.org/forum/viewtopic.php?t=4061726
Но в каком виде все это работает — если честно, без понятия! )
Кстати, не работает align почему-то. Ставил и center и middle…
0
Для тренировки: habrahabr.ru/post/111172/, образ ОС — rutracker.org/forum/viewtopic.php?t=2419674.
0
Уважаемый автор, хотел бы обратиться к Вам с просьбой проверки материала перед публикацией.
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. И самое главное. Трафик возвращается от сервера к клиенту, на основании чего маршрутизатор должен или сделает вывод об обработке пакета той или иной таблицей маршрутизации?
0
Хорошо.
1. Если я скажу, что на каждом интерфейсе внешнем поднят source NAT — так станет понятнее? Или в чем вопрос?
2. Я описал нормальную ситуацию среди нормальных провайдеров. Не цепляйтесь к словам, коллега.
3. В данном случае маршрутизатору не из чего выбирать. Он всегда обязан обработать входящие пакеты соответствующей таблицей маршрутизации. Соответственно, на одном внешнем интерфейсе она одна, на другом — другая. Здесь нет балансировки, т.к. задачи такой не стоит.
1. Если я скажу, что на каждом интерфейсе внешнем поднят source NAT — так станет понятнее? Или в чем вопрос?
2. Я описал нормальную ситуацию среди нормальных провайдеров. Не цепляйтесь к словам, коллега.
3. В данном случае маршрутизатору не из чего выбирать. Он всегда обязан обработать входящие пакеты соответствующей таблицей маршрутизации. Соответственно, на одном внешнем интерфейсе она одна, на другом — другая. Здесь нет балансировки, т.к. задачи такой не стоит.
0
Не понял, а как обратный пакет от веб-сервера будет отправлен в интерфейс ISP2? На основании чего?
Шлюзу прилетает пакет от веб-сервера. Веб-сервер находится в дефолтном VRF. Почему он вдруг отправит его в другой VRF?
Шлюзу прилетает пакет от веб-сервера. Веб-сервер находится в дефолтном VRF. Почему он вдруг отправит его в другой VRF?
0
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. Как этот пакет обрабатывает маршрутизатор (какому провайдеру будет отправлен и почему)?
0
Если честно, я не в курсе, как в деталях работает эта схема, но она работает, это проверено.
По факту она делает следующее: все, что приходит с ISP2 — уходит в него же. Все, что приходит с ISP1, тоже уходит в него же.
Короче, с какого внешнего интерфейса пакет пришел — в тот он и уйдет. Это реально удобно.
По факту она делает следующее: все, что приходит с ISP2 — уходит в него же. Все, что приходит с ISP1, тоже уходит в него же.
Короче, с какого внешнего интерфейса пакет пришел — в тот он и уйдет. Это реально удобно.
-1
Не есть хорошо писать про то, что сами не знаете как работает :)
> который это дело, понятное дело, блочит.
Совсем не понятно, почему это он должен блочить. Симметричный трафик в интернете нормальное явление, корневые и провайдерские роутеры самостоятельно считают наиболее оптимальные для себя маршруты. Соотвественно маловероятно, что пакет который был отправлен с одного континента в другой (из одной AS в другую, значительно удаленную) вернрется тем же путем.
> который это дело, понятное дело, блочит.
Совсем не понятно, почему это он должен блочить. Симметричный трафик в интернете нормальное явление, корневые и провайдерские роутеры самостоятельно считают наиболее оптимальные для себя маршруты. Соотвественно маловероятно, что пакет который был отправлен с одного континента в другой (из одной AS в другую, значительно удаленную) вернрется тем же путем.
0
Совсем не понятно, почему это он должен блочить.
Это же очевидно. Вот есть клиент с PA блоком адресов, выданным данным провайдером. Есть PE роутер, который анонсирует соседям маршрут на этот PA префикс. Префикс не может засветиться в какой-нибудь другой точке Сети, или у другого провайдера, он всегда в одном месте. Потому провайдер делает совершенно правильно, когда включает RPF проверку на PE. Она сработает и дропнет пакет только если клиент что-то неправильно настроит (с этими настройками у него все равно ничего работать не будет, так как обратка улетит неизвестно куда), либо если клиент активно кого-то атакует (тем более имеет смысл блокировать). Третий вариант — «клиенту принадлежат два PA блока от разных провайдеров, и исходящие пакеты могут улетать не в ту сторону» вряд ли часто рассматривается, и думаю, для того, чтобы провайдер не блокировал такие пакеты, надо доказать ему факт владения этой подсетью.
А кому требуется слать пакеты с одним и тем же source сразу нескольким провайдерам, тот покупает PI блок. Все так делают.
celebrate, это действительно очень плохо, когда вы создаете микроскопический пост про жалкие 6 команд, и не можете объяснить, что они делают. Хуже — то, что вы настроили это у себя в боевой инфраструктуре, не разобравшись в них. Да, я тоже не понял, что вы наворотили. Просто статический маршрут для ECMP что ли? Обычно NAT отрабатывает после роутинга, то есть проблемы очень даже будут, если провайдеры осуществляют RPF проверку.
0
В соседней ветке речь пошла про PI AS, соотвественно, мой комментарий именно про эти условия.
Прошу прощения, выразился не точно.
Прошу прощения, выразился не точно.
0
На самом деле, даже при PI AS нужно заранее договориться, кто кому какие сети отдает. В таких условиях тоже имеет смысл включать RPF для ентерпрайз клиента, который не может анонсировать чужие префиксы и не станет пускать через себя транзитный трафик.
Уже бывали факапы масштабом со всю страну — когда провайдер не догадался фильтровать анонсы от клиента, а клиент сильно укорачивал AS PATH. По аналогии, какой смысл НЕ фильтровать приходящие от клиента пакеты?
Уже бывали факапы масштабом со всю страну — когда провайдер не догадался фильтровать анонсы от клиента, а клиент сильно укорачивал AS PATH. По аналогии, какой смысл НЕ фильтровать приходящие от клиента пакеты?
0
3. Это кстаит и есть точная формулировка вопроса на который должна была ответить статья. На сколько я знаю наиболее правильным решением будет являтся анонс собсвтенной AS по BGP и загрузкой full view от обоих провайдеров.
0
А что это даст? Где гарантия, что маршрут к клиенту во 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 и его необходимость (вернее, как раз отсутствие необходимости) отлично расписано тут
0
Ну да, гарантий на обратный маршрут это всё равно не даст…
Но если натить два интерффейса на разных провайдеров (тут нам и as своя не нужна), встает вопрос о том каким образом обеспечивать доступность для клиента? Допустим это веб-сервер, придется делать dns round robin, что тоже не является хорошим решением.
Но если натить два интерффейса на разных провайдеров (тут нам и as своя не нужна), встает вопрос о том каким образом обеспечивать доступность для клиента? Допустим это веб-сервер, придется делать dns round robin, что тоже не является хорошим решением.
0
Где гарантия, что маршрут к клиенту во 2 случае будет лучше через ISP2, чем через ISP1?
Никакой гарантии, но в среднем по больнице пакеты будут ходить по наиболее короткому AS PATH, и можно сделать хоть какой-то load-sharing, не полагаясь на DNS.
В любом случае — будет иметься фейловер без разрыва соединений в пределах пары минут. В предложенном вами сценарии при падении одного из провайдерских каналов все клиенты, прицепившиеся к его адресу, будут довольно долго тупить.
0
А не подскажет ли кто, как это же самое делается в обычном Линуксе?
0
Есть такой мануальчик: 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
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.
Я тут наткнулся на решение схожей задачи на 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.
0
Sign up to leave a comment.
Устранение ассиметричной маршрутизации в Juniper SRX