mt6561
Активный участник-
Публикации
262 -
Зарегистрирован
-
Посещение
Все публикации пользователя mt6561
-
Получение AS и блока ip адресов
тему ответил в Sergo1 пользователя mt6561 в Работа с бумагами
8-() КТО? И самое главное - зачем? -
Господа конкуренты, признавайтесь! Кто и зачем втирает клиентам, что RIPE больше не выдает /24? ;)
-
Ага. И плюс еще накладные расходы. И плюс еще НДС. И плюс риски неоплаты. У нас получается себестомость 80-85 евро за объект, никак не меньше. Вобщем, видимо живут они ровно год до первого счета ;)
-
Это нормально. Это один из мантейнеров самого RIPE. Он не закрывает объекты паролем, но информирует RIPE при любом изменении объекта. На этом мантейнере висят те as-ки и pi-ки, на которые есть договор поддержки с точки зрения райпа. Вот если его НЕТ там - то повод задуматься.
-
Поддержал, а чо! :)
-
Intel e1000e - потери
тему ответил в mt6561 пользователя mt6561 в Программное обеспечение, биллинг и *unix системы
В свитч подключен, там транспорт гигабитный, еще один свитч и еще один комп-роутер аналогичный. -
Intel e1000e - потери
тему ответил в mt6561 пользователя mt6561 в Программное обеспечение, биллинг и *unix системы
Вот по англицки написано: нет буфферов. ethtool -g смотреть, ethtool -G ставить. разные бывают буфера.для начала посмотрите что за чип - lspci -v e1000 - это целое семейство. Встречаются в нем откровенно неудачные поделки igb, конечно, заметно резвей, но, к сожалению, драйвера для этого чипа на данный не являются шедевром стабильности -G стоит максимальное (4096). а сама карта - Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) -
Есть грабля на нагруженной сетевухе 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 колеблется. Что бы это могло быть, и как с этим бороться?
-
Да лично мне-то пофиг, мы что отпускаем пользователей, что принимаем себе совершенно свободно. Но пользователи иногда не сдерживаются и говорят русским матерным на некоторых лиров ;) Потому я и выложил howto'шку что в этом правда, а что нет.
-
Заметил странную ситуацию. Некоторые LIR'ы не разрешают переводить адреса и автономки своих клиентов к другим LIR'ам, мотивируя это страшными карами и даже отписывая отказ на запрос из RIPE NCC о переводе объектов. А сами выставляют не лучшие условия. Что с этим делать? Краткий ответ: ЗАБИТЬ И ПОДОЖДАТЬ ПОЛТОРА МЕСЯЦА. На провокации не поддаваться. Полный ответ: Если у вас нет договора с LIR'ом - то вы привязаны к тому LIR'у, через который получали сеть. Этот LIR должен не позднее 1 марта (до того дедлайн был 1 января - но его расширили) загрузить скан договора с вами на сайт RIPE NCC - LIR Portal. После окончания Phase II, то есть 1 марта, если договор не загружен - СВЯЗЬ LIR-PI/AS ТЕРЯЕТСЯ, и Вы можете заключать новый договор с ЛЮБЫМ LIR, никого не спрашивая. На это будет дано минимум 3 месяца. Как по-мне, при этих раскладах, без реальных рычагов влияния на клиента, пытаться такими не совсем честными путями запугать и заставить клиента подписать договор - только карму себе пачкать ;)
-
В чем может быть проблема, что бы удалить из базы inetnum и route ?А через сутки магистралы обновят фильтры и опаньки. Проблема в том, что "магистралы" и "фильтры по райпу" существуют только в одной, и при этом не сильно большой, части Интернета ;)
-
Ну на самом деле проблема в том, что "отобрать" - не то, чтобы сильно технически возможно, ведь да? :)
-
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 Так что гуляем новогодние праздники спокойно! С наступающими!!! ;)
-
ipv6, практические вопросы
тему ответил в nuclearcat пользователя mt6561 в У нага
Будет фигня как с DHCP. Но кстати если DHCP с клиентов умеют фильтровать даже D-Link'и, то про фильтрацию rtadvd я пока ничего не слышал. Ну так о какой готовности к переходу на IPv6 мы говорим? Там до сих пор не решили как nexthop в cpe отдавать, через rd или dhcpv6. Так что лет 5 еще подождем. Так никто и е спорит. Поскольку внедрение планировали техники, а не менеджеры, то и внедряли они чтобы пинги пингались и трасски трейсились. А надо было со стороны РЕСУРСОВ внедрять! Были бы там много бесплатной порнухи в BluRay RIP'ахинтересные ресурсы - юзеры бы сами вынудили провайдеров к поддержке и переходу ;) -
Что, правда самого RIPE ? ;-) Бгг =)
-
А это сильно зависит от того, кто аплинк.Некоторым пофиг, некоторые вот даже в рассылках говорят, что мы из принципа будем роутить такие PI, так как считаем, что взятие денег за PI неправильно.
-
ipv6, практические вопросы
тему ответил в nuclearcat пользователя mt6561 в У нага
Практических бонусов никаких. -
ipv6, практические вопросы
тему ответил в nuclearcat пользователя mt6561 в У нага
Будет фигня как с DHCP. Но кстати если DHCP с клиентов умеют фильтровать даже D-Link'и, то про фильтрацию rtadvd я пока ничего не слышал. Хм... IPv6, и вдруг broadcast ;) Broadcast в данном случае - это L2, а IPv4/IPv6 - L3. -
ipv6, практические вопросы
тему ответил в nuclearcat пользователя mt6561 в У нага
Все верно, именно для простой autoconfiguration так и сделано. А если кто попросит больше - отроутим ему /48. -
ipv6, практические вопросы
тему ответил в nuclearcat пользователя mt6561 в У нага
Мы можно сказать внедрили.Повесили rtadvd, нарисовали по /64 на сегмент. Трафик небольшой, но бежит. Почему-то весь - 6to4, и как я понял весь - торренты. Юзеры ничего не заметили ;) -
Это если умный клиент, который хотя-бы договор перед подписанием осмысленно читает.А сколько народу "вдруг" обнаружат это дело в самый неподходящий для себя момент? Кстати, а что будет, если клиент таки нарушит этот пункт? На хвост соли насыпят? Или ласково пожурят? ;) Ну все правильно написал. Только забыл "в трехмесячный срок" ;)Или это они просто спамят всем, а не только своим клиентам?
-
Ну кроме этих хомячков есть более другие, и не менее веселые. Я даже не говорю про родных, румыны тоже отожгли нехило. И как я понял, слились.
-
Да я ващет не про тебя, а в первую очередь про тех, у кого цены ниже себестоимости ;)Но раз ты так на эту тему отреагировал, то... :D А кредитовать себе могу позволить, чо.