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

mt6561

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

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

  • Посещение

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


  1. 8-() КТО? И самое главное - зачем?
  2. Господа конкуренты, признавайтесь! Кто и зачем втирает клиентам, что RIPE больше не выдает /24? ;)
  3. Ага. И плюс еще накладные расходы. И плюс еще НДС. И плюс риски неоплаты. У нас получается себестомость 80-85 евро за объект, никак не меньше. Вобщем, видимо живут они ровно год до первого счета ;)
  4. Это нормально. Это один из мантейнеров самого RIPE. Он не закрывает объекты паролем, но информирует RIPE при любом изменении объекта. На этом мантейнере висят те as-ки и pi-ки, на которые есть договор поддержки с точки зрения райпа. Вот если его НЕТ там - то повод задуматься.
  5. Новые критерии выделения IP-адресов

    Поддержал, а чо! :)
  6. В свитч подключен, там транспорт гигабитный, еще один свитч и еще один комп-роутер аналогичный.
  7. Вот по англицки написано: нет буфферов. ethtool -g смотреть, ethtool -G ставить. разные бывают буфера.для начала посмотрите что за чип - lspci -v e1000 - это целое семейство. Встречаются в нем откровенно неудачные поделки igb, конечно, заметно резвей, но, к сожалению, драйвера для этого чипа на данный не являются шедевром стабильности -G стоит максимальное (4096). а сама карта - Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03)
  8. С ДР!

    С Днюхой!!! ;)
  9. Есть грабля на нагруженной сетевухе Intel, вот твкой: driver: e1000e version: 0.5.18.3-NAPI firmware-version: 5.11-2 bus-info: 0000:01:00.0 Наблюдаются потери пакетов, и растут дропы на RX: RX packets:281682443588 errors:2 dropped:11676407 overruns:0 frame:1 TX packets:420950175795 errors:0 dropped:0 overruns:0 carrier:0 А вот детальнее: ethtool -S eth3 NIC statistics: rx_packets: 281855482030 tx_packets: 421317081964 rx_bytes: 184591863557029 tx_bytes: 312544167665840 rx_broadcast: 26201327 tx_broadcast: 200472 rx_multicast: 12097883 tx_multicast: 202852 rx_errors: 2 tx_errors: 0 tx_dropped: 0 multicast: 12097883 collisions: 0 rx_length_errors: 0 rx_over_errors: 0 rx_crc_errors: 1 rx_frame_errors: 0 rx_no_buffer_count: 21102540 rx_missed_errors: 11676407 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 65833073 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 0 tx_restart_queue: 17713119 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 5302 tx_tcp_seg_failed: 0 rx_flow_control_xon: 66462649 rx_flow_control_xoff: 66689453 tx_flow_control_xon: 801606 tx_flow_control_xoff: 928116 rx_long_byte_count: 184591863557029 rx_csum_offload_good: 270490391511 rx_csum_offload_errors: 36560575 rx_header_split: 0 alloc_rx_buff_failed: 0 tx_smbus: 0 rx_smbus: 0 dropped_smbus: 0 rx_dma_failed: 0 tx_dma_failed: 0 При этом растут rx_missed_errors: Проц 4 ядра, загружены равномерно на 25-30%, трафика - где-то мегабит 500-800 колеблется. Что бы это могло быть, и как с этим бороться?
  10. Да лично мне-то пофиг, мы что отпускаем пользователей, что принимаем себе совершенно свободно. Но пользователи иногда не сдерживаются и говорят русским матерным на некоторых лиров ;) Потому я и выложил howto'шку что в этом правда, а что нет.
  11. Заметил странную ситуацию. Некоторые LIR'ы не разрешают переводить адреса и автономки своих клиентов к другим LIR'ам, мотивируя это страшными карами и даже отписывая отказ на запрос из RIPE NCC о переводе объектов. А сами выставляют не лучшие условия. Что с этим делать? Краткий ответ: ЗАБИТЬ И ПОДОЖДАТЬ ПОЛТОРА МЕСЯЦА. На провокации не поддаваться. Полный ответ: Если у вас нет договора с LIR'ом - то вы привязаны к тому LIR'у, через который получали сеть. Этот LIR должен не позднее 1 марта (до того дедлайн был 1 января - но его расширили) загрузить скан договора с вами на сайт RIPE NCC - LIR Portal. После окончания Phase II, то есть 1 марта, если договор не загружен - СВЯЗЬ LIR-PI/AS ТЕРЯЕТСЯ, и Вы можете заключать новый договор с ЛЮБЫМ LIR, никого не спрашивая. На это будет дано минимум 3 месяца. Как по-мне, при этих раскладах, без реальных рычагов влияния на клиента, пытаться такими не совсем честными путями запугать и заставить клиента подписать договор - только карму себе пачкать ;)
  12. В чем может быть проблема, что бы удалить из базы inetnum и route ?А через сутки магистралы обновят фильтры и опаньки. Проблема в том, что "магистралы" и "фильтры по райпу" существуют только в одной, и при этом не сильно большой, части Интернета ;)
  13. Ну на самом деле проблема в том, что "отобрать" - не то, чтобы сильно технически возможно, ведь да? :)
  14. RIPE отсрочил введение этапа 3 полиси 2007-01, то есть собственно отбирание ресурсов, на которых нет контрактов: Dear Colleagues, We would like to inform you that the RIPE NCC has extended the deadline for phase two of the 2007-01 policy implementation ("Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region") by two months. LIRs now have until 1 March, 2010 to provide the required documentation Так что гуляем новогодние праздники спокойно! С наступающими!!! ;)
  15. ipv6, практические вопросы

    Будет фигня как с DHCP. Но кстати если DHCP с клиентов умеют фильтровать даже D-Link'и, то про фильтрацию rtadvd я пока ничего не слышал. Ну так о какой готовности к переходу на IPv6 мы говорим? Там до сих пор не решили как nexthop в cpe отдавать, через rd или dhcpv6. Так что лет 5 еще подождем. Так никто и е спорит. Поскольку внедрение планировали техники, а не менеджеры, то и внедряли они чтобы пинги пингались и трасски трейсились. А надо было со стороны РЕСУРСОВ внедрять! Были бы там много бесплатной порнухи в BluRay RIP'ахинтересные ресурсы - юзеры бы сами вынудили провайдеров к поддержке и переходу ;)
  16. Недобросовестные LIR'ы

    Что, правда самого RIPE ? ;-) Бгг =)
  17. Недобросовестные LIR'ы

    А это сильно зависит от того, кто аплинк.Некоторым пофиг, некоторые вот даже в рассылках говорят, что мы из принципа будем роутить такие PI, так как считаем, что взятие денег за PI неправильно.
  18. ipv6, практические вопросы

    Практических бонусов никаких.
  19. ipv6, практические вопросы

    Будет фигня как с DHCP. Но кстати если DHCP с клиентов умеют фильтровать даже D-Link'и, то про фильтрацию rtadvd я пока ничего не слышал. Хм... IPv6, и вдруг broadcast ;) Broadcast в данном случае - это L2, а IPv4/IPv6 - L3.
  20. ipv6, практические вопросы

    Все верно, именно для простой autoconfiguration так и сделано. А если кто попросит больше - отроутим ему /48.
  21. Недобросовестные LIR'ы

    Можно.
  22. ipv6, практические вопросы

    Мы можно сказать внедрили.Повесили rtadvd, нарисовали по /64 на сегмент. Трафик небольшой, но бежит. Почему-то весь - 6to4, и как я понял весь - торренты. Юзеры ничего не заметили ;)
  23. Недобросовестные LIR'ы

    Это если умный клиент, который хотя-бы договор перед подписанием осмысленно читает.А сколько народу "вдруг" обнаружат это дело в самый неподходящий для себя момент? Кстати, а что будет, если клиент таки нарушит этот пункт? На хвост соли насыпят? Или ласково пожурят? ;) Ну все правильно написал. Только забыл "в трехмесячный срок" ;)Или это они просто спамят всем, а не только своим клиентам?
  24. PI+AS: кто не успел - тот опоздал!

    Ну кроме этих хомячков есть более другие, и не менее веселые. Я даже не говорю про родных, румыны тоже отожгли нехило. И как я понял, слились.
  25. PI+AS: кто не успел - тот опоздал!

    Да я ващет не про тебя, а в первую очередь про тех, у кого цены ниже себестоимости ;)Но раз ты так на эту тему отреагировал, то... :D А кредитовать себе могу позволить, чо.