Új hozzászólás Aktív témák

• #7392 oleeg tag sunyijanika #7391

  Új Válasz 2014-10-20 19:11:26 #7392

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  oleeg

  tag

  válasz sunyijanika #7391 üzenetére

  Szia!

  Nekem az gyanús, hogy ügyfél forgalom nélkül nincs csomagvesztés.

  Ez tipikusan akkor fordulhat elő ha mondjuk van egy Ethernet vonalad amit átadnak mondjuk FastEth vagy GigEth interfészen, de vonali sávszélesség igazából csak az interfész sebességének töredéke és a szolgáltatói vonal nem tolerálja burst -öt. Nálad szerintem mindenképpen probléma lehet, hogy az egyik interfész FastEth a másik pedig GigEth. Ilyenkor az eszköz képes elárasztani (forgalom burst-ös jellege miatt) úgy a vonalat, hogy csomagvesztést tapasztalsz. De ha nincs forgalom a vonalon akkor akár 100e vagy 1m ping is hiba nélkül visszajön. Az interfész számlálók (drop) pedig tiszták. Ilyenkor egy egyszerű shape segíthet melyet mindkét WAN interfészre outbound irányba ráírsz, feltéve, hogy a platform támogatja és még amúgy sincs semmilyen QoS a vonalon.
  Utána érdemes ellenőrizni a policy-map -ot a sh policy-map int <interfész neve> paranccsal működés közben a Queueing rész nézni ahol a (queue depth/total drops/no-buffer drops) 0/0/0 mutatja, hogy ha a shape aktív. Ha a látszik, hogy a default (64 packet) queue limit nem elegendő és emiatt továbbra is dobál akkor növeld a queue limit értékét. Rossz esetben nem lesz már csomagvesztésed, de a válaszidő akár több másodperc is lehet

  o

Új hozzászólás Aktív témák