Xin chào ! Nếu đây là lần đầu tiên bạn đến với diễn đàn, xin vui lòng danh ra một phút bấm vào đây để đăng kí và tham gia thảo luận cùng VnPro.
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • PIng có giải quyết được vấn đê??

    C:\systinet\blizzard-eap1\lib>ping 203.162.4.1 -t
    Reply from 203.162.4.1: bytes=32 time=2303ms TTL=246
    Reply from 203.162.4.1: bytes=32 time=2171ms TTL=246
    Reply from 203.162.4.1: bytes=32 time=2185ms TTL=246
    Reply from 203.162.4.1: bytes=32 time=1412ms TTL=246
    Reply from 203.162.4.1: bytes=32 time=1090ms TTL=246
    Reply from 203.162.4.1: bytes=32 time=1717ms TTL=246
    Reply from 203.162.4.1: bytes=32 time=1761ms TTL=246
    Reply from 203.162.4.1: bytes=32 time=2574ms TTL=246
    Request timed out.
    Reply from 203.162.4.1: bytes=32 time=1451ms TTL=246
    Reply from 203.162.4.1: bytes=32 time=1739ms TTL=246
    Reply from 203.162.4.1: bytes=32 time=1876ms TTL=246
    Reply from 203.162.4.1: bytes=32 time=1969ms TTL=246
    C:\systinet\blizzard-eap1\lib>ping 203.162.0.11 -t

    Pinging 203.162.0.11 with 32 bytes of data:

    Reply from 203.162.0.11: bytes=32 time=3176ms TTL=56
    Reply from 203.162.0.11: bytes=32 time=2715ms TTL=56
    Request timed out.
    Reply from 203.162.0.11: bytes=32 time=1289ms TTL=56
    Reply from 203.162.0.11: bytes=32 time=812ms TTL=56
    Reply from 203.162.0.11: bytes=32 time=1365ms TTL=56
    Request timed out.
    Reply from 203.162.0.11: bytes=32 time=1612ms TTL=56
    Reply from 203.162.0.11: bytes=32 time=1368ms TTL=56
    Reply from 203.162.0.11: bytes=32 time=1576ms TTL=56
    Reply from 203.162.0.11: bytes=32 time=816ms TTL=56
    Reply from 203.162.0.11: bytes=32 time=826ms TTL=56
    Reply from 203.162.0.11: bytes=32 time=774ms TTL=56
    Reply from 203.162.0.11: bytes=32 time=701ms TTL=56

    thời gian gần đây, ping ra VDC có một số vấn đề, thời gian reply rất cao, và mạng mình cũng chậm hơn so với bình thường, một số trang Web khac cũng vậy, mình không biết là nguyên nhân gì. Khi coi lại lượng packet input và out put trên đầu router thì không thấy cao lắm, cả những gói bị drop cũng ko, trong bufer cũng không bị tràn. và Mình không nghĩ là do các sẻver bị quá tải? Còn nhiễu thì không thể , vì thỉnh thoảng mới xảy ra trường hợp này. Còn thông thường thi thời gian reply lại là <100. Vậy là nguyên nhân gì?? Có thể trả lời giùm mình không?

  • #2
    RE: PIng có giải quyết được vấn đê??

    I'd suggest you do a "traceroute" to see what hops might cause the high latency

    Comment


    • #3
      xitrumdl có dùng một chương trình nào để giám sát traffic trên cổng serial của router ở thời điểm bị nghẽn không?

      Comment


      • #4
        Yên tâm đi, thời gian gần đây VDC đang nâng cấp cái quái gì đó, mạng tui cũng bị nè.
        http://ldakvn1.forumgogo.com - My new home

        Comment


        • #5
          RE: PIng có giải quyết được vấn đê??

          you don't really specify out what type of connection you have with VDC (lease line, ADSL, or...)
          give more details, pal. then the community would help you better.
          help yourself first by being specific when questioning

          Comment


          • #6
            RE: PIng có giải quyết được vấn đê??

            Rất tiếc là đang dùng...lease line.
            Và khi xảy ra tình trạng như vậy, Mình biết rằng thời gian reply tăng cao là từ phía đầu Router của mình đến phía nhà cung cấp. Nhưng vì nó không...rớt luôn , cho nên khi liên hệ với VDC, mình không giải quyết được gì cả. Và cũng chẳng biết khắc phục như thế nào???

            Comment


            • #7
              Re: RE: PIng có giải quyết được vấn đê??

              Originally posted by xitrumdl
              Rất tiếc là đang dùng...lease line.
              Mình biết rằng thời gian reply tăng cao là từ phía đầu Router của mình đến phía nhà cung cấp.
              How do you that it's from your router ?
              My company is selling 2000$ for a 2M lease line and we provide utilisation graph, round trip time graph so that customer can view them any time they like. Can you ask VDC for these ?

              One more thing you can do: shoot the question to VDC's NOC. they are supposed to identify the problem and troubleshoot if it's theirs.

              Comment


              • #8
                Originally posted by ftpl
                Originally posted by xitrumdl
                Rất tiếc là đang dùng...lease line.
                Mình biết rằng thời gian reply tăng cao là từ phía đầu Router của mình đến phía nhà cung cấp.
                How do you that it's from your router ?
                My company is selling 2000$ for a 2M lease line and we provide utilisation graph, round trip time graph so that customer can view them any time they like. Can you ask VDC for these ?

                One more thing you can do: shoot the question to VDC's NOC. they are supposed to identify the problem and troubleshoot if it's theirs.
                Viết tiếng Anh kể cũng tốt nhưng do điều kiện sân bãi có hạn nên... tốt hơn là gõ tiếng Việt vậy!

                Hiện tượng của xì trum tôi cũng đã gặp rồi! Phải nói là điên đầu!

                Kinh nghiệm "mau sướng" của tôi xì trum thử theo nhé:

                1. Kiểm tra xem trong LAN có bị Virus bắn broadcast không? Theo kinh nghiệm của tôi thì gần như không phát hiện ra! 5%

                2. Kiểm tra phần cứng thiết bị: ROUTER, NTU, Cáp V.35, ... 90%

                Trường hợp của tôi là do đầu nối cable V.35 đực cái không chuẩn, không hợp :) hehe giao lưu chứ chưa giao thoa ^^

                3. Kiểm tra đường truyền! Hì, việc này thì mấy ông VDC bao h cũng khẳng định như cột bị đinh đóng là CHA.SAO.CA!

                Hi vọng mọi việc sẽ lại tốt đẹp,

                GG GL!
                Kỹ Sư Vỉa Hè...

                Comment


                • #9
                  Với trường hợp như vậy bạn có thể dò kiểm tra theo những bước sau :
                  1) telnet vào Router gõ lệnh :
                  Router#sh processes cpu (sau đó Enter)
                  Trên màn hình xuất hiện các thông số sau (mình chỉ trích 1 phần cho bạn xem qua,chứ thật sự có rất nhiều chi tiết xuất ra) :

                  CPU utilization for five seconds: 5%/2%; one minute: 5%; five minutes: 5%
                  PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
                  1 4 6 666 0.00% 0.00% 0.00% 0 Chunk Manager
                  .......
                  ......

                  Nếu bạn thấy CPU utilization for five seconds: 5%/2%; one minute: 5%; five minutes: 5%. tức là chỉ có 1% đến 10% thì có thể là do Cable của LAN hoạc WAN không ổn định,bạn nên thay cable của WAN (nối từ Router đến NTU) nhưng trường hợp như vậy % xác suất xảy ra thấp,theo mình bạn nên liên hệ với Nhà cung cấp đường truyền kiểm tra cho WAN của bạn trước tiên,có thể trong thời gian hết giờ làm việc (không có tải nhiều) bạn hãy kiểm tra đường truyền xem nó như thế nào,bạn show interface của Router xem nếu thấy : reliability 255/255 (giá trị A/255), txload 2/255, rxload 1/255 thì mới tốt, còn reliability ma` giá trị A thấp hơn 255 rất nhiều thì chứng tỏ lỗi do chất lượng đường truyền của Nhà cung cấp dich vụ rồi. Nhưng nếu bạn thấy giá trị CPU khoảng từ 50% đến 70,80% thì chứng tỏ CPU của Router đã quá tải. Nguyên nhân có thế là do Virus bị lây nhiễm từ 1 hay nhiều máy trạm nào đó trong LAN rồi phát tán muốn làm tê liệt Router (bị tấn công theo dạng QoS),lúc đó bạn nên dùng chương WanSpy 1.5 để biết xem máy trạm nào trong LAN đang gửi nhận packets nhiều nhất (chiếm dụng đường truyền nhiều nhất), lúc này bạn sẽ đến máy trạm đó để cô lập (quét Virus). Nguyên nhân thứ hai có thể là do hệ thống của bạn quá tải nên Router không đáp ứng nỗi, lúc này bạn phải nâng cấp thêm RAM cho Router, nhưng nếu từ đó đến giờ LAN và WAN của bạn không có thay đổi gì về lưu lượng,tải,...thì chắc chắn là do Virus tấn công QoS rồi
                  Cũng có nhiều giải pháp khác như thay WAN Card (WIC) gắn trên Router,hoạc thay cả con Router đang sử dụng, nhưng trước tiên bạn hãy kiểm tra những bước mà mình đã nói ở trên, chúc bạn may mắn

                  Comment


                  • #10
                    Mình bổ sung ở câu đầu mình đã nói là : Nếu bạn thấy " CPU utilization for five seconds: 5%/2%; one minute: 5%; five minutes: 5% " thì Router bình thường, trong điều kiện bình thường thì CPU của Router thay đổi từ 1% đến 5 hoặc 10% thôi

                    Comment


                    • #11
                      Các nguyên nhân và biện pháp khắc phục tình trạng Mạng chậm
                      1. Phần Cứng
                      + Cable: Cable bấm không đúng chuẩn, hoặc khoảng cách quá xa, hoặc …lâu ngày, có thể dẫn đến tình trạng suy hao.-- Thay cable
                      + Sh int sẽ có hiển thị độ tin cậy của đường truyền
                      reliability 255/255. Tức là “ổn rồi” - nhưng cái này nó xạo lắm, ít khi đúng, đôi khi không tin cậy mà nó vẫn báo là 255/255.
                      + Đổi interface, có thể cái interface của mình nó bị khùng …cũng nên. Thử chuyển interface xem sao. Hoặc có thể loopback Interface đó lại, ping thử..
                      + Nếu cable quang thì sao nhỉ ??? thử lâu cái đầu cable bằng đầu lọc thuốc lá xem sao? Cũng có hiệu nghiệm lắm, tại đôi khi nó cũng bị dính bụi.
                      + Àh mà cũng có thể do cai ODF lắm chứ. Thay quách cái khác xem sao. ( Các trường hợp có thể có mà…hi..hi..)
                      + Và một cái nữa là….Đừng nghĩ là khùng nha… Thay luôn thiết bị đi, lấy một con Router hay Switch khác vào thử xem,…
                      2. Phần lưu lượng và virus
                      + sh int, Input queue: 0/75/105/0 (size/max/drops/flushes); Total output drops: 0 xem kích thước của queue, tổng số packets bị drop.
                      5 minute input rate 2005000 bits/sec, 239 packets/sec
                      5 minute output rate 357000 bits/sec, 203 packets/sec
                      Nếu mình chỉ thuê đường truyền có 02M mà “5 minute input rate” là ~02M, thì phải coi lại, tại sao lại cao như vậy. - Giải pháp. Có thể debug hoặc sh ip cache flow trên interface. Có thể một cái PC nào đó đang phun virus lên chăng???( Nếu xịn hơn thì nên có thiết bị đo lưu lượng mạng).
                      Ngoài ra còn phải coi về broadcast, drop, error…
                      + Sh proc cpu: có thể cpu đang xử ly’ gì đó cũng nên. Theo khuyến cáo của Cisco, nếu proc của cpu mà vượt quá 30% thì nên … xem lại.
                      + Nếu có làm Qos, thì bỏ đi nhe… Nó cũng nguy hiểm lắm đấy.. “cực kỳ nguy hiểm”, nếu không có kinh nghiệm thì đừng động vào, kẻo ..gậy ông đập lưng ông..
                      + Rảnh rổi thì coi lại access-list đi. Chắc có cái làm hổng đúng rồi.. Nhưng mà cái này cũng không quan trọng lắm. Chỉ là…dọn dẹp lại cho sạch sẽ thôi.
                      3. Phần botay.com
                      + Có thể do nhà cung cấp … cái này là tình trạng chung, khó nói lắm…họ bảo là không phải lỗi của họ, mà mình cũng hổng phải…Chắc là ‎ ý trời muốn thế ….
                       Giải pháp: Ngồi đợi, một ngày đẹp trời nào đó mạng sẽ nhanh trở lại. Nếu không, nộp đơn xin nghỉ… Nếu không, cũng bị đuổi hà…

                      -------------------------------------------------------

                      Comment


                      • #12
                        hehe, đó mới đúng là kiến thức của CIT, CIT là thực tế, nhất là Phần botay.com :D
                        RK
                        CCxx 2004
                        Goal: MCXX2008
                        :106:

                        Comment


                        • #13
                          theo mình nghĩ nếu ban dùng modem thường thì hay xảy ra các trường hợp sau:
                          -firmware modem không tốt ,dùng thời gian dài thì tràn bộ nhớ.
                          -độ suy hao của port tín hiệu xuất hiện lớn.
                          - 1 chương trình nào đó trên pc của bạn làm cho CPU tăng.

                          Comment

                          Working...
                          X