resident_k Опубликовано 10 декабря, 2015 · Жалоба Работаем по технологии 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 Кто-то встречался с подобным явлением? Как бороться? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Reanemator Опубликовано 10 декабря, 2015 · Жалоба 1) Укажите прошивки ОЛТа, а то не понятно с чем имеем дело. 2) Очень важно, сколько клиентов одновременно сидит в Инете. У 3310B таблица TCAM ограничена, поэтому при использовании DHCP SNooping, DAI и ISG одновременно, в сети могут находиться не более 128 абонентов. Если абонентов больше, то начнутся проблемы. Решается это перенастройкой слайсов для TCAM. Но эта возможность есть только в последних прошивках. Да и то - размер TCAM у BDCOM-а 512 - т.е. даже если поделить TCAM на 3 поровну, то всё равно 256 клиентов одновременно сидеть не смогут. Я не знаю, сколько у Вас ОНУшек, но если их число подходит к значению 256, то включать одновременно DHCP Snooping, DAI и ISG не получится - придётся чем-то жертвовать. Пока что Вы можете сделать так Switch_config_epon0/1#storm-control unicast threshold 1000 Switch_config_epon0/1#storm-control multicast threshold 1000 Switch_config_epon0/1#storm-control broadcast threshold 1000 Switch_config#filter dhcp Switch_config#filter threshold dhcp 100 Т.е. по максимуму отфильтровать левый трафик, чтобы уменьшить нагрузку на проц. Я тестировал DHCP Snooping на ОЛТе - он прекрасно работает и левые DHCP запросы не пропускает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
resident_k Опубликовано 10 декабря, 2015 · Жалоба 1) Укажите прошивки ОЛТа, а то не понятно с чем имеем дело. 2) Очень важно, сколько клиентов одновременно сидит в Инете. У 3310B таблица TCAM ограничена, поэтому при использовании DHCP SNooping, DAI и ISG одновременно, в сети BDCOM_4#sh version BDCOM P3310B Software, Version 10.1.0B Build 29333 Copyright by Shanghai Baud Data Communication CO. LTD. Compiled: 2015-7-21 17:47:52 by SYS_29333, Image text-base: 0x80008000 ROM: System Bootstrap, Version 0.3.3, Serial num:00313001539 System image file is "Switch.bin" (RISC) processor with 131072K bytes of memory, 8192K bytes of flash Base ethernet MAC Address: fc:fa:f7:c9:2e:a6 snmp info: product_ID:228 system_ID:1.3.6.1.4.1.3320.1.228.0 BDCOM_4 uptime is 9:03:56:29, The current time: 2015-12-10 14:18:45 BDCOM_3x16#show version BDCOM P3616-2TE Software, Version 10.1.0E Build 29657 Copyright by Shanghai Baud Data Communication CO. LTD. Compiled: 2015-8-11 9:23:25 by SYS, Image text-base: 0x10000 ROM: System Bootstrap, Version 0.4.2, Serial num:00315070712 System image file is "Switch.bin" hardware version:1.1.1 (RISC) processor with 262144K bytes of memory, 16384K bytes of flash Base ethernet MAC Address: 00:e0:0f:5e:00:87 PCB version:1.1.1 snmp info: product_ID:2011 system_ID:1.3.6.1.4.1.3320.1.2011.0 BDCOM_3x16 uptime is 14:19:32:14, The current time: 2015-12-10 14:19:3 ОНУшек в общей сложности около 900 шт на 2 БДКОМа -16 и один БДКОМ-8. В час пик работает, наверное, 600-700 одновременно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
axisBeam Опубликовано 10 декабря, 2015 · Жалоба Не слишком много технологий зайдествовано?) show ip dhcp-relay snooping ip dhcp-relay snooping ip dhcp-relay snooping vlan 3291-3297 DHCP Snooping trust interface: GigaEthernet0/5 GigaEthernet0/6 GigaEthernet0/4 GigaEthernet0/3 GigaEthernet0/1 GigaEthernet0/2 ARP Inspect trust interface: IP source guard trust interface: DHCP Snooping deny interface: ip dhcp-relay snooping db-file /dhcpr-database show run interface GigaEthernet0/1 switchport trunk vlan-allowed 64,3291-3297 switchport mode trunk dhcp snooping trust interface EPON0/1 switchport trunk vlan-allowed 64,3291 switchport trunk vlan-untagged none switchport mode trunk switchport pvid 64 switchport protected interface EPON0/1:1 onu-configuration epon sla upstream pir 1000000 cir 1024 epon sla downstream pir 1000000 cir 1024 epon onu port 1 ctc vlan mode tag 3291 epon onu port 1 loopback detect !!onu-configuration-end ip dhcp-relay snooping ip dhcp-relay snooping vlan 3291-3297 ip dhcp-relay snooping information option format hn-type host ARP inspection возможно конфликтует с IPSG. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
resident_k Опубликовано 11 декабря, 2015 (изменено) · Жалоба Не слишком много технологий зайдествовано?) [ ARP inspection возможно конфликтует с IPSG. В общем, провели эксперимент - убрали ip arp inspection vlan 331 и ip dhcp-relay snooping log. Стало работать лучше, подключили роутер к ОНУшке неправильно, так чтобы DHCP роутера смотрело в сторону сети. Разогнать процессор БДКОМа до 100% не удалось, ОДНАКО, вечером, когда много пользователей онлайн ситуация повторилась - все 4 OLT BDCOM ушли в 100% загрузку. Помогает краткосрочное отключение одного из ОЛТ, тогда через пару минут спадает загрузка всех ОЛТ. Загрузка процессора одного из БДКОМов Конфиг БДКОМа прилагается bdcom2_20151211.txt Изменено 11 декабря, 2015 пользователем resident_k Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Reanemator Опубликовано 11 декабря, 2015 · Жалоба Смотрите, ситуация вообще не связана с тем, сколько абонов видит суммарно. Вопрос в том, сколько абонентов сидит на конкретном BDCOM_е. 1) Нельзя ОЛТы подключать каскадом - иначе таблицы TCAM не хватит. Надеюсь у Вас в сети не так. 2) Я так и не понял, сколько у Вас ОЛТов 3310, сколько 3608, а сколько 3616. 3) Если всё равно в час-пик нагрузка увеличивается, то на 3310B можно поиграться с настройками FFP, т.е. изменить размер слайсов, которые выделяются под ACL,ISG и DHCP Snooping. Если у Вас ACL не используется, то можно вообще забрать его слайс под DHCP Snooping. Switch_config#ffp ? dhcp-snooping -- Config dhcp snooping ffp record isg -- Config (dhcp snooping) ip source guard ffp record dai -- Config (dhcp snooping) arp inspection ffp record acl-qos -- Config acl and qos ffp record something-else -- Config something else ffp record В общем, смотрите сами - по максимуму на 3310 можно взять всю таблицу TCAM (512 записей) и разделить её только между DHCP Snooping и ISG. Как раз получится, что все 256 клиентов могут сидеть одновременно. Раньше проблема с нехваткой TCAM-а была менее выражена, т.к. не у всех были роутеры. Теперь роутеры есть практически в каждой семье, а значит клиент (то беж роутер) всегда онлайн. Не заставишь же клиента выключать роутер по уходу из дома. Можно ли менять размер TCAM на 3600 серии, я не знаю - не проверял. Можете сами попробовать мою команду. Когда нагрузка опять поднимется до 100%, посмотрите командой show task чем занят процессор. Может дело вообще не в DHCP. Если ситуация не решится, то выход один - убивать ISG тоже, освобождая TCAM только под DHCP Snooping. А по поводу того "не слишком ли много технологий?", я скажу так - DHCP Snooping, DAI и ISG - Это как сиамские близнецы - они всегда идут по жизни рядом. Многие, говоря о DHCP снупинге, подразумевают их тоже. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
resident_k Опубликовано 11 декабря, 2015 · Жалоба Смотрите, ситуация вообще не связана с тем, сколько абонов видит суммарно. Вопрос в том, сколько абонентов сидит на конкретном BDCOM_е. 1) Нельзя ОЛТы подключать каскадом - иначе таблицы TCAM не хватит. Надеюсь у Вас в сети не так. ОЛТы подключены не каскадом. 2) Я так и не понял, сколько у Вас ОЛТов 3310, сколько 3608, а сколько 3616. ОЛТ: Р3310 - 1 шт. (резервный 1 абонент) Р3608 - 1 шт. 58 ОНУшек Р3616 - 2 шт. 390 и 458 ОНУшек 3) Если всё равно в час-пик нагрузка увеличивается, то на 3310B можно поиграться с настройками FFP, т.е. изменить размер слайсов, которые выделяются под ACL,ISG и DHCP Snooping. Если у Вас ACL не используется, то можно вообще забрать его слайс под DHCP Snooping. Команда FFP доступна только на ОЛТ Р3310, на других моделях ее нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Reanemator Опубликовано 11 декабря, 2015 · Жалоба Значит придётся на 3600 отключать ISG. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
resident_k Опубликовано 22 декабря, 2015 · Жалоба Значит придётся на 3600 отключать ISG. не помогло и отключение ISG. Пока удалось решить данную проблему включением БДКОМ-ов через дополнительный свитч Конфигурация данного коммутатора отличается от С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. Какие может будут Ваши идеи по данному оборудованию? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
2garin.90 Опубликовано 10 февраля, 2016 · Жалоба Приветствую. Может кто нибудь подскажет ffp something-else это что такое? Весьма много записей использует. А dhcp-snooping подозрительно мало, активных онушек 110-120, выданных ip адресов 97. Хотелось бы перераспределить слайсы (скоро упремся в ограничение 128 абонентов), но до понимания что их использует не хочется лезть в конфиг. DHCP-snooping, IPSG, DAI включены. #show ip dhcp-relay snooping ip dhcp-relay snooping ip dhcp-relay snooping vlan 343 ip arp inspection vlan 343 ip verify source vlan 343 DHCP Snooping trust interface: GigaEthernet0/5 GigaEthernet0/6 GigaEthernet0/4 GigaEthernet0/3 GigaEthernet0/1 ARP Inspect trust interface: GigaEthernet0/5 GigaEthernet0/6 GigaEthernet0/4 GigaEthernet0/3 GigaEthernet0/1 IP source guard trust interface: GigaEthernet0/5 GigaEthernet0/6 GigaEthernet0/4 GigaEthernet0/3 GigaEthernet0/1 DHCP Snooping deny interface: ip dhcp-relay snooping db-file /dhcpr-database #show ffp use-count ffp dhcp-snooping use count = 2 ffp isg use count = 102 ffp dai use count = 102 ffp acl-qos use count = 0 ffp something-else use count = 251 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
2garin.90 Опубликовано 12 февраля, 2016 (изменено) · Жалоба Кажется понял что значит ffp something-else use count. Это igmp sooping, mcst-vlan, а точнее ip-шники каналов, диапазон которых указывается в mc-vlan.Один из мультикаст вланов: ip mcst mc-vlan 31 range 239.255.1.1 - 239.255.1.90. sh ip mcst mc-vlan-xlate как раз и показывает 250 групп. Если ограничить количество записей и написать ffp something-else record 1 подписка на мультикаст прекращает работать!.. Так что нужно сокращать диапазон адресов в mc-vlan, для экономии записей в TCAM. Прав я или нет не знаю, но очень похоже что так и есть. Изменено 12 февраля, 2016 пользователем 2garin.90 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Гость Костя Опубликовано 13 февраля, 2016 · Жалоба Как попасть в настройку? Какой у него IP. Суть в том, что у меня есть логин и пароль от провайдера, и хочу попробовать указать другой логин и пароль. Как изменить? Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
2garin.90 Опубликовано 20 февраля, 2016 · Жалоба Как попасть в настройку? Какой у него IP. Суть в том, что у меня есть логин и пароль от провайдера, и хочу попробовать указать другой логин и пароль. Как изменить? Спасибо. Telnet и вводите логин и пароль. По умолчанию IP не имеет. Ну а если без IP надо то только консоль. Web управление тоже отдельно включать надо, толку от него правда не много, через cli удобнее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...