16 Mar
2015
16 Mar
'15
8:41 a.m.
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
16 Mar
16 Mar
3:50 p.m.
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.
7:58 p.m.
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
8:33 p.m.
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
8:58 p.m.
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?
9:03 p.m.
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
9:13 p.m.
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
10 p.m.
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).
17 Mar
17 Mar
11:32 a.m.
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:
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
- 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.
3331
days inactive
3332
days old
8 comments
8 participants
participants (8)
-
Brian Kantor -
Cory (NQ1E) -
Lin Holcomb -
Marc, LX1DUC -
Marius Petrescu -
marius＠yo2loj.ro
-
Michael E Fox (N6MEF) -
YT9TP - Pedja