[evd]

Ну почему же, у IX есть правила, на основании которых как бы можно принять меры к нарушителям. В случае msk-ix есть п.13 ТУ

На MSK-IX работают очень грамотные ребята, но вашу веру в их всемогущество хорошо бы подкрепить фактами. Как-то: такого-то числа техслужбой IX зафиксирован левый трафик от участника А к участнику Б, виновник отправлен в карантин :o

 

П.13 - обязательная в таких случаях сентенция про "муж должен любить свою жену". Если вдруг загремишь за злостное хулиганство, то заодно могут припомнить и жалобы супруги на частые измены ;)

[zi_rus]

Вы в качестве средства раскраски трафика, влетевшего с ix-а, предлагаете использовать QoS?

а вы знаете другие способы раскрашивать трафик?

 

Если Вас смутило в вопросе упоминание о iBGP-нейборе, то этим я лишь хотел подчеркнуть, что ix(ы) и аплинк(и) вовсе не обязательно включены все в одну железку

меня смутило уточнение что надо красить трафик, а не маршруты, и я показал как можно красить трафик соответствующий маршрутам

 

на бордере подключенному к ix раскрашиваете трафик, благо dscp номеров хватает, а на выходе на аплинк режете его до нуля полисером или фильтром

 

то, что я предложил выше, тоже можно использовать как вариант если на сети нет свободных dscp и если с ix не идет трафик не попадающий под маршруты с этого ix объявленные

[magr]

2evd,

 

Евгений,

Не все, что описано в тех. условиях, возможно контролировать автоматизированными средствами со стороны самого IX. По части пунктов ТУ, для их применения в отношении кого-либо требуется информация от других участников. ==> пишите письма, кому это актуально.

 

На тему: "такого-то числа техслужбой IX зафиксирован левый трафик от участника А к участнику Б, виновник отправлен в карантин". Такие прецеденты безусловно были, по письмам от участника Б инициировалось разбирательство. Если при этом Б испытывает серьезные проблемы из-за А, и А не реагирует на обращения в разумные сроки, то он попадает в карантин.

Не поручусь, что эти случаи именно по 13-му пункту ТУ проходили, не суть важно.

[ayvango]

а разве эта задача решается таким волшебным способом?

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

[evd]

На тему: "такого-то числа техслужбой IX зафиксирован левый трафик от участника А к участнику Б, виновник отправлен в карантин". Такие прецеденты безусловно были, по письмам от участника Б инициировалось разбирательство. Если при этом Б испытывает серьезные проблемы из-за А, и А не реагирует на обращения в разумные сроки, то он попадает в карантин.

Не поручусь, что эти случаи именно по 13-му пункту ТУ проходили, не суть важно.

Как раз важно. Если бы вдруг MSK-IX решил заняться несвойственной ему функцией контроля валидности ip-трафика согласно п.13, то начинать ему следовало бы с того, что на пушечный выстрел не подпускать к точке обмена трафиком тех, кто не имеет возможности или желания держать на своём бордере full view. И записать это одним из пунктов ТУ. Потому что утекающие по морспецификам пакетики от "операторов эконом-класса", пролетающие через сеть его пира и затем вылетающие в его аплинки - это и есть тот самый левый трафик, который заставляет крупных операторов уходить с ix-ов. Об этом, в частности, говорил Янус чуть выше в этой ветке, imho излишне эмоционально, но по сути

[zi_rus]

Об этом, в частности, говорил Янус чуть выше в этой ветке

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

 

а томы тут в своей деревне сидим и тупо не принимаем more specific анонсы ни от клиентов ни от пиров

Изменено 10 марта, 2012 пользователем zi_rus

[evd]

а вы знаете другие способы раскрашивать трафик?

Про это и был мой вопрос ;)

Так как Вы взялись на него ответить, то следовало предположить, что Вы - знаете

 

меня смутило уточнение что надо красить трафик, а не маршруты

Прочитать всю ветку пробовали? Или хотя бы те две строчки, которые Вы выкусили в первом же своём ответе:

 

Если я правильно понимаю, тут описывали проблему, что от жуликов приезжает траффик с IX и уезжает в аплинк. А кто мешает покрасить траффик и такой цвет не выпускать через аплинк?

 

Дальнейшие ваши уточнения, извините, цитировать не буду. В качестве решения не совсем корректно (imho) поставленной задачи Вы предлагаете более чем сомнительный механизм. Который, в идеале, должен спасать "дорогую" часть трафика в аварийных ситуациях. На практике же - содержит неприличное количество софтовых багов. Вплоть до перекрашивания пакетов случайным образом (конкретно, наблюдал такое на агрегатах/etherchannel'ах, лечилось шаманством типа поочерёдного передёргивания каждого линка в бандле)

 

В случае применения QoS по его прямому назначению, эти баги: а) могут проявиться только в редких случаях аварий на сети; б) даже если проявились, то таки авария, форс-мажор, ну не повезло. Последствия кривизны реализации QoS в случае штатного дропания левого трафика, надеюсь, объяснять не надо ;)

[zi_rus]

Про это и был мой вопрос ;)

Так как Вы взялись на него ответить, то следовало предположить, что Вы - знаете

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

что-то я пару последних дней не в себе, сначала говорю, а потом думаю

 

тем не менее, я настаиваю что по приведенной мной ссылке находится именно та возможность Cisco IOS, которая, при должном применении, позволит сделать то о чем идет разговор

[evd]

можно как-нибудь поподробней описать что делает оператор, читер и что из этого получается?

Конкретный пример с эмоциями можно почерпнуть в одной давней теме

 

С тех пор много чего изменилось, но секс в извращённой форме любовь к морспецификам вечна ;)

[Savaoff]

Кстати дропать на аплинковских портах размеченный средствами qos'а как "с ix'а" трафик необязательно, можно сильно зажать его. Легальные юзеры пожалуются, если в результате глюков qos'а их трафик зажмется, если заметят, конечно. Нелегальные точно заметят и им это вряд ли понравится.

Изменено 10 марта, 2012 пользователем Savaoff

[nuclearcat]

 

Дальнейшие ваши уточнения, извините, цитировать не буду. В качестве решения не совсем корректно (imho) поставленной задачи Вы предлагаете более чем сомнительный механизм. Который, в идеале, должен спасать "дорогую" часть трафика в аварийных ситуациях. На практике же - содержит неприличное количество софтовых багов. Вплоть до перекрашивания пакетов случайным образом (конкретно, наблюдал такое на агрегатах/etherchannel'ах, лечилось шаманством типа поочерёдного передёргивания каждого линка в бандле)

 

В случае применения QoS по его прямому назначению, эти баги: а) могут проявиться только в редких случаях аварий на сети; б) даже если проявились, то таки авария, форс-мажор, ну не повезло. Последствия кривизны реализации QoS в случае штатного дропания левого трафика, надеюсь, объяснять не надо ;)

На оборудовании какого производителя наблюдаются такие баги?

[magr]

Если бы вдруг MSK-IX решил заняться несвойственной ему функцией контроля валидности ip-трафика согласно п.13, то начинать ему следовало бы с того, что на пушечный выстрел не подпускать к точке обмена трафиком тех, кто не имеет возможности или желания держать на своём бордере full view. И записать это одним из пунктов ТУ. Потому что утекающие по морспецификам пакетики от "операторов эконом-класса", пролетающие через сеть его пира и затем вылетающие в его аплинки - это и есть тот самый левый трафик, который заставляет крупных операторов уходить с ix-ов. Об этом, в частности, говорил Янус чуть выше в этой ветке, imho излишне эмоционально, но по сути

 

Про очевидную полезность наличия full-view согласен. Можно и нужно ли это требовать со всех участников, и при каких условиях - вопрос, над которым опять подумаем.

 

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

Что касается темы "пункта 13" - еще раз, факты нужны, письменно сформулированные, для начала разбирательства. И разбор полетов будет не в контексте "несвойственной [iX-у] функцией контроля валидности ip-трафика", а в контексте соответсвия поведения участника тех.условиям IX-а по обращению от другого участника.

[evd]

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

Что касается темы "пункта 13" - еще раз, факты нужны, письменно сформулированные, для начала разбирательства. И разбор полетов будет не в контексте "несвойственной [iX-у] функцией контроля валидности ip-трафика", а в контексте соответсвия поведения участника тех.условиям IX-а по обращению от другого участника.

Magr, не травите душу

Разборки могут получиться кровавыми и многочисленными. И ничего кроме дополнительной озлобленности не дадут. Потому что формально прав как раз тот, кто льёт левый трафик. Он отсылает его на полученный от пира маршрут. А побочный эффект типа наличия в глобальной таблице морспецификов (нередко полностью перекрывающих агрегат), так в ТУ на этот счёт ничего не сказано, и вообще выбор best path - сугубо интимное личное дело каждого оператора

[st_re]

Я немного не понял? Я, вроде как, RS на MskIX пользовать вообще не обязан, соответственно прямые пиры возможны ? Откуда следует, что админы MskIX понятия не имеют об том трафике, который там вполне валидно может ходить (по крайней мере без доброй воли на то участников).. Теоретически там вообще не обязана быть BGP сессия. А трафик по обоюдному согласию ходить с 10.1.2.0/24 на 172.18.11.0/24 и обратно. Или купить там аплинк-lite, с хождением 0.0.0.0/0 с одной стороны. А уже участник вполне может себе представлять, что и кому он анонсит, и что и откуда ждет. Максимум, что мог бы сделать MskIX- фильтровать по просьбе участника, ежели есть таковая возможность-желание.

[evd]

На оборудовании какого производителя наблюдаются такие баги?

Наблюдались. На платформе, от которой меньше всего это ожидалось: Juniper MX с не самой удачной версией JunOS, с гуляющим поверх агрегатов mpls и множеством факторов, которые могли способствовать вылезанию на поверхность данной баги. Впрочем, эта конкретика ни о чём. Безглючных реализаций QoS встречать не приходилось. Пусть себе живёт в качестве соломинки для утопающего, степенью ненадёжности которой можно пренебречь при наличии спасательного жилета ;)

[DelSt]

Наблюдались. На платформе, от которой меньше всего это ожидалось: Juniper MX с не самой удачной версией JunOS

Это которая иногда начинает дропать 100% исход. трафика на порту карты MPC-3D-16X10GE и помогает только перезагрузка карты? =)

Наслышаны о надежности этой платформы - сначала несколько раз проявился этот баг у нас, потом также несколько раз у level3, а недавно снова 2 раза подряд у нас :) Держим руку на пульсе ;)

 

p.s. Хотя не спорю - железки cisco говно того же порядка

Изменено 11 марта, 2012 пользователем DelSt

[evd]

Это которая иногда начинает дропать 100% исход. трафика на порту карты MPC-3D-16X10GE и помогает только перезагрузка карты? =)

Но зато ~60 Mpps прожёвывает не поперхнувшись. И нет никаких сомнений, что прожует и больше, со всеми фильтрами, фаерволами, бридж-доменами, флоу-рутами, малтикастом, v4+v6, терминацией тонких vpn'ов, в т.ч. vpls, и прочей сопутствующей требухой. На MPC, понятное дело. DPC с его плотностью портов не позволяет железке разогнаться

 

Не без глюков, конечно, но они в своём подавляющем большинстве софтовые, а значит поддаются лечению апгрейдом JunOS. Эта сторона MX&MPC пока далека от идеала, увы. Но - исправляются

[Savaoff]

Касательно необходимости FV при подключении к msk-ix (за другие ix'ы не скажу).

У нас был клиент, даже два, работающий по схеме - имея свою AS включиться в msk-ix, а от нас получить только default. Экономили на железе. Через какое-то время появились жалобы на связность. tcpdump/netflow помог - оказывается, среди клиентов msk-ix полно таких, которые:

 

1) анонсируют на msk-ix крупный блок, например /16

2) анонсируют своим АПЛИНКАМ несколько /24, находящихся внутри этого /16

3) эти /24 на msk-ix НЕ АНОНСИРУЮТ

4) более того, трафик к этим /24 через msk-ix НЕ ПРОХОДИТ, в то время как к остальным сеткам из этого /16 может и проходить

 

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

 

Вывод - при подключении к msk-ix необходимо BGP full-view.

Изменено 12 марта, 2012 пользователем Savaoff

[alks]

 

4) более того, трафик к этим /24 через msk-ix НЕ ПРОХОДИТ, в то время как к остальным сеткам из этого /16 может и проходить

 

 

Можете этот момент поподробнее осветить?

я а ix-ах не присутствую, просто интересно.

Изменено 12 марта, 2012 пользователем alks

[magr]

3) эти /24 на msk-ix НЕ АНОНСИРУЮТ

 

Думаю, не менее часто анонсируют, точнее пытаются. Но при этом, не удосуживаются проверить, что такой анонс будет принят роут-сервером (существование роут-объектов и т.д.).

 

Со своей стороны стараемся облегчить прозрачность процесса, на публичном looking glass уже довольно давно сделали отдельную вкладку, отображающую отвергнутые анонсы любого участника. Некоторые замечать стали.

Изменено 12 марта, 2012 пользователем magr

[Tosha]

Господа, провайдер же в первую очередь защищает от попыток слать пакеты от имени другого абонента - соседа, чтобы этому соседу трафик не зачелся в счет. Или чтобы пакет не попал в шейпер соседу, отъедая его купленную полосу.

 

Делается это белым списком на порту абонента или иными технологиями (привязка по ответам DHCP или контролем обратного маршрута).

Абонент может использовать только свои адреса и вопрос принципиальный.

 

Прописать в разрешение чужие адреса не всегда технически возможно в принципе. Зачастую же применяется контроль на основе DHCP ответов!

А если технически можно - нельзя по моральным соображениям!

 

В общем - нельзя! Если работает - то из-за попустительства и без гарантий.