[g3fox]

Я отлично знаю Циску, и поверьте, лимит на 8 VLAN`ов бесит ещё больше.

Что?!

 

Я не ярый противник микротика. Разумеется, ниша у него своя, а за свои деньги девайс отличный.

 

Я больше не понимаю желания делать 50 выносов L2.

Это ***ец же. Делайте l2tp или pptp, а поверх OSPF, на выносах /29 (если у вас там действительно 2 человека и телефон).

Такое решение можно резервировать и масштабировать.

А вы сами себя зарываете в каком-то говне.

[korobeynikov]

Я больше не понимаю желания делать 50 выносов L2.

Это ***ец же. Делайте l2tp или pptp, а поверх OSPF, на выносах /29 (если у вас там действительно 2 человека и телефон).

Вы реально думаете, что мы свою адресацию на L2 выносим?

Наша адресация идёт на L3, по OSPF с резервом.

На L2 выносятся стыки с инфраструктурными службами точки (например, телефонная сеть торгового центра, или служба безопасности).

Изменено 30 апреля, 2015 пользователем korobeynikov

[korobeynikov]

Потом начинаются удивления с флапами - это общепризнанная проблема, и пока никак не решена.

Вы про то, что когда пропадает связь с соседом, после маршрут некоторое время остаётся в таблице маршрутизации?

[vlad11]

Вы про то, что когда пропадает связь с соседом, после маршрут некоторое время остаётся в таблице маршрутизации?

 

Нет.

Flapping BGP Routes

[korobeynikov]

vlad11, это может быть актуально для транзитных AS, я согласен. У нас тупиковая сеть.

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

 

Что с "петлями" на OSPF?

[g3fox]

korobeynikov (Вчера, 21:56) писал:

Вы про то, что когда пропадает связь с соседом, после маршрут некоторое время остаётся в таблице маршрутизации?

 

 

Нет.

Flapping BGP Routes

 

Видимо, коллеги имеют ввиду высокую нагрузку на девайс, от поднятий-падений BGP. Либо наоборот о том, что на микротике это "нормальная" ситуация (но я таких проблем не замечал).

 

 

Вы мне про:

Я отлично знаю Циску, и поверьте, лимит на 8 VLAN`ов бесит ещё больше.

так и не ответили. Какие восемь вланов?!

 

 

Вы реально думаете, что мы свою адресацию на L2 выносим?

Наша адресация идёт на L3, по OSPF с резервом.

На L2 выносятся стыки с инфраструктурными службами точки (например, телефонная сеть торгового центра, или служба безопасности).

Я думаю и делаю выводы исходя из того, что Вы написали. А написали Вы про какую-то херовую затею.

То есть вы тащите чужой L2 к себе? правильно? Чтобы с ним что сделать-то в итоге? Терминировать? А сразу на том самом выносе это нельзя сделать было?

В общем про L2-выносы я так ничего и не понял. Мне кажется, что Вы начинаете "юлить"...

 

 

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

 

Что с "петлями" на OSPF?

 

Как, в вашем случае, iBGP связано с OSPF?

Если Вы не будите редистрибьютить одно в другое, и наоборот - то так и останется iBGP отдельно, а OSPF отдельно.

Напишите поподробнее.

[korobeynikov]

Видимо, коллеги имеют ввиду высокую нагрузку на девайс, от поднятий-падений BGP. Либо наоборот о том, что на микротике это "нормальная" ситуация (но я таких проблем не замечал).

Вы бы хоть ссылки читали, которые Вам дают.

 

Какие восемь вланов?!

VLAN-интерфейсы и BVI, которыми нужно манипулировать.

 

А сразу на том самом выносе это нельзя сделать было?

В том то и дело, что дешевле в каждой точке поставить Микротик и вынести на централизированный сервер, нежели городить тазики с бесперебойниками.

 

Как, в вашем случае, iBGP связано с OSPF?

Это был отдельный вопрос про всяческие баги с петлевыми маршрутами на OSPF.

[g3fox]

Вы бы хоть ссылки читали, которые Вам дают.

Не обратил внимание, что это была ссылка.

 

В том то и дело, что дешевле в каждой точке поставить Микротик и вынести на централизированный сервер, нежели городить тазики с бесперебойниками.

 

Всё равно не понимаю. Какие, к херам, тазики и бесперебойники? Я не говорю Вам, что нужно ставить тазик или циску. Зачем Вы уводите куда-то в сторону постоянно?

На микротике можно сделать только L2 вынос? А если нужно что-то иное, то обязательно тазик и уж никак без ИБП?

 

Если Вы всё равно делаете этот L2-вынос, якобы, для терминации этого L2 в центре на микротике, то почему нельзя терминировать сразу на выносе (тоже на микротике, а не на тазике и ИБП)?

 

Где, логика? Нахера тащить Л2, если можно его оставить за выносом?!

Либо Вы что-то недоговариваете, либо совсем не видите минусов своего решения.

 

Хорошо, что Вы не оператор...

[korobeynikov]

1. СБ должна иметь доступ L2 к любому свичу в организации.

2. Это удобно при инсталляции оборудования.

3. Вам в точке подключения предлагают сделать стык с AS торгового центра.

Изменено 1 мая, 2015 пользователем korobeynikov

[vlad11]

vlad11, это может быть актуально для транзитных AS, я согласен. У нас тупиковая сеть.

 

Это не имеет значения. Нагрузка будет чуть ниже.

Но эффекты те же.

Я хочу посмотреть на микротик, когда он будет принимать маршруты в шахматном порядке от 3-х FV, как он будет в памяти их хранить и как долго они будут в памяти хранится при частом обновлении маршрутов.

Для нынешних времен часто происходит флапинг овер 2K маршрутов.

[g3fox]

1. СБ должна иметь доступ L2 к любому свичу в организации.

2. Это удобно при инсталляции оборудования.

3. Вам в точке подключения предлагают сделать стык с AS торгового центра.

 

Зачем вы опять что-то придумали?

1. Странные требования. Тут скорее есть угрозы безопасности вашей инфраструктуре. Да и не понятно ***я там нужен коммуатор, если, как вы сказали, там 2 ПК + 1 телефон. Опять придумано.

2. ...удобно... слов нет. Срёте хоть не лёжа? Вроде, тоже удобно.

3. И что?! ИБП нужно ставить?

Увольтесь и продавайте мороженое.

 

В общем, покину эту беседу...

[korobeynikov]

vlad11, в FV порядка 500K+ маршрутов.

Как в тупиковой сети словить этот флапинг про который вы пишете?

[DVM-Avgoor]

Маршруты плавают пачками от разных апстримов. Бывает по несколько десятков тысяч уходит и возвращается. Это никак не зависит от того конечная у вас AS или транзитная.

Я со "взрослыми" микротиками дела не имел, но раз там x86-подобие чуть более 1ГГц, вероятно он не будет сильно страдать от флапов бгп, максимум пакеты потеряет некоторое время :)

Другое дело, что он полностью софтовый, а значит пиковые нагрузки на ЦПУ могут (и будут) оказывать влияние на весь процесс прохождения трафика. Если такое у вас допустимо в рамках задачи, то покупайте самый мощный из CCR и учитесь с ним жить.

[NiTr0]

раз там x86-подобие чуть более 1ГГц

В CCR - не х86. VLIW ядрышки, довольно-таки урезанные по кешу и т.п.

[korobeynikov]

Если такое у вас допустимо в рамках задачи, то покупайте самый мощный из CCR и учитесь с ним жить.

Мы на 9 ядер хотели взять, вот к такому приглядываемся: CCR1009-8G-1S-1S+PC.

 

На модели RB1100AHx2, в ходе теста мне не понравилась та штука, что несмотря на то, что общая загрузка CPU 50% — 1 ядро загружено на 100%, другое на 0%, если более 50%, то 100% + остаток%.

[pppoetest]

На модели RB1100AHx2, в ходе теста мне не понравилась та штука, что несмотря на то, что общая загрузка CPU 50% — 1 ядро загружено на 100%, другое на 0%, если более 50%, то 100% + остаток%.

Вы думаете на 9-ти или 36-ти ядерном говнотике будет иная картина?

[DVM-Avgoor]

В CCR - не х86. VLIW ядрышки, довольно-таки урезанные по кешу и т.п.

 

VLIW - не конкретная архитектура, а лишь семейство архитектур, командный язык которых каждый реализует как хочет.

Тилеры, тащем-та, на прикладном уровне полностью x86-совместимы, читайте исходник :) Правда их 1Ггц-ядро значительно проигрывает аналогичному ядру семейства Haswell, например.

 

На модели RB1100AHx2, в ходе теста мне не понравилась та штука, что несмотря на то, что общая загрузка CPU 50% — 1 ядро загружено на 100%, другое на 0%, если более 50%, то 100% + остаток%.

 

Ну дык линукс же во все поля. Наличие сотен ядер не означает умения ими пользоваться. Существующий открытый софт, пока еще, не умеет. Рецепт удачного софтороутера от jab все еще не поменялся: ГГц, размер кэша, скорость памяти - в порядке убывания важности. А кол-во ядер совсем уж вторично, 4 ядра хватит за глаза.

[NiTr0]

VLIW - не конкретная архитектура, а лишь семейство архитектур, командный язык которых каждый реализует как хочет.

Вы вообще понимаете в чем фундаментальное отличие VLIW от CISC/RISC?

 

Тилеры, тащем-та, на прикладном уровне полностью x86-совместимы, читайте исходник

Чего? Вы хотите сказать что вот сейчас на CCR вы зальете слинкованный статикой х86 эльф и он запустится???

[DVM-Avgoor]

Вы вообще понимаете в чем фундаментальное отличие VLIW от CISC/RISC?

 

Тем что можно слать Х инструкций в одной команде. Впрочем это не означает что все так делают. Частенько бывает и CMD;NOP;NOP;NOP например :)

 

Чего? Вы хотите сказать что вот сейчас на CCR вы зальете слинкованный статикой х86 эльф и он запустится???

 

Нет, я лишь сказал, что x86-совместимый набор команд. Для разработчика, если он не пытается писать ассемблерные вставки, с прикладной точки зрения ничего не меняется. Ему не надо сидеть надрачивать на размер слова, выравнивание и байт ордер. Для него это обычный x86. SDK, линкер и компилятор от Тилеры скрывают все особенности архитектуры. В этом конечно и дьявол.

https://2013.asiabsdcon.org/papers/abc2013-K1-paper.pdf для интереса, если не читали :)

[NiTr0]

Нет, я лишь сказал, что x86-совместимый набор команд.

И в чем же эта совместимость, если наборы команд абсолютно разные, и более того, архитектуры абсолютно разные (VLIW с длинным словом команд фиксированной длины и CISC с переменной длиной команды)?

 

Для разработчика, если он не пытается писать ассемблерные вставки, с прикладной точки зрения ничего не меняется. Ему не надо сидеть надрачивать на размер слова, выравнивание и байт ордер.

Точно так же как и для любой другой архитектуры - об этом беспокоится компилятор (ну кроме попыток криворукого программера запихнуть сырой байт-массив в int/float - тут всплывает endianness). А следуя вашей логике - любой little-endian проц х86-совместимый потому что имеет такой же byte order...

[DVM-Avgoor]

И в чем же эта совместимость, если наборы команд абсолютно разные, и более того, архитектуры абсолютно разные (VLIW с длинным словом команд фиксированной длины и CISC с переменной длиной команды)?

 

А как эльбрус будучи vliw может быть x86-совместимым? Еще раз: все конвенции поведения соблюдаются, это залог совместимости. А имя инструкций и ширина аргумента вообще сугубо внутренняя проблема архитектуры. Где-то в вашей логике что-то сломалось?

 

Точно так же как и для любой другой архитектуры - об этом беспокоится компилятор (ну кроме попыток криворукого программера запихнуть сырой байт-массив в int/float - тут всплывает endianness). А следуя вашей логике - любой little-endian проц х86-совместимый потому что имеет такой же byte order...

 

Вам больше заняться нечем, кроме как писать чушь? :) Но вы цепляетесь к мелочам, игнорируя очевидные факты, например: программа скомпилированная для core2-32bit не будет работать на пентиуме первом, хотя они оба x86-совместимые. Или как документ с asiabsdcon, который вы успешно игнорируете, в котором ясно написано что портирование не стало трудной задачей, некоторые мелочи поправили и поехало. Чего нельзя сказать о портировании x86 -> arm/mips/ppc.

ПС. Я лично не вижу смысла продолжать флейм в этой теме, особенно учитывая ваше искаженное понимание вещей. И навязчивое желание уцепиться любой ценой за любую неточность. Это не конструктивно.

[korobeynikov]

DVM-Avgoor, на счёт 9 ядер и CCR1009-8G-1S-1S+PC что скажите?

[DVM-Avgoor]

DVM-Avgoor, на счёт 9 ядер и CCR1009-8G-1S-1S+PC что скажите?

 

Я считаю, что те кому надо принимать 3 FV не должны экономить на железе. Или покинуть такой бизнес, где собирают копейки на бордер.

А насчет 9 или 36 ядер: больше - лучше! Всё равно всё сильно индивидуально, чтобы оценивать хватит или не хватит.

[korobeynikov]

Или покинуть такой бизнес, где собирают копейки на бордер.

Если вам нужно резервировать 3 сервера, вы будете покупать Бордер по цене этих трех серверов?

 

Нагрузка - до 10-20 мегабит.

[DVM-Avgoor]

3 FV на 10 мбит? Это что-то с дизайном плохое. Но отвечая на ваш вопрос, я бы купил juniper srx.