Paxton

Похоже канал на Новосибирск падал.Сейчас вроде вернулся.

Еще как бы не проведено, отделим marketing BS от реальности :)Тем более, что заработают на этом копеечку не "магистралы", а эта.. как ее итить... "побирушка", вот. А магистралы - уже что останется :)

<br />Да работает там все. Перерывы были только в понедельник утром. К 16 часам уже все работало в штатном режиме.<br />Вчера по слухам и магистраль Сибирьтелекома поднялась: вернулись Иркутск, Улан-Удэ и Чита.<br /><br /><br /><br /> Иркутск никуда не уходил, это я вам как злобный качальщик через стк говорю, который живёт в Иркутске рядом с плотиной иркутской. Значит использовались локальные аплинки в Интернет. Магистральные маршрутизаторы были недоступны. Вроде этого - irk-dr1.ncc.sibirtelecom.ru

16 имелось в виду по местному времени.

Да работает там все. Перерывы были только в понедельник утром. К 16 часам уже все работало в штатном режиме.Вчера по слухам и магистраль Сибирьтелекома поднялась: вернулись Иркутск, Улан-Удэ и Чита.

В Абакане интернет есть. По крайней мере от Сибирьтелекома. А вот дальше на восток - связь обрывается :)

Написано - abn-bbar2.ncc.sibirtelecom.ru Значит Абакан, ну или где-то рядом в Хакасии. А оттуда оно может выйти и в Омске, и в Н-ске, и Краноярске, и даже в Иркутске. Как фишка ляжет... Так что переменных несколько больше :)

Очень странное время АВР. С ноля часов в субботу. А пост опубликован за несколько часов до начала аварийно-восстановительных работ... Я чего-то не понимаю... В ЦентрТелекоме рвут кабели по графику? Значительная часть всех АВР - земляные работы и лишь немногие из них - стихия. Никто из нормальных людей ночью в выходной день земляными работами не занимается и уж тем более не предупреждает, что собирается порвать чей-то кабель. Рвут исключительно по незнанию, что в грунте что-то есть или по несоблюдению технологии раскопок или по недосмотру надзирающих за раскопкой связистов. ... Пишут АВР... ха,ха!!! Джей, давно же говорят, к людям надо помягше, а на вопросы смотреть поширше. Вообще говоря, аварии бывают разные, не только в виде обрыва волокна, но и в оборудовании. Причем аварийное оборудование может продолжать функционировать, но лишиться резервирования или портов под расширение. Соответственно, нужно заменить неисправные модули, произвести перекроссировку, возможно перегрузить коробку или заменить софт. Вот такие работы легко могут занять полтора часа.

А какие минусы? Как какие? :) IS-IS=0

А вы попробуйте использовать реальные IP для адресов лупбеков и, соответственно, в BCD для генерации NET. Думаю в данном случае получить дубликаты NET-ов будет проблематично. А адресов много на это не потребуется (ну если только у вас не несколько тысяч маршрутизаторов ;). По ISIS мне в свое время понравилась книжка "The Complete IS-IS Routing Protocol" by Hannes Gredler & Walter Goralski. Хотя она старается быть на пике гребня острия технологии и поэтому местами выглядит устаревшей и/или наивной, ибо написана в 2005 году, но для знакомства с протоколом по-моему пойдет хорошо. Опять же она не заточена под одного конкретного вендора и содержит примеры как для IOS, так и для JUNOS.

Хороша "девочка на телефоне"1. Большой практический опыт работы (в ISP или в системном интеграторе) с оборудованием Cisco (предпочтительно операторского класса 72xx, 76xx, GSR) 2. Глубокие знания протоколов маршрутизации (BGP, IS-IS, OSPF) 3. Глубокие знания технологии MPLS и ее приложений (L3VPN, L2VPN, TE) а также протоколов LDP и RSVP. 4. Опыт работы по аналогичным технологиям с оборудованием Juniper M/T- и Е-серий приветствуется. А крестиком она вышивать и арии петь не должна? Или у вас GSR и Juniper-ы стоят в кейсах третьего приоритета? ну ну.. И не нужно учить жизни, кто такие сервисные инженеры, у самого двое сидят, из 5 (дай Бог) специалистов по одному скандинавскому вендору на всю страну. Сервисный инженер должен многое, а не тупо отвечать на вопросы по телефону. Если требуется, удаленно настроить железку в Якутске в 5 утра по Мск.. Если нужно - выехать к клиенту и решить проблему, тоже его задача. И взгреть вендора и добиться у него нужной прошивки или опции - тоже его. И 4 штуки баксов за эту работу - не такие ужасные деньги для "мелкой" компании nVision. Вы это умеете делать? Скорее всего - нет. Тогда платите. О чем разговор? Вы грудью ложитесь за интересы работодателя? Зря. Не оценит. По-моему, проблема чтения с середины осталась :)По-вашему, значит, вакансия должна звучать следующим образом: "Нужен балбес типа Шарика, остальному научим", так что ли? Мне кажется здесь все же нужен человек несколько другой квалификации, чем те, кем интересуется Sonne :) Я не спорю о суммах, не в курсе последних котировок саппортеров в Москве, просто позиционирование квалификации инженера на данную должность как "ниипацца-гуру-в-сетях" в корне неверна на мой взгляд. Сервисный инженер, кстати, ничего не должен настраивать. Его основная задача устранить неисправность в сети, которая поставлена на поддержку и функциональность которой строго описана в контракте (это естественно в идеальном случае, в жизни все немножко сложнее). ПНР в задачи саппорта вроде ни по какому стандарту не входят. В предельном случае он может работать просто испорченным телефоном между TAC-ом вендора и сетью заказчика. P.S> Кстати, а откуда такой пиетет перед Juniper-ом, что по нему не может быть кейсов третьего приоритета (самого распространенного уровня кейсов)? :)

Т.е. грубо, заплатить высококлассному инженеру на 12х50=600к + 30% налогов в год (т.е. заплатить на ~23к USD в год больше), это не подходит по фин.вопросам. А заваливать проекты (где требуется профессионал) у заказчиков, генерирующих миллионные в у.е. контракты - это вполне квалифицированный менеджмент подход? Шедеврально, что еще добавить. Вы просто куете антирекламу своей любимой лавки. :-) Жадность владельцев и акционеров отдельных росс.интеграторов не знает границ. А потом наивно удивляются, что бизнес то не прет? Почему оборотов нет? Где продажи? Где бы срочно перекредитоваться? И т.п. Кризис - это предсказуемое явление, которое вскрыло все нарывы нашего экономического раздолбайства. Все-таки плохая привычка читать тексты с середины.Запощена вакансия инженера, но инженера ПОДДЕРЖКИ, он же сервисмен, он же суппортер, тот самый, с которым вас соединяет девочка, когда у вас не кажет Стрим-ТВ, а схема пароль-отзыв у девочки не срабатывает. Да должность не девочки на телефоне, да с кучей страшных слов типа карате, джиуджитцу, секондлайнсаппорт, проактивкастомеринтерэкшн и BGP с MPLS-ом. Но какие проекты вы собрались заваливать на этой должности? Кейсы третьего приоритета, генерирующие миллионы у.е.? %) Однако, накатали 4 страницы флуда, с развенчанием мифов и открытием скрижалей тайного знания. Профессионалы, одно слово :)

Эт вы всяким геймерам расскажите :) Которые чуть что, сразу за всякие флудотрейсилки хватаются.

А packet loss разве не показатель "загруженности каналов"? ;) Не приходилось выслушивать любезных информаторов про "у вас тут потери"? Причем, тот факт, что до следующего после "проблемного" хопа долетает все 100% пакетов, почему-то не вызывает у стороннего наблюдателя никаких сомнений в своих выводах Я хотел всего лишь сказать, что пингование транзитного маршрутизатора не может служить достоверной оценкой состояния связи, что с рейтлимитами и фильтрами на lo0, что без. Время отклика на пинги у Джуни вещь, слабо коррелирующая с загрузкой процессора RE. Которому несколько full view совсем не в тягость btw - если памяти хватает Спорить ради спора я не собираюсь. Однако отмечу, что если бы это было так, как вы описываете, то не было бы и возмущенных писем от пользователей сети РТ ;)

Что в общем и целом верно. Особенно если оно вращает несколько full-view BGP. Что RE Джуни вращает внутри себя - значения не имеет. Rate-limit на генерацию icmp в Juniper'е работает на несколько другом уровне. Ни к загрузке routing engine, ни, тем более, к загрузке forwarding engine это не имеет никакого отношения А в общем и целом согласен: выводы из результатов пингов транзитных железок в большей степени зависят от компетентности пингующего, нежели от загрузки каналов ;) Ratelimit пакеты только дропает, а значит повлиять может только на пакетлосс. А загруженный RE дает не столько пакетлосс, сколько джиттер. Из-за чего на показатели пингов нельзя ориентироваться, как на достоверный RTT доступа к ресурсам за маршрутизаторами.

Есть мнение, что к современной сети РТ слово "дизайн" не применимо :) Какие трейсы? У РТ MPLS ядро скрыто. То бишь TTL в IP пакетах на P маршрутизаторах не изменяется. Насколько помню, между УАКами лежат RSVP туннели (full mesh), даже не по одному, а по несколько штук с помощью явного задания strict-loose узлов, через которые должен идти траф конкретного туннеля. Поэтому траф в один и тот же destination может идти разными путями. Ессно на разных участках загрузка каналов разная, поэтому где-то суровые дропы, где-то попроще. Предполагаю, даже в нормальное время с разных source ip к одному и тому же dest ip должен наблюдаться разный RTT - когда траф идет различными путями. Не понял, это что, константация факта того, что управлять трафиком на ИП и МПЛС сетях невозможно?Или иллюстрация конкретной проблемной стройки? Тогда вопрос - а нафига то строили такое глючилово? Это констатация того, что кроме ИП и МПЛС нужно иметь нормальное администрирование и capacity planning. Какой бы ни был инжиниринг трафика, он не поможет передать 25 Гбит/c через 10GE интерфейс :) Что в общем и целом верно. Особенно если оно вращает несколько full-view BGP. Кстати, если у кого проблемы у РТ в ЮФО, то там, говорят, еще и GSR глючит при балансировке - в один канал пакеты отправляет, а в другой - дропает. Так что пусть там дежурная смена сделает clear ip cef. Это, как говорится, ОБС. Аффтар к сети РТ никакого отношения не имеет :)

Поделитесь с теми у кого нет этого железа) У кого нет - ставьте Olive :)http://juniperclue.cluepon.net/index.php/Olive

Какие трейсы? У РТ MPLS ядро скрыто. То бишь TTL в IP пакетах на P маршрутизаторах не изменяется. Насколько помню, между УАКами лежат RSVP туннели (full mesh), даже не по одному, а по несколько штук с помощью явного задания strict-loose узлов, через которые должен идти траф конкретного туннеля. Поэтому траф в один и тот же destination может идти разными путями. Ессно на разных участках загрузка каналов разная, поэтому где-то суровые дропы, где-то попроще. Предполагаю, даже в нормальное время с разных source ip к одному и тому же dest ip должен наблюдаться разный RTT - когда траф идет различными путями.

А люди говорят, что РТ на полку вышли не стыки, а сама магистраль. 10G под завязку. Если не везде, то по некоторым направлениям точно. Так что даже если где есть линки на полке, то их расширять нет смысла, ибо больше через них все равно не прокачать.

Видели мы его. Поставить по границе сети тазики с вендами и всё воткнуть через них. И аплинков и клиентов. Спасибо, я лучше Arbor пощупаю, там хоть вменяемая технология ;)Потеряю, конечно, на точности анализа, ну и ничего страшного, зато управляемость уже построенного не пострадает. Бюджет у проектов, кстати, одинаковый - называется "а сколько у вас в бюджете на это запланировано?" ;) Кстати, а у Arbor часть продуктов (например, TMS) построена на платформах Bivio (железо + Linux c открытым API). JFYI.

Велика значит сеть :) А по сабжу - IS-IS :)

В качестве маленького довеска к новостям выпуска. Похоже сиськовский релиз о тестировании 100GE в Comcast'e оказался если не полным фуфлом, то субстанцией с заметным его (фуфла) содержанием. На самом деле тестировалась DWDM платформа, способная передавать 100G на одной лямбде (сообщество почти уверено, что это Stratalight). На лайтридинге предположили, что для этого использовали плату с 10 10G интерфейсами (что-то вроде престандарта на 100GE Ethernet, который приспособлен для передачи его по 10 парам волокон) и подключили ее этими интерфейсами к CRS-у. А закончилась эта история тем, что даже Stratalight назвала этот пресс-релиз Cisco не иначе как "irrational sex appeal" :) P.S> Наверное возникает вопрос зачем нужно было так дешево позориться? Кое-кто полагает, что этот PR ход был сделан, чтобы заглушить релиз Juniper'а о заключенном контракте на поставку T1600/MX960 в исконно сисковский аккаунт, коим Comcast являлся испокон веков. P.P.S> Почитать можно, например, здесь http://www.lightreading.com/blog.asp?blog_...p;doc_id=157716

Невозможно новую технологию сразу сделать дешевой. Особенно если это не потребительская технология, а операторская. И тот путь, который Ethernet прошел за 35 лет, превратившись в потребительскую технологию, а потом ( уже имея десятки миллионов устройств в активе ) в операторскую, придется проходить каждой новой технологии. А для этого она должна иметь неоспоримые преимущества для массового потребителя, которых у MPLS нет. Массовому потребителю MPLS нафик не нужен и вряд ли в обозримом будущем он потребуется. Технология нужна оператору, потому как в развитии MetroEthernet сетей наметился определенный тупик. И разработка ведется не с нуля, а на базе существующих - в первую очередь банально отсекая лишнее, так что не вижу в этом ничего невозможного. Не исключено, впрочем, что ничего и не получится, как с было со многими "promising" технологиями.

Дружище, я смотрю вас тут разбивают в пух и прах. Даже обвинили в изобретении велосипеда. Но не падайте духом! Многие сильно удивятся, что примерно на ту же тему, что и Ваши умственные упражнения, сейчас ведут разработки не самые последние компании и организации в мире. Задача в пределе проста - срастить Ethernet (цена) и MPLS (операторские фичи). Но не просто срастить, а избавится от детских проблем, которые выплывают в операторских сетях: для Ethernet - это MAC-learning, Spanning Tree и прочая лабуда, для MPLS - сложность оборудования, реализующего все фичи, что выливается в недетскую цену оборудования доступа. Вобщем советую копать в сторону проектов Nortel PBT/PBB (provider backbone transport/provider backbone bridging или что-то вроде того) и IEEE 802.1ah. Коробки, которые коммутируют без MAC learning'a уже есть - например, ADVA FSP150. P.S> Самое важное, как мне кажется, что такие вопросы кого-то еще волнуют. А то на меня пустые корридоры и лаборатории ИППИ (Институт проблем передачи информации, если кто не знает) в свое время произвели удручающее впечатление. Главное - меньше слушайте знатоков. Страна Советов канула в Лету, но советов осталось еще не на одну страну :)

Дарю:http://www.cisco.com/pcgi-bin/apps/search/...en&filter=p Дальше можно поскакать по линкам внутри. Чувствуется масштабность деплоймента, да и с резервированием тоже похоже все ОК. Как возникнет потребность - расскажите. Я слежу за судьбой этой фичи :) P.S> Вообще, мне кажется, мы с вами несколько отклонились от темы. Если есть желание продолжать, пожалуйста, в приват.