VLAN help GS1920

Options
2»

All Replies

  • h3ctic
    h3ctic Posts: 11
    Friend Collector
    edited September 2021
    Options
    @Zyxel_Chris and @Mijzelf   - thanks for your replies. The  "LocB-LinuxIoT" has been tried in MANY ports, it is right now in P33 (I just used a "cable-toner-finder" just to make sure I am using the right cable and got this confirmed). The "LocB-XGFW" is in P1. The uplink to WAN is located in the "LocB-XGFW".

    Edit: Other devices and their ports:

    LocB-PC (192.168.4.100) - P30
    LocB-SophosAPX (192.168.4.101) - P3
    LocB-PC (192.168.200.1) - P ....not sure yet (I cannont unplug this device just now to "tone-find" it)

    (yes, the LAN here is lacking documentation and few of the cables/walloutlets are marked/identified Im afraid)
  • Mijzelf
    Mijzelf Posts: 2,607  Guru Member
    First Anniversary 10 Comments Friend Collector First Answer
    Options
    I don't see anything special in the configuration of port 33. When I look at the difference of port 30 (LocB-LinuxIoT) and port 33 (LocB-PC1) (port 33 can be pinged from LocA-WinSrv, port 30 cannot), I see only a difference in 'Acceptable Frame Type'. 33 is all, 30 is untag only. But that shouldn't make any difference. It is about packets accepted by the switch. As both PC1 and IoT don't do VLAN, they both only transmit untagged frames.

    You write that between the working and non-working state only 'the ZyXEL' was reconfigured. That is the switch, I suppose?
    If you connect an any device to port 33, can it be pinged from WinSrv? In that case it's almost impossible that it has anything to do with VLAN's.

  • Zyxel_Chris
    Zyxel_Chris Posts: 661  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    Options
    @h3ctic,
    Based on your form LocB-PC2 (192.168.4.100) can reach to IoT and there is no data on LocB-SophosAPX (192.168.4.101) therefore can you provide which port that LocB-PC1 (192.168.200.10) connect to?

    The traffic from LocA will pass-through from port 1 to port 33 (IoT server) and the setting looks fine.
    Chris
  • h3ctic
    h3ctic Posts: 11
    Friend Collector
    Options
    @Mijzelf and @Zyxel_Chris

    I took out the IoT from P33 and plugged in my PC. I got IP 192.168.4.102 and the LocA-WinSrv is NOT able to ping it Im afraid.

    I toned out 192.168.200.10 and it is plugged in P38.
  • h3ctic
    h3ctic Posts: 11
    Friend Collector
    Options
    @Mijzelf and @Zyxel_Chris - please do not use any more time trying to figure this out. It is now working! I will be posting back with my findings, what I can say is that there was NO problem with the Zyxel-switch. Ie; its now working without me doing any changes to it. More details soon.
  • h3ctic
    h3ctic Posts: 11
    Friend Collector
    Options
    Ok..here is what happened; since I was stomped and had NO clue as to what caused this problem (but alas; thought the Zyxel and vlans was to blame) I decided to plug the Linux-IoT directly into the LocB-XGFW (P6) and "hardcoded" the port 6 to 192.168.4.70 and thereby bypassing the Zyxel alltogether. ....and it worked (or so I thought).. Atleast the LocA-WinSrv was now able to ping the IoT but for some reason the software used to program the IoT (located on the WinSrv) did NOT like the communication still, and we were still unable to reprogram the IoT. I then called the guy responsible for the IoT and told him that there could be that the problem was with the IoT itself and he came by and unplugged the backup-batteries and restarted the device. No joy still. We then decided to try and reprogram the device to use another IP adress but was unable to telnet into the device as per documentation. So we decided to just leave it for now. I went back into the XGFW and checked the logs and I could see that the ICMP packets was being routed to P1 still (not P6) so I figured there was some sort of P1/P6 "conflict" going on and deleted the P6-hardcoded interface, plugged the IoT back into P36 in the Zyxel and called Sophos support to hopefully get them to look into this whole mess. Whilst waiting in queue I decided to logon to the WinSrv and the IoT-software just to check again...and ...lo and behold....it was now working!!!!?? So, in conclusion, the problem was either the IoT-device itself (and it got fixed either by the restart and/or by us plugging in/out cat-cables into the Lan-interface and "Programming-port" OR the problem was some sort of "hickup" in the XGFW which got corrected by the P6-hardcoding and subsequently deleting it.) Anyways, thanks again guys for all your help and Im a happy camper now that it is working!

Categories

Nebula Tips & Tricks


    Read more

    Nebula Help Center

    EnglishTiếng ViệtРусскийไทย中文（台灣）