Пошук по сайту

UA BGP V1.0 Пока есть сеть с клиентами – она будет приносить прибыль. Чем больше клиентов – тем больше сеть (и прибыль, как следствие). Как привлечь клиентов? Правильно – обеспечить их качественными ресурсами за минимум стоимости. Как решить эту проблему? Об этом ниже. Итак, есть некий провайдер, обеспечивающий неких клиентов неким «интернетом». Откуда он его берет? Правильно, чаще всего от провайдеров вышестоящего уровня. За деньги. Стоимость мегабита в месяц примерно знают все. Задача: дать клиентам качественный ресурс, расположенный на территории Украины (и быстро, и всё рядом – например, UA-IX). Самый простой (а также самый дорогой и неудобный) способ – это пустить траффик через интернет. Теряются и скорость и деньги. А если посложнее? А посложнее – организовать BGP. Вкратце, BGP – протокол граничного шлюза, который предназначен для маршрутизации между автономными системами. Для того чтобы организовать BGP, надо как минимум 2 аплинка: один для глобального междоменного BGP (мировой интернет), один – для локального междоменного BGP (между АС Украины). Суммарное количество роутов для глобального междоменного BGP составляет на данный момент порядка 420К и растет. Для Украины (локальный BGP) это количество составляет около 10К этих самых роутов. тут хорошо описано про BGP рекомендую http://habrahabr.ru/post/113906/ Один из аплинков «затягивает» в себя всю таблицу маршрутизации для мирового BGP, второй – локальную таблицу маршрутизации Украины. И всё бы хорошо, но для того, чтобы поднять Full BGP «у себя дома», нужна «балалайка» типа Extreme или Juniper, причём вложить нужно будет от 10К до 35К американских президентов. Сумма немалая, а из более дешевых решений реально существует и работает только образчики китайского народного творчества типа BD-COM 3928GX с вариациями (GX, GXB, GXE – ссылка тут), и другие модели других производителей. Стоимость их относительно невелика, однако есть гигантская ложка дёгтя: дешевые коммутаторы имеют мало памяти под BGP таблицы маршрутизации (10К-20К роутов), и под ними возможно поднять только локальный Украинский BGP, а весь остальной траффик так или иначе попадает на дефолтный роут вышестоящей АС. Как быть? И хочется, и колется! А что, если реализовать софтверный роутер на базе ПК типа «Таз» и одной (или нескольких) сетевых карт? Итак, нам понадобятся: ПК типа «Таз» с многоядрёным камнем на борту, шина PCI-E x8 и более, поболее ОЗУ и та самая волшебная сетевая карта с 2-мя 10-гиговыми интерфейсами на приём и/или на раздачу (у кого какие аппетиты) и (не обязательно) карта с 2-мя – 4-мя медными/оптическими портами 1G/10G на раздачу/агрегацию (фотки/описания карт ниже). На таз ставится линух – и в бой! а вот давайте посчитаем ориентировочно корпус + бп = 200 уе не фанатим, но и не гуано мать 90 уе сейчас проц 140 уе где то так память 70 уе 16 Gb за глаза видео ну еще 40 уе сетевые ну пусть по 550 уе = 1100 итого 1640 уе если памяти много уберите и будет вам 1600 денег роутер с 4 мя 10г портами а если добавить свитчик от например DGS-3420-28SC - D-Link за 1100 уе то имеем за 2700 решение вполне себе веселое 3 10G свободных порта на свиче и 3 свободных порта на компе итого 6 10г портов ну и бонус 24 sfp занятыми считаю порты линк между компом и свичем вот прайсик на сетевые от Влада ну и сами сетевые Карта A-Gear NIC-10G-2BF: 2 порта SFP+. Каждый порт работает на скорости 10G в полном дуплексе. Чипсет Intel 82599ES. PCI-E 2.0 (5.0 GT/s). Внешний вид. Карта A-Gear NIC-1G-2ET: 2 порта 1000BASE-T. Каждый порт работает на скорости 1G в полном дуплексе. Чипсет Intel 82576EB. PCI-E 2.0 (2.5 GT/s). Внешний вид. Карта A-Gear NIC-1G-2EF: 2 порта SFP 1G. Каждый порт работает на скорости 1G в полном дуплексе. Чипсет Intel 82576EB. PCI-E 2.0 (2.5 GT/s). Внешний вид. Карта A-Gear NIC-1G-4PF: 4 порта SFP 1G. Каждый порт работает на скорости 1G в полном дуплексе. Чипсет Intel 82580EB. PCI-E 2.0 (2.5 GT/s). Внешний вид. Пример реально работающего железа: Конфигурация: Таз: AMD Phenom™ II X6 1100T Processor/Ram 32 Gb/Asrok 990FX Extreme4; Сетевые: обе карты Dual Port SFP+ Slot 10G Ethernet Server Adapter Intel82599 (двухголовая на 10G с двумя SFP+ слотами); NIC-10G2BF 2 x SFP+ slot 2 x 10 Gb/s PCI-E 2.0 x8 (на этой карте модули SFP+ встали без проблем даже с дровами из коробки), INTEL X520-DA2 ETHERNET SERVER ADAPTER (на этой карте с модулями SFP+ от трех разных производителей были проблемы драйвера; пришлось патчить); Драйвер для карт версии ixgbe-3.11.33 был пропатчен дабы работали любые SFP+ модули; Модули применял как SFP+ 20 км WDM (скрещивал их с XFP WDM), так и SFP+ двухглазые (скрещивал их с XFP). Примеры модулей: XFP двух глазые, XFP WDM, SFP+ двухглазые, SFP+ WDM. Результат: la 12:00:05 up 5 days, 5:32, 6 users, load average: 0,01, 0,04, 0,05 Текущий суммарный трафик: Max Average Current In 2268.9 Mb/s (29.1%) 1146.6 Mb/s (14.7%) 1122.7 Mb/s (14.4%) Out 3672.7 Mb/s (47.0%) 1924.1 Mb/s (24.6%) 1991.7 Mb/s (25.5%) Как это было… Обновляем ядро http://kernel.org/ Важно! при сборке выключаем conntrack или выгружаем модули потому кому как удобнее root@zion:/usr/src/linux-3.6.6# cat .config | grep CONN # CONFIG_NF_CONNTRACK is not set Качаем драйвера на сетевые http://sourceforge.n...s/ixgbe stable/ Если у вас сетевая Intel и при установке SFP+ модуля пишет модуль неизвестен, то патчим драйвера: [PATCH] ixgbe: Always allow any SFP+ regardless of EEPROM setting. Intel are trying to limit which SFP's we can use in our NICs. We don't like this practices in the Linux Kernel. Signed-off-by: Jesper Dangaard Brouer <hawk@...dk> --- drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c index 7cf1e1f..2b13083 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c @@ -1061,6 +1061,8 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw *hw) } hw->mac.ops.get_device_caps(hw, &enforce_sfp); + /* Hack: Always allow any SFP regardless of EEPROM setting */ + enforce_sfp |= IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP; if (!(enforce_sfp & IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) && !((hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core0) || (hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core1))) { I cannot understand why Intel are pulling a stunt like this! :-( I have read the code, and the limitation comes from a EEPROM setting on the NIC, see define "IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP 0x1". Here is a (untested) patch I believe removes the limitation in the driver: [PATCH] ixgbe: Always allow any SFP+ regardless of EEPROM setting. Intel are trying to limit which SFP's we can use in our NICs. We don't like this practices in the Linux Kernel. Signed-off-by: Jesper Dangaard Brouer <hawk@...dk> --- drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c index 7cf1e1f..2b13083 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c @@ -1061,6 +1061,8 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw *hw) } hw->mac.ops.get_device_caps(hw, &enforce_sfp); + /* Hack: Always allow any SFP regardless of EEPROM setting */ + enforce_sfp |= IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP; if (!(enforce_sfp & IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) && !((hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core0) || (hw->phy.sfp_type == ixgbe_sfp_type_1g_cu_core1))) { Собираем: make install Выгружаем старые модули загружаем новые: rmmod ixgbe; modprobe ixgbe Смотрим, что вышло: dmesg Обновляем загрузчик, чтобы после перезагрузки грузились новые нами собранные модули: update-initramfs -u После загрузки правим буфера на сетевых, можно добавить в rc.local (ну или кому куда удобнее): ethtool -G eth17 tx 4096 rx 4096 ethtool -G eth19 tx 4096 rx 4096 ethtool -K eth17 gso off ethtool -K eth19 gso off Добавляем в /etc/sysctl.conf net.ipv4.conf.default.rp_filter=0 net.ipv4.conf.all.rp_filter=0 net.ipv4.ip_forward=1 net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_sack = 0 net.ipv4.tcp_rmem = 10000000 10000000 10000000 net.ipv4.tcp_wmem = 10000000 10000000 10000000 net.ipv4.tcp_mem = 10000000 10000000 10000000 net.core.rmem_max = 524287 net.core.wmem_max = 524287 net.core.rmem_default = 524287 net.core.wmem_default = 524287 net.core.optmem_max = 524287 net.core.netdev_max_backlog = 300000 Применяем ну и озаботимся загрузкой их при старте (опять же, кому как удобнее): sysctl -p Дальше строим quagga (хороший мануал по линку ниже): http://muff.kiev.ua/...moshchyu-quagga Вуаля! Всё готово! Сразу хочу сказать, что все работает больше недели. Пожелания по оптимизации принимаются korvin2000 ATATA gmail.com Будет желание отблагодарить – пишите, вышлю номер кошелька. Всем удачи! чуть дополню 13.11.2012 перестроение таблиц вообще моментально я и ощутить не успеваю, как и заливку фула да и опять же на серваке много, что можно дополнительно прикрутить от мониторинга до днса ну и прочее прочее.... благо загрузку я показал, нет ее тем кому аппаратные решения близки есть один нюанс темп роста таблицы и она явно будет больше 512 К в ближайшем будущем, учитывайте это в своих планах это был еще один повод для такого решения кстати вот почем и не стал брать 480 Extrime потому как там она 512 К и кончится она к лету 2013 года такими темпами, а то и раньше а в этом варианте нету проблемы памяти достаточно производительности тоже если не будет хватать ну возьму мать с двумя, четырьмя процами с большим количеством ядер слотов и соберу транк, раскидаю нагрузку например благо опыт есть и все это из подручных средств(правильно в обсуждении отметили еще один + что если что-то сломалось, то за разумное время все можно восстановить) к вопросу о pps .. eth17: 210910.19 P/s 277942.12 P/s 488852.31 P/s eth19: 503610.79 P/s 437217.58 P/s 940828.37 P/s .. total: 1338441.15 P/s 1337760.52 P/s 2676201.67 P/s один момент он важный я сразу о нем забыл написать, но обещал сегодня добавить, что и делаю надо понимать как загружены ядра сморим так cat /proc/interrupts 73: 40706333 4 27 94 874 9783 PCI-MSI-edge eth17-TxRx-0 74: 4 4293093014 16 98 879 10015 PCI-MSI-edge eth17-TxRx-1 75: 1 4 109858012 73 756 9086 PCI-MSI-edge eth17-TxRx-2 76: 0 3 14 81842259 841 11221 PCI-MSI-edge eth17-TxRx-3 77: 1 3 17 103 146222860 13126 PCI-MSI-edge eth17-TxRx-4 78: 3 4 34 160 2357 77321145 PCI-MSI-edge eth17-TxRx-5 79: 369866 0 0 0 0 21 PCI-MSI-edge eth17 80: 525881 0 2 0 0 0 PCI-MSI-edge eth21-TxRx-0 81: 2 525881 0 0 0 0 PCI-MSI-edge eth21-TxRx-1 82: 0 2 525881 0 0 0 PCI-MSI-edge eth21-TxRx-2 83: 0 0 2 525881 0 0 PCI-MSI-edge eth21-TxRx-3 84: 0 0 0 2 525881 0 PCI-MSI-edge eth21-TxRx-4 85: 0 0 0 0 2 525881 PCI-MSI-edge eth21-TxRx-5 86: 0 0 0 0 0 0 PCI-MSI-edge eth21 94: 3418121906 9 20 127 1651 17776 PCI-MSI-edge eth19-TxRx-0 95: 3 3362852205 20 124 1453 18277 PCI-MSI-edge eth19-TxRx-1 96: 0 3 3637069058 113 1286 16919 PCI-MSI-edge eth19-TxRx-2 97: 2 4 17 3514448895 1297 18126 PCI-MSI-edge eth19-TxRx-3 98: 1 3 17 137 3619996895 23037 PCI-MSI-edge eth19-TxRx-4 99: 1 17 27 213 3247 3577909943 PCI-MSI-edge eth19-TxRx-5 100: 3665401 0 0 0 4 19 PCI-MSI-edge eth19 это нормальное состояние если стоят 0 а счетчики увеличиваются на одном из процессоров это и есть узкое место и проблема решений три 1. ставим скрипт он это делает сам /usr/sbin/irqbalance 2. есть в папке с драйверами скрипт запускаем с интерфейсами ixgbe-3.11.33.good/scripts/set_irq_affinity.sh eth19 eth17 3. раскидываем руками кому интересно то найдет как есть еще одна тонкость важная о ней забыл написать ну кто столкнется спросит надо же положительный фидбек получить, а не кучу флейма Еще раз всем удачи и будьте лояльнее друг к другу у каждого свой путь и это не значит, что он не правильный