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

kaktak

Активный участник
  • Публикации

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

  • Посещение

Все публикации пользователя kaktak


  1. Знаю, что тема избитая, но все эти модули сапы и прочее для меня темный лес... Задачи примерно такие: нужен только роутинг, цель раздать 5-10 клиентам 2-3 Гб трафика, 2 full view в одном vrf и по 5-10 тыс. префиксов еще в паре vrf (различные IX). Это задача максимум... также рассмотрю варианты без FV... т.е. нужно определить для руководства ценовую вилку и примерные конфигурации железа. Буду очень признателен, если в своих советах вы будете указывать назначение того или иного модуля. Про linux софт роутер я в курсе, просто хочеться рассмотреть все варианты.
  2. угу, есть такое наблюдение. а что скажите насчет остального?
  3. А можно ли тут публиковать вакансии?

    Ну раз такое дело... ) Объясните, чем вам так rc.local не угодил? Оно конечно идейно не правильно, я и сам стремлюсь к использованию инструментария дистрибутива, но все-таки, что плохого? ) Это ж почти "sh run"! Зашел по ссш на писюк - cat /etc/rc.d/rc.local и уже почти все о нем знаешь ) Другое дело, если опытному например дебианщику, по долгу службы понадобится разобраться с идейно правильно настроенным центосом. Да этож надо целую книгу выкурить.
  4. smartctl -H /dev/hdc smartctl version 5.38 [i686-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED smartctl -A /dev/hdc smartctl version 5.38 [i686-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 075 063 044 Pre-fail Always - 155568880 3 Spin_Up_Time 0x0003 099 099 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 24 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 082 060 030 Pre-fail Always - 198862163 9 Power_On_Hours 0x0032 076 076 000 Old_age Always - 21818 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 037 020 Old_age Always - 24 184 Unknown_Attribute 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Unknown_Attribute 0x0032 100 056 000 Old_age Always - 4295035960 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 073 064 045 Old_age Always - 27 (Lifetime Min/Max 10/36) 194 Temperature_Celsius 0x0022 027 040 000 Old_age Always - 27 (0 10 0 0) 195 Hardware_ECC_Recovered 0x001a 039 031 000 Old_age Always - 155568880 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 Полный вывод:
  5. Linux, Nagios + немного роутинга. Несколько раз в сутки в логи вываливается следующее: hdc: status timeout: status=0xd0 { Busy } ide: failed opcode was: unknown hdc: no DRQ after issuing MULTWRITE_EXT ide1: reset: success Кто расшифрует? Это начало конца или винт просто не вывозит кол-во обращений (из-за нагиоса например)?
  6. еще как! ) а если серьезней то поддержка igmp snooping на них есть, но нет ism/mvr.
  7. Я так понял это приведет к тому, что оно не будет пытаться восстановить криво оборванные сессии, а вместо этого будет будет тихо дропать пакеты, не подходящие под текущее состояние соединения. А отрицательные последствия будут? )
  8. Похоже дело в таймерах.. например приходит от клиента FIN на закрытие, а записи в коннтраке уже нет. Пакет помечается как invalid и летит себе минуя nat. Может кто поделиться грамотными настройками коннтрака? (sysctl -a | grep 'conntrack')
  9. ... пиво! Далее моя фантазия заводит меня в такие дебри, что лучше не писать...
  10. Подождать пока это же предписание дойдет до ваших апстримов и со спокойной совестью отчитаться о миссион комплите )
  11. CCNA иметь или не иметь?

    Да нее, ТС теперь считает, что если сдать CCNA и не сдавать CCNP, то в итоге получит заведомо более низкую оценку своих знаний (основанную на резюме).
  12. CCNA иметь или не иметь?

    В схемотехнике ситуация схожая - разрабатывают новое единицы, основная масса копирует уже готовые схемотехнические решения.
  13. Собственно полезно иметь или наоборот? С одной стороны у профессионалов на форуме сформировалось довольно негативное отношение к обладателям оных - дескать "знаний 0, а чсв зашкаливает". С другой - работодатели зачастую отдают предпочтение именно сертифицированным специалистам (например при прочих равных).
  14. # conntrack -S conntrack v1.0.0 (conntrack-tools): Can't open /proc interface Cудя по исходникам тулза лезет за статистикой в /proc/net/stat/nf_conntrack, а у меня там более древний вариант: /proc/net/stat/ip_conntrack. На всякий случаю даю cat: entries searched found new invalid ignore delete delete_list insert insert_failed drop early_drop icmp_error expect_new expect_create expect_delete 0000ce59 e5a7221a db2a074a 184d9844 037044a7 0005f7eb 18492a1d 0e75fb18 0e7d8cbf 00000007 00000000 00000000 01a56ae0 00000000 00000000 00000000 0000ce59 e241644e da330ad9 18310967 036e734c 0005f5e5 1835515d 0e65ce63 0e5e3fca 00000009 00000000 00000000 01a5102b 00000000 00000000 00000000 0000ce59 e48a68ad da9571aa 184a6793 036fc6ea 0005f1e8 18456580 0e7464a0 0e7c6804 00000006 00000000 00000000 01a5348d 00000000 00000000 00000000 0000ce59 e14902b5 d9b2371e 182dc0ec 036df6a5 0005f8c4 18321ad7 0e642830 0e5cf017 00000007 00000000 00000000 01a4e617 00000000 00000000 00000000 Инвалидов много ага... но ip_conntrack_max вряд ли виновен: net.ipv4.netfilter.ip_conntrack_count = 54466 net.ipv4.netfilter.ip_conntrack_max = 262144 к тому же насколько я помню переполнение коннтрака логируется.
  15. NAT сервер на linux. Несколько десятков правил вида: iptables -t nat -A POSTROUTING -o eth0.300 -s 192.168.200.0/27 -j SNAT --to-source ${white_ip_1} iptables -t nat -A POSTROUTING -o eth0.300 -s 192.168.200.32/27 -j SNAT --to-source ${white_ip_2} iptables -t nat -A POSTROUTING -o eth0.300 -s 192.168.200.64/27 -j SNAT --to-source ${white_ip_3} iptables -t nat -A POSTROUTING -o eth0.300 -s 192.168.200.96/27 -j SNAT --to-source ${white_ip_4} ... Раньше не обращал внимания, но недавно заметил, что не внешнем интерфейсе периодически видны запросы с серыми src_ip из моего диапазона: # tcpdump -nni eth0.300 net 192.168.200.0/24 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0.300, link-type EN10MB (Ethernet), capture size 96 bytes 14:23:22.220704 IP 192.168.200.236.2786 > 81.19.88.81.80: F 1380642332:1380642332(0) ack 1742972196 win 17084 14:23:23.081629 IP 192.168.200.114.59121 > 95.72.36.59.59275: F 2569647600:2569647600(0) ack 3804050925 win 92 <nop,nop,timestamp 23124665 307778> 14:23:28.113995 IP 192.168.200.140.59621 > 114.166.232.79.27694: R 3930089021:3930089021(0) ack 1431587174 win 0 14:23:28.475097 IP 192.168.200.140.59503 > 123.194.59.20.16440: R 915569888:915569888(0) ack 3963260584 win 0 Чем это можно объяснить? При этом в целом все работает без проблем. Из тюнинга коннтрака только: net.ipv4.netfilter.ip_conntrack_max = 262144 net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 300 net.ipv4.netfilter.ip_conntrack_generic_timeout = 300 echo 32768 > /sys/module/ip_conntrack/parameters/hashsize
  16. В основном centos, местами fedora (не моя идея). В принцыпе так и думал, что дистрибутивная часть скорее всего обновится без проблем, а вот то чего там сверху наставлено может и не завестись... и это печально ) А все-таки насколько опасно держать не обновлённые сервера с белыми адресами? мб есть вариант обновить самые критичные пакеты?
  17. Вопрос нубский, но помидорами просьба не забрасывать ) Есть несколько рабочих маршрутизаторов на Linux и пара серверов mysql+apache. Все бы ничего, но не обновлялось все это дело уже больше года. В связи с этим вопрос - насколько это опасно, учитывая, что порты по большей части во внешку закрыты. И с какой долей вероятности они успешно обновятся (и загрузятся =)) со стандартных репозиториев спустя такой период времени?