Перейти к содержимому
Калькуляторы

Посоветуйте как переделать сеть

Добрый день!

 

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

 

 

 

На схеме в ядре стоят свичи (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 не даст затерминировать внутрение вланы на своей стороне?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В л3впн незачем городить хсрп. Две pe-CE сессии с каждым пе и все

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, zhenya` сказал:

В л3впн незачем городить хсрп. Две pe-CE сессии с каждым пе и все

Боюсь что так не получится, т.к. со стороны клиента обычно стоит ПК.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

52 минуты назад, zhenya` сказал:

Это кейс не для л3впн..

Почему нет? Клиент хочет закрытую от посторонних маршрутизацию. У него есть центральная точка, где стоят какие-нить серверы. А остальные просто ходят до центральной точки через л3 облако.

Ну допустим это не l3vpn, а обычная услуга интернет, которая по сути тоже л3впн, т.к. лежит в отдельной таблице.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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-ов, насколько это правильно?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну у вас же так или иначе будет 4000 hsrp group и 4000 сабов, ну будет еще и 4000 pseudowire,  вполне себе нормальный вариант

без pseudowire это только в bridge-domain  добавлять ваш per-link.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

23 часа назад, fork сказал:

ну у вас же так или иначе будет 4000 hsrp group и 4000 сабов, ну будет еще и 4000 pseudowire,  вполне себе нормальный вариант

без pseudowire это только в bridge-domain  добавлять ваш per-link.

Я думаю вы правы, я просто надеялся что есть возможность запаковать эжто все в QinQ и гонять по одному каналу :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В принципе как действовать мне понятно. Для борьбы с петлями на L2 уровне хочу попробовать R-L2GP/MSTP AG. Ну или как план "Б": erps на длинках. Кто-нить делал такое, какие могут быть подводные камни? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Попробовал R-L2GP на тестовом ASRе, вроде все ок, фейковые BPDUшки он шлет. Но проблема в том, что это работает только в нейтив влане, а мне очень хочется весь этот трафик пропустить сквозь 45 и 65 циски, чтобы на них не поднимать MSTP. Пляски с QinQ мне не помогли. Есть мысль на коммутаторах (на 45 и 65ой) делать сквозной Access влан между ASRом и соответствующими длинками с выключенным STP на нем и смотреть на него транками. В принципе это должно быть ок, но нужно будет отключать mac-learning на таком влане. Вот тут у меня есть внутреннее ощущение что это может запетлить, но я не могу понять как. Может есть другой способ, который я не вижу? Или кто что может посоветовать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Делайте L3 транспорт, абонентов гоняйте поверх MPLS. Это единственное верное решение на больших сетях.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

18 часов назад, Saab95 сказал:

абонентов гоняйте поверх MPLS. Это единственное верное решение на больших сетях.

это работает когда на доступе стоят РЕ, а не свитчи делинки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну так свичи длинки тоже умеют мплс некоторые модели, стоимостью 160 тыс.р. Они умеют вланы паковать в туннели, и вот на доступе обычные длинки пакуют абонентские порты во влан, а длинк за 160 тыс. пакует их в мплс.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Коллеги, конечно все было бы проще с L3. Но беда в том, что есть то что есть. И я уже всю голову сломал как сделать так, чтобы трафиг ходил по двум плечам. И честно говоря, не вижу никакого выхода кроме того, чтобы гнать трафик до одного PE MPLS облака. А внутри облака строить PW канал между соответствующими PE.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 минуту назад, fork сказал:

в итоге, как L2 дотягиваете до облака от Access?

Думаю таки построить ERPS кольцо на длинках. На каталистах пропускать трафик через QinQ чтобы они вообще не учавствовали в процессе. План такой :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.