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

я ж в мелком провайдере работаю. откуда нам дадут железку на тесты ?

ну вы покупаете juniper у каких-то барыг

у меня с ними особых проблем не было

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

?

как с NE40E было

они чужие железки по винтикам раскручивают

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

гнать в шею

@somovis А хоть где-то они анонсы свои пишут ? А то кроме "Technical Bulletins" других источников информации не нашел

Конечно пишут. Они презентации делают, в Москве делают раз в год Juniper Summit и потом запись публикают в Youtube, FB

гнать в шею

а других у нас нету :(

ну это не относится к Juniper. Обычно об их планах узнаем только через пол-года после того, как оборудование уже выпущено

Ну это вы)

Мы узнаём ДО

не такое угребище, как 6500/7600

++

dmitryluhtionov opened merge request at / noc: Fix MikroTik.RouterOS.get_interfaces script

merge request merged by dv

я ж в мелком провайдере работаю. откуда нам дадут железку на тесты ?

Закажите POC в Москве или удаленный

++

вот вот, новый наряд для выкопанной стюардессы

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

Ну ты должен понимать, что представители джуна - это менеджеры и SE, а они не могут знать ВСЕХ технический особенностей железа, потому-что это просто не реально и этим занимаются другие люди. Но, они могут задать твой вопрос разработчикам и передать ответ разработчиков тебе. Это уже клиентоориентированность, она выстраивается между заказчиком и аккаунт-менеджером

как с NE40E было

Что с ней? И как вам 20е?

А у нас дхцп на фрирадиусе. Централизованная схема, и сеть на микротах) нищеброды)

Это к вопросу выше о том кто какой дхцп пользует

А у нас дхцп на фрирадиусе. Централизованная схема, и сеть на микротах) нищеброды)

Я, вроде, в нём видел поддержку option82, но пример использования нашёл только 1, и то не понятно на сколько оно хорошо работает

Я, вроде, в нём видел поддержку option82, но пример использования нашёл только 1, и то не понятно на сколько оно хорошо работает

Документация у фрирадиуса наркоманская, что есть то есть...ох сколько я матерился...и потом ещё другие люди после меня)

Документация у фрирадиуса наркоманская, что есть то есть...ох сколько я матерился...и потом ещё другие люди после меня)

А опцию82 в итоге юзали или просто dhcp?

А опцию82 в итоге юзали или просто dhcp?

Нет, не юзали мы статический wisp прибываем абонентские станции по маку и все. Станции у абонентов редко меняются

эх

Войти

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

Учитывая ещё что опыта решения таких задач у нас нет ни у кого

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

по AP MAC можно выдавать адрес (option 82 snooping на самой AP)

по адресу релея можно

или у вас l2 тянется до сервера

Ap у нас это по факту тупой бридж. Схема такая на вышке стоит роутер микрот. К нему подключены ар, к ап, абоненты. На роутере релей на влане абонентском. Между роутером и ядром л3 транспорт.

адрес нужен в зависимости от микрота, который релеит или от ап, к которой он подключен?

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

В зависимости от микрота

Одна базовая станция = 1 л2 сегмент...

а привязка по маку разве не работает с такой схемой?

Работает.

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

Биллинг даёт дхцп серверу инфо кому что выдавать

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

Это все равно статичная привязка адресов к абонентам

Хотим уйти от этого дрочева.

Чтобы адрес к абону привязывался исходя из того за какую бс он подключен

так, всёравно же надо выдавать ip по маку, если нужно, чтобы всегда один и тот же давался

Interface | Multicast | In не отрисовывается в графане? или его надо правильно готовить?

кошка обычная 3560

Нужно чтобы один и тот же был только для абонов с услугой белый ip

А таких единицы на одну бс

У 99% серые адреса и все равно на какой адрес сменится у него

Я теперь вообще не понимаю принипа что как и кому выдавать если влан один, подсетей на нём много. Можно в лс продолжить.

Была мысль делать так: в биллинга есть инфо какие сети на какой бс живут. Биллинг даёт список незанятых адресов и маков станций каждой из подсетей радиусу. Радиус выдав абоненту ИП от нужной бс пишет эту инфо в биллинг и адрес заносится на абонента. Биллинг отдает брасу инфо для аккаунтинга этого адреса ну и тд

Лан, это все досужий разговор, пока оформленной точной схемы нет и говорить не о чем. Написал, думал мож кто то реализовывал подобное. Рассказал бы как у "белых людей" сделано)

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

juniper mx + radius ?

juniper mx + radius ?

=)

juniper mx + radius ?

Нет у нас жуниперов и не предвидится)

Нет у нас жуниперов и не предвидится)

микротик ?

микротик ?

Да

Кстати, микротик же радиус умеет и dhcp у него встроенный есть

Я просто до сих пор не понял, как вы одного абонента от другого будете отличать без мака

Кстати, микротик же радиус умеет и dhcp у него встроенный есть

Хотелось бы особо к вендору не привязывать такой сервис как дхцп....сеть растет...пока что в ядре хватает 2-х 1036...но у микрота потолок это 1072...а что потом делать? Когда он закончится?

dhcp можно там же оставить и по радиусу у него спрашивать какой адрес выдавать кому, вроде

Посмотрю в эту сторону

ток по сути ничего не меняется. Вместо релея dhcp пакета на dhcp-radius, он будет спрашивать тот же сервер через radius.

Но! Если на каждом сайте поднимать дхцп сервер. А решение о том кому что выдавать или не выдавать уже принимать на сервере ответа от радиуса...надо подумать

На основании ответа*

Один фиг на каждой базе в центре схемы стоит микрот

Красиво

dmitryluhtionov opened merge request at / noc: Fix Eltex.DSLAM.get_interfaces script

а что это она ногами держит ?

dmitryluhtionov opened merge request at / noc: Fix Eltex.DSLAM.get_interfaces script

merge request opened by dmitryluhtionov

нок штука хорошая но немного задалбливает вместо доки рыть код))

а что это она ногами держит ?

Раскоояку))

Раскоряку*

merge request opened by aversant

merge request opened by aversant

merge request opened by aversant

merge request opened by aversant

))

merge request opened by aversant

merge request opened by aversant

подскажите, для чего используется snmp_ifindex?

подскажите, для чего используется snmp_ifindex?

именно для этого и ничего более

что делать если lldp возвращает номер порта?

радоваться, что возвращает хотя бы это.

:)

snmp_ifindex это где?

это из get_interfaces

используется при сборе метрик с интерфейсов

по SNMP

merge request opened by aversant