All,
I've been doing some testing with the Type of Service and Differentiated
Services Code Point for tunl0. I've been working to determine if
connectivity to Ronen's camera's could be slightly improved from the
tunnel's perspective. I'm focusing on the improvements seen using hex
code 0xB8, known as High Priority Expedited Forwarding, or 'Virtual
Leased Line.'
I wanted you all to check your connections to me, and make sure that I'm
still reachable. Feel free to ping, or simply use my tool at
http://44.60.44.10/tools/trace/php-trace44.php/ to reach yourselves.
73,
- Lynwood
KB3VWG
> ip tunnel change tunl0 mode ipip ttl 64 tos B8 pmtudisc
> I can modify ampr-ripd (and amprd if needed) to periodically sent some
> data "home", locator and gateway callsign to 44.182.21.1.
> This would need an additional parameter, something like "-Lyo2loj at kn05or <http://hamradio.ucsd.edu/mailman/listinfo/44net>".
> This would allow me to put together a simple tracking database and show
> active nodes on a world map for everybody to gaze at :-)
Yes, it could send some fields like the software version and maybe the number of
routes it has put in the table, so it will be possible to debug things and be able
to notify users when a serious problem is discovered or protocol change is made that
requires update beyond some version number.
That could be done using MNDP or similar protocol sending to 44.0.0.1?
I would recommend having different fields for different information.
(sysop, locator, etc)
Way I the past I had something like this in my NET version. It used multicast to
224.0.1.31 which is a multicast address I registered for this purpose.
host 224.0.1.31
31.1.0.224.in-addr.arpa domain name pointer ampr-info.mcast.net.
You are welcome to use that address when required (probably not, just send over tunnel
to some real destination or 255.255.255.255)
Rob
If anyone is interested, I would propose an experiment.
I can modify ampr-ripd (and amprd if needed) to periodically sent some
data "home", locator and gateway callsign to 44.182.21.1.
This would need an additional parameter, something like "-L yo2loj@kn05or".
This would allow me to put together a simple tracking database and show
active nodes on a world map for everybody to gaze at :-)
Anyone interested?
Marius, YO2LOJ
So with Brians "pressure" on me (HI) i think i have found the problem ... it it the tunnel keep alive
and now the questions
1)Does it necessary to turn it on ?
2) why this uses source address of amprGW and destination of my local address maybe its a a bug in the Mikrotik tunnel ? what protocol keep alive uses ? is there anyone else here with mikrotik that have a keep alive open and know if he get same errors from AMPGW ?
I have changed the keep alive timing from every 10 to 610 seconds and the errors reduced to 2 every 15 minutes from about 100
Ronen - 4Z4ZQ
> Reverse engineering the protocol was a bit of a challenge. I couldn't
> find it documented in sufficient detail anywhere and wound up decoding the
> protocol format from the hex dump and decoding that wireshark provided.
Yes, that is kind of inconvenient. From the wireshark decoding I guessed that
it would be a float. Apparently not.
Wireshark shows that it is TLV data and what the types mean, and I knew that
you would be able to map the TLV to the hexdump.
Rob
> Thanks Tom, yes, when I assume it's seconds, I get
> uptime numbers like 22+02:22:54, which is 22 days,
> 2 hours, and some minutes/seconds.
Yes, it is in seconds. The latest software release was early may, so
that is a uptime that can be expected.
Rob
> So with Brians "pressure" on me (HI) i think i have found the problem ... it it the tunnel keep alive
> and now the questions
> 1)Does it necessary to turn it on ?
> 2) why this uses source address of amprGW and destination of my local address maybe its a a bug in the Mikrotik tunnel ? what protocol keep alive uses ? is there anyone else here with mikrotik that have a keep alive open and know if he get same errors from AMPGW ?
Yes, that is probably the reason. You should simply turn it off.
The tunnel keep alive packets are tunneled packets with source and destination address swapped.
There is no standard for this, but it is a method used by other manufacturers as well.
Apparently the expectation is that the remote end of the tunnel will just route the packets and
return them on the same tunnel, just like a ping.
However, in your case one of the addresses is a 192.168 (RFC1918) address. Likely you are running
your MikroTik behind another router that does NAT. That is not a good idea, you should try to
get the real internet address on the MikroTik. With some ISPs it may be difficult because the
use of the provided router is mandatory and it cannot be put in transparent mode.
Setting "DMZ mode" in the router often causes additional problems.
Rob
Rob or Marius, do you know what units the MikroTik reports
its uptime in? Is it seconds? I get numbers like 1922575
or 1909374 for the two I have MNDP data for.
- Brian
Maybe one of the interesting "things to do" would be to write a small daemon
that captures those UDP packets to 255.255.255.255 port 5678 (MNDP) and
stores the latest one received from each source. It would have to have access
to the outer IPIP header to do that.
Then, it could regularly dump the collected "latest packets" in a tabulated text
file with the fields that there are in these packets each in a column. When you
look in wireshark (which knows about this format) you see it is quite easy to do.
This table would present an overview of the MikroTik routers in use, and could
help identify possible problems with the tunneling they do.
You could also stop handling them as an error condition.
How would such a daemon have to be written so it can run at the gateway?
Could it just do a pcap with the appropriate filter?
Rob
> Why my Mikrotik dont appear in this data ?
When you are using Marius' automatic tunnel configuration script, you won't appear there.
It disables the MNDP transmission on the tunnels.
What you see in that list is only those routers where an IP tunnel to the new gateway was
manually configured and MNDP was not turned off.
Rob
