Re: [MEL-NAP] Putting AUIX local domains into squid

> Andres Kroonmaa wrote:
> > If it is only a matter of determing whether host is local or behind
> > the border gateway, one might define some sort of localness radius in
> > hops, and then construct and send a single udp traceroute packet to
> > the host of interest, then watch for the gateway that returns icmp.
>
> Isn't this what minimum_direct_hops does? Actually, I'm not familiar
> with this and the db stuff, I've never even used it.

    Yes, sort of. If we use source_ping also, this host would have been
 in net_db cache and there would be no need to send a probe at all. What
 makes icmp_pinging not-so-popular is that it is sending probes all over
 the world, bothering many paranoid amdins, who block icmp-s on their
 firewalls, it is unreliable over long distances and gives little info
 about actually which neighbor is closest to it. Using probes with limited
 TTL, we can limit probes to some local radius, although we will loose
 info about hopcount and RTT to the actual source.

> > If your border gateway is always say 4 hops away, you can send a udp
> > that will be dropped in 4 hops by exact this gateway. It would be
> > fairly easy to determine whether host is behind a slow link by simply
> > expecting this gateway to drop foreign probes - anything other is local.
>
> However, what if you have a server on the other side of a slow, congested
> link from your Squid. That's one hop, while you might have another server
> that is five hops away, though those hops are through fast local links?

    Yep, that is a problem, but no more than with any kind of probing.
 Btw, we are going to access this server anyway, we are just wishing to
 know if it should be accessed directly or via parent on the other side
 of yet another congested international link? Hosts that are closer than
 our ttl will answer with "icmp destination unreacheable - bad port".
 From this icmp we can extract both RTT and hopcount and cache it.

    btw, if we wish to make things more complex we could think of some
 algoritm like this:

 1. Upon startup trace each parent/sibling, build a list of gateways on the
    way. Find those that are unique for each neighbor, remember hops (TTL)
    Or, use config file for that.
 2. If host is about to be probed, send a probe with some ttl X, if any
    other gateway but our border gateway responds, we might lookup it
    from the list from 1. This way we might know which parent/sibling is
    closest to the source, (sometimes ;)
 3. If we had many different TTL-s from (1), we'll have to repeat step 2
    for every TTL, increasing udp traffic...

 If using configuration, it might look something like:

    if probettl=X, and gateway=x.x.x.x, then neighbor=CCC
    if probettl=Y, and gateway=x.x.x.y, then neighbor=DDD
    ...

 Introducing routing tables into squid would mean major headache anyway,
 IMO probe&cache approach might do better.

 As this and net_db stuff is at all introduced to solve the need to know
 which neighbor is the right one to use, I would like to just point out,
 that building up some routing decision database in squid process is tough
 task and copies that of actual routers do, why not ask those routers for
 right decisions?

 Actually, what I have suggested is quite a same thing that Miguel has
 proposed, but as traceroute in its full might take too long to complete,
 I tried to reduce the number of probes to some minimum, looking only at
 some specific turning-points.

 And, btw, if source_ping would set and use Record_route option, it would
 have a trace for upto 9 hops for free.

-------------------------------------------------------------------
 Andres Kroonmaa Telefon: 6308 909
 Network administrator
 E-mail: andre@ml.ee Phone: (+372) 6308 909
 Organization: MicroLink Online
 EE0001, Estonia, Tallinn, Sakala 19 Fax: (+372) 6308 901
-------------------------------------------------------------------
Received on Tue Jul 29 2003 - 13:15:40 MDT