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

В каждом VLAN multicast ? Тогда умножайте 6Мб/с на количество VLAN на входе в коммутатор. Ну и по 6М на каждом порту на выходе, даже если порты в одном VLAN, раз IGMP snooping отключен.

А вот хочется спросить у отключающих - если допустим флудящий пользователь отключен, как вы определяете, что он устранил причину и его можно включать обратно? Раз он уже отключен, по постоянному потреблению полосы подозрительным трафиком не получится, а частота запросов может снижаться, даже если у вас есть возможность смотреть деталку по запросам отключенных пользователей. Зачастую в таких ситуациях пользователи говорят, что устранили, а на самом деле это не так.

Морально готовым нужно быть в первую очередь к смене биллинга. Автор уже подобрал себе замену TI под *nix ? С этого стоит начать. Самописные решения не примет Связьнадзор.

Один тоже пригодится. Скажем, 2 аплинка, один основной, другой резервный. От основного получаем full-view, от резервного default. Когда проблемы со связностью у основного, без разрыва BGP-сессии, происходит переключение на резервного. Если от обоих принимать только default, переключения не произвойдет, т.к. он будет постоянно анонсироваться, пока есть линк между вами и вашим аплинком. То есть, мне с моими 70M free даже 1 full-view принять не получится? А как растет загрузка проца при получении full-view? А то у меня уже 80-90%.

Есть Cisco 2811 IOS Version 12.4(3a) с базовыми 256M DRAM на борту. Вопрос к держателям full-view на Cisco - сколько нужно свободной памяти для хранения 2-3 full-view? На сегодня, без единого full-view ситуация такая (свободно 70М): #sh memory sum Head Total(b) Used(b) Free(b) Lowest(b) Largest(b) Processor 458FFB00 108004608 35783800 72220808 25972824 26263432 I/O 3C000000 67108864 5388288 61720576 61558240 61542012 Судя по объему занимаемой памяти, отображаемому в show ip bgp neighbours для моих сегодняшних 3000 маршрутов, один full-view должен занимать около 17М. Но на cisco.com я читал, что рекомендовано 128M. Я правда не понял - это свободной памяти или общий объем DRAM у железки? Я так понимаю, при большой таблице RIB, память будет расходоваться не только на хранение маршрутов, так что такие расчеты (17М) некорректны? Короче, если буду принимать 2-3 full-view, нужно ли покупать еще 256M ?

Есть Cisco 2811 в качестве пограничного маршрутизатора. Она как-то криво пропускает через себя ICMP-пакеты tracerout-a. Так, например, вот что видит человек, трассирующий хост за WAN из LAN: # traceroute ya.ru traceroute: Warning: ya.ru has multiple addresses; using 87.250.251.8 traceroute to ya.ru (87.250.251.8), 30 hops max, 40 byte packets 1 192.168.0.1 (192.168.0.1) 0.969 ms 1.392 ms 1.639 ms 2 ###.###.###.### (###.###.###.###) 6.052 ms * * 3 cisco1.krasnodar.gldn.net (194.186.8.161) 139.643 ms * * 4 pe-l.krasnodar.gldn.net (194.186.10.93) 40.152 ms * * 5 * * * 6 * * p-l.Rostov-na-Donu.gldn.net (194.186.10.81) 37.214 ms 7 * p-l.Moscow.gldn.net (194.67.30.57) 46.119 ms * 8 pe-l.moscow.gldn.net (194.186.80.134) 56.654 ms * * 9 cat03.Moscow.gldn.net (194.186.158.193) 45.366 ms * * 10 cat02.moscow.gldn.net (195.239.10.190) 79.604 ms * * 11 * * * 12 ix2-m9.yandex.net (193.232.244.93) 137.516 ms * 198.609 ms 13 * * * 14 * ya.ru (87.250.251.8) 48.952 ms * При этом сами пинги никуда не пропадают: # ping ya.ru -fc 50 PING ya.ru (213.180.204.8) 56(84) bytes of data. --- ya.ru ping statistics --- 50 packets transmitted, 50 received, 0% packet loss, time 700ms rtt min/avg/max/mdev = 42.303/94.081/147.654/28.271 ms, pipe 12, ipg/ewma 14.300/66.818 ms Вот что видит человек, трассирующий хост за LAN из WAN: #traceroute 2.2.2.2 1 80.72.225.1 (80.72.225.1) 0.430 ms 0.314 ms 0.505 ms 2 80.72.224.122 (80.72.224.122) 4.829 ms 4.094 ms 3.839 ms 3 83.69.67.50 (83.69.67.50) 6.375 ms 5.958 ms 6.943 ms 4 83.69.67.54 (83.69.67.54) 8.917 ms 10.460 ms 7.842 ms 5 1.1.1.1 (1.1.1.1) 62.696 ms 44.746 ms 37.936 ms 6 1.1.1.1 (1.1.1.1) 17.511 ms !X * 12.124 ms !X Здесь 2.2.2.2 - машина за cisco 2811, а 1.1.1.1 - IP самой 2811. то есть, в первый раз она отвечает нормально ICMP: time exceeded (time to live) sent to 80.72.225.4 (dest was 2.2.2.2) , а во второй - вместо того, чтобы отправить пакет дальше на 2.2.2.2, она отвечает ICMP: dst (2.2.2.2) administratively prohibited unreachable sent to 80.72.225.4 (эти строчки я взял из debug ip icmp) Простые пинги (а я так понимаю, что от Traceroute они отличаются только большим TTL) и в этом случае нормально проходят. Ситуация не зависит от того, применяется NAT или нет, какие входные-выходные интерфейсы. Я так подозреваю, что где-то в циске при прохождении пакета через нее TTL меняется более одного раза. У кого-нибудь есть идеи? Конфиг циски очень здоровый, так что выкладывать лучше буду частями, если захотите на что-то конкретно взялянуть, пишите. Заранее благодарен за любую помощь.

Кстати, не могу еще понять, почему у меня DstIf Null. В доке написано, что этот пакет никуда не уйдет, зарубается на роутере и в netflow не попадает. Но у меня коллектор их получает нормально.

Привет всем! Снимаю по Netflow трафик NAT-клиентов с Cisco 2811 известным способом с Loopback-интерфейсом. Мой Inside Global, например, 1.1.1.1. Штука в том, что для некоторых видов трафика (например, DNS UDP Response) "переворота" Inside Global в Inside Local не происходит - и по Netflow льется трафик от ns.xxxxxx.ru до моего 1.1.1.1, вместо 192.168.* Причем фактически-то NAT отрабатывает и клиент получает ответ - только в NetFlow внутреннего адреса клиента нет. Для трафика, flow которого нормально переворачивается, вижу следующую картину в кеше: (идет пинг от 192.168.1.5 до 64.233.187.99) # sh ip cache flow | incl 192.168.1.125 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Fa0/0.13 64.233.187.99 Null 192.168.1.5 01 0000 0000 13 Fa0/1.20 192.168.1.5 Fa0/0.13 64.233.187.99 01 0000 0800 13 А вот для DNS-трафика (ns-сервер 62.183.127.3) вижу такое: SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Fa0/0.13 62.183.127.3 Local 1.1.1.1 11 0035 080A 1 Fa0/1.20 192.168.1.5 Null 62.183.127.3 11 0807 0035 1 Вот вкратце конфиг циски: interface Loopback0 ip address 10.10.10.10 255.255.255.224 ip route-cache policy ip route-cache flow ! interface FastEthernet0/0 no ip address ip route-cache policy ip route-cache flow no ip mroute-cache no cdp enable no mop enabled ! interface FastEthernet0/0.13 encapsulation dot1Q 13 ip address 1.1.1.1 255.255.255.252 ip nat outside ip virtual-reassembly ip policy route-map MAP_NetUP no ip mroute-cache ! interface FastEthernet0/1 no ip address ip route-cache policy ip route-cache flow no ip mroute-cache no cdp enable no mop enabled ! interface FastEthernet0/1.20 encapsulation dot1Q 20 ip address 192.168.1.12 255.255.255.0 no ip redirects ip nat inside ip virtual-reassembly no ip mroute-cache no snmp trap link-status ! ip nat pool GoldenNAT 1.1.1.1 1.1.1.1 netmask 255.255.255.0 ip nat inside source list ACL_Golden_NAT pool GoldenNAT overload ! ip access-list extended ACL_Golden_NAT deny ip host 192.168.1.125 any permit ip 192.168.0.0 0.0.255.255 any ! route-map MAP_NetUP permit 10 description ---------- Retrasmit to calculate traffic for private addresses ---------- match ip address ACL_netflow_rev set interface Loopback0 ! end Буду благодарен за любую помощь. Сорри если не тот раздел, что-то не нашел более подходящего. Если есть - перенесите, плиз.

Тогда интересует вопрос о недостатках PI-адресов. Можно ли на пальцах объяснить, каким образом входящие в АС PI-адреса могут не быть "globally routable"? Это просто имеется ввиду, что нужно обязательно поднимать BGP? Или все зависит от длины префикса и количества памяти под таблицы на магистральных маршрутизаторах? Если да, то в нашем случае (/24) не будет разницы между PI и PA в плане связности? Или смысл в том, что в случае PA пакеты при потере динамического маршрута все равно дойдут по агрегированному? Есть ли смысл для увеличения надежности(связности) брать диапазон шире чем /24 (/23 или /22)? И насколько RIPE более серьезно относится к заявкам на PI, чем на PA - я слышал, что они там реально жмутся на PI-адреса и требуют правдивого обоснования их последующего использования?

Здравствуйте, уважаемые коллеги, помогите пожалуйста начинающему админу. Цель: получить AS и управлять входящим трафиком, перекидывая или распределяя его между двумя аплинками. Сначала вкратце опишу ситуацию: 1. Оборудование, поддерживающее BGP есть. 2. Требования RIPE NCC к получателю AS удовлетворены: имеем 2 PA-диапазона /24 и /27, и 2 подключения к LIR-ам, выдавшим эти адреса. Диапазон /27 в АС нам не очень нужен, и при необходимости мы можем от него отказаться. 3. С обоими LIR есть договоренность о том, чтобы посодействовать получению нами АС, но оба они почему-то плохо представляют себе эту процедуру, и какие адреса в эту АС можно и стоит влкючать (PI или PA). 4. Для нас предпочтительнее было бы остаться на текущих PA-адресах, хотя бы чтобы заново не перенастраивать везде адреса. Получилось так, что прояснить непонятные моменты больше практически негде. Возникли следующие конкретные вопросы, но был бы очень благодарен и за общий совет - что делать в такой типовой ситуации, в правильном ли направлении мы двигаемся? Я не жду, что кто-то очень добрый ответит на все вопросы, но надеюсь, что соберу кое-какую информацию "с миру по нитке". Теперь, собственно, конкретные вопросы: 1. Могут ли входить в AS префиксы длинее 24 бит, или ограничение установлено просто на минимальное количество адресов в ней? 2. Должны ли мы получать PI-адреса, или при наличии доброй воли LIR PA-адреса не проблема? 2.1 Что значит фраза, сказанная в FAQ "...не стоит разрешать клиенту анонсировать адреса из Вашего блока другим провайдерам, могут возникнуть проблемы с прохождением анонсов специфик или Вы получите нежелательный трафик"? Имеется ввиду анонс специфики для нашего PA-диапазона и нежелательный BGP-трафик? 2.2 И какого рода проблемы с этим анонсом? Настолько ли они серьезны, чтобы LIR не захотел анонсировать наш поддиапазон? 3. Если все же PA, то какой из 2 LIR должен подавать заявку на АС, или это может делать любой из них? Но должно же быть между ними какое-то взаимодействие, ведь оба диапазона попадают в AS? 4. Если все же PI, то можно ли на пальцах объяснить, каким образом входящие в АС адреса могут не быть "globally routable"? Или все зависит от длины префикса и количества памяти под таблицы на магистральных маршрутизаторах? Если да, то в нашем случае (/24) не будет разницы между PI и PA в плане связности? Или смысл в том, что в случае PA пакеты при потере динамического маршрута все равно дойдут по агрегированному? 5. Должен ли будет LIR, зарегистрировавший AS потом подтверждать изменение анонсируемых маршрутов, или это можно будет делать самостоятельно? Спасибо заранее за ваши ответы!