RED port goes down

From my understanding "STATUS" is a command to the RED and what you see in "data" is the response.
So LAN1 and 2 are not connected, LAN4 is solid up and LAN3 is flaky.

Can you debug from the switch side?
Maybe LAN3 and LAN4 are in the same broadcast domain and the switch shuts down one because of STP BPDUs received?
AFAIK there is no way to link RED ports together via LACP or similar.

I also had this effect once long ago with an EthernetConnect line provided by Deutesche Telekom with N10ETH SDSL devices - here the ethernet port was set by the Telekom to 10FDX with no NWAY auto negotiation in place, a thing the RED doesn't like as well - but this affected the WAN port. The fix here was to add a small switch with two ports connected - fixed at Telekom side and auto negotiation at RED side.

Also keep in mind, that all LAN ports of the RED come with the same MAC (after all it's a built-in switch), some other Switches don't like it if they see the same MAC on different ports.

Hey dirkkotte ,

Thank you for reaching out to community, can you also share the system.log , kernel.log during the time red goes down ? And also observe the LED status !

Hi all,

Alan Brand  There are different switches behind every port ... and no loop. It runs for some days without problems ... then we have some minutes link up/link down  (like before without the switch)

We have also replaced the RED already.

Vivek Jagad 

The Kernel Log seems to be empty ... is this possible?

System Log
2023:01:08-23:43:01 FIREWALL-2 /usr/sbin/cron[22279]: (root) CMD (/sbin/audld.plx --trigger)
2023:01:08-23:45:01 FIREWALL-2 /usr/sbin/cron[22683]: (root) CMD ( /usr/local/bin/rpmdb_backup )
2023:01:08-23:45:01 FIREWALL-2 /usr/sbin/cron[22684]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2023:01:08-23:45:01 FIREWALL-1 /usr/sbin/cron[27141]: (root) CMD ( /usr/local/bin/rpmdb_backup )
2023:01:08-23:45:01 FIREWALL-1 /usr/sbin/cron[27142]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2023:01:08-23:46:01 FIREWALL-1 /usr/sbin/cron[27295]: (root) CMD (/usr/local/bin/create_rrd_graphs.plx --acc)
2023:01:08-23:47:01 FIREWALL-1 /usr/sbin/cron[28658]: (root) CMD (  nice -n19 /usr/local/bin/gen_inline_reporting_data.plx)
2023:01:08-23:47:01 FIREWALL-2 /usr/sbin/cron[23068]: (root) CMD (  nice -n19 /usr/local/bin/gen_inline_reporting_data.plx)
2023:01:08-23:50:01 FIREWALL-1 /usr/sbin/cron[28794]: (root) CMD (/var/mdw/scripts/pmx-blocklist-update)
2023:01:08-23:50:01 FIREWALL-1 /usr/sbin/cron[28795]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2023:01:08-23:50:01 FIREWALL-2 /usr/sbin/cron[23546]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2023:01:08-23:50:01 FIREWALL-2 /usr/sbin/cron[23545]: (root) CMD (/var/mdw/scripts/pmx-blocklist-update)
2023:01:08-23:50:59 FIREWALL-2 dns-resolver[10647]: Updating REF_NetDnsIPrep2t :: iprep2.t.ctmail.com
2023:01:08-23:53:01 FIREWALL-2 /usr/sbin/cron[24098]: (root) CMD (/usr/local/bin/create_rrd_graphs.plx --acc)
2023:01:08-23:55:01 FIREWALL-1 /usr/sbin/cron[29082]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2023:01:08-23:55:01 FIREWALL-2 /usr/sbin/cron[25370]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2023:01:08-23:58:01 FIREWALL-1 /usr/sbin/cron[29286]: (root) CMD (/var/aua/update_ad_bg_members.plx)
2023:01:08-23:58:01 FIREWALL-2 /usr/sbin/cron[25886]: (root) CMD (/sbin/audld.plx --trigger)
2023:01:08-23:58:01 FIREWALL-2 /usr/sbin/cron[25885]: (root) CMD (/var/aua/update_ad_bg_members.plx)
2023:01:08-23:59:01 FIREWALL-2 dns-resolver[10647]: Updating REF_NetDnsIPrep2t :: iprep2.t.ctmail.com
2023:01:09-00:00:01 FIREWALL -- MARK --
2023:01:09-00:00:01 FIREWALL-2 /usr/sbin/cron[26399]: (root) CMD (/sbin/hwclock --systz --utc)
2023:01:09-00:00:01 FIREWALL-2 /usr/sbin/cron[26404]: (root) CMD (/usr/local/bin/logcontrol.sh)
2023:01:09-00:00:01 FIREWALL-2 /usr/sbin/cron[26408]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2023:01:09-00:00:01 FIREWALL-2 /usr/sbin/cron[26405]: (root) CMD (/var/chroot-smtp/cron/expiredletterscleanup.bin)

Hey dirkkotte  could be possible, that is fine.
> Check when the RED last disconnected or connected:
 #grep -i <RED-ID> /var/log/red.log | grep -i "connected“
> RED-ID = Serial Number of RED
> Check also archived logs for when a RED last disconnected or connected :
 #zgrep -i <RED-ID> /var/log/red/year/month/* | grep -i "connected"
> Check blink code of the RED
=============
> telnet <hostname of the UTM> 3400
> telnet red.astaro.com 3400
Result: Connection timed out
-> In this case it seems like there is a firewall/router in between which blocks the TCP connection on port 3400
Result: Unknown host
-> Check which DNS forwarder and UTM hostname is configured

Hi Vivek,

there is only one "connected" message within the last 7 days (but for another RED - there are 5)

I (and the customer) can't check the LED's, because after days without problem, we have only 5 minutes.

dirkkotte said:

There are different switches behind every port ... and no loop. It runs for some days without problems ... then we have some minutes link up/link down  (like before without the switch)

The question may sound silly, but maybe faulty LAN cable? Or a grounding issue if both switches are in different parts of the building?

Can you PM me the support access id, let me check if I can find anything suspicious in the historical logs...
Just let me know the date and time frame 2-3 instances that occurred ! 

Hi,

thanks, but this is not so simple ... because we have an isolated environment.
I have to request additional external access.
You may remote my Notebook. Possible, I can create a VPN.

BTW: it works for the last 5 years.

did you notice such a log line under the historical logs  "Missing keepalive from reds1?" and I believe the telnet steps would be also useful to diagnose the situation !  

no such message the last 7 days ... until we change a cable today 11:51

The second RED-LAN-Port stay active ... all the time. 

Telnet red.astaro.com 3400 should not be possible from RED, because the RED has no internet connection. 
The RED only reach the UTM-IP-Port (unfiltered).  Routing using this Port is not possible.

There is a second RED within the same MAN, with the same restrictions, connected to the same UTM ... working without problems.