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

Layer 3 Hub? Не троллинга ради...

Имеется "коммутатор" L3, AlliedTelesis x900-24xt. От него уходит 5 гигабит на агрегации, полностью нагружены на чистый гигабит только два линка. Маршрутизирует 100 VLAN-ов сейчас.После добавления сабжевых линков (да и раньше, просто не так массово проявлялось) начал работать как... хм... банальный хаб. Фреймы не коммутирует, а повторяет на все порты VLAN-а, IP-пакеты банально отбрасывает по большей части, SSH-сессии до всего включенного туда рвутся каждые 3-5 минут...

 

Ничего криминального, казалось бы, нет:

core#show mac address-table | redirect 1.out
core#activate sh.sh wc -l 1.out
   3281 1.out
core#show running-config | grep platform
platform enhancedmode nexthop 
core#

 

Обычному show log я не верю, так как там ничего криминального нету, а вот dmesg - неплохо так, весело:

core#activate sh.sh dmesg
packet.
<4>nf_conntrack: table full, dropping packet.
<4>nf_conntrack: table full, dropping packet.
<4>nf_conntrack: table full, dropping packet.
<4>nf_conntrack: table full, dropping packet.
<4>nf_conntrack: table full, dropping packet.
<4>nf_conntrack: table full, dropping packet.
<4>nf_conntrack: table full, dropping packet.
<4>nf_conntrack: table full, dropping packet.
<4>nf_conntrack: table full, dropping packet.
<4>nf_conntrack: table full, dropping packet.
<4>nf_conntrack: table full, dropping packet.
<4>nf_conntrack: table full, dropping packet.
...

 

Можно, конечно, попробовать поизвращаться, вызывая sysctl через ash, что, возможно, поможет с дропами IP, но от отсутствия коммутации, как таковой, это, я думаю, не спасёт. Достаточно запустить на чём угодно, подключенном туда, tcpdump в вот такие вот часы пик и увидеть трафик всего VLAN-а, будто это хаб (а если это некий роутер или другой сервер, на котором несколько VLAN-ов (или все) с trunk-порта, то всё куда веселее).

 

С этим есть смысл пытаться что-то делать или проще выбросить, купить и поставить нормальный L3-коммутатор и забыть как про страшный сон?

Изменено пользователем GFORGX

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


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

веселые ошибки, такие можно встретить на linux-based NAT, когда /proc/sys/net/ipv4/netfilter/ip_conntrack_max слишком маленький, или памяти мало..

по самому телесину не подскажу, не имел опыта.

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


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

Не работал с таким железом.

По логам понятно, что таблица НАТа переполнена. Если есть возможность изменить настройки sysctl - увеличьте к-во сессий трансляций.

Вроде как в Linux было такое - net.ipv4.netfilter.ip_conntrack_max=<size>, задайте что вам надо.

 

Ну и если есть возможность оттюнить tcp/udp таймауты для сессий. Стандатная картина при вирусне, торрентах, резком увеличении клиентов итд. Трафика стало больше - факт.

 

PS: там внутри Linux?

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


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

Не работал с таким железом.

По логам понятно, что таблица НАТа переполнена. Если есть возможность изменить настройки sysctl - увеличьте к-во сессий трансляций.

Вроде как в Linux было такое - net.ipv4.netfilter.ip_conntrack_max=<size>, задайте что вам надо.

 

Ну и если есть возможность оттюнить tcp/udp таймауты для сессий. Стандатная картина при вирусне, торрентах, резком увеличении клиентов итд. Трафика стало больше - факт.

 

PS: там внутри Linux?

Возможность есть, это всё понятно, не в первой на обычных Linux-роутерах, только вот от того, что он концентрирует - вряд ли поможет...

Да, AlliedWare Plus. Вроде бы, почти целиком GPL, даже исходники официальнейшим образом доступны:

core#activate sh.sh uname -a
Linux core 2.6.29.6-at1 #1 Mon Apr 19 18:44:41 NZST 2010 ppc unknown
core#activate sh.sh ls /
BUILD_INFO.TXT  flash           mnt             pkg             share           usr
bin             home            net             proc            skel            var
dev             lib             nvs             root            sys
etc             libexec         opt             sbin            tmp

В принципе, думаю, логичнее убеждать руководство в необходимости чего-то в стиле Cat65/Cat76, а сабж убирать на L3-агрегацию вместо имеющейся L2.

 

 

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


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

Ну если приведете аргументированный доказательства, докажете, что все системы оптимизированны и уперлись в потолок - то да. Покажете динамику роста количества пользователей, красивые картинки мониторинга по PPS и трафику, увеличение правил NAT и ACL...

 

А так, деньги на ветер. Я бы не поверил. И просил бы аргументировать, может даже с привлечением сторонних экспертов.

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


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

Ну если приведете аргументированный доказательства, докажете, что все системы оптимизированны и уперлись в потолок - то да. Покажете динамику роста количества пользователей, красивые картинки мониторинга по PPS и трафику, увеличение правил NAT и ACL...

 

А так, деньги на ветер. Я бы не поверил. И просил бы аргументировать, может даже с привлечением сторонних экспертов.

Грусть в том, что ACL-а там нет. DHCP, которое там было (увы, оказалось, умеет всего 5k статиков, что мало и о чем везде умалчивается), убрано на *BSD. Если туда ещё ACL добавить... Боюсь, оно издаст адские вопли :)

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


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

Ну если приведете аргументированный доказательства, докажете, что все системы оптимизированны и уперлись в потолок - то да. Покажете динамику роста количества пользователей, красивые картинки мониторинга по PPS и трафику, увеличение правил NAT и ACL...

 

А так, деньги на ветер. Я бы не поверил. И просил бы аргументировать, может даже с привлечением сторонних экспертов.

Грусть в том, что ACL-а там нет. DHCP, которое там было (увы, оказалось, умеет всего 5k статиков, что мало и о чем везде умалчивается), убрано на *BSD. Если туда ещё ACL добавить... Боюсь, оно издаст адские вопли :)

Вы не первый здесь, кто решается на DHCP сервис на активном оборудовании, а не на выделенном сервере. Почему так люди делают - мне до сих пор не понять. Неудобно, плохо администрируемо, тяжело отлавливаемо... Фу кароче ;)

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

У нас недавно скандал начался, мол SQL-сервер тормозит основной. Работу работать не успевают. Заткнули скандал просто: подняли документацию, где были приведены расчеты потребления памяти и нагрузки на дисковую подсистему и все. Прописано было до 500 одновременных пользователей максимум, сейчас 560-570 и полезли в своп. Ждем апгрейда.

 

PS: а кто реально решился брать AT и под что, как по мне довольно специфичные и жуткие девайсы.

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


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

Ну если приведете аргументированный доказательства, докажете, что все системы оптимизированны и уперлись в потолок - то да. Покажете динамику роста количества пользователей, красивые картинки мониторинга по PPS и трафику, увеличение правил NAT и ACL...

 

А так, деньги на ветер. Я бы не поверил. И просил бы аргументировать, может даже с привлечением сторонних экспертов.

Грусть в том, что ACL-а там нет. DHCP, которое там было (увы, оказалось, умеет всего 5k статиков, что мало и о чем везде умалчивается), убрано на *BSD. Если туда ещё ACL добавить... Боюсь, оно издаст адские вопли :)

Вы не первый здесь, кто решается на DHCP сервис на активном оборудовании, а не на выделенном сервере. Почему так люди делают - мне до сих пор не понять. Неудобно, плохо администрируемо, тяжело отлавливаемо... Фу кароче ;)

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

У нас недавно скандал начался, мол SQL-сервер тормозит основной. Работу работать не успевают. Заткнули скандал просто: подняли документацию, где были приведены расчеты потребления памяти и нагрузки на дисковую подсистему и все. Прописано было до 500 одновременных пользователей максимум, сейчас 560-570 и полезли в своп. Ждем апгрейда.

 

PS: а кто реально решился брать AT и под что, как по мне довольно специфичные и жуткие девайсы.

Не знаю, удобное CLI, которым удобно управлять через скрипты, вызываемые биллингом, без костылей с перезапусками, наверное, но не суть.

Да, так и будем делать, лежать вечерами почти полностью не доставляет :)

У нас когда-то давно, ещё не при мне, всё было на AT - и ядро, и агрегации (которой тогда как-то толком как таковой не было) и доступ. Вплоть до хабиков AT. Сейчас на доступе D-Link, если ядро будет заменено на Cisco, то останется AT только на агрегации. Там особо ничего специфичного нам ненужно, так что там - действительно неплохо себя чувствует и не мешается :)

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


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

наверное тут важно знать версию прошивки. например с версии 522-08 было исправлено

CR00024386 IP 2 In some network scenarios, the UPD/TCP connection tracker table could fill

up due to the table having a very long timeout period set for established

TCP session information (432000 seconds).

This timeout has now been reduced to 300 seconds. Note that timing out

the TCP session information in the table will not affect the TCP connection.

 

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


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

Этот комутатор могу только поругать.

 

недолго имел с ним дело. На последней прошивке 3-й серии это просто глюкодром. Перезагрузы при удалении вилана через уеб интерфейс к примеру. Эмпирическим путем нашел лекарство: Выкидываем все порты из вилана, потом чистим в нем маки, потом удаляем вилан. Тогда не ребутиться.

 

Внутри, начиная с 5-й ветки прошивок, таки да. Линукс. Идея была в том, что у железки распаяно 512 мб мозгов. И есть слот для CD карточки. Вот линукс на ней и живет. Роутинг там то-же дохлый. В итоге отказался от нее. И заменил на каталист 4006.

 

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


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

наверное тут важно знать версию прошивки. например с версии 522-08 было исправлено

CR00024386 IP 2 In some network scenarios, the UPD/TCP connection tracker table could fill

up due to the table having a very long timeout period set for established

TCP session information (432000 seconds).

This timeout has now been reduced to 300 seconds. Note that timing out

the TCP session information in the table will not affect the TCP connection.

Михаил, у нас 5.3.3:

core#show ver

AlliedWare Plus (TM) 5.3.3 04/19/10 19:10:21

Build name : r1-5.3.3-0.6.rel
Build date : Mon Apr 19 19:10:21 NZST 2010
Build type : RELEASE
NET-SNMP SNMP agent software
(c) 1989, 1991, 1992 by Carnegie Mellon University;
(c) 1996, 1998-2000 The Regents of the University of California.
All Rights Reserved;
(c) 2001, Networks Associates Technology, Inc. All rights reserved;
(c) 2001, Cambridge Broadband Ltd. All rights reserved.
  RSA Data Security, Inc. MD5 Message-Digest Algorithm
(c) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved.
Libedit Library
(c) 1992, 1993 The Regents of the University of California.
All rights reserved.
OpenSSL Library
Copyright (C) 1998-2002 The OpenSSL Project. All rights reserved.
Original SSLeay License
Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)

core#

 

Сегодня оно начало вести себя ещё веселее - концентрирует уже не глядя на VLAN-ы. Молимся, чтобы дожить до прихода Cat76. Бедные наши хомячки... :)

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


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

наверное тут важно знать версию прошивки. например с версии 522-08 было исправлено

CR00024386 IP 2 In some network scenarios, the UPD/TCP connection tracker table could fill

up due to the table having a very long timeout period set for established

TCP session information (432000 seconds).

This timeout has now been reduced to 300 seconds. Note that timing out

the TCP session information in the table will not affect the TCP connection.

Михаил, у нас 5.3.3:

core#show ver

AlliedWare Plus (TM) 5.3.3 04/19/10 19:10:21

Build name : r1-5.3.3-0.6.rel
Build date : Mon Apr 19 19:10:21 NZST 2010
Build type : RELEASE
NET-SNMP SNMP agent software
(c) 1989, 1991, 1992 by Carnegie Mellon University;
(c) 1996, 1998-2000 The Regents of the University of California.
All Rights Reserved;
(c) 2001, Networks Associates Technology, Inc. All rights reserved;
(c) 2001, Cambridge Broadband Ltd. All rights reserved.
  RSA Data Security, Inc. MD5 Message-Digest Algorithm
(c) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved.
Libedit Library
(c) 1992, 1993 The Regents of the University of California.
All rights reserved.
OpenSSL Library
Copyright (C) 1998-2002 The OpenSSL Project. All rights reserved.
Original SSLeay License
Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)

core#

 

Сегодня оно начало вести себя ещё веселее - концентрирует уже не глядя на VLAN-ы. Молимся, чтобы дожить до прихода Cat76. Бедные наши хомячки... :)

по таким проблемам полагаю нужно на support_ru@alliedtelesis.com писать с приложением схемы, выводом sh tech и прочими подробностями.
Изменено пользователем ginodman

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


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.