[s.lobanov]

s.lobanov сказал:

Погодите немного, не расстреливайте пока, пусть он сначала расскажет как именно биллинг не пропускает мак-адреса?

 

Ммм, эээ, ну это ноухау такое, две сточки-то сравнить...

 

Т.е. у вас весь трафик идёт через биллинг-сервер, который на втором уровне проверяет мак-адреса или как оно вообще работает?

[rdc]

Интересно как вы "порт" прописали в договор :) Покажите ваше определение "порта".

А что ему там делать? В договоре указана точка разграничения ответственности - кабель на входе в помещение абонента.

[ThreeDHead]

Т.е. у вас весь трафик идёт через биллинг-сервер, который на втором уровне проверяет мак-адреса или как оно вообще работает?

Боже упаси, нет конечно :) Все тривиально, на доступе фильтрация по макам.

 

А что ему там делать? В договоре указана точка разграничения ответственности - кабель на входе в помещение абонента.

Понятно. К СОРМу вы абонента тоже кабелем притягиваете?

[kf72]

ув ThreeDHead а какие коммутаторы на доступе?

может в ваших железках изоляция портов присутствует, только называется по другому ?

[s.lobanov]

s.lobanov (Вчера, 23:38) писал:

Т.е. у вас весь трафик идёт через биллинг-сервер, который на втором уровне проверяет мак-адреса или как оно вообще работает?

 

Боже упаси, нет конечно :) Все тривиально, на доступе фильтрация по макам.

 

А почему вы пишите что биллинг не пропустит? (хотя в самом деле коммутатор)

[T_Igor]

Зачем столько гимороя наваливать на себя, техподдержку и клиентов? vlan per customer плюс ip unnumbered решают все эти проблемы. Боятся рутины с пробрасыванием вланов до клиентов не надо. Пишется скрипт который пробрасывает влан до каждого клиента с выводом на всякий случай отладочной информации, чтобы если что можно было ручками поправить косяк. Каждый клиент привязан к порту какого-то коммутатора, у каждого коммутатора есть в базе путь до ядра(терминатора вланов)- представляет из себя список IP адресов коммутаторов через которые проходит и магистральные порты на этих коммутаторах. Скрипт оперируя этими данными сам пробросит влан до абонента.

Почитайте про ip unnumbered и вам наверное не придется менять адреса у клиентов.

[ThreeDHead]

А почему вы пишите что биллинг не пропустит? (хотя в самом деле коммутатор)

Биллинг управляет коммутаторами. В него (биллинг), и прописывается MAC.

 

Зачем столько гимороя наваливать на себя, техподдержку и клиентов?

Геморроя ровно столько же, сколько и с виланом на абона, возможно даже меньше.

http://nag.ru/articles/article/16999/vlan-na-polzovatelya-arhitektura-i-alternativyi.html

[T_Igor]

T_Igor сказал:

Зачем столько гимороя наваливать на себя, техподдержку и клиентов?

 

Геморроя ровно столько же, сколько и с виланом на абона, возможно даже меньше.

http://nag.ru/articl...ternativyi.html

Давно читал эту статью - голый пиар. Понимаете все это мы уже прошли потом и нервами, и пока на "vlan per customer плюс ip unnumbered плюс DHCP-relay" нам хорошо живется. "Разделяй и властвуй" - уже давно этот девиз во всех подобных темах светится.

[rdc]

Пишется скрипт который пробрасывает влан до каждого клиента

Кстати, есть более простое решение.

На агрегации QinQ - соответственно, влан нужен только на самом доступе.

А на самом доступе все вланы забиваются заранее - один раз, при установке свича.

Результат - никакое управление свичами не требуется вовсе.

[T_Igor]

Можно и так. Сейчас активно сокращаем длину цепочек из коммутаторов и в идеале остается в цепочке коммутатор агрегации на котором все порты транковые и абоненский коммутатор - тоже как-бы меньше напрягов получается

Изменено 18 марта, 2013 пользователем T_Igor

[Antares]

Мы тоже используем вилан на абонента, это решает очень многие проблемы