In light of what was discussed here, I would propose the following usage of the "radio" flag:
A subnet marked as "Radio" should use this flag exclusively and inherit the Tunnel or BGP flag from its parent network. For allocation only purposes only, a network without any flags is enough.
Rationale: A pure radio network doesn't exist from the point of view of ampr-net since it would not present any internet connectivity. If this connectivity is present, meaning it is reachable by any kind of means, IPIP or BGP routed, it will allow a connectivity method, the same as its parent network.
73s, Marius, YO2LOJ
It seems to me that "radio" is the wrong word. The fact that the physical layer used by a subnet is "radio" says nothing about whether the network is reachable from the Internet. In fact, "radio" connectivity is what we should all be striving for!
Perhaps a different word to achieve the result you're after. I'm not a wordsmith. But perhaps: isolated, independent, separate, detached ... These would all require explanation. Isolated from what? Independent of what? So maybe something that's more self-explanatory of exactly what you're trying to identify: NoInternetAccess
Michael N6MEF
-----Original Message----- A subnet marked as "Radio" should use this flag exclusively and inherit the Tunnel or BGP flag from its parent network. For allocation only purposes only, a network without any flags is enough.
Rationale: A pure radio network doesn't exist from the point of view of ampr-net since it would not present any internet connectivity. If this connectivity is present, meaning it is reachable by any kind of means, IPIP or BGP routed, it will allow a connectivity method, the same as its parent network.
On 16.03.15. 16:50, Michael E Fox (N6MEF) wrote:
It seems to me that "radio" is the wrong word. The fact that the physical layer used by a subnet is "radio" says nothing about whether the network is reachable from the Internet. In fact, "radio" connectivity is what we should all be striving for!
Perhaps a different word to achieve the result you're after. I'm not a wordsmith. But perhaps: isolated, independent, separate, detached ... These would all require explanation. Isolated from what? Independent of what? So maybe something that's more self-explanatory of exactly what you're trying to identify: NoInternetAccess
I think common word for isolated network is 'island'.
--- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Maybe there is time rethink a little our gatewaying approach to solve the BGP/IPIP issue.
Some thoughts on this...
So we have: - TUNNEL - reachable via IPIP - BGP - directly reachable on the Internet Having none of the connectivity flags set actually means "isolated", or "island", or whatever (isolated seems more sugestive to me). That radio flag is in fact not needed.
IMHO the only thing missing at the moment is the possibility of the ampr-gw to forward traffic from the IPIP mesh network from tunnels to BGP announced networks (BGP flag set, TUNNEL not set) in the same way as with regular IP addresses. This would work flawless with the current addressing scheme: - IPIP to IPIP go directly via tunnels - BGP to BGP of course works directly via Internet - BGP to IPIP results in a correct routing via 44.0.0.1 (I can not check if it is filtered at ampr-gw, it probably is)
The only thing missing is IPIP to BGP connectivity via the ampr-gw which is filtered.
Assuming the last function could be implemented (IPIP to BGP via ampr-gw), in regard to publishing these BGP routes, there are 2 options: - Not published at all in the encap data, leaving the routing options to the GW administrator (e.g. all 44/8 via 169.228.66.251). The downside would be that invalid addresses are forwarded resulting in higher ampr-gw traffic - Published as subnets with gateway 169.228.66.251 in encap and RIP - this option would drop the traffic to invalid addresses.
This approach could actually solve the interconnection issues for the 2 ampr network types.
73s de Marius, YO2LOJ
The only thing missing is IPIP to BGP connectivity via the ampr-gw which
is filtered.
It's actually much worse than just a filter. The ampr-gw doesn't make the 44/8 BGP announcements out to the internet itself. Instead, the announcement is made higher up in the UCSD network and the traffic is statically routed back down to the ampr-gw system. This means that any packets ampr-gw attempts to send to 44 addresses on other networks will never make it to the internet and will simply be routed back to itself. This is why BGP networks need to also run the IPIP mesh if they want to talk to any non-BGP 44 networks. Even with the IPIP mesh, BGP networks can never talk to ampr-gw and expect to hear a response.
Has there ever been any progress in getting a fix for this, Brian?
IMHO a network that radio only and not on the internet either the sub net should be using 10.x.x.x, 192.168.x.x or 172.??? address. If later they do connect to the net and then try and route it could cause issues.... Like companies that found that out when they had used 1.x.x.x which is assigned to the US DoD (I think)
Alternately a 44net class C could be set aside for un-coordinated un-rotatable use.
Lin N4YCI
On Mon, Mar 16, 2015 at 10:33:31PM +0200, Marius Petrescu wrote:
- BGP to IPIP results in a correct routing via 44.0.0.1 (I can not check if
it is filtered at ampr-gw, it probably is)
It's not filtered at amprgw, it's misrouted by a default route in an upstream router. It is not practical to delete that default route and replace it with some 200+ individual routes, which is what it would take to eliminate the default route.
To fix this, we could partition the network - move all BGP-announced subnets to the range 44.192.0.0/10 and up. Then it would be possible to change the default route in the upstream router here at UCSD to allow egress of destination addresses in the top quarter of 44/8 and connectivity would be restored.
There are 50 BGP-announced subnets (and a few pending) which would have to be rehomed. It is not clear how many actual hosts would have to be renumbered in doing this. My guess is that most of the BGP-announced subnets are sparsely populated at this point. Likewise, any tunneled hosts in the top quarter would have to be rehomed to lower addresses.
Another alternative was proposed a while back where someone with good connectivity could operate a decapsulating gateway and the tunnel network would simply have tunnel routes to the BGP subnets via that gateway. Doing it this way would avoid having to re-address anyone. The problem with this solution is finding someone to operate the decap gateway. - Brian
It is not practical to delete that default route and replace it with some
200+ individual routes
The opposite approach may also be possible if your upstream network operators are up for it. You could leave the /8 route as it is today, but setup a BGP filter that propagates the more specific internet-based 44 routes to your upstream devices. This would allow the gw to remain a catch-all for research purposes (if that's still a thing).
On 2015-03-16 22:13, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Mon, Mar 16, 2015 at 10:33:31PM +0200, Marius Petrescu wrote:
- BGP to IPIP results in a correct routing via 44.0.0.1 (I can not
check if it is filtered at ampr-gw, it probably is)
It's not filtered at amprgw, it's misrouted by a default route in an upstream router. It is not practical to delete that default route and replace it with some 200+ individual routes, which is what it would take to eliminate the default route.
Actually, the border routers of UCSD should just allow more specific announcements of 44/8 to enter their IRP (iBGP, OSPF, ISIS, whatever) from their upstreams. As the more specific route allows wins, the default route 44/8 could remain in place.
In that case routing at UCSD would work like for anybody else. If there is a more specific route for a subnet of 44/8 honor that route and use it, if there is no specific route for a subnet of 44/8 than use the 44/8 route.
However, all this assumes that the IRP at UCSD is based on routing protocols other than "static".
73 de Marc
-
Brian Kantor -
Cory (NQ1E) -
Lin Holcomb -
Marc, LX1DUC -
Marius Petrescu -
marius＠yo2loj.ro
-
Michael E Fox (N6MEF) -
YT9TP - Pedja