buckethead

В данном случае ASR.

Это достаточно очевидно, и аффектит не только банк-клиенты. PAP очень нужная вещь.

Приведите, пожалуйста, пример, при котором в данной конфигурации может возникнуть роут луп. В текущей конфигурации. Тсс. Это следующий этап. Читать про BCOP и MANRS. Конкретика то будет? Это же vlad11, какая конкретика?

Всё там работает.

Я коротко выше описал, почему всё в одну коробку засовывать не стоит. Это проблемы с масштабируемостью, отказоустойчивостью и поиском проблем. Пока вы очень маленький, но гордый, не побоюсь этого слова, оператор, такой вариант кажется "удачным решением" с точки зрения финансов, особенно когда железо покупается с рук и без сервиса. Люди и не на таком говне строят и работают, но это не повод называть такие схемы "наилучшими".

Я бы не стал делать isp-in-the-box вообще, и тем более на ASR1k. На таком количестве фич, когда esp будет уходить в очередной крэш, для любителей покупать железо у торговцев чёрным деревом траблшутинг превратится в мольбы "не надо так, прошу". На мой взгляд уж лучше действительно набрать 65/76, брасы на тазиках, разделить задачи между железками и копить, копить на нормальный сетап. Это абсолютно неправильная схема.

На мой взгляд это серьёзное упрощение, основанное на дословном переводе. Так-то оно так, все мы пиры, но реальная бизнес логика, а за ней политика маршрутизации не всегда отражает перевод этого термина. Есть хороший драфт от qrator, в котором описываются более-менее актуальные представления о текущей структуре взаимоотношений между AS. https://tools.ietf.org/html/draft-ymbk-idr-bgp-open-policy-00 Например, Tier-1 операторы между собой пирятся и, что главное, бесплатно. А если ты хочешь через одного из них, например, получать сети другого -- это уже отношения Customer-Provider, как я понимаю.

Навскидку, с базовыми линейными картами не поддерживается VPLS (есть только на SUP-2T), нужна карта ES или велосипед (по нынешним меркам) с SIP/SPA с ограниченной производительностью. На ES картах VPWS можно принимать на SVI и с локальной коммутацией в вилане, на линейных картах VPWS работает только на субинтерфейсах. ES карты в 65е шасси не становятся (судя по документации на сайте Cisco). Новые карты стоят как несколько б/у MX80. Данное поведение достаточно известное и сохраняется как для 65, так и для 76, если мы говорим о старом поколении супов, с 40G на слот. 2T все таки значительно отличается, сравнивать 7600 и 6500 на стероидах не совсем честно.

В треке CCIE нет ни слова по аппаратным платформам 6500/7600. О разнице в mpls фичах на базовых картах и SUP'х между коробками не слышал. По NAT вроде есть какая-то FW карта ASA-подобная, на ней что-то можно было сделать, но не уверен, что в 6500 она подойдёт, возможно только в 7600.

И сколько примерно гигабит прокачает WS-SUP720-3BXL / WS-SUP720-3CXL на шасси 6500? ( все выключено, BGP включено , 3 10г в аплинков , 1 10 ( вопрос выходящий за рамки обсуждаемого проекта , для общего понимания ) а если с NAT ? Коробка обещает до 720Gbps, но есть ооооочень много нюансов с фабриками, каналами, их переподпиской, буферами на 10G картах, ограничениями FPGA/ASIC и прочими радостями. Железо достаточно старое и капризное. 3BXL/3CXL даёт больше всяких netflow записей, возможностей для ACL, QoS и так далее. На производительность они не влияют напрямую. Про NAT я бы сразу забыл. Там он есть, но лучше бы его не было. CG-NAT там нет.

То есть если WS-SUP720-3B воткнуть в 6506-E шасси, то там тоже будет иос? А в чем тогда вообще на сегодняшний лень разница между 6500 и 7600? Не в плане производительности, а в плане фич. 76хх можно настроить так ethernet/mpls агрегатор например... 65 нельзя Что такого из коробки без, например, ES карты, 76 умеет в плане mpls, чего 65 не умеет?

P.S. Да, скорее всего 15 IOS вас полностью устроит по фичам. То есть если WS-SUP720-3B воткнуть в 6506-E шасси, то там тоже будет иос? А в чем тогда вообще на сегодняшний лень разница между 6500 и 7600? Не в плане производительности, а в плане фич. Даже если в SUP'е будет CatOS, то он спокойно выпиливается, и ставится IOS, есть оф.гайды от Cisco, как это сделать. Разницы никакой между этими железками практически нет. Разве что 7600 EOS, а 6500 ещё на стероидах продаётся. В 7600 есть карты, которые не поставить в 6500, но вам они, скорее всего, ни к чему. По базовым фичам разницы нет.

А какую ос при этом на него можно залить? только IOS? или CatOS тоже? а в чем между ними разница? CatOS не нужен, это пережиток прошлого. То есть в 15-ом IOS есть все, что может понадобится на ядре? А ISG например есть ( ну вдруг ) ? Вы предполагаете рост fulltable более 1млн префиксов? В ближайшие 5 лет? Если смотрите в сторону ISG, то точно нужно задумываться об ASR1k. На счёт 1kk не знаю, но сколько TCAM на 65/76 с перераспределением выходит? Если миллион, то ещё можно подумать.

Вот этого не знал, благодарю!

Шасси ничем не отличаются, LAN-карты кросс-шасси, WAN-карты, всякое FW и прочие не аеспи извращения вам, как я понимаю, не нужно. SUP'ы переставить, скорее всего не получится, на 7600 нужен RSP720. Не забивайте себе голову, если уж вы собрались в 2017 эти обноски на сети ставить, то хоть с IOS не мудрите. Нужен бордер -- ставьте 12 IOS, будет больше памяти под RIB, для всех остальных случаев ставьте 15 IOS. Алсо, не помню, сколько там TCAM, но "на годы" вам этого точно не хватит, потому что FullTable растёт, а TCAM на этом старом утиле -- нет.

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/107258-C6K-PFC-DFC-CFC.html

Сам SUP и все CFC карты вместе взятые прокачают не более 30 Mpps. DFC карты считаются отдельно и там, вроде 400 Mpps на карту, но могу ошибаться.

А это разве не разные слоты? 3 и 4? Если вопрос ко мне, то ещё раз внимательнее читаем, что я написал -- на разных картах, а не слотах. Речь о моделях, а не номерах карт. На эти 99% можно не обращать внимание. Мы разнесли эту нагрузку на другое оборудование. 100% нет, я бы заметил.

И что вы этим хотите мне показать? У меня в первом посте lag, собранный на картах, расположенных в разных слотах 7609. Но это всё одни и те же карты -- WS-X6708-DFC3C. Мы тоже не собираем lag на подряд идущих портах и о расположении каналов на картах осведомлены. Из 8 используются лишь 4, для карты жёстко задан no hw-module slot X oversubscription, используются лишь 1,2 и 5,6 порты. Так что дело явно не этом.

эт ещё почему? Ну наверное потому, что одни карты CFC, другие DFC. http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/channel.html На практике это даже не всегда собирается, появляются Port-channel X и Port-channel XA или XB. Иногда собирается, но убивает фабрику SUP'а. В общем я бы не рекомендовал такой сетап.

Mod Sub-Module Model Hw Status ---- --------------------------- ------------------ ------- ------- 1 Centralized Forwarding Card WS-F6700-CFC 4.1 Ok 3 Distributed Forwarding Card WS-F6700-DFC3C 1.6 Ok 5 Policy Feature Card 3 7600-PFC3C 1.2 Ok 5 C7600 MSFC4 Daughterboard 7600-MSFC4 1.4 Ok 6 Distributed Forwarding Card WS-F6700-DFC3C 1.5 Ok 7 Distributed Forwarding Card WS-F6700-DFC3C 1.0 Ok 8 Centralized Forwarding Card WS-F6700-CFC 4.1 Ok 9 Centralized Forwarding Card WS-F6700-CFC 4.1 Ok Все модули одинаковые и DFC к ним -- тоже. На разных картах LAG не собирается. У меня пока идея -- всё в третью линейную карту вставить, смущает меньшее redundancy, но хотя бы в качестве теста.

Конечно. На ПЧ простой преимущественно unicast tcp/udp абонентский трафик к различным внешним и внутренним ресурсам. Mcast'а нет кроме, возможно, служебного. Что-то ещё более конкретное сказать тяжело, всё best effort, qos не используем, не знаю, что ещё.. Прикрепляю графики нагрузки всех четырёх интерфейсов. Можно соотносить к графикам загрузки фабрик, например, на третей линейной карте всего два порта заняты, оба из этого ПЧ и графика. А вот, для сравнения графики всех каналов третей фабрики. Трафик на двух портах in/out разный по объёму, это видно по графикам нагрузки портов, а на фабрике всё один в один, и это меня удивляет. Input утилизация совпадает и не проваливается, output -- оба канала (порты на разных каналах, разумеется) чертовщина. И так на каждой LC, где есть порты из этого LAG.

Нет, SPAN не используется, NetFlow тоже. Об этих замечательных инструментах и их воздействии на 65/76 известно на собственном опыте)

К сожалению, такой команды нет, видимо, IOS староват:

c7609-s#show platform hardware capacity fabric Switch Fabric Resources Bus utilization: current: 10%, peak was 17% at 21:24:05 SKH Thu Feb 2 2017 Fabric utilization: Ingress Egress Module Chanl Speed rate peak rate peak 1 0 20G 3% 9% @18:53 02Feb17 4% 13% @12:27 02Feb17 1 1 20G 0% 5% @03:08 06Feb17 2% 11% @12:40 02Feb17 3 0 20G 15% 61% @21:44 03Feb17 17% 73% @20:27 03Feb17 3 1 20G 18% 61% @21:34 02Feb17 17% 72% @20:36 02Feb17 5 0 20G 2% 4% @16:49 02Feb17 0% 5% @21:13 05Feb17 6 0 20G 30% 51% @21:32 03Feb17 42% 82% @20:05 03Feb17 6 1 20G 17% 47% @21:29 02Feb17 37% 99% @19:56 02Feb17 7 0 20G 38% 76% @21:31 03Feb17 17% 74% @21:05 02Feb17 7 1 20G 23% 86% @21:37 03Feb17 3% 13% @21:22 03Feb17 8 0 20G 5% 49% @22:12 02Feb17 18% 41% @21:27 03Feb17 8 1 20G 0% 42% @21:49 03Feb17 0% 13% @21:01 03Feb17 9 0 20G 9% 21% @22:37 04Feb17 43% 72% @20:42 02Feb17 9 1 20G 2% 4% @20:31 02Feb17 4% 14% @20:16 02Feb17 Switching mode: Module Switching mode 1 compact 3 compact 5 compact 6 compact 7 compact 8 compact 9 compact c7609-s# Статистика актуальна после 3 февраля, до этого интерфейсы были расположены иначе и с другой нагрузкой, часть которой вынесли 3 числа с 7609 из-за перегрузки одной фабрики.