17 Jul
2013
17 Jul
'13
1:45 a.m.
I just think the deal is we really should not be required to do
something that we dont have as a project goal. If a BGP site wants to
play in the amprgw world great if not then then no. That is like
saying your FM radio must also be able to receive SSB to opperate on
the 440mhz band. Maybe we dont want to do SSB or incur the extra
complexity and cost. I think the idea is these are not the same
projects they just use the same "band" IP space there is a plan to
divide the sub nets up so that it is easy to see that whole class Bs
or what ever is allocated is not necessarily going to be accessible
unless you specifically make changes to the apmprgw system. It is not
necessary for the packets to route back and forth. It just adds an
extra level of complexity that is not needed for our project goals of
hosting radio projects that are fully rotatable to the internet.
Lin
On Tue, Jul 16, 2013 at 2:35 PM, Heikki Hannikainen <hessu(a)hes.iki.fi> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Tue, Jul 16, 2013 at 6:00 PM, Brian Kantor <Brian(a)ucsd.edu> wrote:
--
Lin Holcomb
Office: +1 404 806 5412
Mobile: +1 404 933 1595
Fax: +1 404 348 4250
On Tue, Jul 16, 2013 at 04:48:57PM +0300, Heikki
Hannikainen wrote:
Yes, exactly. How about if someone sends an encapsulated 44-to-44
packet to amprgw, and the packet has a destination address in one of
the BGP subnets, and the subnet is not in encap database? Would that
get routed out from amprgw (unencapsulated), or would it be dropped?
And wouldn't it be preferred to have that go directly encapsulated to
an encap gateway box at the BGP-enabled site?
If I understood him right, Bob Tenty is suggesting that BGP-enabled
sites should be removed from the encap database altogether, and says
that packets from tunnel-only gateways to those networks should always
be sent via amprgw. My opinion is in the opposite end of the spectrum.
Also, doesn't amprgw at UCSD drop net-44
packets on the floor unless
they're in encap.txt? Or is there an exception for BGP announced
networks?
We would drop them since they're not in the encap database, but they don't
show up here from the Internet in the first place since the narrower BGP
subnets override the larger /8 network and the packets aren't routed here. A solution would be to have the border router at
each of the
directly-connected subnets also have a full set of tunnel routes and
interfaces installed, as it could then participate in the tunnel mesh
and should then be in the encap file. I don't see commercial internet
providers doing that.
The border router does not necessarily need a tunnel route + interface
set. All that is needed is the traditional linux box sitting near it,
that act as the encap gateway with rip44d or whatever. The border
router can have a 44/8 route towards the local encap box for outgoing
packets, so that packets going to the rest of the old 44/8 does not
need to go back to amprgw.ucsd.edu.
If I were to create some fancy new bandwidth-heavy service, and host
it on a BGP-enabled net-44 address here, I think my main motive would
be to (1) make it available to all net-44 users in addition to the
Internet, and (2) make it run fast and not go via amprgw all the time.
If I only had BGP but no encap mesh routes, I suspect both (1) and (2)
would not happen - I'd just be using a net-44 address on the Internet
with quite broken net-44 routing.
So this means that in order for the the
directly-connected subnets to
also participate in the tunnel mesh, there has to be a tunnel-enabled
router downstream of the connection to the commercial Internet.
Yup, my thoughts exactly. Downstream, or on its side.
My point is that the BGP sites *should* have a tunnel-enabled gateway
router in their setup, and they should be in the encap routing table
to keep them well-connected.
- Hessu
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
http://www.ampr.org/donate.html