23 May
2014
23 May
'14
1:04 a.m.
Marius and Brian,
I assume that the route causing the trouble for you emanates from a
static route set up by you Brian on the inside of the tunneled part?
On our side , we are happy with any of the solutions that you Marius
points at.
We just announce via BGP, making 44.140.0,0/16 a regular part of
Internet. We leave the rsponsibility for preventing unauthorised
transmission into amateur radio spectrum to the licensed amateurs
setting up the transceievers.
We are also thinking of a cerificate science gateway like mechanism for
automatic authentication of licensed users.
Bjorn
On 05/23/2014 06:29 AM, Marius Petrescu wrote:
(Please trim inclusions from previous messages)
_______________________________________________
The problem is that the route 44.140.0.0/16 via 44.140.0.1 creates a routing
loop.
The moment one sets this route ont their machine, all traffic, including the
one to the gateway will be encasulated and sent via the tunnel to the
gateway which is impossible...
So for such a setup to work there are 3 solutions:
1) classic:
44.140.0.0/16 via 192.16.126.18
2) 2 routes:
44.140.0.1/32 via 192.16.126.18
44.140.0.0/16 via 44.140.0.1
This will break most setups since usually there is no recursive next-hop
lookup on a sinlge machine GW system.
In a full routed dedicated tunnel host + router combination this would work
(I can give you the details).
3) don't broadcast anything at all
In this case, ham traffic is treated as any regular internet traffic and
nat-ed to ones public IP on their gateway (if there is no 44/8 route via
UCSD),
If the client is also bgp announcet, case in which it wil work flawless.
The problem is that in this case you can not diferentiate ham traffic from
bgp unannounced subnets from regular internet traffic on your GW side.