[psygex]

Значит имеем следующую небольшую сеть metro ethernet

 

Нужно решение для разделения траффика клиентов , клиенты в основном банки (подключение филиалов, банкоматов и т д)

DIS свичи это каталисты 3550 и 3560 , Core SW тоже 3550 но планируеться заменить на гигабитный свич с оптическими портами.

На данный момент склоняюсь к такому варианту. На DIS свичах поднимаеться для каждого клиента VRF-lite а на коре свиче MP-BGP для передачи данных

[nnm]

А с кем этот самый Core SW будет разговаривать на MP-BGP? :) Услуги-то какие предоставляться будут?

[mschedrin]

А зачем VRF lite? Клиенты требуют l3 vpn? Чем l2 не устраивает?

Ну и про mp-bgp тоже не ясно - для чего.

[psygex]

А с кем этот самый Core SW будет разговаривать на MP-BGP? :) Услуги-то какие предоставляться будут?

Разговаривать будет с ДИС свичами , с ДИС свичей будет выполнчться импорт в MP-BGP далее через коре свич на соотвествующий порт другого дис свича ну и экспорт в соотвествующий VRF (я не сталкивался с этой технологией но прочитав пару стаей заинтересовало, может что то не допонял поправьте)

Услуги в основном подключение филиалов банков и других организаций а так же трансмиссию для разного рода услуг например банкоматы, ну и интернет

 

А зачем VRF lite? Клиенты требуют l3 vpn? Чем l2 не устраивает?

Ну и про mp-bgp тоже не ясно - для чего.

Клиенты не требуют просто иногда приходиться учавствовать в машрутизации внутреннего траффика клиента и сталкиваешься с оверлапом адрессов разных клиентов.

MP-BGP нужен для адверсации маршрутов одного клиента через ядро провайдера в формаие ipv4 т е айпи адресс плюс RD.

 

Изменено 18 сентября, 2010 пользователем psygex

[nnm]

Разговаривать будет с ДИС свичами , с ДИС свичей будет выполнчться импорт в MP-BGP далее через коре свич на соотвествующий порт другого дис свича ну и экспорт в соотвествующий VRF (я не сталкивался с этой технологией но прочитав пару стаей заинтересовало, может что то не допонял поправьте)

То, что Вы описываете, называется L3 MPLS VPN. Для того, чтобы это заработало, ДИС должны быть полноценными MPLS PE маршрутизаторами. 3550 этого не умеет.

Делайте так, как сказал mschedrin. Давайте каждому абоненту отдельный VLAN и коммутируйте в ней его трафик на втором уровне. При этом адреса, которые абонент использует в этом VLAN, Вас волновать не будет.

Есть второй вариант - поднять VRF-light на 3750, который встанет в качестве core, и таки маршрутизировать на нем трафик между сайтами абонентов. Конфигурировать сложнее, чем чистый L2 вариант, но если перерастете возможности одного коммутатора в core и решитесь на MPLS, то переход пройдет менее болезненно.

Изменено 18 сентября, 2010 пользователем nnm

[s.lobanov]

Не делайте L2 между точками клиентов(через обычные вланы) - это значит превратить сеть в помойку, сделать её не масштабируемой, трудномодифицируемой, это будет не сеть, а кучка коммутаторов c кучей вланов на каждом и непонятно как диагностировать проблемы когда клиент пожалуется, что из точки А не пингается точка Б.

 

Дейлайте так:

Есть второй вариант - поднять VRF-light на 3750, который встанет в качестве core, и таки маршрутизировать на нем трафик между сайтами абонентов. Конфигурировать сложнее, чем чистый L2 вариант, но если перерастете возможности одного коммутатора в core и решитесь на MPLS, то переход пройдет менее болезненно.

Проще говоря vrf на клиента, IP-сеть на точку включения. А уж с mpls или без него это время покажет

Изменено 18 сентября, 2010 пользователем s.lobanov

[mschedrin]

s.lobanov

Траблшутить L3 легче чем L2? Почему вы так считаете?

[nnm]

Мне тоже кажется, что у L3 есть некоторые преимущества. Но в предлагаемой схеме у него есть и существенный недостаток. Это малое число VRF на мелких коробках. На 3550 кажется 7 или 8, на 3750 - 26. И при включении VRF перестают работать PBR, PVLAN и что-то еще...

[s.lobanov]

s.lobanov

Траблшутить L3 легче чем L2? Почему вы так считаете?

Потому что можно быстро определить участок сети на котором возникла проблема, зарезается мусор на L3-интерфейсах. А в L2 мы что видим? Да ничего, только приходит мак или не приходит.

 

Вот например пожаловался клиент, что с IP адреса xx.xx.xx.xx не пингается yy.yy.yy.yy и что вы будете делать?(без дополнительной информации от клиента вы ещё поищите на каком оборудовании доступа надо смотреть)

Если сеть L3, то просто ищите на каком интерфейс-влане/сабинтерфейсе терминируются сети, смотрите куда уходят вланы, быстренько находите узел доступа(там смотрите линк, ошибки, прочие счётчики), делаете пинги от шлюза до хоста, между шлюзами, начинаете понимать - проблема у вас или у абонента.

 

Но ведь дело не только в траблшутинге, но ещё и в масштабируемости и документируемости.

Изменено 18 сентября, 2010 пользователем s.lobanov

[DelSt]

Вот например пожаловался клиент, что с IP адреса xx.xx.xx.xx не пингается yy.yy.yy.yy и что вы будете делать?(без дополнительной информации от клиента вы ещё поищите на каком оборудовании доступа надо смотреть)

У клиента нельзя запросить физические точки концов? А потом по документам посмотеть точки подключения.

 

делаете пинги от шлюза до хоста, между шлюзами, начинаете понимать - проблема у вас или у абонента.

Можно у клиента спросить адрес сети, которая живет в VPN'е, прописать на L3-девайсе IP из его диапазона и также попингать.

 

Но ведь дело не только в траблшутинге, но ещё и в масштабируемости и документируемости.

Причем тут L2/L3 и документируемость? Нормально документируются оба типа VPN'ов!

Масштабируемость? Тут согласен, но опять же, можно избавить ядро от кучи VLAN с помощью xconnect'ов и VFI

 

Я не фанат L2 VPN'а, я лишь хочу сказать что надо предоставлять обе услуги. Одним клиентам больше подойдет L2 VPN, другим L3 VPN!

[s.lobanov]

>У клиента нельзя запросить физические точки концов? А потом по документам посмотеть точки подключения.

 

зависит от клиента. их админ не всегда знает где физически находится банкомат(или какая-нибудь другая хрень) с номером 6789, в любом случае это лишние затраты времени как клиенту, так и провайдеру(копаться в документах, договорах, схемах и прочем).

 

>Можно у клиента спросить адрес сети, которая живет в VPN'е, прописать на L3-девайсе IP из его диапазона и также попингать.

 

вот как раз этого ответа я и ожидал. Т.е. ради диагностики нужно создавать интефейс-влан(при этом, вообще говоря, надо согласовывать ip этого интерфейса с клиентом, чтоб не захватить что-нибудь важное из его адресного пространства), потом пингать, потом убирать этот интерфейс-влан

 

>Причем тут L2/L3 и документируемость?

L3 в некотором смысле самодокументируемый, т.е. можно смотреть что откуда приходит, где что терминируется, в крайнем случае погрепать бэкапы конфигов, если вдруг какая-то сетка не приходит. L2 надо документировать целиком и полностью.

 

>Я не фанат L2 VPN'а, я лишь хочу сказать что надо предоставлять обе услуги. Одним клиентам больше подойдет L2 VPN, другим L3 VPN!

 

Да не нужен банкам и предприятиям L2VPN, им нужна сетка из их адресного пространства в точке подключения. L2VPN предоставлять только в крайних случаях и желательно всё-таки не тупым добавлением влана во все подряд транки, а так как Вы описали(с помощью vfi)

[DelSt]

зависит от клиента. их админ не всегда знает где физически находится банкомат(или какая-нибудь другая хрень) с номером 6789, в любом случае это лишние затраты времени как клиенту, так и провайдеру(копаться в документах, договорах, схемах и прочем).

Копаться? Это снова к вопросу о правильной документированности сети!

В моих договорах имеется идентификатор L2VPN и идентификатор PORT VPN, поэтому таких проблем лично у меня нет.

 

вот как раз этого ответа я и ожидал. Т.е. ради диагностики нужно создавать интефейс-влан(при этом, вообще говоря, надо согласовывать ip этого интерфейса с клиентом, чтоб не захватить что-нибудь важное из его адресного пространства), потом пингать, потом убирать этот интерфейс-влан

Я работал с nortel metro ethernet, так там канал точка-точка можно настроить в режиме point-to-point и тогда даже mac learning нигде не происходит. И в случае необходимости попингать приходилось переводить канал в режим any-to-any и добавлять один "конец" до любого L3-девайса.Вот это веселуха :)

 

L3 в некотором смысле самодокументируемый, т.е. можно смотреть что откуда приходит, где что терминируется, в крайнем случае погрепать бэкапы конфигов, если вдруг какая-то сетка не приходит. L2 надо документировать целиком и полностью.

Самодокументируемый? А если у тебя 10+ PE?

 

Да не нужен банкам и предприятиям L2VPN, им нужна сетка из их адресного пространства в точке подключения. L2VPN предоставлять только в крайних случаях и желательно всё-таки не тупым добавлением влана во все подряд транки, а так как Вы описали(с помощью vfi)

Лично я не знаю что нужно моим клиентам и позволяю самим выбирать что им нужно. Конечно же иногда позволяя себе дать некоторые рекомендации клиенту. Но у меня правда у многих клиентов покупающих VPLS всего 2-4 конца.

[mschedrin]

Забыли еще про резервирование по L2 - с ним часто сложнее и менее оптимально.

Зато оборудование для l2vpn стоит значительно дешевле.

[Konstantin Klimchev]

Значит имеем следующую небольшую сеть metro ethernet

 

Нужно решение для разделения траффика клиентов , клиенты в основном банки (подключение филиалов, банкоматов и т д)

DIS свичи это каталисты 3550 и 3560 , Core SW тоже 3550 но планируеться заменить на гигабитный свич с оптическими портами.

На данный момент склоняюсь к такому варианту. На DIS свичах поднимаеться для каждого клиента VRF-lite а на коре свиче MP-BGP для передачи данных

В общем...

Тут есть негатив про L2 из оперы "Пастернака не читал, но осуждаю"...

Ваша проблема очень хорошо накладывается на vlan. На uni-интерфейсе чуть подрежете только (port-security, storm-control'ы всякие и т.п.), только в договоре не забудьте это отметить. dscp абонентское не переписывайте, а сделайте перемаркировку в cos для своего внутреннего прохождения (это еще и продать можно). У вас же юрики намечаются - им clear канал нужен будет, да и манагерам vlan на порядок проще продать (никаких согласований ip для статики для l3VPN или ваще казырного улета о rip или bgp... мы же помним про их ущербность, я про манагеров... :) ). Как тупого vlan перестанет хватать, переедете на VPLS, к тому времени у вас хватит на что-то из оперы цисковских ES-карт.

 

ЗЫ. сеть VPLSовская (но это нормальный l2 через MPLS, если сильно упрощено) - все шоколадно. И объединения офисов и последние мили для магистралов.

Изменено 19 сентября, 2010 пользователем Konstantin Klimchev

[psygex]

Разговаривать будет с ДИС свичами , с ДИС свичей будет выполнчться импорт в MP-BGP далее через коре свич на соотвествующий порт другого дис свича ну и экспорт в соотвествующий VRF (я не сталкивался с этой технологией но прочитав пару стаей заинтересовало, может что то не допонял поправьте)

То, что Вы описываете, называется L3 MPLS VPN. Для того, чтобы это заработало, ДИС должны быть полноценными MPLS PE маршрутизаторами. 3550 этого не умеет.

Делайте так, как сказал mschedrin. Давайте каждому абоненту отдельный VLAN и коммутируйте в ней его трафик на втором уровне. При этом адреса, которые абонент использует в этом VLAN, Вас волновать не будет.

Есть второй вариант - поднять VRF-light на 3750, который встанет в качестве core, и таки маршрутизировать на нем трафик между сайтами абонентов. Конфигурировать сложнее, чем чистый L2 вариант, но если перерастете возможности одного коммутатора в core и решитесь на MPLS, то переход пройдет менее болезненно.

То что я описал можно и без мплса поднять тут об этом расказывается

На счет второго варианта не совсем понятно если врф лайт поднят на коре свиче то как добавлять порты на ДИС свичах в тот или иной врф ? Учитываю что коре с дис свичани связан транками

Изменено 20 сентября, 2010 пользователем psygex

[nnm]

То что я описал можно и без мплса поднять тут об этом расказывается

Это, как явствует из названия, VRF-light. Он на коммутаторах работает. Эта технология сама по себе не предполагает применения MP-BGP. MP-BGP - на MPLS PE. Хотите MP-BGP - ставьте PE.

 

На счет второго варианта не совсем понятно если врф лайт поднят на коре свиче то как добавлять порты на ДИС свичах в тот или иной врф ? Учитываю что коре с дис свичани связан транками

Для каждого сайта абонента выделяете уникальный VLAN. Этот VLAN создается на 'своем' ДИС и на core. ДИС это VLAN коммутирует в транк, 'смотрящий' на Core. На Core конфигурируется SVI, в котором VLAN терминируется. SVI помещается в нужный VRF.

 

[psygex]

То что я описал можно и без мплса поднять тут об этом расказывается

Это, как явствует из названия, VRF-light. Он на коммутаторах работает. Эта технология сама по себе не предполагает применения MP-BGP. MP-BGP - на MPLS PE. Хотите MP-BGP - ставьте PE.

 

На счет второго варианта не совсем понятно если врф лайт поднят на коре свиче то как добавлять порты на ДИС свичах в тот или иной врф ? Учитываю что коре с дис свичани связан транками

Для каждого сайта абонента выделяете уникальный VLAN. Этот VLAN создается на 'своем' ДИС и на core. ДИС это VLAN коммутирует в транк, 'смотрящий' на Core. На Core конфигурируется SVI, в котором VLAN терминируется. SVI помещается в нужный VRF.

А каким образом давать клиентам Интернет или другие сервисы, к примеру все банкоматы должны иметь возможность поднимать VPN тоннель с сервером который находиться в влане общий для всех клиентов (т е SVI интерфейс которого находиться в глобальной таблице маршрутизации) ?

При таком раскладе вместо дис свичей можно использовать L2 свичи я правильно понимаю ?

[psygex]

То что я описал можно и без мплса поднять тут об этом расказывается

Это, как явствует из названия, VRF-light. Он на коммутаторах работает. Эта технология сама по себе не предполагает применения MP-BGP. MP-BGP - на MPLS PE. Хотите MP-BGP - ставьте PE.

 

На счет второго варианта не совсем понятно если врф лайт поднят на коре свиче то как добавлять порты на ДИС свичах в тот или иной врф ? Учитываю что коре с дис свичани связан транками

Для каждого сайта абонента выделяете уникальный VLAN. Этот VLAN создается на 'своем' ДИС и на core. ДИС это VLAN коммутирует в транк, 'смотрящий' на Core. На Core конфигурируется SVI, в котором VLAN терминируется. SVI помещается в нужный VRF.

А каким образом давать клиентам Интернет или другие сервисы, к примеру все банкоматы должны иметь возможность поднимать VPN тоннель с сервером который находиться в влане общий для всех клиентов (т е SVI интерфейс которого находиться в глобальной таблице маршрутизации) ?

При таком раскладе вместо дис свичей можно использовать L2 свичи я правильно понимаю ?

У кого какие соображения по этому поводу ?

[nnm]

А каким образом давать клиентам Интернет или другие сервисы, к примеру все банкоматы должны иметь возможность поднимать VPN тоннель с сервером который находиться в влане общий для всех клиентов (т е SVI интерфейс которого находиться в глобальной таблице маршрутизации) ?

Банкомат сам способен поднять криптованный тонель? Клиент готов поставить на банкомат публичный адрес? Включайте в интернет.

Клиент не хочет ставить на банкомате публичку? Тогда и банкомат и сервер, к которому он ходит в VPN.

Если очень хочется странного можно сделать маршрутизацию между VRF и GRT через петлевой интерфейс. :) Только это тааакой костыль.

 

При таком раскладе вместо дис свичей можно использовать L2 свичи я правильно понимаю ?

Ага.

Изменено 21 сентября, 2010 пользователем nnm

[psygex]

А каким образом давать клиентам Интернет или другие сервисы, к примеру все банкоматы должны иметь возможность поднимать VPN тоннель с сервером который находиться в влане общий для всех клиентов (т е SVI интерфейс которого находиться в глобальной таблице маршрутизации) ?

Банкомат сам способен поднять криптованный тонель? Клиент готов поставить на банкомат публичный адрес? Включайте в интернет.

Клиент не хочет ставить на банкомате публичку? Тогда и банкомат и сервер, к которому он ходит в VPN.

Если очень хочется странного можно сделать маршрутизацию между VRF и GRT через петлевой интерфейс. :) Только это тааакой костыль.

 

При таком раскладе вместо дис свичей можно использовать L2 свичи я правильно понимаю ?

Ага.

 

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

Тут предлогается довольно простой метод с редистрибуцией в MP-BGP без мплса . Думаю так и сделать тока вот проблема в том что серия 3500 поддерживает до 8 VRF.

[nnm]

Тут предлогается довольно простой метод с редистрибуцией в MP-BGP без мплса . Думаю так и сделать тока вот проблема в том что серия 3500 поддерживает до 8 VRF.

Да, между VRF так сделать можно. Учтите, что при этом внутренние адреса сети абонента улетят в общий VRF. Если они не уникальны - будет плохо.