10 Apr
2014
10 Apr
'14
10 p.m.
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:
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.
(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. 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