• MPLS повсюду. Как устроена сетевая инфраструктура Яндекс.Облака
    0
    По-английски бы еще то же самое )
  • Rutracker блокируется в транзитном трафике для иностранных пользователей
    0
    Скорее всего слепой дроп, про который вы пишете, — это как раз блокировка магистральным оператором, а не вашим провайдером, про которую я писал выше. Это началось как раз после визита Медведева во ВГИК. Потом 25-го DDoS Guard развернул трафик рутрекера, и началась вот эта истоиря, про которую пишут в ОП.

    Если у вас из Питера (без VPN и надстроек) вдруг наблюдаются симптомы, отличные от ожидаемых, типа стандартной плашки о блокировке вашего провайдера (либо слепые дропы, либо, наоборот, все рабоает), то покажите traceroute, а лучше tcptraceroute на 80-й порт: любопытно.
  • Rutracker блокируется в транзитном трафике для иностранных пользователей
    +1
    Отвлекаясь от вопроса, насколько массовой является практика приземления в РФ магистрального конца туннелей для обхода блокировки (признаться, есть сомнения, но вам виднее), очень похоже на то что фильтрация магистрального трафика теперь будет стандартной практикой. Сорока (и не одна) на хвосте принесла, что после истории с Медведевым РКН этого добивается от транзитных операторов.

    Проявления этого факта заметны не только на примере ТТК, у которого к тому же и международный транзит попал под блокировку, что противоречит, собственно, персловутому закону о блокировках, из-за чего и поднялся этот хай.

    Примерно за неделю до этой истории (сразу после казуса с премьем-министром) появились сообщения о слепых дропах (без показа запретительной плашки) из разных концов российского интернета. Я ковырял один из таких случае — там видно, что фильтрация происходит посредством DPI по хосту в HTTP-запросе. То есть tcptraceroute ходит, пинг, телнет на 80-й порт — все ОК, а в браузере — не открывается. Из тех мест, где блокировки на доступе нету, и должно бы открываться. Народ даже активно предполагал, что это сам рутрекер блокирует «чистый» российский трафик, чтоб всяким премьер-министрам неповадно было.

    Дополнительный анализ показал, что такие симптомы наблюдаются у тех, у кого трафик за пределы РФ идет через российский Ретн. Причем у тех, у кого, трафик покидал РФ через ТТК, оно на тот момент как раз еще работало.

    Так что надо готовиться к тому, что блокировка (причем слепая, без плашек) в России на магистрале будет (или уже стала) повсеместной нормой.
  • Rutracker блокируется в транзитном трафике для иностранных пользователей
    +2
    гонять трафик на очистку куда нибудь в Нидерланды или США означало бы двойные а то и тройные задержки для пользователей в плане скорости

    Очень сомнительный аргумент. Из России трафик по пути на Рутрекер вообще-то и так ходит куда-нибудь в Нидерланды или США, потому что его туда тянут средства обхода блокировки. И вот как раз тащить его обратно в Россию не очень логично в том числе и с точки зрения задержек.
  • Rutracker блокируется в транзитном трафике для иностранных пользователей
    0
    гонять трафик на очистку куда нибудь в Нидерланды или США означало бы двойные а то и тройные задержки для пользователей в плане скорости

    Очень сомнительный аргумент. Из России трафик по пути на Рутрекер вообще-то и так ходит куда-нибудь в Нидерланды или США, потому что его туда тянут средства обхода блокировки. И вот как раз тащить его обратно в Россию не очень логично в том числе и с точки зрения задержек.
  • Rutracker блокируется в транзитном трафике для иностранных пользователей
    0
    Это тот случай, когда традиционные средства обхода блокировки (FreeGate, VPN) не могли гарантированно помочь, потому что трафик из точки выхода вне России на пути в Рутрекер (который тоже вне России) возвращался уже в чистом виде в Россию, и там фильтровался некоторыми операторами. Поэтому во фригейте, например, работали далеко не все прокси (но некоторые, например эстонский, работали, да).
  • О блокировании мобильного приложения Yota со стороны МТС
    0
    Чуваки, а ваш уэб-сервачок часом не ждет этот HTTP GET от конкретного адреса? Типа, с которого клиент до этого через другую TCP-сессию авторизовался где-нибудь у вас? А то у опсосов частенько бывает, что нат по недогляду транслирует разные сессии абонента в разные адреса внешнего пула, и может выйти, что одна сессия к вам с одного айпишничка приходит, другая — с другого. И либо МТС включил залипание адреса по-тихому (так бывает ;), или ваши разрабы что-нибудь вроде привязки юзера не к IP, а кукам запилили (что правильно, потому что такой нат к сожалению случается иногда)?
  • Фулвью ор нот фулвью: о пользе и вреде полной BGP-таблицы
    0
    Упс. Сорвалось.

    > Это не то же самое, что уверенность в том, что если вы (при наличии префикса)

    Это не то же самое, что уверенность в том, что если вы (при наличии префикса A) пошлете трафик назначению A, то он до него дойдет.
  • Фулвью ор нот фулвью: о пользе и вреде полной BGP-таблицы
    0
    Если вспомнить, что роутинг и ричабилти — не одно и тоже, то будет чуть понятнее. Да, отказ от кастом-префиксов — это определенная плата. И вся речь лишь о том, в чем эта плата состоит и за что она.

    Если вы не держите полной таблицы — вы не знаете, ходит ли префикс от назначения A к вашему провайдеру по BGP. Это не то же самое, что уверенность в том, что если вы (при наличии префикса)

    Если префикса нет, значит связности (ричабилити) нету. Но. Если префикс есть — это вообще ни о чем не говорит. В боевых ситуациях бывает сколько угодно примеров, когда префикс есть, а трафик не ходит. Потому где-то у ISP линк перегружен например, или потому что у него в сети флэппинг или какая-нибудь еще нестабильность, от которой наличие FullView на вашей стороне никак не страхует.

    Что касается же FullView, то любой мало-мальски вменяемый ISP имеет несколько внешних линков. И ситуация, при которой у него нету связности с какими-то префиксами, и он не даст вам полной таблицы — экстраординарная. Если она происходит — это повод задуматься о смене ISP в любом случае.

    Теперь про то, за что это (отказ от FV) плата. Ну, собственно, вся статья про это. Вы существенно экономите (деньги) на оборудовании.

    То есть, еще раз. Тип отказов, от которых вас страхует полная таблица на вашей стороне — не единственный и не самый страшный. По хорошему задача инженера в том, чтобы четко понимать, от каких типов отказов страхует его FullView, что она дает чего нет, и уметь доносить это до бизнеса. А решать, выкладывать ли за страховку от такого-то типа раска приличную сумму — вопрос не технический, а про бизнес.

    Примерно в 90% случаях, когда я работаю таким консультантом для случая корпоративной сети, моя рекомендация — потратить эти деньги на что-нибудь более полезное.

    Мы в каментах тут про все это много раз поговорили со всех сторон. Вот например дельная веточка:
    habrahabr.ru/post/113906/?reply_to=7045634#comment_3703216

    >чем-то вроде Dynamic DNS и при падении ISP менять IP-адреса внешних ресурсов.

    Для интерактивных приложений типа web — нет. А для неинтерактивных (типа SMTP) реализация как правило поддерживает возможность резервирования средствами протокола (если недоступен один MX, идем на другой). В сущности, да, корпоративной сети AS и PI-блок нужна в первую очередь для обеспечения отказоустойчивости web-сервисов. Все остальное по большому счету сегодня можно сделать не парясь этим.

    Для связности интернета, транзитных AS и т. д. — там да, там полные таблицы во все стороны нужны.
  • Еще раз про IP-адреса, маски подсетей и вообще
    0
    Конечно, если человек в работе использует продукцию компании X, то ему придется изучить концепцию, которые компания X использует в своих продуктах. Если это хвосты классовой адресации — значит надо знать про хвосты классовой адресации, если свитки Торы — надо знать про свитки Торы, принцип запрета Паули — придется и его освоить. При этом осознавая, что компания Y может на все это наплевать и пользоваться противоположными принципами.

    Еще, например, цискины экзамены полны вопросов про EIGRP и FrameRelay. Да и слава тебе господи, пусть люди, которые сдают те экзамены, с этим и возятся, причем тут я и моя статья? Ведь ниоткуда не следует, что она предназначена для людей, которые собираются стать специалистами по продуктам Cisco.

    Вообще, я выше в каментах где-то писал, что если кто-то воспринимает мои посты в бложике как единственный источник знаний о профессии, то ему лучше бы сразу поискать себе работу в другой области. Я даже не считаю нужным делать дисклеймер на этот счет, потому что нормальным людям и так очевидно, что это не руководство по подготовке к CCIE и даже — к JNCIA.

    >Почему для подсетей всегда рисуется нечто, что очень напоминает классовую сеть? А ведь 21
    >век на дворе!!!

    Основная причина — бабло. Никакая циска ни в каком веке не станет просто так выкидывать на ветер миллионы ради исправления проблемы, которая проблемой не является (плевать на самом деле, как именно отсортированы маршруты в выводе, лишь бы можно было найти нужный не слишком напрягаясь). Всем понятно, что у нее в выводе написано — понятно. Принципы странные? — да и хрен бы с ними. Маркетологи говорят, что если поменять, то продажи возрастут на на миллиард? — не говорят. Есть опасения, что если это поменять, то у людей сломаются говноскрипты и много всякой другой херни, из-за чего начнется вой, нагрузка на TAC и недовольство ключевых заказчиков? — есть. Значит оставляем все как есть.

    Логика структуры вывода цискиного show ip route — это повод для анекдотов уже лет десять как. Ее большинство инженеров внутри самой Cisco не понимают, и ничего — живут как-то. Вообще, ахинея такого вот рода

         82.0.0.0/32 is subnetted, 1 subnets
    S        82.94.230.130 [1/0] via 129.143.103.77

    это лучшая иллюстрация тезиса, что про классы адресов давно пора бы забыть.

    P. S. По существу — вы второй коммент подряд порете херню, извините. То подкрепляете доводы цитатой, в которой написано прямо обратное, то вывод всей таблицы маршрутизации на экран называете наиважнейшиим навыком. Причем делаете это в довольно-таки хамском и чересчур надменном, простите, тоне.

    Если вы хотите сообщить мне, что вы не последний человек в профессии — дык я вам и так верю, можно так не напрягаться. А вот выступать потребителем вашего самовыражения — извините, скучновато.
  • Еще раз про IP-адреса, маски подсетей и вообще
    0
    Я ничего из ваших рассуждений про определение CIDR-блока не понял. И совершенно не чувствую, чтоб мне это как-то мешало жить :) Приведите точную цитату, может.

    Про RIPng тоже был разговор в каментах к этому топику:
    habrahabr.ru/post/129664/?reply_to=6951594#comment_4311694
    Стр. 14 доклада по моей ссылке там. Доклад этот Стинберген делал на NANOG49, 2009 год. На дату RFC2080 сами поглядите.

    Цитата про BGP autosummary объясняет как работает команда, а не зачем нужна автосуммаризация в BGP (заметьте, я говорю не про суммаризацию BGP-префиксов вообще, а про АВТО-суммаризацю). Так вот эта циата — она про то и говорит, что если автосаммари включено, то вместо реального префикса 10.100.50/24 в BGP уйдет 10/8. Это и есть бред сивой кобылы. =В данном случе разговор про суммаризацию по границе класса.

    И даже если бы она была бесклассовой, а некий другой «умный» механизм бы из двух соседних префиксов 10.100.50/24 и 10.100.51.0/24 автоматически бы по умолчанию всегда делал 10.100.50.0/23, то это все равно было бредом сивой кобылы. Например потому что BGP — протокол предназначенный для передачи очень большого количество маршрутов (сотен тысяч и миллионов). И выдергивание нескольких префиксов /24 из таблицы, в которой автоматически сделана такая суммаризация, может привести к неадекватно большим вычислительным затратам. Впрочем, это далеко не единственная причина.

    Циска — один из немногих вендоров, реализации которой что-то знают про классы адресов. Делает она это не потому что так уж любит классовую адресацию, а потому что выкидывание фич, пусть даже устаревших, из огромной промышленной машины с заказчиками, привычками, миллионо специфический внедренй, документацией (внешней и внутренней), книгами и т. д. — это гораздо сложнее (читай: очень дорого), чем сохранять эти фичи, не трогая их.

    Большинство же вендоров вообще не употребляют такие слова как «класс адресов» и «CIDR-блок», потому что никаких других кроме CIDR блоков адресов давно уже нету. И это совершенно никому не мешает.

    Знать про все это, в принципе, нужно, для кругозора и вообще, чтоб читать всякие такие старинные RFC и уметь поддержать беседу про RIP.
  • Еще раз про IP-адреса, маски подсетей и вообще
    0
    Про автосаммари мы выше разговаривали. См. чего sahe пишет в частности в этой ветке: habrahabr.ru/post/129664/#comment_4311895 Если хоротко, то это где-то в диапазоне между «говно мамонта» до «причуды реализации одного вендора». С RIP то же самое. Я еще в 2003 году учился в Cisco Academy и ребята там балуясь на доске рисовали могилку и писали «RIP RIP». 10 лет прошло.

    То есть ретроспективно, для общего развития, рассказов внукам, пугания детей и проч. — про все это имеет смысл иметь какое-то представление. Если говорить о ликбезе, то нахрен это оно не сдалось.

    Кстати, для BGP автосуммаризация, хоть классовая, хоть бесклассовая — это вообще бред сивой кобылы.

    Никакой классовой адресации нету. Нету. Забудьте. Есть вендоры, экзамены, книжки, люди, которые это слово употребляют. Да, есть. Ну есть еще люди, которые говорят «лóжить» и «звóнить». Ну есть. Ну говорят.
  • Еще раз про IP-адреса, маски подсетей и вообще
    0
    Про автосаммари мы выше разговаривали. См. чего sahe пишет в частности в этой ветке: habrahabr.ru/post/129664/#comment_4311895 Если хоротко, то это где-то в диапазоне между «говно мамонта» до «причуды реализации одного вендора». С RIP то же самое. Я еще в 2003 году учился в Cisco Academy и ребята там балуясь на доске рисовали могилку и писали «RIP RIP». 10 лет прошло.

    То есть ретроспективно, для общего развития, рассказов внукам, пугания детей и проч. — про все это имеет смысл иметь какое-то представление. Если говорить о ликбезе, то нахрен это оно не сдалось.

    Кстати, для BGP автосуммаризация, хоть классовая, хоть бесклассовая — это вообще бред сивой кобылы.

    Никакой классовой адресации нету. Нету. Забудьте. Есть вендоры, экзамены, книжки, люди, которые это слово употребляют. Да, есть. Ну есть еще люди, которые говорят «лóжить» и «звóнить». Ну есть. Ну говорят.
  • Построение провайдерской сети на коммутаторах Cisco с использованием Option 82 и Dynamic ARP Inspection
    0
    Ой. Я не это совсем имел в виду. Ну, т. е. использовать EoL и БУ оборудование — это вполне себе бизнесс-стратегия, успех которой обсуждать мне, честно говоря, лень. Скажу лишь, что для данной конкретной задачи 2950 ничем не лучше, чем третьесортный китайский OEM. Но мне, честно говоря, показалось, что автор их использовал просто потому что они у него под рукой были — типа, лаба.

    Я скорее про техническую часть. Вообще сеть под ШПД-подписку из одних только коммутаторов такого рода (не обязательно c2950, вообще любых энтерпрайзных свичей) — это сомнительная затея с точки зрения масштабируемости, управляемости, устойчивости к отказу и проч. Точнее, она более-менее ОК, когда между BRAS-ом и абонентом не больше двух коммутаторов. Дальше начинается подземелье.
  • Построение провайдерской сети на коммутаторах Cisco с использованием Option 82 и Dynamic ARP Inspection
    +1
    Ну типа про option82 — да (хотя имхо 1:1 VLAN веселее), но строить провайдерский доступ, обставив город каталистами 2950 — о-хо-хо, написал бы вот кто-нибудь о том, почему так делать не надо :)
  • Способы представления словарей для автоматической обработки текстов
    0
    Ну, то есть, я правильно понимаю, что все рассуждения про оптимизацию здесь справедливы только для частного случая морфлогического анализа и описываемый подход может оказаться неприемлем, если задача расширяется до синтаксиса?
  • Способы представления словарей для автоматической обработки текстов
    0
    Складывается ощущение, что все описанное имеет отношение только к морфологии.

    Но ведь очевидным желанием является хранить внутри представлений слов как минимум синтаксические свойства слов (ок, на следующем этапе и т. д.) Ведь в конце концов ваш пример с «мама мыла раму» — он про синтаксис. В конечном итоге задача сведется к ответу на вопрос «мыла» — это «мыло» или «мыть». Да и ссылки на примеры систем автоматической обработки текстов — они как минимум не про чистую морфологию.

    Соответственно, у переходов в дереве состояний должны быть какие-то веса/вероятности/etc, сигнализирующие морфологические изменения в зависимости от синтаксической роли. Ну или как-то еще структура должна позволять (в будущем) хранить эту (а возможно и другие типы) информации о словах.

    Получается, что весь разговор про оптимизацию структур нужно вести в контексте возможности масштабирования и возможности «навески» дополнительных аспектов. Иначе может получиться, что оптимизированное представление, рассчитанное только на морфологическую информацию, не позволит использовать словарь для более-менее реальных прикладных задач.

    Ну или по крайней мере хочется понять, зачем нужен словарь, которые содержит только морфологические данные.
  • Критическая уязвимость во всех версиях JunOS начиная с 7.6R1
    0
    Я прекрасно понимаю, о чем вы.

    Но только еще раз повторюсь, что пакет, прежде чем вообще быть скоммутированным свичем, который передает трафик с плат коммутации в RE, должен пролезть через систему файрвольных фильтров внутри комплекса коммутации. В случае с eBGP это должен быть пакет только от пира, и только с TTL 1. То есть это способ защититься в том числе от этой уязвимости, и это должно быть сделано, на любом маршрутизаторе, RE которого общается с недоверенными сетями.

    И если этого не сделано, то бессмысленно вообще говорить о каких-либо уязвимостях, потому что, если кто-то хочет выставить свою задницу в интернет, вопрос о том, каким именно способом его могут трахнуть, приобретает вторичное значение.

    SSH с web-менеджментом, если он у вас есть, на время до апгрейда можно и вовсе отключить из интернета. Другие TCP, адресованные в RE, надо просто выкидывать у помойку не глядя. И до того, как этот косяк обнаружили, так и после.

    Так что никакой страшной неопределеннсти и вот этого вот «ах, неизвестно к чему это можно привести. Вдруг нам нужно какие-нибудь еще TCP-порты слушать, а мы не знаем, какие» — ничего этого нету. Все вполне известно и определенно. И защититься в данном конкретном случае вполне можно и нужно.

    А то что уязвимость и баги это плохо — ну, можно и попалакать, конечно, но мне лень, если честно. Далеко не самая страшная это проблема, в т. ч. из встречающихся в JUNOS.
  • Критическая уязвимость во всех версиях JunOS начиная с 7.6R1
    0
    Ну, я с вашего позволения, повторю свой первоначальный тезис:

    Если так случилось, что конфигурация уязвима в отношении данного экспойта, то с большой вероятностью она уязвима к массе других возможных атак на тот же BGP, о которых известно давно и подробно. И наоборот: если вы раньше думали головой и все делали правильно, то от этой проблемы вы защищены — проапгрейдиться все же стоит, но скорее в плановом режиме, чем сломя голову.

    А дальше каждый сам решает, разумеется.
  • Критическая уязвимость во всех версиях JunOS начиная с 7.6R1
    0
    Ну, то есть, поймите правильно мой спич. Задуматься об апгрейде надо, нет вопросов. Но вот прям паниковать и сломя голову менять софт, нарушив стандартные правила этого дела (как минимум чтение Release Notes плюс соотнесение номера релиза со здравым смыслом) — по-моему не стоит. Лучше проверить, чего у вас в части стандартных механизмов защиты сделано.
  • Критическая уязвимость во всех версиях JunOS начиная с 7.6R1
    0
    Ну, если все так плохо: и multihop, и вы max ttl выставили от души, и атакующий знает адреса пиров, то да, можно кричать «караул». Только по хорошему делать это надо несколько раньше. Спорим, что в таком сулчае у вас на сессии нету аутентификации, и положить вашу внеш пиринг можно без всяких багов просто послав вам чего-нибудь по BGP? А еще лучше — просто слать вам TCP RST со всех подряд src-портов.
  • Критическая уязвимость во всех версиях JunOS начиная с 7.6R1
    0
    prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR839412

    Собственно, там все написано. Судя по всему, это уязвимость ядра FreeBSD (так что надо жать аналогичные репорты о других продуктах на базе этого ядра).

    Честно говоря, причин для паники не вижу.

    Если у вас RE не защищен от входящих TCP откуда ни попади, то вас можно задосить еще примерно сотней способов.

    В идеале FW-фильтры, защищающие RE, и не должны принимать TCP на RE от всех подряд. BGP должен быть разрешен только от сконфигурированных пиров (одна команда), к тому же eBGP — только с TTL 1. SSH — от доверенных, и т. д.

    О best-practices защиты RE см. например вот эти книжки:

    www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/ (доступно официально бесплатно в виде PDF).
    www.juniper.net/us/en/training/jnbooks/mx-series.html
  • Juniper PTX series как шаг в светлое будущее
    0
    К вопросу об устройстве LINX.

    www.nanog.org/meetings/nanog54/presentations/Wednesday/Cobb.pdf

    Как и ожидалось, Extreme… эээ… ну не в ядре, в общем, точно.
  • Линус Торвальдс о бинарной совместимости
    0
    Мне, признаться, показалось, что все не до такой степени плохо. Но не стану спорить.
  • Линус Торвальдс о бинарной совместимости
    +6
    Почитал предыдущую часть переписки, и у меня сложилось ощущение, что Торвальдс как истинный финн был пьян в сраку, когда это писал не все так однозначно. Если принять за верные все постулаты, которые он столь экспрессивно критикует, — то да.

    Но Байдерман-то выше пишет, что неработоспособность патча — это в первую очередь баги с опечатками, и вообще его наколеночность. И, мол, надо тестить и разбираться. Коммитить код с багами, конечно, совсем некруто, но речь там идет не о выкидывании счетчика вообще, а об опции в конфиге, которая бы его выключала. Можно подумать, это была бы единственная опция в конфиге ядра, которая делала бы часть приложений неработоспособными. Хахаха.

    Короче, сложилось ощущение, что Эрик про бузину, а Линус про в Киеве дядьку. То есть именно про теоретически правильную и основную функцию ОС обслуживать юзерспейс — ОК, спору нет, но деградация перформанса ради кривого счетчика — это чо, не юзерспейс что ли?

    Ну либо это из раза в раз такое, и Торвальдс уже затрахался ему объяснять за концепцию.
  • Juniper PTX series как шаг в светлое будущее
    0
    Надо как минимум уметь делать крутую балансировку с возможностью настраивать поля для хэша и умением заглядывать глубоко в пейлоад с условиями типа «если это IPv4, то включать в хэш то, а если VPLS, то это». Там меня кто-то ткнул в драфт про энтропийный лейбл, типа это упрощает дало. А это нифига не упрощает, потому что нужно просерфить стек до самого низу и забрать оттуда 20 бит в хэш (да и когда это еще PE научатся его сигнализировать). Дешевым чипам, которые ставят в большие L3-свичи, до всего этого как до Марса. И нихрена не получится вынуть чип из какого-нибудь QFX или EX4500 и поставить в PTX.

    Плюс к этому есть еще FRR 1:N, потом Interprovider Option C не мешало бы уметь в ядро втыкать. Если MPLS-TP взлетит, то скорее всего, нужно будет на границе ядра еще одну транспортную метку шлепать. Потом — P2MP LSP надо и реплицировать качественно, и протекцию им делать. Подозреваю, что если поковырять, то найдутся и другие фичи.

    Весьма непростой forwarding plane получается. Собственно, если я все правильно понимаю, хваленая простота PTX'ового чипа Express — лишь в том, что у него FIB маленький и соответственно АЛУ, которое в нем лукапы делает, нужно меньше дури. Соответственно, меньше энергии, выделения тепла, больше чипов в коробку можно впихнуть, выше перформанс на погонный метр. А по фичам он все равно сложный, и стоимость разработки у него небось не ниже, чем у Trio.

    Не видел ты (как и я) много чистых P потому что на сегодняшнем железе их нет смысла делать. По вышеописанным причинам вендорам невыгодно делать мало фич на дорогом чипе, поэтому уж если делать, то сразу очередную вариацию на тему M/MX. Тэшки позиционируют как ядерные, а как до цены дело доходит, то (ну, до недавних пор) они дороже MX'ов выходят.

    А ребята, которые готовы купить MX или T под чистые P-роутеры, — им-то как раз PTX и нужен, они лучше за бóльшую дурь заплатят, чем за все эти эджевые фичи с багами.
  • Juniper PTX series как шаг в светлое будущее
    0
    Переполнение FIB то есть, SRAM, а не TCAM :)
  • Juniper PTX series как шаг в светлое будущее
    0
    Ой, Саша, я верю, что Экстрим — вменяемый вендор, но все это разговор совсем про другое. Сей агрегат — конкурент в лучшем случае MX'ам, а не PTX. А по SP-фичам скорее всего и ему не конкурент. Как эдж-PE-свич для ЦОДов и IXов (свич с VLL-ями и VPLS) — очень может быть, а как агрегатор клиентов (про брас умолчим) — я, скажем прямо, сомневаюсь.

    Я в j-nsp (см. ветку про переполнение TCAM на EX8200) уже выступал на эту тему: P-роутер — штука куда более сложная, чем кажется на первый взгляд, и я крайне-крайне сомневаюсь, что под нее можно приспособить любой комодити-чип по 2$ за ведро, у которого дури много, а ума мало. Там не только тупо свопать надо.

    Где-то рядом в этой же ветке RAS высказывался в том ключе, что по-настоящему разработку MPLS нынче понимают только два вендора, просто хотя бы в силу того, они же и пишут большую часть стандартов. Я склонен согласиться (сомневаюсь, что Extreme тут принципиально обгоняет Brocade).

    Ну и да, спору нет, чисто ядерные супермегамноготерабитные MPLS P-роутеры — это сегодня еще два с половиной [well, два с половиной десятка] заказчика по всему миру, но тенденция, я бы сказал, верная: обратное разделение на P и PE по-моему таки неизбежно.
  • Juniper PTX series как шаг в светлое будущее
    0
    Я плохо знаю линейку Extreme, но по-моему это всего лишь ethernet-свич. Косвенно мое подозрение подтверждается тем, что если лондонский IX в своем уме, то ядерных агрегатов ему сто лет не надо, а нужны имендо эджовые агрегаторы тысяч L2-портов. Даже если я ошибаюсь, то, признаться, не верю, что Extreme сколько-нибудь близко может конкурировать с джунипером и циской в MPLS-е, пусть даже ядерном. То есть это про разное вообще разговор.

    Насчет года — да Juniper стал любить такие выкрутасы. Инвестор верит, акции растут :)
  • О ненужности Spanning Tree
    0
    CEF — это про другое вообще.
  • О ненужности Spanning Tree
    0
    Кстати, а где такие IX, на которых разрешают больше одного мака на порту?
  • О ненужности Spanning Tree
    0
    На IX вряд ли вам это удастся. Со всех точек зрения. Так что, спорный вопрос, кто кого протарифицирует )
  • О ненужности Spanning Tree
    0
    Эх, ошибся.

    user@EX-4200.senetsy.lab> show virtual-chassis protocol ?            
    Possible completions:
      adjacency            Show virtual chassis adjacency database
      database             Show virtual chassis link-state database
      interface            Show virtual chassis protocol interface information
      route                Show virtual chassis routing table
      statistics           Show virtual chassis performance statistics


    Слова ISIS там в явном виде нету, но по выводу, в общем, все понятно.

  • О ненужности Spanning Tree
    0
    >Если мы говорим о трёх уровневой иерархической модели, то это модель для построения кампусных сетей, а не операторских.

    Ну да. Просто в бумажке, на которую вы дали ссылку, предполагается L3 между вторым и первым (типа, ядром) уровнями гирлянды (routed access layer или как оно там). В жизни (кампусной, ага, сети) это слишком сильное упрощение, так не бывает. Во-первых нужна фильтрация, которую такое решение очень затрудняет, во-вторых — обычно требуется возможность проброса VLAN'ов (тот же голос) по всей сети.

    Плюс, я хотел сказать, что три уровня иерархии свичей — это весьма и весьма крупный кампус (не первые тысячи пользовательских портов). В большинстве случаев обычно достаточно двух уровней. Но если нужно три, то механизмов реализации сегодня уже предостаточно, в т. ч. даже допускающих мультивендорность, я с этим и не спорю. И вообще нигде речь не шла, что, скажем, Juniper или какой-то другой вендор в рассматриваемой области предлагает что-то принципиально прям иное (QFabric vs Trill оставим за скобками, это про другое).

    Собственно, по-моему у нас с вами спору-то в этой части нету.

    >И что значит «У провайдеров никакого L3 не может быть»?

    На доступе не может. Особенно, если ШПД для физлиц, впрочем, и юриков тоже так не наагрегируешься. Ну, то есть, в жизни, конечно, еще не то может, особенно в наших краях (весьма популярный способ, да), но это противоречит всему, чему можно противоречить. Несколько тысяч абонентов, и все, привет, дальше не масштабируется. Исключением можно считать, пожалуй, пакетную подсистему сетей мобильных операторов, но там это обстоятельство тянет за собой неслабое количество архитектурных примочек и стоит соответствующих денег.
  • О ненужности Spanning Tree
    0
    Буду читать второе предложение статьи со слов «то как минимум» :) Еще есть дурацкие способы LDP VPLS-мультихоминга, например.
  • О ненужности Spanning Tree
    0
    В Питере, чего не построй, все продать можно, если продавать уметь.
  • О ненужности Spanning Tree
    0
    Ну, вашу нелюбовь к MPLS мы уже обсуждали :) Правда я не понял про «если б строились с нуля». MPLS у них вроде с нуля, думаю, ATM тоже в свое время был с нуля.

    Просто еще города с плотностью населения как в Питере — это одно, а какая-нибудь республика Коми — это трошки совсем другое.
  • О ненужности Spanning Tree
    0
    В книжке «JUNOS Enterprise Switching» (в интернетах найти можно при желании). В CLI есть команда show virtual chassis чего-то там isis database и т. д. На каждом заборе, да, не написано, но никакого секрета в этом нет.

  • О ненужности Spanning Tree
    0
    MPLS железки класса MX80, которые можно поставить в районный городишко — они ж вот только появились. А на кольца переходить, видно, очень уж не хотелось (что правильно).
  • О ненужности Spanning Tree
    0
    Да ни в чем, кром етого, что его надо чем-то заменять. Есть присутствие MPLS-магистрали в крупных городах региона. И есть ATM-акцесс, которым они дотягиваются до клиентов в соседних р-нах и т. д. Собственно, чем его заменять? Кольцами скажете с ринг-проекшеном? Сомневаюсь. А MPLS потихоньку дотягивается на районные узлы, становится, извиняюсь за грубое слово, seamless — ATM выкидывают.