xaoc_nsk

к примеру NMPv2-SMI::enterprises.2011.5.14.3.2.1.3.8.0 = IpAddress: 10.28.0.77 это вывод уже назначенного ip на сервис port (-1) т.е на 7 сервис порт. 0 при этом это просто id записи. заменить тут не выходит, в принципе и из консоли тоже самое, можно только удалить и создать новый. а по snmpset ошибка при попытке добавления Error in packet. Reason: Unknown Error Failed object: iso.3.6.1.4.1.2011.5.14.3.2.1.3.8.0 удаление по snmp работает, методом подбора нашел NMPv2-SMI::enterprises.2011.5.14.3.2.1.4.8.0 i 6 Хотел скачать ems, чтобы п

День добрый, коллеги. Кто то пробовал по snmp реализовать команду bind ip service-port X 10.x.x.x очень удобная фишка, пользуемся пока через консоль. Можно до 10 ip адресов задавать на клиентском сервис порту и только с этих адресов он может взаимодействовать с сетью, что исключает подмены и пр. ( бывают умники)

немного разобрался...элтексы можно привязывать по другому конфиг dba: dba-profile add profile-id 10 profile-name "unlim_200m" type3 assure 1024 max 204800 -------------------- конфиг ont-lineprofile дефолтный ont-lineprofile gpon profile-id 0 profile-name "line-profile_default_0" tcont 0 dba-profile-id 2 tcont 1 dba-profile-id 10 commit quit ----------------------- srv-profile используем дефолтный, в конфиге почему-то не видно его активируем терминалы через add ont затем прописываем service-port #service-port n vlan xxxx gpon 0/5/4 ont x eth 1 mult

MA5683T>display patch all Software Version:MA5600V800R015C00 SPH103 HP1007

а версия прошивки какая у вас? У нас они норм авторизовываются. никаких ошибок не пишет. Но вот загвоздка. Вчера нашли кое-что. Мы назначаем произвольный srv-profile на ntu-1, а когда уже все сконфигурировали, делаем modify srv-profile на стандартный как на сайте...и о чудо трафик сразу начинает идти. Если же сразу назначаем стандартный профиль ничего не идет. Это ужас как не удобно, учитывая, что даже, если сохранять все, то после перезагрузки головы снова перестает работать, хотя все на месте. Если снова сделать modify - то начинает работать

Правильно MA 5683T, ошибся немного

Добрый день. Имеется данное обрудование Настроили стандартно, как указано в документации nag.ru, по примеру на сайте C Huawei работает отлично. Был ли у кого опыт подключения терминалов eltex ntu-1? C такими же профилями что и в примере, терминал авторизовался, все прошло без проблем, мак адреса видим на точке терминации, но вот никак не хочет идти трафик. Даже не получает ip по dhcp Пробавали прописать вручную на клиента, маки так же видим на точке терминации, ни трафика ни пинга нет Может быть профили немного другие нужны?

Сейчас проблема только в одном осталась, это нат.

Ну или хотя бы для начала, чтобы при падении одного из бордеров аплинки не терялись.

Пытаемся реализовать, или понять можно ли или какими средствами

было вот так. Работало отлично. Никто и не замечал,если кто-то из брасов вылетал напрочь

С утра набросаю схему, как было до, как стало после, и что пытаемся. Мои недоработки, думаю со схемы и стоило начинать, меньше слов было бы

по сути помоему так и можно делать с помощью того же оспф. Но что делать, чтобы не потерять аплинки с отвалившегося, это считай 2 гбита трафика

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

да прошу прощения. Это все похоже от недосыпов. OSPF используется. для перестроения маршрутов когда один из брасов падает

fullview с дефолтом от 2х полноценных провайдеров и еще 2 у нас это точки обмена (nsk-ix, xcom) с них ни одного не второго как объясняет 1 из админов т.е по факту получается так. 1 бордер - 1 провайдер с fv и дефолт + 1 точка обмена 2 бордер - 2 провадер с fv и дефолт + 2 точка обмена

Если бы нат был отдельно, может что-то и проще бы было. Но появилось бы еще одно узкое место. с сервером на котором все натится.

Бордер и нат на одной. И белые через нее же ходят. Нат на этой машине стоит, чтобы удобнее было шейпить через физицеский интерфейс, не используя imq и прочее

На белых ip проверили, вообще проблем нет, все четко проходит. А с натом проблема в том, что с одного уходит и может прийти на второй бордер. Нат там другой, коннтрэка нет... ну и дроп соответственно. Извиняюсь, может не так объяснил, 2 по 28 из общей /24 мы для ната используем на разных бордерах, остальные белые. но анонсится 24 полностью. Все поправил в первом сообщении

на обоих бордерах бгп поднят и анонсируется /24 Предположим если на 1 бордере собраны все 4 аплинка, .ну и анонсируем 24 каждому провайдеру только тут на 1 бордер сходят 2 прова, и на второй 2 прова. и там и там анонсится /24 на обоих бгп. Разница только в нате на бордерах.

День добрый! Может кто сталкивался с подобным, если не сложно - ткните носом куда смотреть. Есть два сервера для сбора всего трафика с абонентов и 1 бордер. На нем шейпы, нат, бгп. Нагрузка на оба браса в среднем пополам по vlan. Работают в связке через keepalived( vrrp). Если 1 брас отвалился, все это добро, что было на нем, благополучно переселяется на другой, до поднятия первого, с минимальной потерей связи, секунды 2-3, а то бывает и вообще не заметно. Собственно теперь появился еще 1 бордер. Для резервирования и балансировки, ибо трафика стало многовато. Да и аплинков уже не

к сожалению нет((((это было бы идеально. Но подсетки белых ip уже разделены на /26 давно и выдрать конкретно эти ip не выйдет((

Имеется SLES 11 sp 2, сервер под биллинг 2 интерфейса Ранее на eth0 был прописан только один серый ip, теперь потребовалось прописать еще 1 белый для работы с банком Банк устанавливает свой терминал аппаратного кодирования у нас у него так же белый ip из этой же подсети. Ситуация: Необходимо было сделать разделение сетей на интерфейсах. К примеру на eth1 прописан 195.xx.xx.21/26, на терминале 195.xx.xx.24/26, доступ к белому ip должен быть только извне и с 195.xx.xx.24/26 Все остальные должны ходить на биллинг через серый ip 10.xx.xx.13 Проблема возникала из-за того, что все

http://forum.nag.ru/forum/index.php?showtopic=45266&st=3600 Вот пожалуйста... смысл мне такое придумывать, увидел и попробовал

этот атрибут работает и здесь? тоесть без использования радиуса?