Re: [44net] TUNNEL vs DIRECT connection of subnets

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