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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net