Перейти до

не работает DHCP snooping на BDCOM


hillers

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

Работаем по технологии IPoE. Есть 4 головы BDCOM - на 16 и на  8 направлений.

Все четыре BDCOM включены в один свитч.

Столкнулись со следующей проблемой - одновременно начинает колбасить все BDCOM. Загрузка процессоров подскакивает до 100% на всех головах одновременно.

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

 

 

Провели эксперимент - Схема включения:

Router TP-Link wr941nd   <---> ONU BDCOM P1501C1 <---> BDCOM P3310 <---> BRAS Ericsson SE-100 <----> NAS <----> Internet
 
 
При подключении Router TP-Link wr941nd в порты с ДХЦП-сервером  на BDCOM P3310 нет никакой реакции, но CPU самого BDCOM P3310 еще не растет.
 
По истечении ~ 4 мин. приходят сообщения о попытках отбросить ДХЦП-пакеты:
 
BDCOM_4#Dec  9 17:28:14 %FILTER-4-UNBLOCK: [dhcp]Source MAC Address b048.7abf.8aa0 vlan 331 600s on EPON0/4
Dec  9 17:28:14 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:14 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:14 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:16 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:17 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:17 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:17 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:18 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:20 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:20 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:20 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:20 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:20 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:21 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:23 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:23 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:23 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:23 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:23 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
Dec  9 17:28:23 DHCPR: server DHCP packet received from untrusted server(Interface: EPON0/4 ,IP: 192.168.0.1,MAC:b0:48:7a:bf:8a:a0),dropped
 
При этом пока БДКОМ еще работает - пингуется по 0,5мс.
Проходит еще ~4-5 минут. CPU BDCOM P33100  взлетает до 100%, при этом наблюдаем почти 100% потери пакетов ICMP.
При этом все остальные BDCOM-ы также начинают тормозить и CPU у них вырастает до 100%. На других BDCOM-ах в логах нет никаких сообщений.
 
Такая ситуация длится до тех пор пока не отключаем Router TP-Link wr941nd  от  ONU BDCOM P1501C1.
Как только это сделали отключение, буквально через ~30-40 сек. восстанавливаться нормальная работа всех BDCOM-ов.
 
 
Вот настройки из конфига
 
BDCOM_1x8#sh ip dhcp-relay snooping
 
ip dhcp-relay snooping
ip dhcp-relay snooping vlan  331
ip arp inspection vlan  331
ip verify source vlan  331
ip dhcp-relay snooping log
DHCP Snooping trust interface:
   GigaEthernet0/1
 
ARP Inspect trust interface:
   GigaEthernet0/1
 
IP source guard trust interface:
   GigaEthernet0/1
 
DHCP Snooping deny interface:
 
ip dhcp-relay snooping db-file /dhcpr-database

 

 

Кто-то встречался  с подобным явлением? Как бороться?

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

Для начала уберите ip arp inspection vlan  331 и ip dhcp-relay snooping log. ISG можно оставить - полезная штука.

благодарю за советы, проведем эксперименты, по результатам отпишусь

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Для начала уберите ip arp inspection vlan  331 и ip dhcp-relay snooping log. ISG можно оставить - полезная штука.

 

 

В общем, провели эксперимент - убрали ip arp inspection vlan  331 и ip dhcp-relay snooping log. Стало работать лучше, подключили роутер к ОНУшке неправильно, так чтобы DHCP роутера смотрело в сторону сети. Разогнать процессор БДКОМа до 100% не удалось, ОДНАКО, вечером, когда много пользователей онлайн ситуация повторилась - все 4 OLT BDCOM ушли в 100% загрузку. Помогает краткосрочное отключение одного из ОЛТ, тогда через пару минут спадает загрузка всех ОЛТ.

Загрузка процессора одного из БДКОМов

Bezimyanni_2968766_19829956.jpg

Конфиг прилагается.

bdcom2_20151211.txt

Відредаговано hillers
Ссылка на сообщение
Поделиться на других сайтах
  • 2 weeks later...
Пока удалось решить данную проблему включением  БДКОМ-ов  через дополнительный свитч 

Конфигурация данного коммутатора  отличается от С704 (в который раньше были включены BDCOMы) включенным DHCP-snooping binding.

 

 

Конфигурация портов:

Interface Ethernet1/25

 description BDCOM_1x8

 ip multicast destination-control access-group 6000

 switchport mode trunk

 switchport trunk allowed vlan 303;331;400

 ip access-group 100 in

 loopback-detection specified-vlan 303;331;400

 loopback-detection control shutdown

 arp-guard ip 192.168.7.1

 arp-guard ip 192.168.6.1

 arp-guard ip 192.168.5.1

 arp-guard ip 192.168.4.1

 arp-guard ip 192.168.3.1

 arp-guard ip 192.168.11.1

 arp-guard ip 192.168.10.1

 arp-guard ip 10.100.0.10

 arp-guard ip 192.168.2.1

 arp-guard ip 192.168.1.1

 arp-guard ip 192.168.0.1

 arp-guard ip 10.100.2.9

 arp-guard ip 10.0.0.1

 arp-guard ip 10.120.0.1

 arp-guard ip 10.100.2.7

 arp-guard ip 10.100.2.1

 ip dhcp snooping action shutdown recovery 180

 

 

на С704:  (в который раньше были включены BDCOMы)

 

Interface Ethernet4/11

 description BDCOM_1x8

 ip multicast destination-control access-group 6011

 switchport mode trunk

 switchport trunk allowed vlan 303;331;400

 ipv6 access-group 600 in

 loopback-detection specified-vlan 300;303;331-332;400

 loopback-detection control shutdown

 ipv6 security-ra enable

 arp-guard ip 10.100.0.10

 arp-guard ip 192.168.2.1

 arp-guard ip 192.168.1.1

 arp-guard ip 192.168.0.1

 arp-guard ip 10.120.0.1

 arp-guard ip 10.0.0.1

 arp-guard ip 10.100.2.1

 anti-arpscan trust supertrust-port

 

Уже более 5 дней наблюдаем нормальную работу БДКОМ-ов.

До этого каждый день, по несколько раз возникал некий штром со 100% загрузкой процессоров всех БДКОМов одновременно.

Похоже что есть ошибка в прошивке БДКОМ-ов относительно DHCP-snooping.

 

Какие может будут Ваши идеи по данному оборудованию?
Ссылка на сообщение
Поделиться на других сайтах

Изолировать порты свитча, в который воткнуты головы. Или еще правильнее рассадить в разные vlan'ы клиентов с разных голов, а то и деревьев. Описаны основные признаки шторма.

 

P.S. Loopback-detect и прочий функционал в режиме shutdown на агрегаторе трафика олтов - это круто. 

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

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

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

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

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

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

Вхід

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

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

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

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

    • Від tadesky
      Продам б/в BDCOM P3616-2TE OLT . 

      Повністю робочий, без нюансів, знятий після модерну.  Комплектований резервним БЖ. 
      Оціночна вартість 40 тис. грн.

      За потреби можна комплектувати SFP Picotel EPON SFP PX++ = 600 грн/шт. 
       
      Пишіть в особисті. 
       
    • Від forella
      Имеется такая ситуация.
      топология: абонент---ону---bdcom p3310---cisco 4948--- далее 2 пути, 99% идут на линуксовый шлюз, оставшиеся(избранные, назовем их так) 1% на микротик по оттдельному vlan.
      олт 13шт. каждая олт оттдельным портом на 4948 подключена. все аналогично работают как описано выше.
      наблюдается вот такая ситуация на циско:
       
      *Apr 20 03:17:28.873: %C4K_EBM-4-HOSTFLAPPING: Host 78:9A:18:C7:61:85 in vlan 321 is moving from port Gi1/11 to port Gi1/7 *Apr 20 03:17:32.289: %C4K_EBM-4-HOSTFLAPPING: Host C4:AD:34:02:A9:FA in vlan 321 is moving from port Gi1/5 to port Gi1/11 *Apr 20 03:17:33.489: %C4K_EBM-4-HOSTFLAPPING: Host C4:AD:34:02:A9:FA in vlan 321 is moving from port Gi1/11 to port Gi1/5 *Apr 20 03:17:34.273: %C4K_EBM-4-HOSTFLAPPING: Host 74:4D:28:4D:3D:88 in vlan 321 is moving from port Gi1/10 to port Gi1/11 *Apr 20 03:17:34.277: %C4K_EBM-4-HOSTFLAPPING: Host 74:4D:28:4D:3D:88 in vlan 321 is moving from port Gi1/11 to port Gi1/10 *Apr 20 03:17:43.769: %C4K_EBM-4-HOSTFLAPPING: Host 78:9A:18:C7:61:85 in vlan 321 is moving from port Gi1/7 to port Gi1/11 *Apr 20 03:17:43.973: %C4K_EBM-4-HOSTFLAPPING: Host 78:9A:18:C7:61:85 in vlan 321 is moving from port Gi1/11 to port Gi1/7 *Apr 20 03:17:47.289: %C4K_EBM-4-HOSTFLAPPING: Host C4:AD:34:02:A9:FA in vlan 321 is moving from port Gi1/5 to port Gi1/11 vlan 321 это те самые избранные, и по логам видно что связующее звено 11 порт, за ней олт. (порты 5,7,10 так же олт)
      что было сделано:
      на олт за 11 портом выключены абоненты имеющие отношение к влан 321 - флапы продолжились.
      выключены пон порты по очереди и все сразу - флапы продолжились.
      выключен порт 11 на циско - флапы прекратились.
      включен порт, но удален влан 321 на циско - флапы прекратились.
      собственно вопрос - это глюк прошивки олт, что при выключеных пон портах флапы продолжаются, либо не там ищу причину?
       
    • Від Emanon
      Приветствую форумчан. Есть проблема и суть ее такова:
      В топологии одной провайдерской сети сделали определенные изменения. Некоторые access-коммутаторы (edge core ec3528M) в домах, решили подключить по gpon-у. Тоесть, если ранее все это дело шло ветками от одного свича к другому, то теперь ответственность, за их агрегацию , частично лягла на olt bdcom gp3600.
      Если схематически : свич -> onu -> olt -> свич агрегации -> bras (accel ipoe) ну и далее уже в ядро. Onu кстати - bdcom gp1701. Вопросы о том, зачем все это и насколько целесообразно - можно оставить для другого разговора.
      А пока что хотелось бы в кое чем разобраться. Недавно, начали идти заявки от НЕКОТОРЫХ абонентов одного и того же дома с одного и того же узла с жалобой на нестабильный интернет. Это через неделю-две после изменения топологии и соответственно, переключения их коммутатора к pon-сети.
      Техник, осмотрев происходящее, заявлял что рандомно, раз в минуту-две, начинаются потери пакетов. Проверял целостность линий,  подключался напрямую ноутом. Результат один и тот же. Линк между свичом и роутером не падает. Не падает линк и между onu и свичом. Проблем с режимами (half duplex, full duplex) портов тоже не было. Если уже далеко зайти, сам домовой свич, olt, коммутатор агрегации, без проблем пингуются (правда находятся в отдельном управляющем vlan). Очевидные проблемы, вроде роста cpu и утечек памяти, в их работе не наблюдались. В логах все чисто. В мониторинге видно, что канал не нагружен (download и upload не превышают 250 Мбит как по pon так и выше, нет аномальных значений pps как для broadcast, так для unicast и multicast). Да и для остальных пользователей, кроме проблемных, не было вопросов. У всех вроде работает, кроме некоторых ребят с конкретного узла. Трасса упорно показывает, что проблемный участок как раз между роутером и bras. Логи на роутерах тоже ничего вразумительного не пишут. При этом, стоило подключить вместо абонентского tp link archer ax12, c64 или keenetic titan, какой то древний роутер, вроде dlink dir300 или tp link tl-wr841n, как все работало стабильно, без потерь. 
      Со стороны bras сессии не рвутся, но через tcpdump действительно обнаруживается, что при пинге ( как 32 байта, так и побольше) часть icmp пакетов от проблемных абонентов не доходит. 
      Менялись mac  абонентских устройств, пытались найти mac flapping, менялся mac aging, менялся абонентский ip. Без результатов. Mac таблица за onu не забивается кстати, там не более 8 устройств. Проверялись оптические уровни. Конечно, onu rx -24 и olt rx -26 - это уже почти на грани. 
      И наверное это отчасти играет роль. Но нюанс с тем, что происходит при замене роутеров, заставляет задуматься. Возможно то, что такое вылезло именно после перехода на gpon - это совпадение. Но есть подозрения, что связь все таки есть. И проблема довольно странная, ранее не встречал.
      Ещё стоит сказать, что это далеко уже не первый домовой свич, подключенный по такой схеме. Но проблема пока вылезла именно тут. В общем, хотелось бы услышать мнения опытных ребят, с чем конкретно связаны проблемы.
      Прошу не судить сильно по части некоторых решений и высказываний. Я пока не имею солидного опыта и большого багажа знаний. Но буду благодарен за помощь
    • Від CoUL
      Sync users ONU скрипт.
      Скрипт виконує автоматичне додавання ONU та відповідної OLT, на якій вона зареєстрована, в карту абонента MikBiLL.
      Забезпечує повну синхронізацію ONU при зміні топології мережі — тобто при реальному переміщенні ONU між OLT або між абонентами. Все відбувається автоматично без необхідності вручну додавати чи змінювати ONU працівниками.
      Можлива синхронізація окремих OLT в ручному режимі.
      Підтримується робота з BDCOM EPON та GPON обладнанням.
      Можливе розширення під інших виробників OLT за потреби.
      💬 По всім питанням звертайтесь у приват.
      BDCOM xPON ONU Auto Sync Script.webm
    • Від ГрозаИнтернета
      Всем привет. Сеть разбили, продаю оборудование, которое удалось спасти.
      Роутер MikroTik 1036-12G-4S - 16500 грн.
      Сервер Dell R410(Xeon L5640(60Вт), 16 Gb RAM, 2x300 Gb SAS, iDrac, Raid, IPMI) - 4500 грн.
      Коммутатор ZyXEL MES-3528 - 2000 грн.
      Коммутатор HUAWEI S2326 - 1500 грн.
      Коммутатор Dell PowerConnect 6224F(опц.10G) - 5000 грн
      Коммутатор D-Link DGS-3627G (нюанс) - 1000 грн
      OLT BDCom P3310(Пролайн упс) - 9000 грн
      Упс APCSmart-UPS RT 2000 + картаAP9619 + кабель для подключения внешних АКБ - 12500 грн.
      Коммутатор ELTEX MES2324FB AC в коробке - 10000
      OLT EPON E9004-D 10G (Пролайн упс) в коробке - 10000
      Кабель OK-NET S/FTP Cat.6a 500Mhz LSOH AWG 23 4pr 280 метров - 8500
      Куча SFP EPON C+++, SFP SC, сетевые карты, твинакс кабеля.

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