Алексей Андриянов

У меня такой вопрос: Наши объекты регистрировались в свое время двумя разными LIR. Мы еще не заключили договор ни с каким LIR, и хотим заключить его с третьим LIR после НГ. Насколько я понимаю, нужно просто подождать до НГ и получить напрямую от RIPE предложение заключить договоры с любым LIR. Проблема в том, что один из первых двух LIR уже пометил выданные им ресурсы как My End User, не имея с нами договора, и теперь утверждает, что нам по-любому придется заключать договор на первый год именно с ним, т.к. RIPE включила стоимость наших ресурсов в его charging scheme на 2010. Правда ли это (что нужно будет заключать договор с ним), или просто отчаянно пытаются отбить свои деньги?

Нет, паравиртуализация. Интерфейс отдан гостевому домену через bridge. То есть в конфиге написано vif = [ 'bridge=eth0' ] где eth0 - это мост, куда входит физическая сетевуха peth0. Через VT-d я не имею пока возможности отдать, т.к. на сервере сетевуха всего одна, а виртуальная машина с бордером - не единственная. Конечно, если это поможет, можно поставить доп. сетевуху и прокинуть через VT-d, но это требует HVM, а я читал, что это _гораздо_ медленнее паравиртуализации. У меня на соседнем xen-сервере windows xp крутится в hvm, тормозит жутко, так что я верю :)

Ну может и правда не из-за него. Там непонятно было, xentop говорил 100% и система не откликалась никак - не отвечала на пинги и на нажатия клавиш в консоли. Когда убрал ipt-netflow, вроде бы прошло. А раз вы пробовали снимать netflow с xen-виртуалок, там наверное, был и трафик серьезный? Не было проблем с прерываниями на каждый пакет, как у меня?

http://ineu.su/blog/2008/09/27/optimalnyj-netflow-sensor/За год использования абсолютно никаких нареканий, юзерспейсовые сенсоры вспоминаю как страшный сон. Я его пробовал, и у меня на нем ядро периодически падало.

Скажу сразу - у меня бордер на VM, и мне он не нравится. Теперь уже понимаю, что скорее всего это извращение, но может быть, кто-то имеет похожий опыт, и поделится? У меня проблема с производительностью. Конфигурация системы: Xen hypervisor 3.4.3, 2 x Xeon E5405 (по 4 ядра, 2.00Ghz), сетевуха одна Broadcomm NetXtreme BCM5722 (драйвер tg3 последний). На предыдущем сервере была Intel-овская сетевуха с драйвером e1000e, и ситуация была та же самая. Трафика - 60 Мбит, 15-20kpps. ресурсы на бордере: paravirtOps-ядро 2.6.31 2 x vcpu 1G ram Задачи на бордере: nat (около 300 000 трансляций, упирается в ip_conntrack_max), шейпер HTB (около 1500 классов и фильтров, фильтры захешированы), 1 x BGP full-view, несильно развесистый iptables (около 20-30 match-ей, через которые проходит каждый пакет) netflow-сенсор на libpcap (softflowd) xentop говорит, что border ест от 90 до 150% cpu. И при этом еще 55% ест dom0, который ничем не занят, кроме бриджевания пакетов с физической сетевухи в vif виртуальной машины. top на самом бордере (виртуальном): top - 21:41:51 up 5 days, 12:50, 1 user, load average: 0.37, 0.52, 0.44 Tasks: 53 total, 2 running, 51 sleeping, 0 stopped, 0 zombie Cpu(s): 5.3%us, 3.7%sy, 0.0%ni, 71.0%id, 0.0%wa, 0.0%hi, 19.8%si, 0.2%st Mem: 793192k total, 767404k used, 25788k free, 0k buffers Swap: 524280k total, 380k used, 523900k free, 309604k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 30939 nobody 20 0 17692 16m 640 R 52 2.1 2012:32 softflowd 31024 nobody 20 0 4932 3620 600 S 10 0.5 205:28.23 softflowd 1799 quagga 20 0 158m 155m 1148 S 3 20.1 408:28.82 bgpd 1 root 20 0 1988 648 596 S 0 0.1 0:01.97 init Выключение softflowd картины радикально не меняет - в xentop на dom0 вместо 90% становится 65-70, и на dom0 по-прежнему 55. `mpstat 1` на боредере говорит так: 09:43:44 PM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s 09:43:45 PM all 4.64 0.00 4.30 0.00 0.33 19.87 0.33 70.53 19579.00 09:43:46 PM all 7.85 0.00 4.10 0.00 0.00 18.77 0.00 69.28 18767.00 09:43:47 PM all 4.21 0.00 3.88 0.00 0.00 18.45 0.32 73.14 19104.00 09:43:48 PM all 4.26 0.00 3.28 0.00 0.00 19.34 0.33 72.79 18797.00 Бросается в глаза очень большое количество прерываний и 20% softirq. А на dom0 их еще больше: `mpstat 1` 09:50:11 PM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s 09:50:12 PM all 0.00 0.00 0.13 0.00 0.00 1.02 0.76 98.09 35237.25 09:50:13 PM all 0.00 0.00 0.00 0.00 0.00 0.62 0.86 98.52 35934.65 09:50:14 PM all 0.00 0.00 0.00 0.00 0.00 1.49 0.62 97.89 36420.79 09:50:15 PM all 0.00 0.00 0.00 0.00 0.00 0.86 0.86 98.28 35048.51 09:50:16 PM all 0.00 0.00 0.00 0.00 0.00 0.99 0.87 98.14 35116.83 `cat /proc/interrupts` на dom0 (ненужное поскипал): CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 1275: 1799227419 0 0 0 0 0 0 0 Phys-irq peth0 1321: 3439284801 0 0 0 0 0 0 0 Dynamic-irq vif13.0 Т.е., прерывания генерятся не только на каждый принятый пакет на сетевухе, но и на каждый принятый и на каждый переданный в вирт. интерфейс xen пакет. Подозреваю, что мои проблемы кроются в большом количестве прерываний из-за неэффективности работы драйверов xen с прерываниями, использовании единственной сетевухи на вход и выход и неэффективном способе снятия netflow. Я собираюсь переводить бордер на физическую машину с многопортовой сетевухой, и сомневаюсь - позволит ли это радикально уменьшить нагрузку? И был бы очень рад найти выход, чтобы оставить бордер на виртуальной машине. Как можете посоветовать прооптимизировать без перевода на физическую машину? Действительно ли проблемы именно в том, что я обозначил, или я не вижу очевидного? Кто как снимает netflow и сколько ресурсов у вас на это уходит? Заранее спасибо за ответы.

Снова к вопросу о правомерности взимания абон. платы в заблокированном состоянии в случае ежедневных списаний. А что если сформулировать это в договоре как штраф (пеню) за день просрочки платежа в размере дневной абонентской платы?

Объясните мне, зачем вам именно 200 L3-портов? Не лучше ли поставить что-то 24-портовое в ядро, и несколько L2-коммутаторов уровня доступа?

Я пробовал вчера вечером. Не помогает.потом убрал это через no ip route-cache, оно так и осталось в конфиге "no ip route-cache policy" И циска после этого реально стала все пакеты на том интерфейсе обрабатывать программно, CPU usage стал 99%, Ip input отжирал около 70%, и пропускная способность катастрофически снизилась. Я сделал "default ip route-cache policy", но это ничего не изменило, как раньше не стало. Пришлось перезагружать. После перезагрузки на том же конфиге стало как было. Я так понял, что всякого рода route-cache включен на этой платформе по умолчанию.

Нет, пакеты уходят на другой SVI, не на тот, с которого пришли. И вообще всякие эксперименты с ip route-cache не помогают, там он и так включен по умолчанию, как я понял.

core#sh sdm prefer The current template is "desktop routing" template. The selected template optimizes the resources in the switch to support this level of features for 8 routed interfaces and 1024 VLANs. number of unicast mac addresses: 3K number of IPv4 IGMP groups + multicast routes: 1K number of IPv4 unicast routes: 11K number of directly-connected IPv4 hosts: 3K number of indirect IPv4 routes: 8K number of IPv4 policy based routing aces: 512 number of IPv4/MAC qos aces: 512 number of IPv4/MAC security aces: 1K core#sh platform tcam utilization CAM Utilization for ASIC# 0 Max Used Masks/Values Masks/values Unicast mac addresses: 400/3200 67/482 IPv4 IGMP groups + multicast routes: 144/1152 33/213 IPv4 unicast directly-connected routes: 400/3200 67/482 IPv4 unicast indirectly-connected routes: 1040/8320 58/372 IPv4 policy based routing aces: 512/512 11/11 IPv4 qos aces: 512/512 8/8 IPv4 security aces: 1024/1024 447/447 Связность внутренняя конечно нужна. То есть, пакеты в сети, присутсвующие в routing table, отправляются минуя этот маршрутизатор, а на него отправляется только интернет-трафик. Локального трафика может быть много.А насчет второго предложения - поправьте меня, если не так понял, но суть именно в последовательном соединении маршрутизаторов, т.е. с основного роутера пакеты пойдут уже на "их роутер"? Такой вариант тоже не самый желанный, поэтому я его заранее в первом посте исключил. Если с циской "договориться" не удастся, то мне лучше будет объединить функции этих 2 маршрутизаторов в одном, чем гонять трафик туда-сюда.

Есть Cisco Catalyst 3560G, у которой частенько полностью загружен CPU: core#sh proc cpu sorted CPU utilization for five seconds: 85%/74%; one minute: 84%; five minutes: 83% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 226 471399 396572 1188 2.39% 0.19% 0.04% 0 SNMP ENGINE 4 1774737 152678 11624 1.11% 0.16% 0.12% 0 Check heaps 214 162886 776437 209 0.79% 0.06% 0.01% 0 IP SNMP 218 76479 388234 196 0.47% 0.03% 0.00% 0 PDU DISPATCHER 157 1859354 9144594 203 0.31% 0.11% 0.11% 0 IP Input 115 938939 236540 3969 0.15% 0.10% 0.10% 0 HQM Stack Proces 7 1272636 2456675 518 0.15% 0.09% 0.07% 0 ARP Input 160 3715873 31734198 117 0.15% 0.22% 0.22% 0 Spanning Tree 230 101 44 2295 0.15% 0.09% 0.02% 2 Virtual Exec 9 0 2 0 0.00% 0.00% 0.00% 0 AAA high-capacit 10 0 1 0 0.00% 0.00% 0.00% 0 Policy Manager Трафик через нее ходит смешной: 5 minute input rate 16081000 bits/sec, 4009 packets/sec 5 minute output rate 71942000 bits/sec, 7110 packets/sec Подозреваю, что все из-за вот этого route-map, прицепленного к паре SVI, так как на нем и на его ACL быстро растут счетчики пакетов, а значит все обрабатывается на CPU: core#sh route-map rFromHome route-map rFromHome, permit, sequence 20 Match clauses: ip address (access-lists): rACL_from10_fastroute Set clauses: Policy routing matches: 2472767969 packets, 865799606 bytes route-map rFromHome, permit, sequence 30 Match clauses: Set clauses: ip next-hop 10.0.100.10 Policy routing matches: 2483 packets, 2493699 bytes core#sh access-l rACL_from10_fastroute Extended IP access list rACL_from10_fastroute 10 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 (2398023137 matches) 20 permit ip 10.0.0.0 0.255.255.255 xx.xxx.xxx.0 0.0.0.255 (5882107 matches) 30 permit ip 10.0.0.0 0.255.255.255 192.168.0.0 0.0.0.255 (55673890 matches) 40 permit ip 192.168.0.0 0.0.255.255 any (13739593 matches) Задача этого роут-мапа - пакеты определенной группы клиентов, направленные в Интернет, отправлять на "их маршрутизатор", а не на обычный шлюз по умолчанию для всех остальных. Как победить эту проблему, не объединяя эти маршрутизаторы и не втыкая их последовательно, придумать не могу.

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

Автор нигде не написал, как у пользователя должно все работать в заблокированном режиме. А при текущей постановке задачи - shutdown на интерфейс пользователя пока он не оплатит - самый оптимальный вариант.

Здесь кое-какая информация о различиях между этими коммутаторами от официальных лиц: http://forum.dlink.ru/viewtopic.php?t=67816

Так ведь АР до порта коммутатора то логически тоже коммутатор... если вы на порту свича вланы перемаркируете на основании маков это траффик между клиентами этой АР не ограничит... Если на самой АР он не запрещен. Да. Причем:1) Запретить коммутацию из WLAN в WLAN позволяют многие точки доступа 2) За точкой доступа все абоненты могут быть в одном VLAN, они там между собой не скоммутируются, свитчи не коммутируют кадры в тот же порт, с которого кадры пришли. Так что ваша прозрачная L2-изоляция достигается простым запретом обмена трафиком для беспроводных клиентов на точке доступа. Разумеется, нужно сделать еще L3-изоляцию, чтобы клиенты не смогли общаться между собой через роутер, но это делается элементарно с помощью firewall ACL.

Такое можно сделать например на коммутаторе Zyxel GS-4012F - у него аксесс-листы позволяют на основе заданных правил менять PVID кадра. Но лучше переосмыслить задачу, то что вы хотите - наверняка не лучший способ добиться того, что вам действительно нужно. Огласите цель.

На свитче Catalyst 3560G наблюдается следующая проблема - потери пакетов при коммутации из порта в режиме 1000M в порт в режиме 100M. При этом скорость коммутируемого потока не превышает 10Мбит, т.е. никак не упирается в 100М. Если выставить одинаковый speed на обоих портах, неважно 100 или 1000, потерь нет. Проблема не в автоопределении параметров - у обоих железок, включенных в C3560, параметры Speed,Duplex и flowctl совпадают с параметрами портов на C3560. Если кто-то сталкивался или есть какие-то идеи, пожалуйста, помогите советом.

sbca, спасибо за советы. Но PPPoE не используем, для ограничение на испускаемый multicast в 3526 есть отдельная функция, никак не связанная с access-profile, а выключать доступ планируем переводом в другой VLAN, где http-запросы будут заворачиваться в личный кабинет.

Конечно, этот адрес в ARP-пакете будет расположен с другим смещением, нежели чем в IP-пакете, если вы об этом. Если говорить конкретно об ACL в DES-3526, то считал. У меня получилось 5 "основопологающих" Access-profile : permit ARP, deny ARP, permit IP, deny IP, deny DHCP. Еще есть в запасе 4 access-профиля, на 2 пары permit-deny. В ограничение на правила на порт вообще трудно упереться, там около 200 правил на группу (октет) портов. Вполне хватает, чтобы обезопаситься от злонамеренных действий пользователя. А от непреднамеренных действий пользователя (вирусов и т.п.) вы и с BRAS не очень-то убережетесь - все равно будет пролезать там, где есть локалка. Пользователям проще растолковать про firewall, чем все новые заразы отслеживать и в центре зарубать. Насчет дешевизны схемы VLAN-per-client и т.п. - предложите решение дешевле для моих объемов (40 домовых коммутаторов, маленький район) - 40 * DES-3526 + 2 * DGS-3627G + 80 * SFP = 550 000 руб (это грубо так). Только железо, понятно, должно быть новое. И чтобы не загиналось на 1000 SVI со всеми вашими ACL в центре.

Точно, доводов оппонента не понимают и не принимают. ARP-спуфинг можно исключить с помощью ACL. В теле ARP-пакета прописан IP-адрес, именно его вы и фильтруете так же, как и source IP в IP-пакетах. Именно он и подменяется злоумышленником на IP-адрес другого компьютера.

Ну положим IPv6 - не проблема для тех, кто не собирается его внедрять, а таких - тьма. Чем там будут обмениваться два умника в своем сегменте, прописавшие себе IPv6-адреса - никого в общем не интересует, маршрутизатор их дальше сегмента не выпустит. По пользовательскиму broadcast-софту - это дело вкуса. Многим нравится, когда у них в сетевом окружении видятся компы соседей или в играх автоматически определяются доступные сервера. Если не давать засылать broadcast на большой скорости, то ничего плохого в нем нет. А вот возможность оберегать пользователей от новых зараз, поражающих ОС и резать любой неугодный трафик действительно ценна, как и теоретическая возможность учета локального трафика. Но для этого нужно действительно серьезное оборудование на терминацию туннелей или VLAN, и экономическая целесообразность сомнительна. Но скажу сразу, боевого опыта применения у меня нет, мы только собираемся строить сеть с использованием по одному VLAN где-то на 200 пользователей, с ACL на клиентских портах и разрешенным broadcast. Поэтому и излагаю свои мысли, может, меня тут переубедят :)

скажу так, отвлекаясь от оборудования и методов защиты, чем меньше сегмент и чем их больше, тем меньше шанс в один прекрасный момент один очень умный/глупый долбоёб положит как можно большее количество машин очередной L2 атакой. Можете привести пример такой атаки? Мне что-то в голову не приходит. От подделки IP-адреса в IP и ARP-пакетах защитит ACL, от source-MAC-спуфинга - небольшое максимальное количество MAC на порт, от broadcast/mcast - storm control, от петель - loopback detection и STP. Что еще этот ваш долбоёб на L2 сможет сделать?

В catalyst автоопределение MDI/MDX не работает при ручных настройках speed и duplex. Скорее всего проблема решается переворотом пар в патч-корде.

А что с тарелкой в Казахстане не так?

У меня была та же ситуация, когда проверял IGMP proxy в 2003. Оставил, вернулся, показывает. Правда, у меня и каналы переключал после этого. Но недолго. Потом перестал показывать вообще. Короче, нормально это не работает. Мне было интересно - у меня одного так? Выходит, что нет.