Azamat

Всем доброго дня. Находимся в ЕАЭС, но не РФ. Законодательство в целом калька с РФ/ЕАЭС. Получаем сигнал со спутника и ретранслируем в IPTV Сейчас вдруг пытаются навязать лицензию на использование радиочастот. Типа/мотивация - вы же используете частоту на прием сигнала. Как бы отбиться от такого буквального трактования термина - использование раодичастотного спектра ? Для всех, кто в теме, очевидно - использование = передача на этой частоте. Но лицензия на прием - это что-то новое.

там один единственный ACL из нескольких правил. Вряд ли бы он как то аффектнул ТСАМ. На 3к пробовали - там странное - в счетчики пакеты попадают, но не дропаются - их видно в "зеркале" на интерфейсе, куда они по логике АСЛ не должны были долетать. На ИОС-ных коммутаторах вообще не было подобной проблемы.

К сожалению, не работает не только на транках, но и на access-ных портах :( Все проверили так/сяк. Только permit Уже думаем, т.к. в 5548 для L3 нужна специальная приблуда, может без нее не видит igmp ..

Чуть выше было - Ethernet1/25 - ingress (Port ACL) Это только в одном случае - ip port access-group .... ко вланам ничего не применялось

Если не указать statistics в acl - то не будет вообще таких продолжений [match=0]. Я просто не вывел эту строку как само-собой разум. summary: IPV4 ACL i.fake statistics per-entry Total ACEs Configured:6 Configured on interfaces: Ethernet1/25 - ingress (Port ACL) Active on interfaces: Ethernet1/25 - ingress (Port ACL) IPV4 ACL i.fake statistics per-entry 10 deny igmp 172.33.0.0/16 239.255.1.0/24 [match=0] 20 deny igmp 172.33.0.0/16 239.255.2.0/27 [match=0] 30 deny igmp 172.33.0.0/16 239.255.3.0/27 [match=0] 31 deny ip 172.33.0.0/16 239.255.3.0/24 [match=0] 100 permit igmp any any [match=0] 150 permit ip any any [match=93726395] Порты - чистые ethernet в режиме транка.

Всем доброго дня. Плз подскажите, если кто знает, как заставить работать фильтрацию на порту. Вопрос таков: Создан acl для фильтрации igmp сообщений от wi-fi китайщины на портах нексуса. Сначала разрешенный трафик на группы - на всяк случай сделано и по ip и по igmp (не работает ни так, ни так) 10 permit ip 10.10.0.0/16 239.255.1.0/24 [match=0] 11 permit ip 10.10.0.0/16 239.255.2.0/24 [match=0] 12 permit ip 10.10.0.0/16 239.255.3.0/24 [match=0] 13 permit igmp 10.10.0.0/16 239.255.1.0/24 host-report [match=0] 14 permit igmp 10.10.0.0/16 239.255.2.0/24 host-report [match=0] 15 permit igmp 10.10.0.0/16 239.255.3.0/24 host-report [match=0] Запрещаем трафик от китайщины: 99 deny igmp 172.22.0.0/16 224.0.0.0/4 [match=0] 100 deny ip any 239.0.0.0/8 [match=0] 200 permit ip any any [match=16309701] после применения на портах счетчики растут только в 200-ом правиле - permit ip any any Зеркалирование на вышестоящем показывает, что поток всякой ерунды из 172 сети спокойно приходит до него через аплинк. 13:47:50.129083 64:ee:b7:13:cc:d9 > 01:00:5e:00:00:02, ethertype 802.1Q (0x8100), length 60: vlan 970, p 0, ethertype IPv4, 172.22.91.84 > 224.0.0.2: igmp leave 239.255.3.1 13:47:51.628223 64:ee:b7:13:cc:d9 > 01:00:5e:00:00:02, ethertype 802.1Q (0x8100), length 60: vlan 970, p 0, ethertype IPv4, 172.22.91.84 > 224.0.0.2: igmp leave 239.255.1.10 На IOS коммутаторах все это работает норм, даже без дублирования. На нексусе - ни в какую. Плз просветите, если кому ведомо решение/костыль Заранее спасибо и все такое.

Насчет использования как L3 - какие аргументы по не-использованию-то ? один из таких несколько лет гоняет гиг 500 между несколькими SVI, штук 12 bgp сессий (без full естественно) что еще от него ожидать за его стоимость ? версия у нас 6.хх какая-то, работает - смысл трогать ?

Всем доброго дня. Хорошо бы от 500 шт, чтобы не возиться с мелкими партиями. Хотя, в принципе, можно начать с любого кол-ва от 50

Приставки работают со Сталкером (Middlw) ?

Всем доброго дня. Плз подскажите, на 3064 хоть в какой-нибудь прошивке выше 6.ххх есть возможность включитиь mvr ? В n5k это есть, в какой-то новой серии 3600 тоже есть. Заранее спс и все такое.

Всем доброго дня. Насчет кол-ва маков, которые может переварить 3064 - там явно не 32К, ибо сейчас на одном таком: show mac address-table count MAC Entries for all vlans: Dynamic Address Count: 105384 Вланов порядка 470. Софт еще 6 ветки, но нареканий нет - поэтому не меняем. С подобным глюком за 3 года эксплуатации ни разу не встречались, хотя петли бывали.

сони в целом реагирует достаточно доброжелательно на запросы по разбану адресов из НАТ пула конечно, если в сети обитают махровые "хакеры", пытающиеся раз-за-разом нае..ть соню - юзать "левые" акки и тд. - это будет отягчающим обстоятельством

BGP + НАТ на линуксе, проц - Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz 2 сетевые карты DA520, порты в 2х2 lacp В пике тянет 13.5Гиг на вход, 1.5 на выход , потом softirq съедает процессор. сервер собран в 14 году, потом диски перенесены были на более новый комплект железа. На такой же задаче, как у XaTTa6bl4 держим сервер на FreeBSD 8.4, проц. Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz гоняет 9.1 / 1 Гбит, la в пике 3, top кажет минимальный idle 35%

плз подскажите в контексте "фрю с карпом" если БГП вращается, то что-то не нашел настроек как сделать. Это реально ? пока просто 2 сервера с своими настройками бгп.

первым делом сделали - адрес на нотник прилетел по dhcp нормально, но мак-адрес на нексусе не появлялся в таблице маков. Средствами нексуса сняли дамп по мак-адресу, в процессор dhcp пакет от устройства попадает (inband-low) - но в таблице мака нет: Frame 1: 444 bytes on wire (3552 bits), 348 bytes captured (2784 bits) on interface 0 Interface id: 0 Encapsulation type: Ethernet (1) Arrival Time: Oct 17, 2019 18:28:05.221254000 KGT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1571315285.221254000 seconds [Time delta from previous captured frame: 0.000000000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 0.000000000 seconds] Frame Number: 1 Frame Length: 444 bytes (3552 bits) Capture Length: 348 bytes (2784 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:vlan:ip:udp:bootp] Ethernet II, Src: 00:1a:79:51:56:54 (00:1a:79:51:56:54), Dst: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff) Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff) Address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) Source: 00:1a:79:51:56:54 (00:1a:79:51:56:54) Address: 00:1a:79:51:56:54 (00:1a:79:51:56:54) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: 802.1Q Virtual LAN (0x8100) 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 207 000. .... .... .... = Priority: Best Effort (default) (0) ...0 .... .... .... = CFI: Canonical (0) .... 0000 1100 1111 = ID: 207 Type: IP (0x0800) Internet Protocol Version 4, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 330 Identification: 0x0000 (0) Flags: 0x00 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (17) Header checksum: 0x79a4 [correct] [Good: True] [Bad: False] Source: 0.0.0.0 (0.0.0.0) Destination: 255.255.255.255 (255.255.255.255) User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67) Source port: 68 (68) Destination port: 67 (67) Length: 310 Checksum: 0x1357 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Bootstrap Protocol Message type: Boot Request (1) Hardware type: Ethernet (0x01) Hardware address length: 6 Hops: 0 Transaction ID: 0x7b78aa25 Seconds elapsed: 16141 Bootp flags: 0x0000 (Unicast) 0... .... .... .... = Broadcast flag: Unicast .000 0000 0000 0000 = Reserved flags: 0x0000 Client IP address: 0.0.0.0 (0.0.0.0) Your (client) IP address: 0.0.0.0 (0.0.0.0) Next server IP address: 0.0.0.0 (0.0.0.0) Relay agent IP address: 0.0.0.0 (0.0.0.0) Client MAC address: 00:1a:79:51:56:54 (00:1a:79:51:56:54) Client hardware address padding: 00000000000000000000 Server host name not given Boot file name not given Magic cookie: DHCP Option: (53) DHCP Message Type Length: 1 DHCP: Discover (1) Option: (61) Client identifier Length: 7 Hardware type: Ethernet (0x01) Client MAC address: 00:1a:79:51:56:54 (00:1a:79:51:56:54) Option: (57) Maximum DHCP Message Size Length: 2 Maximum DHCP Message Size: 576 Option: (55) Parameter Request List Length: 8 Parameter Request List Item: (1) Subnet Mask Parameter Request List Item: (3) Router Parameter Request List Item: (6) Domain Name Server Parameter Request List Item: (12) Host Name Parameter Request List Item: (15) Domain Name Parameter Request List Item: (28) Broadcast Address Parameter Request List Item: (42) Network Time Protocol Servers Parameter Request List Item: (43) Vendor-Specific Information Option: (60) Vendor class identifier Length: 13 Vendor class identifier: InfomirMAG322 Option: (82) Agent Information Option Length: 18 Option 82 Suboption: (1) Agent Circuit ID Length: 6 Agent Circuit ID: 000400cf0101 Option 82 Suboption: (2) Agent Remote ID Length: 8 Agent Remote ID: 0006189c5d2dcc00 Option: (255) End Option End: 255

нет, в логах все чисто. Более того, если этот мак внести статиком - все снова начинает нормально работать, статик/динамик - коллизия бы никуда не делась бы.

А как узнать ?

NXOS 6.0(2)U5(3) где-то 113К маков на борту. Проблема пока только с одним. Конфиг примитивен, как и его функция в целом. Если какой-то конкретный участок конфига может вызвать сомнения - плз озвучьте. Это чтобы всю портянку не вываливать.

Всем доброго дня. в эксплуатации Nexus 3064 вылез странный глюк с обучением мак-адреса устройства - ни в какую не хочет помещать в таблицу. Суть такова: к nex3064 подключен c2960, к 2960 подключены 2 устройства одного типа. Оба должны получать адрес по dhcp. Оба шлют правильные discover, которые доходят до dhcp-сервера, и этот сервер на них отвечает. Причем dhcp пакеты проходят насквозь через 2960 и целевой nexus. Вот здесь начинается прикол. До одного из устройств offer доходит, до второго нет. Разбор показал, что мак-адрес первого устройства (которое получает offer от dhcp-сервера) внесен в таблицу мак-адресов на nexus, а мак второго - никак не хочет изучаться и вноситься в таблицу. Причем, если внести мак адрес статиком - все начинает работать, offer доходит. Удалить статическую запись - мак снова перестает фиксироваться в таблице. Вот сами маки: корявый - 00:1a:79:51:56:54 нормальный - 00:1a:79:3b:5c:fb Может кто-то сталкивался с подобным ? Будем признательны за любую подсказку

не, на не маленькой сети в мст переходить - лучше в 512 вланах жить (имхо).

Проверили по ссылке выше - к домену претензий нет: По Вашему запросу ничего не найдено Значит, одними и теми же IP адресами у CloudFlare прикрыты множество сайтов. Вряд ли РКН что-то изменит, если их вежливо попросить убрать данные адреса из списка ?

Всем доброго дня. Плз подскажите, если кому не лень будет, есть что-то радикально другое в прошивках 9.Х в отличии от 6.Х ? Я бы обновился, если бы кол-во активных вланов выросло бы выше 512, но это же аппаратное ограничение.

Спасибо, а то был ответ от РКН, мол к сайту претензий не имеем. Значит прицепом.

Коллеги, доброго дня. Просьба, у кого есть возможность, глянуть - нет ли в списке на блокировку адресов : Address: 104.24.124.213 Address: 104.24.125.213 Это адреса CloudFlare, за ними оказался сайтец, весьма популярный в нашем конце географии - СНГ, но не РФ. Наши арбайтеры в РФ с него, в том числе, черпали инфу о том, все ли у нас сдохло, или что то еще есть живое. Может он прицепом оказался в выгрузке ? Причем резолв и пинги на эти адреса ходят, а браузер дает ошибку соединения. Заранее спасибо и все такое .

нет, это коммутаторы с простой задачей без шансов на получение full. из того, что успели зафиксировать - вырос параметр FWM_MEM_fwm_temp_t Но, есть ли корреляция или нет - не понятно.