Перейти к содержимому
Калькуляторы

wtyd

Активный участник
 Просмотреть профиль  Активность

  • Публикации

    530

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем wtyd

  1. Опубликовано · Жалоба на ответ

    On 9/16/2019 at 2:21 PM, VolanD666 said:

    Т.е. так можно и к цисковскому DMVPN подключаться?

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

  2. Опубликовано · Жалоба на ответ

    Получилось запустить на 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 проходит и надо заново резолвить. безопасность ... её нет, т.е. надо ойписекас делать.

  3. Опубликовано · Изменено пользователем wtyd · Жалоба на ответ

    Потому что иначе регистрация в хабе вообще не происходит, я пробовал. Еще в примерах frr именно так указано делать (http://docs.frrouting.org/en/latest/nhrpd.html). Про какие ноуты идет речь ?

    Такое ощущение, что mgre + nhrp только на цысках работает. opennhrp последний релиз от 2013 года, а в рассылке к нему пишут про требование ARPD со стороны ядра. В том-то и дело, что рабочих современных экзамплов найти не могу.

  4. Опубликовано · Жалоба на ответ

    Всем привет.

     

    Есть задача сделать 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 на линуксах ?

  5. Опубликовано · Жалоба на ответ

    20 hours ago, rm_ said:

    А вы ваши таблицы прописали в /etc/iproute2/rt_tables (и ID для них)? Использую у себя автодобавление таблиц туда со случайно генерируемым ID, они получаются очень большими (например 353283, 275972), принимаются без проблем.

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

  6. Опубликовано · Жалоба на ответ

    Всем привет.

     

    Столкнулся с потенциальной проблемой масштабирования 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 году.

  8. Опубликовано · Жалоба на ответ

    В 26.08.2017 в 22:48, fractal сказал:

    Хочу поднять кластер из 2-х серверов

     

    Что сделал (пока работаю с одним)

     

    1. Raid10 из 4-х дисков по 2TB

    2. Разбил raid на 2 раздела, первый 200Гб, второй 3500Гб

    3. Установил drbd

     

    Пока у меня есть только один сервак, хочу настроить на нем все, далее перенести с работающего сервака виртуалки на него и далее работающий сервак загнать в кластер, но drbd ругается

     

      

    
root@pve-1:~# drbdadm up r0
/etc/drbd.d/r0.res:1: in resource r0:
       Missing section 'on  { ... }'.
resource r0: cannot configure network without knowing my peer.
     

     

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

  9. Опубликовано · Жалоба на ответ

     ip pim neighbor-filter MC <-- пустой acl,ничего не разрешено.Просто он там был я новый не стал делать

    Поведение пустых ACL может отличаться от места применения, если вешается как ACL на интерфейс то трафик не блокируется (то есть будто ACL не назначали). В случае с neighbor-filter может быть такая же история: пустой ACL не влияет на соседства.

    С mvr не сталкивался, нормально ли описанное вами не скажу. И для диагностики проблем с мультикастом лучше включать дэбаг pim'а, сэкономите часы времени, настолько причины ошибок или непонятного поведения порой бывают неожиданны.

     

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

     

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

     

    Ещё такой вопрос: может ли этот расколбас быть из-за потерь в сети ? Я конечно на мониторинг всё уже поставил, потерь не задетектил, ошибок на интерфейсах нет, но может быть я что-то упустил.

  10. Опубликовано · Изменено пользователем wtyd · Жалоба на ответ

    Интересно, клиенты могут поафектить своим пимом или нет ?

    Конечно могут, только пакеты 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. Кваггу я ставил, чтобыв дебаге узнать причину ассертов, но не узнал ...

  11. Опубликовано · Жалоба на ответ

    PIM sparse-dense это (по крайней мене на цисках) pim sparse для всех групп кроме тех, для которых указано что они dense, то есть при настройках по умолчанию в работе sparse-dense = sparse.

     

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

     

    Ещё пробовал на mvr влане убирать pim и вместе с ним пропадает igmp snooping, т.е. перестаёт показывать. Так и должно быть или надо как-то по-другому сделать ? В mvr влане роутеров мультикаста нет и источников тоже, есть только абоненты.

  12. Опубликовано · Изменено пользователем wtyd · Жалоба на ответ

    Assert посылается когда в сегменте больше одного маршрутизатора PIM, это стандартное поведение протокола, так исключается дублирование мультикаст вещания одновременно несколькими маршрутизаторами в сегменте. В одном вилане пачками они прилетать не должны однозначно, надо включать дебаг PIM и разбираться почему так происходит.

    Частично согласен с предыдущим оратором: отключить PIM Hello скорее всего нельзя, однако запретить или ограничить PIM соседства на абонентских портах однозначно стоит.

    И по вашему сообщению не понятно от кого прилетают PIM Hello и Assert, от ваших же маршрутизаторов или это абоненты изучают сетевые протоколы.

     

    Ну тутпросто так было сделано, пока не ясно почему. Либо это действительно было надо, либо просто забыли или не знали, что надо отключать. Все Hello и Assert летят от маршрутизатора сети, т.е. не от разных, а от одного, который и есть главный (судя по сорс маку).

     

    Посмотрел: pim на клиентском интерфейсе выключен, скорее всего он через mvr залетает. Т.е. клиенты на него поаффектить не могут, но на него что-то другое аффектит значит. И ещё почему-то везде включено ip pim sparse-dense-mode, ip pim sparse-mode только в одном месте включено. почему так, пока нет возможности спросить, знающие люди в отпуске.

  13. Опубликовано · Жалоба на ответ

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

     

    Что это может быть ?

  14. Опубликовано · Жалоба на ответ

    Снял отчет ревизором получил пропуск https://130.185.148.34/en/,130.185.148.34, GET хотя адрес заблокирован. Но есть одно но. на Роскомсвободе дата добавления 15.03.2017, а в отчете 05 Фев, 2017 10:25:50. Блин чет у них не все нормально согласованно.

     

    Что за роскмсвобода ? У вас есть 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 -- надо вообще всё блокировать по идее.

  15. Опубликовано · Изменено пользователем wtyd · Жалоба на ответ

    После изменения способа подключения сервера (мультикаст подали в отдельном влане) перестала работать запись каналов по расписанию (пользователь на пульте включает запись и потом смотрит). Показывает, что идёт запись, но потом при попытке посмотреть выдаёт "Сервер недоступен" и всё, файлик нулевой длины создаётся. Сейчас вот такая конфигурация:

    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 запросы куда-то не туда улетают или их никто не шлёт ?

  16. Опубликовано · Жалоба на ответ

    пожалуй присоеденюсь к просьбе,kayot. Позвольте полюбопытствовать Ваш подход, вернее реализацию.

     

    Доброго времени.

    Может кому-нибудь будет полезно.

    Еще один вариант [рабочий] полисера на 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 делал, но уже всё забыл.

  17. Опубликовано · Жалоба на ответ

    Это что, мы еще и все урлы на переадресацию проверять должны чтоле?

     

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

  18. Опубликовано · Жалоба на ответ

    Если вы не обновляли прошивку, то рискну предположить, что вы и настраивали свичи не вполне достаточно ? может у вас влан управления и клиентский влан это один и тот же влан ? Может вы используете влан 1 ? Может вы их по веб-морде конфигурите ? Может вы spanning-tree оставляете с настройками по-умолчанию ? Да там столько всего может быть, что лучше вам начать пкоазывать конфиги свичей, которые виснут, и рисовать схемы :-).

     

    Забыл добавить что когда свич вис на него и по консоли не достучишься. Нет управляющий и абонентов вланы разные. 1 влан вообще не используем. Конфигурим через консоль. После замены свичей на новые, уже пол года без нареканий работают. На всех обновил прошивку до 1.5.1.18. Полет нормальный. :-)

     

    Виснут они из-за утечек памяти -- консоль при этом тоже не работает. Утечки памяти у них в ДНК -- их копипастят китайцы из старого кода в новый, как я уже говорил -- из кода для старых свичей в код прошивок для новых моделей. Потому чтоу них одни и те же баги были замечены в разных моделях, которые на совсем разных чипсетах были сделаны. Утечки там есть и вряд ли их оттуда уберут. Значит надо делать так, чтобы в ЦПУ как можно меньше попадало трафика.

     

    Ещё было замечено, что у одной модели (ES3528M) одной h/w вершн было разное поведение, но это касалось diag кода: после одновления diag и reload все свичи загружались и работали, но после ребута по питанию больше половины не загружалось, но остальные загружались и работали нормально. Седых волос на голове у меня тогда стало на много больше чем было до этого :-), сильно я не мог экспериментировать собирать статистику, просто очень быстро поменял везде diag на прежнюю версию и больше никогда его удалённо не апгрейдил. Этот факт позволяет нам сделать вывод, что свичи в пределах одной модели и одной h/w version всёравно могут аппаратно отличаться. Завод изготовитель оставляет за собой право вносить изменения в конструкцию ... (с). А может у вас порсто дефектные свичи попались :-).

     

    Первый влан у ТС в тектовом файлике фигурирует, поэтому я про него и написал. У меня были 3528М с аптаймами больше года и это были не access свичи, за ними ещё было несколько свичей и клиенты в них тоже были включены.

  19. Опубликовано · Изменено пользователем wtyd · Жалоба на ответ

    Покупали партию в 35 штук что ли. Ставили все работало. Но вот 5-6 свичей из коробки без обновления прошивки начали сами по себе терять управление. Если юзер выключал роутер или комп, то не получал адреса от дхцп. Пробовали загрузчик и прошивку обновлять и что только не делали все равно теряли управление. Хотя другие скажем на соседней ветке где даже нагрузка была больше чем где завис работал без нареканий и мультикаст гонял. Сдали по гарантии в Вимком выдали новые а что стало со старыми не знаю.

     

    Если вы не обновляли прошивку, то рискну предположить, что вы и настраивали свичи не вполне достаточно ? может у вас влан управления и клиентский влан это один и тот же влан ? Может вы используете влан 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 - Первый влан нахер из сети выкорчёвываем -- потому что он для любого оборудовани дефолтный, можно наошибаться и получить кучу глюков, а если вы его использовать перестанете, то вы все вланы сконфигурите и скорее всего правильно - наошибаться вероятность меньше. Есть ещё другие причины, по которым использование влана номер один является показателем некомпетентности администраторов сети.

  20. Опубликовано · Жалоба на ответ

    Отулючайте всё лишнее. В логах то что? К зависшему свичу кончолью подключиться можно?

     

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

     

    Ну если уж совсем быстро надо, то для начала отключите spanning-tree на порту вышестояшего мутатора для цепочки из ежей.

  21. Опубликовано · Жалоба на ответ

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

  22. Опубликовано · Жалоба на ответ

    как надёжно определить модель свича ?

    Единственный метод дающий 146% гарантию - ведение БД.

     

    Я бы не стал так огульно утверждать за всех вендоров.

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

    В силу естественных причин это не всегда возможно.

     

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

  23. Опубликовано · Жалоба на ответ

    Бэкап прекрасно выполняется через снмп

     

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

  24. Опубликовано · Жалоба на ответ

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

     

    В общем, отличной идеей было хранить модель конкретного свича в базе, но до тех пор, пока коллеги не начали ошибаться при работе с базой. Свич заменили, исправить забыли или просто ошиблись.

     

    Хочу в скрипте, который что-то будет делать на свиче, узнавать, что за свич и в зависимости от модели выполнять именно ту команду, которая для данной модели точно подходит.

     

    Когда стал писать эту функцию, то для длинков в какой-то мере получилось, а на е-коре уже ступор :-). Там в sh version и в sh system нет названия модели в некоторых моделях :-). Что делать ? Может вообще как-то иначе узнавать модель свича ?

     

    Хотелось бы услышать конструктивные предложения.

  25. Опубликовано · Изменено пользователем wtyd · Жалоба на ответ

    ... кстати, заметил, что так(см. конфиг выше) почему-то не работает. Выдаёт только второй адрес, либо два вторых адреса. Не могу объяснить почему :-).

     

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