[tehmeh]

А как d-link взаимодействует с pvstp? И почему, кстати, не rapid-pvst раз уж на то пошло?

[darkagent]

длинк не умеет pvst ни в каком виде. mstp в длинке настолько "забавное", что хочется начать убивать.

[EShirokiy]

tehmeh, mstp в dlink. Как я понял из описания, основан на rstp и работает с vlan.

[EShirokiy]

darkagent, я понял, значит проще поставить что нибудь l3 и уже через l3 организовать колечки?

[tehmeh]

И вы пытаетесь подружить MST на d-link вместе с Cisco PVST? Я не уверен, что они совместимы даже в рамках одного вендора (в данном случае Cisco).

[EShirokiy]

tehmeh, прошу прощения, что ввел вас в заблуждение, речь шла исключительно про mstp, перепутал название

[tehmeh]

Теоретически схема рабочая даже на L2. Но лучше конечно L3 делать, соглашусь с предыдущими ораторами. Да и не факт, что d-link с cisco подружатся в этом плане.

[SyJet]

ребята, на пальцах поясните.

Как на l3 колечки организовывать в схеме когда влан на пользователя и все терминируеются на агрегации (cat6500) и ipoe?

На пальцах поясните.

[NikAlexAn]

ребята, на пальцах поясните.

Как на l3 колечки организовывать в схеме когда влан на пользователя и все терминируеются на агрегации (cat6500) и ipoe?

На пальцах поясните.

У вас ядро и агрегация совмещены , так что это не ваш случай.

[Abram]

Тогда уж мне на пальцах объясните - влан на пользователя, все запаковываются в qinq на агрегации и отправляются в ядро. Нужно на агрегации кроме qinq еще в mpls запаковывать?

[NikAlexAn]

Тогда уж мне на пальцах объясните - влан на пользователя, все запаковываются в qinq на агрегации и отправляются в ядро. Нужно на агрегации кроме qinq еще в mpls запаковывать?

А от агрегации до ядра сколько путей? На этих уровнях есть оборудование поддерживающее mpls/vpls?

[g3fox]

Подскажите как быть в такой ситуации

 

Хочу соединить прокинуть линк между 3 и 6 райоными и зарулить все в STP что бы была отказоустойчивость. Реально это? Или все таки смотреть в сторону докладки волокон?

 

На мой взгляд все решения в mpls/vpls - из пушки по воробьям.

А нет возможности просто проварить линк от "район 6" а "аггрегация 2" ?

[FATHER_FBI]

Подскажите как быть в такой ситуации

 

Хочу соединить прокинуть линк между 3 и 6 райоными и зарулить все в STP что бы была отказоустойчивость. Реально это? Или все таки смотреть в сторону докладки волокон?

 

На мой взгляд все решения в mpls/vpls - из пушки по воробьям.

А нет возможности просто проварить линк от "район 6" а "аггрегация 2" ?

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

[g3fox]

Почему не будет? От порыва кабеля защита как раз будет, а вот от выхода из строя узла "аггрегация 2" не будет.

Смотрите картинку во вложении.

Зелёные и синие - волокна, прямоугольники - р-ны, которые работают на этих волокнах. Соответственно зелёное волокно через синий район просто проваривается.

[tehmeh]

Тогда уж мне на пальцах объясните - влан на пользователя, все запаковываются в qinq на агрегации и отправляются в ядро. Нужно на агрегации кроме qinq еще в mpls запаковывать?

А от агрегации до ядра сколько путей? На этих уровнях есть оборудование поддерживающее mpls/vpls?

Отвечу вместо пропавшего Abram, если есть несколько путей, например, прямые линки от агрегации до ядра, и линки между агрегацией. Там соответственно L3 кольца, но вот как гонять Q-in-Q до ядра между агрегацией в случае отвала основного линка? Ядро на 7609, я так понимаю надо туда ES плату и VPLS(l2-circuit)?

[Saab95]

Отвечу вместо пропавшего Abram, если есть несколько путей, например, прямые линки от агрегации до ядра, и линки между агрегацией. Там соответственно L3 кольца, но вот как гонять Q-in-Q до ядра между агрегацией в случае отвала основного линка? Ядро на 7609, я так понимаю надо туда ES плату и VPLS(l2-circuit)?

 

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

[tehmeh]

Отвечу вместо пропавшего Abram, если есть несколько путей, например, прямые линки от агрегации до ядра, и линки между агрегацией. Там соответственно L3 кольца, но вот как гонять Q-in-Q до ядра между агрегацией в случае отвала основного линка? Ядро на 7609, я так понимаю надо туда ES плату и VPLS(l2-circuit)?

 

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

 

Не совсем понимаю, как вы совмещаете понятия L2/L3 с СКС и скоростью? Что мешает мне на существующей физической топологии реализовывать схемы L2-connected или L3-connected? Сейчас у нас как раз авторизация вынесена на агрегацию. Нас такая схема не устраивает по многим причинам, одна из которых – не резиновый пул адресов.

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

[Saab95]

Не совсем понимаю, как вы совмещаете понятия L2/L3 с СКС и скоростью? Что мешает мне на существующей физической топологии реализовывать схемы L2-connected или L3-connected? Сейчас у нас как раз авторизация вынесена на агрегацию. Нас такая схема не устраивает по многим причинам, одна из которых – не резиновый пул адресов.

 

Пул адресов не зависит от того, где авторизация - в центре или на промежуточной агрегации, если IP адреса выдаются поштучно абонентам. L3-connected всегда лучше, потому что можно абонентский локальный трафик гонять помимо ядра сети.

 

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

 

Имелось в виду, что нельзя бесконечно стягивать волокна в центр, пусть там хоть 10G ходит. Поэтому промежуточные узлы агрегации необходимы.

[tehmeh]

Пул адресов не зависит от того, где авторизация - в центре или на промежуточной агрегации, если IP адреса выдаются поштучно абонентам. L3-connected всегда лучше, потому что можно абонентский локальный трафик гонять помимо ядра сети.

Не знаю, как он у кого не зависит, я вижу это примерно так: либо он у тебя в одном месте, либо раскидан по сети, а это где-то недобор, где-то перебор, начинается жонглирование. Гонять трафик мимо ядра не всегда комильфо.

 

Имелось в виду, что нельзя бесконечно стягивать волокна в центр, пусть там хоть 10G ходит. Поэтому промежуточные узлы агрегации необходимы.

 

Конечно необходимы, больше того скажу – их есть у меня.

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

[alibek]

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

Просто VLAN это устаревшая технология.

Поэтому микротиководы умеют только все засунуть в бридж и подать наверх по отдельному волокну.

[Saab95]

Не знаю, как он у кого не зависит, я вижу это примерно так: либо он у тебя в одном месте, либо раскидан по сети, а это где-то недобор, где-то перебор, начинается жонглирование. Гонять трафик мимо ядра не всегда комильфо.

 

Если у вас есть пул /20, то вы везде раздаете адреса из пула /20, анонсите их по OSPF, а что бы ходил трафик между адресами из пула, включаете прокси-арп.

 

Никакого жонглирования не будет, например у вас 3 узла агрегации, на 1 могут забрать половину пула, на 2 почти все оставшиеся, а на 3 вообще пару адресов. Соответственно если измените топологию, то все абоненты могут легко перейти на другие узлы и адреса распределяться в другом соотношении.

[VVSina]

2tehmeh

 

Просто агрегация при авторизации абонента ломится по радиусу или ещё как в единое место, которое и управляет раздачей адресов.

Поэтому пул получается 1 на всех, а не разбивается на несколько по числу узлов агрегации как вы пишите.