Re: route cacheing for gif(4) should be optional

From: Andre Oppermann (andre_at_freebsd.org)
Date: 11/29/04

  • Next message: Gleb Smirnoff: "Re: route cacheing for gif(4) should be optional" 
    Date: Mon, 29 Nov 2004 16:14:01 +0100
To: Gleb Smirnoff <glebius@freebsd.org>

    Gleb Smirnoff wrote:
    >
    > On Thu, Nov 25, 2004 at 09:55:10PM -0500, James wrote:
    > J> On Thu, Nov 25, 2004 at 05:06:41PM +0300, Gleb Smirnoff wrote:
    > J> > Back to this problem:
    > J> >
    > J> > http://freebsd.rambler.ru/bsdmail/freebsd-net_2004/msg01305.html
    > J> >
    > J> > I've found two more people who dislike this feature of gif(4).
    > J> > So I'd like to make it optional.
    > J> >
    > J> > We already have LINK2 flag removing sourceroute filter from gif(4),
    > J> > which is commonly used in asymmetrically routed networks. I suggest
    > J> > to use this flag also for disabling route cacheing, since asymmetricity
    > J> > often appears in dynamically routed networks, and if one runs dynamic
    > J> > routing, he probably wants to remove route cacheing, too.
    > J>
    > J> I'd think we should create a separate option for removing the route
    > J> cache. Sometimes, certain people want to use the tunnel at the highest
    > J> maximum performance possible with both sourceroute filter disabled
    > J> and tunneling routes allocated at their creation time. Perhaps link3 is a
    > J> good place for this option?
    >
    > There is no LINK3 flag :)
    >
    > However, gif(4) does not use LINK0 flag. It was used in past. We can utilize
    > it now. Any objections?

    IMO you should scrap it altogether. However there have been reasons for
    storing the rtentry pointer in struct gif. In the old days ip_output()
    required an rtentry pointer to be passed on, this is no longer the case.
    And it was sort of a safe-guard to make it harder to send the gif encapsulated
    packets back through the same gif interface. That didn't work really well
    and as I say it should be scapped instead of rigged on somewhere else with
    yet another obscure option. ;) 

    -- 
Andre
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Gleb Smirnoff: "Re: route cacheing for gif(4) should be optional"

    Relevant Pages

    • Re: route cacheing for gif(4) should be optional
      ... A>> storing the rtentry pointer in struct gif. ... A>> required an rtentry pointer to be passed on, this is no longer the case. ... > When a route flap occurs in dynamicly routed network my gif tunnels are stuck. ... This can give preferences of caching among with satisfactory time of renewal. ...
      (freebsd-net)
    • Re: routing bug?
      ... In -current protocol cloning is gone and pointers to an rtentry are no ... This causes a route lookup to be done for ... UDP packet is being sent to determine the source address and thus it ... storing the rtentry pointer in the inpcb at all. ...
      (freebsd-current)
    • Multipath with 2x ADSL, non-random path selection?
      ... I'm having trouble with a linux gateway router that makes available ... It sets up a multipath default gateway on the router: ... The linux kernel assigns a random route ... cache, so that future packets take the same route. ...
      (comp.os.linux.networking)
    • Re: Disabling route cache
      ... > iproute2 to load balance users onto the Internet. ... > cache the result is sometimes poor. ... Is there a way to disable route ... Debian Linux Sid ...
      (Linux-Kernel)
    • Re: Cached IP routes
      ... I've removed the "route cache" in ip_forwardmainly because it was ... However this cache was only caching the last used route. ... have a default route the routing table is so small that a normal routing ... just caches the route to the tunnel destination which normally stays ...
      (freebsd-net)