dimzerman

Разобрался, ответ - ip proxy arp. Хосты из secondary сетей могли общаться между собой, но не видели шлюз.

Добрый день! Пробую реализовать раздачу адресов через ip unnumbered на Cisco Nexus9000 C9372PX. Для этого я создал интерфейс Vlan111 с подсетями, т.к. Нексус не позволяет в качестве unnumbered для интерфейсов vlan использовать loopback. И всё работает, но только если на Unnumbered интерфейсе одна подсеть. Если я добавляю secondary подсети, то на них этот функционал не работает, только на primary подсетке. Вопрос: Нексус не поддерживает несколько подсетей на одном Unnumbered интерфейсе, или нужны дополнительные настройки? Текущие настройки: interface Vlan99 no shutdown no ip redirects ip unnumbered Vlan111 interface Vlan111 description ---IP-unnumbered--- no shutdown no ip redirects ip address 192.168.7.1/24 ip address 192.168.8.1/24 secondary При таких настройках 192.168.7.0/24 подсеть работает, а 192.168.8.0/24 нет.

большое спасибо за информацию!

А там же всё написано. Дежурная служба ЦМУ ССОП сделает рассылку со своего почтового ящика noc@cmu.gov.ru, где будут указаны префиксы и AS, в которой эти префиксы были созданы. В свою очередь, нам нужно будет создать фильтр для всей AS или для отдельных префиксов. На Cisco ASR всё довольно просто, можно сделать так: Для запрета всех префиксов от AS: ip as-path access-list 1 deny _Num$ ip as-path access-list 1 permit .* Вначале запрещаем все маршруты, которые создала AS с номером "Num", затем разрешаем анонсы от всех других AS. Ну а фильтр отдельных префиксов через prefix-list. Применяем к bgp-соседу, soft reset, и, скорее всего, пишем отчёт в личном кабинете или на почту.

Приветствую! Сеть представляет собой большой L2-сегмент, в котором функционал BRAS и NAT лежал на BGP-router, авторизация по протоколу PPPoE. Решили установить Accel-ppp сервер для функций BRAS и NAT, убрав пользовательские vlan с BGP-router. Одновременно с этим, вводим Qinq с архитектурой Vlan-per-switch, S-Vlan на агрегацию. Это необходимо, т.к. сегмент настолько большой, что для Vlan-per-switch не хватит свободных vlan, да и в будущем планируем переход на IPoE. Коммутаторы агрегации добавляют вторую метку vlan с таким же типом, как внутренняя метка - 802.1Q (0x8001). На транзитных коммутаторах агрегации включена поддержка Jumbo-frame,но на самом ядре (SW1 - Cisco Nexus 9k) MTU интерфейса в сторону агрегаций и сервера Accel-ppp составялет 1500 байт. У сервера Accel-ppp в PPPoE MTU и MRU установлены 1480 байт. Авторизация происходит, тестовые абоненты работают, сайты грузятся. Сейчас система в отладке. Но понятно, что MTU нужно привести в порядок. Возникло несколько вопросов: 1. Если всё и так зацепилось, нужно ли в таком случае изменять значение MTU на интерфейсах коммутатора ядра SW1 в сторону Accel-ppp и агрегаций? Как многие советуют, хотя бы до 1504 байт. Если нужно, достаточно ли просто активировать Jumbo-frame на этих интерфейсах? 2. Что входит в значение MTU интерфейсов у cisco? Я читал, что MTU = Hardware MTU = IP MTU = [ip-header] + [tcp-header]+ [payload], но мне не понятно, почему это работает с двумя метками и pppoe. Интерфейс по факту может передавать большее значение, чем Hardware MTU? 3. Насколько целесообразно включать Jumbo-frame на агрегациях и ядре с транковыми линками 1Gb/s и 10Gb/s? Есть ли польза. Читал, что 10Gb/s недостижимы без поддержки Jumbo-frame.

Спасибо за статью. Как оказалось, в моём случае нужно выделить память для e-qos. Но есть проблема. Я поджимаю регион, например hardware access-list tcam region vpc-convergence 0 И при попытке hardware access-list tcam region e-qos 256 всё равно ругается на нехватку места. Пробовал так же поджимать регион racl 256, вместо стандартных 512. Как правильно выполнить эту операцию в моём случае? Не могу найти подробного пояснения по теме tcam carving.

Приветствую! Разбираюсь с Cisco Nexus9000 C9372PX, NXOS: version 9.3(8). Настроил несколько портов в транк, создал 80 штук vlan. Используются interface-vlan. После подключения, порт переходит в состояние UP, но тут же в логгинге появляется ошибка: %ETHPORT-5-IF_SEQ_ERROR: Error ("TCAM region is not configured. Please configure TCAM region and retry the command") communicating with MTS_SAP_SPM for opcode MTS_OP C_ETHPM_PORT_LOGICAL_BRINGUP Порт в UP, но мак адресов никаких не транслирует, хотя должен, т.к. на нём много абонентов. И если посмотреть состояние влан по команде sh interface status err-vlans, напротив активного порта будет TCAM region is not configured. Please configure TCAM region and retry the command . Я так понимаю, нужно изменять параметры в TCAM, но не могу найти, какой конкретно. Подскажите пожалуйста, как решить проблему. И вдогонку, на Нексусах часто нужно мониторить и корректировать TCAM для процессов?

Приветствую! Поделитесь, пожалуйста, своим опытом, кто использует их в операторской среде. Реализована ли у него Selective QinQ? Выбираем коммутатор для агрегации с функционалом L3. Какие подводные камни, возможно, встречали. Или же, на какие аналоги стоит посмотреть?

Хорошо, попробую поиграть с препендами, спасибо за советы. А можно ли сделать так, чтобы трафик клиентов, например из сети /28, отправлялся и приходил через однго и того же провайдера? А то возникают ситуации, когда до игрового сервера вчера был пинг один, сегодня другой, и выясняется, что человек просто работает то через одного провайдера, то через другого. Либо, если нельзя, насколько будет правильно, если я просто буду им с помощью Route-map указывать нужный next-hop, это сильно исправит ситуацию? Интересно, как это работает у других.

К сожалению, я не смог найти подобного решения на форуме, поэтому создал новую тему. Имеем ASR1001-X, свою AS, сеть /22 и стыки с двумя магистральными провайдерами. Было необходимо настроить распределение входящего трафика между двумя провайдерами, в идеале 50:50, или около того. В качестве временного решения, общая сеть /22 была анонсирована обоим провайдерам, от обоих провайдеров получаем fullview, используется bgp bestpath as-path multipath-relax. Настройки bgp для обоих провайдеров идентичны. Сейчас входящий трафик делится примерно 70:30, и первый провайдер всегда пересылает больше трафика, чем второй, даже если очистить маршруты от первого, и получить их заново, всё равно распределение остается таким же (я думал, что принцим "чем старше маршрут, тем он предпочтительнее" будет работать, но нет). Сейчас стоит задача приблизится к распределению входящего трафика 50:50. Была идея разделить /22 на четыре подсети /24 и по паре отдать каждому провайдеру, но в каждых из четырех сетей есть NAT, и должна быть возможность клиентов за NAT перенаправлять либо через первого, либо через второго провайдера, и, в случае жесткого деления, так сделать не получится. Так же, нет гарантии, что трафик, отправленный в первого провайдера, вернётся именно через первого провайдера, а не через второго. Таким образом, есть ли возможность обеспечить клиенту отправку исходящего трафика и получение входящего трафика только через одного провайдера (например первого), для подсетей меньше чем /24? Тогда была бы возможность более детально распределить трафик. А, при необходимости, поменять первого провайдера на второго? Я так понимаю, это Route-map, но боюсь, что будут возникать ситуации, когда исходящий трафик клиента ушел в первого провайдера, а входящий трафик для этого же клиента пришел через второго.

К сожалению, 2950 Restricted TCN не умеют, но идея интересная) попробую всё-таки с разными регионами вариант, пока ничего лучше не нашел

Спасибо, почитаю, попробую)

А есть ли какие-то ограничения на кол-во коммутаторов в регионе MSTP? Например, у меня может быть 50 коммутаторов на агрегацию (коммутаторы всех колец суммарно, включая агрегацию), будут ли они нормально сходиться в регионе при таком количестве?) В данный момент ядро и все агрегации находятся в одном регионе. Я думаю сделать каждую агрегацию в своём регионе.

спасибо за информацию, попробую проверить на стенде)

Господа, я всё пытаюсь выжать что-то полезное из сложившейся ситуации) Решил вынести это в отдельную тему, не могу найти информацию, возможно ли вообще сотворить такое, или нечто подобное. Сеть провайдера представляет собой большой L2 сегмент, примерно 200 коммутаторов. В основном используются коммутаторы SNR-S2950-24G, в агрегациях SNR-S2970G-24S, ядро - Mikrotik CCR1036-12G-4S. В сети много колец, максимально из 16 коммутаторов. На агрегации может быть несколько (2-6) колец. Агрегации L3 не умеют, поэтому абоненты по L2 тянутся аж до ядра. Vlan управления в данный момент один на всю сеть (200 коммутаторов). Планирую разделить Vlan управления по одному на агрегацию. Для контроля линков в кольцах исползуется RSTP, и при перестроении некоторых особо больших колец происходит рассылка на весь L2 сегмент о том, что топология изменилась, и на несколько секунд парализуется сеть, а иногда возникают широковещательные шторма. Некоторые линки приходится выключать/включать вручную, т.к. RSTP срабатывает некорректно. Для контроля за кольцами было бы хорошо MRPP/ERPS, но не все коммутаторы его умеют, в сети частенько встречаются Dlink 3526. Всё, что я придумал, это поместить агрегации вместе со всеми их кольцами в MSTP-Регионы, и тогда перестроения внутри региона не будут распространяться дальше этого региона. Но всё равно изменения топологии в одном кольце будет озвучено на все коммутаторы в пределах региона (на все коммутаторы в пределах агрегации). Можно ли как-то изолировать Topology change тем кольцом, в котором это происходит? Чтобы кольца никак не реагировали на изменения топологии в других кольцах? Или это выходит за возможности MSTP? Как тогда можно решить подобную задачу?