On 04/10/2014 02:46 PM, Marc, LX1DUC wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 10/04/2014 23:33, Marc, LX1DUC wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 10/04/2014 23:23, Bart Kus wrote:
At step (c) the packet matched a route that is associated with an IPIP tunnel. The inner headers are from-44.whatever and to-44.24.240.0/20. When that match is made, the packet is IPIP encapsulated, and given new outer src/dst IPs. The dst-IP in this case should be 44.24.221.1, and the src-IP should be whatever local-address was configured for the IPIP tunnel (which should be routable over his public ISP). Then the router has to make a 2nd routing decision about how to deliver to 44.24.221.1. In this case, it should match default route (0.0.0.0/0).
Please disregard this message, I was reading the previous message and replying to this one.
Your proposed setup could work for internal 44net traffic. But due to restrictions with routing setup of 44/8 @ UCSD, traffic from the commercial internet wouldn't necessarily always reach you. In cases where traffic is not routed to according to your BGP announcement, traffic would go to UCSD where it would end up in a routing loop.
If the traffic is not respecting our 44.24.240.0/20 BGP announcement, then there has been an Internet routing error. We can work on any such edge cases as they come up, but 99% of the time things will route OK.
Additionally some check would need to added to the portal 44GW should only be allowed to have a 44net address if that address is part of an independent BGP announce. Tunneling of a 44net to a 44GW which itself is only reachable via another 44GW and tunnel is probably not desirable.
I think a simpler/stricter check might be to make sure the 44GW is (1) part of an allocated 44net, and (2) that 44net is not configured with a gateway at all, and (3) the 44GW is not in the range of any of the 44nets being presently configured with said gateway.
Furthermore, if the 44net which contains the 44GW ever wishes to configure a gateway for itself, it should be denied until all its IPs are not in service as 44GWs for other 44nets.
This is a fair bit of logic, which is why I asked to have our 44.24.221.1 gateway configured manually first and only then have the portal work done. It'll probably take a while to implement the right logic here.
--Bart