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 multi-service user-vlan untagged ------------------------------------------- трафик с терминалов начинает идти мгновенно и все счастливы Единственное, что не понятно, это почему при перезагрузке головы терминалы не работают. Дот ех пор пока я не грохну service-port и не пропишу заново

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 бордер. Для резервирования и балансировки, ибо трафика стало многовато. Да и аплинков уже не 2, а 4...планируется еще 1. Имеем сетку /24 адресов 2 по /28 используем под NAT. И вот собственно вопрос. Пытаемся поднять оба бордера в такой же связке. Такак как ипов на нат не много, поделили их пополам на оба бордера. Первое с чем столкнулись, вполне логично...что запрос уходит через одного провайдера на брд1 - а приходит через другого на брд2 иииии tcp reset. ( на Белых ip не успел проверить) Но серым это точно не понравится. чтобы быстрее разрешить вопрос. сделали каждому свою связку брас-бордер, иначе многие пострадают Возможно ли вообще балансировать трафик. Это не первостепенная задача. Когда падает один бордер, а он, собака, падает намертво, причину пока не установили, то тут возникает проблема с перестроением маршрутов. По факту выходит, что один из брасов тупо перестает ходить в сеть. Железо есть. сидим думаем, но к сожалению с таким столкнулся в первый раз. Забыл упомянуть. Все на linux (sles) на новом стоит дебиан, но он что-то неадекватно себя ведет, возможно не нравится ядро...это сейчас тестируем. вообще хотелось бы уйти от sles. начинали на нем работать еще так давно только изза того, что он не очень хорошо работал с некоторыми рейдами( инфа по рейдам не моя, сказали мол так, хотя какая разница какая система).

к сожалению нет((((это было бы идеально. Но подсетки белых 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 Проблема возникала из-за того, что все белые адресе в сети переставали нормально работать через серый адрес. Выглядело так, будто запрос уходит на серый, а возвращается с белого. Сделал вот что ip route add 10.xx.xx.0/22 dev eth0 src 10.xx.xx.13 table T1 ip route add default via 10.xx.xx.1 table T1 ip route add 195.xx.xx.0/26 dev eth1 src 195.xx.xx.21 table T2 ip route add default via 195.xx.xx.1 table T2 ip rule add from 10.xx.xx.13 table T1 ip rule add from 195.xx.xx.21 table T2 Все вроде бы заработало, но сервер периодически подтупливает, при чем доступ теряется только с белых ip на серый ip адрес биллинга. Может я что не так настроил или не хватает чего... да забыл сказать, 195.xx.xx.1 и 10.xx.xx.1 это ip в одном vlan100(шлюз для белых и серых в одном vlan)

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

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