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:
classic: 44.140.0.0/16 via 192.16.126.18
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).
- 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.