could you support for this case?
as you can find in below screen, we can communicate with all inter-VLAN
also, we can ping and browse the PTZ camera without any problem.
But the issue is we cannot browse the Radar via radar explorer, only we can ping it.
the Radar working by UDP 41252
also, find the attached configuration,
The fact you can successfully ping the device shows you have working IP transport. Looking at the config you have provided there are no ACLs in the path which would restrict traffic to UDP/41252 . What config is on the Moxa, maybe an ACL exists there?
With regard to the radar explorer, are you saying it connects to the radar device on port UDP/41252? That strikes me as odd, since that is an ephemeral port. Services typically use low port numbers. Or does the radar device reach out to the radar explorer sourcing its traffic from UDP/41252 ?
Thanks, Seb for your reply,
FYI, I have assigned new NIC on the server and connected to VLAN 104 and I can ping and browsing the Radar.
that means I cannot browse the Radar from the server (107) but at the same time, I can ping it from Server.
as you can see in below screen, w can ping the radar
also, next screen from the Radar Software, IP 10.0.7.89 is the IP for the server (VLAN 107)
by this IP we cannot browse the radar
by the next screen, as I mentioned you can browse all the radar.
I am waiting for your new solution
I'd check the TTL value in the IPv4 header of the packets sent out by the radar device. The fact that it's packets appear to not be routable suggests the TTL must be set to a value of 1. I have seen similar behaviour with door management systems!
The switch should also record these drops in the CEF statistics:
show ip cef switching statistics
...should hopefully show hits against RP LES TTL expired
Thanks, Seb for your reply
when I ping the radar from the server as in below screen, I don't have any loss for TTL in the core switch
Core SW, with running show ip cef switching statistics
In your example output is the server still on the same subnet (VLAN 104) as the radar device? If so you will not see the 'TTL expired' counter increment as the packet is not being routed by the switch.
If you put the server back on its original VLAN (107), then I am sure you will see the counter going up. Perhaps not for the ICMP packets, but when you try to use the radar browser. It would be ideal if you could capture the packets leaving the radar device. Maybe use a SPAN port where the Moxa switch connects to the 3850.
i have disabled the NIC (VLAN 104) which connected to Radar VLAN directly.
as you can see in below screen, I had ping from Server (VLAN 107) and I got the below
OK, so the next step is to try and use the radar browser whilst the server and radar are in different subnets, and check to see if the CEF TTL Expired counter starts to go up.
You will have to check the configuration docs for your radar device to see if you can increase the TTL. Chances are this setting cannot be edited. If this is the case then your only option is to place a server interface in the same subnet.
as per the below link,
and as per this kind of radar working by UDP, the reply ping should be (TTL64)
any more support??
I think the fact that when using the radar browser from VLAN107 -> VLAN104 the TTL expired counter increments on the router, this shows that the radar device is using a TTL value of 1. There is no other explanation.
Like seb mentions not a connectivity issue since you can ping. Can you console into that radar to see locally how you can connect to it for management purposes? Also does it maybe use some sort of multicast only?