- UANOG - uanog.one

Выбор FS для maildir storage
by Sergey A. Gribchenko 17 Mar '07

17 Mar '07

Привет! Посоветуйте оптимальную FS, для хранения большого колличества почты, в maildir-ах Объем хранилища от 200 гб Самолично проведены тесты с ufs2, jfs, reiserfs. Каждая из систем имеет как плюсы так и минусы. Хотелось бы услышать в сторону чего еще стоит посмотреть. Выводы которые сделаны сейчас: ufs2 очень надежна, ни одного сбоя за год, но медленная на большом колличестве файлов. jfs сразу отпадала в реад онли на тестах при создании в 10 потоков нескольких сотен тысяс файлов. reiserfs работает, вполне быстро, но в неопределенные моменты времени рассыпается с ошибками вида ReiserFS: warning: green-16003: Invalid item type observed, run fsck ASAP process `named' is using obsolete setsockopt SO_BSDCOMPAT ReiserFS: warning: is_tree_node: node level 21864 does not match to the expected one 1 ReiserFS: sdc1: warning: vs-5150: search_by_key: invalid format found in block 59790138. Fsck? ReiserFS: warning: is_tree_node: node level 21864 does not match to the expected one 1 ReiserFS: sdc1: warning: vs-5150: search_by_key: invalid format found in block 59790138. Fsck? Возможно это вина кривых рук, но делали все что могли. -- GSA-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo(a)uanog.kiev.ua with "unsubscribe uanog" in the body of the message

8 9

Cisco interfaces errors
by antoha＠antohabest.com 16 Mar '07

16 Mar '07

Здравствуйте многоувожаемый uanog. В конторе поставили такую задачу: Есть порядка 70 свичей( в основном каталисты), которые обслуживают большое колличество серверов. Вот во всей этой системе иногда попадаються некачественные сетевые кабели. Ситуация такова, что периодически раз в месяц на одном из интерфейсов свича начинает глючить коннект. Это происхдит или в следствии того что например какой-то из энжинеров случайно зацепил какой-то кабель или в случае низкого качества самого кабеля. Скажите есть ли вариант снимать например по SNMP параметр "input errors" с интерфейса на свиче и в случае достижения им какого-то критического значения уже отправляь через nagios или SiteScope алерт. Или может лучше будет написать какой-нибудь скрипт на перле, который бы заходил на свичь раз в 10 минут и делал например: sh interfaces и выхватывал оттуда значение " input errors". Ковырял гугл и доки на cisco.com ничего путевого не нашел. Может кто-нибудь сталкивался с этой проблемой или есть какое-нибудь готовое решение этой задачи. Заранее спасибо. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo(a)uanog.kiev.ua with "unsubscribe uanog" in the body of the message

2 1

USB to COM адаптер
by Artem Grishin 15 Mar '07

15 Mar '07

Здравствуйте, uanog. Народ, подскажите, есть ли где в Украине сабжевые зверьки? Ситуация - ноутбук, много УСБ, 0 КОМ портов. А железки с ком-портами иногда приходится конфигурить, и очень важно иметь хотя бы один КОМ порт. Не важно, веришь ли ты в бога, важно верит ли он в тебя... -- SUI-UANIC GAS-RIPE ______________________________________________ --== ISP Zaporozhye On Line ==-- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo(a)uanog.kiev.ua with "unsubscribe uanog" in the body of the message

9 12

Очередной забег по GPRS - Hyper.net
by Paul Arakelyan 13 Mar '07

13 Mar '07

Решил я включить себе єто чудо рекламного прогресса - hyper.net от ЮМС (календарные сутки GPRS за 5грн, трафик не считается) Ну, включил и решил поиграться с ним. Не ожидал, что всё будет "так хорошо", что это дешевле и круче лайфовского гига-интернета(с точки зрения что-либо скачать), похоже. И так, железо и софт: Siemens A65 - GPRS class 8 modem, USB charger data cable (uplcom) Siemens Me45 - GPRS class 10, RS-232 cable. Notebook w/FreeBSD-6.2 (PII-75..400MHz), ppp+openvpn Домашний десктоп, тыкнутый в ноут. Первые грабли: 57600 на порту на USB забивали ноут прерываниями по-чёрному. 115200 - стало легче, 230400 - ваще хорошо. скорость - 9KB/s download. Даже скайпом можно позвонить :), но как-то class 8 device - не совсем подходит для того, чтоб вас услышали. Вторые грабли: телефон ГРЕЕТСЯ. Это действительно стало неожиданностью. От нагрева аккумулятор или отключается, или перестаёт заряжаться, садится и отключается. 4-5 часов непрерывного посыпания пакетами в ppp-линке и телефон (А65) сдыхает. Me-45 с древней-оригиальной батареей (1,5 часа разговора) сдох через пол-часа - тоже явно нагревшись. Скорость у ME-45 также была ~9KB/s, либо если его шнурок воткнуть в USB->rs-232 шнурок (такой же device uplcom) - то 7КБ/с. Скайпом не баловался. Грабли решились случайно - на столе случайно лежала алюминиевая коробка - вот положив на неё телефон и удалось добиться достаточного отвода тепла. Вобщем - в сочетании с openvpn и сервером, к которому можно им подключиться - получилось вполне жизнеспособное решение, способное перенести всякие рассоединения и переключения телефонов "на ходу". -- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo(a)uanog.kiev.ua with "unsubscribe uanog" in the body of the message

2 1

Ответ Стесину
by Max Tulyev 13 Mar '07

13 Mar '07

[Форваржу без исправлений. -- Netch] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hi All! Естественно, всегда приятно обосрать человека там, где он не может ответить, да? Так вот андрюшенька, ответить на этот раз ПРИДЕТСЯ. Теперь по сути: все то, что написал этот отморозок, есть лишь плод его белой горячки. Бросай пить, пока жив еще! А хотя нет, лучше не надо. Сервис проброса VPN Ukrtelecom-UAIX родился от недогруженного канала в Укртелеком, просто как некая фишка для друзей. НИКОГДА на нем не зарабатывались деньги и это и даже не планировалось. Потом сервис стал популярен и у других пользователей, небольшой канал быстро забился. Таки да, клиенты ОГО хотят играть в игры со своими знакомыми, качать фильмы и т.д. В Укртелекоме аналогичных сервисов нет и похоже не будет. А большинство домашних пользователей вообще сидят в домосетках, которые почти все в IX'ах. Я написал письмо Елене Катковой с просьбой хотя-бы расшейпить канал на исход. НИКАКИХ ДЕНЕГ С УКРТЕЛЕКОМА НИКОГДА Я НЕ ПРОСИЛ. Это просто наглая ложь. Я не говорил о мировом коннективити, даже о входящем трафике. Просто просил расшейпить ИСХОД, таким образом совершенно бесплатно улучшить жизнь укртелекомовским же клиентам! Мое письмо было проигнорировано (хм, кто бы сомневался! Ведь для Укртелекома пользователи ОГО - всего лишь "эта свора имбецилов"). Возможно я таки поступил неправильно, но нескольким людям я дал email Катковой, чтобы они как КЛИЕНТЫ УКРТЕЛЕКОМА высказали свои ПОЖЕЛАНИЯ своему провайдеру, причем именно куратору услуги ОГО. Я не ожидал, что писем будет много. Но это значит только то, что ВАШИ КЛИЕНТЫ ХОТЯТ ТАКОГО СЕРВИСА! Их МНОГО! К их мнению можно прислушиваться, можно игнорировать, а можно обзывать их "сворой имбецилов", чего-то там хотящих. Жрите, что дают, и не выеживайтесь! As you wish! Только пусть уж результат тогда не удивляет... P.S. Ждите на новостниках заголовков вида "Сотрудники Укртелекома называют в конференциях своих клиентов "сворой имбецилов". Я уж постараюсь, приложу весь свой писательский талант ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO) =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo(a)uanog.kiev.ua with "unsubscribe uanog" in the body of the message

15 49

RE: [uanog] Re: Re: [uanog] Ответ Стесину
by Hrynchuk Oleh 13 Mar '07

13 Mar '07

Пішли б краще пиво пити... з кавою та коньяком. Або просто коньяк. Чи каву. 13 число все ж :). > -----Original Message----- > From: owner-uanog-outgoing(a)uanog.kiev.ua > [mailto:owner-uanog-outgoing@uanog.kiev.ua] On Behalf Of Andrew Stesin > Sent: Tuesday, March 13, 2007 5:53 PM > To: Vladimir Litovka > Cc: Alexandr Kovalenko; uanog(a)uanog.kiev.ua > Subject: Re: [uanog] Re: Re: [uanog] Ответ Стесину > > 2007/3/9, Vladimir Litovka <doka.ua(a)gmail.com>: > > > P.P.S. Дискуссия явно давно переросла в переливание из пустого в > > > порожнее... :( > > > > Ну это было понятно еще пару дней назад :) > > Время покажет, каким будет результат. > > > Когда в ход пошли > > Абстрактные Провайдеры и Неочевидные Попугаи, чтобы увести > разговор с > > совсем неудобного русла. > > Причем тут "неудобное русло"? Ладно, при встрече расскажу. > > =================================================================== > uanog mailing list. > To Unsubscribe: send mail to majordomo(a)uanog.kiev.ua with > "unsubscribe uanog" in the body of the message > =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo(a)uanog.kiev.ua with "unsubscribe uanog" in the body of the message

1 0

Job @ Ericsson
by Oleksandr Pantus 13 Mar '07

13 Mar '07

Hi ! Может кого интересует. http://www.ericsson.com/ua/ericsson/hr/jobs.shtml -- S/Y, Oleksandr

1 0

UMC
by Gregory Edigarov 12 Mar '07

12 Mar '07

Здравствуйте, А есть здесь кто-нибудь из UMC? Отзовитесь пожалуйста off-list. Заранее спасибо. -- With best regards, Gregory Edigarov =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo(a)uanog.kiev.ua with "unsubscribe uanog" in the body of the message

1 0

UMC
by Gregory Edigarov 12 Mar '07

12 Mar '07

Здравствуйте, А есть здесь кто-нибудь из UMC? Отзовитесь пожалуйста off-list. Заранее спасибо. -- With best regards, Gregory Edigarov =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo(a)uanog.kiev.ua with "unsubscribe uanog" in the body of the message

1 0

Fw: Protocol Action: 'BGP Support for Four-octet AS Number Space' to Proposed Standard
by Katie Petrusha 12 Mar '07

12 Mar '07

Привет, Какое-то движение появилось :) -------- Original Message -------- Begin forwarded message: Date: Fri, 09 Mar 2007 16:34:36 -0500 From: The IESG <iesg-secretary(a)ietf.org> To: IETF-Announce <ietf-announce(a)ietf.org> Cc: idr mailing list <idr(a)ietf.org>, idr chair <idr-chairs(a)tools.ietf.org>, Internet Architecture Board <iab(a)iab.org>, RFC Editor <rfc-editor(a)rfc-editor.org> Subject: Protocol Action: 'BGP Support for Four-octet AS Number Space' to Proposed Standard The IESG has approved the following document: - 'BGP Support for Four-octet AS Number Space ' <draft-ietf-idr-as4bytes-13.txt> as a Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Bill Fenner and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-13.txt Technical Summary Currently the Autonomous System number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. Based on historical and current allocation rates, the range available to two-octet AS numbers is expected to run out in 2010. Working Group Summary This is a long-standing work item for the working group, with the first draft being published in February 2001. The approach described in the draft to support 4 Byte AS numbers is one of no change to BGP in terms of protocol in all but one aspect: The OPEN message uses a 4-Byte capability advertisement and the use of a 2 Byte MyAS field value. In all other respects there is no change to the protocol elements of BGP, other than using 4 bytes where ASs are used. The other substantive topic of the draft is in the interoperation of 4-Byte AS speakers with 2-Byte AS speakers. The OPEN message with capability advertisement has attracted one comment that this is contrary to RFC3392, however a detailed analysis of this comment has not lead to substantiation of this comment. Using this as a dynamic capability rather than an OPEN capability was raised as a comment, with the response that there is no reason to make the capability dynamic in this case. The tunnelling technique of using an opaque transitive community attribute to carry the 4-Byte AS Path attracted some comment. The comment was concerned with the reconstruction of the 4-Byte AS path across a 2-to-4 byte BGP boundary, where the algorithm for the reconstruction was, in some comments, not sufficiently well-defined. However it is also the case that the critical elements of the role of the AS Path are adequately described in the draft. The AS path length is used as a metric in the BGP path selection process, and the AS path itself is used for loop prevention. The draft specifies that the reconstruction of the AS path across a 2-byte to 4-byte AS transition should preserve the AS path length. The draft does not cover every possible eventuality of reconstruction of the 4-byte AS path, but a closer examination of the loop detection issue reveals that loops that may occur across a mixed 2 Byte / 4 Byte path are detectable within one iteration of the loop within the 2-Byte component of the mixed loop path in all circumstances. Accordingly, both the use of the AS path length as a path metric and the use of the AS path as a loop detection mechanism are preserved in this approach, even though the draft is not definitive in describing the AS path reassembly algorithm in every possible eventuality. In other words the draft contains the necessary and sufficient minimum set of properties for AS path reconstruction, leaving the precise algorithm up to the implementation. This approach is not seen as impairing the functionality, interoperability or integrity of BGP, either within the context of the individual peering session or in the context of the broader IDR framework. A comment was raised that on-the-wire inspection of BGP updates would not know in all cases whether they were seeing 2-byte or 4-byte AS BGP updates. The BGP update contains no additional control flags, and unless the on-the-wire device collects the initial OPEN message with the capability negotiation then the information as to 2-byte or 4-byte AS updates is not explicit. It has been noted that heuristics could be readily applied here, and the presence of the reserved 2-byte AS value 0 in the AS path is one indicator that the momitor is applying a 2-byte interpretation to a 4-byte BGP update. There were no other approaches referenced in the working group during Last Call, and the choice of this draft as representing one that is backwards compatible with existing BGP appears to have been an obvious obvious choice to the working group. The IETF Last call comments concernd the RFC3392 Capability Advertisement examination of these comments indicates that the concerns relating to RFC3392 are unwarranted, and the treatment of the capability advertisement is consistent with a conventional use of RFC3392 and is compatible with older versions of BGP. The IETF Last Call comments touched upon the larger size of BGP updates, and the desireability of using a compressed representation of AS Path. The Working Group did not see any need to include a compressed representation of AS paths in BGP updates. It appears that the onus of making a case that some form of compressed encoding of these BGP fields is of merit lies with the proponents of this as a potential source of problem, and the solution with respect to the AS_PATH representation lies in RFC3392 with additional capabilities being negotiated, either at session OPEN time or possibly dynamically. Thus, this 4-byte spec, that does not used compressed representation of AS_PATH is adequate, and those who believe that more compact representations are called for have a clear path of proposing such a specification to the IDR working group as a negotiated capability. The task for those who are of the opinion that such compact encodings are important to show why and propose a capability to be negotiated to do so in both the 4Byte and 2Byte worlds in the IDR Working Group. Protocol Quality Bill Fenner and Geoff Huston reviewed the document for the IESG. There are implementations; see the implementation report at http://www.ietf.org/IESG/Implementations/bgp4_impleme.txt _______________________________________________ IETF-Announce mailing list IETF-Announce(a)ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --Steve Bellovin, http://www.cs.columbia.edu/~smb ----- End forwarded message ----- -- Katie Petrusha =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo(a)uanog.kiev.ua with "unsubscribe uanog" in the body of the message

1 0