Перейти до

Как правильней связать vlan per user и Ubilling.

l1ght

Автор: l1ght,
в Stargazer Ubilling

 Share Подписчики 2

Рекомендованные сообщения

KaYot

KaYot 3 730

Опубліковано:
Опубліковано: (відредаговано)

 

Циска хуже. Чем? Чем линукс. Хотя бы тем что это лишняя точка отказа в цепочке прохождения трафика.
Может у Вас это и так. А как у Вас решаеться задача с резервированием ? У нас, если падает один брас, то сразу же все юзеры бегут в другой брас. Если выключаеться БД сервер, или любой другой в "связке" - всеравно юзеры работают. 

 А у Вас, если потечет память с с ацелем, то что делают юзеры ?

 

Переключаются автоматом на соседний сервер с accel. Странно, да?

Ну и аццель почему-то не течет и не падает, за год он ребутился несколько раз только для обновления софта.

 

Число терминируемых вланов у б/у цисок невелико(~750 для спокойной жизни), с точки зрения масштабируемости это грусть.
С точки зрения масштабируемости, можно 37 на 45 версию поменять. А вот как добиться производительности в миллионы pps на линупсе - это грусть.

 

Заветные мильены PPS - это несколько десятков гигабит трафика. И соответственно 10ки тысяч онлайн-юзеров. Чувствуете масштабы, да?

+ на тупой маршрутизации(а у нас ведь банальная маршрутизация+шейпинг) "этот наш линукс" запросто лопатит эти самые мильены PPS.

+ балансировка и резервирование. У софта все это делается by design, а у цисок ручным перебрасыванием вланов между железками, да? :)

+ а кто сказал что у 45xx есть какой-то запас по тем же вланам? 2к(причем не онлайн а суммарно), это смешные цифры для "масштабируемости". Даже у шкафчиков 6500/7600 их толи 2к, толи 4к. Не фонтан.

Ну и что б добить окончательно - вы подменяете понятия. Циска ведь в вашей схеме просто терминирует вланы. Дальше трафик все равно должен пройти через тазик, для учета/доступа/шейпинга. Зачем тут циска, для красивого бизнес-плана? :)

 

А когда ipv6 в ворота постучит(он таки постучит, через год-два-три), 
Dual-Stack будем юзать, у цисок с этим проблем нет.

 

В смысле нет проблем? Пробормочите заклинание, и ваша циска 3550/3750/4500 научится делать unnumbered для IPv6? Хренушки. Придется продавать машину и бежать за б\у MX80.

 

Но сама по себе она ведь ничего не умеет делать, верно? Считать трафик, разрешать доступ, шейпить etc - нужны какие-то модули, скрипты и костыли. Логичнее вместо этого использовать готовое решение, тот же accel например. 
Может все  что надо и даже больше чем линупс.

 

Т.е. по вашему, BSD умеет быть BRASом сама по себе? Научите очередному заклинанию, очень интересно.
Відредаговано KaYot
Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 55
  • Створено
  • Остання відповідь

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

KaYot

Я не намекаю, я кричу об этом в голос)) Если на каждого юзера отдельный влан - не нужны никакие классические костыли, авторизация проводится именно по номеру влана, и 'мозг' умеющий opt82(в который

Abram

Вы путаете красное с мягким. Удачи.

KaYot

Повторюсь, путаете технологии и не понимаете сути явления. Зачем это делать на доступе, если можно сделать в любом удобном месте? Хоть на агрегации, хоть в ядре, но лучше всего - прямо на BRASе.  

loki

loki 86

Опубліковано:
Опубліковано: (відредаговано)

Вы  SVI не путайте с  802.1q тегами. А еще у  "шкафчиков" есть разные супервизоры. И ваши опусы про вланы. это наверное для 3550 серии цисок, которые ставят обычно в сетки до 1К юзеров. 

Ваша философия костылинга привела Вас к той схеме, которая вам приемлема. И, ессесно минусов у софт решений нет  :D

Я противник того, чтоб вланы терминировать на софте, этому есть свои железки. 

 балансировка и резервирование

PBR + VRRP

root@bras2:/ # netstat -w1 -h
            input        (Total)           output
   packets  errs idrops      bytes    packets  errs      bytes colls
      292k     0     0       208M       285k     0       206M     0
      276k     0     0       197M       270k     0       195M     0
      259k     0     0       183M       253k     0       182M     0
      264k     0     0       190M       257k     0       189M     0

root@bras2:/ # uptime
10:32PM  up 155 days, 18:26, 2 users, load averages: 3.36, 2.43, 1.77

Вот только что снял стату по одному из  трех брасов. На этом в пиках под 500К ппс. И все это на  Intel® Xeon® CPU     X3430

Чувствуешь разницу, да ? 

 

 Отсыл unnumbered для ipv6 вообще неуместен.

Т.е. по вашему, BSD умеет быть BRASом сама по себе?

Сама по себе это как ?  Типа как Установка-далее-далее ?? Ну тогда типа того, да.

Відредаговано loki
Ссылка на сообщение
Поделиться на других сайтах
KaYot

KaYot 3 730

Опубліковано:
Опубліковано:

Вы  SVI не путайте с  802.1q тегами. А еще у  "шкафчиков" есть разные супервизоры. И ваши опусы про вланы. это наверное для 3550 серии цисок, которые ставят обычно в сетки до 1К юзеров. 

Ваша философия костылинга привела Вас к той схеме, которая вам приемлема. И, ессесно минусов у софт решений нет  :D

Ага, понял. Вы по аналогии с реализованными ранее костылями собираетесь делать схему без SVI на клиента. Удачи вам в начинаниях, я затыкаюсь.

 


Вот только что снял стату по одному из  трех брасов. На этом в пиках под 500К ппс. И все это на  Intel® Xeon® CPU     X3430

Чувствуешь разницу, да ? 

...

поскипано
Честно - вообще не понял о чем это. Какой-то поток сознания.

             


			
		


		

		
	


	

	

		
Ссылка на сообщение

		
			
		
		
		

		
			
Поделиться на других сайтах

			

	

		
	



	



					
					
					
          
    
        
          	

			
        
    


				

					

					
          			
					






					
					
					
          

				
			
			



		

	


	
		

			


	
	

		

	
	
	
	
	
		
        
		

			
				
				



	
	
		

			
				
Создайте аккаунт или войдите в него для комментирования

				
Вы должны быть пользователем, чтобы оставить комментарий

			
	
			

				

					

						
Создать аккаунт

						
Зарегистрируйтесь для получения аккаунта. Это просто!

						
							
						
						Зарегистрировать аккаунт
					

					

						
Вхід

						
Уже зарегистрированы? Войдите здесь.

						Войти сейчас
					

				

			

		

	


			
		

	

	
		

			
				

					


    
          Share
    

    

				

			
			

				


	

	
		Подписчики
		2
	


			

			
		

	







	

		
			
				Перейти до переліку тем
			
		
	

	




						


	

		
    
			
				
					
					
  • 


    
	
		Зараз на сторінці
	
	
		  0 користувачів
	

    

    
	
		
    Немає користувачів, що переглядають цю сторінку.
    
	

    • 
				
					
					
  • 

    Схожий контент
    

    
	
      
	
		
    • 
			
      
				


	
		grach_witch_cheese
	

			
      
			
      
				
      ubilling+accel-ppp-ipoe+option82
      
				Від 

grach_witch_cheese
      
				
					
      
						Вітаю, колеги!

      


	Маю наступну схему:

      


	
		DHCP-сервер: Accel-PPP (IPoE)
	 
	
		DHCP-Relay: MikroTik
	 
	
		RADIUS: Запущений безпосередньо на сервері uBilling
	 



	Зараз авторизація абонентів здійснюється за MAC-адресою, але планується перехід на авторизацію через Option 82.

      


	У документації uBilling наведені приклади конфігурацій, коли DHCP-сервер працює локально (на самому uBilling) і містить відповідні шаблони для обробки Option 82.

      


	Однак немає чіткої інформації про використання Option 82 при віддаленому DHCP-сервері, зокрема, коли Accel-PPP використовується як DHCP-сервер у режимі remote та налаштований через Купаген.

      


	Питання:

      


	
		Чи можливо використовувати Accel-PPP як віддалений DHCP-сервер з авторизацією через Option 82?
	 
	
		Якщо так, то де відбувається парсинг значень Remote-ID і Circuit-ID? Де в цьому випадку мають зберігатися шаблони для Option 82?
	 



	Буду вдячний за роз'яснення або посилання на відповідні приклади.

      

					
      
				
			
      
		
      • 
	
		
    • 
			
      
				


	
		nightfly
	

			
      
			
      
				
      Релізи Ubilling 2025
      
				Від 

nightfly
      
				
					
      
						Ubilling 1.5.2 rev 9302 Book of Endings

      


	 

      


	
		Зміни в структурі БД.
	 
	
		alter.ini: нова опція FASTPROFITCALC_ENABLED, що вмикає швидкий підрахунок прибутку.
	 
	
		alter.ini: нова необов'язкова опція KARMA_IN_PROFILE що вмикає показ карми в профілі користувача.
	 
	
		alter.ini: нова опція SWITCHES_AUTH_ENABLED, що вмикає довідник даних авторизації пристроїв.
	 
	
		alter.ini: нова опція PON_SCRIPTS_ENABLED, що вмикає підтримку скриптів OLT в ПОНізаторі.
	 
	
		alter.ini: нова опція PON_ONU_FDB_SELFFILTER, що вмикає фільтр MAC-ів при відображенні FDB за ONU.
	 
	
		alter.ini: нова опція USERBYIP_ENABLED, що вмикає виклик userbyip в RemoteAPI.
	 
	
		alter.ini: пачка нових опцій PB_FASTURL_*, що керують поведінкою модулю відсилання коротких посилань на оплату.
	 
	
		Модуль PONizer: виправлена помилка зникнення PON інтерфейсів при опиті BDCOM GP3600
	 
	
		Модуль “Профіль користувача”: для опису плагінів профілю та оверлеїв на кшталт “чорної магії” тепер опційно можливо вказувати link_target.
	 
	
		Модуль “Панель задач”: для опису елементів панелі задач, тепер опційно можна вказувати LINK_TARGET.
	 
	
		Модуль Записи телефонних розмов: вирішено проблеми швидкодії, при перегляді списку записів дзвінків.
	 
	
		Модуль “Записи телефонних розмов”: більше не призводить до вичерпання пам'яті процесу, при перегляді великих архівів дзвінків.
	 
	
		Модуль “Записи телефонних розмов”: новий аудіо-плеєр для прослуховування записів з візуалізацією аудіо-хвилі.
	 
	
		Модуль “Пошук оплат”: реалізовано можливість швиденького підрахунку прибутку по обраних чекбоксами платежах.
	 
	
		Модуль УКВ: реалізовано можливість швиденького підрахунку прибутку по обраних чекбоксами платежах.
	 
	
		Модулі Мапа обладнання та користувачів: трішки вичищено код. Ліпше не стало.
	 
	
		Модуль “Мапа будинків”: поле пошуку при розташуванні будинку, тепер попередньо заповнено локацією, при переході за посиланням “розташувати на мапі”.
	 
	
		Модуль “Панель задач”: опція TB_QUICKSEARCH_INLINE змінила свою поведінку, та може тепер приймати значення 0|1|2.
	 
	
		Модуль “Звіт по трафіку”: виправлено проблему відображення графіків OphanimFlow для NAS на роздільних здатностях менше ніж FullHD.
	 
	
		Кабінет користувача: в модулі “Відеоспостереження” відображення попереднього перегляду каналів користувача, стало трішки притомнішим.
	 
	
		Сховище зображень: трішки покращено поведінку форми завантаження.
	 
	
		RemoteAPI: новий виклик onusigcompressor, що радикально стискає розпухаючі дані історії сигналів ONU.
	 
	
		RemoteAPI: новий виклик pbxmonrefill, що оновлює кеш записів телефонних розмов.
	 
	
		RemoteAPI: новий виклик userbyip, що повертає дані про користувача за його IP.
	 
	
		OpenPayz: в бекенді та фронтенді platon виправлено проблему диких заокруглень, при вказанні зовнішньої комісії.
	 



	 

      


	Повний чейнджлог 

      


	Оновлена демка

      


	 

      


	

      

					
      
				
			
      
		
      • 
	
		
    • 
			
      
				


	
		ppv
	

			
      
			
      
				
      Проблеми з відображення сигналів на OLT BDCOM P3310B та P3608-2TE
      
				Від 

ppv
      
				
					
      
						Після оновлення до 1.5.1 не відображаються сигнали на

      


	OLT BDCOM P3310B (Device version10.1.0B)

      


	

      


	та

      


	P3608-2TE (Firmware Version10.1.0E). 

      


	

      


	3310C та P3608B ніяких проблем немає, знімає все добре. 

      


	З GPON3600-8 все зрозуміло будуть виправлення в Ubilling: 1.5.2.

      


	 

      


	Може в когось було щось подібне? Хочу знати куди копати.

      

					
      
				
			
      
		
      • 
	
		
    • 
			
      
				


	
		Чучундра
	

			
      
			
      
				
      Прокинути пачку VLAN-ів на ONU в BDCOM GP3600
      
				Від 

Чучундра
      
				
					
      
						Добрий день.

      


	 

      


	Буду вдячний якщо хтось поділиться робочим конфігом щоб прокинути на ЛАН порт ОНУ декілька VLAN-ів з тегами.

      

					
      
				
			
      
		
      • 
	
		
    • 
			
      
				


	
		mac
	

			
      
			
      
				
      Глюк з MAC адресом ONU та шлях усунення
      
				Від 

mac
      
				
					
      
						Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.

      


	olt - bdcom gepon.

      


	Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.

      


	Можливо snmpwalk тригериться на якомусь символі, мені невідомо.

      


	 

      


# tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241
...
    olt.snmp > ub.47940: [udp sum ok]  { SNMPv2c C="*****" { GetResponse(44) R=93278354  E:3320.101.10.4.1.1.241="8LO"W*" } } 
    ub.47940 > olt.snmp: [udp sum ok]  { SNMPv2c C="*****" { GetNextRequest(34) R=93278355  E:3320.101.10.4.1.1.241 } } 

snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1
SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*"

snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1
SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A


	 

      


	Це стосується таких параметрів у snmp конфізі bdcom
      
	 

      


[signal]
MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1"
[misc]
ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"


	 

      


	За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()

      


	Це працює. Мабуть станеться у нагоді:

      


	 

      


# diff api.ponbdcom.php{.new,.bak}
37c37
<                     $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE);
---
>                     $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE);
91c91
<         $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);
---
>         $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);


	 

      


	P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...

      


	 

      


	

      

					
      
				
			
      
		
      • 
	
	
    

    • 
				
			
		

	


					

					


	

		
		
			
			

		
		
		


	


					

				

			

			
		

		
			
            


			


	

		×
		

			
				

					
				

			

			
		

	






	

		×
		

			
    
				
  • Створити нове...
    •