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