Pinging Clients Through WGB - Configuration Help

[Theo Kazmark]

Hello,

I have a vehicle connected to our network via a Cisco 2702 AP configured as a WGB. 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. Here is the configuration I am working with:

version 15.3
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname wgb-wn-plt-122-1
!
!
logging rate-limit console 9
enable secret 5 $1$AceP$Mz/jr8loqPS0G2zTQx4wC1
!
no aaa new-model
clock timezone CST -6 0
no ip source-route
no ip cef
!
!
!
!
dot11 syslog
!
dot11 ssid TestWGB
authentication open
authentication key-management wpa version 2
wpa-psk ascii 7 06120A325847071E544541
!
!
!
!
!
username [private] password 7 [private]
username [private] password 7 [private]
!
!
bridge irb
!
!
!
interface Dot11Radio0
no ip address
no ip route-cache
shutdown
antenna gain 0
station-role root
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 spanning-disabled
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
!
interface Dot11Radio1
no ip address
no ip route-cache
!
encryption mode ciphers aes-ccm
!
ssid TestWGB
!
antenna gain 0
peakdetect
stbc
station-role workgroup-bridge
mobile station minimum-rate 9.0
mobile station period 60 threshold 90
bridge-group 1
bridge-group 1 spanning-disabled
!
interface GigabitEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
no keepalive
bridge-group 1
bridge-group 1 spanning-disabled
!
interface GigabitEthernet1
no ip address
duplex auto
speed auto
bridge-group 1
bridge-group 1 spanning-disabled
!
interface BVI1
mac-address [private]
ip address 192.122.2.200 255.255.255.0
no ip route-cache
!
ip default-gateway 192.122.2.1
ip forward-protocol nd
ip forward-protocol udp 2222
ip http server
no ip http secure-server
ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag
!
!
bridge 1 route ip
!
!
!
line con 0
line vty 0 4
login local
transport input all
!
sntp server 10.241.24.33
end 

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.

If someone has experience with this situation, or could point me to a resource, I would greatly appreciate it.

[patoberli]

Does the client firewall allow you to ping it from a foreign network? It's blocked by default in Windows for example.

[Theo Kazmark]

Hello Patoberli,

Thank you for your response. We do not have any rules blocking communication between the affected users trying to ping the PLC. We know this because we can ping other devices in the same 192.122.2.X subnet. The only thing that differs is that this PLC is a wired client behind a WGB while the other hosts connect directly to an access switch.

[Grendizer]

If you can’t ping the PLC and it is connecting and working fine then there is one of below possibilities:
1) 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)
2) 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. As a result, the traffic flow to the wired client fails. 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:
iOS AP command because you have Cisco 2702 AP:
bridge bridge-group-number aging-time seconds
in your case will be:
AAP(config)#bridge 1 aging-time ?
<10-1000000> Seconds
AAP(config)#bridge 1 aging-time
To check if your client in the bridge table use:
show bridge verbose

3) 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.

[Theo Kazmark]

Hello Grendizer,

Thank you for your response! I will test this out as soon as possible and respond with the results.

[Theo Kazmark]

Hello Grendizer,

1) I do not have access to the PLC configuration directly. I am working with my electrical engineer to verify if ICMPv4 is enabled/disabled.

2) I have set 'bridge 1 aging-time 100000' on the WGB.

3) I think I misunderstood what was written for this step. I will connect the PC to the WGB Gi0 port with a 192.122.2.x connection to mimic the PLC to see if I can get a valid ping to rule out if ICMPv4 is blocked on the PLC. I will get this data tomorrow.

Along with your suggestions I did test adding a static arp entry to the WGB via 'arp 192.122.2.11 001d.9cc7.08d7 ARPA' with no results. I also placed this static entry on the L3 router with no success.

I will work with my engineer to get the answer to #1 ASAP and let you know what they say.

Note: I have attached a readout of the 'show bridge verbose'.

[Grendizer]

OK, Good, I know you were just testing but just to let you know this should and will work without any static ARP entry or static route,

[Theo Kazmark]

Hello Grendizer,

My electrical engineer has verified that there is no option in the PLC for toggling ICMPv4 to enable/disable. We tested ping by sending one from the WGB and received a response, so the PLC is not blocking them.
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.

It looks to me that the issue lies with the WGB. 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. 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. 

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. Since this is in a 24/7 environment I want to avoid any impacts that could halt production. 

[Grendizer]

Hi Theo,
Actually there is nothing you need to configure on the WGB to allow that, by default the WGB will not block ping or ICMPv4
And you don't need that cli command, this needed if you want to permanently add that MAC to the WGB and will keep it after the reboot and will show as "P" in Age if you do "sh bridge verbose", it's another way to avoid wired client from being removed from the bridge table which you already did when configured aging-time.
If you still can't ping thru the wireless bridge, then you can clear the ARP with below command:
clear ip arp the_destination_IP
Is this WGB connected to a root Autonomous AP or to a WLC? And How the wired client or the PLC connect? WGB --> Switch --> Wired client or different way?

[Theo Kazmark]

Hello Grendizer,
I will issue the 'clear ip arp destination_IP' command when I next connect to the WGB. It is outside of the window I can connect to it today, so I will have to get in on Monday.

The AP connects to a WLC. The PLC is physically connected to the WGB over ethernet. I have attached a crude diagram to show the path from the WLC to the WGB/PLC.

[Theo Kazmark]

Hello Grendizer, 

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

C:\WINDOWS\system32>ping 192.122.2.11

Pinging 192.122.2.11 with 32 bytes of data:
Reply from 192.122.2.11: bytes=32 time<1ms TTL=64
Reply from 192.122.2.11: bytes=32 time<1ms TTL=64
Reply from 192.122.2.11: bytes=32 time=19ms TTL=64
Reply from 192.122.2.11: bytes=32 time=2ms TTL=64

Ping statistics for 192.122.2.11:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 19ms, Average = 5ms

C:\WINDOWS\system32>ping 192.122.2.200

Pinging 192.122.2.200 with 32 bytes of data:
Reply from 192.122.2.200: bytes=32 time=1ms TTL=255
Reply from 192.122.2.200: bytes=32 time<1ms TTL=255
Reply from 192.122.2.200: bytes=32 time<1ms TTL=255
Reply from 192.122.2.200: bytes=32 time<1ms TTL=255

Ping statistics for 192.122.2.200:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms

C:\WINDOWS\system32>ping 192.122.2.1

Pinging 192.122.2.1 with 32 bytes of data:
Reply from 192.122.2.12: Destination host unreachable.
Reply from 192.122.2.12: Destination host unreachable.
Reply from 192.122.2.12: Destination host unreachable.
Reply from 192.122.2.12: Destination host unreachable.

Ping statistics for 192.122.2.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

I also tested having another user attempt to ping my laptop while connected behind the WGB, and that failed too.

I believe I may have found an issue with the SSID the WGB is connected to. I will post more details after I investigate.

[Theo Kazmark · Accepted solution]

Hello Everyone,

I found the problem. The SSID the WGB was connecting to (TestWGB) was on a different subnet. The SSID was using 192.199.1.X as opposed to 192.122.2.X. Once I changed the SSID to one with the same subnet, the pings were allowed through. Thank you all for your time looking at this issue.

[ryeteur]

Missed choosing up my normal morning espresso at the go back and forth while operating from home and other automobile products as you can check, so offered a coffee grinder and Italian coffee device to get my caffeine restoration at domestic.