_Wolf_

Пишите, пишите... у меня уже 3-й месяц весит кейс по подобным же массовым пропускам с ими же поставленным приоритетом " 2 - High " который они вообще проигнорировали - даже не ответили ни слова после постановки заявки в работу и назначения приоритета. Третий месяц пошел! А вы про NBD!

Все зависит, видимо, от конкретного Ревизора - когда он обновил свой список и в какое время выполнял проверку. У меня по трём цифры "пропусков" совершенно разные, но они есть. И еще - "скатовцы" когда-то проводили исследование - на "ревизоры" часто обновления загружаются раньше, чем становятся доступны для операторов. Иногда разница несколько часов. Пруф ищите в их ВиКи.

Совершенно не важно, что они "давние записи". К "давним записям" добавляются новые IP при этом номер записи и дата внесения в реестр остаются старыми. Так всегда.

Да, то же самое в то же время. При этом по логу самого СКАТа обращения к "облаку" за списком проходили успешно, но с отсутствием изменений для загрузки. Похоже на то, что они там прозевали обновления.

Извините,но!.. по самой логике проекта... так ли уж часто на серверах во время работы добавляются-удаляются сетевые интерфейсы??? И к тому же собственно в параметрах командной строки запуска программы предусмотрен параметр - имя интерфейса. А это вроде бы уже само по себе предполагает жесткую привязку к конкретному интерфейсу и исключает необходимость вообще как-то реагировать на их добавление/удаление во время работы. И собственно основной мой вопрос в том, не грозит ли какими-то неожиданными эффектами если я подправлю авторскую функцию на предмет вызова bind() все таки с указанием конкретного IP-адреса интерфейса.... О! Только что подумалось... у автора же предполагается, что в командной строке можно указать несколько имен интерфейсов... а вызов bind() происходит кажется только 1 раз... видимо потому и биндится к ANY для простоты... а потом где-то в другом месте фильтрация как вы говорите... С одной стороны, видимо, это не даст поправить ситуацию так уж просто если сохранить возможность указания нескольких интерфейсов... с другой - не совсем понятно, зачем тогда вообще было вводить интерфейсы как параметры запуска... если только чтобы исключить реакцию на запросы на каких-то интерфейсах... т.е. получается, что программа зря занимает сокет, на котором сама игнорирует запросы и не дает привязаться к нему ни кому другому... Как-то все это выглядит серьезной недоработкой... и я уже не знаю, как сам мог бы что-то поправить... пожалуй, если только попутно "выпилить" возможность указания нескольких интерфейсов и биндиться всегда только к одному... ...моей квалификации в программировании явно не хватит чтобы настолько въехать в логику исходников, несмотря на относительно небольшой их объем...

Здравствуйте, коллеги... Поскольку автор этого проекта, судя по всему, не только прекратил его разработку и поддержку, но и сам пропал в неизвестности, обращаюсь к общественности... т.к. сам в программировании не силён, а с программированием для сетей под юниксами вообще ни когда дела не имел. Около года использовал этот сервер версии 0.1.a.10 на сегменте сети. Вцелом, все работало. Хотя на одну странность обратил внимание сразу же. Но поначалу она не мешала, а вот сейчас стала "камнем преткновения". В параметрах запуска сервера присутствует указание интерфейса, на котором он якобы должен "слушать". Но! если после успешного запуска посмотреть вывод netstat -lnn , то видно, что на самом то деле "привязывается" он ко всем адресам (0.0.0.0:67)... До сих пор это не мешало, но сейчас возникла потребность запустить на этом же сервере рядом еще и ISC DHCP, слушающий на другом физическом интерфейсе. И вот "второй" DHCP запускаться отказался с сообщением, что адрес, к которому ему предлагается биндиться, уже занят... ну и по netstat видно, что но действительно так и понятно кем.... Просмотр исходников db2dhcp показал нечто странное... (повторюсь - я вообще 0 в сетевом программировании): вызов bind() нашелся только в одном месте (файл dhcp_process.c) <-cut-> struct sockaddr_in udp_sock; bzero(&udp_sock, sizeof(udp_sock)); udp_sock.sin_family = AF_INET; udp_sock.sin_port = htons(port); udp_sock.sin_addr.s_addr = INADDR_ANY; if( bind(dummy_socket, (const struct sockaddr *) & udp_sock, sizeof(udp_sock)) ) <-cut-> и тут тоже видно, что сокет привязывается к INADDR_ANY, что соответствует показаниям от netstat. При этом интерфейсы из параметров строки запуска исправно парсятся... в таком случае не понятно - зачем, если биндимся все равно "ко всему"... Пришла мысль "пофиксить это безобразие"... полез дальше... приведенный фрагмент присутствует в функции: static int make_dummy_socket(uint16_t port) т.е. у нее параметр тоже только 1 - порт... адрес привязки не предполагается... опять же вопрос - зачем указываются интерфейсы при запуске сервера???? в свою очередь вызов make_dummy_socket нашелся тоже только в одном месте.. dhcp_process.c /* Make dummy socket for suppress ICMP-port unreacheble messagess on unicast DHCP messages */ CHECK_VALUE(make_dummy_socket(config->dhcp_server_port), "Can't create dummy socket.", 0); и вот тут меня очень смутил авторский комментарий относительно потенциальных проблем с юникастными DHCP-сообщениями... можно ли все таки "поправить" функцию make_dummy_socket и ее вызовы на предмет использования второго параметра (конкретного адреса интерфейса) или это чревато проблемами, о которых я не знаю и о которых не сказано в "руководствах для начинающих по программированию сокетов"? кое-где в форумах попались сообщения (правда, относительно Windows), что система не дает дважды привязаться к одному и тому же сокету с предопределенным адресом...а у автора же используется многопоточность... В общем, я в недоумении...

Не могу найти, как сконфигурировать интерфейс Cisco Catalyst Vlan через SNMP Cisco Catalyst 3560G Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(44)SE6 Конкретно, требуется воспроизвести следующую конфигурацию: interface Vlan2963 ip unnumbered Loopback10 ip helper-address 10.10.10.10 Не могу найти, как сконфигурировать "ip helper-address" (возможно, с ip unnumbered... тоже будет проблема, но до этого я пока и не дошел) Из относящегося к теме удалось найти только OID ciiHelperAddressTable в CISCO-IP-IF-MIB iso.org.dod.internet.private.enterprises.cisco.ciscoMgmt.ciscoIPIfMIB.ciscoIPIfMIBObjects.ciiHelperAddressConfiguration.ciiHelperAddressTable Но соответствующий пример из: http://www.cisco.com/en/US/docs/ios/interface/configuration/guide/ir_ipifmib.pdf не работает. В ответ на snmpbulkget -v2c -Ob -c private 192.168.1.1 1.3.6.1.4.1.9.9.309.1.2.1 выплевывает что-то относящееся к port security: SNMPv2-SMI::enterprises.9.9.315.1.1.1.0 = INTEGER: 6144 SNMPv2-SMI::enterprises.9.9.315.1.1.2.0 = INTEGER: 0 SNMPv2-SMI::enterprises.9.9.315.1.1.3.0 = INTEGER: 1 SNMPv2-SMI::enterprises.9.9.315.1.1.4.0 = INTEGER: 0 SNMPv2-SMI::enterprises.9.9.315.1.1.5.0 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.315.1.1.6.0 = INTEGER: 0 SNMPv2-SMI::enterprises.9.9.315.1.2.1.1.1.10101 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.315.1.2.1.1.1.10102 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.315.1.2.1.1.1.10103 = INTEGER: 2 SNMPv2-SMI::enterprises.9.9.315.1.2.1.1.1.10104 = INTEGER: 2

Не представляется возможным.Вот образец стойки http://www.cmo.ru/catalog/165/478/ Не хватает двольно много, 250-300мм Мда.. смотреть же надо было когда заказывали... IMHO сейчас вариант - заказать еще пару направляющих и "проявив инженерную смекалку" закрепить их с отступом от задних... только тут опять внимательнее надо, потому что направляющие бывают как минимум 3 разных профилей. В один все сервера встают нормально, в другой - "не все" (HP не встал, IBM, Dell - нормально), в 3-й сервера вообще не встают.

Вы вообще о чем? Речь не о АРП, а о АРП-прокси. У "железки" в любом случае единственная дорога "куда слать" - на агрегатор. Без вариантов. Что без АРП-прокси, что с ним... только во 2-м случае агрегатор сам отвечает на все ARP-запросы если у него есть соответствующий статический маршрут к адресу назначения. Опять же что "писюки" работают без вопросов. Проблема вылезла с "мыльницами". IMHO, дело в конкретной реализации стека протоколов... если при маске /32 на своем интерфейсе хост "знает", что все без вариантов надо слать на "шлюз по умолчанию" - точно как при а-ля ppp (p2p) то все в порядке. "vlan на абонента" он по сути тот же самый p2p и есть. Опять же согласно "модели взаимодействия открытых систем" АКА OSI для протокола верхнего уровня (3-го в данном случае, IP) не должно быть ни какой разницы в реализации интерфейса ниже лежащего уровня (2-го). Т.е. при корректной реализации стека в соответствии с принципами OSI для IP не должно быть разницы - что там ниже - езернет или ppp или что еще. Точно так же и "уровню езернета" не должно быть ни какого дела до того, какую там сетевую маску назначили протоколу вышележащего уровня.

Сделали у себя "vlan на абонента"+"ip unnumbered"+DHCP. В качестве агрегаторов - Cisco Catalyst 3560G, DHCP - ISC 3-й ветки Первоначально настроили выдачу сетевой маски абонентам равной маске подсети, "прибитой" к соответствующему Loopback, на который терминируются абонентские vlan-ы. Соответственно на абонентских vlan-ах включен arp-proxy (по дефолту для каталистов). Все работало. НО! Есть мнение, что arp-proxy не очень то уместно в рамках "Vlan на абонента"... стоило ли изолировать юзеров на 2-м уровне чтобы тут же фактически объединить их обратно на том же 2-м уровне... К тому же слышал и читал, что arp-proxy сам по себе создает дополнительную не желательную нагрузку на агрегатор и делает его более уязвимым, в частности в случае бродкаст-шторма. Поэтому была предпринята попытка организовать выдачу абонентам сетевых параметров с маской /32 "чтобы все работало только через 3-й уровень". На агрегаторе создали еще один loopback, к нему "прибили" еще одну подсеть и соответственно настроили ее на DHCP. (Конфиги - ниже). И получилось, что при подключении в качестве абонентского устройства компьютера все работает прекрасно, а вот из числа испытанных SOHO-роутеров заработал только D-Link DIR-100. С остальными добиться работоспособности не удалось... при этом "каждый не работает по-своему"... D-Link DVG-5004 (VoIP-шлюз+роутер) - сам по себе в режиме роутера работает (с него пингуются все хосты в сети, работает телефония), но подключенные на его LAN-интерфейсы компьютеры доступа к сети не имеют (пингуется LAN IP-интерфейс роутера, но не доступен даже Default Gateway на агрегаторе) Linksys RV042, D-Link DIR-330 - сетевые параметры получают, но не работает вообще ничего (даже сами не могут пропинговать Default Gateway на агрегаторе) Как-то эта картина не обнадеживает... Вопрос - это я что-то не допилил, или выдавать клиентам /32 принципиально невозможно? Ведь роутеры даже дома используются весьма часто.... Ниже - конфиги DHCP и агрегатора. Соответственно в Vlan2024 все работает, а Vlan124 - нет. ---------------------- Cisco Catalyst 3560G -------------------------- ! interface Loopback100 description Users_network ip address A.B.184.1 255.255.255.224 ip ospf network point-to-point end ! interface Loopback101 description Users_network ip address A.B.185.129 255.255.255.128 no ip proxy-arp end ! interface Vlan124 description Test Client port1 ip unnumbered Loopback101 ip helper-address <DHCP server IP address> no ip proxy-arp end ! interface Vlan2024 ip unnumbered Loopback100 ip helper-address <DHCP server IP address> end ------------------------------- DHCP ------------------------------ subnet A.B.184.0 netmask 255.255.255.224 { option domain-name-servers A.B.D.E, A.B.D.F; # Test1 class "VLAN2024" {match if binary-to-ascii (10, 16, "", substring(option agent.circuit-id, 2, 2))="2024";} pool {range A.B.184.4; option routers A.B.184.1; allow members of "VLAN2024";} } subnet A.B.185.128 netmask 255.255.255.128 { option domain-name-servers A.B.D.E, A.B.D.F; option subnet-mask 255.255.255.255; # Test 2 class "VLAN124" {match if binary-to-ascii (10, 16, "", substring(option agent.circuit-id, 2, 2))="124";} pool {range A.B.185.130; option routers A.B.185.129; allow members of "VLAN124";} }

Кто-нибудь проходил собственноручно процедуру апгрейда функционала Cisco Catalyst 3560E с IP-Base до IP-Services? С самой процедурой получения файла лицензий по PAK и их регистрации на железках как раз таки все понятно. У Циски все подробно описано. Проблема в другом... поскольку система эта новая, то не знали - что конкретно из каталога нужно заказывать. Доверившись дистрибьютору, приобрели у него позиции 3560E-IPSLCB-QTY (по Cisco GPL). Так в счете и накладной. Внимание - ВОПРОС! Что конкретно мы должны были получить от него в материальной форме? Максимально подробно. Дело в том, что нам был прислан по е-майлу скан обычного листочка с соответствующим заказанному количеством PAK (+серийники наших железок, номер заказа). При попытке сгенерировать лицензии на соответсвующей странице сайта Циски нам сообщают, что эти лицензии уже активированы. Причем аж за 2 недели до того, как нами был получен тот листок с PAK-кодами... При общение по телефону с дилером нам было сказано, что яко бы наши лицензии были ими уже активированы и нам была выслана ВСЯ необходимая информация в составе того самого листочка и больше они нам ни чего не должны. А эти коды мы яко бы и должны ввести в железку. Описать процедуру ввода отказались. Что-то мне все это очень напоминает банальное кидалово. Но мы сами так реально и не знаем наверняка - что же все таки они обязаны были нам предоставить в соответствии с заказанными позициями. Версий и рассуждений на тему "как, вероятно, оно должно быть" наслушались уже достаточно. Поэтому интересует только заведомо достоверная информация от тех, кто эту процедуру проходил.

Авторизация и аутентификация - это тупо провод в квартиру. Есть опция в виде 802.1X или её копия в виде веб-авторизации через перехват пакетов. Это как-раз самый решёный момент. А вот с приминением политик... тут всё очень грустно. Либо самодельный комбайн (см. вышеприведённые ссылки на БРАСологию), либо мегадевайсы типа Juniper E-series или CISCO 10/12К .1X - это первое же, что еще в самом начале мне пришло в голову. На первый взгляд - красиво. Но по недолгому размышлению - проблем и потенциальных звонков в техсуппорт светит куда поболе, чем с pppoe. Насчет мега-девайсов... как в этом свете видится например Cisco SCE-2000? Я не разобрался пока конкретно методах ее действия. Но если пользовательт однозначно ассоциирован с IP-адресом/подсетью - то не может ли она непосредственно управлять трафиком без посредничества ISG? Просвятите...

Про "просто так" речь и не шла... я не просто так в самом начале упомянул - "на уровне организации". Прошу прощения, если был понят не правильно. Я прекрасно понимаю, что "проводить семинар для чайников" ни кому из реально работающих совершенно не интересно. Только боюсь, что "поделиться взаимообразно" нам пока нечем... Операторы "традиционной телефонии", причем лично я с этим практически не связан. Предоставляем доступ по ADSL. Но на нем стало уже "тесно". Вот решили развиваться в сторону Ethernet. На "свободных волокнах" начали строить сеть аналогового КТВ... в этом вопросе есть люди, перешедшие из других организаций и достаточно опытные как в технических вопросах, так и договорных отношениях с каналами. Собственно поэтому в вопросе PPPoE vs CVLAN плюсы-минусы первого нам вполне известны и прочувствованы. Поэтому рассказывать о его прелестях нам не за чем. Пусть вопрос выбора между этими двумя методами для нас пока и не решен окончательно, но вот именно для этого и хочется "из первых рук" узнать об опыте применения "Vlan per user", прикинуть, сравнить что это нам дает и что за собой влечет. О вариантах технической реализации в плане конфигурации оборудования у меня по итогам чтения этого форума определенное представление сложилось уже давно. А вот что касается точек применения политик, формирования и схем предоставления услуг, и в первую очередь аутентификации/авторизации - для меня "огромное белое пятно". Мне вовсе не хотелось перетаскивать сюда "из соседних веток" очередной холивар на эту тему. Лично мне нравится идея "воткнул и работай". Но окончательные решения принимаю не я, а людей, которые не первый год предоставляют доступ через ADSL\PPPoE с явным вводом логина/пароля преубедить, мягко говоря, очень сложно... а с моим уровнем компетенции и практически невозможно.

... а в гости так ни кто и не пригласил :-)

Как в эту тему вписывается/не вписывается Cisco SCE ?

аутентификация или авторизация? кстати, обе присутствуют при VLAN-per-customer давайте не будем повторять наши споры в соседних темах, здесь вот Войсмастер умеет ставить самодостаточные точки :) аутентификация должна быть, на базе логина/пароля, сертификата, отпечатка пальца, сканирования сетчатки глаза, анализа ДНК. НЕ ВОЛНУЕТ . А можно прямые ссылки на эти самые "соседние темы"? Как-то они ускользнули от моего внимания. А именно с аутентификацией для меня больше всего непонятного.

У вас 3 пути: - сделать умным access/aggregation, закольцевать последнее и max разгрузить core - сделать тупым access/aggregation, заташив всю логику в дорогое MetroEthernet core - разварить GPON и поставить серьезную BRAS молотилку + разные миксы из xDSL/E1/Wi-Fi для "хотящих странного" Судя по закупкам есть тяготение с варианту #1. IMHO, разумеется. P.S. C-VLAN выглядит весьма неплохо в вашем случае. Не переживайте так ;-) . В сад. "Дом абонента полнценен, самодостаточен, уважаем" - (с) /me . Да, именно "1-й вариант" лично мне и кажется наиболее приемлемым с учетом того, во что уже вложились и с надеждой на будущее... Ядро в данной комплектации видимо не достаточно "умное"... связываться GPON пока желания нет, хотя в определенных кругах такие идеи время от времени и звучат. Поэтому кажется разумным "распределить мозги по всей сети". А вот с аутентификацией/авторизацией пользователей в такой схеме для меня самое большое "белое пятно"...

В таком примерно направлении мысль и движется... про лимит в 1000 SVI-unnumbered для 3560 я в курсе... эту 1000 еще набрать надо, а наберется - ну заменится железка на 65xx... не о том сейчас голова болит..."генеральную линию Партии" определить надо.... Сеть видится не только для того, чтоб "интернет народу раздавать"... "Коммерсанты" уже сейчас хотят там VoD давать ("источник" уже есть и как-то работает), в ближайшей перспективе - IPTV и VoIP... вопрос "коммерческой эффективности" этих начинаний тут тоже не обсуждается... это - тоже "исходные данные". В том числе и поэтому от PPPoE мысль и отвернулась....

Здравствуйте, господа Взялась наша организация строить сеть масштаба города (~200 000 население). К сожалению, как это не редко бывает в крупных организациях, "дом начинают строить с крыши"... Т.е. часть оборудования уже закуплена, часть - смонтирована, но проекта и даже определенной концепции/модели сети до сих пор нет. У тех, кто принимает решения, - довольно неопределенное представление о том, "что же все таки строим и что хотим получить". А тем временем планируются дальнейшие закупки оборудования. Понятно, что путь архи-неправильный, более того - ситуация близкая к кошмарной. Но, к сожалению, это уже данность... Хотелось бы все таки по возможности направить процесс в нужном направлении, чтобы не строить сегодня "сеть вчерашнего дня", и чтобы по возможности хотя бы свести к минимуму последующие перестройки и проблемы эксплуатации. К сожалению, сам я пока не достаточно компетентен в вопросе, чтобы эффективно влиять на руководство. По итогам изучения этого форума сложилось представление, что надо двигаться в сторону модели предоставления доступа по схеме "VLAN-на пользователя". Но, в отличие от схемы pppoe/pptp для меня в этой теме все еще больше вопросов, чем ответов. Та часть оборудования, которая уже закуплена, вроде бы удовлетворяет нужным требованиям (D-Link 3526 -доступ, WS-C3560G - агрегация, С7606+WS-C3560E (10G) - "ядро"). Чего, собственно, хотелось бы... 1) Чтобы кто-то, кто уже реально использует такую модель в своей сети, пригласил нас на уровне организации к себе "в гости", и провел "ликбез". 2) Возможно, подписался на полноценную разработку проекта сети.

Осмелюсь вставить свои 5 коп. и предположить, что соединяетесь с каталистом не через консоль, а по ssh/telnet тогда terminal monitor ответ на вопрос