Dear List
I'm pretty newly connected to hamnet, and also work at an ISP.
I always assumed 44.0.0.0/8 would not be announced to the internet, but only routed privately on hamnet.
Now I see routing issues I don't quite understand as for me this looks like routing is completely broken...
On the internet core router I see that 44.0.0.0/8 is being announced by AS7377 (UCSD).
But IP Addresses from the swiss HamNet range are not reachable via AS7377. So what is the point announcing the whole range to the internet? There is no 'more specific' route to 44.142.200.1
On the other hand I cannot reach parts of hamnet via hamnet. Take for example the Primary DNS of ampr.org:
ampr.org. 3600 IN SOA ampr.org.
ampr.org has address 44.0.0.1
1 gateway (157.161.57.65) 2.947 ms 2.887 ms 2.847 ms 2 mikrotik-hamnet.woody.ch (192.168.57.243) 4.937 ms 4.920 ms 4.887 ms 3 rf0.am-32.hb9am.ch.ampr.org (44.142.162.97) 21.810 ms 24.858 ms 29.860 ms 4 bb-hb9am-30.db0wbd.ch.ampr.org (44.224.90.81) 29.847 ms 32.792 ms 32.771 ms 5 wan-db0wbd.hc.r1.ampr.org (44.148.240.45) 78.907 ms 81.925 ms 84.438 ms 6 dc1-dc2.hc.r1.ampr.org (44.148.255.253) 97.808 ms 98.107 ms 113.973 ms 7 wan-db0gw.db0fhn.ch.ampr.org (44.224.122.2) 113.986 ms 113.149 ms 118.384 ms 8 db0fhn.ch.ampr.org (44.130.60.100) 126.890 ms 118.628 ms 137.776 ms 9 * * *
My Gateway has a default route to the internet and a static route for 44.0.0.0/8 pointing to my WLAN Link to a 'public' Hamnet AP.
So what is the point of having sort of a split-brain situation on the 44.0.0.0/8 hamnet ip range?
I 'see' ospf packets on the WLAN link, but they only seem announce the local routes withing the swiss part of hamnet, not the global routes. Sort of makes sense, as you probably would run bgp to interconnect the different hamnet as numbers.
So do I need to get an own hamnet as number? As a User?!?
Or what mechanism is there supposed to be to tell a user which hamnet ip ranges are reachable via internet and which ones are reachable via hamnet.
73 -Benoit- / HB9EUE
Hi Benoit,
44/8 is announced via UCSD indeed. Within that /8 there is a /16 per country, which each country may announce, if requested. Each /16 is subdivided in user networks, those are managed by the country coordinators. Users may announce their own subnet (starting from a /24) via BGP if they request it and fill in the document as requested by Brian Kantor.
A country may decide to advertise their /16 to the internet, or they can choose to not advertise it, and only use it as an "internal" range If your /16 is announced by your countries coordinators, then you should go and see them and request how your network can be routed to and from the internet. If your coordinators choose to not announce it, it will be reachable via the /8 that is announced at UCSD, but only if your ip's have a valid reverse DNS configured. Those DNS entries can either be added by your countries coordinators, or by Brian.
From what I see in the global internet routing table, your IP country does not advertise it's /16, but your IP goes via AS7377
I hope this clarifies some things for you.
73,
Ruben - ON3RVH
-----Original Message----- From: 44Net [mailto:44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org] On Behalf Of Benoit Panizzon Sent: zaterdag 24 februari 2018 10:10 To: AMPRNet working group 44net@mailman.ampr.org Subject: [44net] Routing of 44.0.0.0/8 how are routes announced to users?
Dear List
I'm pretty newly connected to hamnet, and also work at an ISP.
I always assumed 44.0.0.0/8 would not be announced to the internet, but only routed privately on hamnet.
Now I see routing issues I don't quite understand as for me this looks like routing is completely broken...
On the internet core router I see that 44.0.0.0/8 is being announced by AS7377 (UCSD).
But IP Addresses from the swiss HamNet range are not reachable via AS7377. So what is the point announcing the whole range to the internet? There is no 'more specific' route to 44.142.200.1
On the other hand I cannot reach parts of hamnet via hamnet. Take for example the Primary DNS of ampr.org:
ampr.org. 3600 IN SOA ampr.org.
ampr.org has address 44.0.0.1
1 gateway (157.161.57.65) 2.947 ms 2.887 ms 2.847 ms 2 mikrotik-hamnet.woody.ch (192.168.57.243) 4.937 ms 4.920 ms 4.887 ms 3 rf0.am-32.hb9am.ch.ampr.org (44.142.162.97) 21.810 ms 24.858 ms 29.860 ms 4 bb-hb9am-30.db0wbd.ch.ampr.org (44.224.90.81) 29.847 ms 32.792 ms 32.771 ms 5 wan-db0wbd.hc.r1.ampr.org (44.148.240.45) 78.907 ms 81.925 ms 84.438 ms 6 dc1-dc2.hc.r1.ampr.org (44.148.255.253) 97.808 ms 98.107 ms 113.973 ms 7 wan-db0gw.db0fhn.ch.ampr.org (44.224.122.2) 113.986 ms 113.149 ms 118.384 ms 8 db0fhn.ch.ampr.org (44.130.60.100) 126.890 ms 118.628 ms 137.776 ms 9 * * *
My Gateway has a default route to the internet and a static route for 44.0.0.0/8 pointing to my WLAN Link to a 'public' Hamnet AP.
So what is the point of having sort of a split-brain situation on the 44.0.0.0/8 hamnet ip range?
I 'see' ospf packets on the WLAN link, but they only seem announce the local routes withing the swiss part of hamnet, not the global routes. Sort of makes sense, as you probably would run bgp to interconnect the different hamnet as numbers.
So do I need to get an own hamnet as number? As a User?!?
Or what mechanism is there supposed to be to tell a user which hamnet ip ranges are reachable via internet and which ones are reachable via hamnet.
73 -Benoit- / HB9EUE _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hi Brian
Thank you for the quick reply.
But I fear they don't explain the routing issue I see.
If my country coordinator did not choose to announce it's /16, it is routed via UCSD.
At the moment, my Mikrotik connected to the HAMNET AP on the next hill, is getting: 44.142.162.123 via DHCP.
So if I got that right, this IP should be reachable via UCSD for the 'internet' world:
traceroute to 44.142.162.123 (44.142.162.123), 64 hops max, 40 byte packets 1 prt-cbl-sw1-vlan-13-0.gw.imp.ch (157.161.1.1) 1.947 ms 1.693 ms 1.273 ms 2 prt-cbl-core1-ve-255.gw.imp.ch (157.161.254.5) 0.737 ms 0.72 ms 0.774 ms 3 swissix.zrh2.llnw.net (91.206.52.217) 10.473 ms 10.431 ms 36.897 ms 4 tge1-1.fr3.mrs1.llnw.net (87.248.194.221) 16.802 ms 16.758 ms 16.781 ms 5 lag34.fr3.cdg1.llnw.net (68.142.88.62) 18.134 ms 18.146 ms 18.116 ms 6 lag20.fr3.iad.llnw.net (68.142.88.48) 93.476 ms 93.568 ms 98.834 ms 7 lag33.fr3.atl1.llnw.net (68.142.88.153) 115.251 ms 115.383 ms 115.225 ms 8 lag23.fr3.dal.llnw.net (68.142.88.137) 135.555 ms 135.661 ms 135.636 ms 9 lag10.fr3.phx3.llnw.net (68.142.88.129) 154.628 ms 154.773 ms 154.6 ms 10 tge1-1.fr3.aza1.llnw.net (69.164.62.16) 154.898 ms 154.856 ms 154.785 ms 11 lag25.fr3.lax.llnw.net (68.142.88.168) 167.615 ms 167.707 ms 167.612 ms 12 198.32.251.189 (198.32.251.189) 159.841 ms 159.864 ms 159.75 ms 13 137.164.11.25 (137.164.11.25) 161.957 ms 137.164.11.23 (137.164.11.23) 161.043 ms 160.964 ms 14 dc-sdg-agg4--tus-agg3-100ge.cenic.net (137.164.11.9) 162.512 ms 137.164.11.11 (137.164.11.11) 162.053 ms dc-sdg-agg4--tus-agg3-100ge.cenic.net (137.164.11.9) 162.323 ms 15 dc-ucsd-1--sdg-agg4.cenic.net (137.164.23.54) 161.835 ms 161.855 ms 161.852 ms 16 nodem-core-6807-vlan2767-gw.ucsd.edu (132.239.254.61) 162.085 ms 161.915 ms 162.061 ms 17 rci-nodem-p2p.ucsd.edu (132.239.254.177) 162 ms 162.759 ms 163.389 ms 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * *
Noe, it isn't. From my point of view, this would be OK, as the hamnet links could be very slow packetradio links and you do not want to expose them to the bad things on the internet which constantly scan the whole ip range. :-)
But then, why not just announce the /16 which are reachable via internet? It's not that a bad pollution of the routing table as routing single /24s.
And also the other way round, why am I not able to reach the ampr.org primary DNS, over hamnet?
How, as a hamnet 'user' do I know which hamnet destinations are reachable via internet and which ones via internet? I would need to run a routing protocol for that and establish peerings, from a dynamic IP?!?, but this is something the 'normal' user would be unable to cope with and in my point of view, not the task of the user.
Well, my goal was initially to connect my DMR hotspot via HamNet so it would work independently of my internet connection, but if the DMR Master's HAMNET IP Address I want to connect to is not reachable via hamnet, that does not make much sense.
73 Benoit HB9EUE
I do not know why your country coordinator did not choose to announce its /16 or any parts of it. Perhaps it costs too much, or no ISP was willing to do so. You would have to ask him.
The encap routing table entry for your address is 44.142.0.0/16 141.75.245.225 and 141.75.245.225 is pingable from the AMPRGW router at UCSD.
However, NO addresses on the 44.142.162.x subnet are in the allowed filter list at AMPRGW, so there will be NO connectivity to your DHCP address from the Internet via AMPRGW. Thus the traceroute you show is correctly reflecting your unreachability. You will have to ask your coordinator or your hamnet manager why this is so.
It may be that the next hop in the path out from your hamnet address is a router with knowledge of the tunnels and reachability of the rest of AMPRNet. Again, you will have to ask your hamnet manager how this is configured.
Best wishes. - Brian
Hello Benoit,
Am 24.02.2018 um 10:09 schrieb Benoit Panizzon panizzon@woody.ch:
Dear List
I'm pretty newly connected to hamnet, and also work at an ISP.
You should better ask your local community about your problems and questions. No one in america, russia or china will be able to answer you question.
I always assumed 44.0.0.0/8 would not be announced to the internet, but only routed privately on hamnet.
That's only partial true.
Now I see routing issues I don't quite understand as for me this looks like routing is completely broken...
On the internet core router I see that 44.0.0.0/8 is being announced by AS7377 (UCSD).
Yes, since the 1980's.
But IP Addresses from the swiss HamNet range are not reachable via AS7377. So what is the point announcing the whole range to the internet? There is no 'more specific' route to 44.142.200.1
connectivity. For the users who like be reachable. ucsd.edu knows the path to your 44.142.200.1 via the correspondent ipip-gateway. He may filter traffic from the internet in order to protect you from non-ham-traffic and other harmful things.
On the other hand I cannot reach parts of hamnet via hamnet. Take for example the Primary DNS of ampr.org:
ampr.org. 3600 IN SOA ampr.org.
ampr.org has address 44.0.0.1
1 gateway (157.161.57.65) 2.947 ms 2.887 ms 2.847 ms 2 mikrotik-hamnet.woody.ch (192.168.57.243) 4.937 ms 4.920 ms 4.887 ms 3 rf0.am-32.hb9am.ch.ampr.org (44.142.162.97) 21.810 ms 24.858 ms 29.860 ms 4 bb-hb9am-30.db0wbd.ch.ampr.org (44.224.90.81) 29.847 ms 32.792 ms 32.771 ms 5 wan-db0wbd.hc.r1.ampr.org (44.148.240.45) 78.907 ms 81.925 ms 84.438 ms 6 dc1-dc2.hc.r1.ampr.org (44.148.255.253) 97.808 ms 98.107 ms 113.973 ms 7 wan-db0gw.db0fhn.ch.ampr.org (44.224.122.2) 113.986 ms 113.149 ms 118.384 ms 8 db0fhn.ch.ampr.org (44.130.60.100) 126.890 ms 118.628 ms 137.776 ms 9 * * *
Interesting: Your local dns server maps the official reverse lookup (db0fhn.as64664.de.ampr.org) under a ch.ampr.org domain.
44.0.0.1 is only reachable from a source address in 44/8, if this address has a reverse lookup. Perhaps it's part of the concept, that ucsd.edu filters incoming internet traffic for unassigned 44-destinations. Unfortunately, it affects the dns resolving.
You said, your IP is 44.142.200.1 ? That IP does not have a PTR record.
My Gateway has a default route to the internet and a static route for 44.0.0.0/8 pointing to my WLAN Link to a 'public' Hamnet AP.
Common setup.
So what is the point of having sort of a split-brain situation on the 44.0.0.0/8 hamnet ip range?
No split-brain. Unfortunately, it's a filter that affects you.
I 'see' ospf packets on the WLAN link, but they only seem announce the local routes withing the swiss part of hamnet, not the global routes.
It's a local configuration of your hotspot. They may speak ospf. Ask them what's it worth for.
Sort of makes sense, as you probably would run bgp to interconnect the different hamnet as numbers.
Yes, the hamnet routers speak bgp to each other.
So do I need to get an own hamnet as number? As a User?!?
No. In no hamnet area I know.
Or what mechanism is there supposed to be to tell a user which hamnet ip ranges are reachable via internet and which ones are reachable via hamnet.
There's no such mechanism.
vy 73, - Thomas dl9sau
Hi Thomas
You said, your IP is 44.142.200.1 ? That IP does not have a PTR record.
No, that was just an example. My actual DHCP assigned IP on Hamnet is: 44.142.162.123, and has no PTR either.
So it more or less all boils down to needing to have a PTR to have your IP address routed within hamnet itself?
So I should ask the local admin of that user access hotspot to define PTR eintries for his DHCP range, so the users can access services within hamnet via hamnet?
Benoît / HB9EUE
Benoit,
Routing for subnets of 44/8 is very complex compared to simple ISP-style routing. I will try to describe it in general; there are fine points which I won't go into here.
Routing inside AMPRNet, and to and from the outside world is very different depending on which kind of AMPRNet subnet you are connected to.
Note that the UCSD AMPRNet router is known as AMPRGW.
If you are connected via one of the AMPRNet subnets which is directly connected to the Internet and announced via BGP, or you are on a non-44 subnet (such as one provided by your ISP), your routing to addresses on network 44 is handled just like any other Internet address; it goes via your default route to the Internet backbone which routes it to the destination. Note that that destination may be via AMPRGW or it may be another subnet of 44/8 which is directly connected. (If you look at the global BGP routing tables, you will see that 44.0.0.0/8 is variably subnetted, with subnets varying in size from /24 to /15.) There are about 150 44.x.x.x subnets which are directly connected to the Internet backbone and are announced via BGP.
But there are some 600 MORE subnets of AMPRNet which are NOT announced via BGP. They are not directly reachable from the Internet backbone. Instead, they are announced to the world by the overarching 44/8 route via AMPRGW at UCSD. Packets to them are sent to AMPRGW, which encapsulates them in a TUNNEL and sends them to a gateway to the subnet, where the packets are de-encapsulated and placed on the subnet's LAN.
Packets originating on that LAN are sent, depending on their destination, either via the tunnel to AMPRGW for injection into the Internet backbone, or if for another tunnel-connected AMPRNet subnet, via another tunnel to the appropriate gateway for the destination's 44.x.x.x LAN.
The connectivity *INSIDE* the tunnel-connected AMPRNet is a MESH with 600+ tunnels connecting the various subnets that are not BGP-announced. There is, strictly speaking, no single default route to all of network 44/8. There is a routing table (often referred to as "the encap table") which lists the tunnel-connected subnets and the Internet address of the gateway which serves it. A few lines of this table look like this:
44.0.0.1/32 via 169.228.34.84 44.10.2.0/27 via 66.85.73.59 44.102.1.112/30 via 68.40.58.30 44.102.1.0/24 via 23.115.92.204
There is no BGP announcement for subnet 44.10.2.0/27, except the one for all of 44/8 at AMPRGW. So non-44 hosts, and those on BGP-announced 44 subnets would send packets for (eg) 44.10.2.1 to AMPRGW, which they would be encapsulated into a tunnel whose endpoint (as shown in the table above) is 66.85.73.59. Response packets would take the reverse route back via AMPRGW.
44-net hosts which are tunnel connected would consult their local routing table and see that packets to 44.10.2.1 would need to be encapsulated and sent to the tunnel between that host (or its gateway) and 66.85.73.59, where they would be de-encapsulated and placed on the 44.10.2.0/27 LAN.
Packets to non-existent subnets of 44/8 are dropped, either by AMPRGW if they get that far, or by the local tunnel gateways.
In addition, in order to reduce the amount of garbage reaching AMPRNet hosts, and to isolate those that don't want to be connected to the main Internet, AMPRGW filters inbound packets at the /32 level before encapsulating them. If you're not in the filter table (which is driven by the AMPR.ORG DNS tables), you won't get any traffic from the Internet via AMPRGW.
Doing this mesh routing in a conventional router (by Cisco, Mikrotik, Juniper, FreeBSD, etc) is painful. You need some 450 separate tunnels each with their own endpoint, to some 600+ destination subnets. As these can change hourly, maintaining this is hard. However, the Linux kernel 'iptables' has a mechanism where you can set up a single tunnel interface which can have a per-packet endpoint address, so once the 'encap' routing table is loaded, only one tunnel interface is needed. Most people do it this way. There is a periodic transmission from the AMPRGW gateway to all the tunnel gateways which updates the routing table automatically, a little like RIP would.
I hope this helps. - Brian
[NB: you say you are connected to 'hamnet'. There are several different hamnets; I don't know the specifics of the one you're connected to.]
On Sat, Feb 24, 2018 at 10:09:44AM +0100, Benoit Panizzon wrote:
Dear List
I'm pretty newly connected to hamnet, and also work at an ISP.
I always assumed 44.0.0.0/8 would not be announced to the internet, but only routed privately on hamnet.
Now I see routing issues I don't quite understand as for me this looks like routing is completely broken...
[...]
Hi Brian
Thank you for your quick explanations. Ok I now understand that routing is not just nice and easy done by routing protocols as in the internet but a hand-made error prone mesh :-)
[NB: you say you are connected to 'hamnet'. There are several different hamnets; I don't know the specifics of the one you're connected to.]
Yes I am. Well, so the DNS PTR filter would only affect packets transfered across gateways between hamnet and the internet.
So any clue, why I can not reach parts from the hamnet 44.0.0.0/8 space from my true hamnet ip address: 44.142.162.123?
Mainly the 'primary' DNS Server of ampr.org which I assumed should be reachable from everywhere within hamnet:
traceroute to 44.0.0.1 (44.0.0.1), 30 hops max, 60 byte packets
2 mikrotik-hamnet.woody.ch (192.168.57.243) 4.584 ms 4.605 ms 4.585 ms 3 rf0.am-32.hb9am.ch.ampr.org (44.142.162.97) 12.475 ms 12.477 ms 18.788 ms 4 bb-hb9am-30.db0wbd.ch.ampr.org (44.224.90.81) 18.827 ms 24.174 ms 24.165 ms 5 wan-db0wbd.hc.r1.ampr.org (44.148.240.45) 62.922 ms 70.345 ms 72.729 ms 6 dc1-dc2.hc.r1.ampr.org (44.148.255.253) 95.661 ms 93.691 ms 102.363 ms 7 wan-db0gw.db0fhn.ch.ampr.org (44.224.122.2) 108.112 ms 111.090 ms 117.816 ms 8 db0fhn.ch.ampr.org (44.130.60.100) 122.348 ms 116.826 ms 121.290 ms 9 * * * 10 * * * 11 * * *
(Forget about the local IP 192.168.57.243, this is the LAN side, the packets get source nated to 44.142.162.123)
I mentioned DMR, but as I also run an APRS i-Gate I wanted to have it connect to the APRS-IS Server within Hamnet: db0alg.ampr.org
3 rf0.am-32.hb9am.ch.ampr.org (44.142.162.97) 19.117 ms 24.044 ms 24.063 ms 4 br0.am-33.hb9am.ch.ampr.org (44.142.162.67) 26.680 ms 28.756 ms 28.985 ms 5 eth3.zrh-am.hb9zrh.ch.ampr.org (44.142.255.177) 61.952 ms 82.993 ms 106.007 ms 6 * * * 7 * * * 8 * * *
Same Problem, it's not reachable within hamnet.
So is this an issue I have to look at with the local swiss admins, or is this common, that there are local, non interconnected regions within hamnet? Or is this a result of the manual routing mesh?
Benoît HB9EUE
Hello,
On Sat, Feb 24, 2018 at 7:24 AM, Benoit Panizzon panizzon@woody.ch wrote:
(Forget about the local IP 192.168.57.243, this is the LAN side, the packets get source nated to 44.142.162.123)
Are you sure? Perhaps you're getting dropped because you're not being NAT'd. db0alg.ampr.org does not reply to me on the Internet, but it replies to my BGP-connected AMPRnet address (not via the IPIP gateway at UCSD). This probably means it's internet connected but only allowing 44/8 sourced traffic.
So is this an issue I have to look at with the local swiss admins, or is this common, that there are local, non interconnected regions within hamnet? Or is this a result of the manual routing mesh?
I think it's local to your site. The AMPRGW encap might be strange, but the routing isn't anything difficult. It really should work. I see 44.0.0.1/32 in the encap. I cannot test it's reachability via IPIP, but this means to me the AMPRGW's filters should not be at play.
Regards, Scott
On 25/02/18 00:53, Scott Nicholas wrote:
Are you sure? Perhaps you're getting dropped because you're not being NAT'd. db0alg.ampr.org does not reply to me on the Internet, but it replies to my BGP-connected AMPRnet address (not via the IPIP gateway at UCSD). This probably means it's internet connected but only allowing 44/8 sourced traffic.
Probably. It's reachable for me via IPIP.
I think it's local to your site. The AMPRGW encap might be strange, but the routing isn't anything difficult. It really should work. I see 44.0.0.1/32 in the encap. I cannot test it's reachability via IPIP, but this means to me the AMPRGW's filters should not be at play.
I'm also able to reach 44.0.0.1, so I agree, the OP has something local to their endpoint going on.
Hi Benoit, 44.0.0.1 is not reachable via ICMP traceroute. Try a UDP traceroute, or even just directing a DNS query to that address.
- Josh VK2HFF
On 24/02/2018 11:24 PM, Benoit Panizzon wrote:
So any clue, why I can not reach parts from the hamnet 44.0.0.0/8 space from my true hamnet ip address: 44.142.162.123?
Mainly the 'primary' DNS Server of ampr.org which I assumed should be reachable from everywhere within hamnet:
traceroute to 44.0.0.1 (44.0.0.1), 30 hops max, 60 byte packets
2 mikrotik-hamnet.woody.ch (192.168.57.243) 4.584 ms 4.605 ms 4.585 ms 3 rf0.am-32.hb9am.ch.ampr.org (44.142.162.97) 12.475 ms 12.477 ms 18.788 ms 4 bb-hb9am-30.db0wbd.ch.ampr.org (44.224.90.81) 18.827 ms 24.174 ms 24.165 ms 5 wan-db0wbd.hc.r1.ampr.org (44.148.240.45) 62.922 ms 70.345 ms 72.729 ms 6 dc1-dc2.hc.r1.ampr.org (44.148.255.253) 95.661 ms 93.691 ms 102.363 ms 7 wan-db0gw.db0fhn.ch.ampr.org (44.224.122.2) 108.112 ms 111.090 ms 117.816 ms 8 db0fhn.ch.ampr.org (44.130.60.100) 122.348 ms 116.826 ms 121.290 ms 9 * * * 10 * * * 11 * * *
traceroute uses UDP by default. To use ICMP you need to add the '-I' parameter.
And 44.0.0.1 is traceable by both methods (I just checked...).
Marius, YO2LOJ
On 24.02.2018 22:42, Josh wrote:
Hi Benoit, 44.0.0.1 is not reachable via ICMP traceroute. Try a UDP traceroute, or even just directing a DNS query to that address.
- Josh VK2HFF
On 24/02/2018 11:24 PM, Benoit Panizzon wrote:
So any clue, why I can not reach parts from the hamnet 44.0.0.0/8 space from my true hamnet ip address: 44.142.162.123?
Mainly the 'primary' DNS Server of ampr.org which I assumed should be reachable from everywhere within hamnet:
traceroute to 44.0.0.1 (44.0.0.1), 30 hops max, 60 byte packets
2 mikrotik-hamnet.woody.ch (192.168.57.243) 4.584 ms 4.605 ms 4.585 ms 3 rf0.am-32.hb9am.ch.ampr.org (44.142.162.97) 12.475 ms 12.477 ms 18.788 ms 4 bb-hb9am-30.db0wbd.ch.ampr.org (44.224.90.81) 18.827 ms 24.174 ms 24.165 ms 5 wan-db0wbd.hc.r1.ampr.org (44.148.240.45) 62.922 ms 70.345 ms 72.729 ms 6 dc1-dc2.hc.r1.ampr.org (44.148.255.253) 95.661 ms 93.691 ms 102.363 ms 7 wan-db0gw.db0fhn.ch.ampr.org (44.224.122.2) 108.112 ms 111.090 ms 117.816 ms 8 db0fhn.ch.ampr.org (44.130.60.100) 122.348 ms 116.826 ms 121.290 ms 9 * * * 10 * * * 11 * * *
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Ok... Now the correct AMPR trace...
UDP trace:
root@server:~# traceroute -i ampr0 44.0.0.1 traceroute to 44.0.0.1 (44.0.0.1), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * gw.ampr.org (44.0.0.1) 192.180 ms 192.244 ms
ICMP trace:
root@server:~# traceroute -I -i ampr0 44.0.0.1 traceroute to 44.0.0.1 (44.0.0.1), 30 hops max, 60 byte packets 1 gw.ampr.org (44.0.0.1) 192.062 ms 191.997 ms 191.973 ms
On 25.02.2018 01:06, Marius Petrescu wrote:
Forget my previous answer. I just traced via the regular internet.
On 25.02.2018 01:04, Marius Petrescu wrote:
traceroute uses UDP by default. To use ICMP you need to add the '-I' parameter.
And 44.0.0.1 is traceable by both methods (I just checked...).
Marius, YO2LOJ
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
AMPRGW (44.0.0.1) has an ICMP reply rate limiter in effect; if someone is already pinging it a lot, you might not get a response to pings or ICMP traceroutes. And people do ping it a LOT. - Brian
On Sun, Feb 25, 2018 at 01:04:44AM +0200, Marius Petrescu wrote:
traceroute uses UDP by default. To use ICMP you need to add the '-I' parameter.
And 44.0.0.1 is traceable by both methods (I just checked...).
Marius, YO2LOJ
Hi Josh
44.0.0.1 is not reachable via ICMP traceroute. Try a UDP traceroute, or even just directing a DNS query to that address.
Nope. not working either, and would the traceroute stop somewhere within german hamnet space if just 44.0.0.1 would not be responding to icmp? Well you never know with ipip tunnels :-)
For all sceptics out here who belive I do not source nat correctly, see the attached pcap of this specific DNS query from my true hamnet ip address to 44.0.0.1.
I wonder, what happens when anyone else is tracerouting or pinging back to me: 44.142.162.123 are you getting through? No, I don't filter ICMP, they are useful for PMTU discovery and a lot of other things :-)
-Benoît / HB9EUE-
Hello Benoît.
Below tracert from within Windows 8/64b
Microsoft Windows [Version 6.2.9200] (c) 2012 Microsoft Corporation. All Rights Reserved.
C:>ping 44.142.162.123
Pinging 44.142.162.123 with 32 bytes of data: Reply from 44.142.162.123: bytes=32 time=162ms TTL=57 Reply from 44.142.162.123: bytes=32 time=254ms TTL=57 Reply from 44.142.162.123: bytes=32 time=156ms TTL=57 Reply from 44.142.162.123: bytes=32 time=158ms TTL=57
Ping statistics for 44.142.162.123: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 156ms, Maximum = 254ms, Average = 182ms
C:>
C:>tracert 44.142.162.123
Tracing route to 44.142.162.123 over a maximum of 30 hops
1 59 ms 58 ms 57 ms dyn1.oh-vpn.ampr.org [44.139.11.1] 2 * * * Request timed out. 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 235 ms 160 ms 159 ms 44.142.162.123
Trace complete.
C:>
Best regards. Tom - SP2L
Benoit,
You should check with Markus Müller HB9CTB, he is the coordinator for Switzerland and he can tell you how the routing goes and what you should do. (see a few mail back in the thread)
73,
Ruben - ON3RVH
-----Original Message----- From: 44Net [mailto:44net-bounces+on3rvh=on3rvh.be@mailman.ampr.org] On Behalf Of Benoit Panizzon Sent: maandag 26 februari 2018 14:45 To: Josh josh@festy.org Cc: 44net@mailman.ampr.org Subject: Re: [44net] Routing of 44.0.0.0/8 how are routes announced to users?
Hi Josh
44.0.0.1 is not reachable via ICMP traceroute. Try a UDP traceroute, or even just directing a DNS query to that address.
Nope. not working either, and would the traceroute stop somewhere within german hamnet space if just 44.0.0.1 would not be responding to icmp? Well you never know with ipip tunnels :-)
For all sceptics out here who belive I do not source nat correctly, see the attached pcap of this specific DNS query from my true hamnet ip address to 44.0.0.1.
I wonder, what happens when anyone else is tracerouting or pinging back to me: 44.142.162.123 are you getting through? No, I don't filter ICMP, they are useful for PMTU discovery and a lot of other things :-)
-Benoît / HB9EUE-
On Mon, Feb 26, 2018 at 02:45:07PM +0100, Benoit Panizzon wrote:
Hi Josh
44.0.0.1 is not reachable via ICMP traceroute. Try a UDP traceroute, or even just directing a DNS query to that address.
Nope. not working either, and would the traceroute stop somewhere within german hamnet space if just 44.0.0.1 would not be responding to icmp? Well you never know with ipip tunnels :-)
There's still no reverse lookup for 44.142.162.123 ; as discussed before, until fixed, 44.0.0.1 will not respond.
vy 73, - Thomas dl9sau
Hi Thomas
There's still no reverse lookup for 44.142.162.123 ; as discussed before, until fixed, 44.0.0.1 will not respond.
Well, this is where I got confusing replies...
Some state I only need a PTR if this IP should be reachable from the internet. So no need for a PTR for it to communicate with any other ip within the 44.0.0.0/8 range.
Some, like you, state that a PTR is needed for any communication, even within hamnet.
I tend to believe the first statement is the more correct one as this makes more sense to me and filtering based on PTR is done at the gateway @ UCSD and not on every hamnet router.
But I am in contact with Markus HB9CTB to look into the issue now.
73 Benoit
To be more precise, a PTR entry for 44.142.162.123 is needed in order for AMPRGW (at UCSD) to respond to or route packets from that address. This filtering is performed by the front-end firewall in amprgw (ipfw on FreeBSD). - Brian
On Mon, Feb 26, 2018 at 03:11:01PM +0100, Benoit Panizzon wrote:
Hi Thomas
There's still no reverse lookup for 44.142.162.123 ; as discussed before, until fixed, 44.0.0.1 will not respond.
Well, this is where I got confusing replies...
Some state I only need a PTR if this IP should be reachable from the internet. So no need for a PTR for it to communicate with any other ip within the 44.0.0.0/8 range.
Some, like you, state that a PTR is needed for any communication, even within hamnet.
I tend to believe the first statement is the more correct one as this makes more sense to me and filtering based on PTR is done at the gateway @ UCSD and not on every hamnet router.
But I am in contact with Markus HB9CTB to look into the issue now.
73 Benoit _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
On Mon, Feb 26, 2018 at 03:11:01PM +0100, Benoit Panizzon wrote:
Hi Thomas
There's still no reverse lookup for 44.142.162.123 ; as discussed before, until fixed, 44.0.0.1 will not respond.
Well, this is where I got confusing replies...
Some state I only need a PTR if this IP should be reachable from the internet. So no need for a PTR for it to communicate with any other ip within the 44.0.0.0/8 range.
Some, like you, state that a PTR is needed for any communication, even within hamnet.
I tend to believe the first statement is the more correct one as this makes more sense to me and filtering based on PTR is done at the gateway @ UCSD and not on every hamnet router.
thousand people, thousand and one answers.
Anyway, just believe in that what the sysop for amprgw (44.0.0.1), Brian Kantor, wrote in his mail two days ago:
== However, NO addresses on the 44.142.162.x subnet are in the allowed filter list at AMPRGW, so there will be NO connectivity to your DHCP address from the Internet via AMPRGW. Thus the traceroute you show is correctly reflecting your unreachability. You will have to ask your coordinator or your hamnet manager why this is so. ===
Benoit,
Routing between HAMNET (which is not reachable from the Internet) and 44net hosts that are reachable via the Internet is always tricky. And I need some more details to figure out what is going wrong, probably at the international HAMNET routing node at DB0FHN.
To take a closer look at the situation, contact me directly at hb9ctb@bluewin.ch
73 de Markus HB9CTB
Markus Müller HB9CTB Coordinator HAMNET/44net IP Adresses Switzerland
-----Ursprüngliche Nachricht----- Von: 44Net [mailto:44net-bounces+hb9ctb=bluewin.ch@mailman.ampr.org] Im Auftrag von Benoit Panizzon Gesendet: Samstag, 24. Februar 2018 10:10 An: AMPRNet working group Betreff: [44net] Routing of 44.0.0.0/8 how are routes announced to users?
Dear List
I'm pretty newly connected to hamnet, and also work at an ISP.
I always assumed 44.0.0.0/8 would not be announced to the internet, but only routed privately on hamnet.
Now I see routing issues I don't quite understand as for me this looks like routing is completely broken...
On the internet core router I see that 44.0.0.0/8 is being announced by AS7377 (UCSD).
But IP Addresses from the swiss HamNet range are not reachable via AS7377. So what is the point announcing the whole range to the internet? There is no 'more specific' route to 44.142.200.1
On the other hand I cannot reach parts of hamnet via hamnet. Take for example the Primary DNS of ampr.org:
ampr.org. 3600 IN SOA ampr.org.
ampr.org has address 44.0.0.1
1 gateway (157.161.57.65) 2.947 ms 2.887 ms 2.847 ms 2 mikrotik-hamnet.woody.ch (192.168.57.243) 4.937 ms 4.920 ms 4.887 ms 3 rf0.am-32.hb9am.ch.ampr.org (44.142.162.97) 21.810 ms 24.858 ms 29.860 ms 4 bb-hb9am-30.db0wbd.ch.ampr.org (44.224.90.81) 29.847 ms 32.792 ms 32.771 ms 5 wan-db0wbd.hc.r1.ampr.org (44.148.240.45) 78.907 ms 81.925 ms 84.438 ms 6 dc1-dc2.hc.r1.ampr.org (44.148.255.253) 97.808 ms 98.107 ms 113.973 ms 7 wan-db0gw.db0fhn.ch.ampr.org (44.224.122.2) 113.986 ms 113.149 ms 118.384 ms 8 db0fhn.ch.ampr.org (44.130.60.100) 126.890 ms 118.628 ms 137.776 ms 9 * * *
My Gateway has a default route to the internet and a static route for 44.0.0.0/8 pointing to my WLAN Link to a 'public' Hamnet AP.
So what is the point of having sort of a split-brain situation on the 44.0.0.0/8 hamnet ip range?
I 'see' ospf packets on the WLAN link, but they only seem announce the local routes withing the swiss part of hamnet, not the global routes. Sort of makes sense, as you probably would run bgp to interconnect the different hamnet as numbers.
So do I need to get an own hamnet as number? As a User?!?
Or what mechanism is there supposed to be to tell a user which hamnet ip ranges are reachable via internet and which ones are reachable via hamnet.
73 -Benoit- / HB9EUE _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Actually it is not. The problem comes up only if you use "best practice" setups that have a default route to ampr-gw on hamnet hosts, which is almost all of them.
And if you BGP announce a hamnet subnet to the internet, but just forget on offering a tunnel endpoint for mesh users...
On 25.02.2018 12:25, Markus Mueller wrote:
Benoit,
Routing between HAMNET (which is not reachable from the Internet) and 44net hosts that are reachable via the Internet is always tricky. And I need some more details to figure out what is going wrong, probably at the international HAMNET routing node at DB0FHN.
-
Benoit Panizzon -
Brian Kantor -
Josh -
Marius Petrescu -
Markus Mueller -
Ruben ON3RVH -
Scott Nicholas -
SP2L＠wp.pl -
Thomas Osterried -
Tony Langdon