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

КузярБ

Пользователи
  • Публикации

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

  • Посещение

О КузярБ

  • Звание
    Абитуриент
  1. Какая-то искусственная задача. В бою машину в основном грузят фаервол, нат и шейпер. Так или иначе, но добрая часть провайдерского трафика через них проходит, т.е. все равно где-то будут еще машинки выполняющие эти функции, которые сами по себе роутеры - вот их то и надо тестировать.
  2. SNMP+Zyxel mib's

    Ковырялся с ipsg на ES2024A, то ли я не умею читать мибы, толи косяк где-то еще, но в итоге пришлось подбирать OIDы методом тыка. Подключать МИБы даже и не пробовал. Еще один праздник заключается в том, что включенная arpInspection не отображается в Веб интерфесе (в CLI по моему тоже ). Если интересно, могу выложить фрагменты перлового кода. V3 не пользовал, V2C в отдельноми влане достаточно.
  3. Бордер на Linux

    Попробовал этот вариант - похоже работает. Но на этом подопытном компе собирается за 4 часапо 600к записей, так что надо копать дальше - вставлять NOTRACK где можно.
  4. Бордер на Linux

    Это все мертвому припарки, какой производительности можно ожидать, когда (см.выше) Читаем тут http://www.wallfire.org/misc/netfilter_conntrack_perf.txt
  5. TBF + iptables -j MARK

    Классовая то она классовая, да вот только разблюдовка по классам в ней осуществляется по TOS полю и никак иначе. WTF? priomap "If you do not provide tc filters to classify traffic", the PRIO qdisc looks at the TC_PRIO priority to decide how to enqueue traffic. The kernel assigns each packet a TC_PRIO priority, based on TOS flags or socket options passed by the application. The TC_PRIO is decided based on the TOS Да, проглядел, фильтры можно использовать. Вот только в исходном примере нескладно получится - из сетки 192.168.100.3/24 оно пойдет в первый класс, а все остальное будет раскидано в соответствии с TOS, в т.ч. туда же в первый класс.
  6. TBF + iptables -j MARK

    Классовая то она классовая, да вот только разблюдовка по классам в ней осуществляется по TOS полю и никак иначе.
  7. Вот оно провайдерское счастье - службе технической поддержки заняться больше нечем, кроме как принимать заявки на смену MACов.
  8. Извиняюсь, вопрос немного не в тему - пржде чем искать биллинг вы проверяли, это все реально работает? Просто, скажем у Zyxelя как-то не очень, вот интересно как с этим у Dlink-а.
  9. Просто хранить состояние пользовательских порта(ов) для того чтобы их переключать недостаточно, надо еще где-то держать конфигурацию up и down-линк портов, уметь их отличать от обычных, иметь интерфейс для конфигурации, следить чтобы не было накладок итд. В общем, одним скриптом тут не обойтись. Что касается ACL - да, дергать его большого ума не надо, но не все хотят ими пользоваться, скажем в моей подопытной сетке админы не хотят нагружать L3 оборудование сотнями записей. Это по совету "доброго" производителя и я его отчасти понимаю - все же не Linux и не FreeBSD внутри, ipset на помощь не придет. Ставить PC-фаервол в случае распределенной сети не всегда возможно, аренда каналов туда-сюда тоже денег стоит. Так что LB billing+inventory это хорошая идея, вот только сведений про реализацию что-то маловато.
  10. Извиняюсь, а вы этих устриц с неизвестными биллингу причинами смены состояний на каких свичах ели? Я вот все управляю портами без мониторинга, а они почему-то сами по себе не переключаются. Единственное что их останавливает - это зависание-вырубание-исчезновение свича - и вот тут действительно инвентори оказывается очень полезным. Можно взять с полки новую железяку, прописать ей IP, snmp коммьюнити, гонец отвезет ее в поле, а мы нажмем кнопочку и зальем в нее конфиг сгенеренный с базы. Это небольшой хинт, если вдруг команда LB не знает куда руки приложить (хотя она и сама уже наверное эту мысль подумала).To slukl: как я понял покопавшись в сети переключение портов хорошо реализовано скорее всего только в LB, во всяком случае только они пишут правильные слова. Там проблема в том, что в соответствии с Q-Bridge-Mib порты в VLANе настраиваются все разом и чтобы перевести конкретный порт в другой VLAN нужно иметь актуальную (полученную по сведениям из биллинга) базу состояния всего свича. Т.е. переключающий скриипт должен довольно сильно быть срощенным как с базой железок, так и с биллингом, а это есть похоже только у LB.