So to solve the issue of Existing AMPRnet tunnel users not being able to reach BGP announced 44-net IP Space I've drawing the below drawing that shows how this can be done without having Brian Kantor ask UCSD to make any network/routing changes. This only requires at least 1 (or more) ISP (or companies running BGP) willing to setup a BGP over GRE tunnel to Brian's server to make this work. There are currently two ISP I know of willing to do this if Brian is willing to do this on the AMPRnet Server shown in the drawing. This only requires setting up BGP with a route-map for changing the next hop IP's and running GRE tunnels on his server. The bonus is he can set this up with multiple ISP so that there is redundancy. Since the ISP is only sending BGP routes of the 44 IP Space of size /16-/24, this will not consume very much routing table space on his box (currently 53 prefixes). I also have to imagine the bandwidth going over this GRE tunnels not going to be a huge amount.
So to summarize how this work. AMPRnet tunnel users can send traffic to a BGP announced 44 ip space which would travel over their IPIP tunnels (perhaps a low pref 44.0.0.0/8 route to UCSD in rip? or inject the BGP routes into RIP) back to UCSD and then over the GRE tunnel to a ISP and then ride the internet to get to that BGP announced block. Return traffic would just follow the existing internet routing table and come back via the UCSD network.
AMPRNet Interoperability with BGP Drawing: https://www.osburn.com/amprnet-150614-1.0.0-bgptunnels.jpg
Tim Osburn www.osburn.com W7RSZ
On Sun, Jun 14, 2015 at 05:26:26PM -0700, Tim Osburn wrote:
This only requires at least 1 (or more) ISP (or companies running BGP) willing to setup a BGP over GRE tunnel to Brian's server to make this work. There are currently two ISP I know of willing to do this if Brian is willing to do this on the AMPRnet Server shown in the drawing.
I'm willing but not able. The server 'amprgw' is an old FreeBSD system that doesn't understand GRE. We have been discussing updating it to a more modern system (both hardware and software) but at this point it doesn't seem like that's going to happen. We've not been able to identify ANY router product that can do what the gateway needs to do in order to replace 'amprgw'.
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. UCSD could still advertise the 44/8 overarching route (which I strongly believe is essential to preventing prefix hijacks), but since there would be more specific routes for the BGP and tunnel subnets, that wouldn't matter. 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.
Flaws? - Brian
On Sun, 14 Jun 2015, Brian Kantor wrote:
I'm willing but not able. The server 'amprgw' is an old FreeBSD system that doesn't understand GRE. We have been discussing updating it to a more modern system (both hardware and software) but at this point it doesn't seem like that's going to happen. We've not been able to identify ANY router product that can do what the gateway needs to do in order to replace 'amprgw'.
What specifically does the gateway need to do?
Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
On Sun, Jun 14, 2015 at 05:01:37PM -1000, Antonio Querubin wrote:
What specifically does the gateway need to do?
Primarily, it needs to accept all traffic to 44/8, filter the destinations that are to be encapsulated to the IPIP tunnels and forward to them, and divert all the rest of the traffic to the measurement system ("telescope").
Note that the filtering is currently done based on more than just destination subnet: using a list of registered DNS PTRs ANDed with the gateway subnet list (some 15,947 terms), and also filtering on ports (port 135-139,445,1025-1028 are blocked).
It needs to decapsulate traffic from the tunnels and place it on the Ethernet for outbound routing.
Secondarily, it has to generate the pseudo-RIP, act as a slave database server, whois server, and also serve as the master nameserver. - Brian
For the moment before we find an ISP doing that..
If one of those machines who are making the BGP announcements is willing to receive IPIP tunnel packets and can route them to the others of that BGP club, then the problem is solved for the time being. In that I case I can just change my default route from ucsd to that particular address.
Bob VE3TOK
On 15-06-14 09:20 PM, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Sun, Jun 14, 2015 at 05:26:26PM -0700, Tim Osburn wrote:
This only requires at least 1 (or more) ISP (or companies running BGP) willing to setup a BGP over GRE tunnel to Brian's server to make this work. There are currently two ISP I know of willing to do this if Brian is willing to do this on the AMPRnet Server shown in the drawing.
I'm willing but not able. The server 'amprgw' is an old FreeBSD system that doesn't understand GRE. We have been discussing updating it to a more modern system (both hardware and software) but at this point it doesn't seem like that's going to happen. We've not been able to identify ANY router product that can do what the gateway needs to do in order to replace 'amprgw'.
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. UCSD could still advertise the 44/8 overarching route (which I strongly believe is essential to preventing prefix hijacks), but since there would be more specific routes for the BGP and tunnel subnets, that wouldn't matter. 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.
Flaws?
- Brian
On Sun, 14 Jun 2015, Brian Kantor wrote:
Date: Sun, 14 Jun 2015 18:20:22 -0700 From: Brian Kantor Brian@ucsd.edu Reply-To: AMPRNet working group 44net@hamradio.ucsd.edu To: AMPRNet working group 44net@hamradio.ucsd.edu Subject: Re: [44net] AMPRNet Interoperability with BGP
(Please trim inclusions from previous messages) _______________________________________________ On Sun, Jun 14, 2015 at 05:26:26PM -0700, Tim Osburn wrote:
This only requires at least 1 (or more) ISP (or companies running BGP) willing to setup a BGP over GRE tunnel to Brian's server to make this work. There are currently two ISP I know of willing to do this if Brian is willing to do this on the AMPRnet Server shown in the drawing.
I'm willing but not able. The server 'amprgw' is an old FreeBSD system that doesn't understand GRE. We have been discussing updating it to a more modern system (both hardware and software) but at this point it doesn't seem like that's going to happen. We've not been able to identify ANY router product that can do what the gateway needs to do in order to replace 'amprgw'.
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. UCSD could still advertise the 44/8 overarching route (which I strongly believe is essential to preventing prefix hijacks), but since there would be more specific routes for the BGP and tunnel subnets, that wouldn't matter. 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.
Flaws?
- Brian
Brian, I've updated the drawing in response to your private email you sent to me. Would it be possible to "add" a shim box between the telescope project and your amprgw server? I think we could still achieve what we're trying to do if that is something you can do.
RE: "advertise /24 summary routes" The only downside too off loading the IPIP tunnels to a ISP is that the telescope project will loose 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. Where as if you add the shim box then all the traffic outside the allocated space in that /24 would pass onto the telescope making for better research data.
https://www.osburn.com/amprnet-150614-1.1.0-bgptunnels.jpg
Tim Osburn www.osburn.com W7RSZ
On Sun, Jun 14, 2015 at 08:44:05PM -0700, Tim Osburn wrote:
Brian, I've updated the drawing in response to your private email you sent to me. Would it be possible to "add" a shim box between the telescope project and your amprgw server? I think we could still achieve what we're trying to do if that is something you can do.
What you seem to suggest would be to put the SHIM essentially in series with the telescope and have amprgw forward all outbound 44/8 traffic to the SHIM - where some of it would be encapsulated to the various tunnel gateways. If I understand what you're proposing, the traffic to the BGP-routed 44 subnets would travel from the SHIM over the GRE tunnel to the ISPs who would then route it appropriately. All inbound 44/8 traffic which didn't pass the filters would be routed to the telescope. This requires that TWO boxes know about the gateway subnets, as well as having the SHIM learn about the BGP-routed subnets via BGP from the ISP over the GRE tunnel. This seems needlessly complex. It also means that all telescope data has to pass through the SHIM box, which could tax an underpowered box. (I'm not familiar with the SHIM box itself.)
A year or more ago we discussed a scheme where each BGP-routed subnet would simply register a route in the gateways table that pointed to a cooperating router (off the UCSD network) which was capable of decapsulating the tunneled packets and routing them appropriately. This has two advantages: it doesn't require any additional hardware and it doesn't require any changes in the UCSD gateway or network. I don't know how hard it would be to set up a general decapsulator in an existing router, but if it's not too difficult this is a simple step to get where we want to go, don't you think? True, it means that each new BGP subnet would have to register a single entry in the portal, but I don't see that as a hassle. What do you think of this alternative?
RE: "advertise /24 summary routes" The only downside to off loading 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. Where as if you add the shim box then all the traffic outside the allocated space in that /24 would pass onto the telescope making for better research data.
In the grand scheme of things, even rounded up to /24s, the total allocated ham radio space is miniscule compared to the unallocated space anyway. I think the researchers already factor this in. I also see the number of tunnel gateways decreasing in future. - Brian
On Sun, 14 Jun 2015, Brian Kantor wrote:
Date: Sun, 14 Jun 2015 21:45:44 -0700 From: Brian Kantor Brian@ucsd.edu Reply-To: AMPRNet working group 44net@hamradio.ucsd.edu To: AMPRNet working group 44net@hamradio.ucsd.edu Subject: Re: [44net] AMPRNet Interoperability with BGP
(Please trim inclusions from previous messages) _______________________________________________ On Sun, Jun 14, 2015 at 08:44:05PM -0700, Tim Osburn wrote:
Brian, I've updated the drawing in response to your private email you sent to me. Would it be possible to "add" a shim box between the telescope project and your amprgw server? I think we could still achieve what we're trying to do if that is something you can do.
What you seem to suggest would be to put the SHIM essentially in series with the telescope and have amprgw forward all outbound 44/8 traffic to the SHIM - where some of it would be encapsulated to the various tunnel gateways. If I understand what you're proposing, the traffic to the BGP-routed 44 subnets would travel from the SHIM over the GRE tunnel to the ISPs who would then route it appropriately. All inbound 44/8 traffic which didn't pass the filters would be routed to the telescope. This requires that TWO boxes know about the gateway subnets, as well as having the SHIM learn about the BGP-routed subnets via BGP from the ISP over the GRE tunnel. This seems needlessly complex. It also means that all telescope data has to pass through the SHIM box, which could tax an underpowered box. (I'm not familiar with the SHIM box itself.)
Well the "shim" box is there to run the BGP process and GRE termination since it can't be done on the FreeBSD server. True each box would need to pass along the traffic for the default route going up the drawing. But the BGP part of this would be a fully automated/self updating forwarding of routes. Once routes showed up in the global BGP table they appear in the shim box and just start routing without needing to do anything.
A year or more ago we discussed a scheme where each BGP-routed subnet would simply register a route in the gateways table that pointed to a cooperating router (off the UCSD network) which was capable of decapsulating the tunneled packets and routing them appropriately. This has two advantages: it doesn't require any additional hardware and it doesn't require any changes in the UCSD gateway or network. I don't know how hard it would be to set up a general decapsulator in an existing router, but if it's not too difficult this is a simple step to get where we want to go, don't you think? True, it means that each new BGP subnet would have to register a single entry in the portal, but I don't see that as a hassle. What do you think of this alternative?
I remember that, I setup a tunnel but I don't think anyone did any testing with it. We can try that again. So to recap that idea, that would be a IPIP tunnel from a none UCSD router (Router Z) on the internet to the amprgw server. You would then add the current 53 authorized BGP prefixes as static routes on the amprgw to go over that IPIP tunnel and then egress out to the internet from that router Z location. Router Z would need to allow traffic from any 44 IP Address to egress out router Z's ISP internet connectivity.
RE: "advertise /24 summary routes" The only downside to off loading 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. Where as if you add the shim box then all the traffic outside the allocated space in that /24 would pass onto the telescope making for better research data.
In the grand scheme of things, even rounded up to /24s, the total allocated ham radio space is miniscule compared to the unallocated space anyway. I think the researchers already factor this in. I also see the number of tunnel gateways decreasing in future.
- Brian
True, I was just thinking of the children here :)
Tim Osburn www.osburn.com 206.812.6214 W7RSZ
On 15.06.2015 07:17, Tim Osburn wrote:
I remember that, I setup a tunnel but I don't think anyone did any testing with it. We can try that again. So to recap that idea, that would be a IPIP tunnel from a none UCSD router (Router Z) on the internet to the amprgw server. You would then add the current 53 authorized BGP prefixes as static routes on the amprgw to go over that IPIP tunnel and then egress out to the internet from that router Z location. Router Z would need to allow traffic from any 44 IP Address to egress out router Z's ISP internet connectivity
+1
Once that's working it would be nice to let the maintainers of the current 53 authorized BGP prefixes decide (e.g. through the AMPRNet Portal) whether they want to add an IPIP route for their prefix pointing to router Z which is decapsulating traffic directed to these nets or not (some do setup an IPIP endpoint theirself already). This way we are able to keep End-to-End-Communication (Source-44 to Dest-44) alive and source-route-filtered gateways do not net to NAT through their ISPs commercial address(es).
Btw: My current workaround would be to parse the BGP-table of the Internet for net44-prefixes and do it myself (I have something similar to "router Z"). I would be happy if there is a non-private solution...
73, Jann
On Mon, 15 Jun 2015, Jann Traschewski wrote:
Date: Mon, 15 Jun 2015 07:37:56 +0200 From: Jann Traschewski jann@gmx.de Reply-To: AMPRNet working group 44net@hamradio.ucsd.edu To: AMPRNet working group 44net@hamradio.ucsd.edu Subject: Re: [44net] AMPRNet Interoperability with BGP
(Please trim inclusions from previous messages) _______________________________________________ On 15.06.2015 07:17, Tim Osburn wrote:
I remember that, I setup a tunnel but I don't think anyone did any testing with it. We can try that again. So to recap that idea, that would be a IPIP tunnel from a none UCSD router (Router Z) on the internet to the amprgw server. You would then add the current 53 authorized BGP prefixes as static routes on the amprgw to go over that IPIP tunnel and then egress out to the internet from that router Z location. Router Z would need to allow traffic from any 44 IP Address to egress out router Z's ISP internet connectivity
+1
Once that's working it would be nice to let the maintainers of the current 53 authorized BGP prefixes decide (e.g. through the AMPRNet Portal) whether they want to add an IPIP route for their prefix pointing to router Z which is decapsulating traffic directed to these nets or not (some do setup an IPIP endpoint theirself already). This way we are able to keep End-to-End-Communication (Source-44 to Dest-44) alive and source-route-filtered gateways do not net to NAT through their ISPs commercial address(es).
There would be no NATTING in this setup since to be the ISP for this design you will need to allow the 44 IP space to egress without being NATTED. There is no reason you need to NAT public IP Space to public space other then a policy, which if that is the case then you're not a good fit for a 44 IP space egress server.
Drawing: https://www.osburn.com/amprnet-150614-1.0.0-ipip_tunnels.jpg
Btw: My current workaround would be to parse the BGP-table of the Internet for net44-prefixes and do it myself (I have something similar to "router Z"). I would be happy if there is a non-private solution...
73, Jann
Tim Osburn www.osburn.com 206.812.6214 W7RSZ
On 15.06.2015 07:51, Tim Osburn wrote:
There would be no NATTING in this setup since to be the ISP for this design you will need to allow the 44 IP space to egress without being NATTED. There is no reason you need to NAT public IP Space to public space other then a policy, which if that is the case then you're not a good fit for a 44 IP space egress server.
I was just thinking about the IPIP-Mesh Linux Boxes (source-route filtered) which have a routing table like this:
0.0.0.0/0 via ISP 44.a.b.c/16 via IPIP-Endpoint X 44.x.y.z/20 via IPIP-Endpoint Y 44.o.p.q/22 via IPIP-Endpoint Z ...
Would be nice to have the 53 BGP prefixes in that table. Otherwise the connection will be established through the ISP (and therefore will be NATed). It would be just a nice *option* to keep the end-to-end communication in Network44 alive (if we consider backward compatibility).
73, Jann
On Sun, Jun 14, 2015 at 10:17:04PM -0700, Tim Osburn wrote:
I remember that, I setup a tunnel but I don't think anyone did any testing with it.
As I recall, I set up one route but I don't think anybody tried it. Who knows, it might have been working all along. You'd have to look in the encap table to see if the router address is somewhere in there as a gateway endpoint.
There's no question that the shim system is the more elegant and perhaps more useful mechanism, but I'm very concerned about the cost issue, as we have no budget to buy hardware. It'd have to be donated. People typically don't have rackmount servers sitting around. Especially not with a 10GbE interface, which might be necessary to connect to the telescope. - Brian
Maybe it is time for some crowdfunding?
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Brian Kantor Sent: Monday, June 15, 2015 09:04 To: AMPRNet working group Subject: Re: [44net] AMPRNet Interoperability with BGP
(Please trim inclusions from previous messages) _______________________________________________ On Sun, Jun 14, 2015 at 10:17:04PM -0700, Tim Osburn wrote:
I remember that, I setup a tunnel but I don't think anyone did any testing with it.
There's no question that the shim system is the more elegant and perhaps more useful mechanism, but I'm very concerned about the cost issue, as we have no budget to buy hardware. It'd have to be donated. People typically don't have rackmount servers sitting around. Especially not with a 10GbE interface, which might be necessary to connect to the telescope. - Brian
On 6/15/15 2:22 AM, Brian Kantor wrote:
There's no question that the shim system is the more elegant and perhaps more useful mechanism, but I'm very concerned about the cost issue, as we have no budget to buy hardware. It'd have to be donated. People typically don't have rackmount servers sitting around. Especially not with a 10GbE interface, which might be necessary to connect to the telescope.
There are drawbacks to crowdfunding. Plus my experience with getting donations from hams has been poor. We are a cheap bunch.
- Brian
10g interfaces?
What is the utilization of the interfaces? If it's a transiting an old freeBSD box (still need details on this), surely we're unable to do 10g Ethernet in something that old (5.3 was the time 10g was introduced for the Intel driver), and since that's the choke point, a raspberry PI or router-board would be able to handle 1g.
I have a quad xeon server I'd be willing to donate to it if need be. It's even got an IPMI in it and 6 x1g copper interfaces, and I use it as my backup virtual router lab.
How about a donation from the network telescope people, since they are using 44/8 for free? If they are unable to provide even the smallest help, what benefit does it give ham radio/ARDC for them to use the netblock?
Bryan,
You have it backwards. UCSD lets us use their network connectivity for free because it's beneficial for their research.
If they no longer find it useful then they may not be willing to swallow a /8 of random traffic.
If there are ISP's willing to do that for free, I'd be very surprised.
-Neil
On Mon, Jun 15, 2015 at 2:09 PM, Bryan Fields Bryan@bryanfields.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 6/15/15 2:22 AM, Brian Kantor wrote:
There's no question that the shim system is the more elegant and perhaps more useful mechanism, but I'm very concerned about the cost issue, as we have no budget to buy hardware. It'd have to be donated. People typically don't have rackmount servers sitting around. Especially not with a 10GbE interface, which might be necessary to connect to the telescope.
There are drawbacks to crowdfunding. Plus my experience with getting donations from hams has been poor. We are a cheap bunch. - Brian
10g interfaces?
What is the utilization of the interfaces? If it's a transiting an old freeBSD box (still need details on this), surely we're unable to do 10g Ethernet in something that old (5.3 was the time 10g was introduced for the Intel driver), and since that's the choke point, a raspberry PI or router-board would be able to handle 1g.
I have a quad xeon server I'd be willing to donate to it if need be. It's even got an IPMI in it and 6 x1g copper interfaces, and I use it as my backup virtual router lab.
How about a donation from the network telescope people, since they are using 44/8 for free? If they are unable to provide even the smallest help, what benefit does it give ham radio/ARDC for them to use the netblock?
-- Bryan Fields
727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 6/15/15 5:13 PM, Neil Johnson wrote:
Bryan,
You have it backwards. UCSD lets us use their network connectivity for free because it's beneficial for their research. If they no longer find it useful then they may not be willing to swallow a /8 of random traffic.
UCSD gets grants for their research (it's a full time job). It's not asking much for them to compensate ARDC for use of their space. Just because it's a non-profit doesn't mean they should be able to get use of the space for free.
44/8 is worth much more that some connectivity which can't be provisioned with dynamic routing. I'm willing to work with UCSD, but in today's world there is a premium on IP space. Ham radio is endowed with a very precious resource.
This argument is akin to saying "this TV station lets us put a repeater on their tower, but they get to use the repeater for non-ham purposes". Or being a student athlete in the NCAA and getting a nebulous "communications" degree for letting the school make millions off your talents.
I've seen the work CAIDA/UCSD does, it's good and benefits the Internet community, but I will not let this take precedence over the needs of amateur radio, vis-à-vis end to end reachability.
If there are ISP's willing to do that for free, I'd be very surprised.
I know of four. At least one would be willing to sign it in a contract. There a lots of hams in the upper echelons of IP carriers.
To date I've yet to see any numbers on the utilization of the amprgw so I really don't think it's that much traffic.
Brian, will you share the details on this?
On Sun, Jun 14, 2015 at 11:03 PM, Brian Kantor Brian@ucsd.edu wrote:
People typically don't have rackmount servers sitting around
I do. HP DL360 G5/G6 with dual Xeon Processors (1U) and redundant power supplies. Glad to donate that and a 10GigE card to the cause. Benefits of having worked for failed startups.
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
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
On Tue, Jun 16, 2015 at 07:09:45AM -0700, Cory (NQ1E) wrote:
Do we have a rough idea on how many /24s that would amount to?
After summarizing the smaller routes at the /24 level, the number of subnet routes that would have to be advertised is about 350. If we summarize at the /16 level, there would have to be about 12.
We *know* that most of the approx 475 gateways in the database are no longer active. These are still contributing to this total.
Despite multiple requests by Chris, so far no one with PHP programming experience has stepped forward to help write the program that is necessary to clear them out. I would wager that the number of subnet routes necessary would drop precipitously if we were to eliminate the inactive gateways. - Brian
I'm on a plane, sorry for the top post.
Brian, how much traffic does the current AMPRnet gw handle peak?
Would it be possible to aggregate some of these routes selectivily or have some people volunteer to move ip? In the greater scheme of things 350 prefixes is not huge.
My concern would be on the routing db and filter side. But this could be automated via rpsl.
On June 16, 2015 12:00:09 PM EDT, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jun 16, 2015 at 07:09:45AM -0700, Cory (NQ1E) wrote:
Do we have a rough idea on how many /24s that would amount to?
After summarizing the smaller routes at the /24 level, the number of subnet routes that would have to be advertised is about 350. If we summarize at the /16 level, there would have to be about 12.
We *know* that most of the approx 475 gateways in the database are no longer active. These are still contributing to this total.
Despite multiple requests by Chris, so far no one with PHP programming experience has stepped forward to help write the program that is necessary to clear them out. I would wager that the number of subnet routes necessary would drop precipitously if we were to eliminate the inactive gateways.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-- Bryan Fields 727-409-1194 http://bryanfields.net
In 44.24.0.0/16 we have multiple BGP gateways coming on line.
We have moved address space to accommodate larger masks and people have been willing to move as we explain the rationale and provide a window of time to accomplish the movement.
On Tue, Jun 16, 2015 at 9:09 AM, Bryan Fields bryan@bryanfields.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ I'm on a plane, sorry for the top post.
Brian, how much traffic does the current AMPRnet gw handle peak?
Would it be possible to aggregate some of these routes selectivily or have some people volunteer to move ip? In the greater scheme of things 350 prefixes is not huge.
My concern would be on the routing db and filter side. But this could be automated via rpsl.
On June 16, 2015 12:00:09 PM EDT, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jun 16, 2015 at 07:09:45AM -0700, Cory (NQ1E) wrote:
Do we have a rough idea on how many /24s that would amount to?
After summarizing the smaller routes at the /24 level, the number of subnet routes that would have to be advertised is about 350. If we summarize at the /16 level, there would have to be about 12.
We *know* that most of the approx 475 gateways in the database are no longer active. These are still contributing to this total.
Despite multiple requests by Chris, so far no one with PHP programming experience has stepped forward to help write the program that is necessary to clear them out. I would wager that the number of subnet routes necessary would drop precipitously if we were to eliminate the inactive gateways. - Brian _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-- Bryan Fields 727-409-1194 http://bryanfields.net
Incidentally, we are also creating VPN tunnels to bring 'islands' into routers that have BGP capability and advertising from those routers.
https://www.youtube.com/watch?v=PMI9YSM0mzY
On Tue, Jun 16, 2015 at 9:21 AM, K7VE - John k7ve@k7ve.org wrote:
In 44.24.0.0/16 we have multiple BGP gateways coming on line.
We have moved address space to accommodate larger masks and people have been willing to move as we explain the rationale and provide a window of time to accomplish the movement.
On Tue, Jun 16, 2015 at 9:09 AM, Bryan Fields bryan@bryanfields.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ I'm on a plane, sorry for the top post.
Brian, how much traffic does the current AMPRnet gw handle peak?
Would it be possible to aggregate some of these routes selectivily or have some people volunteer to move ip? In the greater scheme of things 350 prefixes is not huge.
My concern would be on the routing db and filter side. But this could be automated via rpsl.
On June 16, 2015 12:00:09 PM EDT, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jun 16, 2015 at 07:09:45AM -0700, Cory (NQ1E) wrote:
Do we have a rough idea on how many /24s that would amount to?
After summarizing the smaller routes at the /24 level, the number of subnet routes that would have to be advertised is about 350. If we summarize at the /16 level, there would have to be about 12.
We *know* that most of the approx 475 gateways in the database are no longer active. These are still contributing to this total.
Despite multiple requests by Chris, so far no one with PHP programming experience has stepped forward to help write the program that is necessary to clear them out. I would wager that the number of subnet routes necessary would drop precipitously if we were to eliminate the inactive gateways. - Brian _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-- Bryan Fields 727-409-1194 http://bryanfields.net
On Tue, Jun 16, 2015 at 09:25:01AM -0700, K7VE - John wrote:
Incidentally, we are also creating VPN tunnels to bring 'islands' into routers that have BGP capability and advertising from those routers.
So you're doing exactly what I'm proposing except that you're using modern VPN technology instead of legacy IPIP. - Brian
On Tue, Jun 16, 2015 at 9:40 AM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jun 16, 2015 at 09:25:01AM -0700, K7VE - John wrote:
Incidentally, we are also creating VPN tunnels to bring 'islands' into routers that have BGP capability and advertising from those routers.
So you're doing exactly what I'm proposing except that you're using modern VPN technology instead of legacy IPIP. - Brian
Precisely. One of the problems of using IPIP for this is that there is no feature in the protocol that tells us when a remote router is unreachable. There's also no authentication or message integrity. These are common features of modern VPN protocols. (Depending on the protocol, they also traverse NAT more easily.)
Knowing reachability allows us to selectively advertise BGP routes for only reachable routers. If a gateway operator maintains VPN tunnels to multiple BGP advertisement points, one of those BGP routers can go down for maintenance for a few hours without bringing down their linked repeater system, etc. During the downtime, all traffic would route over the other VPN interface.
Eventually, I'd like to support a multitude of VPN protocols, but for now we have only implemented IPsec.
Tom KD7LXL
I appreciate especially the filtering out of 44 addresses who are not in the dns by ucsd. I hate to loose that when it goes to another ISP. I remember well the days when that extra garbage was not filtered out and I will hate it when that is lost.
My gateway is presently just at a home connection with a static ip.
I object when that stuff is moved and no filtering will be in place whatsoever. With other words: UCSD is working fine.
So why is it that those BGP subnets have no mandatory IPIP entries in the list also? They don't have to route back over IPIP, only need to receive IPIP.
Easy solution, nothing drastic, KISS, and done in no time..
Bob VE3TOK
On 15-06-16 12:00 PM, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jun 16, 2015 at 07:09:45AM -0700, Cory (NQ1E) wrote:
Do we have a rough idea on how many /24s that would amount to?
After summarizing the smaller routes at the /24 level, the number of subnet routes that would have to be advertised is about 350. If we summarize at the /16 level, there would have to be about 12.
We *know* that most of the approx 475 gateways in the database are no longer active. These are still contributing to this total.
Despite multiple requests by Chris, so far no one with PHP programming experience has stepped forward to help write the program that is necessary to clear them out. I would wager that the number of subnet routes necessary would drop precipitously if we were to eliminate the inactive gateways.
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
-
Antonio Querubin -
Boudewijn (Bob) Tenty -
Brian Kantor -
Bryan Fields -
Cory (NQ1E) -
Don Fanning -
Jann Traschewski -
K7VE - John -
Marius Petrescu -
Neil Johnson -
Tim Osburn -
Tom Hayward