12 Nov
2014
12 Nov
'14
12:08 p.m.
Nigel;
On Wed, 2014-11-12 at 08:07 -0800, Nigel Vander Houwen wrote:
I believe the issue stands (and this is hearsay) that
the 44/net router at
UCSD assumes that ALL 44/8 traffic goes to them, so they can't route to
externally announced 44/8 addresses.
If you're using BGP, smaller subnet broadcasts take a higher priority
and UCSD shouldn't know about your route, but this shouldn't necessarily
prevent it from routing out to you if an exceptions table
somewhere/somehow is made. Right now as it stands, a 44-net/BGP route
not in encap/rip I wouldn't see and I would default route it to UCSD via
encap based on both route tables (aka: default) and policy route rules
(send 44/8 via tunnel). Any non-BGP amprnet routing would not go via
UCSD, but instead be point-to-point between ends.
So until that got fixed, I don't
believe your idea would be workable. However, that's not too different (if
I understand you correctly) from what I proposed, that UCSD handles the
routing (if the issue were to be resolved) for entries that aren't in the
encap, and end points/users can still route to specific tunnel entries,
and the rest of 44/8 to UCSD.
You're correct that USCD would have to allow outbound routing via encap
to the 44-net IPs broadcast by BGP. My suggestion to accomplish this
would be if some sort of an amprbgp-gw existed to decode the remote
non-BGP 44-net encapsulated frames, and link the routing out. Then
again, it doesn't even have to necessarily be at UCSD either. It could
be anywhere that's not SAFed, and has free 44-net to 44-net routing via
non-encapsulated means. An ideal location would be one of the locations
who is announcing their block via BGP that can put say eth0 on a non-44
Ip and eth1 on their announced 44-net IP, with a tunnel interface to
cover those encapsulated frames coming in.
The commercial IP of eth0 would be the gateway for the tunnel interface
IP, and the outbound route would be via eth1 using the BGP announced
44-net IP. If you have a box that could do something such as this, I'd
be happy to test the theory. If interested, contact me off list.
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.