16 Jun
2015
16 Jun
'15
9:09 a.m.
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(a)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 offloading
the 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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net