evd

Ok. Тогда вопрос: что есть "оптимальный путь" и куда он ведёт? :) Морспецифик - это частный случай. Более обще оно формулируется так: клиент отдаёт Вам не все те свои маршруты, которые светит вовне. Какие-то префиксы (не обязательно морспецифики) по каким-то причинам он, нехороший, анонсит только вашему конкуренту. Далеко не экзотический случай. А другие ваши клиенты, которым Вы обязаны обеспечить полную связность, шлют, негодяи, пакетики и на эти префиксы тоже. Этот трафик - паразитный или как? А оптимально - это когда за один и тот же трафик Вы берёте денюжку дважды, и с отправителя, и с получателя? ;) Смысл статьи - как избавиться от кросс-пирингового трафика. Смею утверждать, что других смыслов там нет

Ok. Уточним предмет разговора. Пир или апстрим отправляет к Вам трафик на клиентский лесспецифик, потому что морспецификов он не видит. Причина не имеет значения. То ли это клиент намеренно или случайно криворук, то ли, скажем, пир экономит на памяти для full view на своём бордере, не суть. Вы следуете логике пира/апстрима и отправляете трафик к клиенту по его лесспецифику. Обманутых и обиженных нет. Пакеты улетают ровно тем маршрутом, который предполагался их источником Ваша "оптимизация" неявно предполагает нечто обратное: светить клиенту морспецифики в составе full view, а влетевший от него трафик отправлять по лесспецифику. К затронутой в этом топике теме оно не имеет никакого отношения

Буквально первый пост в обсуждении статьи - ваш. Цитирую: Что случилось с этим вашим пониманием? Трафик от клиентов куда бы то ни было вовне не является предметом обсуждаемой статьи

И как из этих vrf'ов нарезать full view, который попросит multihomed клиент? А в Looking Glass какой из vrf'ов светить? :o А памяти PFE маршрутизаторов под эту красоту не жалко? Табличка маршрутов на пиринге может оказаться вполне сравнимой по размерам с full view Для полноты картины FYI: оператор, для которого транзит не развлечение, но хлеб насущный, будет бороться за каждый as-хоп в as-path. Порезанная на кусочки bgp-таблица этому никак не способствует

Завернуть пакет в vrf - это разве не "заставить железку сделать еще один lookup"? Альтернатива ихде? ;)

А есть альтернатива? Вообще-то речь изначально о кросс-пиринговом трафике. Клиентов эти ограничения не затрагивают ни разу, их исходящий трафик отправляется ровно туда, куда показывает bgp. Если по морспецифику в ix или в аплинк, значит так тому и быть, это их святое право

Правильно кажется :) Механизм ровно тот же, что описан в статье. Надо только поменять цель: не дропать, а отправлять в клиентский лесспецифик (if any)

Imho надо бы чуть по-другому: глупо ломать себе связность морспецификами, с невинным видом объясняя своим энд-юзерам, что-де все беды от криворукого аплинка. И в качестве доказательства демонстрируя трейсы в его сторону, но "забывчиво" обходя стороной вопрос об обратном маршруте :) А "залётный" от пира трафик, для которого нет вообще никаких клиентских маршрутов, в т.ч. less-specific - да, блокируется. Пирам (как, впрочем, и аплинкам) гарантируется связность только с клиентами

Более того, практика несколько устарела. ReTN уже очень давно от неё отказался, отправляя кросс-пиринговый трафик по less-specific маршруту в стык с клиентом, без сизифовой работы по фильтрации морспецификов. В итоге и волки не голодные, и овцам нет повода для обид :)

В скетче забыто: над каждой больничной койкой висит видеокамера круглосуточного наблюдения :)

Хм @RT.IAD.HKG> show pfe statistics traffic | match pps Packet Forwarding Engine traffic statistics: Input packets: 38545613579366 11785967 pps Output packets: 38530288676566 11766443 pps MX104 в далёком Гонконге, где старшим MX'ам пока делать нечего. Для PFE MX104 это не нагрузка. Вот RE там слабоват, да. Но залить в него "паразитный трафик" при наличии фильтров не должно бы получиться :)

aut-num: AS60926 as-name: DC-AS org: ORG-DC52-RIPE organisation: ORG-DC52-RIPE org-name: OOO "Defense Center" Ключевое здесь "defence". Среди клентов ReTN есть несколько операторов, специализирующихся на защите от DoS-атак. А среди их клиентов случаются и его непосредственные downstreams. Будь то банальный route leak - прямые анонсы Релкома в ReTN выигрывали бы по длине as-path Второй случай больше похож на route leak по довольно часто встречающейся причине "это клиентский префикс, отдам его вовне, а что он получен вовсе не на стыке с клиентом - проблемы индейцев". Imho шериф в исходном сообщении угадан правильно

Воспользуюсь затишьем, чтобы вернуться к топику Если задаться вопросом "а как?", то в голову приходит только RFC 6811, для внедрения которого тот же JunOS, например, вполне готов. Пусть даже обязаловка, но ни разу не отмена bgp. Imho не так страшен чёрт :)

Спасибо на добром слове. Но правильнее было бы сказать не "снова", а "впервые". Пока не было короткого маршрута в Гонконг - не имело смысла поднимать там стык с NTT

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