On 04/10/2014 02:20 PM, Brian Kantor wrote:
As far as I know, because of routing restrictions on the amprgw network connectivity, hosts on BGP-announced subnets of 44/8 will be unable to communicate with hosts on tunnel-routed subnets of 44/8 unless the BGP-announced subnet also runs a listed tunnel router gateway with a non-44/8 gateway address.
This is because the building-level router one hop upstream from amprgw has a fixed route directing all 44/8 traffic to amprgw. This building-level router does not speak BGP and so cannot learn about BGP-announced subnets of 44/8. This is a historical artifact; it predates the availability of BGP-announced 44/8 subnets by many years.
Something doesn't add up here. What kind of router doesn't speak BGP? :)
I suspect the router does indeed speak BGP and OSPF and RIP, it's just probably not powerful enough to store the entire Internet routing table. Luckily, to solve this problem, it doesn't need to! UCSD IT can feed that router with an extremely partial BGP feed. This feed would only contain 44.0.0.0/8 Internet BGP-announced routes. We have such a feed right now on our Seattle edge router for HamWAN. Here is the entirety of the 44net routing table on the Internet:
[eo@Seattle-ER1] /ip route> print where bgp active Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADb 0.0.0.0/0 209.189.196.65 20 3 ADb 44.0.0.0/8 209.189.196.65 20 54 ADb 44.16.15.0/24 209.189.196.65 20 55 ADb 44.46.160.0/22 209.189.196.65 20 56 ADb 44.68.52.0/24 209.189.196.65 20 57 ADb 44.74.128.0/24 209.189.196.65 20 58 ADb 44.98.254.0/24 209.189.196.65 20 59 ADb 44.103.0.0/19 209.189.196.65 20 60 ADb 44.127.128.0/24 209.189.196.65 20 61 ADb 44.130.99.0/24 209.189.196.65 20 62 ADb 44.135.120.0/24 209.189.196.65 20 63 ADb 44.136.138.0/24 209.189.196.65 20 64 ADb 44.136.139.0/24 209.189.196.65 20 65 ADb 44.136.150.0/24 209.189.196.65 20 66 ADb 44.136.151.0/24 209.189.196.65 20 67 ADb 44.136.158.0/24 209.189.196.65 20 68 ADb 44.136.224.0/24 209.189.196.65 20 69 ADb 44.136.227.0/24 209.189.196.65 20 70 ADb 44.139.0.0/16 209.189.196.65 20 71 ADb 44.140.0.0/16 209.189.196.65 20 72 ADb 44.144.0.0/16 209.189.196.65 20 73 ADb 44.161.252.0/22 209.189.196.65 20 96 ADb 44.169.48.0/20 209.189.196.65 20 75 ADb 44.208.0.0/16 209.189.196.65 20 [eo@Seattle-ER1] /ip route>
Please use monospace font to see it properly. This is a whopping count of:
[eo@Seattle-ER1] /ip route> print count-only where bgp active 24
24 routes! *Any* router can handle that. In fact, one of the BGP routes is our default gateway, so in your case it'd only be 23 routes. 44.0.0.0/8 is already there though, so 22 additional routes. Hmmm actually that's missing all the routes we (HamWAN) announce, so I guess add 4 to that total. Either way, it's a small number!
To enable this partial-BGP-feed, UCSD IT need only make a 1-line change to whatever will be BGP-feeding that router:
ip prefix-list HAMWAN-PREFIX-OUT seq 110 permit 44.0.0.0/8 le 24
That's not necessarily the right change for UCSD, but an example of the right direction. This particular line of config is what feeds our Seattle edge router with the required routes so we can make routing decisions between taking the Internet or taking an IPIP tunnel to deliver packets.
We hope to change this topology in the future to connectivity with the border router that DOES speak BGP, but indications are that that change will not be able to be done soon.
In the meantime, gateway tunnel routers with a non-44 gateway address (that's all of them, except HamWan's proposed gateway) are the workaround to this restriction.
I'm sorry for this difficulty but it's what we're stuck with for now.
- Brian
This does introduce a recurring cost for us, in that we'd have to buy a commercial /24 of IP address space for ham radio purposes. AMPR has plenty, so it doesn't make much sense. :) I would probably leave the UCSD communication broken instead, until UCSD fixes the routing issue. We'd still enjoy the benefits of redundant tunnel termination for every other AMPRnet.
Can you make the database change to configure 44.24.221.1 as the gateway for 44.24.240.0/20?
--Bart