wtyd

Ну вообще воде можно, но я не пробовал :-). У меня нет цыскиного DMVPN. У меня пока что-то не очень понятное с несколькими хабами получается. Один тушу и какой-то расколбас в сети появляется, пока непонятно, как хабы между собой конфигурить надо.

Получилось запустить на opennhrp, дело было не в бобине ... alpine sysctl пре-сет сидел в кабине :-). После удаления sysctl файлов и ребута всех нод, opennhrp почему-то заработал, а frr так и не работает. Это портит дальнейшую перспективу для ipsec, можетне получится, т.к. opennhrp очень старый для современногос офта и инструкций пока не нашел. Кому интересно вот более менее рабочий вариант конфигов для стенда описанного выше (маски на туннельных ойпи посенял на /16 как того хочет opennhrp): a1:~# cat /etc/opennhrp/opennhrp.conf interface gre1 non-caching redirect shortcut cisco-authentication secret8 holding-time 30 interface eth0 shortcut-destination interface lo shortcut-destination alpine2:~# cat /etc/opennhrp/opennhrp.conf interface gre1 # map 10.0.0.1/16 192.168.101.2 register dynamic-map 10.0.0.0/16 192.168.101.2 shortcut redirect non-caching cisco-authentication secret8 # holding-time 30 holding-time 300 alpine3:~# cat /etc/opennhrp/opennhrp.conf #interface gre1 # map 10.0.0.1/16 192.168.101.2 register # shortcut # redirect # non-caching # cisco-authentication secret8 interface gre1 dynamic-map 10.0.0.0/16 192.168.101.2 shortcut redirect non-caching cisco-authentication secret8 holding-time 60 Ну еще закомментил все упоминания про racoonctl в файлах /etc/opennhrp/opennhrp-script, а то иначе скрипт ругался. Впечатления пока не очень, работает как-то ненадежно. Если рестартануть хаб, то ноды в нем не быстро перерегистрируются - holdtime афектит вообще на всё, протокол stateless. Когда пинг со спока на спок запускаешь, то теряется 1-3 первых пакета, пока не происходит разрешение нейбора, но зато потом вроде не теряются даже когда holdtime проходит и надо заново резолвить. безопасность ... её нет, т.е. надо ойписекас делать.

Потому что иначе регистрация в хабе вообще не происходит, я пробовал. Еще в примерах frr именно так указано делать (http://docs.frrouting.org/en/latest/nhrpd.html). Про какие ноуты идет речь ? Такое ощущение, что mgre + nhrp только на цысках работает. opennhrp последний релиз от 2013 года, а в рассылке к нему пишут про требование ARPD со стороны ядра. В том-то и дело, что рабочих современных экзамплов найти не могу.

Всем привет. Есть задача сделать point-to-multipoint сеть на nbma сети. Т.е. mgre + nhrp овер интернет. Как бы большая плоская сеть с кучекй нейборов в mgre. В статике всё работает, если на всех хостах прописать всех нейборов, то всё ок. Хочется динамики. Для этого вроде бы есть nhrp: ноды регистрируются на хабе (или на нескольких хабах), хабы знают про все ноды. При необходимости (как ее создать ?) нода запрашивает у хаба nbma(т.е. публичный адрес ноды в интернете) адрес, получает ответ и туннель начинает работать. Вторая нода так же узнает про первую на хабе по загадочной необходимости и у себя делает запись про нейбора (на какой-то ТТЛ) и туннель в обратную сторону тоже начинает работать. Что-то типа АРП но для гре. Так всё в теории, на виртуалках так не работает -- ноды не хотят ничего узнавать у хаба, точнее, я пока не знаю, как сказать нодам "адреса нейборов вот для этого диапазона надо узнавать у хаба, потому что он доступен напрямую через туннель". Делаю пока всё без ipsec (там столько мест, где можно ошибиться). За основу для frr и quagga взял https://github.com/FRRouting/frr/blob/master/nhrpd/README.nhrpd. Вот там как бы и нет указания на то, что именно надо "резолвить у хаба", а адреса на туннелях делаются /32, с другими масками регистрация на хабе вообще не работает. Три ноды в трёх разных ip-сетях (192.168.10{1..3}.2), гре туннели вида: iface gre1 inet static pre-up ip tunnel add $IFACE mode gre key 42 ttl 64 dev e#th0 || true address 10.0.0.{1..3} netmask 255.255.255.255 post-down ip tunnel del $IFACE || true a1# sh ru #(hab) Building configuration... Current configuration: ! frr version 7.1 frr defaults traditional hostname a1 log syslog no ipv6 forwarding ! debug nhrp all ! interface gre1 ip nhrp network-id 1 ip nhrp registration no-unique ip nhrp shortcut no link-detect tunnel source eth0 ! router bgp 65000 neighbor Q peer-group neighbor Q remote-as 65000 neighbor Q disable-connected-check bgp listen range 0.0.0.0/0 peer-group Q ! address-family ipv4 unicast network 10.0.0.0/16 redistribute nhrp neighbor Q route-reflector-client exit-address-family ! line vty ! # spoke 1 alpine2# sh ru Building configuration... Current configuration: ! frr version 7.1 frr defaults traditional hostname alpine2 no ip forwarding no ipv6 forwarding ! interface gre1 ip nhrp network-id 1 ip nhrp nhs dynamic nbma 192.168.101.2 ip nhrp registration no-unique ip nhrp shortcut no link-detect tunnel source eth0 ! router bgp 65000 neighbor 10.0.0.1 remote-as 65000 neighbor 10.0.0.1 disable-connected-check ! line vty ! end alpine2# # spoke2 alpine3# sh ru Building configuration... Current configuration: ! frr version 7.1 frr defaults traditional hostname alpine3 no ip forwarding no ipv6 forwarding ! interface gre1 ip nhrp network-id 1 ip nhrp nhs dynamic nbma 192.168.101.2 ip nhrp registration no-unique ip nhrp shortcut no link-detect tunnel source eth0 ! router bgp 65000 neighbor 10.0.0.1 remote-as 65000 neighbor 10.0.0.1 disable-connected-check ! line vty ! end alpine3# Вроде бы рекомендуют именно так делать. В этой схеме почему-то надо чтобы первый пакет пошел через хаб, хаб бы его пророутил и послал бы nhrp-redirect, после чего на ноде возникает нейбор и туннелирование идёт напрямую минуя хаб. Один раз даже заработало (включил форвардинг и iptables правило из документации на хабе), заработало только в одну сторону, второй спок продолжал слать ответы через хаб. С opennhrp на туннелях делал /16 , геристрация вообще не работала. В сети вообще очень мало про opennhrp и он наверное мёртв (?) Вопрос: как объяснить спокам, что надо узнавать адреса нейборов на хабе и слать трафик напрямую в туннель между споками, а не через хаб ? Если есть рабочие конфиги для любых nhrp демонов, то просьба поделиться ими и нюансами в настройке. У цыски настраивается немного иначе, но в frr/quagga нет таких точно команд, а у меня нет цысок чтобы проверить :-). Может быть есть другой способ сделать point-to-multipoint на линуксах ?

Спасибо, вроде бы работает, если в /etc/iproute2/rt_tables прописать тыщу таблиц. По крайней мере добавлять и потом смотреть получилось, дальше пока не тестировал :-).

Всем привет. Столкнулся с потенциальной проблемой масштабирования PBR в linux. Обще известное решение выглядит примерно так: пишем ip rule которое матчит, например, сорс ойпи пакета и в качестве экшн направляется в какую-то таблицу маршрутизации посмотреть default gw или что там еще будет. Вроде бы ничего другого кроме таблицы там указать-то и нельзя. Таблиц в ядре очень много (https://serverfault.com/questions/315705/how-many-custom-route-tables-can-i-have-on-linux) но iprouter2 по каким-то причинам имеет доступ только от 0до 255 (реально от 1 до 252), остальные 2^30 недоступны. Предполагаю это пространство зарезервировано под namespace или что-то другое. В общем, надо иметь возможность сделать больше чем 255 ПБР и всё. Вопрос: что можно сделать, если мне понадобится сконфигурировать более 255 политик ? Есть ли другие хорошо поддерживаемые способы делать PBR в линукс ? P.S. Если я правильно помню, то у цыско в роут-мап тоже существует ограничение на 256 записей :-), но это не точно. Типа "если тебе нужно больше, то у тебя неправильный дизайн сети" (с) цыско. Но в данном случае дизайн никогоне интересует, надо чтобы работало и чтобы не было предела в 255 ПБР политик, ну хотя бы на порядок больше хочется :-), 255 это как-то не серьёзно в 2019 году.

Попробуйте указать в конфиге отсутствующую ноду, которая потом появится у вас. Т.е. наверное для 10.10.10.2 добавить секцию.

Покажите, что в конфиге-то ?

Поведение пустых ACL может отличаться от места применения, если вешается как ACL на интерфейс то трафик не блокируется (то есть будто ACL не назначали). В случае с neighbor-filter может быть такая же история: пустой ACL не влияет на соседства. С mvr не сталкивался, нормально ли описанное вами не скажу. И для диагностики проблем с мультикастом лучше включать дэбаг pim'а, сэкономите часы времени, настолько причины ошибок или непонятного поведения порой бывают неожиданны. На самом деле на других маршрутизаторах (там похожая конфигурация mvr влана) этот ACL содержит deny any. В "sh ip pim nei" никогда левых нейборов никогда не было, т.е. скорее всего этот расколбас делается своими же нейборами. acl я заполню, но чё-то пока кардинальных изменений вообще нет, только после перевода в читый sparse-mode пачки пакетов исчезли, но асерты всё равно есть и непонятно, чем они вызваны. На счёт дебага: есть опасения потерять управление при включении любого дебага :-). Его же нельзя на 5 минут включить, чтобы он потом сам отключился. Ничего страшного не будет ? А то ответственная железка и идти до неё не близко. Ещё такой вопрос: может ли этот расколбас быть из-за потерь в сети ? Я конечно на мониторинг всё уже поставил, потерь не задетектил, ошибок на интерфейсах нет, но может быть я что-то упустил.

Конечно могут, только пакеты PIM передаются мультикастом и пакеты PIM от абонентов (если такие приходят) вы должны видеть. Для включения маршрутизации мультикаста в вилане необходимо разрешать на нем PIM (собственно процесс PIM и создает мультикаст-маршруты чтобы трафик лился куда надо), подписка при этом может быть по PIM либо IGMP. А чтобы абоненты не влияли на ваш PIM надо на вилане включать BSR-border и настраивать ACL запрещающий PIM соседства. Это касательно циски и обычных виланов с мультикастом, в вашем случае с MVR и не-циско настройки могут быть несколько иные. На влане, который потом в других свичах является mvr теперь сделано так: ip address X.X.12.1 255.255.255.0 secondary ip address X.X.255.209 255.255.255.252 no ip redirects no ip proxy-arp ip pim neighbor-filter MC <-- пустой acl,ничего не разрешено.Просто он там был я новый не стал делать ip pim bsr-border ip pim sparse-mode ip igmp snooping mrouter interface GigabitEthernet3/29 <-- там есть источники мультиков, они просто льют поток ip igmp snooping mrouter interface GigabitEthernet3/31 ip igmp snooping mrouter interface GigabitEthernet4/9 ip igmp snooping mrouter interface GigabitEthernet4/10 ip igmp snooping mrouter interface GigabitEthernet4/27 ip igmp snooping mrouter interface Port-channel12 ip ospf database-filter all out Ещё заметил, что sh ip pim interface для этого влана выводит звёздочку, хотя NbrCount там ноль. Про звёздочку ничего ненашёл, но скорее всего это то, откуда есть потоки, так ? Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior ... X.X.255.209 Vlan13 v2/S * 0 30 1 X.X.255.209 ... neighbor-filter ничего не изменил, по-прежнему есть Hello и Assert, пачками не вылетают, но они есть на этом влане. Ещё есть подозрения, что я не там ищу... P.S. Скоре всего звёздочкой в sh ip pim interface обозначается bsr-border P.P.S. Поставил кваггу с pimd на свой комп и отключил ip pim neighbor-filter MC, не завязались квагга со свичем :-). Т.е. квагга нейбора как бы видела, а свич кваггу не видел. Видимо, с mvr всё же клиенты не могут влиять на pim. Кваггу я ставил, чтобыв дебаге узнать причину ассертов, но не узнал ...

Поменял везде, где нашёл, на sparse, пока что пачек пакетов не видел, но единичные hello и asert есть. Так что есть разница между sparse-dense и sparse (может быть времени мало прошло и они ещё прилетят :-)). Hello раз в 30 секунд или на каждый assert, а assert стали не часто и по одному прилетать. Прилетает всё это действительно скорее всего через mvr. Интересно, клиенты могут поафектить своим пимом или нет ? Ещё пробовал на mvr влане убирать pim и вместе с ним пропадает igmp snooping, т.е. перестаёт показывать. Так и должно быть или надо как-то по-другому сделать ? В mvr влане роутеров мультикаста нет и источников тоже, есть только абоненты.

Ну тутпросто так было сделано, пока не ясно почему. Либо это действительно было надо, либо просто забыли или не знали, что надо отключать. Все Hello и Assert летят от маршрутизатора сети, т.е. не от разных, а от одного, который и есть главный (судя по сорс маку). Посмотрел: pim на клиентском интерфейсе выключен, скорее всего он через mvr залетает. Т.е. клиенты на него поаффектить не могут, но на него что-то другое аффектит значит. И ещё почему-то везде включено ip pim sparse-dense-mode, ip pim sparse-mode только в одном месте включено. почему так, пока нет возможности спросить, знающие люди в отпуске.

В сети есть mvr. Заметил, что временами в клиентский порт прилетает пачка PIM Hello и PIM Assert. Т.е. обычно только PIM Hello раз в 30 секунд прилетает, но потом бац и 70 пакетов за секунду, а может и больше, прилетает Hello и Assert в перемешку через одного. Смотрел вирешарком, соержимое разное, значит не петля. Есть подозрение, что в такие моменты каналы подсыпаются. Что это может быть ?

Что за роскмсвобода ? У вас есть dump.xml с ЭЦП, там всё написано: /usr/bin/xml2 < /path/to/dump.xml > dump.txt ... /reg:register/content/@id=441821 /reg:register/content/@includeTime=2017-02-05T13:25:50 /reg:register/content/@entryType=1 /reg:register/content/@blockType=ip /reg:register/content/@hash=4CA2BC0B54EA6F21DB521DAEA89A35B5 /reg:register/content/decision/@date=2013-05-23 /reg:register/content/decision/@number=2-1687/2013 /reg:register/content/decision/@org=суд /reg:register/content/ip=130.185.148.13 /reg:register/content/ip /reg:register/content/ip=130.185.148.12 /reg:register/content/ip /reg:register/content/ip=130.185.148.21 /reg:register/content/ip /reg:register/content/ip=130.185.148.24 /reg:register/content/ip /reg:register/content/ip=130.185.148.25 /reg:register/content/ip /reg:register/content/ip=130.185.148.29 /reg:register/content/ip /reg:register/content/ip=130.185.148.31 /reg:register/content/ip /reg:register/content/ip=130.185.148.32 /reg:register/content/ip /reg:register/content/ip=130.185.148.34 ... Объект добавлен 2017-02-05T13:25:50. Тип блокировки ip -- надо вообще всё блокировать по идее.

После изменения способа подключения сервера (мультикаст подали в отдельном влане) перестала работать запись каналов по расписанию (пользователь на пульте включает запись и потом смотрит). Показывает, что идёт запись, но потом при попытке посмотреть выдаёт "Сервер недоступен" и всё, файлик нулевой длины создаётся. Сейчас вот такая конфигурация: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 90:e6:ba:71:ae:53 brd ff:ff:ff:ff:ff:ff inet X.Y.Z.88/26 brd 78.140.15.127 scope global eth0 inet6 fe80::92e6:baff:fe71:ae53/64 scope link valid_lft forever preferred_lft forever 6: eth0.14@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 90:e6:ba:71:ae:53 brd ff:ff:ff:ff:ff:ff inet 10.11.12.3/24 scope global eth0.14 inet6 fe80::92e6:baff:fe71:ae53/64 scope link valid_lft forever preferred_lft forever # ip r default via X.Y.Z.65 dev eth0 10.11.12.0/24 dev eth0.14 proto kernel scope link src 10.11.12.3 X.Y.Z.64/26 dev eth0 proto kernel scope link src X.Y.Z.88 224.0.0.0/4 dev eth0.14 scope link python dumpstream -a 233.173.129.16 -p 1234 ничегоне вываливает, но в соседней консоли видно, что на eth0.14 поток для этой группы летит. В какой момент времени начал лететь поток я не знаю, может он там и до запуска dumpstream летел :-). Т.е. пока не получается явно узнать, из-за чего перестала работать запись каналов по расписанию. Что можно сделать ? UPD: Попробовали запустить dumpstream на группу, которая там точно не летит -- ничего не полетело. tcpdump не показал ничего в том числе и igmp-запросов на эту группу. Может в этом всё и дело, что igmp запросы куда-то не туда улетают или их никто не шлёт ?

Доброго времени. Может кому-нибудь будет полезно. Еще один вариант [рабочий] полисера на TC. Недостаток, нельзя выделить одно полосу для нескольких ip, как в HTB (Хотя может я и не разобрался до конца). /sbin/tc qdisc add dev bond0.628 ingress /sbin/tc f a dev bond0.628 parent ffff:0 prio 10 handle 3: protocol ip u32 divisor 256 /sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 800:: match ip dst 192.168.64.0/18 hashkey mask 0x000000ff at 16 link 3: /sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 3:0x63: match ip dst 192.168.120.99 action police rate 5500Kbit burst 550K drop mtu 1500 flowid :12 /sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 3:0x62: match ip dst 192.168.120.98 action police rate 5500Kbit burst 550K drop mtu 1500 flowid :13 Не совсем понял этот пример. последний октет адреса является ключом к хешу, т.е. ойпи 192.168.120.98 попадает в 3:0x62 (98 = 0x62), а зачем тогда ещё один матч делать ? Т.е. зачем нужна запись "match ip dst 192.168.120.98" ведь пакет и так уже попал в 3:0x62, может без матча будет работать ? Если без этого матча будет работать, то ещё несколько процессорных тактов освободится. На самом деле я правда не знаю, я такое несколько лет назад на htb и затем на hfsc делал, но уже всё забыл.

С точки зрения Яровой -- да, мы должны всё, что она с товарищами напридумывали и подразумели. Либо мы должны платить бабло, т.е. штрафы. Что касается SCE, то это оборудование создавалось не для реализации законопроектов Яровой, а для другого -- там не было целей фильтровать трафик в ситуации активного противодействия этому :-). Т.е. просто фильтровать SCE может, а когда записи в реестр вносят не всегда и не совсем адекватные "специалисты", то 100% фильтрации получить невозможно. Надо ещё постоянно следить за этими записями и за "специалистами". Так же у SCE есть ограничения, которые рано или поздно будут достигнуты этими "специалистами": слишком много записей в реестр будет добавлено, слишком длинные url будут добавлены, слишком неадекватные записи будут добавлены ... да мало ли чего ещё из непредусмотренного может случиться ? :-). SCE же не всё может ...

Забыл добавить что когда свич вис на него и по консоли не достучишься. Нет управляющий и абонентов вланы разные. 1 влан вообще не используем. Конфигурим через консоль. После замены свичей на новые, уже пол года без нареканий работают. На всех обновил прошивку до 1.5.1.18. Полет нормальный. :-) Виснут они из-за утечек памяти -- консоль при этом тоже не работает. Утечки памяти у них в ДНК -- их копипастят китайцы из старого кода в новый, как я уже говорил -- из кода для старых свичей в код прошивок для новых моделей. Потому чтоу них одни и те же баги были замечены в разных моделях, которые на совсем разных чипсетах были сделаны. Утечки там есть и вряд ли их оттуда уберут. Значит надо делать так, чтобы в ЦПУ как можно меньше попадало трафика. Ещё было замечено, что у одной модели (ES3528M) одной h/w вершн было разное поведение, но это касалось diag кода: после одновления diag и reload все свичи загружались и работали, но после ребута по питанию больше половины не загружалось, но остальные загружались и работали нормально. Седых волос на голове у меня тогда стало на много больше чем было до этого :-), сильно я не мог экспериментировать собирать статистику, просто очень быстро поменял везде diag на прежнюю версию и больше никогда его удалённо не апгрейдил. Этот факт позволяет нам сделать вывод, что свичи в пределах одной модели и одной h/w version всёравно могут аппаратно отличаться. Завод изготовитель оставляет за собой право вносить изменения в конструкцию ... (с). А может у вас порсто дефектные свичи попались :-). Первый влан у ТС в тектовом файлике фигурирует, поэтому я про него и написал. У меня были 3528М с аптаймами больше года и это были не access свичи, за ними ещё было несколько свичей и клиенты в них тоже были включены.

Если вы не обновляли прошивку, то рискну предположить, что вы и настраивали свичи не вполне достаточно ? может у вас влан управления и клиентский влан это один и тот же влан ? Может вы используете влан 1 ? Может вы их по веб-морде конфигурите ? Может вы spanning-tree оставляете с настройками по-умолчанию ? Да там столько всего может быть, что лучше вам начать пкоазывать конфиги свичей, которые виснут, и рисовать схемы :-). Вот чё это за хрень ? interface ethernet 1/25 switchport allowed vlan add 1 untagged switchport mode trunk switchport allowed vlan add 1,178,195,199,419 tagged Вот так надо аплинк настраивать: interface ethernet 1/26 switchport mode trunk switchport ingress-filtering #1 switchport allowed vlan add 18,936 tagged switchport allowed vlan remove 1 #4 spanning-tree edge-port #2 spanning-tree spanning-disabled spanning-tree bpdu-filter spanning-tree tc-prop-stop mvr domain 1 type source #3 #1 - без этой команды все неизвестные свичу вланы будут влетать ему в ЦПУ и ему будте "бо-бо" #2 - использовать спаннинг три в ежах не хочешь ты #3 - ну это если ойпи-тэвэ есть #4 - Первый влан нахер из сети выкорчёвываем -- потому что он для любого оборудовани дефолтный, можно наошибаться и получить кучу глюков, а если вы его использовать перестанете, то вы все вланы сконфигурите и скорее всего правильно - наошибаться вероятность меньше. Есть ещё другие причины, по которым использование влана номер один является показателем некомпетентности администраторов сети.

+1. У ежей это из поколения в поколение передаётся ;-). Там разработчики баги копипастят из предыдущего софта. Надо чтобы им в проц летело как можно меньше -- отключайте все подряд ненужные фичи, которые выполняются в ЦПУ (stp, lldp и т.п., снупинги, фигупинги, вообще всё, без чего сможете жить) , смотрите, что у вас летает в влане управления, сегментируйте управление, чтобы там меньше всяких броадкастов летало, ставьте на edge, на core не ставьте ;-). Ну если уж совсем быстро надо, то для начала отключите spanning-tree на порту вышестояшего мутатора для цепочки из ежей.

Пожалуйста, ткните носом дайте ссылку на требования к железу для extfilter -- надо собрать сервер (наконец-то!). На сколько я помню, нужно N сетевых карт из списка поддерживаемых http://dpdk.org/doc/nics (наверное лучше Intel карты) для зеркала и ещё минимум одну для работы с по сети, по одному ядру на карту для зеркала + сколько-то ядер под ОС. Я всё правильно перечислил или есть ещё какие-то особенности ?

Единственный метод дающий 146% гарантию - ведение БД. поэтому в сети лучше иметь одного вендора, хотя бы на раздаче В силу естественных причин это не всегда возможно. Ну я же написал в начале, что хранить данные в базе можно до тех пор, пока туда люди не внесут косячные данные или забудут поменять :-). Людям свойственно ошибаться. Можно конечно самому вести эту базу, но я больше не хочу этого делать :-).

Одинаково у всех вендоров ? и всех моделей одного вендора ? Нет же, так бы юзали :-). Бекап-то делается, проблема в другом: как надёжно определить модель свича ?

Решил написать функцию для своих будущих скриптов на expect, которая лезет на свич и узнаёт его модель. Дело в том, что даже у разных моделей одного вендора, например, команды сохранения конфига на tftp разные (!), они сильно похожи, но немного отличаются. в качестве примера можно указать на DES-3200, у которого даже у разных ревизий команды отличаются ("upload cfg_toTFTP ${TFTPIP} dest_file /${CFGNAME}" - у А1 и "upload cfg_toTFTP ${TFTPIP} /${CFGNAME}" у С1). Я не говорю уже о разных вендорах в сети :-). В общем, отличной идеей было хранить модель конкретного свича в базе, но до тех пор, пока коллеги не начали ошибаться при работе с базой. Свич заменили, исправить забыли или просто ошиблись. Хочу в скрипте, который что-то будет делать на свиче, узнавать, что за свич и в зависимости от модели выполнять именно ту команду, которая для данной модели точно подходит. Когда стал писать эту функцию, то для длинков в какой-то мере получилось, а на е-коре уже ступор :-). Там в sh version и в sh system нет названия модели в некоторых моделях :-). Что делать ? Может вообще как-то иначе узнавать модель свича ? Хотелось бы услышать конструктивные предложения.

... кстати, заметил, что так(см. конфиг выше) почему-то не работает. Выдаёт только второй адрес, либо два вторых адреса. Не могу объяснить почему :-). UPDATE: вроде работает -- поменял в конфиге индексы у &DHCP-Domain-Name-Server с 1 и 2 на 0 и 1, потом в конфиге модуля cache соответственно. После чего в tcpdump стало видно по два разных ip-адреса DNS.