VolanD666 Опубликовано 10 января, 2020 · Жалоба Добрый день! Коллеги, посоветуйте как красиво настроить сеть с кольцами. Схема сети выглядит вот так: На схеме в ядре стоят свичи (cisco catalyst 45XX или 65XX) и роутеры (asr 9k и 1k). На доступе стоят Dlink DSG-3420-28TC. В идеале хочется избавиться от L2 трафика в ядре и перейти на p2p линки между ASRами. В таком случае каталисты становятся просто "сетевыми карточками" для ASRов и в переспективе их можно будет поменять на что-нибудь попроще. На Dlinck используются чисто как L2 свичи на доступе. Из сервисов планируется: 1) L3VPN 2) L2VPN (xconnect) 3) L2VPN (VPLS или VXLAN) В процессе осмысления этой схемы возникло несколько вопросов: 1) Начнем с L3VPN. Там в принципе все ясно, на соответствующих ASRах создаются сабинтерфейсы, настраивается HSRP. Далее влан кидается до конкретного клиента (схема 1 клиент- 1 влан). Вот тут возникает затык. Чтобы HSRP нормально отрабатывал нужно чтобы была резервируемая L2 связность между ASRами. Т.е. если порвется полукольцо (например между asr1002 и asr1001x) тогда трафик должен пойти через MPLS иначе каждый ASR будет думать что он ACTIVE и клиенты будут страдать. Конечно можно было бы кинуть влан между каталистами, но как я говорил хочется избежать колец в ядре. Как вариант можно делать xconnect между сабинтерфейсами, но тогда на каждого клиента придется создать такой виртуальный канал, насколько это правильно? Может есть какое-то решение чтобы упаковать это все в QinQ, но я боюсь что ASR не даст затерминировать внутрение вланы на своей стороне? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 10 января, 2020 · Жалоба В л3впн незачем городить хсрп. Две pe-CE сессии с каждым пе и все Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 10 января, 2020 · Жалоба 1 час назад, zhenya` сказал: В л3впн незачем городить хсрп. Две pe-CE сессии с каждым пе и все Боюсь что так не получится, т.к. со стороны клиента обычно стоит ПК. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 11 января, 2020 · Жалоба Это кейс не для л3впн.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 11 января, 2020 · Жалоба 52 минуты назад, zhenya` сказал: Это кейс не для л3впн.. Почему нет? Клиент хочет закрытую от посторонних маршрутизацию. У него есть центральная точка, где стоят какие-нить серверы. А остальные просто ходят до центральной точки через л3 облако. Ну допустим это не l3vpn, а обычная услуга интернет, которая по сути тоже л3впн, т.к. лежит в отдельной таблице. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fork Опубликовано 1 февраля, 2020 · Жалоба В 10.01.2020 в 17:49, VolanD666 сказал: Начнем с L3VPN. Там в принципе все ясно, на соответствующих ASRах создаются сабинтерфейсы, настраивается HSRP. Далее влан кидается до конкретного клиента (схема 1 клиент- 1 влан). Вот тут возникает затык. Чтобы HSRP нормально отрабатывал нужно чтобы была резервируемая L2 связность между ASRами. Т.е. если порвется полукольцо (например между asr1002 и asr1001x) тогда трафик должен пойти через MPLS иначе каждый ASR будет думать что он ACTIVE и клиенты будут страдать. Конечно можно было бы кинуть влан между каталистами, но как я говорил хочется избежать колец в ядре. Как вариант можно делать xconnect между сабинтерфейсами, но тогда на каждого клиента придется создать такой виртуальный канал, насколько это правильно? Может есть какое-то решение чтобы упаковать это все в QinQ, но я боюсь что ASR не даст затерминировать внутрение вланы на своей стороне? если между ASR у Вас MPLS поднят, что мешает поднять pwe + bridge group/bridge-domain на двух коробках? К BVI привязать HSRP, ну или к сабу. l2vpn bridge group R1 bridge-domain R1 ! neighbor 10.10.10.1 pw-id 1 ! routed interface BVI1 l2vpn bridge group R2 bridge-domain R2 ! neighbor 10.10.10.2 pw-id 1 ! routed interface BVI1 в этом случае вы полностью отвязаны от per-link Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 1 февраля, 2020 · Жалоба 8 часов назад, fork сказал: если между ASR у Вас MPLS поднят, что мешает поднять pwe + bridge group/bridge-domain на двух коробках? К BVI привязать HSRP, ну или к сабу. l2vpn bridge group R1 bridge-domain R1 ! neighbor 10.10.10.1 pw-id 1 ! routed interface BVI1 l2vpn bridge group R2 bridge-domain R2 ! neighbor 10.10.10.2 pw-id 1 ! routed interface BVI1 в этом случае вы полностью отвязаны от per-link Ну я в принципе тк ебе это и представлял. НО что если у меня 4000 клиентов. Тогда 4000 pseudowire-ов, насколько это правильно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fork Опубликовано 2 февраля, 2020 · Жалоба ну у вас же так или иначе будет 4000 hsrp group и 4000 сабов, ну будет еще и 4000 pseudowire, вполне себе нормальный вариант без pseudowire это только в bridge-domain добавлять ваш per-link. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 3 февраля, 2020 · Жалоба 23 часа назад, fork сказал: ну у вас же так или иначе будет 4000 hsrp group и 4000 сабов, ну будет еще и 4000 pseudowire, вполне себе нормальный вариант без pseudowire это только в bridge-domain добавлять ваш per-link. Я думаю вы правы, я просто надеялся что есть возможность запаковать эжто все в QinQ и гонять по одному каналу :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 3 февраля, 2020 · Жалоба В принципе как действовать мне понятно. Для борьбы с петлями на L2 уровне хочу попробовать R-L2GP/MSTP AG. Ну или как план "Б": erps на длинках. Кто-нить делал такое, какие могут быть подводные камни? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 5 февраля, 2020 · Жалоба Попробовал R-L2GP на тестовом ASRе, вроде все ок, фейковые BPDUшки он шлет. Но проблема в том, что это работает только в нейтив влане, а мне очень хочется весь этот трафик пропустить сквозь 45 и 65 циски, чтобы на них не поднимать MSTP. Пляски с QinQ мне не помогли. Есть мысль на коммутаторах (на 45 и 65ой) делать сквозной Access влан между ASRом и соответствующими длинками с выключенным STP на нем и смотреть на него транками. В принципе это должно быть ок, но нужно будет отключать mac-learning на таком влане. Вот тут у меня есть внутреннее ощущение что это может запетлить, но я не могу понять как. Может есть другой способ, который я не вижу? Или кто что может посоветовать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 7 февраля, 2020 · Жалоба Делайте L3 транспорт, абонентов гоняйте поверх MPLS. Это единственное верное решение на больших сетях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fork Опубликовано 8 февраля, 2020 · Жалоба 18 часов назад, Saab95 сказал: абонентов гоняйте поверх MPLS. Это единственное верное решение на больших сетях. это работает когда на доступе стоят РЕ, а не свитчи делинки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 8 февраля, 2020 · Жалоба Ну так свичи длинки тоже умеют мплс некоторые модели, стоимостью 160 тыс.р. Они умеют вланы паковать в туннели, и вот на доступе обычные длинки пакуют абонентские порты во влан, а длинк за 160 тыс. пакует их в мплс. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 8 февраля, 2020 · Жалоба Коллеги, конечно все было бы проще с L3. Но беда в том, что есть то что есть. И я уже всю голову сломал как сделать так, чтобы трафиг ходил по двум плечам. И честно говоря, не вижу никакого выхода кроме того, чтобы гнать трафик до одного PE MPLS облака. А внутри облака строить PW канал между соответствующими PE. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fork Опубликовано 8 февраля, 2020 · Жалоба в итоге, как L2 дотягиваете до облака от Access? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 8 февраля, 2020 · Жалоба 1 минуту назад, fork сказал: в итоге, как L2 дотягиваете до облака от Access? Думаю таки построить ERPS кольцо на длинках. На каталистах пропускать трафик через QinQ чтобы они вообще не учавствовали в процессе. План такой :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...