I have also noticed that traceroutes through the amprgw router don't seem to work, although the destination host is reachable. I have yet to spend much time on figuring out why this is. - Brian
On Fri, May 05, 2017 at 11:35:40PM +0100, M6XCV (Mike) wrote:
I think this is because you are trying to send via the gateway.
I am not sure why, but I have tried using the gateway to access the internet and my packets go missing. I assumed it should work, however the fact that it did not was not something I thought it was worth investigating as I am BGP routed. If are trying to reach me through the main gateway then perhaps it is worth asking Brian to look in to it?
For the record, I attempted to ping you and my outbound seems fine. https://u4477715.ct.sendgrid.net/wf/click?upn=MJaTQVDJZogYIZySndf7y-2BCWLgZM... 668edee920.pcap
I can ping 44.0.0.1. Traceroutes also show my packets reach the gateway but go no further. I added a static route for 8.8.8.8 encapped via the gateway and it gave me this.
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 onsite.notmike.uk (44.131.14.129) 0.412 ms 0.392 ms 0.382 ms 2 Gateway.AS206671 (44.131.14.254) 9.972 ms 9.989 ms 9.988 ms 3 amprgw.sysnet.ucsd.edu (169.228.66.251) 158.942 ms 158.981 ms 159.397 ms 4 * * * 5 * * *
I suspect a firewall rule, however there are A records under ampr.org for all of my IP addresses.
Thanks, Mike, M6XCV
Oops, Now I feel silly. I just noticed it's not the gateway IP in the traceroutes. I think I saw a routerish hostname and my mind decided the extra hop was the gateway IP. This does not appear to be related, however Leon should find the pcap file useful (I assume it made it to the list, it got moderated). If you still have a problem and can capture the packets that I should be getting I can look further in to the lack of reply.
Regarding the gateway thing - I bet broken traceroutes make debugging fun! However, a normal ping to 8.8.8.8 doesn't work either. (The reply should come directly)
https://u4477715.ct.sendgrid.net/wf/click?upn=Ki4chJONuNfM0VomxEE-2BoYpt2g-2... f787e216aa1fb0ac72d2ac.pcap
Is this related to my gateway being inside the prefix?
Thanks, Mike, M6XCV
On 5 May 2017 at 23:40, Brian Kantor Brian@ucsd.edu wrote:
I have also noticed that traceroutes through the amprgw router don't seem to work, although the destination host is reachable. I have yet to spend much time on figuring out why this is. - Brian
On Fri, May 05, 2017 at 11:35:40PM +0100, M6XCV (Mike) wrote:
I think this is because you are trying to send via the gateway.
I am not sure why, but I have tried using the gateway to access the internet and my packets go missing. I assumed it should work, however the fact that it did not was not something I thought it was worth
investigating
as I am BGP routed. If are trying to reach me through the main gateway
then
perhaps it is worth asking Brian to look in to it?
For the record, I attempted to ping you and my outbound seems fine. https://u4477715.ct.sendgrid.net/wf/click?upn=MJaTQVDJZogYIZ
ySndf7y-2BCWLgZMpB-2F6rqsxKorA6Zd8-2FFwGB3FKB5i-2BnDpHTmUXAH 6kSknH2SrN02JEFVmq6PjMbZGwUX5nrEmv-2BhvkIHA-3D_OIlTlgJW10XUg PTQAICULPKsUf21p-2F0ZefV-2BAMgQ41-2FrbCWrbwsRnHmWNLe9mSsbnHd j88mG70Fbg1-2FOZtz7xpymzmP1fRDRXTrz-2BHsAVqtbFucc4kKs6KRtjWQ Acr0q5QAukagOaxK2iizQLuPCHGuAUpCkigdKsRBGRh3J-2FS9yckcehz4aG asfDgT2DR5QyQQhlSxckZYhRkGxOo2-2FKg-3D-3D
668edee920.pcap
I can ping 44.0.0.1. Traceroutes also show my packets reach the gateway
but
go no further. I added a static route for 8.8.8.8 encapped via the
gateway
and it gave me this.
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 onsite.notmike.uk (44.131.14.129) 0.412 ms 0.392 ms 0.382 ms 2 Gateway.AS206671 (44.131.14.254) 9.972 ms 9.989 ms 9.988 ms 3 amprgw.sysnet.ucsd.edu (169.228.66.251) 158.942 ms 158.981 ms 159.397 ms 4 * * * 5 * * *
I suspect a firewall rule, however there are A records under ampr.org
for
all of my IP addresses.
Thanks, Mike, M6XCV
Brian,
Trace Output:
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 kb3vwg-001.ampr.org (44.60.44.1) 1.376 ms 1.214 ms 1.293 ms 2 amprgw.sysnet.ucsd.edu (169.228.66.251) 68.036 ms 68.297 ms 68.292 ms 3 ebu-3b-720-vl441-cse-sysnet-gw-222-1.ucsd.edu (137.110.222.1) 69.470 ms 69.966 ms 69.959 ms 4 ebu3b-6509-720-vlan910-gw.ucsd.edu (132.239.255.130) 70.363 ms 71.036 ms 71.128 ms 5 mx0--nodem-core-30ge.ucsd.edu (132.239.254.162) 70.300 ms 70.355 ms 70.978 ms 6 dc-sdg-agg4--ucsd-1.cenic.net (137.164.23.53) 71.258 ms 67.644 ms 67.971 ms 7 dc-tus-agg3--sdg-agg4-100ge.cenic.net (137.164.11.8) 69.613 ms 69.380 ms 69.416 ms 8 dc-lax-agg6--tus-agg3-100ge.cenic.net (137.164.11.6) 70.377 ms 71.316 ms 71.311 ms 9 74.125.49.165 (74.125.49.165) 71.379 ms 72.487 ms 72.470 ms 10 108.170.247.193 (108.170.247.193) 73.333 ms 73.325 ms 108.170.247.225 (108.170.247.225) 73.411 ms 11 108.177.3.225 (108.177.3.225) 73.406 ms 72.14.235.53 (72.14.235.53) 74.535 ms 216.239.58.169 (216.239.58.169) 74.619 ms 12 google-public-dns-a.google.com (8.8.8.8) 74.148 ms 74.178 ms 74.200 ms
done ...
I'm not sure what you mean, traceroute has ALWAYS worked for me.
- Lynwood KB3VWG
------------------------------------------------------------------------
I have also noticed that traceroutes through the amprgw router don't seem to work, although the destination host is reachable. I have yet to spend much time on figuring out why this is. - Brian
All,
If you want to use traceroute, you must explicitly set a Time-To-Live on the encapsulated packets.
These are the OpenWRT/LEDE/Linux commands (note the second line):
ip tunnel add tunl0 ip tunnel change tunl0 mode ipip ttl 64 pmtudisc ip link set tunl0 mtu 1480 up
- KB3VWG
I'm not sure what you mean, traceroute has ALWAYS worked for me.
I'm glad it does work, and now I'm puzzled by why it didn't work when I tried it a few days ago.
Thank you! - Brian
On Fri, May 05, 2017 at 09:05:57PM -0400, lleachii--- via 44Net wrote:
I'm not sure what you mean, traceroute has ALWAYS worked for me.
- Lynwood
KB3VWG
Brian,
From: https://linux.die.net/man/8/ip
'INHERIT' is the default value, this us why you must set a TTL.
- KB3VWG
ttl N
set a fixed TTL N on tunneled packets. N is a number in the range 1--255. 0 is a special value meaning that packets inherit the TTL value. The default value for IPv4 tunnels is: inherit. The default value for IPv6 tunnels is: 64.
I'm glad it does work, and now I'm puzzled by why it didn't work when I tried it a few days ago.
Thank you! - Brian
-
Brian Kantor -
lleachii＠aol.com -
M6XCV (Mike)