#Wired client workgroup Pc#
#Wired client workgroup mac#

I was able to ping the WGB and PLC, but unable to ping anything beyond, such as the subnet gateway. I went ahead and connected directly to the WGB on interface Gi1 with a static IP of 192.122.2.12. Unfortunately, clearing ARP entries did not change the behavior. I entered the 'clear ip arp destination_IP' like we discussed.

Since this is in a 24/7 environment I want to avoid any impacts that could halt production.

#Wired client workgroup mac#

I did come across a command to forward a mac address via the BVI, 'bridge bridge-number address MAC-address forward interface interface-number' but I need to research it more to make sure it doesn't cause any issues upstream/downstream by putting that in. I am thinking there must be a way to set a rule to specifically allow/forward traffic coming to/from the WGB to an intended target network. Either it is blocking pings from the upper network down to the PLC, or blocking pings from the PLC out to the upper network possibly both. It looks to me that the issue lies with the WGB. We also sent pings from a good laptop configured with an IP from the local subnet and connected to the Gi1 port on the WGB and received a response. We tested ping by sending one from the WGB and received a response, so the PLC is not blocking them. My electrical engineer has verified that there is no option in the PLC for toggling ICMPv4 to enable/disable.

#Wired client workgroup Pc#

To check if your client in the bridge table use:ģ) If you still can’t ping the PLC, I suggest to connect a “tested pingable” windows PC and connect it to the switch that connect to the Cisco 2702 AP (meaning mimc the PLC connection), make sure it is connected and getting IP Address then ping that PC from your network, if that’s successful then the PLC is blocking those ICMPv4 replies. IOS AP command because you have Cisco 2702 AP:īridge bridge-group-number aging-time seconds To avoid the traffic loss, prevent the wired client from being removed from the bridge table by configuring the aging-out timer on the WGB to a large value using the following: As a result, the traffic flow to the wired client fails.

If you can’t ping the PLC and it is connecting and working fine then there is one of below possibilities:ġ) The client is not configured to send ICMPv4 replies or the client’s firewall blocking that (for example, Windows Firewall is blocking ICMPv4 by default and to allow that you need to add a rule for that to Windows Firewall, not sure if it’s the same for the PLC)Ģ) If a wired client does not send traffic for an extended period of time, the WGB removes the client from its bridge table, even if traffic is continuously being sent to the wired client. If someone has experience with this situation, or could point me to a resource, I would greatly appreciate it. I am unsure if I need to forward the mac address of the PLC on the WGB, or if I need to add VLAN sub-interfaces. Here is the configuration I am working with:Įnable secret 5 $1$AceP$Mz/jr8loqPS0G2zTQx4wC1Īuthentication key-management wpa version 2 The wired client PLC behind the WGB is able to communicate with the network in order to perform its work, but I am unable to ping the PLC directly. I have a vehicle connected to our network via a Cisco 2702 AP configured as a WGB.