SM
Size: a a a
2020 July 16
D
А в случае weight только один брас пошлет пакет авторизации в радиус? Или как при offer-delay все пошлют?
Все будут слать
DM
Все будут слать
Это очень плохо, тем более при масштабировании, например у меня 4 браса и все шлют. Это возможно оптимизировать?
D
Это очень плохо, тем более при масштабировании, например у меня 4 браса и все шлют. Это возможно оптимизировать?
Возможно, но пока задач много и без этого
DM
Возможно, но пока задач много и без этого
В какую категорию это лучше оформить на фабриктор?
D
Когда несколько брасов с одним сегментом dhcp, то биллинг, как я понимаю должен решить какая сессия будет активной в итоге. То есть, он должен выдать каждому запросу по адресу из своей базы, аццель дальше отдает в оффер, а когда клиент стартанул на одном из брасов, то ранее забронированные адреса должны освободиться. Так, выходит на практике?
D
Когда несколько брасов с одним сегментом dhcp, то биллинг, как я понимаю должен решить какая сессия будет активной в итоге. То есть, он должен выдать каждому запросу по адресу из своей базы, аццель дальше отдает в оффер, а когда клиент стартанул на одном из брасов, то ранее забронированные адреса должны освободиться. Так, выходит на практике?
Биллинг должен разрешить обоим нас, т.е. RADIUS должен ответить Acess-Accept возможно с одними и теме же параметрами. А Брасы сами разберуться кто ответит offer
D
Ну да, но адрес можно отправлять один и тот же на 2 браса
В нашем случае, помимо общих пулов у нас есть пулы, прибитые к конкретным брасам, которые анонсируются агрегированно. И для них надо выдавать конкретный диапазон. Можно, конечно размазать всё по всём, но много /32 появится.
ST
Ну да, но адрес можно отправлять один и тот же на 2 браса
приколько когда ір вьідаю динамически - то в билинге появляются количество разньіх ір = кол нас. ))
