Пошук по сайту

имеется схема gp3600-16(version 10.3.0D build 105479) - cisco nexus 3064 - шлюз на линуксе на олт все ону одной модели model-id F601V6.0 олт не видит петлю на порту\влан, а за олт циска переодически видит петлю и постоянно блочит по конфигу на олт !version 10.3.0D build 105479 gpon onu-config-template port1_1 cmd-sequence 001 gpon onu tcont-virtual-port-bind-profile tvbind-default cmd-sequence 002 gpon onu uni 1 vlan-profile vlan1701_test cmd-sequence 003 gpon onu uni 1 uni-profile MTU cmd-sequence 004 gpon onu loopback-detect protocol private cmd-sequence 005 gpon onu uni 1 loopback-detect enable cmd-sequence 006 gpon onu flow-mapping-profile vlan1701 interface TGigaEthernet0/1 switchport trunk vlan-allowed 321,1601,1700-1716,2201 switchport trunk vlan-untagged none switchport mode dot1q-tunnel-uplink dhcp snooping trust ip-source trust storm-control broadcast threshold 5 storm-control multicast threshold 5 storm-control unicast threshold 5 interface GPON0/1 gpon pre-config-template port1_1 bind-onuid 1-128 gpon bind-onutype onutype-default-hgu precedence 127 gpon bind-onutype onutype-default precedence 128 filter dhcp switchport trunk vlan-allowed 321,1701,2201 switchport trunk vlan-untagged none switchport mode trunk switchport protected 1 storm-control broadcast threshold 1000 storm-control multicast threshold 1000 storm-control unicast threshold 5 interface GPON0/1:1 gpon onu model-id F601V6.0 gpon onu tcont-virtual-port-bind-profile tvbind-default gpon onu flow-mapping-profile vlan1701 gpon onu virtual-port 1 gem-port 256 gpon onu tcont 1 alloc-id 259 gpon onu loopback-detect protocol private gpon onu uni 1 vlan-profile vlan1701_test gpon onu uni 1 uni-profile MTU gpon onu uni 1 loopback-detect enable и глобально включено: loopback-detection по nexus логи: %L2FM-2-L2FM_MAC_FLAP_DISABLE_LEARN_N3K: Loops detected in the network for mac 3cfd.feab.c600 among ports Eth1/19 and Eth1/52 vlan 1701 - Disabling dynami c learning notifications for a period between 120 and 240 seconds on vlan 1701 %L2FM-2-L2FM_MAC_FLAP_RE_ENABLE_LEARN_N3K: Re-enabling dynamic learning on vlan 1701 Eth1/19(bdcom) - nexus - Eth1/52(linux(3cfd.feab.c600)) (п.с. да, ону не из лучших конечно, но ходовые, может у кого была подобная проблема и кому-то удалось както решить ее)

Добрый день. Прошу помощи в теоретических познаниях. Есть у меня аплинк провайдер, с которого не допроситься 10G (нет у него свободного для меня порта). Но есть от него 2 штуки 1G линка в разных местах моей сети. Агрегацию (транк) сразу не рассматриваю, так как точки включения физически в разных железках и кроме этого, по одному волокну приходит натив, по второму тагет влан, оба этих канала (натив и тагет у провайдера в одном влане, 1220). Натив провайдера я превращаю в свой тагет 997 и шлю эти оба тегированых влана (1220 и 997) на свой сервер. То-есть в мой сервер они входят в разные сетевые адаптеры и с разными метками влана, но по факту, у провайдера вланы будут совпадать. Для чего это мне нужно? Я в каждом влане имею разные паблик айпи, и буду делить свой трафик между ними. Не получится ли при такой конфигурации петля. Ведь то что вылетит скажем с моего 997 влана, попадёт на стороне провайдера в его 1220 влан, который также есть на моей второй сетевой карте сервера. Единственное что хорошо, то что сетевые адаптеры у меня разные, следовательно маки разные. Но у прова то мак шлюза один и я его получается буду видеть в обоих свих интерфейсах, как в 997 так и в 1220. Для большей наглядности, рисую примерную схему.

В офисе есть один старичок des, который родился еще до LoopBack Detection, но в нем есть spanning tree. Вопрос: spanning tree действительно не умеет бороться с петлями на порту ? как бы читал про LoopBack Detection и spanning tree, понял что spanning tree это немного другая функция в отличие от LoopBack Detection, хотя и схожа

Проблемная ситуация. Пропадает связь с шлюзом на протяжении дня. Порт 1 - Debian шлюз (10.10.0.1) Порт 2 - DHCP server (10.10.0.2) Порты 3-5 - P3310b с включенным dhcp_snooping (его отключение тоже не помогает . Это часть сети в 1 влане. Остальная сеть - влан на абонента (accel-ipoe), работает нормально. Симптомы - перестает ходить арп к шлюзу, хотя свою подсеть клиентвидит. На шлюзе в арп-таблице мак пропадает ( "(10.10.0.35) at <incomplete> on bond0" ). Клиент не может пропингать шлюз. По графику DHCP сервера видно скачки траффика, почти совпадают с моментом падения. На свиче настроен "filter dhcp_server". В логе свича пр ипроблеме появляется запись: Detected untrusted DHCP server (IP: 10.10.0.2, Port: 3) Detected untrusted DHCP server (IP: 10.10.0.2, Port: 4) Detected untrusted DHCP server (IP: 10.10.0.2, Port: 5) Но этот айпи (DHCP сервера) находится во 2 порту. Если на олте отключить dhcp_snooping - проблема остается, а в лог свича не ругается. Так же на свиче включен arp_spoofing_prevention, что наверное исключает arp-spoofing. На шлюзе установлен Debian 7. 4 карточки в бондинге. Все абоненты в своем влане (accel-ipoe), кроме сегмента с олтами. Включен arp-proxy как в accel так и на интерфейсе bond0 (возможно с єтим связано). bond0 смотрит в сеть с олтами. Проблему наблюдаю уже несколько дней. Идеи кончились.