Перейти к содержимому
Калькуляторы

Негативное влияние пиринговых площадок на сеть. MSK-IX, DATA-IX, AMS-IX, DE-CIX

Да я бы с радостью, но нифига у нексуса 3064 нет mac acl.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
13 часов назад, RN3DCX сказал:

А что это за маки?

Это ipv6 богадельня. Случается, что клиентские CPE сходят с ума (этим поделия блинка отличаются с завидным постоянством) и начинают срать в WAN-порт флудом dhcpv6-запросов на эти MAC'и. И когда темп запросов доходит до 50-100 в секунду, начинает плохеть control-plane всем коммутаторам, через которые эти запросы проходят. Даже если DHCP-snooping и ipv6 везде выключены.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
4 часа назад, taf_321 сказал:

Это ipv6 богадельня. Случается, что клиентские CPE сходят с ума (этим поделия блинка отличаются с завидным постоянством) и начинают срать в WAN-порт флудом dhcpv6-запросов на эти MAC'и. И когда темп запросов доходит до 50-100 в секунду, начинает плохеть control-plane всем коммутаторам, через которые эти запросы проходят. Даже если DHCP-snooping и ipv6 везде выключены.

Ну сейчас немного мимо. Мы же тут про IX-ы говорим, а там "сходят" с ума не клиентские CPE, а операторские ASBR-ы :) ну не совсем сходят с ума, надо смотреть на распределение кол-ва запросов по макам в ipv6-multicast на DE-CIX. Ну т.е. если равномерно, то это значит ipv6 такой плохой протокол (точнее, его сигнализация), если нет - ну значит кто-то подключился каким-нибудь шлакотиком или длинком к IX

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

может попробовать сменить native VLAN на 911 и повесить на него VACL резать все и вся.

И на 2282 также VACL прибив IPv6

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 25.12.2018 в 06:32, taf_321 сказал:

Режьте пакеты по dst MAC - 33:33:ff:00:00:01 и 33:33:ff:00:00:02

Именно резать а не дропать?

Хотелось бы увидеть пример на циске.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 hours ago, feeman said:

Именно резать а не дропать?

это одно и тоже.

 

2 hours ago, feeman said:

Хотелось бы увидеть пример на циске.

На какой модели?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И с VACL на nexus 3064 ничего не вышло) ошибку не помню уже, но не дал применить к влану

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
11 hours ago, 704114 said:

И с VACL на nexus 3064 ничего не вышло) ошибку не помню уже, но не дал применить к влану

Да к сожалению VACL там только  IPv4.

 

Вот пример  CoPP

Spoiler

class copp-s-v6routingProto2
    police pps {если нету IPv6, то можно поставить уменьшить}

 

Возможно дело в TCAM

Spoiler

By default, all IPv6 TCAMs are disabled (the TCAM size is set to 0)

 

сделайте вывод

show hardware access-list tcam region

show ipv6 access-lists

switch(config)# show hardware profile tcam region

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так, нашел в какую сторону копать.

Дело действительно в COPP,  а конкретно в:

 

  class-map copp-s-arp (match-any)
      police pps 20
        OutPackets    10021095
        DropPackets   2404530

 

По дефолту стояло значение police pps 200, понизил до 20, коммутатор начал умирать в том числе с одним вланом от MSK-IX.

В общем получается что всё логично, чем больше пирингов включать, тем больше пакетиков под правило попадают и иногда дропаются arp, которые идут из/в влан управления.

 

Вопрос как правильно разрулить это дело? police pps 2000 выставить? Но во время какого-нибудь шторма это может навредить.

Почему вообще коммутатор отправляет на процессор arp пакеты? Я понимаю если бы у меня был ip интерфейс, а тут то чистые l2 vlan ы от пирингов. Свитч их должен просто пропускать без анализа, или я не понимаю логику работы на l2?

 

Вот такую фигню нашел. Очень надеюсь что дропы не затрагивают транзитные arp паеты, иначе жесть.

https://community.cisco.com/t5/data-center-switches/n3k-arp-packets-in-l2-vlan-increase-copp-counters/td-p/3693772

Придется теперь проверять что не дропается транзит.

 

 

Изменено пользователем Sergey R.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Sergey R. 

Не знаю как конкретно на Cisco Nexus, но всякой китайщине аля DCN казалось бы транзитные arp, dhcp и т.д. попадали на CPU. Одно время, заставил китайцев это передать, но потом (в более новых версиях ПО) опять стало по-старому (скорее всего, мне показывали какой-нибудь фейк). И да, сигнализационный трафик транзитных вланов дропался если cpu не справлялся. Вообщем, надо уточнять этот вопрос в саппорте Cisco (просто копируется трафик на cpu или идёт сквозь cpu). Например, на huawei s-свитчах, имеется задержка в изучении mac-ов в vpls, т.е. задерживается в очереди на обработку на cpu, при этом сам трафик коммутируется, но обратный, естественно, идёт как бродкаст пока мак не изучится (т.е. это режим копирования, а не сквозной)

 

Радикальное решение таких проблем - делать по-олдскульному, а именно OOB mgmt (судя по даташиту, на cisco nexus 3064 2 таких порта). Эти порты типа не участвуют в коммутации трафика и поэтому, как минимум, управление вы не потеряете по причине дропа arp-ов. Но в самом деле тут тоже могут быть нюансы, зависит от того как именно устроен CoPP и на каком участке взаимодействия компонент он режет трафик, даже у одного вендора это бывает сделано по-разному.

И ещё можно запилить мегакостыль в виде static-арпа в mgmt vlan с обеих сторон (как со стороны nexus, так и там где он терминируется), но сами понимаете во что это выльется при замене оборудования

 

2 часа назад, Sergey R. сказал:

я не понимаю логику работы на l2?

Просто свитчи работают не совсем так как написано в учебниках. Обычно эти нюансы возникают либо из-за ограничения аппартной плафтормы, либо из-за кривых рук программистов, которые трапят тупо весь сигнальный трафик на cpu, даже когда есть возможность этого не делать

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 02.01.2019 в 22:53, Sergey R. сказал:

  class-map copp-s-arp (match-any)

Вот такую фигню нашел. Очень надеюсь что дропы не затрагивают транзитные arp паеты, иначе жесть.

https://community.cisco.com/t5/data-center-switches/n3k-arp-packets-in-l2-vlan-increase-copp-counters/td-p/3693772

Придется теперь проверять что не дропается транзит.

 

 

 

 Кто-то арп транзитит ? Обуеть...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
16 часов назад, YuryD сказал:

 Кто-то арп транзитит ? Обуеть...

длинк dxs-3600 на древних софтах арпы из транзитных л2 поднимал на проц. китайцы грешат таким как выше уже сказали. 

 

а по теме, там блэкхолинга маков нет? может дст маки для ipv6 nd в блэкхол загнать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, zhenya` сказал:

длинк dxs-3600 на древних софтах арпы из транзитных л2 поднимал на проц. китайцы грешат таким как выше уже сказали. 

 

а по теме, там блэкхолинга маков нет? может дст маки для ipv6 nd в блэкхол загнать?

ну вот такой он оем. Полечили они это, ip arp elevation

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 Дык при живом bgp зачем маки транслировать ?  Ну даете l2 - bgp тут причём ? Дали вам l2 с точек обмена - транслируйте и маки и вланы. Для сей хрени мне пришлось на входе с одного из обменников положить отдельный коммутатор, который вланы умеет. И соотв распихано по вланам-портам, где инет с обменника, а где l2 клиента. Ибо моя брокада таких фокусов не смогла. Далее - да хоть что они в свой влан пусть засунут. ткам от нага пока пережевывает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Благодарю, да, согласен что идеальный вариант это OOB mgmt, как раз его сделаем в будущем. 

Но пока вполне хватит static arp. Оборудование меняется не так уж часто, также проблем никаких не вижу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 05.01.2019 в 10:01, Butch3r сказал:

ну вот такой он оем. Полечили они это, ip arp elevation

а можно детали? а то гугл выдаёт лишь пару упоминаний на форуме длинка

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
4 минуты назад, s.lobanov сказал:

а можно детали? а то гугл выдаёт лишь пару упоминаний на форуме длинка

http://forum.dlink.ru/viewtopic.php?f=2&t=164063

 

 

И вот такой же фикс появился для DGS-3630

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас