-
/habralogo.jpg)
Сетевые протоколы и т.п.
Перенос из темы «Кто что делает, компьютерный вариант [часть 4]»Теги:
/habralogo.jpg)
Lamort
Интересное явление, может кто и сталкивался. 
У нас стоит радиоканал, за ним коммутатор cisco 2950, так вот, у него куда-то исчез не только IP, но и MAC, однако при этом всё работает, причём через это соединение идёт устойчивый трафик.
По причине большой лени и нежелания тащиться именно в эту организацию мы смотрим и удивляемся, но ничего не делаем.
Я понимаю, что у коммутатора MAC может отсутствовать, за ненадобностью, но тут он был и куда-то делая без влияния на работу сети.
Может быть кто-то видел что-то подобное?
У нас стоит радиоканал, за ним коммутатор cisco 2950, так вот, у него куда-то исчез не только IP, но и MAC, однако при этом всё работает, причём через это соединение идёт устойчивый трафик.
По причине большой лени и нежелания тащиться именно в эту организацию мы смотрим и удивляемся, но ничего не делаем.
Я понимаю, что у коммутатора MAC может отсутствовать, за ненадобностью, но тут он был и куда-то делая без влияния на работу сети.
Может быть кто-то видел что-то подобное?
инфо
инструменты
Lamort> Может быть кто-то видел что-то подобное?
ЕМНИП, у коммутатора и то, и другое исключительно для управляющего интерфейса. Так что ничего удивительного. Просто удаленное управление невозможно.
ЕМНИП, у коммутатора и то, и другое исключительно для управляющего интерфейса. Так что ничего удивительного. Просто удаленное управление невозможно.
"Остановите Землю — я сойду" (С) Лесли Брикасс, Энтони Ньюли
Lamort>> Может быть кто-то видел что-то подобное?
Jerard> ЕМНИП, у коммутатора и то, и другое исключительно для управляющего интерфейса. Так что ничего удивительного. Просто удаленное управление невозможно.
Это ясно, в той же сети стоит несколько неуправляемых коммутаторов, их не видно вообще никак. Однако, интересна ситуация когда именно коммутатор cisco работает с такими вот "наполовину сломанными мозгами", причём с точки зрения работы именно как коммутатора это никак не проявляется.
Jerard> ЕМНИП, у коммутатора и то, и другое исключительно для управляющего интерфейса. Так что ничего удивительного. Просто удаленное управление невозможно.
Это ясно, в той же сети стоит несколько неуправляемых коммутаторов, их не видно вообще никак. Однако, интересна ситуация когда именно коммутатор cisco работает с такими вот "наполовину сломанными мозгами", причём с точки зрения работы именно как коммутатора это никак не проявляется.
Lamort> Однако, интересна ситуация когда именно коммутатор cisco работает с такими вот "наполовину сломанными мозгами",
Это его штатный режим после включения.Если не трогать УИ так и будет стоять.
>причём с точки зрения работы именно как коммутатора это никак не проявляется.
Это разные модули, причем физически.
P.S. Если туда никто не лазил (в УИ и "wr" НЕ писал) то можно просто перегрузить. Должно заработать.
Это его штатный режим после включения.Если не трогать УИ так и будет стоять.
>причём с точки зрения работы именно как коммутатора это никак не проявляется.
Это разные модули, причем физически.
P.S. Если туда никто не лазил (в УИ и "wr" НЕ писал) то можно просто перегрузить. Должно заработать.
"Остановите Землю — я сойду" (С) Лесли Брикасс, Энтони Ньюли
Jerard> Это его штатный режим после включения.Если не трогать УИ так и будет стоять.
Хотите сказать, что у него и мак-адреса тоже нет после включения?
Jerard> Это разные модули, причем физически.
Jerard> P.S. Если туда никто не лазил (в УИ и "wr" НЕ писал) то можно просто перегрузить. Должно заработать.
Там была установлена определённая конфигурация без которой он не мог бы нормально работать и, более того, периодически этот коммутатор "появляется в нормальном виде", но потом точно так же самопроизвольно исчезает.
Хотите сказать, что у него и мак-адреса тоже нет после включения?
Jerard> Это разные модули, причем физически.
Jerard> P.S. Если туда никто не лазил (в УИ и "wr" НЕ писал) то можно просто перегрузить. Должно заработать.
Там была установлена определённая конфигурация без которой он не мог бы нормально работать и, более того, периодически этот коммутатор "появляется в нормальном виде", но потом точно так же самопроизвольно исчезает.
Lamort> Хотите сказать, что у него и мак-адреса тоже нет после включения?
ХЗ, но работать ему это не помешает.
ХЗ, но работать ему это не помешает.
"Остановите Землю — я сойду" (С) Лесли Брикасс, Энтони Ньюли
Lamort>> Хотите сказать, что у него и мак-адреса тоже нет после включения?
Jerard> ХЗ, но работать ему это не помешает.
По-моему, если вообще нет IOS коммутатор cisco 2950 работать не будет никак, хотя, честно говоря, не уверен, надо попробовать, что получится.
Jerard> ХЗ, но работать ему это не помешает.
По-моему, если вообще нет IOS коммутатор cisco 2950 работать не будет никак, хотя, честно говоря, не уверен, надо попробовать, что получится.
Может ли кто пояснить откуда в Linux вылезает 15-секундый таймаут отсутствия данных от клиента, после которого сервер штатно закрывает TCP соединение?
Установка соединения:
18:47:16.385653 IP 127.0.0.1.65001 > 127.0.0.1.5044: Flags [S], seq 2509773856, win 43690, options [mss 65495,sackOK,TS val 1126526359 ecr 0,nop,wscale 7], length 0
18:47:16.385684 IP 127.0.0.1.5044 > 127.0.0.1.65001: Flags [S.], seq 4122977173, ack 2509773857, win 43690, options [mss 65495,sackOK,TS val 1126526359 ecr 1126526359,nop,wscale 7], length 0
18:47:16.385704 IP 127.0.0.1.65001 > 127.0.0.1.5044: Flags [.], ack 1, win 342, options [nop,nop,TS val 1126526359 ecr 1126526359], length 0
Передача данных:
18:47:16.388096 IP 127.0.0.1.65001 > 127.0.0.1.5044: Flags [P.], seq 1:3, ack 1, win 342, options [nop,nop,TS val 1126526362 ecr 1126526359], length 2
[вырезано]
18:47:16.417621 IP 127.0.0.1.5044 > 127.0.0.1.65001: Flags [P.], seq 1:7, ack 1944, win 1024, options [nop,nop,TS val 1126526391 ecr 1126526362], length 6
18:47:16.417638 IP 127.0.0.1.65001 > 127.0.0.1.5044: Flags [.], ack 7, win 342, options [nop,nop,TS val 1126526391 ecr 1126526391], length 0
Клиент ждет данных или какого-то события:
18:47:31.397478 IP 127.0.0.1.5044 > 127.0.0.1.65001: Flags [F.], seq 7, ack 1944, win 1024, options [nop,nop,TS val 1126541371 ecr 1126526391], length 0
18:47:31.436920 IP 127.0.0.1.65001 > 127.0.0.1.5044: Flags [.], ack 8, win 342, options [nop,nop,TS val 1126541411 ecr 1126541371], length 0
Сервер закрыл соединение, упс.
keepalive тут совсем не причем, поскольку по умолчанию:
148 #define TCP_KEEPALIVE_TIME (120*60*HZ) /* two hours /
149 #define TCP_KEEPALIVE_PROBES 9 / Max of 9 keepalive probes */
150 #define TCP_KEEPALIVE_INTVL (75*HZ)
Установка соединения:
18:47:16.385653 IP 127.0.0.1.65001 > 127.0.0.1.5044: Flags [S], seq 2509773856, win 43690, options [mss 65495,sackOK,TS val 1126526359 ecr 0,nop,wscale 7], length 0
18:47:16.385684 IP 127.0.0.1.5044 > 127.0.0.1.65001: Flags [S.], seq 4122977173, ack 2509773857, win 43690, options [mss 65495,sackOK,TS val 1126526359 ecr 1126526359,nop,wscale 7], length 0
18:47:16.385704 IP 127.0.0.1.65001 > 127.0.0.1.5044: Flags [.], ack 1, win 342, options [nop,nop,TS val 1126526359 ecr 1126526359], length 0
Передача данных:
18:47:16.388096 IP 127.0.0.1.65001 > 127.0.0.1.5044: Flags [P.], seq 1:3, ack 1, win 342, options [nop,nop,TS val 1126526362 ecr 1126526359], length 2
[вырезано]
18:47:16.417621 IP 127.0.0.1.5044 > 127.0.0.1.65001: Flags [P.], seq 1:7, ack 1944, win 1024, options [nop,nop,TS val 1126526391 ecr 1126526362], length 6
18:47:16.417638 IP 127.0.0.1.65001 > 127.0.0.1.5044: Flags [.], ack 7, win 342, options [nop,nop,TS val 1126526391 ecr 1126526391], length 0
Клиент ждет данных или какого-то события:
18:47:31.397478 IP 127.0.0.1.5044 > 127.0.0.1.65001: Flags [F.], seq 7, ack 1944, win 1024, options [nop,nop,TS val 1126541371 ecr 1126526391], length 0
18:47:31.436920 IP 127.0.0.1.65001 > 127.0.0.1.5044: Flags [.], ack 8, win 342, options [nop,nop,TS val 1126541411 ecr 1126541371], length 0
Сервер закрыл соединение, упс.
keepalive тут совсем не причем, поскольку по умолчанию:
148 #define TCP_KEEPALIVE_TIME (120*60*HZ) /* two hours /
149 #define TCP_KEEPALIVE_PROBES 9 / Max of 9 keepalive probes */
150 #define TCP_KEEPALIVE_INTVL (75*HZ)
Floyd> Может ли кто пояснить откуда в Linux вылезает 15-секундый таймаут отсутствия данных от клиента, после которого сервер штатно закрывает TCP соединение?
я бы для начала в сторону TCP SYN FIN копнул, какие tcp_syn_retries стоят?
я бы для начала в сторону TCP SYN FIN копнул, какие tcp_syn_retries стоят?
с.т.> я бы для начала в сторону TCP SYN FIN копнул, какие tcp_syn_retries стоят?
6, по умолчанию. Но этот параметр оказывает влияние только на этап установки соединения.
А в моем случае оно уже установлено, но бездействует.
Задал TCP_KEEPALIVE_TIME и TCP_KEEPALIVE_INTVL значения по 5 секунд, без каких либо результатов, даже syn пакеты не пошли.
6, по умолчанию. Но этот параметр оказывает влияние только на этап установки соединения.
А в моем случае оно уже установлено, но бездействует.
Задал TCP_KEEPALIVE_TIME и TCP_KEEPALIVE_INTVL значения по 5 секунд, без каких либо результатов, даже syn пакеты не пошли.
а что в целом говорит
sysctl net.inet.tcp
зы а вот глупая мысль пришла в голову...а это не может сам сервер закрывать коннект?
sysctl net.inet.tcp
зы а вот глупая мысль пришла в голову...а это не может сам сервер закрывать коннект?
с.т.> а что в целом говорит
с.т.> sysctl net.inet.tcp
с.т.> зы а вот глупая мысль пришла в голову...а это не может сам сервер закрывать коннект?
Все по умолчанию, из коробки.
Ты имеешь в виду приложение? В таком случае точно нет. Поскольку с таким поведением я столкнулся в двух абсолютно не связанных случаях. Хотя нет, объединяет их то что оба серверных приложения Java EE, а клиенты написаны на Си.
Вот кстати, нечто подобное на stackoverflow
с.т.> sysctl net.inet.tcp
с.т.> зы а вот глупая мысль пришла в голову...а это не может сам сервер закрывать коннект?
Все по умолчанию, из коробки.
Ты имеешь в виду приложение? В таком случае точно нет. Поскольку с таким поведением я столкнулся в двух абсолютно не связанных случаях. Хотя нет, объединяет их то что оба серверных приложения Java EE, а клиенты написаны на Си.
Вот кстати, нечто подобное на stackoverflow
want to change TCP closing timeout
We have a client server application in use on our suse linux server. Sometimes it happens, that on the client side the tcp socket somehow goes away and on the server side the other end of the socket // stackoverflow.com
Floyd> Вот кстати, нечто подобное на stackoverflow
Floyd> linux - want to change TCP closing timeout - Stack Overflow
попробуй с tcp_frto поколдовать тогда
может действительно из-за RTO такой эффект
ps и полюбому...я не знаю что там у тебя за ява и что за апликухи...ну допустим нестареющая классика апач-томкат (ну и там сверху что хочешь, крайний раз градле попападалась которая через томкат-WAR дергает приложения-сервлеты)..так вот, там есть таймауты на уровне сервера приложений - как минимум в самом томакат-апаче...стоит там где-то у тебя в конфиге томкат-апача (или там вебсферы которая тот же апач)
что-то типа
Timeout 300
KeepAlive On
MaxKeepAliveRequests 0
KeepAliveTimeout 15
MinSpareServers 16
MaxSpareServers 64
StartServers 16
MaxClients 512
и хоть ты весь TCP стек перепиши....а будет тебе 15 секунд
уж больно знакомое число )))
connectionTimeout
The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 60000 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 20000 (i.e. 20 seconds). Unless disableUploadTimeout is set to false, this timeout will also be used when reading the request body (if any).
20 секунд...у тебя может где-то 15 прописано, после чего он молча гасит коннект
Floyd> linux - want to change TCP closing timeout - Stack Overflow
попробуй с tcp_frto поколдовать тогда
может действительно из-за RTO такой эффект
ps и полюбому...я не знаю что там у тебя за ява и что за апликухи...ну допустим нестареющая классика апач-томкат (ну и там сверху что хочешь, крайний раз градле попападалась которая через томкат-WAR дергает приложения-сервлеты)..так вот, там есть таймауты на уровне сервера приложений - как минимум в самом томакат-апаче...стоит там где-то у тебя в конфиге томкат-апача (или там вебсферы которая тот же апач)
что-то типа
Timeout 300
KeepAlive On
MaxKeepAliveRequests 0
KeepAliveTimeout 15
MinSpareServers 16
MaxSpareServers 64
StartServers 16
MaxClients 512
и хоть ты весь TCP стек перепиши....а будет тебе 15 секунд
уж больно знакомое число )))
Apache Tomcat 7 Configuration Reference (7.0.72) - The HTTP Connector
Links Top Level Elements Executors Connectors Containers Nested Components Cluster Elements web.xml Other The HTTP Connector element represents a Connector component that supports the HTTP/1.1 protocol. It enables Catalina to function as a stand-alone web server, in addition to its ability to execute servlets and JSP pages. A particular instance of this component listens for connections on a specific TCP port number on the server. One or more such Connectors can be configured as part of a single Service, each forwarding to the associated Engine to perform request processing and create the response. // Дальше — tomcat.apache.orgconnectionTimeout
The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 60000 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 20000 (i.e. 20 seconds). Unless disableUploadTimeout is set to false, this timeout will also be used when reading the request body (if any).
20 секунд...у тебя может где-то 15 прописано, после чего он молча гасит коннект
Это сообщение редактировалось 27.09.2016 в 08:42
с.т.> 20 секунд...у тебя может где-то 15 прописано, после чего он молча гасит коннект
Так оно и есть. client_inactivity_timeout по дефолту 15 секунд.
Правда изменение этого параметра никак не отразилось на поведении ПО, печаль
Так оно и есть. client_inactivity_timeout по дефолту 15 секунд.
Правда изменение этого параметра никак не отразилось на поведении ПО, печаль
Mishka
с.т.>> 20 секунд...у тебя может где-то 15 прописано, после чего он молча гасит коннект
Floyd> Так оно и есть. client_inactivity_timeout по дефолту 15 секунд.
Floyd> Правда изменение этого параметра никак не отразилось на поведении ПО, печаль
Это фича джавы.
ServerSocket (Java Platform SE 7 ) и Socket (Java Platform SE 7 ) — посмотри на setSoTimeout метод. Он немного означает разное для серверного сокета и клиентского сокета. Но после того, как в сервеном сокете accept вернул управление, то в качестве результата он возвращает обычный клиентский сокерт (Socket), в котором первым же вызовом часто ставят это дело:
Работает совершенно независимо от TCP keep alive. Устанавливается, обычно (если вообще устанавливается) через джава проперти файл. При этом сервер надо перезагружать.
Floyd> Так оно и есть. client_inactivity_timeout по дефолту 15 секунд.
Floyd> Правда изменение этого параметра никак не отразилось на поведении ПО, печаль
Это фича джавы.
ServerSocket (Java Platform SE 7 ) и Socket (Java Platform SE 7 ) — посмотри на setSoTimeout метод. Он немного означает разное для серверного сокета и клиентского сокета. Но после того, как в сервеном сокете accept вернул управление, то в качестве результата он возвращает обычный клиентский сокерт (Socket), в котором первым же вызовом часто ставят это дело:
code java
- client.setSoTimeout( 15 * 1000 ); // 15 seconds
Работает совершенно независимо от TCP keep alive. Устанавливается, обычно (если вообще устанавливается) через джава проперти файл. При этом сервер надо перезагружать.
Mishka> Это фича джавы.
Миша, спасибо, это оно!
Миша, спасибо, это оно!
- Последние действия над темой
- Balancer [09.01.2013 04:16]: Тема создана из Кто что делает, компьютерный вариант [часть 4]
- Balancer [09.01.2013 04:17]: Перенос сообщений из Кто что делает, компьютерный вариант [часть 4]
- Все действия над темой
Copyright © Balancer 1997..2018
Создано 14.12.2012
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 14.12.2012
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
