[Sergey R.]

Всем привет!

 

Имеется сеть, состоящая из коммутаторов  nexus 3064, используются как чисто L2  железки. Маршрутизация на  cisco760x.

До определенного момента сеть успешно функционировала, далее решили добавить помимо двух имеющихся пирингов: MSK-IX и DATA-IX еще два: AMS-IX, DE-CIX

 

Первоначально vlan от пирингов проходил также через коммутатор DLINK DGS-3120.

Первое что случилось - умер DLINK. По управлению мертвый, связь через него также прервалась.

Ну ладно, посчитали что длинку не место в данной топологии, удалили его.

 

Далее, по управлению начинают умирать nexus! В логах тишина, периодически управление отваливается/восстанавливается. (трафик ходит слава богу...)

Вроде также руки тянулись поменять нексусы, но время показала еще одно...

 

Стал кашлять cisco760x.... 

Вот тут данный вопрос обсуждали

 

Сейчас вот начинают терзать сомнения что вообще что-то нужно менять из железа.

cisco760x конечно же мы поменяем, но там роутер по TCAM скоро упрется...

 

Возникают такие мысли: пиринговые сети это большие L2 сегменты, участников много, много широковещательного трафика, он и прикладывает наши железки.

Терминировать vlan на порту подключения пока возможности нет, в точке подключения отсутсвует роутер, и пока только в голову приходит выключить нафиг эти пиринги, чтобы не создавали лишние простои сети.

 

Может кто-то сталкивался с чем -то подобным? Протаскивал пиринговые vlan через l2 до маршрутизаторов ядра?

Наверняка на те же грабли должны были наступить.

Возможно есть какое-то более простое решение чем установка роутеров в точке подключения?

 

 

[Butch3r]

А что в момент такого события происходит из консоли железки? Мангал (76 кошка) легко умирает от петли, которые кстати регулярно бывают в таких пиринговых вланах

[crank]

9 часов назад, 704114 сказал:

Далее, по управлению начинают умирать nexus! В логах тишина, периодически управление отваливается/восстанавливается. (трафик ходит слава богу...)

А у вас доступ к нексусам не через 76-ую кошку сделан случаем? Я больше склоняюсь к проблемам с ней, т.к. оратор выше уже сказал про то, что убить её control plane довольно легко.

У нас подобная вашей схеме включения, только вместо нексус стоит экстрим X670. В качестве бордера (да простят меня за кощунство) стоит SE600. Подключены к MSK-IX, DATA-IX, DE-CIX и ещё нескольким более мелким площадкам + аплинки + пиринги. Всё терминируется на одной железке (SE600) и проблем как бы особых нет.

[VolanD666]

В мониторинге то что?

[s.lobanov]

Да можно бесконечно гадать, надо делать дампы и смотреть что за мусор приходит. Это может быть multicast (сейчас много всякого ipv6 multicast можно встретить ввиду особенностей ipv6), arp-штормы и т.д. Ну и да, то что с точки зрения cisco76 может быть мусором в самом деле это нормальный трафик (например, ipv6 nd). 

Ну и да, версия о том, что тупит сама 76ая тоже очень даже реалитичная. У вас хотя быть мониторинг cpu и прочих ресурсов настроен?

 

Ну и нужно понимать, что IX-ы по большому счёту это огромная L2 почти помойка (не смотря на все меры типа тестирования, перевода плохих участников в карантин и т.д., установки фильтров админами IX-ов). Сейчас на IX-ах может быть сотни или даже тысячи хостов в одном vlan, ну а во что это выливается наверное знает любой человек, работавший с пионернетами(где так делают даже имея управляемые свитчи)

[Sergey R.]

В мониторинге тишина, в логах пусто. Нексусы просто прикладываются по управлению. Пока склоняюсь к такому же мнению как  у s.lobanov, пробую дампить, перекрыть  ipv6 multicast (ipv6 на данный момент не нужен). В общем последний день на разборки в случае неудачи отключим de-cix. По крайней мере до того момента пока 76xx не заменим на джун mx204.

Очень дорого обходятся эти падения железа.

[Sergey R.]

Сдампил трафик, под 1000pps сыпится пакетов multicast ipv6

11:51:52.894562 00:12:f2:92:eb:03 > 33:33:ff:00:00:02, ethertype IPv6 (0x86dd), length 86: fe80::212:f2ff:fe92:eb03 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2001:7f8::31aa:0:2, length 32
11:51:52.894925 5c:5e:ab:d2:a1:90 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::21f:1202:e58c:87c1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:7f8::220d:0:1, length 32
11:51:52.894935 5c:5e:ab:d2:a1:90 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::21f:1202:e58c:87c1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:7f8::797f:0:1, length 32
 

Вероятно их блокировка облегчит жизнь, но вероятно нексус 3064 фиг даст заложить эти пакеты?

 

Из доступных средств что попробовал:

storm-control multicast level 0.00, результата никакого, всё равно пропускает

 

С ACL также дохлый номер, не лочит эти пакеты.

 

interface port-channel1
  switchport mode trunk
  switchport trunk allowed vlan 2282
  ipv6 traffic-filter deny-all-ipv6 in
  spanning-tree port type edge trunk
  spanning-tree bpdufilter enable
  storm-control multicast level 0.00
 

IPv6 access list deny-all-ipv6
        5 deny ipv6 any any log
        10 deny ipv6 any any
        20 deny ipv6 any ff02::1:ff00:1/128
 

Есть еще идеи как залочить ВЕСЬ ipv6? Сейчас mac acl еще гляну, но боюсь что в нексусе 3064 mac acl нету.

 

 

[Sergey R.]

ipv6 acl не допилили они похоже, как  ingress (Router ACL) он его видит

Хотя po1 чисто L2 интерфейс.

 

sh ipv6 access-lists

IPV6 ACL deny-all-ipv6
        Total ACEs Configured: 3
        Configured on interfaces:
                port-channel1 - ingress (Router ACL)
        Active on interfaces:

 

 

[TheUser]

Вставлю свои 3 копейки.

С Хуавеем были проблемы на обменниках: прилетало что-то OAM-ное. В эту сторону тоже гляньте.

[StSphinx]

26 минут назад, 704114 сказал:

Сдампил трафик, под 1000pps сыпится пакетов multicast ipv6

11:51:52.894562 00:12:f2:92:eb:03 > 33:33:ff:00:00:02, ethertype IPv6 (0x86dd), length 86: fe80::212:f2ff:fe92:eb03 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2001:7f8::31aa:0:2, length 32
11:51:52.894925 5c:5e:ab:d2:a1:90 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::21f:1202:e58c:87c1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:7f8::220d:0:1, length 32
11:51:52.894935 5c:5e:ab:d2:a1:90 > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::21f:1202:e58c:87c1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:7f8::797f:0:1, length 32
 

Вероятно их блокировка облегчит жизнь, но вероятно нексус 3064 фиг даст заложить эти пакеты?

 

Из доступных средств что попробовал:

storm-control multicast level 0.00, результата никакого, всё равно пропускает

 

С ACL также дохлый номер, не лочит эти пакеты.

 

interface port-channel1
  switchport mode trunk
  switchport trunk allowed vlan 2282
  ipv6 traffic-filter deny-all-ipv6 in
  spanning-tree port type edge trunk
  spanning-tree bpdufilter enable
  storm-control multicast level 0.00
 

IPv6 access list deny-all-ipv6
        5 deny ipv6 any any log
        10 deny ipv6 any any
        20 deny ipv6 any ff02::1:ff00:1/128
 

Есть еще идеи как залочить ВЕСЬ ipv6? Сейчас mac acl еще гляну, но боюсь что в нексусе 3064 mac acl нету.

 

 

По симптомам - умирает control plane от мультикаста. Так может посмотреть в сторону CoPP?

[s.lobanov]

Не эксперт по cisco nexus, но попробуйте VACL. https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3000/sw/security/503_u1_1/b_Cisco_n3k_security_cg_503_u1_1/b_Cisco_n3k_security_cg_503_u1_1_chapter_01000.html

 

Если умирает всё-таки 76ая, то CoPP должен спасти

 

>1000pps сыпится пакетов multicast ipv6

ну да, убивайте любыми способами, это полная ж для старых cisco

[Sergey R.]

Благодарю за советы. Сейчас погасили сессии и убрали трафик с маршрутизатора.

Роутеру очень сильно полегчало.

Теперь остались нексусы, которые ложаться только по управлению, связь не обрывается.

Т е теперь могу спокойно проводить тесты с vacl, acl, CoPP и прочим.

 

[Sergey R.]

на 760x загрузка по CPU раза в 3 упала сразу, ARP процесс в основном освободился.

В общем опасения подтвердились, громадный L2 с тысячью маков, куча всяких широковещалок.

MSK-IX и DATA-IX не доросли до такого, не вероятно в будущем будет тоже самое.

Так что подозреваю я что придётся роутер на границу сети купить и изолировать эти зверинцы на порту подключения. Спокойнее жить будет.

Изменено 24 декабря, 2018 пользователем 704114

[s.lobanov]

на MSK-IX очень жёсткая политика по отношению к говнотрафику, наверное даже жёстче чем на европейских IX

 

>Так что подозреваю я что придётся роутер на границу сети купить и изолировать эти зверинцы на порту подключения. Спокойнее жить будет.

ну вообще да, правильнее конечно организовывать пиринги на роутерах. Из-за таких как вы (ничего не имею против лично Вас), которые включаются свитчами на IX-ы, появляются и штормоптели и прочие прелести

 

И кстати, по поводу свитчей - попробуйте объявить vlan rspan'ом , это транзитный режим, который создан для того чтобы гонять любой трафик через себя. Единственное - потеряете диагностику  в виде просмотра мак-таблицы

 

[StSphinx]

1 час назад, s.lobanov сказал:

ну вообще да, правильнее конечно организовывать пиринги на роутерах. Из-за таких как вы (ничего не имею против лично Вас), которые включаются свитчами на IX-ы, появляются и штормоптели и прочие прелести

 

Ой, было дело. Стыдно вспоминать. Принимали W-IX на мангал и отправляли L2 по сети до бордера. Из-за глюка на мангале устроили шторм на IX. Пришлось краснеть и писать оф. письма чтобы обратно включили.

[Sergey R.]

1 hour ago, s.lobanov said:

на MSK-IX очень жёсткая политика по отношению к говнотрафику, наверное даже жёстче чем на европейских IX

 

Знаю я эту политику) отработал от звонка до звонка там 3 года :-D

На самом деле думаю дело не столько в политике сколько в количестве пиров.

Вот сейчас глянул на порту MSK-IX менее 500 маков.

В DEC-IX под 1000, и ipv6 там больше, прямо видно по количеству мультикаста входящего.

Так что теоретически если MSK-IX будет расти то также будут мешать L2 сегменту.

 

Но я думаю что уже вопрос решен и сделаем изоляцию на уровне портов всех этих зверинцев. Извините несколько месяцев эта проблема доставала пока не пережили несколько серьёзных падений и глубоко копать не начали.

[Butch3r]

У вас был 3120, который первым умирал

Напишите на нам acl, подропайте лишнее, повешайте его на порты пирингов. Включите шторконтролл, лупдетект и прочие защитные плюшки. Для начала хватит.

[s.lobanov]

1 минуту назад, Butch3r сказал:

лупдетект

Ага, лупдетектом срать в IX, ну просто гениально! Вы ещё stp предложите включить или erps какой-нибудь. На IX-ах явно в правилах пишут выключать такой трафик

 

https://kb.msk-ix.ru/en/ix/reqs/

Цитата

3.3.On all the interfaces connected to MSK-IX Network, the Customer must disable ARP proxy, Broadcast forwarding, Spanning tree, IP redirects, link-layer protocols (LLDP, etc.), and vendor-specific protocols sending extraneous Ethernet frames (CDP, Layer 2 keepalive, etc.), except for LACP protocol when connecting via EtherChannel.

 

[smart85]

втыкаться в пиринговый влан без CoPP ? однако

Изменено 24 декабря, 2018 пользователем mse.rus77

[taf_321]

18 часов назад, 704114 сказал:

С ACL также дохлый номер, не лочит эти пакеты.

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

[Butch3r]

В 24.12.2018 в 20:12, s.lobanov сказал:

Ага, лупдетектом срать в IX, ну просто гениально! Вы ещё stp предложите включить или erps какой-нибудь. На IX-ах явно в правилах пишут выключать такой трафик

 

https://kb.msk-ix.ru/en/ix/reqs/

 

А я так раньше и делал, правда не долго. Сейчас IX напрямую в мангале.

[zhenya`]

41 минуту назад, Butch3r сказал:

А я так раньше и делал, правда не долго. Сейчас IX напрямую в мангале.

no keepalive на интерфейсе есть и no map enabled ? )

[Butch3r]

неа)

[RN3DCX]

В 25.12.2018 в 06:32, taf_321 сказал:

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

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

[azhur]

1 час назад, RN3DCX сказал:

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

NDP (Neighbor Discovery Protocol) и обнаружение маршрутизатора соответственно, если я не путаю.