On Tue, Jul 16, 2013 at 10:20 PM, Brian Kantor Brian@ucsd.edu wrote:
On Tue, Jul 16, 2013 at 09:35:03PM +0300, Heikki Hannikainen wrote:
How about if someone sends an encapsulated 44-to-44 packet to amprgw, and the packet has a destination address in one of the BGP subnets, and the subnet is not in encap database? Would that get routed out from amprgw (unencapsulated), or would it be dropped?
It's supposed to get routed out unencapsulated. I haven't tested that to make sure it works.
Tested, does not work:
44.74.128.0/24 is announced using BGP, but it's not in the encap routing table yet. There is an APRS-IS server in that block now (44.74.128.25, fifth.aprs.net, one of rotate.aprs.net core servers - cool, an APRS-IS core server on AMPRNet *and* the Internet at the same time with a single address!).
I manually added an encap route on my amprnet encap gateway, pointed it to amprgw.ucsd.edu. Packets go out towards amprgw, but replies don't come back. Here's the tcpdump -vv output for packet to amprgw and the reply from there:
22:46:44.558642 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPIP (4), length 80) 85.188.1.118 > 169.228.66.251: IP (tos 0x0, ttl 64, id 64699, offset 0, flags [DF], proto TCP (6), length 60) 44.139.39.8.33351 > 44.74.128.25.14501: Flags [S], cksum 0x254d (correct), seq 802450829, win 14400, options [mss 1440,sackOK,TS val 1479217 ecr 0,nop,wscale 2], length 0
22:46:44.757626 IP (tos 0x0, ttl 42, id 49221, offset 0, flags [none], proto IPIP (4), length 76) 169.228.66.251 > 85.188.1.118: IP (tos 0xc0, ttl 254, id 37842, offset 0, flags [none], proto ICMP (1), length 56) 137.110.222.1 > 44.139.39.8: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 64699, offset 0, flags [DF], proto TCP (6), length 60) 44.139.39.8.33351 > 44.74.128.25.14501: tcp 40
Seems to be a routing loop somewhere over there, 137.110.222.1 probably routes all of 44/8 to amprgw (maybe it has a static route for 44/8 and does not have the full BGP routing table with more specific routes announced elsewhere) and amprgw then gives packet destined to 44.74.128.25 back to 137.110.222.1 since it's not in the encap routing table. Or something along those lines.
And wouldn't it be preferred to have that go directly encapsulated to an encap gateway box at the BGP-enabled site?
I think it should, for network efficiency and robustness. Perhaps we should make that a required part of the network architecture?
That's what I would propose, just to keep the amprnet interconnected.
It'd be counterintuitive if some of the really advanced cool sites, which set up BGP for performance and robustness, would resort back to relying on amprgw for their amprnet traffic.
- Hessu