L2TP тунели, интересная ситуация.

Конкретно как с этим в циске не знаю, но задача вполне решаема http://habrahabr.ru/post/100919/

Andron_buton, вы немного не поняли :)

Предложенный вами пример позволяет работать с двумя операторами связи... балансируя или разделяя нагрузку между ними, в моей задаче таких условий нет, у меня получается абсурдная ситуация в рамках которой мне надо установить ДВА ОДИНАКОВЫХ СТАТИЧЕСКИХ МАРШРУТА НА РАЗНЫЕ ШЛЮЗЫ

представьте себе:

1.1.1.0/24 - > 5.5.5.5

1.1.2.0/24 - > 5.5.5.5

Как будет себя вести роутер (любой я полагаю) при наличии такого в таблице маршрутизации?

При этом мне не надо балансировать, мне не надо распределять, мне вообще не надо что бы эти каналы знали друг про друга, они должны работать как бы независимо, кто пришел по одному в него ушел... тут загвоздка в том что надо строить L2TP тунели, а клиенты че-то не дозваниваются в нам если нет статических маршрутов о которых я пишу, однако ситуация как я уже выше написал такова, что я как бы вынужден прописывать два одинаковых маршрута в две разные стороны..... :((((

как-то пример неудачно сделан, ибо с этой фразой не совпадает

В этом и моя проблема\вопрос.... Провайдер что подает мне клиентов слегка зажранный, по этому там отвечают тупо в стиле "настраивайте со своей стороны"..... и точка.... а я вот че-то въехать не могу... то ли мне надо пилить их менеджеров что бы добиться результатов, либо может я какие-то основы упускаю :(

Главный вопрос: а зачем 2 линка? Для отказоустойчивости или других каких-то целей?

Ну так для этого нужно использовать метрики. В случае недоступности маршрута по приоритетной метрике роутер переключит на более низкую.

Неужели циско этого не умеет? Сомневаюсь...

Основная суть заключается в том, что основной линк уже используется на 90-100%.... по этому взяли дополнительный.... Отказоустойчивость тут не при чем. Просто 1 Gb/s стало мало.

---------- Добавлено 09.01.2015 в 09:11 ----------

Метрика будет делать приоритеты между маршрутами, однако мне требуется что бы работали оба линка одновременно.... по сути они и так работают, только вот не ясно как быть с роутингом который просит провайдер с той стороны :((( В этом и делема... и странность... но пообщаться предметно с провайдером очень сложно... они пишут "решайте на свой стороны вопросы".....

Оно? https://supportforums.cisco.com/document/96651/troubleshooting-eigrp-variance-command

Andreyka, не думаю, смотри какая штука получается:

У меня не до конца раскрыта концепция ввиду того, что мой апстрим очень молчаливый..... у меня ситуация выглядит так:

1 канал смотрит в интернет.

1 канал от молчаливого апстрима, откуда приходят pppoe клиенты через L2TP.

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

Однако теперь появился третий линк, по аналогии с первым, он тоже будет присылать pppoe клиентов через L2TP тунели, однако в доке по второму линку просьба установить те же статические маршруты только теперь уже на шлюз от второго линка.....

Вот мне надо понять, как настраиваются именно такие вещи, возможно это дебилизм со стороны молчаливого провайдера.... а возможно я чего-то не понимаю.... По этому хочется найти тех кто делал нечто подобное....

Ведь пропись статических маршрутов для одной и той же сети в двух разных направлениях.... как бы не укладывается в моем понимании... Работать будут по факту доступности, это ясно, однако надо что бы работали ОБА... а получается история, что если если я прописываю повторный роутинг, то весь трафик заворачивается в новый канал и пропадает с первого......

Вот такая фигня....

Если все приоритеты одинаковые, то почему бы нет?

Ну так оно на самом деле работает или вы еще не пробовали просто?

Технологически препятствий нет. Можно на разные arp-адреса отправлять пакет с любым адресом назначения

С цисководами ведь главное что - найти как они это называют с маркетинговой точки зрения и дальше уже читать. Называют они это Load-Balancing .

Я что-то не могу найти отдельной статьи, но это означает что фича настолько естественна, что статьи не удостоилась.

Есть про проблемы возникающие вместе с CEF

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipswitch_cef/configuration/15-mt/isw-cef-15-mt-book/isw-cef-load-balancing.html#GUID-EEC28AD8-F73C-4106-B46F-D1CEDC7F7AF9