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

MaLblsH

Активный участник
  • Публикации

    113
  • Зарегистрирован

  • Посещение

Все публикации пользователя MaLblsH


  1. 3610 лежит у нас до сих пор. Мы его купили году так в 2009 в качестве ядра сети, где он и простоял около года и довольно хорошо себя вёл. Не подружился он у нас с CWDM-ными модулями, в то время как 3627 скушал и не подавился. Времени экспериментировать не было, оставили 27. Теперь Extreme.
  2. Вы любите строить сети на EOL железе? Я понимаю что "научится готовить" можно любой продукт. Только вот в 3612/27 это никакого смысла не имеет. Он в зависимости от ревизии ведет себя совершенно непредсказуемо в разнообразных сценариях. Это плохой Л3-коммутатор и очень не выгодный Л2-коммутатор. Я не пытаюсь доказать, что Dlink классное оборудование и не призываю к его повсеместному использованию. Деньги на оборудование я достаю не из своего кармана и работаю с тем, что есть. Устраивать рекурсию - Dlink *авно - Но работает - Но при это всё равно *авно - Да, но работает ... тоже не вижу смысла ибо само по себе название Dlink стало уже почти что именем нарицательным :) А с заменой 12 на 27 я всё же погорячился - 27ые и в продаже найти тяжело. Я конечно же хотел написать про 3620-28.
  3. Вот ну не совсем я с Вами согласен по а) и б): всё таки с обязанностями он справляется. Не всё конечно гладко, но справляется. Стараемся больше 1К абонентов не держать на 36-ой серии (новую 3620 пока не тестировали). В любом случае 12-ые будут в относительно скором времени поменяны на 27. По г) - собственно это в результате того, что мы не могли организовать mBGP с IPTV-uplink'ом, поэтому пришлось статикой создать. По методу 2 - к этому всё идёт. Медленно, но уверенно. Как минимум мысли есть перекинуть PIM на Extreme, а с него уже ISM на доступ, даже тему создавал. Изначально (08 или 09 год) схема "родилась" на форуме Dlink, в которой сотрудник Руслан Бигаров, используя свои старые тестовые схемы, помогал настроить. В итоге имеем то, что имеем :) Это пока... руки не дошли до перепрошить Extreme и скормить ему Core лицензию. В нашей схемы VLAN'ы до B и C разные. p.s. вообще это уже второй или третий случай, и пока только 3612G страдали. Коллега забыл уточнить про ARP таблицу - она на всём устройстве занимала ~540 записей. Опять же по сравнению с другими не много. + пробовали чистить и её и даже FDB. А вот кстати да. Сейчас проверил на остальных роутерах - там выставлена версия 2. Вчера уже глаза очевидного не видели :(
  4. Из всех приведённых вариантов лично мне LACP не симпатичен вообще :) Единственный его плюс - дешёво. Мне больше всего нравится с переносом PIM на Extreme, но нужна Core лицензия (мы её недавно купили, но не тестировали) и периодически натыкаюсь на сообщениях в разделе Extreme, где в особенности последнего входит просить перезагрузку после некоторых изменений конфигурации. А в нашей схеме Extreme играет так же роль агрегации районных роутеров и не очень круто будет его периодически в ребут пускать.
  5. Доброго времени суток. На данный момент имеем такую схему вещания: На схеме изображены несколько провайдеров IP-TV с которых мы берем multicast потоки по протоколу PIM, далее спускаем их по протоколу PIM-SM до районных роутеров на которых созданы ISM-VLAN'ы (на Extreme поднимать PIM не хочется). Хотелось бы узнать правильная ли в данном случае схема вещания? Так же думаем вместо D-Link DGS-3627G поставить Cisco, но с 10G портами выходит слишком дорого, поэтому ходим поставить Cisco Catalyst WS-C3750G-12S-S и продумываем альтернативные схемы подключения: 1. Поднять ISM_VLAN (в случа Cisco это будет MVR) до роутера в который попадают потоки от провайдеров, и объединить несколько районов в один ISM_VLAN, что бы не гнать много одинаковых потоков между Cisco Catalyst WS-C3750G-12S-S и Extreme x670 которые идут на разные районы, что в свою очередь позволяет раскидать VLAN'ы по разным линкам. 2. Спустить PIM ниже до Extreme x670, что бы не гнать много одинаковых потоков между Cisco Catalyst WS-C3750G-12S-S и Extreme x670 которые идут на разные районы. 3. Оставить всё как есть, но сделать LACP между Cisco Catalyst WS-C3750G-12S-S и Extreme x670, есть ли у кого-то реальная практика прередачи IP-TV через LACP? Если не один из вариантов не подойдет, тогда придется покупать Cisco Catalyst WS-C3560E-24PD-S + один из 10G модулей для неё: http://shop.nag.ru/catalog/04260.Moduli-X2
  6. У меня практически по такой же схеме льются внутренние потоки IPTV. До каждого роутера льётся весь поток, даже если его никто не запрашивал.
  7. Я почему-то подумал, что источник это отдельный маршрутизатор, в который воткнуты вещающие сервера. Тогда нет ничего удивительного, что у Вас поток постоянный от источника.
  8. По ситуации с постоянным потоком: а сервера, которые вещают поток, находятся в том же сегменте (10.11.10.0/24) ? Если так, то попробуйте их вынести в другой сегмент и vlan.
  9. По-моему, очевидным плюсом multicast является возможность использовать MVR (ну или ISM для Dlink). К примеру, при схеме с http unicast два клиента на уровне доступа пытаются смотреть один и тот же канал, что приведёт к дублированию отправки потока на коммутатор. В случае с MVR (ISM) до коммутатора побежит один поток, а коммутатор уже "спустит" его до клиентов. Но если Вас не интересует вопрос масштабируемости, то для Вас это может не оказаться плюсом.
  10. Если Вы взаимодействуете по vlan 9 с источником по PIM, то зачем на vlan 9 включен igmp snooping ? p.s. возможно как раз поэтому Вам источник льёт постоянно поток.
  11. Спасибо всем за помощь! UTM5 без проблем встал на x64 (ядро+rfw). Большего от него и не надо.
  12. Сейчас буду пробовать, потому что обновление до последней stable 8.3 не помогло. Даже ради эксперимента поставил чистый SNAPSHOT 8.3 STABLE i386, собрал ядро PAE и неуспех.
  13. Попробую обновить до последней stable 8.3. Очень давно пробовали ставить на amd64, и вроде даже эту опцию включали, но стоит ещё раз попробовать. Был на форуме NetUp человек, который переписывал rfw под amd64, но у нас всё равно не вышло его (rfw) завести. С того момента (2007 или 2008 год) больше не пробовали. Если не получится с обновлённой до 8.3 i386, попробую поднять utm на той же 8.3, только amd64. А платёжная система - это Вы про payment_tool или это связка с популярными платёжными системами ? Если да, то мы их и не используем, поэтому есть шанс. Разделять биллинг не хочется на 2 сервера. Добавил, перезагрузил. Параметры применились, а вот драйвер пишет всё туже ошибку.
  14. Думаю, всем интересно, почему. Есть вероятность, что те сервисы, которые сейчас крутятся на этом сервере, могут не заработать на обновленной системе. я очень сомневаюсь что что-то не заработает, но вы, наверное, можете сделать копию на тестовый сервер и обновить на нем... Да, так и решили поступить. Сделать копию диска с системой и спокойно обновиться до 8.x на тестовом стенде Собственно и обновились и всё даже заработало: и драйвера к сетевой и всё что нужно. Правда есть одно НО (о нём ниже). Вот тут у нас и проблема: т.к. у нас UTM5, у которого пакет RFW работает только под i386, нам приходится держать всё это именно на i386. Но т.к. оперативки у нас 12Gb, ядро у собрано с PAE для поддержки оной. А теперь возвращаясь к обновлению до 8.x. Удалось обновиться до следующей ветки: 8.0-RELEASE-p6 Изначально собрали с GENERIC. Драйвера встали (как штатные, так и с сайта Intel), сетевуху видно, линк есть, всё круто. Решили пересобрать ядро с PAE да и заменить диски.. После пересборки ядра с PAE, драйвера опять начали ругаться: ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.4> port 0x2000-0x201f mem 0xd8000000-0xd807ffff,0xd8100000-0xd8103fff irq 30 at device 0.0 on pci7 ix0: Using MSIX interrupts with 5 vectors ix0: ixgbe_dma_malloc: bus_dma_tag_create failed; error 22 ix0: Unable to allocate TX Descriptor memory device_attach: ix0 attach returned 12 ix1: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.4> port 0x2020-0x203f mem 0xd8080000-0xd80fffff,0xd8104000-0xd8107fff irq 37 at device 0.1 on pci7 ix1: Using MSIX interrupts with 5 vectors ix1: RX Descriptors exceed system mbuf max, using default instead! ix1: ixgbe_dma_malloc: bus_dma_tag_create failed; error 22 ix1: Unable to allocate TX Descriptor memory device_attach: ix1 attach returned 12 В гугле по ixgbe и PAE нашёл интересный патч, но там немного другое, кмк. Хотя попробовать стоит.
  15. Скиньте и мне, пожалуйста! Спасибо!
  16. И как ? Помогло ? Стоит у меня из портов данная версия, но даже с патчем по ссылкам выше, всё равно такая же проблема: Dlink видит quagga, а quagga Dlink нет :(
  17. 1. Это вопрос доверия с одной стороны и здоровой/нездоровой паранойи, перестраховки с другой. 2. Как уже написал st_re, похоже что вы путаете всех участников сети MSK-IX и некоторое подмножество участников, использующих роут-сервер. В составе AS-MSKROUTESERVER и AS8631 присутствуют только те участники, кто пользуется роут-сервером. 1. Тогда логично воспользоваться подсказкой выше и установить prefix limit. 2. Скорее всего так и получилось, спасибо за разъяснение.
  18. Вот в списке на сайте MSK-IX есть сеть, а в запросе к ripe её нету в AS-MSKROUTESERVER и AS8631. В тоже время в рассылку они постоянно присылают свои обновления. Значит если MSK фильтрует по ripe, то повторный фильтр у себя делать смысла нету ?
  19. Добрый день! Не так давно мы стали участниками MSK-IX. Сейчас задумали сделать автоматическую генерацию фильтров по AS-PATH для участников MSK-IX. Какой утилитой генерировать вопросов не вызывает: bgpq (в качестве bgp используем QUAGGA). Вопрос в другом: как (и где) получить список AS-SET участников MSK-IX ? С RIPE скачал их WHOIS клиент, но в информации по AS8631 или AS-MSKROUTESERVER можно найти не всех участников :( Можно конечно парсить страничку с участниками с сайта MSK-IX, но хотелось бы более красивого решения. Подскажите, пожалуйста, как Вы решаете данный вопрос ?
  20. Вот у нас шейпер как раз реализован мостом. fastforwarding тоже кстати стоит значение "1".
  21. FreeBSD 7.3-STABLE #0: net.inet.ip.dummynet.io_pkt_drop: 14558307 net.inet.ip.dummynet.io_pkt_fast: 139517436 net.inet.ip.dummynet.io_pkt: 923458709 Хм... может мы где в правилах запутались :( Если не сложно, киньте кусочек правил для одной трубы ?
  22. У меня на 8.0-STABLE-201005 amd64 при: net.inet.ip.dummynet.io_fast: 1 Счётчики показывают: Получается у меня вообще никто мимо шейпера не бегает ? Полосы от 1 Мбита и до 16 Мбит. Не думаю, что все полосы забиты до краёв. Параметр применяем ещё с 7.0, если не изменяет память, и никогда счётчик не был равен 0. upd: на другом шейпере с FreeBSD 7.2-STABLE-200906 точно такая же петрушка :(
  23. А VLAN на натах пойдёт как виртуальный интерфейс ?
  24. Если Вы про это: ... interface em1 ip ospf cost xx ... то во-первых Dlink всё равно видит маршрут с cost 1; а во-вторых это будет глобально для двух Dlink...а нам надо что бы для 3612 роут на 10.50.0.111 имел один cost, а для 3627 этот же маршрут имел другой cost.
  25. Доброго дня! Есть вот такая схемка центра сети: состоит из(снизу вверх): Dlink DGS-3627 (ip 10.50.0.99) в качестве районного L3 Dlink DGS-3612 (ip 10.50.0.199) так же в качестве районного L3 Данные роутеры подключены через L2 Switch в NAT1 и NAT2 (оба FreeBSD+quagga). Задача организовать OSPF между данными маршрутизаторами таким образом, что бы NAT1 и NAT2 отдавали дефолт роут на себя каждому 36xx, но так, что бы для 3627 cost 10.50.0.111 был меньше чем 10.50.0.222, а для 3612 наоборот (cost для 10.50.0.222 был меньше, чем 10.50.0.111). Т.е. сделать без баллансировки. Ну а в свою очередь 36хх отдавали маршруты на свои сети обоим натам. На данный момент удалось выполнить задачу почти на 100%, за исключением как раз выставление cost для 36xx. Конфиги такие: NAT1: ospfd.conf hostname nat1 password 123 enable password 123 ! interface em1 ! router ospf ospf router-id 10.50.0.111 default-information originate always network 10.50.0.0/24 area 0.0.0.0 NAT2: hostname nat2 password 123 enable password 123 ! interface em1 ! router ospf ospf router-id 10.50.0.222 default-information originate always network 10.50.0.0/24 area 0.0.0.0 3627: config ospf ipif System state enable config ospf ipif NET1 state enable config ospf ipif NET2 state enable enable ospf 3612: config ospf ipif System state enable config ospf ipif NET3 state enable config ospf ipif NET4 state enable enable ospf При таком раскладе каждый 36хх отдаёт натам маршруты на свои сети и получает 2 дефолта: 10.50.0.111 и 10.50.0.222, но с одинаковыми cost (чего нам совсем не надо). Где и как выставить cost для определённого neighbor найти нигде не могу :( До кучи нарисовалась такая проблема на натах: каждый нат стал дефолтным для другого, т.е. 10.50.0.111 получил дефолт роут на 10.50.0.222 и наоборот. Настоящий дефолт роут наты должны получать по iBGP сверху, но маршруты OSPF видать приоритетнее. Пока решили проблему прописав defaultrouter в rc.conf, который в принципе приоритетнее чем quagga. Удалось установить, что эти дефолты натам раздают 36хх, т.к. трафик между натами заблокировал в pf. Но вопрос с выставление cost стоит острым углом. Может кто-то делал что-то подобное ?