ARP table?

van 2 PC-m (UBUNTU Linux) kozottuk pedig par cisco router. az egyik PC-rol nagy halozati
forgalmat generalok a masikra. a problema hogy egy bizonyos hatranal kb. 9000 packet/sec (kb. 7 Mbit/s)
a cel gep halozati kartyaja ujraindul. vagyis nem vagyok benne biztos. inkabb leirom amit tapasztalok:
szoval a forgalom leall 10-15 sec-re aztan ujraindul mind a cel es a forras gepnel. megneztem
ethereal-el hogy ilyenkor mi tortenik pontosan. a forras gep elviszti a cel gep MAC address-et es
egy ARP request-et kuld aztan amikor megkapja a valaszt a forgalom ujra indul. ez kb. 10-15 sec es
ismetlodik kb. 50 sec-enkent.
kerdes:
mitol lehet?
valami beepitett vedekezo mechanizmus? ha elkezdem flood-olni ujraindul?
lehet ha statikusan beallitom a MAC address-t megszunik a problema csak nem tudom hol kell es hogyan...
barmilyen otlet jol jonne...

Hozzászólások

arp -m -el lehet manualisan is tolteni az ARP tablat. A kezzel felvett ertekeket asszem nem is dobja ki onnan.
Ettol fuggetlenul valoban nyugtalanito es fura problema.
Kerdes: miert tart 10-15 sec-ig kiszolgalni egy ARP requestet? Valami ott nem kerek mar alapbol sem.

cisco-k mit mondanak közben?

ARP táblának direkt az a lényege, h. akikkel mostanában beszélt a gép, azokat "ismerje", tehát
nagyon nem normális h. ilyen forgalom mellett fogja magát, és pont azt a címet felejti el.
Biztos kóser az a hálókártya?

a forras geptol csinaltam egy static route-ot a cel gep fele
ezzel annyit sikerul elernem hogy a forgalom mar csak a cel gepnel szakad meg
nincs ARP request sem, egyszruen nem fogad csomagokat 15 sec-ig
most frissitek 6.10es UBUNTU-ra mert eddig 6.06-ot hasznaltam
de nem remelek tul sok jot
amugy a routerek-en megy a forgalom, ott minden ok
jah, meg valami probaltam tobb forgalmat kuldeni ra 16 Mbit/s csak joval kevesebb csomag szammal
masodpercenken es mukodott. gondolom a sok egy idoben erkezo csomagtol hasal meg, de miert?

Nos,
9000 packet/sec (kb. 7 Mbit/s) ez így már nem jól hangzik. Nálunk 9500 pps-hez tartozik 64 Mbit/s forgalom. Tehát baromi sok kis csomagot küldesz, nem életszerű szituáció...
A kb. 10-15s-es kihagyás nagyon spanning-tree-nek tünik. Hogy ennek mi köze van a problémához nem tudom... cisco-ban sho log? Ill. vannak a cisco-kban beépített védelmi mechanizmusok, de ez szintén sho log-an látszik.

Mik

Azt mondjuk érdemes tudni, hogy ha két keszülék között egy vagy több router van (!=switch), akkor természetesen egymás MAC-address-ét nem ismerik/használják, csak ki-ki a hozzá legközelebbi router (egyik interface-ének) MAC-address-ét.

igen, ugy nez ki megis csak a routereknel lesz valami gond
amugy VoIP forgalamt szeretnek szimulalni azert ilyen sok kicsi csomag van
csak nem igazan tudom mit kedjek ezekkel a router uzenetekkel:

Mar 19 15:14:59 192.168.1.41 121: *Mar 4 00:25:16: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.50 on Ethernet1/2 from FULL to DOWN, Neighbor Down: Interface down or detached
Mar 19 15:14:59 192.168.1.41 122: *Mar 4 00:25:16: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.78 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
Mar 19 15:14:59 192.168.1.41 123: *Mar 4 00:25:16: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.18 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
Mar 19 15:22:25 192.168.1.42 43: *Mar 1 00:51:12.979: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.41 on Ethernet1/0 from FULL to DOWN, Neighbor Down: Dead timer expired
Mar 19 15:22:31 192.168.1.6 34: *Mar 1 00:04:39.751: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.18 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
Mar 19 15:22:31 192.168.1.6 35: *Mar 1 00:04:39.755: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.50 on Ethernet1/0 from FULL to DOWN, Neighbor Down: Dead timer expired
Mar 19 15:22:31 192.168.1.6 36: *Mar 1 00:04:39.755: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.78 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
Mar 19 15:22:31 192.168.1.6 37: *Mar 1 00:04:39.867: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.78 on FastEthernet0/1 from LOADING to FULL, Loading Done
Mar 19 15:22:31 192.168.1.6 38: *Mar 1 00:04:39.867: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.50 on Ethernet1/0 from LOADING to FULL, Loading Done
Mar 19 15:23:37 192.168.1.6 40: *Mar 1 00:05:45.579: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.50 on Ethernet1/0 from LOADING to FULL, Loading Done
Mar 19 15:23:37 192.168.1.6 41: *Mar 1 00:05:45.587: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.78 on FastEthernet0/1 from LOADING to FULL, Loading Done
Mar 19 15:23:37 192.168.1.6 42: *Mar 1 00:05:45.607: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.18 on FastEthernet0/0 from LOADING to FULL, Loading Done

Jólenne tudni a routerek típusát, IOS verziókat
link
Router# show proc cpu | include CPU utilization

CPU utilization for five seconds: 99%/90%; one minute: 48%; five minutes: 25%

Router#

2w0d: %OSPF-5-ADJCHG: Process 100, Nbr 6.6.6.122 on Vlan46 from FULL to DOWN, Neighbor
Down: Dead timer expired

Első nekifutásra nekem úgytűnik, hogy simán túlterhelted valamelyiket...

Mik

routerek adatai:
Cisco 2621XM routers using IOS (tm) C2600 Software (C2600-IS-M), Version 12.2(15)T11, RELEASE SOFTWARE (fc2)

igen, sajnos nekem is ugy tunik. a diplomamunkam irom. a feladatom hogy csinaljak egy Diffserv archtekturat es ezt teszteljem. tehat van egy bottleneck link. 2 iranybol kapja a router a forgalamt es szolgaltatas szerint kene szurje es queue-ba pakolja. szolgaltatskent video-t stream-eltem VLC-vel es VoIP-ot D-ITG-vel. (sima UDP vagy TCP termesztesen nem jo mert nem eletszeru) egesz jol mukodik amig ra nem kuldom a 9000 packets/sec-es forgalmat, ekkor meghasal. sajna ez meg csak 7 Mbit/s-es forgalom plusz a video kb. 2 Mbit/s ami keves a 10 Mbit/s-es bottleneck-hez.

szoval akkor ennyi ezeknek a routereknek a kapacitas?
meg valami, nem tudnad nekem leirni hogy hogy tudom a routerlogot terminalrol olvasni? mert ugy sikerult csak megoldjam hogy beallitottam az egyik gepen egy log server-t es oda kuldi az info-t, de terminalra nem tudtam elocsalni...

A Cisco-ban az a jó (vagyis én azt szeretem) hogy kuva vagyis bocsánat, nagyon jó a doksija:
link
Aztat mondja, hogy a 21XM-nek 30K pps az áteresztő képessége (switch módban!). Nem teljesen értem amit írtál (se diffserv-el, se bottleneck-el nem volt még dolgom) de jól értem, hogy QoS-ezni szeretnél ezekkel a routerekel? Most nem nézem már meg, de úgysejtem, hogy ezek ezt szoftveresen oldanák meg, akkor bizony 9000 pps-nél elfogyhat a cpu ha max. 30 pps az áteresztő képessége.
A logot betelnetelve (telnet v. ssh megy rajtuk?) enable módban show logging -al lehet megnézni.

Mik

igen, vegulis QoS. DiffServ elegge hasonlit az mpls-hez, de megsem az es mukodik mind2
egyszerre is.

nekem show logging-ra ennyit mutat:
(gondolom valamit meg allitgatnom kene rajta)
sydney#sh logging
Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0 flushes, 0 overruns, xml disabled)
Console logging: level debugging, 59 messages logged, xml disabled
Monitor logging: level debugging, 0 messages logged, xml disabled
Buffer logging: disabled, xml disabled
Logging Exception size (4096 bytes)
Count and timestamp logging messages: enabled
Trap logging: level debugging, 64 message lines logged
Logging to 192.168.1.1, 64 message lines logged, xml disabled

Hmm, eddig midegyik Cisco loggolt amivel találkoztam, nálam:
sho log
Syslog logging: enabled (0 messages dropped, 6 messages rate-limited, 0 flushes, 0 overruns)
Console logging: level debugging, 60262 messages logged
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 60268 messages logged
Exception Logging: size (4096 bytes)
Count and timestamp logging messages: disabled
Trap logging: level informational, 56673 message lines logged
Logging to ipcim, 56673 message lines logged

A buffer loggingot kellene beállítanod:
logging buffered debugging

Ha nem lesz elég erős a vas, mi fog történni?

Mik

Lekapcsol halokartya zold lampaja ?

Szerintem hibas a halokartya.
Ket kopra, ugyan ulyan rendszerbol az egyik ezt csinalta nekem, egyertelmu hw. bug.
Ha alaplapi es nincs gar az !=jo. Vegyel bele masikat azt meg ne hasznald.

"Szerintem hibas a halokartya."

ennek orulnek a legjobban, de sajnos nem. probaltam masik halokartyat es masik teljes gepet is a problema ugyan az volt. a router nem birja a terhelest. Diffserv-el kb. 6-7K pps-ig megbizhato. Diffserv nelkul nyomhattam tovabb is. gondolom 30K pps-ig, de nem probalgattam

"Ha nem lesz elég erős a vas, mi fog történni?"

D-ITG-be tudtam allitani a VoIP codec-jet. igy nagyobb csomagokat kuld es kisebb pps-el el tudom elerni ugyanazt a savszelesseg kihasznalast. az uj codec-el 9 Mbits/s biztosagos VoIP forgalmat tudok generalni. szereztem 3 uj video-t is mind1ik 2.4 Mbits/s. ha egyszerre nyomom mindet akkor az mar tobb mint 16 Mbits/s. remelem eleg lesz.

es mukodik a routereken a log is most mar. koszi a tippet :)