Jump to content

ISC-DHCP мусорит в лог (повторяющиеся запросы)

infery
 Share

Recommended Posts

infery

infery

Posted
Posted (edited)

Картинка сети: network

Добрый вечер. Подскажите, пожалуйста, по следующей проблеме. В логах ISC-DHCP-SERVER появляется куча вот таких сообщений:

192.168.100.1 - cisco c ip-helper, 192.168.100.3 - DHCP сервер, 192.168.100.111 - абонент

 

 

 

Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPREQUEST for 192.168.100.111 from 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPACK on 192.168.100.111 to 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPREQUEST for 192.168.100.111 from 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPACK on 192.168.100.111 to 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPREQUEST for 192.168.100.111 from 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPACK on 192.168.100.111 to 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPREQUEST for 192.168.100.111 from 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPACK on 192.168.100.111 to 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPREQUEST for 192.168.100.111 from 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPACK on 192.168.100.111 to 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPREQUEST for 192.168.100.111 from 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPACK on 192.168.100.111 to 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPREQUEST for 192.168.100.111 from 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPACK on 192.168.100.111 to 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPREQUEST for 192.168.100.111 from 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPACK on 192.168.100.111 to 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPREQUEST for 192.168.100.111 from 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPACK on 192.168.100.111 to 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPREQUEST for 192.168.100.111 from 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPACK on 192.168.100.111 to 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1
Aug 22 18:45:27 debian-dhcp-server dhcpd: DHCPREQUEST for 192.168.100.111 from 00:1a:4d:f8:dc:91 (sfetgwg) via 192.168.100.1

 

 

 

Конфиг интерфейса на циске (для примера, все вланы настроены аналогично):

 

 

 

interface Vlan136
ip unnumbered Loopback10
ip helper-address 192.168.100.3
no ip redirects
no ip unreachables
ip local-proxy-arp
ip route-cache same-interface
end

 

 

 

циска подключена к коммутатору dlink, который выступает просто l2 транспортом (просто куча вланов на итерфейсах). С DLink запускаются edge-core 3510 вот с таким конфигом:

 

 

sntp server 0.0.0.0 0.0.0.0 0.0.0.0
!
!
!
!
no cluster
!
clock timezone-predefined GMT-Greenwich-Mean-Time-Dublin,Edinburgh,Lisbon,London
broadcast bit-rate 80 level 5
multicast bit-rate 80 level 5
unicast bit-rate 80 level 5
!
no dot1q-tunnel system-tunnel-control
!         
!
snmp-server community public ro
snmp-server community private rw
!
!
username admin access-level 15
username admin password 7 21232f297a57a5a743894a0e4a801fc3
username guest access-level 0
username guest password 7 084e0343a0486ff05530df6c705c8bb4
enable password level 15 7 1b3231655cebb7a1f783eddf27d254ca
!
!
no logging trap
!
!
!
!
!
vlan database
vlan 1 name DefaultVlan media ethernet state active
vlan 10 name manage media ethernet state active
vlan 100 media ethernet state active

****************<пропустил 200 вланов>

vlan 300 media ethernet state active
vlan 4093 media ethernet state active
!
!
!
!
!
!
spanning-tree MST configuration
!

ip dhcp snooping
ip dhcp snooping vlan 128
ip dhcp snooping information option
ip dhcp snooping information policy keep
!
no lldp
!

interface VLAN 1
!
interface VLAN 10
IP address 172.16.0.28 255.255.0.0
!
interface VLAN 100
!
<пропустил 200 вланов>
!
interface VLAN 300
!
interface VLAN 4093
!         
interface ethernet 1/1
switchport allowed vlan add 128 untagged
switchport allowed vlan add 4093 tagged
switchport native vlan 128
switchport allowed vlan remove 1
!
interface ethernet 1/2
switchport allowed vlan add 128 untagged
switchport allowed vlan add 4093 tagged
switchport native vlan 128
switchport allowed vlan remove 1
!
interface ethernet 1/3
switchport allowed vlan add 128 untagged
switchport allowed vlan add 4093 tagged
switchport native vlan 128
switchport allowed vlan remove 1
!
interface ethernet 1/4
switchport allowed vlan add 128 untagged
switchport allowed vlan add 4093 tagged
switchport native vlan 128
switchport allowed vlan remove 1
!
interface ethernet 1/5
switchport allowed vlan add 128 untagged
switchport allowed vlan add 4093 tagged
switchport native vlan 128
switchport allowed vlan remove 1
!
interface ethernet 1/6
switchport allowed vlan add 128 untagged
switchport allowed vlan add 4093 tagged
switchport native vlan 128
switchport allowed vlan remove 1
!
interface ethernet 1/7
switchport allowed vlan add 128 untagged
switchport allowed vlan add 4093 tagged
switchport native vlan 128
switchport allowed vlan remove 1
!         
interface ethernet 1/8
switchport allowed vlan add 128 untagged
switchport allowed vlan add 4093 tagged
switchport native vlan 128
switchport allowed vlan remove 1
!
interface ethernet 1/9
ip dhcp snooping trust
switchport acceptable-frame-types tagged
switchport mode trunk
switchport allowed vlan add 1,10,100-300,4093 tagged
switchport native vlan 1
!
interface ethernet 1/10
ip dhcp snooping trust
switchport acceptable-frame-types tagged
switchport mode trunk
switchport allowed vlan add 1,10,100-300,4093 tagged
switchport native vlan 1
!
!
ip default-gateway  172.16.0.1
!

line console
silent-time 0
!
!
line VTY
!
!
!
end
!

 

 

 

на сервере option82 Отлавливаются так:

 

 

authoritative;
local-address 192.168.100.3;
ddns-update-style none;
ddns-update-style none;
ignore client-updates;
option wpad code 252 = text; 
option wpad "\n";

..........................

class "match_p_1_sw_012cf8b490" {
 match if binary-to-ascii(16, 8, ":", substring(option agent.remote-id, 2, 6)) = "0:12:cf:8b:4:90"
 and
 binary-to-ascii(10, 8, "", substring(option agent.circuit-id, 5, 1)) = "1";
}
pool {
 range 192.168.100.111;
 allow members of "match_p_1_sw_012cf8b490";
}

 

 

 

Вот так для каждого абонента сыпется в лог. Подскажите куда копать, кто виноват. Может это нормально вообще? Спасибо

post-106944-081664300 1377184723_thumb.png

Edited by infery
vurd

vurd

Posted
Posted

А с чего вы взяли, что проблема в DHCP-сервере? Судя по названию темы, вы так предполагаете?

По логу видно, что клиент хочет взять таки адрес "REQUEST", на что ему сервер таки его дает "ACK", но он у него не берется? Зачем клиент снова запрашивает "давай подтвердим этот адрес".

Вам нужно посомтреть что происходит на клиентах и станет ясно в чем причина.

infery

infery

Posted
  • Author
Posted (edited)

Еще немного логов:

 

 

 

Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPINFORM from 192.168.100.62 via 192.168.100.1
Aug 22 22:28:01 debian-dhcp-server dhcpd: DHCPACK to 192.168.100.62 (00:14:85:1e:30:a6) via eth0

 

 

 

Конфиг сети из dhcpd.conf

subnet 192.168.100.0 netmask 255.255.255.0 { 
option domain-name-servers 192.168.100.3; 
option subnet-mask 255.255.255.0; 
option routers 192.168.100.1; 
max-lease-time 3600; 
default-lease-time 3600;

 

Грешу на сервер потому, что проблема не с одним абонентом, а практически со всеми, кто за эджкорами. Есть SNR, подключенный к DLink, с абонентами на нем таких ситуаций не возникает. Опять же IP ловится исправно, но боюсь накопления критической массы, когда абонентов станет больше, не хочу пускать на самотек

 

P.S. В интернете ссылаются на виндовую автонастройку proxy. К сожалению не могу проверить

Edited by infery
srg555

srg555

Posted
Posted

информ это венда просит доп.параметры. на форуме бы рецепт избавления от этого

 

хотяудя пл таймстемпам больше похоже на баг или петлю. dhcp запросы идентичные или ид таки разные?

infery

infery

Posted
  • Author
Posted (edited)

информ это венда просит доп.параметры. на форуме бы рецепт избавления от этого

 

хотяудя пл таймстемпам больше похоже на баг или петлю. dhcp запросы идентичные или ид таки разные?

 

Такие информы от разных абонентов, я так понимаю паки до них не моментально доходят и они долбят снова и снова. Больше грешу на эджкоры даже, но это скорей по неопытности в работе с ними.

 

Вот линк на dhcpdump в момент флуда dump

Edited by infery
Negator

Negator

Posted
Posted

1. Рекомендую заменить:

class "match_p_1_sw_012cf8b490" {  match if binary-to-ascii(16, 8, ":", substring(option agent.remote-id, 2, 6)) = "0:12:cf:8b:4:90"  and  binary-to-ascii(10, 8, "", substring(option agent.circuit-id, 5, 1)) = "1";

на

class "sw_10.1.1.253" match if binary-to-ascii(10, 8, ".", packet(24, 4))="10.1.1.253" and binary-to-ascii(10, 8, "", substring(option agent.circuit-id, 5, 1)) = "1";

где 10.1.1.253 = IP коммутатора откуда прилетает запрос. Таким образом remote_id не нужен вовсе.

 

А далее вопросы:

В вашей схеме релеит циска. Почему сервер настроен отдавать адреса по opt_82 по порту?

Налицо явные проблемы с настройкой коммутаторов доступа.

infery

infery

Posted
  • Author
Posted (edited)

Клиенты то при этом работают или как?

Какая киска?

На ме3400g пришлось довольствоваться proxy-arp.

 

Абоненты IP ловят, работают. К сожалению, не могу проверить насколько быстро они ловят ip и как гладко это происходит.

c3750-ipbasek9-mz.122-50.SE5/c3750-ipbasek9-mz.122-50.SE5.bin, WS-C3750G-12S

 

1. Рекомендую заменить:

В эти выходные скорей всего уже не получится, но при первой возможности попробую и отпишусь. используем opt82, потому что и было задумано использовать opt82.

Edited by infery
infery

infery

Posted
  • Author
Posted

1. Рекомендую заменить:

class "match_p_1_sw_012cf8b490" {  match if binary-to-ascii(16, 8, ":", substring(option agent.remote-id, 2, 6)) = "0:12:cf:8b:4:90"  and  binary-to-ascii(10, 8, "", substring(option agent.circuit-id, 5, 1)) = "1";

на

class "sw_10.1.1.253" match if binary-to-ascii(10, 8, ".", packet(24, 4))="10.1.1.253" and binary-to-ascii(10, 8, "", substring(option agent.circuit-id, 5, 1)) = "1";

где 10.1.1.253 = IP коммутатора откуда прилетает запрос. Таким образом remote_id не нужен вовсе.

 

А далее вопросы:

В вашей схеме релеит циска. Почему сервер настроен отдавать адреса по opt_82 по порту?

Налицо явные проблемы с настройкой коммутаторов доступа.

 

В запросе всегда прилетает ip релея, т.е. циски, но никак не коммутатора.

infery

infery

Posted
  • Author
Posted

Победил данный "баг/фичу" следующим способом:

ip dhcp snooping vlan 100-300

 

В ходе тестов выяснилось, что каждый еджкор со включенным снуппингом повторял запрос, пришедший с downlink. Не знаю чей это косяк, прошивка последняя.

wtyd

wtyd

Posted
Posted (edited)

Победил данный "баг/фичу" следующим способом:

ip dhcp snooping vlan 100-300

 

В ходе тестов выяснилось, что каждый еджкор со включенным снуппингом повторял запрос, пришедший с downlink. Не знаю чей это косяк, прошивка последняя.

 

Какие модели e-core используются ? Случайно dhcp relay не включен на корках ? Ну и какая именно версия прошивки используется ?

Edited by wtyd
infery

infery

Posted
  • Author
Posted

wtyd

     CLI session with the ES3510 is opened.
     To end the CLI session, enter [Exit].

Vty-0#sh ver
Serial Number:           **************
Service Tag:             
Hardware Version:        R01
EPLD Version:            0.00
Number of Ports:         10
Main Power Status:       Up
Loader Version:          1.0.0.2
Boot ROM Version:        1.0.0.5
Operation Code Version:  1.1.0.39

Vty-0#sh ip dhcp relay 
Status of DHCP relay information:
Insertion of relay information: disabled.
DHCP option policy: drop.
DHCP relay-server address: 0.0.0.0, 0.0.0.0, 0.0.0.0, 0.0.0.0, 0.0.0.0
DHCP sub-option format: extra subtype included
DHCP remote id sub-option: mac address (hex encoded)
DHCP option TR101 board id:
Interface   Circuit-ID Mode
----------  ---------------
Eth 1/1     Vlan-Unit-Port 
Eth 1/2     Vlan-Unit-Port 
Eth 1/3     Vlan-Unit-Port 
Eth 1/4     Vlan-Unit-Port 
Eth 1/5     Vlan-Unit-Port 
Eth 1/6     Vlan-Unit-Port 
Eth 1/7     Vlan-Unit-Port 
Eth 1/8     Vlan-Unit-Port 
Eth 1/9     Vlan-Unit-Port 
Eth 1/10    Vlan-Unit-Port

wtyd

wtyd

Posted
Posted

Ну ... печалька. Коммутаторы давно EoL. Я сам не могу собрать стенд и проверить - в наличии только один такой мутатор. Однако, судя по логам, косвенное подтверждение сказанного вами есть, т.е. я не могу на 100 процентов утверждать, что включенные цепочкой корки повторяют запрос, но вижу в логах по несколько одинаковых запросов в секундные интервалы времени. Очень может быть, что происходит то же что и у вас.

 

Попробуйте написать на форуме вимкоме или им на е-маил. Может быть, если удастся воспроизвести баг, вендор выпустит ещё одну прошивку с фиксом.

 

Вообще, стали сталкиваться с тем, что у абонента всё работало месяцами и даже годами, потом вдруг почему-то винда получает адрес, но получить не может. Думаем, что это очередные обновления винды так сделали, больше-то ничего не менялось. Может винда стала слать какие-то не такие как раньше запросы и е-корки их обратно вернуть не могут (до сервера запросы долетают).

 

Кстати, мне е-коры именно этим и не нравятся, что у них за время жизни продукта не успевают допилить софт к нему до юзабельного уровня, потом говорят "а всё, свич стал EoL, покупайте новые модели". Ну конечно никто в здравом уме не начинает менять все свичи доступа на новые модели того же вендора потому что они стали EoL, все начинают думать о смене вендора при новых закупках оборудования :-).

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.