13 Mar
2015
13 Mar
'15
9:30 p.m.
At the current moment I can see no way for an AMPRNet subnet to be both
TUNNEL and DIRECT (BGP-announced) connected, unless a special provision
has been made to operate a gateway from a non-44/8 address into the
BGP-connected subnet.
This is because the tunnel mesh can't reach 44/8 addresses that aren't
reachable via a non-44/8 tunnel entrance.
This means that we can't have gateways whose entrance address is in 44/8.
This implies that TUNNEL and DIRECT should be mutually-exclusive options
in allocation requests.
I'd be happy to be wrong about this.
- Brian
13 Mar
13 Mar
10:50 p.m.
On Fri, Mar 13, 2015 at 6:30 PM, Brian Kantor <Brian(a)ucsd.edu> wrote:
At the current moment I can see no way for an AMPRNet
subnet to be both
TUNNEL and DIRECT (BGP-announced) connected, unless a special provision
has been made to operate a gateway from a non-44/8 address into the
BGP-connected subnet.
This is because the tunnel mesh can't reach 44/8 addresses that aren't
reachable via a non-44/8 tunnel entrance.
There's a diagram that shows this. The red box is what you're talking about:
http://www.hamwan.org/t/AMPRNet
(sorry, I couldn't find the original source)
This means that we can't have gateways whose
entrance address is in 44/8.
Seems to work just fine for us (with 44.24.240/20), in most cases. The
traffic doesn't come from 44/8 addresses, it comes from their tunnel
endpoints. Their ISPs have no problem routing to 44.24.221.1 because
it's announced globally with BGP. Since we're talking about a tunnel
mesh, it's the tunnel gateway ISP that needs to reach the other tunnel
gateway, not AMPR gateway. Packets going out will have a source IP
from their ISP and a payload of an IPIP packet.
Tom KD7LXL
14 Mar
14 Mar
3:09 a.m.
Hello,
I see this a little different.
Actually, the restriction is not the gw address 44/8.
A gw wit 44/8 address can be used, as long as that gw address is NOT a
tunnel and accepts IPIP traffic from any IP range.
Let me give an example:
44.0.0.0/24 -> BGP announced, no tunnel, no encap entry
44.0.1.0/24 -> regular tunnel setup, encap entry with tunnel endpoint
44.0.0.1
44.182.21.0/24 -> my network, gw address 1.2.3.4, tunnel
The access to 44.0.0.0/24 is the same as regular internet traffic, meaning 2
variants.
1. If my ISP does no source filtering, this setup is a little tricky,
involving or not ampr-gw depending on the routers on the way.
44.182.21.0/24->44.0.0.0/24 fill go directly via internet, without passing
ampr-gw.
Return traffic will either come back the same way, iff all routers track the
connection (inprobably), or will have a return path via amprgw, where
packets will be discarded, since ampr-gw AFAIK drops traffic from 44 sources
and allows only non-ampr return traffic.
2. My ISP does source filtering, so I need to use NAT to my public IP, in
which case everything works great on accessing 44.0.0.0/24, but using my
public IP as src address.
Now regarding 44.0.1.0/24
Using the second access variant (NAT), any IPIP encap traffing from my own
gw to the subnet gateway (44.0.0.1) will be working, the tunnel being
established between my public IP (1.2.3.4) and the BGP announced peer, which
is from the ISPs/Internet's POV a regular IP address, and does not pass
ampr-gw, in neither direction.
Any traffic for 44.0.1.0/24 is correctly encapsulated on 1.2.3.4 and
decapsulated on 44.0.0.1, and the other way around.
This is fully supported at the moment.
I can also imagine an 2 step IPIP encapsulation between 2 tunneled networks,
but there is a routing loop problem in the current implementation.
So, the only restriction applies to the fact that a tunnel endpoint for a
subnet CAN NOT be on a encap announced network.
73s de Marius, YO2LOJ
5:55 a.m.
Sorry, but I think I used an bad example, so please ignore the previous
message.
(Or assume 44.0.2.0/24 instead of 44.0.0.0/24 to avoid confusions with the
ampr gateway IP)
Corrected version with add ons:
Let me give an example:
44.0.1.0/24 -> regular tunnel setup, encap entry with tunnel endpoint
44.0.2.1
44.0.2.0/24 -> BGP announced, no tunnel, no encap entry
44.182.21.0/24 -> my network, gw address 1.2.3.4, tunnel
The access to 44.0.2.0/24 is the same as regular internet traffic, meaning 2
variants.
1. If my ISP does no source filtering, this setup is a little tricky,
involving or not ampr-gw depending on the routers on the way.
44.182.21.0/24->44.0.2.0/24 fill go directly via internet, without passing
ampr-gw.
Return traffic will either come back the same way, iff all routers track the
connection (inprobably), or will have a return path via amprgw, where
packets will be discarded, since ampr-gw AFAIK drops traffic from 44 sources
and allows only non-ampr return traffic.
2. My ISP does source filtering, so I need to use NAT to my public IP, in
which case everything works great on accessing 44.0.2.0/24, but using my
public IP as src address.
Now regarding 44.0.1.0/24
Using the second access variant (NAT), any IPIP encap traffing from my own
gw to the subnet gateway (44.0.2.1) will be working, the tunnel being
established between my public IP (1.2.3.4) and the BGP announced peer, which
is from the ISPs/Internet's POV a regular IP address, and does not pass
ampr-gw, in neither direction.
Any traffic for 44.0.1.0/24 is correctly encapsulated on 1.2.3.4 and
decapsulated on 44.0.2.1, and the other way around.
This is fully supported at the moment, assumed that there is NO default 44/8
route via ampr-gw.
I can also imagine an 2 step IPIP encapsulation between 2 tunneled networks,
but there is a routing loop problem in the current implementation, which can
not be resolved on a single machine.
It can work on a router + gateway server, but I think this is out of scope,
because if one has already an 44/8 access via a tunnel, and such an
encapsulation is futile.
So, the only restriction applies to the fact that a tunnel endpoint for a
subnet CAN NOT be on an IPIP encaped network, whith the most common
situation being that the gateway is on the SAME subnet as the destination
subnet.
Using ampr-ripd, this error is avoided by the daemon by dropping subnets for
which the endpoint is inside its own subnet, but it would be great not
allowing any setup in the web interface, for which the gateway is already in
a defined subnet. BGP announced networks have to be announced in the
encap/RIP data ONLY if they offer an IPIP endpoint.
73s de Marius, YO2LOJ
3351
days inactive
3351
days old
3 comments
3 participants
participants (3)
-
Brian Kantor -
Marius Petrescu -
Tom Hayward