Jump to content
Калькуляторы

IVB

Активный участник
  • Content Count

    172
  • Joined

  • Last visited

About IVB

  • Rank
    Студент
  • Birthday 05/26/1961

Контакты

  • Сайт
    http://
  • ICQ
    178680058

Информация

  • Пол
    Мужчина

Город

  • Город
    Северодонецк, Украина

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Защита ОНУ

    Нет, с возвратом проблем не было. Но вот клиент несколько месяцев не платит. И даже объясняет, почему (уехал на заработки - не пользуется, вернётся - будет пользоваться дальше). И кто его знает - может, действительно уехал, а, может, на конкурента переключился. Вот и хочется найти какое-то решение, чтобы наше оборудование, которое пока не используется в нашей сети, не использовалось в сети конкурента.
  2. Защита ОНУ

    ОНУ находится у клиента на ответственном хранении, и по расторжении договора клиент обязан ОНУ вернуть. Но, думаю, большинство провайдеров допускают ситуации, когда клиент не расторгает договор - но и не пользуется услугами и не платит за них достаточно длительный период.
  3. Здравствуйте. Интересует такой вопрос. Существуют ли какие-либо способы предотвратить использование ОНУ другим провайдером? Вот, допустим, пришёл к нашему клиенту другой провайдер и предложил пакет на 5 копеек дешевле. И нашу же ОНУ нашим кабелем подключил к своей сети. Есть ли какая-то возможность сделать так, чтобы ОНУ работали только в нашей сети, а в другой (без дополнительных усилий со стороны того провайдера) не работали? ОЛТы у нас используются P3310B и P3310C. ОНУшки - зоопарк: Pon E107-CF нонейм Gpon Alcatel-Lucent I-010G NGpon E105 Foxgate 1001WZ несколько разных моделей BDCOM... Понимаю, что вопрос достаточно глупый, но вдруг у кого-то есть положительный опыт...
  4. большое спасибо за помощь! всё очень просто - когда знаешь, как :)
  5. Здравствуйте. Настраиваю "выносной" сервер доступа на Микротике. В user manager прописаны МАС-адреса из локальной сети, которые могут получать IP по DHCP. Там же прописаны ограничения скорости. Устройства с прописанными МАС-адресами получают IP по DHCP и доступ за пределы сети. Если МАС отсутствует - адрес не выдаётся, доступа нет. Но если вручную на устройстве из локальной сети прописать IP из пула, из которого выдаются адреса - устройство получает доступ за пределы локалки вне зависимости от его МАС адреса. Как эту лазейку правильно заблокировать? Спасибо.
  6. Здравствуйте. На "железных" железках никогда не сталкивался с ситуацией, чтобы интерфейсы "перенумеровывались". А вот сейчас проверяю определённые идеи на виртуалке с РоутерОС - и столкнулся с тем, что у меня в определённый момент "поехали" интерфейсы: порядок интерфейсов в конфиге виртуалки перестал соответствовать порядку интерфейсов "внутри" МикроТика. Т.е. первый интерфейс в виртуалке стал ether2, 2-й - ether3, ..., последний - ether1 (сначала такой чехарды не было). Хочу "прибить" названия интерфейсов к их МАС-адресам. Пробовал set [ find orig-mac-address=XX:XX:XX:XX:XX:XX ] name=myname и set [ find mac-address=XX:XX:XX:XX:XX:XX ] name=myname МикроТик всё равно "переиначивает" эти команды в set [ find default-name=etherX ] Но вот эти X в etherX уже один раз "съехали", и нет никакой гарантии, что они не съедут ещё раз :( Есть какая-то возможность "закрепить" названия интерфейсов, привязав их не к "etherX", а к чему-то более постоянному? Или это особенность реализации RouterOS X86 и остаётся только смириться? (и ни для чего, кроме как для тестов, её не использовать)
  7. Всё понятно, спасибо. Слишком давно разбирался с PPPoE и успел подзабыть реализацию :( Приношу извинения за глупый вопрос.
  8. Есть два БРАСа - "железный" (SE100) и Акцель. SE100 работает давно, Акцель только начинаем внедрять. Почему-то на запросы на получение адреса по протоколу PPPoE отвечает только Акцель. Сложилось впечатление, что SE100 "видит" ответ Акцеля на запрос, и сам даже к Радиусу уже не обращается. Можно ли (если да - то как), сделать так, чтобы к Радиусу для обработки PPPoE запроса обращались оба БРАСа? В случае с IPoE к Радиусу обращаются оба БРАСа, и Радиус определяет, какой из БРАСов должен авторизовать клиента. Такого же поведения хочется добиться и для PPPoE.
  9. # tc filter show dev ipoe0 filter parent 1: protocol ip pref 90 fw filter parent 1: protocol ip pref 90 fw handle 0x30 classid 1: # tc filter show dev ipoe1 filter parent 1: protocol ip pref 90 fw filter parent 1: protocol ip pref 90 fw handle 0x30 classid 1:
  10. Да, этот вариант мне в голову не пришёл. Спасибо за хорошую идею.
  11. -l - это именно data, а не управление (проверено экспериментально) а управление - это -A (тоже проверено) не могу ручаться за реализации всех протоколов (т.к. они выполняются разными демонами), но демон bgpd умеет биндиться не к 0.0.0.0 (к сожалению, он умеет либо к 0.0.0.0, либо к одному конкретному адресу) так что по поводу сорцов - их действительно не мешало бы "допилить", чтобы можно было указывать несколько параметров -A и -l
  12. Это почти то, что нужно. Почти - потому что параметр -l может быть только один (если задать больше одного - игнорируются все, кроме последнего). А мне ведь нужно, чтобы bgpd с разными пирами общался (с разных адресов, естественно), в т.ч. и с bird. Спасибо за информацию - но, похоже, моя хотелка нереализуема.
  13. Спасибо, попробую. (самое интересное - что в man'е этих ключей нет, только в help'е).
  14. В моём случае DNAT не нужен. quagga "общается" с соседями на стандартном порту. bird будет общаться только с нашей quagga, поэтому достаточно настроить bird на нестандартный порт, и в настройках соседа-bird на quagga указать этот же порт. Вот только не взлетает всё равно такая конструкция... (но только это уже отдельная тема, здесь продолжать нет смысла)
  15. Не, файрвол не поможет. Т.к. на другие адреса должен биндиться bird. (вот такой я извращенец)