12 Nov
2014
12 Nov
'14
11:07 a.m.
Brian,
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. 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.
If the described issue doesn't exist, or can be resolved, I think that
would be the easiest way for everyone.
Nigel
(Please trim inclusions from previous messages)
_______________________________________________
Nigel et al;
On Wed, 2014-11-12 at 06:59 -0800, Nigel Vander Houwen wrote:
If a âreverseâ list of users who announce via
BGP and use 44/net
addresses as tunnel endpoints would help with getting these routing
setups better situated so traffic doesnât end up lost in the loop,
then I would be pleased to assist in itâs creation. Ideally, this
would be put in place at UCSD itself, so that individual users could
still route via UCSD, and UCSD would take care of sending it along to
the endpoint. (Us or someone else)
Actually, in thinking this over I may have come up with a solution...
A gateway entry would be required in encap.txt/ripv2 in which that
gateway would live at UCSD, and those whom announce their own routes
would naturally see them as an encapped route to UCSD, who in turn can
route non-encapped to those points. This would also solve the multiple
SAFed gateways from having to incorporate individual policy route rules
for those who are BGP announced. They would instead route normally from
their 44-net policy rules.
I could assist with this if needed, and it would cure more than just
your subnet since more are announced. As BGP routes are added, (I'll
assume) Brian would have to enter in these routes into his gateway
within the portal. This shouldn't be too difficult since requests to
allow one's subnet to be announced still requires approval.
--
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.
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net