14 Mar
2015
14 Mar
'15
4: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