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

Добрый день!

Подскажите пожалуйста, возможно поднять Q-in-Q на L3 не создавая отдельного интерфейса для каждого клиентского vlan'a и если можно то какая железка с этим справится.

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


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

Добрый день!

Подскажите пожалуйста, возможно поднять Q-in-Q на L3 не создавая отдельного интерфейса для каждого клиентского vlan'a и если можно то какая железка с этим справится.

т.н. q-in-q это вообще-то чистый L2 :-) Вы чего хотите получить? а то главный телепат в бессрочном отпуске

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


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

Можно, если например PPPoEoQinQ. На 7200, ESR и на других железках.

Для IPoEoQinQ придётся для каждого вилана создавать сабинтерфейс.

Можно ещё свалить их в одну бридж-группу на ES-20 или SIP/SPA, но это не совсем то...

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


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

Добрый день!

Подскажите пожалуйста, возможно поднять Q-in-Q на L3 не создавая отдельного интерфейса для каждого клиентского vlan'a и если можно то какая железка с этим справится.

т.н. q-in-q это вообще-то чистый L2 :-) Вы чего хотите получить? а то главный телепат в бессрочном отпуске

Имеется сеть FTTB (около тысячи коммутаторов доступа), используется схема user-peer-vlan, уровня агрегации как такового нет(к сожалению), то есть, в ядро приходит некоторое количество q-in-q vlan'ов которые успешно терминируются на BRAS(pppoe). К сожалению при выбработке проекта не участвовал и L3 не предусмотрен. Теперь с ростом трафика встала необходимость поднять L3 и не гонять внутренний трафик между пользователями через BRAS. Каким образом это можно сделать с минимальными затратами рабочего времени и разумеется средств.

 

Можно, если например PPPoEoQinQ. На 7200, ESR и на других железках.

Для IPoEoQinQ придётся для каждого вилана создавать сабинтерфейс.

Можно ещё свалить их в одну бридж-группу на ES-20 или SIP/SPA, но это не совсем то...

Как раз схема с PPPoEoQinQ и была реализована. Хотелось бы создать инетерфейс завести туда QinQ vlan, повесить ip helper-address и получить таким образом IPoEoQinQ :-). Видимо я размечтался :-(

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


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

Как раз схема с PPPoEoQinQ и была реализована. Хотелось бы создать инетерфейс завести туда QinQ vlan, повесить ip helper-address и получить таким образом IPoEoQinQ :-). Видимо я размечтался :-(
Самому хотелось бы. Циска это давно обещает, но когда реализует - неизвестно.

В связке с DHCP и ISG намного упростило бы управление маршрутизатором.

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


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

Как раз схема с PPPoEoQinQ и была реализована. Хотелось бы создать инетерфейс завести туда QinQ vlan, повесить ip helper-address и получить таким образом IPoEoQinQ :-). Видимо я размечтался :-(

а q-in-q у Вас прямо с доступов уходит или до ядра с 1 тегом, а на входе в ядро второй навешиваете?

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


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

Имеется сеть FTTB (около тысячи коммутаторов доступа), используется схема user-peer-vlan, уровня агрегации как такового нет(к сожалению), то есть, в ядро приходит некоторое количество q-in-q vlan'ов которые успешно терминируются на BRAS(pppoe). К сожалению при выбработке проекта не участвовал и L3 не предусмотрен. Теперь с ростом трафика встала необходимость поднять L3 и не гонять внутренний трафик между пользователями через BRAS. Каким образом это можно сделать с минимальными затратами рабочего времени и разумеется средств.
При сохранении "вилан-на юзера" такое невозможно - всё пойдёт через центр.

А что не нравится? Локалку "похаляве" так не дать, конечно, но оно и не надо - наоборот, сделайте это объёктом торговли (внутренние скорости отдельно от внешних, например).

 

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


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

Как раз схема с PPPoEoQinQ и была реализована. Хотелось бы создать инетерфейс завести туда QinQ vlan, повесить ip helper-address и получить таким образом IPoEoQinQ :-). Видимо я размечтался :-(

а q-in-q у Вас прямо с доступов уходит или до ядра с 1 тегом, а на входе в ядро второй навешиваете?

Именно так и происходит:-(

 

Как раз схема с PPPoEoQinQ и была реализована. Хотелось бы создать инетерфейс завести туда QinQ vlan, повесить ip helper-address и получить таким образом IPoEoQinQ :-). Видимо я размечтался :-(

а q-in-q у Вас прямо с доступов уходит или до ядра с 1 тегом, а на входе в ядро второй навешиваете?

Именно так и происходит:-(

В ядре второй вешается.

 

Имеется сеть FTTB (около тысячи коммутаторов доступа), используется схема user-peer-vlan, уровня агрегации как такового нет(к сожалению), то есть, в ядро приходит некоторое количество q-in-q vlan'ов которые успешно терминируются на BRAS(pppoe). К сожалению при выбработке проекта не участвовал и L3 не предусмотрен. Теперь с ростом трафика встала необходимость поднять L3 и не гонять внутренний трафик между пользователями через BRAS. Каким образом это можно сделать с минимальными затратами рабочего времени и разумеется средств.
При сохранении "вилан-на юзера" такое невозможно - всё пойдёт через центр.

А что не нравится? Локалку "похаляве" так не дать, конечно, но оно и не надо - наоборот, сделайте это объёктом торговли (внутренние скорости отдельно от внешних, например).

У конкурентов внутренний трафик не объект торговли поэтому и нам им торговать не стоит.

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


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

У конкурентов внутренний трафик не объект торговли поэтому и нам им торговать не стоит.
ХМ, в этом будет отличие. Неужели все операторы в городе должны быть как близнецы?

Торговать можно не трафиком, а полосами. Например, 2 мегабита внешнего, 10 внутреннего.

Да и нафига он вообще, этот внутренний? Что там внутри сети найти можно? В инете несопоставимо больше всего...

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


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

У конкурентов внутренний трафик не объект торговли поэтому и нам им торговать не стоит.
ХМ, в этом будет отличие. Неужели все операторы в городе должны быть как близнецы?

Торговать можно не трафиком, а полосами. Например, 2 мегабита внешнего, 10 внутреннего.

Да и нафига он вообще, этот внутренний? Что там внутри сети найти можно? В инете несопоставимо больше всего...

А как же экономия внешних каналов, у нас и при желании лишний гигабит не найти, а так же ресурсы BRAS
Изменено пользователем xelaalex

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


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

А чего их экономить, если за них заплачено?

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


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

А чего их экономить, если за них заплачено?

Имелось ввиду, что еще гиг другой купить пока не у кого, все провайдеры уже что могли отдали.:-(

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


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

Имеется сеть FTTB (около тысячи коммутаторов доступа), используется схема user-peer-vlan, уровня агрегации как такового нет(к сожалению), то есть, в ядро приходит некоторое количество q-in-q vlan'ов которые успешно терминируются на BRAS(pppoe). К сожалению при выбработке проекта не участвовал и L3 не предусмотрен. Теперь с ростом трафика встала необходимость поднять L3 и не гонять внутренний трафик между пользователями через BRAS. Каким образом это можно сделать с минимальными затратами рабочего времени и разумеется средств.

 

Можно, если например PPPoEoQinQ. На 7200, ESR и на других железках.

Для IPoEoQinQ придётся для каждого вилана создавать сабинтерфейс.

Можно ещё свалить их в одну бридж-группу на ES-20 или SIP/SPA, но это не совсем то...

Как раз схема с PPPoEoQinQ и была реализована. Хотелось бы создать инетерфейс завести туда QinQ vlan, повесить ip helper-address и получить таким образом IPoEoQinQ :-). Видимо я размечтался :-(

То что вы хотите можно сделать на алкатель 7750 SR, и на более мелких железках этой серии.

Какой бюджет у вас и количество трафика?

Можно в личку.

 

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

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

 

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


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

У вас весь трафик под контролем, поставить пяток дополнительных одноюнитовых PPPoE серверов в стойку сильно проще чем поддерживать двойную адресацию и объяснять пользователям маршрутизацию.
Поставить один ESR или ASR - ещё проще. :)

Да и дешевле.

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


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

У вас весь трафик под контролем, поставить пяток дополнительных одноюнитовых PPPoE серверов в стойку сильно проще чем поддерживать двойную адресацию и объяснять пользователям маршрутизацию.
Поставить один ESR или ASR - ещё проще. :)

Да и дешевле.

Человек хочет красиво, IPoE )

Если в его городе это даст преимущество, почему бы и нет.

 

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


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

Имеется сеть FTTB (около тысячи коммутаторов доступа), используется схема user-peer-vlan, уровня агрегации как такового нет(к сожалению), то есть, в ядро приходит некоторое количество q-in-q vlan'ов которые успешно терминируются на BRAS(pppoe). К сожалению при выбработке проекта не участвовал и L3 не предусмотрен. Теперь с ростом трафика встала необходимость поднять L3 и не гонять внутренний трафик между пользователями через BRAS. Каким образом это можно сделать с минимальными затратами рабочего времени и разумеется средств.

 

Можно, если например PPPoEoQinQ. На 7200, ESR и на других железках.

Для IPoEoQinQ придётся для каждого вилана создавать сабинтерфейс.

Можно ещё свалить их в одну бридж-группу на ES-20 или SIP/SPA, но это не совсем то...

Как раз схема с PPPoEoQinQ и была реализована. Хотелось бы создать инетерфейс завести туда QinQ vlan, повесить ip helper-address и получить таким образом IPoEoQinQ :-). Видимо я размечтался :-(

То что вы хотите можно сделать на алкатель 7750 SR, и на более мелких железках этой серии.

Какой бюджет у вас и количество трафика?

Можно в личку.

 

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

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

Спасибо за информацию, сейчас буду искать доку по этой железке. Еще Huawei заявил на s9300 серии подобное, сегодня- завтра вроде как должны сказать точно.

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


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

У вас весь трафик под контролем, поставить пяток дополнительных одноюнитовых PPPoE серверов в стойку сильно проще чем поддерживать двойную адресацию и объяснять пользователям маршрутизацию.
Поставить один ESR или ASR - ещё проще. :)

Да и дешевле.

Человек хочет красиво, IPoE )

Если в его городе это даст преимущество, почему бы и нет.

IPoE при "вилан-на-юзера" ему ничего не даст, ему нужен "колхоз" с максимум "вилан-на-дом", а ещё лучше "вилан-на-квартал".

Только при этом очень большие проблемы с безопасностью, боюсь всю сеть придётся переделывать...

Главное - это почти не имеет смысла, т.к. очень мало трафика замыкается в пределах дома и даже квартала, всё равно львиная доля трафика пойдёт через центр.

Так что поставить в центр приличную железку, сделать честные 100 мегабит на дом - и всё в порядке.

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


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

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

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

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


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

Именно так и происходит:-(

В ядре второй вешается.

 

У конкурентов внутренний трафик не объект торговли поэтому и нам им торговать не стоит.

в принципе правильный настройки (traffic segmentation и т.д. в терминологии D-Link) на доступе и vlan на коммутатор доступа при установке BRASа уровня ESR, ASR (все зависит от количества хомяков) решит вопрос с ipoe, ну будет куча сабинтерфейсов на картах BRASа, ну и что? :-)

 

не хотите продавать локалку, не продавайте, но пиариться дешево можно:-) не давать полностью порт под неё, а начать с доли малой сиротской, сегодня 30 Мбит дали, завтра еще 20 добавили под очередную рекламную кампанию и т.д.

Изменено пользователем White_Alex

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


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

У вас весь трафик под контролем, поставить пяток дополнительных одноюнитовых PPPoE серверов в стойку сильно проще чем поддерживать двойную адресацию и объяснять пользователям маршрутизацию.
Поставить один ESR или ASR - ещё проще. :)

Да и дешевле.

Человек хочет красиво, IPoE )

Если в его городе это даст преимущество, почему бы и нет.

IPoE при "вилан-на-юзера" ему ничего не даст, ему нужен "колхоз" с максимум "вилан-на-дом", а ещё лучше "вилан-на-квартал".

Только при этом очень большие проблемы с безопасностью, боюсь всю сеть придётся переделывать...

Главное - это почти не имеет смысла, т.к. очень мало трафика замыкается в пределах дома и даже квартала, всё равно львиная доля трафика пойдёт через центр.

Так что поставить в центр приличную железку, сделать честные 100 мегабит на дом - и всё в порядке.

Колхоз тоже имеется в виде "вилан-на-дом", а потом эти vlan так же попадают в Q-in-Q. Трафик пусть идет через центр, главное что бы не через BRAS, ибо, зачем его грузить внутренним трафиком.

 

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

1. Увеличенный расход public IP тк при такой схеме их будет использоватся больше (комп у клиента включен - значит пользователь online, не обязательно что он интернет использует). Nat пользоватили ну очень не любят, так что серые схемы не годятся.

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

 

 

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


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

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

Вот чего не надо давать - так это "локалку" на скорости порта, т.к. потом от халявы не отучить. Давайте единицы мегабит, раза в 2-3 больше, чем в инет...

А PPPoE там или IPoE - дело десятое.

У меня, кстати, сеть IPoEoQinQ, весь трафик через BRAS'ы идёт...

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


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

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

Вот чего не надо давать - так это "локалку" на скорости порта, т.к. потом от халявы не отучить. Давайте единицы мегабит, раза в 2-3 больше, чем в инет...

А PPPoE там или IPoE - дело десятое.

У меня, кстати, сеть IPoEoQinQ, весь трафик через BRAS'ы идёт...

А как вы на L3 поднимаете без PPPoE и кто у вас в роли BRAS выступает ?

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


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

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

1. Увеличенный расход public IP тк при такой схеме их будет использоватся больше (комп у клиента включен - значит пользователь online, не обязательно что он интернет использует). Nat пользоватили ну очень не любят, так что серые схемы не годятся.

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

За все нужно платить, от первого пункта никуда не деться.

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

С коммутаторами и влететь недолго, во первых режут часто на L1, во вторых эджкор недавно отличился, в третьих перерывы бывают с электричеством, в четвертых на брасе локалку можно по одному порезать, инет по другому, и т.д.

Изменено пользователем rus-p

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


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

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

1. Увеличенный расход public IP тк при такой схеме их будет использоватся больше (комп у клиента включен - значит пользователь online, не обязательно что он интернет использует). Nat пользоватили ну очень не любят, так что серые схемы не годятся.

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

За все нужно платить, от первого пункта никуда не деться.

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

С коммутаторами и влететь недолго, во первых режут часто на L1, во вторых эджкор недавно отличился, в третьих перерывы бывают с электричеством, в четвертых на брасе локалку можно по одному порезать, инет по другому, и т.д.

С первым пунктом согласен. Что касается второго - я искал недорогую альтернативу использованию BRAS, но получается при схеме IPoE для нормального управления придется использовать что нить подобное SCE. Выходим на те же деньги.
Изменено пользователем xelaalex

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


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

У меня, кстати, сеть IPoEoQinQ, весь трафик через BRAS'ы идёт...
А как вы на L3 поднимаете без PPPoE и кто у вас в роли BRAS выступает ?

Сабинтерфейс у каждого клиента, как ещё?

А BRAS'ы - ESR PRE-3.

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


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

Join the conversation

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

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

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

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

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

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

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