Solar

Симптомы удалось снять. Загрузка процессора вернулась с норму. Существовала вот такая конструкция: interface Loopback13 ip address 10.0.0.1 255.255.255.0 ip address 10.* 255.255.255.0 secondary ip address 10.* 255.255.255.0 secondary ip address 10.* 255.255.255.0 secondary no ip redirects no ip unreachables no ip proxy-arp ip flow ingress ip route-cache policy end данный интерфейс навешивался на все пользовательские vlan'ы, vlan'ы, соответственно, настроены следующим образом: interface Vlan1120 ip unnumbered Loopback13 ip helper-address 192.168.105.138 no ip redirects no ip unreachables no ip proxy-arp ip flow ingress ip route-cache policy end В vlan'ах есть как пользователи авторизующиеся при помощи DHCP + opt82 (которым в качестве шлюза выдается 10.0.0.1), так и пользователи авторизующиеся при помощи Dual Access РРРоЕ. Серые IP последних подроблены на подсети класса С. Шлюз для каждой такой сетки и повешен на тот же loopback интерфейс в каче стве secondary IP. Так вот, выяснилось, что с увеличением этих самых secondary адресов на loopback интерфейсе растет ARP Input. После того, как было снижено количество этих вторичных адресов на loopback'е загрузка пришла в норму, циска больше не впадает в кататонический ступор. К сожалению, так и не удалось понять саму физику данного явления, т.е. все это происходит потому, что где-то что-то банально недонастроено, или мы уперлись в какие-то аппаратные/программные ограничения? Чтение цисковской документации пока ответа не дает, если есть знатоки, разбирающиеся в вопросе, огромная просьба поделиться информацией.

Столкнулся с довольно неприятной проблемой: периодически на маршрутизаторе Cisco 6509 (720 супервизор, IOS 12.2(33)SXJ4) уходит в 100% загрузку routing processor, при этом switching processor загружен едва ли на 5%. Судя по выводу show processes cpu "давит" процессор ARP Input. В шасси приблизительно 200 активных портов, выяснить с какого именно из них идет ARP флуд пока не смог (буду благодарен, если кто-то подскажет эффективный способ зделать это). Пока единственный найденный способ исправления ситуации - перезагрузка роутера, что весьма болезненно т.к. он стоит на агрегации довольно большой сети. Собственно вопрос: не сталкивался ли кто-нибудь с подобной ситуацией, выяснили ли причину, нашли ли какие-либо эффективные способы решения проблемы?

На свиче с "правильным" отображением: <Huawei0>dir Directory of flash:/ Idx Attr Size(Byte) Date Time FileName 0 -rw- 811 Jan 01 2008 00:00:54 private-data.txt 1 -rw- 571,936 Jan 01 2008 00:02:15 s23_33_53-v100r005sph007.pat 2 -rw- 6,463,980 Jan 01 2008 00:24:26 S2300-V100R005C01SPC100.cc 3 -rw- 6,456 Sep 14 2012 16:26:28 config.cfg 4 -rw- 12,240 Jan 01 2008 00:04:44 $_patchstate_reboot 14,632 KB total (7,708 KB free) <Huawei0>dis patch Patch Package Name :flash:/s23_33_53-v100r005sph007.pat Patch Package Version:V100R005SPH007 ************************************************************************ * The hot patch information, as follows: * ************************************************************************ Slot Type State Count ------------------------------------------------------------ 0 C Running 22 На свиче с "урезанным": <Huawei1>dir Directory of flash:/ Idx Attr Size(Byte) Date Time FileName 0 -rw- 830 Oct 22 2012 15:00:12 private-data.txt 1 -rw- 571,936 Jan 01 2008 00:15:31 s23_33_53-v100r005sph007.pat 2 -rw- 12,240 Oct 22 2012 14:59:36 $_patchstate_reboot 3 -rw- 6,418,980 Oct 22 2012 14:51:18 s2300-v100r005c01spc100.cc 4 -rw- 6,474 Oct 22 2012 14:58:38 112.cfg 5 -rw- 6,536,780 Jul 06 2012 11:19:30 s2300-v100r006c01spc100.cc 14,632 KB total (1,376 KB free) <Huawei1>dis patch Patch Package Name :flash:/s23_33_53-v100r005sph007.pat Patch Package Version:V100R005SPH007 ************************************************************************ * The hot patch information, as follows: * ************************************************************************ Slot Type State Count ------------------------------------------------------------ 0 C Running 78

Одну зацепку все-же удалось найти: на всех зависающих свичах был софт версии s2300-v100r006c01spc100 а на парочке свичей, которые в зависании замечены не были более старая версия - s2300-v100r005c01spc100. В процессе перепрошивки была замечена еще одна не совсем понятная особенность: на свиче display version выдает помимо всего прочего и строку: VRP (R) software, Version 5.70 (S2300 V100R005C01SPC100) я забираю файл прошивки с этого свича, затем заливаю его же на другой свич и там уже вижу VRP (R) software, Version 5.70 (S2300 V100R005C01) не пойму куда и почему девается SPC100 возможно я что-то упускаю, и нужно кроме файла с прошивкой копировать что-то еще? в мануале об этом ни слова...

Возникла следующая проблема: несколько месяцев назад (приблизительно июнь) поставили на доступ полтора десятка сабжевых свичей, до последнего времени все работали без каких-либо нареканий, но, примерно недели 2 назад стали периодически "подвисать", причем с довольно необычными симптомами - сам свич перестает пинговаться, но клиенты подключенные к нему на момент зависания продолжают нормально работать, после зависания новые клиенты подключиться уже не могут. Решается проблема аппаратной перезагрузкой (выключением-включением питания). Изначально предположили, что какая-то проблема с электрикой (скачки напряжения приводят к заисанию), но после установки в ящики ИБП с фильтрами ситуация не изменилась. Другая странная особенность - зависают свичи, почему-то, только в ночное время, есть предположение, что это как-то связано с температурным режимом, но если такие незначительные понижения температуры (ночью у нас сейчас около +10, кроме того ящики со свичами находятся в подъездах) приводят к такому эффекту, то чего ждать в дальнейшем... Будте добры, подскажите не сталкивался ли кто-нибудь с такой проблемой, если да, то с чем она связана и как можно решить?

Большое спасибо всем, прошу прощения за дилетантский вопрос, честно говоря, не знал о существовании subclass.

Всё, вопрос решен, оказывается dhcp snooping нужно включать и глобально, и в абонентском vlan'e.

похоже, таки, изменяет, сделал вот так: # dhcp enable dhcp snooping enable dhcp option82 format extend # ... # interface GigabitEthernet0/0/1 port link-type trunk undo port trunk allow-pass vlan 1 port trunk allow-pass vlan 10 1021 undo ntdp enable undo ndp enable dhcp snooping trusted # с тем же самым результатом - на выходе никaкой opt82

Здравствуйте, господа, есть следующий вопрос: у меня в ISC DHCP существуют 2 пула адресов - основной и альтернативный, соответственно есть 2 группы клиентов. Первой группе клиентов выдаются рандомные (в том смысле, что не должно быть строгой привязки киент-IP) адреса из первого пула - стандартнее некуда. Со второй группой всё немного сложнее: принадлежность клиента к группе определяется по MAC адресу, т.е. есть список МАС адресов всех клиентов из второй группы, и этим клиентам тоже нужно выдавать рандомные IP, но уже из второго пула. Достать МАС клиента из приходящего запроса элементарно, главный мой вопрос в том, можно ли как-то организовать проверку принадлежности этого МАС к списку клиентов второй группы, либо же возможно ли всех клиентов второй группы описать индивидуально, но выдавать им всем IP адреса из одного пула?

Помогите, пожалуйста с настройкой opt82 на сабжевом коммутаторе, настраиваю следующим образом: ... # vlan batch 1 10 1021 # ... # dhcp enable dhcp option82 format extend # ... vlan 1021 dhcp option82 insert enable interface Ethernet 0/0/1 to 0/0/12 ... # interface Vlanif10 ip address 10.103.100.100 255.255.0.0 # interface Ethernet0/0/1 port hybrid pvid vlan 1021 undo port hybrid vlan 1 port hybrid untagged vlan 1021 undo ntdp enable undo ndp enable # ... # interface GigabitEthernet0/0/1 port link-type trunk undo port trunk allow-pass vlan 1 port trunk allow-pass vlan 10 1021 undo ntdp enable undo ndp enable # При этом на выходе в vlan'e 1021 получаю DHCP запрос без добавленной opt82. Подскажите пожалуйста в чем может быть причина, возможно, я упускаю какой-то нюанс?

Простите ради бога за дурацкий вопрос, но упёрся на ровном месте и не могу понять в чем проблема, делаю: system-view dhcp enable vlan 1021 dhcp option82 rebuild state enable interface Ethernet 0/0/1 to 0/0/12 порты с 1 по 12 находятся в access режиме, и, естественно, принадлежат влану 1021, uplink порт GigabitEthernet0/0/1 - транковый и тоже принадлежит этому же влану (помимо него там есть еще и управляющий vlan с IP адресом, но это не существенно). Беда в том, что option82 на выходе у меня в DHCP запрос от клиента так и не добавляется, т.е. сам запрос я вижу, но нужных полей в нём нет. Пробовал различные варианты: задавал формат опции, настраивал не на vlan-е а на отдельно взятом интерфейсе и т.д. - безрезультатно. Подскажите пожалуйста, что я делаю не так?

Да, моя первая мысль была именно такой, а потом я решил, что стоит сначала поинтересоваться вдруг я банально что-то упустил/недонастроил.

2 nuclearcat дальше стоит BRAS на котором всё и шейпится. 2 martini вот тут позвольте с Вами не согласиться, абсолютно не важно как настраивать unnumbered, можно хоть на какой-то левый vlan с совершенно посторонним IP, важно только собственно наличие самого unnumbered на интерфейсе: если он есть - статические адреса прописываются автоматически, если его нет, то и автомтического добавления маршрутов нет.

Имеется следующая схема: несколько L2 свичей к которым подключены пользователи, Сisco 6509, которая всё это дело агрегирует и маршрутизирует. Пользователи бывают 2х типов: со статическими адресами, прописанными на пользовательских компах вручную, и пользователи получающие все свои настройки по DHCP (в их случае 6509 является DHCP relay-ем). Пользователи разбиты на vlan-ы и в одном и том же vlan-е могут быть пользователи обоих типов. Возникает следующая проблма: если в качестве ip на пользовательском vlan-e указать не unnumbered, а адрес из подсети, где ip-шки прописаны вручную, 6509 автоматически не создает маршрутов для абонентов подключающихся по DHCP - подскажите пожалуйста, так оно и должно быть, т.е. это такая цисковская "фича", или возможно все-таки настроить так, чтобы маршруты для DHCP абонентов добавлялись без unnumbered? И обратная ситуация: если на vlan-е unnumbered, то не маршрутизируется подсеть, а работает только добавление статического маршрута на хост пользователя /32, что, в принципе, не смертельно, но создает определённые неудобства. Опять же: возможно ли как-то настроить маршрутизацию по подсетям при использовании unnumbered или это не лечится? Пример для наглядности: есть некий vlan 1000, в нем есть пользователи с прописанными вручную адресами из подсетей 10.10.10.0/24 10.10.11.0/24 (допустим 10.10.10.3 и 10.10.11.5) и пользователь, получающий по DHCP адрес из подсети 192.168.1.0/24 (динамический). В случае, если vlan настроен следующим образом: interface Vlan1000 ip address 10.10.10.1 255.255.255.0 ip address 10.10.11.1 255.255.255.0 secondary ip helper-address 192.168.105.138 no ip redirects no ip unreachables ip flow ingress ip route-cache policy end адреса пользователей из соответствующих сетей доступны как connected via Vlan1000, но при подключении пользователя, получающего динамический адрес посредством DHCP (например 192.168.1.7) соответсвующий статический маршрут автоматически не добавляется. Что посоветуют знатоки? Почему автоматически маршруты для DHCP пользователей добавляются только при использовании unnumbered? Стоит курить доки по DHCP-relay или бессмысленно? Возможно, кто-то поделится готовым решением? И вторая ситуация: interface Vlan1000 ip unnumbered Loopback7 ip helper-address 192.168.105.138 no ip redirects no ip unreachables ip flow ingress ip route-cache policy end static route для пользователя отрелееного к DHCP добавляется и удаляется автоматически, но достучаться до пользователей 10.10.10.3 и 10.10.11.5 можно только прописав вручную статические маршруты непосредственно на их хосты, маршрут вида ip route 10.10.10.0 255.255.255.0 vlan 1000 permanent по непонятной мне причине не работает, подскажите пожалуйста так и должно быть, или я что-то недоделал/сделал неправильно?

Как в таком случае быть с клиентскими vlan-ами? IP адреса клиентам планируется выдавать динамически (за исключением тех кто захочет статику). На сколько я понимаю, чтобы циске была L3 на ней должен быть IP из клиентской сети, точнее по одному IP на vlan?