10 Apr
2014
10 Apr
'14
6:18 p.m.
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