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

semop

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

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

  • Посещение

О semop

  • Звание
    Студент

Информация

  • Пол
    Не определился

Посетители профиля

Блок посетителей профиля отключен и не будет отображаться другим пользователям

  1. MIBы

    Здравствуйте. Что-то не могу найти OID для сохранения конфига на TFTP. Нашел в MIB'ах (NMS-EPON-TFTP.MIB): .1.3.6.1.4.1.3320.101.20.1 - NMS EPON OLT device source file path. .1.3.6.1.4.1.3320.101.20.2 - NMS EPON OLT device source file name. .1.3.6.1.4.1.3320.101.20.3 - NMS EPON OLT device destination file path. .1.3.6.1.4.1.3320.101.20.4 - NMS EPON OLT device destination file name. .1.3.6.1.4.1.3320.101.20.5 - NMS EPON OLT device tftp operation status. When the value 'upload(1)' is set, all the value in this mib file would be read into system and cresponding file in destination would be uploaded into flash. As the value 'download(2)' is set, the file in the flash would be downloaded into local machine. After all the operations finish, the value would be set as 'disable(3)' automatically. А где указывать IP адрес TFTP сервера не нашел...
  2. Прокси отключен только на втором. Если на первом его отключить, то все ТВ стопорится.
  3. На обоих применил: ip igmp snooping vlan 100 l2-general-querier-source 10.253.0.1 Указав IP Querier'a. На SNR_2 отключил прокси (no ip igmp snooping proxy) Переехал на схему 2. Все вроде работает. Ура)
  4. На HWI есть такая команда, он тоже с 0.0.0.0 отвечал. Применил когда то давно такое у него на влане и все успокоилось: vlan 100 description ISM vlan igmp-snooping enable igmp-snooping general-query source-ip 10.253.0.1 igmp-snooping special-query source-ip 10.253.0.1 Но IP тут - Querier'а, а не коммутатора. Спасибо. Попробую аналогично на SNR. На обоих это наверно надо указывать. с этой командой примененной на SNR_1 (схема 1) - при включении канала, ТВ играет 2сек и картинка встает. В стоке "ip igmp snooping proxy", с ней все хорошо работает. Пробовал ее применять/отменять на SNR_2 (схема 2) - результата не дало.
  5. Действительно сработало ограничение 50 групп. Поправил. Появилась другая непонятная проблема. Старая схема работы IGMP: Источники живут за SNR_1, Querier тоже за SNR_1. Приемники/приставки - за HWI и за DLINK. На DLINK - создан мультикаст-влан. По трассе - просто снупинг. Все прекрасно. Делаю так: Меняю на SNR_2 mrouter-port в сторону SNR_1 Убираю на старых линках влан IGMP. Переключаю на DLINKe влан в сторону SNR_2 Мультикаст заводится и показывает. Но после этого переключения наблюдаю картину, при которой любая отписка в облаке DLINK - отписывает все что на нем живет. Т.е. с двух разных портов DLINK подключены приставки. Например они смотрят одну и ту же группу и если на любой из них отключить ее/отписаться/переключить - то отпишется и первая. Конфиг DLINK для igmp не меняется. Конфиги SNRов идентичны, mrouter-port только разные: ! vlan 100 ! ip igmp snooping ip igmp snooping vlan 100 ip igmp snooping vlan 100 limit group 1024 ip igmp snooping vlan 100 mrouter-port interface Ethernet1/0/14 ! Влан проключен для каждой схемы в соответствующие порты транком, никаких петель. Фильтры пока что все убрал. Конкретика: 1 схема - если отписаться, то счетчик на коммутаторе доступа для группы обновится до default значения. Порт на DLNIK будет подписан. ТВ не прерывается. 2 схема - если отписаться, то счетчик на коммутаторе доступа для группы станет 0, группа пропадет. Но порт на DLINK останется быть подписаным. ТВ прерывается (причем у всех людей кто был к этой группе подписан) Я по началу думал fastleave где то отрабатывает не так, но это вроде не он. Схему 1 я просто увеличиваю до схемы 2 одним коммутатором, где влан ИПТВ просто проключен со снупингом, как собственно он проключен и на HWI. Схема 1 работает, схема 2 - нет. Нужна помощь. (подозреваю если отключить снупинг на SNR_2 то все будет работать, но мне так не надо)
  6. Я на транковых сделал так: vlan 5 ! Interface Ethernet1/0/5 switchport mode trunk switchport trunk allowed vlan .......... switchport trunk native vlan 5 ! Interface brief: Ethernet1/0/5 is up, line protocol is up Ethernet1/0/5 is layer 2 port, alias name is TAG BRASS #1/2, index is 5 Ethernet1/0/5 is LAG member port, LAG port:Port-Channel12 Hardware is SFP+, address is f8-f0-82-77-fc-92 PVID is 5 Просто левый влан, никуда не проключен. У цыски можно делать так: ! vlan 5 shutdown ! Жаль у SNR нельзя. Маки как бы остаются, но дальше порта никуда не ходят. Это первое, что на ум пришло после цыски. С discard более правильно наверно)
  7. BDCOM p3608 DHCP не видит запросов

    Заработало у нас DHCP. Помог НАГ. Спасибо им!) Добавлена команда - epon local-mac forward Никаких абонентских влан-интерфейсов, хэлперов и тд у нас никогда не было в конфиге. Голый dhcp-relay snooping. Он работал очень долго. Потом сам перестал. В конфиге этой команды тоже никогда не было. Так и не понял почему без нее столько времени отработало) Ну ладно, главное сейчас заработало как надо. Еще раз спасибо НАГу. Вряд ли я бы до этой команды додумался. В конфиг-гайдах о ней ни слова.
  8. BDCOM p3608 DHCP не видит запросов

    У нас релеило до 13/01/2019 С таким конфигом: ip dhcp-relay snooping ip dhcp-relay snooping vlan x-x ip dhcp-relay snooping information option format hn-type ///этого никогда не было ip dhcpd enable ! interface VLAN216 description Clients ip address 172.20.0.216 255.255.255.0 no ip directed-broadcast ip helper-address 192.168.0.250 ! Полгода работало) И опц82 была и запросы с ответами. А вчера просто перестало. Абсолютно никаких изменений на сети и в конфигах. Просто проснулись утром, а там вот. Проключеные транзитом коммутаторы работают. А сам BDCOM с его абонентами - нет. Перепробовано множество вариантов, но пока так и не удалось его "починить". Включал dhcpd, и интерфейс поднимал, и пинги везде ходят, и грузил я его раза три, и прошивку менял. Тишина. Понимаю головой, что такого не бывает просто так. Обязана быть причина. Но ему на самом деле ничего не мешает работать. Я в ступоре. == По дебагу если судить нашему и формату DHCP, то я такое видел 2 раза. На коммутаторах длинк. Было ровно то же самое поведение. И так же причина не была обнаружен. Психанул, перезагрузил свич и все само заработало. Не знаю что это было. Потом такая же штука случилась на GPON, но у другого вендора. Там еще прикольней было. Не было 82 опции и dhcp только с одной ONU. Точнее приходило криво. Конфиг унифицирован для всех, а не пашет одна онушка с куста. И вновь не понял причину не работы. Заменил терминал у абонента, сбросил конфиг порта и вернул копи-пастом обратно. Заработало. В случае с BDCOM эти все манипуляции я сделал в первую очередь. Но в его случае не работает весь GPON-доступ, а не один терминал. Перезагрузкой не лечится и сбросом конфига тоже.
  9. SNR-S2990G-24FX M-LAG

    Вроде нет. SNR (порт на SLAVE, подключен к HWI) HWI (подключен к SNR) ==== На Мастере все чисто. На такой же паре портов.
  10. SNR-S2990G-24FX M-LAG

    Так а это не проблема. Просто для информации мне хотелось узнать. Если это особенности стека, то ладно. Обновление 1мин.
  11. SNR-S2990G-24FX M-LAG

    Скажите пожалуйста, нормально ли такое: snmp мониторинг загрузки портов коммутаторов с VSF 1) загрузка порта на мастере 2) загрузка порта на слэйв 3) загрузка порт-ченнел (другая пара портов) 4) загрузка VSF портов Т.е. мониторинг рвет графики вне зависимости от того, что это: просто одна физика или порт-ченнел именно на SLAVE коммутаторе. Мастер рисуется чисто. Так же чисто рисует и зеркальные порты коммутаторов, которые подключены к SNR'ам. На доступе это я никак не регистрирую. Все хорошо работает. Джиттера нет, пинги ровные. Но почему то так рисуется... Есть собраные в стек длинки и хуавеи. Такие же порт-ченнелы. Но там такого не происходит с графиками.
  12. SNR-S2990-16X vlan bandwith

    насколько помню у длинка она распространяет свое действие на весь физический порт.
  13. xconnect cisco 6506 / ME-3800 L2VPN

    Я запускал xconnect mpls без PW. Т.е. вот так вот и все: mpls ldp neighbor 172.23.0.251 targeted mpls ldp neighbor 172.23.0.254 targeted mpls ldp loop-detection mpls ldp graceful-restart timers neighbor-liveness 300 mpls ldp graceful-restart timers forwarding-holding 300 mpls ldp graceful-restart mpls ldp tcp pak-priority no mpls ip propagate-ttl mpls label protocol ldp ! interface GigabitEthernet0/2.52 description Zelenaya-3b encapsulation dot1Q 52 no cdp enable xconnect 172.23.0.254 52 encapsulation mpls mtu 1500 ! sh mpls l2transport bi 52 Destination Address: 172.23.0.254, VC ID: 52 Local Label: 126 Cbit: 0, VC Type: Eth VLAN, GroupID: 0 MTU: 1500, Interface Desc: Zelenaya-3b VCCV: CC Type: CW [1], RA [2] CV Type: LSPV [2] Remote Label: 140290 Cbit: 0, VC Type: Eth VLAN, GroupID: 0 MTU: 1500, Interface Desc: n/a VCCV: CC Type: None CV Type: None sh mpls l2transport vc 52 de Local interface: Gi0/2.52 up, line protocol up, Eth VLAN 52 up Destination address: 172.23.0.254, VC ID: 52, VC status: up Output interface: Gi0/2.4086, imposed label stack {140290} Preferred path: not configured Default path: active Next hop: 172.23.0.18 Create time: 1y18w, last status change time: 11w5d Signaling protocol: LDP, peer 172.23.0.254:0 up Targeted Hello: 172.23.0.252(LDP Id) -> 172.23.0.254 Status TLV support (local/remote) : enabled/not supported Label/status state machine : established, LruRru Last local dataplane status rcvd: no fault Last local SSS circuit status rcvd: no fault Last local SSS circuit status sent: no fault Last local LDP TLV status sent: no fault Last remote LDP TLV status rcvd: not sent MPLS VC labels: local 126, remote 140290 Group ID: local 0, remote 0 MTU: local 1500, remote 1500 Remote interface description: Sequencing: receive disabled, send disabled VC statistics: packet totals: receive 0, send 0 byte totals: receive 0, send 0 packet drops: receive 0, seq error 0, send 0 PW на l2tun xconnect'e работает. Цыска правда 29.
  14. Так ипсек то завелся почти. Это уже круто. Интерфейсы 145 и 147 с виду друг от друга ничем не отличаются. а с соурса 10.127.145.1 в первом случае тоже не пинг? может на хосте .81 шлюз .1 не выставлен или некорректны маршруты? И второй вопрос к обратной стороне. Как настроена она.
  15. Тема конкретно сползла в холивар с элементами оффтопа. Не понимаю про какие гигабиты трафика и терминирования сессий тут говорят. Точнее зачем. ТС надо было подключить 1 клиента по оптике + радио. Он уже наверно сделал))