[Sergey_Taurus]

Здравствуйте, коллеги.

 

В продолжении темы начатой здесь

 

Текущая топология сети представлена ниже.

 

Текущая сеть образована коммутаторами L2. Core Switch подключен к Distribution Switch’ам по оптике (SFP или GBIC, 1000BASE-LX). Access Switch’и подключены к Distribution Switch’ам через медиаконвертеры (100BASE-FX).

 

На ядре сети имеется концентратор доступа (PPPoE BRAS), на который по принципу “один VLAN на Distribution Switch” вынесена авторизация физических абонентов. BRAS подключен 802.1q транком к Core Switch и принимает для авторизации количество VLAN, которое соответствует количеству Distribution Switch’ей.

 

На уровне доступа абоненты изолированы друг от друга на L2 (ProtectedVLAN, PrivateVLAN, AsynVLAN) и имеют возможность обмена трафиком только через Distribution Switch. На Distribution Switch все приходящие соединения с Access Switch’ей также изолированы друг от друга на L2 (ProtectedVLAN, PrivateVLAN, AsynVLAN) и разрешен трафик только на оптическую магистраль. В итоге, конкретно взятый абонент имеет возможность получения услуг только после PPPoE авторизации. Неавторизованный абонент доступа ни к каким услугам не имеет.

 

Также существует ряд абонентов (юридических лиц), которым предоставляются отдельные выделенные VLAN’ы без выхода в общую сеть или Интернет. Клиентам работающим по данной схеме выдается персональный VLAN, который проходит 802.1q транками через всю сеть: через Access Switch’и, все Distribution Switch’и и Core Switch.

 

В настоящее время возникла проблема с PPPoE авторизацией и выделенными VLANами. Путем титанических усилий было установлено, что по непонятным причинам по магистрали некорректно распространяется MAC информация. Например, в рамках одного Distribution Switch MAC'и от всех Access Switch’ей есть, MAC'и от абонентов подлкючающихся по PPPoE есть, MAC'и от абонентов которым дается выделенный VLAN тоже есть, а вот на соседнем Distribution Switch их уже нет, или есть через раз, или то есть, то нет. Ну говоря уже о других Distribution Switch, находящиеся в удалении 2-3 от рассматриваемого. Все это приводит к тому, что соединения по PPPoE у юзеров самопроизвольно рвутся (два PPPoE BRAS не загружены даже на половину, так что проблема вроде как не в них) по таймауту (PPPoE BRAS пишет что Echo за 3х20секунд период он не получил и поэтому соединение дропается), Access Switch тоже выпадают из мониторингов и прочего, абоненты на выделенных VLANах жалуются, что у них какие-то точки (размазанные по всей сети) работают, а какие-то нет, какие-то через раз. В общем, ситуация неприятная. Вендору уже задолбался слать дебаги и MAC таблицы. Пока четкого понимания что же делать дальше нет, поддержка вендора что-то советует\спрашивает, но света в конце туннеля не видно.

 

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

 

От устанавливаемого оборудования мы ожидаем:

 

На физическом уровне:

- Core Switch: минимум 4xSFP 1000BASE-LX (как вариант Combo), + минимум 24х1000BASE-TX. Опционально 2xXFP.

- Distribution Switch: минимум 2хSFP или 2xGBIC + минимум 24x100BASETX ИЛИ 24x100BASE-FX (SC connector). Опционально 2xXFP.

 

На логическом уровне:

 

1) Сохранение схемы при которой неавторизованный по PPPoE абонент не получает доступа ни к каким сервисам: не имеет возможность обмена L2 траффиком между клиентами, подключенными да разные Access Switch’и в рамках как одного и того же Distribution Switch, так и различных Distribution Switch. Т.е. схема “один VLAN на Distribution Switch” с вынесением этого VLAN на PPPoE BRAS для авторизации. Модель PPPoE BRAS во внимание не принимаем: это может быть как аппаратное решение, так и soft-based решение на UNIX\Linux\BSD системе.

2) Сохранение возможности предоставления VLAN для отдельных абонентов. Количество VLAN (с учетом VLAN для выноса авторизации с Distribution Switch’ей) – не менее 128.

3) Сходимость сети в Ethernet-кольце c временем меньшим чем сходимость при использовании STP\RSTP. Обеспечение предотвращения Switching Loop в нормальном режиме работы (кольцо) и гарантированная работа в аварийном режиме, когда кольцевая топология нарушена. Возврат в нормальный режим (кольцо) при устранении повреждения на магистрали. Минимальное количество устройств в магистральном кольце – 20. В принципе, возможен пересмотр физической топологии в сторону реализации нескольких «лепестков» и уменьшения количества устройств в каждом получившемся кольце.

4) Возможность внедрения в будущем (разумеется при условии замены оборудования доступа на тоже на что-то другое) услуг стандарта MetroEthernet: VLAN на абонента, VLAN на сервис, динамическое создание VLAN при авторизации абонента на магистральном оборудовании. Таким образом я так понимаю необходима поддержка Q-in-Q (или даже дополнительно MAC-in-MAC для клиентов, которым предоставляется выделенный VLAN, в котором может быть большое количество устройств), Cos, QoS.

5) Обеспечение гарантированной работы нескольких сотен VLAN (часть для выноса вторизации на PPPoE BRAS, часть для выделенных абонентов), в каждой из которых может быть большое количество MAC адресов. Т.е. от магистрального оборудования нужен либо достаточный для этого размер MAC таблиц, либо использование какой либо технологии для уменьшения его размера (к примеру MAC-in-MAC).

6) (Очень-очень опционально) Поддержка MPLS с возможностью организации VLAN для всех вышеуказанных целей не традиционными L2 технологиями, а с помощью функциональности MPLS.

7) Возможность варианта с использванием 2-x Core Switch для резервирования отказов. Поддержка протокола VRRP или ему подобного.

 

Спасибо всем, кто дочитал до конца.

 

Хотелось бы услышать советы что конкретно можно поставить (с указанием моделей), чтобы все стало на свои места.

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

 

Заранее спасибо за ответы.

Изменено 5 декабря, 2008 пользователем Sergey_Taurus

[White_Alex]

Как причину Ваших трудностей могу предположить с высокой долей вероятности, что в сети просто переполняются TCAM на коммутаторах

насчет модернизации, как вариант приведу пример, на чем сделано все у нас:

 

bras - Cisco 10k8

core - Cisco 76xx + ES20 (между железками 10G MPLS с широким применением H-VPLS для организации bridge доменов)

distribution - цепочки Cisco 3560 (разными концами к разным узлам ядра)

access - D-Link 3526 ну и 3010 там, где надо совсем мало портов без какого-либо роста в будущем

 

собственно все Вами описаные задачи реализованы

 

зыж ценник на все это не детский, ну да не об этом вроде топик

[Sergey_Taurus]

Как причину Ваших трудностей могу предположить с высокой долей вероятности, что в сети просто переполняются TCAM на коммутаторах

Тоже первым делом на это подумал, но:

 

В даташите на AT-8824:

MAC addresses 8K

Реально:

sh swi sw=arl

ARL Table: 719/(1-8191) entries

 

Таким образом, текущего железа с его заявленными 8к адресов для Distribution и 16к для Core "на бумаге" должно хватать. Но по непонятной причине наблюдаются описанные непонятности. Плюс к этому совершенно кошмарно реализован просмотр CAM: никакой фильтрации по VLAN или порту, просто все куском. Даже на более младших моделях вендора (АТ-8024 или АТ-8524) и то более менее просто что-то искать чем на АТ-8824 и АТ-9924Т

 

насчет модернизации, как вариант приведу пример, на чем сделано все у нас:

 

bras - Cisco 10k8

core - Cisco 76xx + ES20 (между железками 10G MPLS с широким применением H-VPLS для организации bridge доменов)

distribution - цепочки Cisco 3560 (разными концами к разным узлам ядра)

access - D-Link 3526 ну и 3010 там, где надо совсем мало портов без какого-либо роста в будущем

 

собственно все Вами описаные задачи реализованы

 

зыж ценник на все это не детский, ну да не об этом вроде топик

Спасибо за пример.

 

Маленький вопрос (по причине нулевого опыта с MPLS и его технологиями создания виртуальных частных сетей):

насколько я понимаю, MPLS только в Core? Если допустим где то в сети есть клиент, которому нужна VLAN, то до ядра

его как вытащить? Тем же 802.1q? Или я несовсем понимаю технологию? Если можно пояснить, в пару словах или ссылкой. Спасибо.

 

Насчет ценников не так все радужно. И скорее всего, ничего на MPLS не светит...

Нужно разумными затратами привести все в более-менее нормальное состояние, хотя бы через нормальный стабильный 802.1q и Q-in-Q. Тем более, что судя по примерам строительства сетей с "тупым" доступом и дистрибьюцией, в которых максимум бегают VLANы и стоит центральный BRAS на PPPoE - есть. Почему не работает в нашем варианте - непонятно.

Изменено 5 декабря, 2008 пользователем Sergey_Taurus

[White_Alex]

вопрос-то немаленький на самом деле

да, MPLS только в ядре

Рекомендую почитать про функционал карт ES-20, именно они выполняют всю основную работу по манипуляции 802.1Q тегами, обеспечивая правильную работу всей системы, Q-in-Q на данный момент в уровне агрегации нет (исключение будет только если появится какой-нить клиент, пожелающий собственные VLANы гонять между арендованными портами, у нас в провинции таких пока не наблюдается, но реализация данных клиентских хотелок абсолютно не проблема)

[Sergey_Taurus]

вопрос-то немаленький на самом деле

да, MPLS только в ядре

Рекомендую почитать про функционал карт ES-20, именно они выполняют всю основную работу по манипуляции 802.1Q тегами, обеспечивая правильную работу всей системы, Q-in-Q на данный момент в уровне агрегации нет (исключение будет только если появится какой-нить клиент, пожелающий собственные VLANы гонять между арендованными портами, у нас в провинции таких пока не наблюдается, но реализация данных клиентских хотелок абсолютно не проблема)

Почитал в целом про EVC основанном на PsevdoWire. В целом идея понятна. E-Line или BridgeDomain "вытягивается" с уровня доступа через дистрибьюцию на ядро и далее на соответввующий BRAS где потом с ним что-то делается. Таким образом, PW и есть та обертка, которая вытаскивает абонентский порт или сервис на BRAS или делает те самые виртуальные частные сети. Но, для всего этого нужно чтобы как минимум на дистрибьюции везде стояли кошки, которые все это понимают и будут делать. И судя по всему, между D-Link'и которые у Вас стоят на доступе и 3560 уже бегают простые вещи типа нетегированного или тегированного Ethernet (или Q-in-Q при необходимости), а уже на 3560 все чудеса и начинаются. А сами магистраль ядро-дистрибьюция соответсвенно исключительно L3. Я все верно понял?

 

[Sergey_Taurus]

Коллеги, вопрос остается открытым.

 

MPLS и кошки это все хорошо, но денег на это похоже нет.

 

Остается старая схема с VLAN'ами как они есть. У кого что-то подобное работает (VLAN'ы в чистом виде для юриков и "выноса" физиков на PPPoE BRAS)? На чем работаете?

Изменено 5 декабря, 2008 пользователем Sergey_Taurus

[sorain]

Коллеги, вопрос остается открытым.

 

MPLS и кошки это все хорошо, но денег на это похоже нет.

 

Остается старая схема с VLAN'ами как они есть. У кого что-то подобное работает (VLAN'ы в чистом виде для юриков и "выноса" физиков на PPPoE BRAS)? На чем работаете?

можно кошки, но без mpls

меняете core свич на 3560 и aggr. свичи на me24хх и радуетесь жизни

получаете то же, что у Вас, но на другом железе.

цены по GPL

WS-C3560G-24TS-E Catalyst 3560 24 10/100/1000T + 4 SFP + IPS Image 8790

ME-3400-24TS-D Cisco ME 3400 Switch - 24 10/100 + 2 SFP, DC PS 2495

ME-3400-24FS-A Cisco ME 3400 Switch - 24FX SFP + 2 SFP, AC 2495

 

 

 

 

[White_Alex]

Уже тогда лучше 3750-е каталисты ставить, из-за стека, опять же агрегационные цепочки разными концами в разные коммутаторы в стеке заводить, устойчивее к сбоям получится

[sorain]

советовал исходят из требования:

Core Switch: минимум 4xSFP 1000BASE-LX (как вариант Combo), + минимум 24х1000BASE-TX

 

судя по топологии лепестков не предусмотрено,

так что стеком только саму железку задублируете.

 

 

[White_Alex]

кто-то из местных гуру уже озвучвал про шину в 3560, 3750, оно вроде как 32Гбпс полудуплексом, т.е. на ядро 24 гиговых порта - потенциально блокировка вырастает:-)

[Bambuk]

Sergey_Taurus, ваши проблемы очень похожи на то, что от клиентов приходят пакеты с маками брасов. Как вы защищаетесь от мак-спуфинга?

[Sergey_Taurus]

Sergey_Taurus, ваши проблемы очень похожи на то, что от клиентов приходят пакеты с маками брасов. Как вы защищаетесь от мак-спуфинга?

Было бы очень похоже, но это не объясняет проблем в выделенных клиентских VLAN и того факта, как я уже говорил в первом посте, что наблюдается ситуация, когда в рамках одного Distribution Switch на нём MAC'и от всех Access Switch’ей есть и все Access Switch’и пингуются и телнетятся, MAC'и от абонентов подлкючающихся по PPPoE есть, MAC'и от абонентов которым дается выделенный VLAN тоже есть, а вот на соседнем Distribution Switch их уже нет, или есть через раз, или то есть, то нет. Не говоря уже о других Distribution Switch, находящиеся в удалении 2-3 от рассматриваемого.

 

Разумеется, защиту от спуфинга надо делать, но привязывать абонентов к портам по МАКам очень бы не хотелось. Единственное что можно попробовать сделать (но это опять же просто на будущее, т.к. на мой взгляд к проблеме с текущими непонятностями на L2, например в выделенных клиентских VLAN, это никак не относится), так это статическим ARP' ом на AccessSwitch'ах привязать МАКи BRAS'ов к аплинкам, чтобы со стороны абонентских портов не было возможности их спуфить.

 

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

 

Коллеги, еще будут какие-нибудь варианты\вендоры кроме кошек - кандидаты на магистральное оборудование? Huawei\Juniper например. D-Link отсоветовали, его только на доступ. Или все-таки общая тенденция - это двигаться к цисковским магистральным решениям с\без MPLS с чем-то попроще на доступе?

Изменено 8 декабря, 2008 пользователем Sergey_Taurus

[Nag]

Коллеги, еще будут какие-нибудь варианты\вендоры кроме кошек

Сильно зависит от того, на сколько грамотные спецы у вас.

С сиской разбираться НАМНОГО проще - просто потому что она "у всех".

 

[Sergey_Taurus]

Коллеги, еще будут какие-нибудь варианты\вендоры кроме кошек

Сильно зависит от того, на сколько грамотные спецы у вас.

С сиской разбираться НАМНОГО проще - просто потому что она "у всех".

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

 

Также на мой взгляд плюсом в варианте с кошками является возможность (при наличии в будущем средств) получить нормальное 100% MPLS-совместимое MetroEthernet операторское решение без замены магистрального оборудования. Т.е. как здесь посоветовали, первоначально использовать схему без MPLS, а в дальнейшем если будут возможности и необходимости - внедрить MPLS. Остается только правильно выбрать кошек...

 

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

 

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

Изменено 8 декабря, 2008 пользователем Sergey_Taurus

[Bambuk]

Посмотрите на Huawei S85XX, они же H3C S95XX. Если портов много не надо, то можно взять 2 или 5 слотовое шасси. С вашими конфигурациями Core и Distribution это будет порядка $50K за железку. На кольцевых топологиях L2 с большим количеством узлов там есть RRPP с sub50ms сходимостью и оно работает. Есть MPLS: L3VPN, L2VPN VLL поддерживается самими линейными платами, а для VPLS потребуется отдельная плата. Но как L3 и эджевые железки я их рассматривать не рекомендую, а вот как транспорт они работают хорошо.

[Мартен]

"купи глючное L3 за $50k."

мда.

уж лучше б/у шеститонники.

[Stak]

Просьба не считать некропостером, но мои три копейки про H3C S95XX: "Есть MPLS: L3VPN, L2VPN VLL поддерживается самими линейными платами" - это не совсем так. У них на обычных лан-картах это НЕ поддерживается. Нужны специфические, в полтора раза дороже, с определёнными буковками в обозначении. Причём все упоминания об этом упрятаны поглубже в дебри документации)))

[ugluck]

дешовый цыскин почти-MPLS-свич 3750-metro