mightyscv

ну так это оно и есть. ставя букву L вы указываете, что это формат 4byte:2byte других применений я не знаю. если вам расскажут - поделитесь

есть два формата RD 4byte:2byte 2byte:4byte я ставлю RD 1:1 как системе узнать какой формат я подразумеваю?

я, конечно, всю теорию уже забыл, но BGP же анонсирует соседу только лучший маршрут из всех которые есть в таблице значит ваш iBGP 0/0 лучше чем eBGP 0/0, что само по себе парадокс так как iBGP AD хуже чем eBGP AD. попробуйте в эту сторону глянуть

А зачем у вас на клиентском интерфейсе PIM в активном режиме вообще? Это в принципе неправильно, к клиенту hello не должно быть - он же может включить у себя PIM, и начать вам что нибудь слать.

Предлагаю ещё месяц подождать - глядишь и гиг на доступе под сомнение попадёт.

Saab95 Это не так. Все проблемы MAC-адресов(совпадения, хэш коллизии, лимиты размера таблиц коммутатора) остаются, просто они локализованы в L2 сегменте, который включен в PE. Собственно все те же самые проблемы будут если вместо PE у вас непосредственно BRAS. Да и вообще, PWHT(я надеюсь мы про него говорим?) не для этого придуман. Он решает задачу "как бы нам завести все наши L2 сегменты в один BRAS в MPLS-сети, и при этом иметь все плюшки MPLS?", потому что без PWHT это решается через PW/VPLS, но с ограничениями. Необходимость строить L2 сеть доступа это не отменяет, про MPLS на доступе все только разговаривают, но на практике я о таких решениях не слышал, и вообще не уверен что кто-то control plane под это хотя бы написал(потому что никому не нужно). Ваша схема это то же самое, что я предложил, только вместо BRAS у вас предполагается PE и PWHT. Она прекрасно работает, просто это вопрос размеров оператора и требуемой ему масштабируемости.

feeman Не очень понял вопроса. Грубо говоря с обычным 802.1q вы пишете encapsulation dot1q 500 а с QinQ как-то так(команда может отличаться, главное принцип) encapsulation dot1q inner 500 outer 600 Надеюсь, логика понятна. Далее, руками это никто не прописывает. Используется dynamic vlan, пример конфигурации http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/isg/configuration/xe-16/isg-xe-16-book/isg-dyn-vlan.html Я лично на Cisco ASR этого не делал никогда, я это делал на Juniper MX. Но принципы везде одинаковые, и судя по тому что я нагуглил за 2 минуты, у Cisco всё это работает и поддерживается точно так же как и у Juniper, за исключением самих команд конечно.

Схемки красивой не нашёл, поэтому вкратце объясню суть.На доступ ставятся коммутаторы с минимальным мозгом. Порты к абонентам получают свой inner-VLAN, например с 101 по 124(для 24х портового коммутатора конечно). Порт наверх - транк. Это типовая конфигурация для всех коммутаторов доступа. Коммутаторы агрегации чуть поумнее, умеют QinQ, считают нижестоящих братьев QinQ клиентами, и вешают второй тег(outer VLAN) поверх первого, уникальный для каждого коммутатора. В итоге на BRAS к вам абонентский трафик прилетает с уникальным сочетанием 802.1q тегов, типа [100,110]. По этому уникальному сочетанию делается аутентификация и авторизация. В такой схеме можно иметь по грубой прикидке >4000 коммутаторов доступа, и ~96 тысяч абонентов(портов). Это уже не каждый BRAS осилит, да и коммутаторы с такой здоровой MAC-таблицей стоят негуманно(они кстати вообще есть? как-то подзабыл уже), но если надо больше, то вводите второе "поколение" коммутаторов доступа, порты которым метите уже другим набором вланов, например 201-224. Сочетание тегов опять уникально, хотя теперь в сети есть два коммутатора доступа, которым назначен один outer VLAN. В этом ничего страшного, но иногда можно запутаться. С другой стороны у вас уже под 200000 абонентов, и в этом случае у вас должно хватать выручки чтобы нанять пару CCIE, чтобы у них об этом голова теперь болела. Дальше можно сделать третье "поколение", четвёртое, и так пока пространство под inner VLAN на закончится. Теоретически - 4096*4096=16777216(больше 16.5 миллионов) портов, на практике столько в один BRAS никогда не терминируются, потому что BRAS таких мощных не бывает, и коммутаторов с такой MAC-таблицей уж точно нет, да и централизация безумная слишком. Эта архитектура решает, как минимум, следующие проблемы: - полная изоляция абонентов на L2. Никакие левые DHCP серверы проблем не создают, соответственно не нужен никакой DHCP-snooping, L2 фильтры, и прочее. Да, абоненты друг с другом общаются через BRAS(через proxy-ARP), но если вы будете СОРМ делать то вам это даже понравится; - упрощенная авторизация. Никаких DHCP opt-82 и прочих костылей - outer-VLAN,inner-VLAN, всё просто; - возможность продавать triple-play без особой головной боли. Интернет как интернет, телефонию как телефонию, телевизор с использованием STB и MVR; - при наличии свободных VLAN(я не знаю каким монстром нужно быть чтобы их не было) можно на той же сети продавать какие-то другие сервисы другим клиентам, например какой нибудь fixed IP юридическому лицу, или L2VPN; - упрощённая процедура замены коммутаторов доступа. Конфигурация типовая, отличается только hostname да IP. Если один сдох - можно тут же достать из зипа другой и заменить вообще без вмешательства поддержки. При наличии нескольких "поколений" коммутаторов достаточно иметь отдельный зип на каждое поколение, ну или привлечь поддержку для минимального тюнинга конфигурации; - минимизация вероятности хэш коллизий, что для простеньких коммутаторов иногда бывает критично. В такой схеме у вас каждый коммутатор доступа видит в влане только 2 MAC-адреса - BRAS и CPE. Агрегация видит побольше маков, но всё равно они хорошо размешаны по VLAN. Сюда же можно добавить приятным бонусом защиту от совпадения MAC(хотя я такого ни разу в своей практике не встречал) - теоретически вообще у всех абонентов может быть одинаковый MAC, форвардинг в сети идёт фактически по outer/inner VLAN тегам. Может что-то ещё, что я забыл.

За это деньги обычно платят. Иначе - communtity support, т.е. эта тема.

VTPv2 - старое зло. feeman Вы оператор связи? Используйте QinQ и VLAN-per-port архитектуру. Очень много проблем сразу решите. Ну или просто QinQ и влан на здание если на порт не подходит.

facepalm.jpg

Да. Вот пример - Это характерно для любых онлайн стрелялок.

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

Смешно наблюдать со стороны, как умные люди зачем-то пытаются изобрести велосипед. Или все тщательно скрывают своё геймерское прошлое, и делают вид, что не знают, что такое net_graph? Ни wireshark, ни tcp/ucd/icmp/самонакатанные_на_коленке_пакетные_генераторы не нужны, когда есть net_graph. Если в net_graph проблем не видно - с сетью проблемы нет. Точка. Умеет ли ТС правильно интерпретировать его показания - под вопросом. p.s. - видео так и не доставлено. Впрочем, пива я пока тоже не пил. Но в субботу планирую! ТС, смекаешь?

Сначала просто хотел отметиться в платиновом топике, но всё таки внесу каплю конструктива. Почему в игрушках UDP а не TCP? Потому что игрушки стремятся к realtime, насколько он возможен в человеческом восприятии. А в realtime важна концепция "лучше потерять, чем доставить с задержкой". Движение персонажа задаётся векторами - если вы потеряли несколько пакетов то это не страшно - вектора и скорость есть, движение можно предсказать с очень высокой точностью, причём делает это как сервер так и клиент. Ну и немного о механизме работы сервера. Он собрал с пользователей данные скопом - обработал - это и есть ваш "tick", разослал текущее положение дел, ждёт новых данных. Так и tick-tock'ает себе. Тут же решается и кто кого убил - выстраивается очерёдность действий("но я же первый выстрелил!"). Если ваш пакет пришёл уже после завершения тика из-за внезапной™ задержки - получается та самая "кровь хлещет а он не умирает", аки зомби. Для этого в нормальных играх есть параметр типа "использовать подтверждённые сервером данные(попадания)", чтобы клиент перестал выпендриваться и рисовал кровь только тогда, когда сервер это подтвердит. TCP не нужен так как не будете же вы ждать ретрансляции за пределами тика? Не успели данные прилететь - и пофиг, без них обсчитаем. Получается гарантированная доставка не нужна, а с ней не нужен и TCP. По этой причине шейпинг UDP - зло. Если вы оператор связи, и шейпите UDP - вы дебил, геймеры и пользователи VoIP передают вам пламенный привет. О диагностике. Самый верный метод - смотреть net_graph в игре, если таковой есть. Он скажет всю правду конкретно для игрового трафика. Если там джиттер не плавает и потерь нет - дело в голове. Насколько я понял из контекста - net_graph есть, да ещё и идеальный(поэтому я уверен, что дело в голове). Так что всякие iperf, ICMP, и прочие инструменты можно выкинуть за ненадобностью. Ну wireshark оставить разве что, он хороший. Если net_graph показывает лёгкую эротику, то wireshark - вскрытие. По итогу предлагаю ТС запилить стримчик, который никто смотреть не будет конечно же, поэтому лучше потом выложить запись на ютюбе или ещё где, с включенным net_graph и игровыми процессом с комментариями "вот, видели - вот тут лагнуло", итд. А мы заценим на выходных под пивко.

nuclearcat Чтоб так сходу не скажу причину, но есть мысли по процессу диагностики. Взять новые SFP, обязательно с DDM. По SNMP забирать с них оптическую мощность rx/tx, мощность mW, температуру. Запихать это в графики типа заббикса, и смотреть. Если есть деградация - вы её увидите на графике со временем. Возможно деградируют от перегрева. Давненько не трогал SFP в EX но память мне подсказывает, что они там весьма ощутимо могут греться - 50-60C.

s.lobanov Это гениально! Учитывая тенденцию(IPSec, DNSSEC, BGPSEC, etc) - вам надо срочно в IETF бежать с этой мыслью :)

SUrov_IBM Словами это можно как угодно описывать, а суть в том, что раньше владелец PI блока общался напрямую с RIPE NCC, а теперь он общается с LIR. В этом и была разница PI/PA. Передать свой PI блок через RIPE NCC было сложно, так как у них нет такой процедуры(кроме как через поглощение). По сути это была процедура возврата блока, и его дальнейшего перевыделения новой организации, с сопутствующим заполнением всех анкет и обоснованием необходимости. Сделать ту же операцию через LIR, особенно если вы сами и есть этот LIR - на порядки проще и быстрее. Да, PI статус по прежнему существует, и у него есть ограничение на невозможность дальнейшего деления, но это по сути несущественно, да и я думаю это отменят в будущем. pppoetest Маршрутизация про RIPE и его объекты ничего не знает в принципе, и работает по алгоритму выбора лучшего маршрута. В вашем случае оно на первом же пункте упрётся в правило more specific - из двух одинаковых маршрутов выбираем тот, у кого маска короче(более специфичная). Это на самом деле даже относится не к алгоритму выбора маршрута, а напрямую к операциям форвардинга. Здесь стоит сделать небольшое отступление - если ваш короткий префикс где-то не примется, то трафик оттуда будет идти в сторону длинного префикса. С технической точки зрения у PI блоков был иммунитет - для них не бывает никакого more specific префикса кроме 0/0, и в этом случае если кто-то этот блок не принимал то у него просто не было маршрута. В такой ситуации если ваш блок часть PA оператора, то рекомендуется иметь с этим оператором BGP стык - в этом случае трафик придёт к этому оператору в его less specific, а он уже отправит трафик в ваш more specific. Из личной практики - с префиксом длиной /24 без стыка с его less specific оператором никаких проблем со связностью не было. Но я не исключаю, что для префиксов короче(/25 и короче) это может вызвать проблемы со связностью.

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

myst Не понимаю. Пример привести можете?

myst sh route <prefix>/<length> all sh route <prefix>/<length> hidden итд Указывая <prefix>/<length> вы получите все специфики, входящие в этот префикс. Возможно пора уже почитать документацию по JUNOS CLI?

myst Где-то в этот момент обычно люди понимают, что не надо пользоваться конструкцией sh route | match, а надо sh route <prefix>/<length>

Да. Возможно в packet mode режиме выдаст больше, но тогда попрощайтесь со всеми функциями фаервола. Ещё можно попробовать убрать "ненужное", например screens. Логика простая: чем меньше SRX фаервол - тем больше пропускная способность.

Мы тут немного в оффтопик скатываемся, но всё же. myst Из описания вашей проблемы я так понял, что у вас next-hop один. Тогда принципиальной разницы между next-hop и next-vrf стилем нет, чуть больше конфигурации разве что. Зато я вспомнил какую задачу стилем next-hop не решить - когда требуется динамическая маршрутизация для резервирования например. Указав next-vrf можно очень гибко ликать в него маршруты из динамических протоколов, вплоть до LSP. С next-ip стилем этого сделать нельзя по очевидным причинам.

Сам спросил - сам и ответил. Оказывается с 12.2 можно и next-ip указать. Я так понимаю что пока что не на всех платформах. http://www.juniper.net/techpubs/en_US/junos15.1/topics/topic-map/filter-based-forwarding-policy-based-routing.html myst Это в принципе вопрос предпочтений и контекста конкретной задачи. Если разных next-hop много то создавать отдельные VRF для каждого, конечно, неудобно. Но обычно такая ситуация это уже повод задуматься о правильности дизайна.