Do we have a rough idea on how many /24s that would amount to?
I would add that a major downside to that configuration would be not playing nice from the perspective of the internet community. It sounds like we're talking about adding hundreds of new routes to the already enormous global routing tables and most of them will likely refuse all traffic without a 44/8 source.
I always assumed that we had the 44/8 route just to be able to avoid that scenario. If you're telling us that the only reason the 44/8 route exists is for research purposes, that's fine. However, I'd agree with Bryan that it seems like we're getting the short end of the stick if they won't even help us configure it properly.
On Tue, Jun 16, 2015 at 1:11 AM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Sun, Jun 14, 2015 at 08:44:05PM -0700, Tim Osburn wrote:
On Sun, 14 Jun 2015, Brian Kantor wrote:
I have an alternative suggestion, which would be to find an ISP or two that are willing to take over the IPIP tunnel routing.
They would BGP advertise /24 summary routes for the smaller tunnels, as
well
as appropriate routes for the wider tunneled subnets. That way there is no fixed route that blinds the tunnels to the BGP subnets.
[...]It would only be necessary for the tunneled gateways to change their tunnel endpoint address -- there is no need for tunneled gateways to suddenly have to change software or overall configuration.
[...]RE: "advertise /24 summary routes" The only downside to offloadingthe IPIP tunnels to a ISP is that the telescope project will lose out on some traffic. Example; if a /30 or /32 has been allocated out of a /24 CIDR then the ISP would need to advertise the whole /24 just for that one small tiny use case.
I want to say that I think that this is the best of the three solutions that have been proposed, for several reasons:
First, it completely solves the problem. Full end-to-end connectivity between the legacy tunneled subnets and the modern BGP-advertised subnets would be restored.
Second, it is flexible. Assuming that the routing in the ISP's router is generated by automated scripts from the encap table data, no manual intervention is necessary when tunnel gateways come or go. Updates could occur as often as desired, whether hourly or daily at the ISP's discretion.
Third, it's compatable. No one has to do anything on the BGP side of the house, and the only thing the tunneled folk have to do is a one-time update of their configuration to reflect the new tunnel endpoint address.
Fourth, it's inexpensive. No hardware needs to be purchased/donated and very little software needs to be developed or configured (scripts to convert the encap data to Cisco and Mikrotik routers already exist).
Fifth, it's not very disruptive. There would not be much of a outage; none for the BGP folk and only the one config change for the tunnel folk.
Sixth, it takes UCSD and me both out of the loop. We'd simply shut down the UCSD tunnel gateway system after the conversion is complete.
Seventh, it's not much of a burden on the ISP that takes over the tunnel routing. The amount of additional traffic they'd be handling is small since the tunnel subnets are small as well.
Downside: the tunnel folks would see a small increase in the amount of IBR they have to contend with as the filtering that the current tunnel router does would be reduced to subnet-only selection, rather than being ANDed with the DNS. I think this would be acceptable, and it removes the existing dependency on the DNS.
I would appreciate it if people were to give this proposal serious consideration, including whether an ISP will come forward that would be willing to do this. I'm hoping there is; after all, the burden on the ISP is little different from that of the 'shim' proposal and I got the distinct impression that at least one ISP had already volunteered to host that solution.
I'd like to get this underway as soon as practical. The existing lack of connectivity has obtained for too long already.
Comments please? - Brian _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net