cbeckstein  Freshman Member

@ Sorry no, I cannot do that: I already spent many hours in March and April chasing bugs in the XNG1915 (resulting in 4 fixes for the April 2024 FW) but at the moment I simply cannot afford the time for lengthy experiments with wireshark stuff

Sorry, no,… In my case the slave XMG1915 is NOT only inaccessible (for ping or login), there is no more traffic from the master XMG1915 to it - until the next reboot of the slave So I dare to contradict your claim that the cases are completely different The slave does not handle correctly / recognize its master going down…

I know this is a thread that adresses the XS1930, nevertheless.. the enhancement for switch port recovery of the XS1930 thatmentioned above is very interesting could it possibly be extended to the XMG1915E and fix a similar recovery problem which I brought up here This problem is still unfixed in the April 2024 FW for the…

No, I did not disconnect all the devices from the two switches when I did the tested as described in my previous msg… Cannot do that at the moment because they are in heavy use. Maybe some time during the coming weekend, but not now during the work week…

Yes, I can confirm this… The password there (in the saved config backup file for AZ) is the original UNencrypted one (of the cluster member WZ) although both, AZ and WZ have Password Encryption set to ON…

I usually do not reboot the two XMG1915-10Es… no reason to do that because… as long as I leave them alone, they run like a charm —- one or the other strange behaviour excluded, see my other post "Strange IPV6 related behaviour shown by a XMG1915-10E configured for DHCPV6" from March 24th in this community… I only noticed…

OK: No change in network topology between the two testing periods, no device moved… Disabled IPV6 on both AZ and WZ (by disabling the IPV6 interface, otherwise anything IPV6 related unchanged like in the Tech support files I sent you a few days ago) Switched off STP on the two switches for the ports that are wired directly…

One more idea: Could it make a difference with my setup whether the slave Switch_WZ is power-cycled or just rebooted via its Web interface? Is there anything different in its reconfiguration during restart, maybe wrt initializing its SFP+ ports (configured for media type DAC10G) when it is just rebooted?

Hi Judy, This is driving me nuts… I replaced my two older XS1250-12 Zyxel switches with the XMG1915-10Es because I needed a more flexible but nevertheless reliable network solution… Wrt Case 1 —- I probably was not precise enough: Both switches have an optical SFP+ 10GBASE-T RJ-45 transceiver in port 10 and are connected…

I do not really understand your question "happens with IPV4 or IPV6?" The switches have set both IPV4 and IPV6 active, and when the inaccessibility of Switch WZ happens, I cannot access it via IPV4 and not via IPV6 I will send you the Support Downloads for both switches right away privately. They may also be relevant for…

Just an idea: Did you experiment with the "Auto Power Down" settings for the ports of the switch? I mean, does the problem persist if you disable "Auto Power Down" for all its ports?

Problem solved - at least for the XMG1915-10Es (I do not own a XS1930, so cannot speak for that). Thanks a lot for this professional support job…

Thanks for the offer… If it is not too much of an effort, I of course would love to get (another) date code firmware for my XMG1915-10E (which already is running date code firmware V4.80(ACGO.1)20240222 | 02/22/2024 you sent to me because of an ugly bug in IPV6 configuration)

Same here for a XMG1915-10E, stand alone, with latest FW V4.80(ACGO.1)20240222 | 02/22/2024 when I set Security - Access Control - Service Access Control - SNMP to OFF (all grey button saying OFF) then in the Switch Dashboard Quick Link area it says SNMP is ON (in green) and vice versa: when I set Security - Access Control…

Attached please find the Tech-Support data you asked for…