SOLVED
Hi @Wing1 !
The configuration seems fine. Could you paste here output of "display interface Vlan-interface20" and "display interface GigabitEthernet0/1"?
Also, when you try to ping, do you ping FROM the router or you ping the router from a host connected to Gig0/1? And if the second option is correct, is this host directly connected to MSR's Gig0/1 or through another device, like a switch?
Hi @Wing1 !
Vlan-interface20 is up, Gig0/1 is access in VLAN20, so it should work. But there is something wrong with the link on Gig0/1. Let's take a look at the port's statistics:
Input (normal): 1916 packets, - bytes
0 unicasts, 766 broadcasts, 1150 multicasts, 0 pauses
Input: 0 input errors, 0 runts, 0 giants, - throttles
0 CRC, - frame, - overruns, 0 aborts
- ignored, - parity errors
Output (total): 0 packets, 0 bytes
- unicasts, - broadcasts, - multicasts, - pauses
Output (normal): 0 packets, - bytes
0 unicasts, 0 broadcasts, 0 multicasts, 0 pauses
Output: 0 output errors, - underruns, - buffer failures
0 aborts, 0 deferred, 0 collisions, 0 late collisions
- lost carrier, - no carrier
From first glance no errors, BUT - from 1916 frames received on this port 766 are broadcast frames and the rest 1150 are multicast frames. Very weird. I mean I can imagine a situation when there are no unicasts, because the device connected couldn't resolve IP of the router using ARP, probably there was no reply from the router, but it's just a guess. Also we see zero packets output which is strange as well. Ok, let's check STP, maybe you enabled it and the port is in blocking state? "display stp brief". If STP is not configured (you will see that message in the command's output in this case), let's see how the port's configuration looks like - "display current-config". Just delete all sensitive data like password hashes etc. "display version" output will also be handy to see the s/w the switch is running on.
BTW, one important question I missed from the very beginning - have you tried to convert the Gig0/1 back to the routed port mode (port link-mode route), assign same IP 192.168.210.5/24 and then ping a PC connected to it? If you didn't try it, it's worth to try to see if the issue appears only when the port is in bridged mode.
Ok, I think I know where the problem is - seems like you missed one important log message when you configured Gig0/1 to the bridged mode. Could you do the following - access your router's CLI and run 'terminal monitor' command, then go to the system-view, switch the port to routed moded, then to bridged mode again:
system-view
int gig0/1
port link-mode route
port link-mode bridge
What I expect is this message:
DRVMSG/5/DRVMSG: This interface can be used only for the EVI feature when it is operating in bridge mode.
If you see it, then it's not going to work as normal bridged port. Seems like full bridged mode on these routers is possible only with additional switching modules which ports work as normal Ethernet switch.
As a workaround you can use sub-interfaces on this port if VLAN tagging of the traffic is what you need to achieve. However, if you need to bridge several embedded ports on Layer 2, it is not possible.
Hi @Wing1 !
No, it's not a bug at all. When you connect to VTY console of any Comware product (Telnet, SSH) the output of log messages is not visible in the console, but those messages appear in the logbuffer (use 'display logbuffer' command to see it). Not many people want to be interrupted during their CLI session by log messages, sometimes it can get annoying, so this behavior was selected as default setting. BTW, almost all major networking vendors use the same logic. That is why if you really need to see syslog messages in the SSH or Telnet session, run 'terminal monitor' to enable this feature. BTW, if you connect to the router using console port, that has 'terminal monitor' enabled by default, because normally console port is used in emergency situations and you probably want to see all messages generated by Comware in order to troubleshoot an issue.
P.S. Use 'undo terminal monitor' to disable monitoring of log messages in current terminal session.