Agent2006

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

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

  • Посещение

Информация о Agent2006

  • Звание
    Студент
  • День рождения

Контакты

  • ICQ
    0

Информация

  • Пол
    Не определился
  1. Вчера после 22 часов на графике снова проявился QUIC. Будем думать, что это были какие-то происки гугла. )))
  2. Вопрос к тем, кто использует NFSEN в связке со СКАТ. Судя по графику загрузки канала в NFSEN с 4 ноября у нас раз эдак в 10 просел трафик по протоколу QUIC. Осталась самая малость. Это гугл чудит или СКАТ у нас перестал детектировать QUIC?
  3. Будем решать проблемы по мере их поступления. :) В данный момент не стоит задача выдать абонентам IPv6. Более актуально было бы избавиться от пачки SE100. Была надежда обойтись малой кровью перейдя на СКАТ - ждали только NAT 1:1. Но, видно, не судьба...
  4. К сожалению, не всё так просто. У нас исторически сложилось, что серые адреса выдавались абонентам последовательно. Поэтому для того, чтобы сейчас абоненту выдать "правильный" серый адрес (который, как я понимаю, должен подойти под "неблокирующий алгоритм диспетчеризации в DPI"), этот серый IP нужно забрать у другого абонента. Честно говоря, такой алгоритм выдачи "статики" не выглядит простым и прозрачным (в данный момент используем пачку SE100, на которых в конфигах руками прописываем статику и на абонента навешивается политика nat 1:1). Тем более, что, как я понял, в случае со СКАТ-10 и выше, алгоритм получится сложнее чем чет/нечет.
  5. Вот-вот, также есть желание избавиться от пачки SE100. :) Но, увы, NAT 1:1 (надеюсь пока) работает не так, как нам надо....
  6. Я Вас понял. Имхо, NAT 1:1 имел бы больший смысл в следующей реализации: 1. Под NAT 1:1 выделяется пул белых IP-адресов. 2. Конкретный серый IP натится в конкретный белый IP - такая своеобразная статика только для тех абонентов, кому она нужна. 3. Было бы очень здорово, если бы такую привязку можно было осуществлять через RADIUS. Пожалуйста, подумайте над этим предложением. Отсутствие такого механизма NAT 1:1 сдерживает нас от покупки лицензии Complete с целью использования СКАТ в роли браса.
  7. Может на данный момент и не совсем полноценный, может Вы не знали, но...
  8. Изменения в версии 7.2 Добавлена поддержка NAT 1:1 Добавлена терминация PPPoE в L2 BRAS Исправления в работе BRAS по результатам внедрений Непонятен механизм работы NAT 1:1. Cоздаем профиль услуги NAT 1:1, в котором определяем диапазон IP адресов пула fdpi_ctrl load profile --service 11 --profile.name test_nat --profile.json '{ "nat_ip_pool" : "5.200.44.0/24", "nat_type" : 1 }' где nat_ip_pool - диапазон внешних IP адресов в формате CIDR Подключаем абоненту услугу 11 с заданными ранее параметрами пула Вопрос. Можно ли абоненту с конкретным серым IP назначить конкретный белый IP-адрес? Если да, то каким образом?
  9. Также озадачились вопросом замены DES-3200 на что-то актуальное. Поставщики предложили попробовать DGS-1210/ME или DGS-1510/ME. Взяли на пробу DGS-1210/ME. Попробовали и положили на склад, т.к. нужный нам функционал с IP-MAC-Port Binding так как надо работать не захотел. Модель DGS-1210/ME выпускают уже более 3-х лет, но судя по чейнджлогу и обсуждению на длинковском форуме до идеала ему еще очень далеко. Очень плохо, что DES-3200 сняли с производства, а на его замену ничего толкового не выпустили.
  10. А нет в планах реализовать планировщик, чтобы в определенное время брас самостоятельно, например, изменял скорость абонентам с дневной на ночную и обратно? Если такого в планах нет, то каким образом можно реализовать такую возможность?
  11. viktorcorneev, везите трупики в ремонт.
  12. А чего там есть у длинка из железа с гиговыми медными портами схожего по функционалу с DES-3200?
  13. По появлению Radius Accounting и DNAT/1:1 нет более конкретных сроков?
  14. Переустановите, должно заработать (патч 1.0.6.1) Да, заработало. Спасибо.
  15. Попробовали сегодня обновить интерфейса управления СКАТ до v.1.0.6. Результат получился такой Интерфейс управления СКАТ v.1.0.5 работает нормально.