Re: route takes long time to give the table

From: Sergio Basurto Juarez (sbasurtoj_at_yahoo.com)
Date: 11/17/04

  • Next message: Sergio Basurto Juarez: "Re: problem with pasive MODE and NAT"
    Date: Wed, 17 Nov 2004 13:00:16 -0800 (PST)
    To: debian-user@lists.debian.org
    
    

    --- "H. S." <greatexcalibur@yahoo.com> wrote:

    > Sergio Basurto Juarez wrote:
    > > --- "H. S." <greatexcalibur@yahoo.com> wrote:
    > >
    > >
    > >>Apparently, _Riccardo Tortorici_, on 16/11/04
    > >>22:39,typed:
    > >>
    > >>>Check your iptables settings...I had this problem
    > >>
    > >>months ago...
    > >>
    > >>What did you find your problem was? How did you
    > >>solve it?
    > >>
    > >>->HS
    > >>
    > >>
    > >>
    > >>>H. S. wrote:
    > >>>
    > >>>
    > >>>>On Debian Testing running 2.6.7,the 'route'
    > >>
    > >>command is taking
    > >>
    > >>>>unusually long time to give the table:
    > >>>>~# time route
    > >>>>Kernel IP routing table
    > >>>>Destination Gateway Genmask Flags
    > >>
    > >>Metric Ref Use Iface
    > >>
    > >>>>x.y.z.z * 255.255.255.255 UH
    > >>
    > >>0 0 0 ppp0
    > >>
    > >>>>192.168.1.0 * 255.255.255.0 U
    > >>
    > >>0 0 0 eth0
    > >>
    > >>>>192.168.0.0 * 255.255.255.0 U
    > >>
    > >>0 0 0 eth1
    > >>
    > >>>>default x.y.z.z 0.0.0.0 UG
    > >>
    > >>0 0 0 ppp0
    > >>
    > >>>>real 0m20.010s
    > >>>>user 0m0.002s
    > >>>>sys 0m0.002s
    > >>>>
    > >>>>
    > >>>>However, 'route -n' command gives the output
    > >>
    > >>almost instantly.
    > >>
    > >>>>Anybody else experiencing this? Any idea why
    > this
    > >>
    > >>would be so?
    > >>
    > >>>>->HS
    > >>>>
    > >>>>
    > >>>
    > >
    > > When you type the command:
    > > #route -n
    > > you are telling to route that does not try to
    > resolv
    > > names. That's why it returns almost immediatly.
    > > Nevertheless if your dns server is setup correctly
    > it
    > > does not have to take long time in fact the
    > difference
    > > is tiny:
    > >
    > > # time route
    > > Kernel IP routing table
    > > Destination Gateway Genmask
    > Flags
    > > Metric Ref Use Iface
    > > 10.0.0.0 * 255.255.255.0 U
    >
    > > 0 0 0 eth1
    > > 192.168.0.0 * 255.255.255.0 U
    >
    > > 0 0 0 eth0
    > > default 10.0.0.1 0.0.0.0 UG
    >
    > > 0 0 0 eth1
    > >
    > > real 0m0.005s
    > > user 0m0.000s
    > > sys 0m0.000s
    > > # time route -n
    > > Kernel IP routing table
    > > Destination Gateway Genmask
    > Flags
    > > Metric Ref Use Iface
    > > 10.0.0.0 0.0.0.0 255.255.255.0 U
    >
    > > 0 0 0 eth1
    > > 192.168.0.0 0.0.0.0 255.255.255.0 U
    >
    > > 0 0 0 eth0
    > > 0.0.0.0 10.0.0.1 0.0.0.0 UG
    >
    > > 0 0 0 eth1
    > >
    > > real 0m0.003s
    > > user 0m0.010s
    > > sys 0m0.000s
    > >
    > >
    > > Regards.
    >
    >
    > Ah. Thanks for the explanation. I am connecting to
    > my ISP through ADSL
    > modem (that x.y.z.z was my IP at that time). So from
    > your explanation
    > the problem could be at their end?
    >
    > ->HS

    Yes, I think so, nevertheless you can test this if you
    setup a bind9 server as a caching only name server,
    and the response from route -n should be faster than
    the one you have right now.

    Extending the explanation:
    Also if you have a private network and route try to
    resolve the ip's from your private network to names,
    then the problem comes becuase your ISP does not map
    your private ip's to names, and that's why it takes
    too much time. Then if you have a private network I
    recommend you set up a caching only server, and
    resolve your ip's to names, you do not need a public
    domain, but you must have a line in your named.conf
    like

    notify no;

    in order to don't get other servers confused with the
    private domain that you will use. Also you can map
    your ip's just to names like 192.168.0.1 correspond to
    alex_arc for example.

    You can get a much better picture of all with the
    DNS-HOWTO and also recommend you to read the RFC's
    that comes in the HOWTO (Just for fun).

    Regards.

    =====

    --
    Sergio Basurto J.
    If I have seen further it is by standing on the 
    shoulders of giants. (Isaac Newton)
    --
    		
    __________________________________ 
    Do you Yahoo!? 
    Meet the all-new My Yahoo! - Try it today! 
    http://my.yahoo.com 
     
    -- 
    To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
    

  • Next message: Sergio Basurto Juarez: "Re: problem with pasive MODE and NAT"

    Relevant Pages

    • Re: Set priority for the DNS server to resolve the useful ip address in the RR
      ... rather than wasting time to resolve entire A record. ... the server to set the priority in the A record. ...
      (microsoft.public.windows.server.dns)
    • RE: Unable to Fax
      ... Microsoft CSS Online Newsgroup Support ... This newsgroup only focuses on SBS technical issues. ... faxing on our 2003 server has been resolved. ... please try the following steps to try to resolve ...
      (microsoft.public.windows.server.sbs)
    • RE: SBS 2003 error during step 5
      ... Let"s perform the following tests to try to resolve the OWA issue: ... Clear the IIS server files follow these steps: ... Microsoft CSS Online Newsgroup Support ... This newsgroup only focuses on SBS technical issues. ...
      (microsoft.public.windows.server.sbs)
    • RE: Route added by RRAS that overrides local LAN route on NIC
      ... I am using SBS as the VPN server. ... The route I am speaking of is the route to local LAN that is put in the ... After the RAS client connects there is another route added so the two ...
      (microsoft.public.windows.server.sbs)
    • RE: Cannot Connect via remote desktop
      ... please ensure the domain name vpn.XXX.co.uk resolve to the ... As you want to connect the SBS via VPN, I suggest you also perform the ... select Disable Routing and Remote ... You have to rerun the CEICW to make sure your SBS 2003 server have right ...
      (microsoft.public.windows.server.sbs)

    Loading