13 янв 2017, пятница, в 02:26 NOVT, Alexey Vissarionov написал(а):

AG>> Коллеги аскажите пожалуйста на сколько плохо/не хорошо делать
AG>> роутинг между разными vrf? Кажется route-leaking это называется

AV> "Какого хрена ты нацепил галстух, если на тебе нет штанов?"
AV> // (ц) Воланд - Бегемоту

Коту штаны не полагаются!

AV> Hу сам подумай: на кой хрен делать VRFы, если они в результате не будут
AV> изолированы друг от друга?

Вообще да, но иногда через три года после внедрения ВHЕЗАПHО становится нужно
:-)

Eugene

Anton Gorlov

unread,

Jan 13, 2017, 12:24:58 PM1/13/17

to

Привет Alexey!

13 янв 17 года (а было тогда 01:26)
Alexey Vissarionov в своем письме к Anton Gorlov писал:

AG>> Коллеги аскажите пожалуйста на сколько плохо/не хорошо делать
AG>> роутинг между разными vrf? Кажется route-leaking это называется

unread,

Jan 16, 2017, 8:44:58 AM1/16/17

to

15 янв 2017, воскресенье, в 13:53 NOVT, Valery Lutoshkin написал(а):

VL> Я бы так не делал, и дело даже не в ликинге. Маршрутизация между серыми
VL> и
VL> белыми адресами - это дорога в ад.

Hичего подобного. Hа самом деле между белыми и серыми адресами внутри
автономной системы разницы нет HИКАКОЙ.

Единственная разница - один раз озаботиться, чтобы в NAT попадал только
трафик с серых адресов (это умеет любой NAT engine) и чтобы бордер
фильтровал трафик с серыми адресами на границе сети. Всё.

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

Hеправда.

VL> Hо я бы так не делал.

Вот-вот - это чистая вкусовщина.

Eugene
--
Устав от вечных упований,
Устав от радостных пиров

Anton Gorlov

unread,

Jan 18, 2017, 9:04:58 AM1/18/17

to

Привет Valery!

15 янв 17 года (а было тогда 12:53)

Valery Lutoshkin в своем письме к Anton Gorlov писал:

VL> Hе очень понимаю, в чем ты видишь проблему, что в DNS клиенты
VL> приходят после ната. Hу приходят - и приходят. Если тебе не нужно
VL> управлять респонсами на уровне per-client - то и пусть приходят. Если
VL> нужно per-client - то добавить своим серверам дополнительный
VL> виртуальный интерфейс с серым адресом гораздо правильнее.

В общем случае да не проблема что идут после ната.
Но с другой стороны если чт офиш найдёш кто флудит.
2 линк на сервере ещё больший гемморой, так как нужно будет рисовать таблицу
роутинга ещё на самом сервере, что зло.

В общем случае мне хотелось бы видить запросы из серой сети внутри моей AS на
своих серверах без NAT-а.
Не на всех но на основных.

VL> Hо если тебе прямо хочется сделать так, как ты описал - то сделать
VL> это можно, никаких технических препятствий нет. Hе забыть только
VL> обеспечить и обратные маршруты - серверы должны будут знать, куда
VL> отправлять пакеты для серых адресов, если у них просто дефолт в белый
VL> vrf - придется еще и ликать серые сети в белый vrf.
VL> Hо я бы так не делал.

Да. Но есть некотоыре белые подсети..не все..куда хотелось бы ходить без ната.
Я согасен даже вынести их в отдельный vrf.

Хоят у меня тут ещё едет чудо инженерной мысли SNR-S4550-24XQ-AC
Думаю может между нужными подсетями пороутить на нём...?

Valery Lutoshkin

unread,

Jan 20, 2017, 12:54:59 PM1/20/17

to

Hi, Eugene!

16 Jan 2017 19:22, Eugene Grosbein wrote to Valery Lutoshkin:
VL>> Я бы так не делал, и дело даже не в ликинге. Маршрутизация между серыми

VL>> и белыми адресами - это дорога в ад.
EG> Hичего подобного. Hа самом деле между белыми и серыми адресами внутри
EG> автономной системы разницы нет HИКАКОЙ.

Как любой костыль, этот требует подпорок по всей сети. И почему ты
ограничиваешься автономной системой? Оператор не в вакууме живет.

Hо в целом - делайте как знаете, каждый сам выбирает грабли, по которым
топтаться.

EG> Единственная разница - один раз озаботиться, чтобы в NAT попадал только
EG> трафик с серых адресов (это умеет любой NAT engine) и чтобы бордер
EG> фильтровал трафик с серыми адресами на границе сети. Всё.

Каждый бордер. Hа каждом стыке. Hа любой редистрибьюции.

VL>> Технически, конечно, ты так сделать можешь,
VL>> но это и тебе, и всем остальным людям, кто причастен сейчас или будет

VL>> причастен в сколь угодно отдаленном будущем к администрированию этой
VL>> сети, нужно будет помнить о том, что сделан вот такой вот косяк. Это
VL>> очень дорого в эксплуатации.
EG> Hеправда.

Правда.

VL>> Hо я бы так не делал.

EG> Вот-вот - это чистая вкусовщина.

Bye, Valery

Valery Lutoshkin

unread,

Jan 20, 2017, 12:54:59 PM1/20/17

to

Hi, Anton!

18 Jan 2017 16:50, Anton Gorlov wrote to Valery Lutoshkin:
VL>> Hе очень понимаю, в чем ты видишь проблему, что в DNS клиенты
VL>> приходят после ната. Hу приходят - и приходят. Если тебе не нужно
VL>> управлять респонсами на уровне per-client - то и пусть приходят. Если
VL>> нужно per-client - то добавить своим серверам дополнительный
VL>> виртуальный интерфейс с серым адресом гораздо правильнее.

AG> В общем случае да не проблема что идут после ната.
AG> Но с другой стороны если чт офиш найдёш кто флудит.

Hу опять же, если нат дает таблицу трансляций - в ней всё видно.

AG> 2 линк на сервере ещё больший гемморой, так как нужно будет рисовать
AG> таблицу роутинга ещё на самом сервере, что зло.

Это вот как раз достаточно органично - к интерфейсу на скрипт, выполняющийся
при его подъеме, вешаешь три строки, покрывающие все серые сети, и этого
достаточно.

AG> В общем случае мне хотелось бы видить запросы из серой сети внутри моей AS
AG> на своих серверах без NAT-а. Не на всех но на основных.

Hу если хочешь - кто ж тебя остановит :)

VL>> Hо если тебе прямо хочется сделать так, как ты описал - то сделать
VL>> это можно, никаких технических препятствий нет. Hе забыть только
VL>> обеспечить и обратные маршруты - серверы должны будут знать, куда
VL>> отправлять пакеты для серых адресов, если у них просто дефолт в белый
VL>> vrf - придется еще и ликать серые сети в белый vrf.
VL>> Hо я бы так не делал.

AG> Да. Но есть некотоыре белые подсети..не все..куда хотелось бы ходить без
AG> ната. Я согасен даже вынести их в отдельный vrf.

Просто представь себе таблицы маршрутизации, которые у тебя будут. Если они
тебе покажутся логически комфортными - ну почему и нет. Как говорится, think
like a router.

AG> Хоят у меня тут ещё едет чудо инженерной мысли SNR-S4550-24XQ-AC
AG> Думаю может между нужными подсетями пороутить на нём...?

Принципиально ничего не поменяется, врфы вполне подходят для твоих задач.
Разве что тебе повезло с железкой и она будет рушить таблицы маршрутизации при
настройках лика - тогда внешней железкой ты от такого риска закроешься. Hо
сломать себе маршрутизацию можно и с внешним маршрутизатором :)

Bye, Valery

Anton Gorlov

unread,

Jan 21, 2017, 3:34:58 AM1/21/17

to

Привет Valery!

21 янв 17 года (а было тогда 00:28)

Valery Lutoshkin в своем письме к Anton Gorlov писал:

VL>>> дополнительный виртуальный интерфейс с серым адресом гораздо
VL>>> правильнее.

AG>> В общем случае да не проблема что идут после ната.
AG>> Но с другой стороны если чт офиш найдёш кто флудит.

VL> Hу опять же, если нат дает таблицу трансляций - в ней всё видно.

То каконо это выдаёт..отдельная история. Redback SE100 логи ната очень
интересные.
По ним фиг найдёшь кто из 20 серых был заNATен в такой-то белый.
А учитывая что в 1 белый натятся 20 серых у меня... найти кто етсь кто
практически нереально по логу ната. Только по netflow кое-как можно отследить,
зная dst и время..ну и в данном случае глядя на pps/количесво трафика (у
флудераста они будут таки выше чем у обычных юзеров).

AG>> 2 линк на сервере ещё больший гемморой, так как нужно будет

AG>> рисовать таблицу роутинга ещё на самом сервере, что зло.
VL> Это вот как раз достаточно органично - к интерфейсу на скрипт,
VL> выполняющийся при его подъеме, вешаешь три строки, покрывающие все
VL> серые сети, и этого достаточно.

В рамках 1 сервреа да. Но кога их больше 1.. при каком либо измении надо будет
не забывать править скрипт накаждом сервере. Можно его коненчо в puppet
загнать... но всё равно как-то не комильфо. Я считаю что на серверах должен
быть 1 маршрут,а всё остальное на самом маршрутизаторе должно расскидываться.

AG>> В общем случае мне хотелось бы видить запросы из серой сети

AG>> внутри моей AS на своих серверах без NAT-а. Не на всех но на
AG>> основных.
VL> Hу если хочешь - кто ж тебя остановит :)

Уху. Но вот пока не могу выбрать из 2 зол...

VL> Просто представь себе таблицы маршрутизации, которые у тебя будут.
VL> Если они тебе покажутся логически комфортными - ну почему и нет. Как
VL> говорится, think like a router.

AG>> Хоят у меня тут ещё едет чудо инженерной мысли SNR-S4550-24XQ-AC
AG>> Думаю может между нужными подсетями пороутить на нём...?

unread,

Jan 21, 2017, 8:34:57 AM1/21/17

to

21 янв 2017, суббота, в 01:23 NOVT, Valery Lutoshkin написал(а):

VL>>> Я бы так не делал, и дело даже не в ликинге. Маршрутизация между

VL>>> серыми

VL>>> и белыми адресами - это дорога в ад.
EG>> Hичего подобного. Hа самом деле между белыми и серыми адресами внутри
EG>> автономной системы разницы нет HИКАКОЙ.

VL> Как любой костыль, этот требует подпорок по всей сети. И почему ты
VL> ограничиваешься автономной системой? Оператор не в вакууме живет.

В IP нет принципиальных различий между публично маршрутизируемыми
адресами и немаршрутизируемыми, поэтому для маршрутизации никаких
костылей или граблей нет в этом месте. Мы же не о SOHO говорим.

Denis Ognewsky

unread,

Jan 21, 2017, 12:54:58 PM1/21/17

to

Hello, Anton Gorlov.
On 21.01.17 21:16 you wrote:

AG> Жалко,чтов isc dhcpd нет поддержки sql-бэкендов..

sql это медленно. я скриптом генерю конфиг.

Denis Ognewsky

unread,

Jan 21, 2017, 12:54:58 PM1/21/17

to

Hello, Anton Gorlov.
On 21.01.17 21:41 you wrote:

AG> Скажемтак- сейчас меня сильно бесит, что если что яне могу
AG> простымметодом найти кт оименно из клиентов флудит на тот или
AG> иной сервер.. не изучив netflow логи. То есть если что нет
AG> оперативности.

а как же tcpdump ?

Anton Gorlov

unread,

Jan 21, 2017, 1:14:58 PM1/21/17

to

Привет Denis!

21 янв 17 года (а было тогда 20:41)
Denis Ognewsky в своем письме к Anton Gorlov писал:

AG>> Жалко,чтов isc dhcpd нет поддержки sql-бэкендов..

DO> sql это медленно. я скриптом генерю конфиг.

Я скорее со строны логов dhcp
По логам не очень удобно искать когда та или иная лиза была освобождена.

Anton Gorlov

unread,

Jan 21, 2017, 1:14:58 PM1/21/17

to

Привет Denis!

21 янв 17 года (а было тогда 20:43)

Denis Ognewsky в своем письме к Anton Gorlov писал:

AG>> Скажемтак- сейчас меня сильно бесит, что если что яне могу
AG>> простымметодом найти кт оименно из клиентов флудит на тот или
AG>> иной сервер.. не изучив netflow логи. То есть если что нет
AG>> оперативности.

DO> а как же tcpdump ?

И как по IP за натом ты узнаешь кто из клиентов это есть?
Если в 1 IP натится 20 серых?

Denis Ognewsky

unread,

Jan 21, 2017, 2:04:58 PM1/21/17

to

Hello, Anton Gorlov.

On 21.01.17 23:05 you wrote:

AG>>> Жалко,чтов isc dhcpd нет поддержки sql-бэкендов..
DO>> sql это медленно. я скриптом генерю конфиг.

AG> Я скорее со строны логов dhcp По логам не очень удобно искать
AG> когда та или иная лиза была освобождена.

а это для чего ?

unread,

Jan 21, 2017, 6:34:58 PM1/21/17

to

21 янв 2017, суббота, в 20:16 NOVT, Anton Gorlov написал(а):

AG> Сейчас топология после прошлого админа только только вырисовывается.
AG> Hапримре у
AG> него сервре радиуса висел втом же влане чтои влан управлния свитчами
AG> доступа...и
AG> всё управление доступом было в 1 влане с маской /24.. Аха свыше 200
AG> железок в 1
AG> влане..

Это совершенно нормально в 2017. Если у тебя нынче сетка имеет хоть
какие-то проблемы с 250 свичами в менеджмент-влане, то у тебя или
допотопное железо, или почему-то 10-мегабитный линк с полудуплексом :-)

Hа самом деле можно даже 500 хостов в одном влане держать и ничего
плохого не будет. Hе конец 1990-х на дворе.

Eugene

Eugene Grosbein

unread,

Jan 21, 2017, 6:34:58 PM1/21/17

to

21 янв 2017, суббота, в 21:41 NOVT, Denis Ognewsky написал(а):

AG>> Жалко,чтов isc dhcpd нет поддержки sql-бэкендов..

DO> sql это медленно. я скриптом генерю конфиг.

Hичего не медленно. Выдача адреса 1000 одновременно ломящимся клиентам
в течение 2 секунд суммарно это медленно?

Eugene
--
И знатную леди от Джуди О'Греди
Hе сможет никто отличить.

Eugene Grosbein

unread,

Jan 21, 2017, 6:34:58 PM1/21/17

to

unread,

Jan 22, 2017, 4:34:58 AM1/22/17

to

Привет Denis!

22 янв 17 года (а было тогда 07:16)

Denis Ognewsky в своем письме к Anton Gorlov писал:

DO>>>>> sql это медленно. я скриптом генерю конфиг.
AG>>>> Я скорее со строны логов dhcp По логам не очень удобно искать
AG>>>> когда та или иная лиза была освобождена.
DO>>> а это для чего ?
AG>> Как минимум для отработки соответствующих запросов из органов.
AG>> Hужна инфгмация об том кому в тот или иной момен твремени
AG>> выдавался тот или иной IP

DO> аа. просто я по dhcp выдаю одни и теже ip-адреса. привязка кому какой,
DO> когда ip выдавался сразу в базе лежит.

У меня сейчас PPPoE.. оно было до меня и до IpOE пока руки не дошли.

Anton Gorlov

unread,

Jan 22, 2017, 4:34:58 AM1/22/17

to

Привет Denis!

22 янв 17 года (а было тогда 07:14)

Denis Ognewsky в своем письме к Anton Gorlov писал:

DO>>>>> а как же tcpdump ?
AG>>>> И как по IP за натом ты узнаешь кто из клиентов это есть? Если

AG>>>> в 1 IP натится 20 серых?

DO>>> тисипидампить до ната. или прямо на том же тазике где нат.
AG>> Э.. ну я посмотрю как ты на брасе запустишь tcpdump :) У меня не
AG>> тазики, а redback se100

DO> ну там есть чтото типа debug ip packet, хотя это очень не удобно. но
DO> опять же ни что не мешает отзеркалить нужный трафик на тазик с
DO> tcpdump'ом

УКху..если ест ьсвободые SPAN сессии.
на 65 их всего 2. 1 ушла на СОРМ,а 2 на DPI
2 в следующем месяце конечно освобожу - едет L3 свитчик на который вынесу
UPLINK брасов и туда же DPI и там же сделаю SPAN на DPI вместо 65.

Anton Gorlov

unread,

Jan 22, 2017, 4:34:58 AM1/22/17

to

Привет Eugene!

22 янв 17 года (а было тогда 05:24)
Eugene Grosbein в своем письме к Anton Gorlov писал:

AG>> Скажемтак- сейчас меня сильно бесит, что если что яне могу

AG>> простымметодом найти кт оименно из клиентов флудит на тот или
AG>> иной сервер.. не изучив netflow логи. То есть если что нет
AG>> оперативности.
EG> Так пускай трафик своих клиенто к своим серверам без трансляции
EG> и никого не слушай. Внутри своей автономной системы вообще не делай
EG> различий между белыми и серыми адресами, она ни для чего не нужна.

Вот так и хочу. Но не хочу всё в 1 vrf пихать... Поэтому и ищу как наиболее
правильно пустить трафик между 2 vrf

Anton Gorlov

unread,

Jan 22, 2017, 4:34:58 AM1/22/17

to

Привет Eugene!

22 янв 17 года (а было тогда 05:22)
Eugene Grosbein в своем письме к Denis Ognewsky писал:

AG>>> Жалко,чтов isc dhcpd нет поддержки sql-бэкендов..
DO>> sql это медленно. я скриптом генерю конфиг.

EG> Hичего не медленно. Выдача адреса 1000 одновременно ломящимся клиентам
EG> в течение 2 секунд суммарно это медленно?

Уху. У меня за 5-10 секундл успевает подняться порядка 2-3к PPPoE сессий с
авторизациями в радиусе - SQL (mysql)

Anton Gorlov

unread,

Jan 22, 2017, 4:34:59 AM1/22/17

to

Привет Eugene!

22 янв 17 года (а было тогда 05:19)
Eugene Grosbein в своем письме к Anton Gorlov писал:

AG>> Сейчас топология после прошлого админа только только

AG>> вырисовывается. Hапримре у него сервре радиуса висел втом же
AG>> влане чтои влан управлния свитчами доступа...и всё управление
AG>> доступом было в 1 влане с маской /24.. Аха свыше 200 железок в 1
AG>> влане..
EG> Это совершенно нормально в 2017. Если у тебя нынче сетка имеет хоть
EG> какие-то проблемы с 250 свичами в менеджмент-влане, то у тебя или
EG> допотопное железо, или почему-то 10-мегабитный линк с полудуплексом
EG> :-)

Ну..Пока ещё в сети ещё хватает DES-3200-52 с их вечнымми коллизиями маков.
Ну и опять же когда в сегменте бегает слишком много bpdu пакетов тоже не
хорошо.

EG> Hа самом деле можно даже 500 хостов в одном влане держать и ничего
EG> плохого не будет. Hе конец 1990-х на дворе.

Мб оно и так..но я предпочитаю всё таки влан упралвния сегментировать.

Anton Gorlov

unread,

Jan 22, 2017, 4:34:59 AM1/22/17

to

Привет Eugene!

22 янв 17 года (а было тогда 05:21)

Eugene Grosbein в своем письме к Anton Gorlov писал:

AG>> Жалко,чтов isc dhcpd нет поддержки sql-бэкендов..

EG> Если тебе нужен SQL-бекенд для DHCP, то зачем вообще держаться
EG> за ISC DHCPD, за какой надобностью? Бери FreeRADIUS с его
EG> DHCP-модулем, настраивай лазать в какую хочешь базу (хоть даже в MS
EG> SQL :-), работает.

Окак..Не знал что к freeradius приделали dhcp

А поддержка opt82 и запрсов с dhcp-релеев по юникасту в нём есть?

Eugene Grosbein

unread,

Jan 22, 2017, 5:34:57 AM1/22/17

to

22 янв 2017, воскресенье, в 13:16 NOVT, Anton Gorlov написал(а):

AG> Окак..Hе знал что к freeradius приделали dhcp
AG> А поддержка opt82 и запрсов с dhcp-релеев по юникасту в нём есть?

Да, у меня именно так и работает - с opt82 и юникастом с релеев.

Eugene
--
И кого не любишь, в лицо не знать, и смотреть на звезды и жить спокойно.

Eugene Grosbein

unread,

Jan 22, 2017, 5:54:59 AM1/22/17

to

22 янв 2017, воскресенье, в 13:25 NOVT, Anton Gorlov написал(а):

EG>> Это совершенно нормально в 2017. Если у тебя нынче сетка имеет хоть
EG>> какие-то проблемы с 250 свичами в менеджмент-влане, то у тебя или
EG>> допотопное железо, или почему-то 10-мегабитный линк с полудуплексом
EG>> :-)

AG> Hу..Пока ещё в сети ещё хватает DES-3200-52 с их вечнымми коллизиями
AG> маков.

А можно ссылочку на информацию о том, что у DES-3200 коллизии FDB?

AG> Hу и опять же когда в сегменте бегает слишком много bpdu пакетов тоже не
AG> хорошо.

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

EG>> Hа самом деле можно даже 500 хостов в одном влане держать и ничего
EG>> плохого не будет. Hе конец 1990-х на дворе.

AG> Мб оно и так..но я предпочитаю всё таки влан упралвния сегментировать.

Hу так и мы сегментируем. 250 свичей в одном сегменте /24,
следующие 250 в другом /24 и так далее. Когда у тебя десятки тысяч
свичей, такая сегментация вполне нормально работает.

Eugene

Anton Gorlov

unread,

Jan 22, 2017, 6:04:58 AM1/22/17

to

Привет Eugene!

22 янв 17 года (а было тогда 16:08)

Eugene Grosbein в своем письме к Anton Gorlov писал:

AG>> Окак..Hе знал что к freeradius приделали dhcp
AG>> А поддержка opt82 и запрсов с dhcp-релеев по юникасту в нём есть?

EG> Да, у меня именно так и работает - с opt82 и юникастом с релеев.

Ооок.. Ща пойду читать про dhcp в freeradius..
1 фиг мне надо всопнмить как готовить фрирадиус, так как на текущем почеу-то в
табицу сессий не попадают маки клиентов..хотя с железки они летят..

Anton Gorlov

unread,

Jan 22, 2017, 7:54:59 AM1/22/17

to

Привет Eugene!

22 янв 17 года (а было тогда 16:25)

Eugene Grosbein в своем письме к Anton Gorlov писал:

EG>>> Это совершенно нормально в 2017. Если у тебя нынче сетка имеет

EG>>> хоть какие-то проблемы с 250 свичами в менеджмент-влане, то у
EG>>> тебя или допотопное железо, или почему-то 10-мегабитный линк с
EG>>> полудуплексом

EG>>> :-)
AG>> Hу..Пока ещё в сети ещё хватает DES-3200-52 с их вечнымми

AG>> коллизиями маков.
EG> А можно ссылочку на информацию о том, что у DES-3200 коллизии FDB?

Где-то на наге инфа на эту тему была и тамже скриптики для тестов. Ну и ещёююу
меня в сети часто попадаюся китайские сетвки у абонентв с одинаковыми маками. В
осном на платах гигабайт и asrock
На стенде удавалось воспроизвести. Сейчас на доступы SNR ставим.

unread,

Jan 24, 2017, 6:24:58 AM1/24/17

to

Привет Denis!

23 янв 17 года (а было тогда 06:19)

Denis Ognewsky в своем письме к Anton Gorlov писал:

DO>>>>> аа. просто я по dhcp выдаю одни и теже ip-адреса. привязка

DO>>>>> кому какой, когда ip выдавался сразу в базе лежит.

AG>>>> У меня сейчас PPPoE.. оно было до меня и до IpOE пока руки не
AG>>>> дошли.
DO>>> PPPoE прекрасно хранит лог в таблице radacct благодаря радиусу.
DO>>> впрочем вам виднее чего и как у вас устроено.
AG>> Да. Записи есть, но нет инфомации об маке клиента. А иногда
AG>> бывает нужна. Просто пустой столбец вместо маков.

DO> это вроде от nas'а зависит. он должен передавать mac клиента.
DO> покрутите опции на той стороне.

Оно его передаёт, но в своей vendor specific опции
AVP: l=25 t=Vendor-Specific(26) v=Ericsson, Inc. (formerly 'RedBack
Networks')(2352)

Сижу вкуриваю как в freeradius получить значение этой опции

Anton Gorlov

unread,

Jan 24, 2017, 6:24:58 AM1/24/17

to

Привет Eugene!

23 янв 17 года (а было тогда 06:59)
Eugene Grosbein в своем письме к Anton Gorlov писал:

DO>>> PPPoE прекрасно хранит лог в таблице radacct благодаря радиусу.
DO>>> впрочем вам виднее чего и как у вас устроено.
AG>> Да. Записи есть, но нет инфомации об маке клиента. А иногда

AG>> бывает нужна. Просто пустой столбец вместо маков.
EG> Hу так надо вправить мозги BRAS-у, чтобы MAC клиента передавал
EG> в атрибуте Calling-Station-Id (31).

Ещё бы мело оно это..

radius attribute calling-station-id format ?
agent-circuit-id Build Calling-ID string with agent circuit id
agent-remote-id Build Calling-ID string with agent remote id
description Build Calling-ID string with VC-description
hostname Build Calling-ID string with host name
slot-port Build Calling-ID string with slot-port info

Мак оно передаёт, но в своём аттрибуте, vendor-specific

AVP: l=25 t=Vendor-Specific(26) v=Ericsson, Inc. (formerly 'RedBack
Networks')(2352)

AVP Type: 26
AVP Length: 25
VSA: l=19 t=Mac-Addr(145): e0-3f-49-52-c2-fd

Вот сижу соображаю как мне вот это получить и загнать в calledstationid или
какое либо другое поле..

Anton Gorlov

unread,

Jan 24, 2017, 6:24:58 AM1/24/17

to

Привет Eugene!

23 янв 17 года (а было тогда 07:08)

Eugene Grosbein в своем письме к Anton Gorlov писал:

Не совсем понимаю как оно взлетит. Проблема в том, что на адаптере адрес SIP
шлюза
172.25.255.254 и этот же IP указан в качестве ethernet gateway на самом
адаптере

AG>> Сейчас побаболь - это IP-телефония с сетью 172.25.255.240/16

AG>> которая по всему городу в 1 влане и порой особо ушлые абоненты по
AG>> ней гоняют между собой трафик. Что тут поделать пока даже не
AG>> представляю..учитывая что там овер 2к абонентов по всему городу и
AG>> все настройки вбиты статиком в адаптеры. Благо оно хоть в

AG>> отдельном влане от PPPoE (PPPoЕ у меня по влану на дом/доступ)

EG> В циске по дефолту работает arp proxy. Делаешь на циске отдельный
EG> interface Loopback10 с ip address 172.25.255.240 255.255.255.255
EG> и сегментируешь VoIP-сетку на нужное тебе количество вланов и
EG> соответствующие интерфейсы в циске прописываешь как ip unumbered
EG> Loopback10 плюс суда же суешь ip verify unicast source reachable-via
EG> rx.
EG> Роутинг создаёшь командами типа ip route 172.25.255.242 255.255.255
EG> Vlan123. Вуаля! Уже никто ничего левого не гоняет по влану, а при
EG> большом желании на вланы можно дополнительные ACL навесить, но
EG> основную проблему ip verify снимает автоматически.
EG> А голос за счёт arp proxy всё будет продолжать работать как ни в чём
EG> не бывало - голосовой шлюз посылает ARP-запрос на прописанный
EG> статически у себя адрес роутера, а циска отвечает ему своим
EG> MAC-адресом и дальше ethernet-трафик ходит с MAC голосового шлюза на
EG> MAC циски и обратно, как и до этого.

Dmitriy Yermakov

unread,

Jan 24, 2017, 7:44:58 AM1/24/17

to

Hello, Anton!

At 24 Jan 17 13:40:10, Anton Gorlov wrote to Eugene Grosbein:

AG> Мак оно передаёт, но в своём аттрибуте, vendor-specific

AG> VSA: l=19 t=Mac-Addr(145): e0-3f-49-52-c2-fd

В словаре есть - dictionary.redback

AG> Вот сижу соображаю как мне вот это получить и загнать в calledstationid
AG> или какое либо другое поле..

примерно так
%{Called-Station-Id} := %{Mac-Addr}

/dyer

Anton Gorlov

unread,

Jan 24, 2017, 9:04:57 AM1/24/17

to

Привет Dmitriy!

24 янв 17 года (а было тогда 15:20)
Dmitriy Yermakov в своем письме к Anton Gorlov писал:

DY> At 24 Jan 17 13:40:10, Anton Gorlov wrote to Eugene Grosbein:

AG>> Мак оно передаёт, но в своём аттрибуте, vendor-specific
AG>> VSA: l=19 t=Mac-Addr(145): e0-3f-49-52-c2-fd

DY> В словаре есть - dictionary.redback

AG>> Вот сижу соображаю как мне вот это получить и загнать в

AG>> calledstationid или какое либо другое поле..
DY> примерно так
DY> %{Called-Station-Id} := %{Mac-Addr}

Аха..Уже тоже стряхнул пыль с документов по радиусу и нашёл сиё.
В общем спасибо всем за помощь.

Eugene Grosbein

unread,

Jan 24, 2017, 9:44:58 AM1/24/17

to

24 янв 2017, вторник, в 14:37 NOVT, Anton Gorlov написал(а):

AG> Hе совсем понимаю как оно взлетит. Проблема в том, что на адаптере адрес
AG> SIP
AG> шлюза
AG> 172.25.255.254 и этот же IP указан в качестве ethernet gateway на самом
AG> адаптере

Hу значит этот адрес на лупбек поставь, маской 255.255.255.255.
И почитай про arp proxy чего-нибудь.

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

Denis Ognewsky

unread,

Jan 24, 2017, 10:14:58 AM1/24/17

to

Hello, Anton Gorlov.

On 24.01.17 16:13 you wrote:

DO>>>>>> аа. просто я по dhcp выдаю одни и теже ip-адреса. привязка
DO>>>>>> кому какой, когда ip выдавался сразу в базе лежит.
AG>>>>> У меня сейчас PPPoE.. оно было до меня и до IpOE пока руки не
AG>>>>> дошли.
DO>>>> PPPoE прекрасно хранит лог в таблице radacct благодаря радиусу.
DO>>>> впрочем вам виднее чего и как у вас устроено.
AG>>> Да. Записи есть, но нет инфомации об маке клиента. А иногда
AG>>> бывает нужна. Просто пустой столбец вместо маков.
DO>> это вроде от nas'а зависит. он должен передавать mac клиента.
DO>> покрутите опции на той стороне.

AG> Оно его передаёт, но в своей vendor specific опции AVP: l=25
AG> t=Vendor-Specific(26) v=Ericsson, Inc. (formerly 'RedBack
AG> Networks')(2352) Сижу вкуриваю как в freeradius получить значение
AG> этой опции

добавить словарь ? у меня какие то были от se100.

Anton Gorlov

unread,

Jan 24, 2017, 12:44:58 PM1/24/17

to

Привет Denis!

24 янв 17 года (а было тогда 18:00)
Denis Ognewsky в своем письме к Anton Gorlov писал:

DO>>>>> PPPoE прекрасно хранит лог в таблице radacct благодаря

DO>>>>> радиусу. впрочем вам виднее чего и как у вас устроено.

AG>>>> Да. Записи есть, но нет инфомации об маке клиента. А иногда
AG>>>> бывает нужна. Просто пустой столбец вместо маков.
DO>>> это вроде от nas'а зависит. он должен передавать mac клиента.
DO>>> покрутите опции на той стороне.
AG>> Оно его передаёт, но в своей vendor specific опции AVP: l=25
AG>> t=Vendor-Specific(26) v=Ericsson, Inc. (formerly 'RedBack
AG>> Networks')(2352) Сижу вкуриваю как в freeradius получить значение
AG>> этой опции

DO> добавить словарь ? у меня какие то были от se100.

Дасловарик откпался и в родной поставке freeradius.
Просто честно говорю - я с радиусом до этого не особо плотно работал и забыл
уже что там было и как.. в частности про словари.

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

Anton Gorlov

unread,

Jan 24, 2017, 12:44:58 PM1/24/17

to

Привет Eugene!

24 янв 17 года (а было тогда 20:34)
Eugene Grosbein в своем письме к Anton Gorlov писал:

AG>> Hе совсем понимаю как оно взлетит. Проблема в том, что на

AG>> адаптере адрес SIP шлюза 172.25.255.254 и этот же IP указан в
AG>> качестве ethernet gateway на самом адаптере
EG> Hу значит этот адрес на лупбек поставь, маской 255.255.255.255.
EG> И почитай про arp proxy чего-нибудь.

То что его на лупбэк это понятно. Вопрос в том как мне дальше трафик с циски
завернуть на VoIp сервер и какой адрес вешатьна VoIp сервер.

Eugene Grosbein

unread,

Jan 25, 2017, 1:44:57 AM1/25/17

to

24 янв 2017, вторник, в 21:29 NOVT, Anton Gorlov написал(а):

AG>>> Hе совсем понимаю как оно взлетит. Проблема в том, что на
AG>>> адаптере адрес SIP шлюза 172.25.255.254 и этот же IP указан в
AG>>> качестве ethernet gateway на самом адаптере
EG>> Hу значит этот адрес на лупбек поставь, маской 255.255.255.255.
EG>> И почитай про arp proxy чего-нибудь.

AG> То что его на лупбэк это понятно. Вопрос в том как мне дальше трафик с
AG> циски
AG> завернуть на VoIp сервер и какой адрес вешатьна VoIp сервер.

Я думал, у тебя циска работает VoIP-сервером или прокси.
Если нет, то на лупбек не надо вешать адрес VoIP-сервера
и менять его тоже не надо, пусть будет какой сейчас работаеть.

Циске на лупбек повесить другой адрес из сети, за счет arp proxy
роутинг трафика будет работать как ни в чём не бывало.

Eugene
--
И знатную леди от Джуди О'Греди
Hе сможет никто отличить.

Victor Kakhnych

unread,

Jan 25, 2017, 4:14:58 AM1/25/17

to

Hello Anton!

24 Jan 17 13:40, you wrote to Eugene Grosbein:

AG> Ещё бы мело оно это..

AG> radius attribute calling-station-id format ?
AG> agent-circuit-id Build Calling-ID string with agent circuit id
AG> agent-remote-id Build Calling-ID string with agent remote id
AG> description Build Calling-ID string with VC-description
AG> hostname Build Calling-ID string with host name
AG> slot-port Build Calling-ID string with slot-port info

AG> Мак оно передаёт, но в своём аттрибуте, vendor-specific

AG> AVP: l=25 t=Vendor-Specific(26) v=Ericsson, Inc. (formerly 'RedBack
AG> Networks')(2352) AVP Type: 26 AVP Length: 25

AG> VSA: l=19 t=Mac-Addr(145): e0-3f-49-52-c2-fd

AG> Вот сижу соображаю как мне вот это получить и загнать в
AG> calledstationid или какое либо другое поле..

У меня так в radiusd.conf:

attr_rewrite mac_to_caller_id {
attribute = Calling-Station-Id
searchin = packet
searchfor = ""
replacewith = "%{Client-Mac-Address}"
ignore_case = yes
new_attribute = yes
max_matches = 1
append = no
}

Victor