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
On Fri, Mar 13, 2015 at 6:30 PM, Brian Kantor Brian@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
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
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
-
Brian Kantor -
Marius Petrescu -
Tom Hayward