Jump to content
Калькуляторы

Q-in-Q and L3 Q-in-Q and L3

Добрый день!

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

Share this post


Link to post
Share on other sites
Добрый день!

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites
Добрый день!

Подскажите пожалуйста, возможно поднять 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 :-). Видимо я размечтался :-(

Share this post


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

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

Share this post


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

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

Share this post


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

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

 

Share this post


Link to post
Share on other sites
Как раз схема с 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. Каким образом это можно сделать с минимальными затратами рабочего времени и разумеется средств.
При сохранении "вилан-на юзера" такое невозможно - всё пойдёт через центр.

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

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

Share this post


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

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

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

Share this post


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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
Имеется сеть 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 серверов в стойку сильно проще чем поддерживать двойную адресацию и объяснять пользователям маршрутизацию.

 

Share this post


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

Да и дешевле.

Share this post


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

Да и дешевле.

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

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

 

Share this post


Link to post
Share on other sites
Имеется сеть 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 серии подобное, сегодня- завтра вроде как должны сказать точно.

Share this post


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

Да и дешевле.

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
Именно так и происходит:-(

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

 

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

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

 

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

Edited by White_Alex

Share this post


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

Да и дешевле.

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

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

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

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

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

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

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

 

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

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

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

 

 

Share this post


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

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

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

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

Share this post


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

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

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

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

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

Share this post


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

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

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

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

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

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

Edited by rus-p

Share this post


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

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

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

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

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

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

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

Share this post


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

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

А BRAS'ы - ESR PRE-3.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this