Pull to refresh
136
0
Send message
Ну, если все так плохо: и multihop, и вы max ttl выставили от души, и атакующий знает адреса пиров, то да, можно кричать «караул». Только по хорошему делать это надо несколько раньше. Спорим, что в таком сулчае у вас на сессии нету аутентификации, и положить вашу внеш пиринг можно без всяких багов просто послав вам чего-нибудь по BGP? А еще лучше — просто слать вам TCP RST со всех подряд src-портов.
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
К вопросу об устройстве LINX.

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

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

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

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

Ну либо это из раза в раз такое, и Торвальдс уже затрахался ему объяснять за концепцию.
Надо как минимум уметь делать крутую балансировку с возможностью настраивать поля для хэша и умением заглядывать глубоко в пейлоад с условиями типа «если это 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 и нужен, они лучше за бóльшую дурь заплатят, чем за все эти эджевые фичи с багами.
Переполнение FIB то есть, SRAM, а не TCAM :)
Ой, Саша, я верю, что Экстрим — вменяемый вендор, но все это разговор совсем про другое. Сей агрегат — конкурент в лучшем случае MX'ам, а не PTX. А по SP-фичам скорее всего и ему не конкурент. Как эдж-PE-свич для ЦОДов и IXов (свич с VLL-ями и VPLS) — очень может быть, а как агрегатор клиентов (про брас умолчим) — я, скажем прямо, сомневаюсь.

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

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

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

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

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 там в явном виде нету, но по выводу, в общем, все понятно.

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

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

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

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

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

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

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

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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity