Azamat
-
Публикации
316 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем Azamat
-
-
там один единственный 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.хх какая-то, работает - смысл трогать ?
-
Опубликовано · Изменено пользователем Azamat · Жалоба на ответ
Всем доброго дня.
Хорошо бы от 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 года эксплуатации ни разу не встречались, хотя петли бывали.
-
сони в целом реагирует достаточно доброжелательно на запросы по разбану адресов из НАТ пула
конечно, если в сети обитают махровые "хакеры", пытающиеся раз-за-разом нае..ть соню - юзать "левые" акки и тд. - это будет отягчающим обстоятельством
-
Опубликовано · Изменено пользователем Azamat · Жалоба на ответ
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 сервера с своими настройками бгп.
-
Опубликовано · Изменено пользователем Azamat · Жалоба на ответ
первым делом сделали - адрес на нотник прилетел по 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
Но, есть ли корреляция или нет - не понятно.
Соседняя страна. Попытка навязать лицензию на использование радиочастот на ПРИЕМ со спутника.
в Работа с бумагами
Опубликовано · Жалоба на ответ
Всем доброго дня.
Находимся в ЕАЭС, но не РФ. Законодательство в целом калька с РФ/ЕАЭС.
Получаем сигнал со спутника и ретранслируем в IPTV
Сейчас вдруг пытаются навязать лицензию на использование радиочастот. Типа/мотивация - вы же используете частоту на прием сигнала.
Как бы отбиться от такого буквального трактования термина - использование раодичастотного спектра ? Для всех, кто в теме, очевидно - использование = передача на этой частоте.
Но лицензия на прием - это что-то новое.