Помогите разобраться с Option 82.
Если адреса всех абонентов будут выдаваться из одного динамического пула, зачем привязываться к конкретной ONU ? Или нужно выдавать разные адреса на разных ONU ?
Последний раз редактировалось serjk Пт дек 19, 2014 12:34, всего редактировалось 1 раз.
Я понимаю и читаю это особенность GEPON на BDCOM. Я специально показал строку, возвращаемую по опции 82 из связки, НЕТУ там мака OLT вот совсем нету и не привязаться к нему, приходится изворачиваться и ставить его имя, которое там есть, зато есть мак ONU, но как порт его использовать нельзя, вот и вопрос как попробовать взлететь со всей этой хреновиной.TiRider писал(а):Вы понимаете. Человек не понимает и не читает то, что ему пишут!serjk писал(а):Видимо я не понимаю задачи.
Чей hostname приходит в opt 82 ?
Предлагаете в оборудовании завести вместо одного OLT несколько сотен ONU прицепить их на 1 пул и отталкиваться от мака, в принципе это может быть решением, не совсем удобно конечно, но лучше чем ничего, сейчас попробую на стенде. В качестве Remote ID надо указать мак онушки без разделителей при заведении?serjk писал(а):Если адреса всех абонентов будут выдаваться из одного динамического пула, зачем привязываться к конкретной ONU ? Или нужно выдавать разные адреса на разных ONU ?
Предлагаю в оборудовании завести один OLT, и всех абонентов привязывать к нему, если адреса предполагается выдавать из одного пула. Индивидуальные ONU не рассматривать.
[s]OLT идентифицировать по Remote-ID (который равен его MAC адресу)[/s] а тут я уже запутался, и не уверен, кто из них (ONU/OLT) подставляет в DHCP пакеты свою опцию 82
[s]OLT идентифицировать по Remote-ID (который равен его MAC адресу)[/s] а тут я уже запутался, и не уверен, кто из них (ONU/OLT) подставляет в DHCP пакеты свою опцию 82
Последний раз редактировалось serjk Пт дек 19, 2014 12:49, всего редактировалось 2 раза.
А как мне тогда шейпить и блокировать абонентов? Я же не смогу их различать если они будут привязаны к ОЛТу а не к ОНУserjk писал(а):Предлагаю в оборудовании завести один OLT, и всех абонентов привязывать к нему, если адреса предполагается выдавать из одного пула. Индивидуальные ONU не рассматривать.
ONU - это клиентское устройство, похоже на роутер, на одном ONU может сидеть только 1 абонент, так как ставится ONU в конечную квартиру - это устройство оконцовки последней мили на схеме FTTS. Тут основная задача именно в том чтоб абоненту ничего не надо было настраивать, ни каких авторизаций, воткнул патчкорд, трафик полетел, а если завязываться на OLT придется предусмотреть какую-либо авторизацию абонента, для тех кто с авторизацией есть отдельный BRAS и не хотелось усложнять жизнь тем кто на FTTSserjk писал(а):А какое отношение шейпирование и блокировка имеет к выдаче адресов? Даже если абоненты будут привязаны к ONU, на одном ONU может сидеть много абонентов с разным статусом блокировки и тарифом, не пойму логики.
В любом случае, у Вас 2 варианта
1. Привязывать всех абонентов к OLT и не рассматривать ONU
2. Заводить по коммутатору на каждый ONU (фактически на абонента)
При чем здесь абонентские настройки, блокировки и шейпирование - мне по-прежнему не понятно. Если шейпирование задается DHCP опциями, то только 2 вариант, причем опции придется изменять руками (в свойставах коммутатора-ONU) при смене абонентом тарифа.
1. Привязывать всех абонентов к OLT и не рассматривать ONU
2. Заводить по коммутатору на каждый ONU (фактически на абонента)
При чем здесь абонентские настройки, блокировки и шейпирование - мне по-прежнему не понятно. Если шейпирование задается DHCP опциями, то только 2 вариант, причем опции придется изменять руками (в свойставах коммутатора-ONU) при смене абонентом тарифа.
Попробовал второй вариант, ONU на абонента, все еще не получаю адрес, но тут похоже другая причинаserjk писал(а):В любом случае, у Вас 2 варианта
1. Привязывать всех абонентов к OLT и не рассматривать ONU
2. Заводить по коммутатору на каждый ONU (фактически на абонента)
При чем здесь абонентские настройки, блокировки и шейпирование - мне по-прежнему не понятно. Если шейпирование задается DHCP опциями, то только 2 вариант, причем опции придется изменять руками (в свойставах коммутатора-ONU) при смене абонентом тарифа.
Код: Выделить всё
DHCP packet header
op: 2
htype: 1
hlen: 6
hops: 0
xid: a0cad2cb
secs: 0
flags: 0
ciaddr: 0.0.0.0
yiaddr: 91.219.232.10
siaddr: 91.219.232.2
giaddr: 0.0.0.0
chaddr: 5c:f9:dd:61:bd:59
sname:
file:
option [dhcp-message-type]: 02
option [dhcp-server-identifier]: 91.219.232.2
option [dhcp-lease-time]: 600
option [routers]: 91.219.232.1
option [subnet-mask]: 255.255.255.0
option [domain-name-servers]: 195.114.6.38;8.8.8.8
option [domain-name]: realbeb.pro
option [relay-agent-info]: 010500fa0007020206fcfaf7c575d8091200000cf80d010b4f4c545f4176746f64656c
Решение предоставьте для людей.Rico-X писал(а):Спасибо выловил по дампам на пути волшебный свич, на котором ответы бились.serjk писал(а):Смотреть, где фильтруется ответ DHCP сервера. Клиент его скорее всего не получает.
Чтобы они не бились в следующий раз.
Желательна картинка с настройками профиля оборудования.
Шаблон оборудованияРешение предоставьте для людей.
Чтобы они не бились в следующий раз.
Желательна картинка с настройками профиля оборудования.
Емкость 1
Активен только Remote ID
Тип: бинарный
Расположение: Опция 82
Смещение: 9
Длина: 6
Коммутатор
В качестве Remote ID указываем мак ONU
Опции DHCP в связке абонента
Указываем нужную нам ONU в качестве коммутатора, выбираем общий пул.
Не решенные пока проблемы:
1) Есть 2х и 4х портовые ONU похоже придется привязывать еще и порт, либо шаблоном самого OLT блокировать все порты кроме 1.
2) Динамический шейпер, пока выглядит очень костыльно, жду новую версию биллинга, в которой должно появиться управление опцией через радиус, сейчас радиус и опция две разные не пересекающиеся части системы, для программных роутеров это не проблема, можно навернуть любую логику через rfw скрипт, но у меня Juniper MX, а он вменяемо работает с динамическими шейперами только на Dynamic Subscriber Interfaces как их подружить на данный момент с биллингом без радиуса пока не разобрался, дергать же конфиг джуна при каждом изменении - адский костыль, пока сделал это раз в час, но надо избавляться. Жду поддержки от биллинга этих пар http://juniper.tw/techpubs/en_US/junos1 ... rview.html чтоб всю логику руления пулами вынести на джун полностью, как это сделано в PPPoE, а чтоб УТМка отвечала исключительно за радиус.