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 и игровыми процессом с комментариями "вот, видели - вот тут лагнуло", итд. А мы заценим на выходных под пивко.