14 Jun
2015
14 Jun
'15
8:26 p.m.
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
14 Jun
14 Jun
9:20 p.m.
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
11:01 p.m.
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(a)lavanauts.org
xmpp: antonioquerubin(a)gmail.com
11:43 p.m.
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
11:08 p.m.
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
11:44 p.m.
On Sun, 14 Jun 2015, Brian Kantor wrote:
Date: Sun, 14 Jun 2015 18:20:22 -0700
From: Brian Kantor <Brian(a)ucsd.edu>
Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
To: AMPRNet working group <44net(a)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:
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
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 
15 Jun
15 Jun
12:45 a.m.
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
1:17 a.m.
On Sun, 14 Jun 2015, Brian Kantor wrote:
True, I was just thinking of the children here :)
Tim Osburn
www.osburn.com
206.812.6214
W7RSZ
Date: Sun, 14 Jun 2015 21:45:44 -0700
From: Brian Kantor <Brian(a)ucsd.edu>
Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
To: AMPRNet working group <44net(a)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:
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.
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?
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 
1:37 a.m.
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
1:51 a.m.
On Mon, 15 Jun 2015, Jann Traschewski wrote:
Date: Mon, 15 Jun 2015 07:37:56 +0200
From: Jann Traschewski <jann(a)gmx.de>
Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
To: AMPRNet working group <44net(a)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:
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
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
Tim Osburn
www.osburn.com
206.812.6214
W7RSZ
3:47 a.m.
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
--
Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany
Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn
2:03 a.m.
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
2:10 a.m.
Maybe it is time for some crowdfunding?
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)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
3:09 p.m.
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
5:13 p.m.
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(a)bryanfields.net> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On 6/15/15 2:22 AM, Brian Kantor wrote:
--
Neil Johnson
http://erudicon.com
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
6:30 p.m.
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?
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
3:46 a.m.
On Sun, Jun 14, 2015 at 11:03 PM, Brian Kantor <Brian(a)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.
16 Jun
16 Jun
4:11 a.m.
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
10: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
noon
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
12:09 p.m.
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(a)ucsd.edu> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Tue, Jun 16, 2015 at 07:09:45AM -0700, Cory (NQ1E) wrote:
--
Bryan Fields
727-409-1194
http://bryanfields.net
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net 
12:21 p.m.
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(a)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(a)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(a)hamradio.ucsd.edu
> >http://hamradio.ucsd.edu/mailman/listinfo/44net
>
> --
> Bryan Fields
> 727-409-1194
> http://bryanfields.net
>
12:25 p.m.
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(a)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(a)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(a)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(a)hamradio.ucsd.edu
>> >http://hamradio.ucsd.edu/mailman/listinfo/44net
>>
>> --
>> Bryan Fields
>> 727-409-1194
>> http://bryanfields.net
>>
12:40 p.m.
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
1:07 p.m.
On Tue, Jun 16, 2015 at 9:40 AM, Brian Kantor <Brian(a)ucsd.edu> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Tue, Jun 16, 2015 at 09:25:01AM -0700, K7VE - John wrote:
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
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
6:36 p.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
3257
days inactive
3258
days old
26 comments
12 participants
participants (12)
-
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