Hi!
i've just installed a ptp650, replacing a ptp500. everything is good and I enjoy new transport capacity.
i've only one problem, i cannot read snmp or just ping the new devices from a different network from the one they are configured in.
i've read the configuration parameters, but i cannot find anything related, i think.
any idea?
thanks!
Hi,
This seems to be a Network issue; that is, either routing or gateway issue.
-Are you able to ping any other devices on the network where this radio located? If yes, what is the gateway IP configured on that device?
-Do you have the route or routing to reach from that network this network? did you check that?
-The radio's Gateway IP address, is that pointing the correct gateway for the reachability of other network?
Regards,
Vijay Gnanamurtthi
yes, i can ping and reach snmp services of other radio located in the same lan. i used to reach the ptp500, that had the same ip address, that has been replaced by these ptp650.
and yes, the gateway is the right one.
if it helps, it has 1.42 software version, but has the same problem with 1.41 and 1.40.
thanks
You mention a problem with ping and SNMP, but not HTTP.
Are you able to access the ODU from a different network using HTTP? If so, the gateway must be configured correctly.
Are you able to access the SNMP interface from within the same network as the ODU? If not, it may be that the SNMP interface is disabled.
Thanks, Mark
no, i cannot reach even http.
i can reach snmp from the same lan.
i can ping the odu from the gateway, and i double checked the gateway setting in both odu
thanks
I'm not sure what's happening here.
One action that might cast some light on the problem is to ping from the ODU.
If you connect to the ODU by Telnet (from the local network in this case) you can set up a ping like this:
Here you see me ping the management agent at the remote end of the link (10.130.159.42) and then you see me ping an address outside the network.
If Telnet is not enabled on the ODU, you will have to enable it using HTTP, in the Web-Based Management page. In your case, that will of course have to be done from the local network.
If you decide to give this a go, let us know what you find.
i can ping the gateway from the odu:
sysadmin$ ping 169.254.255.1
Reply from 169.254.255.1: 64 bytes icmp_sn=0. time=0 ms
Reply from 169.254.255.1: 64 bytes icmp_sn=1. time=0 ms
Reply from 169.254.255.1: 64 bytes icmp_sn=2. time=0 ms
Reply from 169.254.255.1: 64 bytes icmp_sn=3. time=0 ms
Reply from 169.254.255.1: 64 bytes icmp_sn=4. time=0 ms
i cannot ping outside the local lan:
ping x.x.x.x
----x.x.x.x PING Statistics----
5 packets transmitted, 0 packets received, 100% packet loss
OK
if i try to ping something 'outside' but blocked from other router:
ping y.y.y.y
Ping failed with error Network is unreachable
----y.y.y.y PING Statistics----
2 packets transmitted, 0 packets received, 100% packet loss
OK
- Are you using In-band management?
- Are you using a management VLAN?
in band management yes, management vlan no.
may be i've found something interesting: it seems that ping req and ping reply are sent with TTL=1, so the first router the packet traverse should drop them.
here some tcpdump:
ping req:
18:40:16.257424 IP (tos 0x0, ttl 1, id 35884, offset 0, flags [none], proto ICMP (1), length 84)
169.254.1.2 > xxxxxxxxxxxxxxx: ICMP echo request, id 45124, seq 3, length 64
ping reply:
18:39:35.105366 IP (tos 0x0, ttl 1, id 35851, offset 0, flags [none], proto ICMP (1), length 84)
169.254.1.2 > xxxxxxxxxxxx: ICMP echo reply, id 29533, seq 2, length 64
is it possible that this is why?
thanks
I guess we should ask for the sake of completeness what Subnet Mask you have on the PTP 650?
The TTL might well be a clue to the odd behavior. When I ping a PTP 650 from another network, I receive a ping response (verified using Wireshark) with TTL=127. This has passed through one router, so the ping response was presumably transmitted by the ODU with TTL=128.
Similarly, I receive a ping request triggered at the ODU with TTL=127 after one router, suggesting it was sent by the ODU with TTL=128.
I wonder if TTL=1 is set by a router on the basis that it knows it is delivering the packet directly in the destination network?
I'm betting it's to do with the 169.254 subnet.
Can you try 10.a.b.c/24 IPs?
j
I'm confident that newkirk has the answer, and a bit disappointed with myself for not spotting it.
The 169.254.X.X network is not supposed to be routed. A router should not forward into or out of this network. I suspect that we set TTL=1 in PTP 650 if the address is in 169.254.X.X, where we set TTL=128 in PTP 500. It's an "improvement". We'll check that this is the correct explanation.
ok: let's say that using another ip class ( always private ) , everything is ok, i can ping, read snmp, etc..
thanks to all!!
We confirm that the TCP/IP stack on PTP650 sets TTL to 1 if ip address is link local. This is inline with section 2.7 of RFC 3927 which states the below.
<< A sensible default for applications which are sending from an IPv4 Link-Local address is to explicitly set the IPv4 TTL to 1.
An IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it, regardless of the TTL in the IPv4 header. >>
