Hello,
Its very strange issue. At first look It looks like a problem on the network, First problems appeared 2/2022, b-stations did freeze every week till 4/2022, then IT operator removed some restriction on switcher port.
Then the B-station probably worked properly until 11/2022, when there was some upgrade on the network elements and there start the problems with the B-stations freezing again. After consulting with the network administrators, the administrator told us that he had already removed all port protections and could not remove anything else. The situation has improved, but the controllers still freeze occasionally. When we tried to communicate with the administrator again, he told us that there was nothing more he could do and that the fault would be on the device's side, as all the other devices on the network were fine except for the B-stations. He also told us that he doesn't want to deal with a device he doesn't know anymore because it's not his responsibility and it's up to the supplier and the manufacturer.
I would therefore need to define more precisely what the problem might be.
In the last attempt of the IT administrator to solve the problem, he found the following information from the log output on the switch:
-------------------------------------------------- ------------------------------------------------
occasionally - ?once a week it happens that the controller disconnects from the network.
At this moment, the device (driver) behaves like a "sleeping laptop", when after a requested handshake on the switch side, the port is set to a-10M/a-half-duplex. ("a" means that the port is automatically set to the best connection between the switch and the device. The port configuration does not specify specific connection parameters and is set based on a handshake - a mutual agreement between the switch and the device.
In the case of a laptop, after startup, NB will request a handshake again and the port will be set to a-1000M/a-full-duplex. But for some reason, the driver sw can't do that, or it gets into an untreated state from the point of view of the sw, when it is unable to respond to anything and it has to be restarted.
See the status of the port on the switch in the event of a "fault", when the controller stops responding. Ping doesn't work either. The port is in the up/connected state.
Gi6/0/34 ovl-204 notconnect 94 auto auto 10/100/1000BaseTX
Gi6/0/35 Studio Plus1 connected 94 a-half a-10 10/100/1000BaseTX
Gi6/0/36 AV BluePill connected 94 a-full a-1000 10/100/1000BaseTX
Settings on the port:
swri13-3p#sho run inte gi6/0/35
Building configuration...
Current configuration: 140 bytes
!
interface GigabitEthernet6/0/35
description Studio Plus1
switchport access vlan 94
switchport mode access
spanning-tree portfast
end
Status of the port where the device (driver) is connected:
swri13-3p#sho inte gi6/0/35
GigabitEthernet6/0/35 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 700f.6a8e.bf16 (bia 700f.6a8e.bf16)
Description: Studio Plus1
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 10Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:13:59, output 00:00:01, output hang never
Last clearing of "show interface" counters 7w6d
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
Queuing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 29000 bits/sec, 25 packets/sec
16334258 packets input, 3079636478 bytes, 0 no buffer
Received 4306239 broadcasts (142277 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 142277 multicast, 0 pause input
0 input packets with dribble condition detected
106310805 packets output, 15810585982 bytes, 0 underruns
155 output errors, 478 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 530 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
swri13-3p#
Ping not going through:
swri13-3p# ping 192.168.94.207
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.94.207, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
swri13-3p#
There is no information in the log on the switch about errors that would occur there if the port is switched to the error-disable state.
Feb 10 15:24:44.780: %LINK-3-UPDOWN: Interface GigabitEthernet6/0/35, changed state to up
Feb 10 15:24:45.779: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet6/0/35, changed state to up
Feb 14 11:42:38.042: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet6/0/35, changed state to down
Feb 14 11:42:39.043: %LINK-3-UPDOWN: Interface GigabitEthernet6/0/35, changed state to down
Feb 14 11:42:54.405: %LINK-3-UPDOWN: Interface GigabitEthernet6/0/35, changed state to up
Feb 14 11:42:55.404: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet6/0/35, changed state to up
Feb 15 08:44:05.165: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet6/0/35, changed state to down
Feb 15 08:44:05.505: %ILPOWER-5-IEEE_DISCONNECT: Interface Gi6/0/35: PD removed
Feb 15 08:44:06.165: %LINK-3-UPDOWN: Interface GigabitEthernet6/0/35, changed state to down
Feb 15 08:44:18.493: %ILPOWER-7-DETECT: Interface Gi6/0/35: Power Device detected: IEEE PD
Feb 15 08:44:19.492: %ILPOWER-5-POWER_GRANTED: Interface Gi6/0/35: Power granted
Feb 15 08:44:22.562: %LINK-3-UPDOWN: Interface GigabitEthernet6/0/35, changed state to up
Feb 15 08:44:23.563: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet6/0/35, changed state to up
Feb 15 14:27:40.596: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet6/0/35, changed state to down
Feb 15 14:27:41.597: %LINK-3-UPDOWN: Interface GigabitEthernet6/0/35, changed state to down
Feb 15 14:27:43.956: %LINK-3-UPDOWN: Interface GigabitEthernet6/0/35, changed state to up
Feb 15 14:27:44.956: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet6/0/35, changed state to up
After finding that the device was connecting on a-100/a-full auto handshake, I set the port hard and the device rebooted and connected.
swri13-3p#sho inte status | in 6/0/35
Gi6/0/35 Studio Plus1 connected 94 full 100 10/100/1000BaseTX
swri13-3p#
swri13-3p#ping 192.168.94.207
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.94.207, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
swri13-3p#sho run inte gi6/0/35
Building configuration...
Current configuration: 164 bytes
!
interface GigabitEthernet6/0/35
description Studio Plus1
switchport access vlan 94
switchport mode access
speed 100
duplex full
spanning-tree portfast
end
Please monitor the behavior on this device. In case of problems, please - call.
With regards and wishes for a peaceful day
jirka
----------------------------------------------------------------------------------------------------
I don't think the fault will be on the hw, it's not just one bstation doing it, and it worked fine for a period of time. Even the backlight of the buttons does not respond when it freezes.
We just need to somehow find out the cause.
You wrote: "It can also be some messages not aimed at the b-station like a broadcast message coming from any device on the network."
We use at this subnet also a lot of NDI based devices (cameras) and other audio IP protocols. Could there be some conflict caused by such traffic?
On B-stations we use your template for LPU-2, only we change the preset numbers and backlite colour. So I don't know where there could be a loop that overwhelms Bstation
Im sorry for such a long issue, but we have to solve it.
Best regards,
Michal