Здравейте,

Имам 4 компютъра и един NVR в мрежа,два потребителски компюъра един сървър и един каса+две везни(ако това има някъкво значение).
Свързани са в една локална мрежа с един суич от суича излиза кабел към рутера(на интернет доставчика), който раздава(DHCP) адреси на компютрите и от който идва интернета.
проблема е в това че компютъра на касата периодично си губи локалната мрежа и след рестарт се оправя за неопределено време.
Сменях суича,всички конектори,сложих и втора лан карта на касата.Махнал съм отметката от настройките на локалкана карта"Разреши на компютъра да изключва това у-во с цел пестене на енергия".кабелите са тествани и няма проблеми по трасето.

Нямам обяснение нито решение на проблема ако има някой с идея от какво може да се получава това ще се радвам да я чуя.

Поздрави.

 

Позвънете на доставчика на интернет да пратят човек да провери рутера.

преди 14 минути, stfpetrov написа:

Здравейте,

Имам 4 компютъра и един NVR в мрежа,два потребителски компюъра един сървър и един каса+две везни(ако това има някъкво значение).
Свързани са в една локална мрежа с един суич от суича излиза кабел към рутера(на интернет доставчика), който раздава(DHCP) адреси на компютрите и от който идва интернета.
проблема е в това че компютъра на касата периодично си губи локалната мрежа и след рестарт се оправя за неопределено време.
Сменях суича,всички конектори,сложих и втора лан карта на касата.Махнал съм отметката от настройките на локалкана карта"Разреши на компютъра да изключва това у-во с цел пестене на енергия".кабелите са тествани и няма проблеми по трасето.

Нямам обяснение нито решение на проблема ако има някой с идея от какво може да се получава това ще се радвам да я чуя.

Поздрави.

 

Пробва ли да му зададеш статичен адрес на место да взима от рутера?

преди 1 минута, JohnTRIVOLTA написа:

Пробва ли да му зададеш статичен адрес на место да взима от рутера?

Да, пробвах и няма резултат.

преди 4 минути, Bubbles написа:

Позвънете на доставчика на интернет да пратят човек да провери рутера.

Ако проблема е в рутера не би ли следвало да има проблем при всички компютри не само на касата?

преди 18 минути, stfpetrov написа:

Да, пробвах и няма резултат.

Вероятно компютъра е старичък? Нещо по-конкретно , като хардуер, защото може да е проблемен вече?!

преди 36 минути, stfpetrov написа:

Ако проблема е в рутера не би ли следвало да има проблем при всички компютри не само на касата?

Така е, но все пак може да има и изключения.

Между другото, след като всичко е свързано в суич, не виждам рутера какво общо има освен DHCP .

преди 3 часа, stfpetrov написа:

един сървър и един каса

Това ме навежда на мисълта, че се ползва софтуер тип СУПТО, като основната база е на сървъра

преди 3 часа, stfpetrov написа:

компютъра на касата периодично си губи локалната мрежа и след рестарт се оправя за неопределено време

Това събитие, съпроводено ли е с някаква индикация/съобшение? Какво и кой реагира на проблема - самата ОС или сървърната част на използваната система? склад про на микроинвест имаше подобни ядове когато базата е mdb и е на отделен сървър в LAN - при слаб хардуер на сървъра. При преминаване към SQL база нещата се нормализираха. Каква е опорната LAN - 100 или гигабитова?

Едни точно определени мрежови чипсети имаха подобни проблеми. Оправят се с подходящия драйвър. Пробвай набързо с външна LAN карта, ако имаш такава.

преди 3 минути, jtaggerx написа:

Едни точно определени мрежови чипсети имаха подобни проблеми. Оправят се с подходящия драйвър. Пробвай набързо с външна LAN карта, ако имаш такава.

`Kога ще се научите да четрете, преди да пишете глупости? Кои точно са тия чипсети? Това прочетели го:

преди 4 часа, stfpetrov написа:

сложих и втора лан карта на касата.

 

преди 4 часа, stfpetrov написа:

сложих и втора лан карта на касата

Без конкретни модели, може да слагаш еднакви/близки карти.

Какво точно се случва когато си със статично IP?

преди 9 минути, teo-glavata написа:

 Кои точно са тия чипсети?

Определени Intel гигабитови мрежови чипсети.  Не, не прочетох за втората карта. В такъв случай да се използват ръчно зададени IP.
Да не се окаже, че мрежата се губи точно когато лийза на DHCP адреса изтече. А и не е уточнено какво значи "мрежата се губи".

В такива ситуации, вместо да действам с проба-грешка, обикновено започвам да чета event-ите в Event Viewer. Често отговорът се крие точно там, in plain text.

 

преди 5 минути, jtaggerx написа:

точно когато лийза на DHCP адреса изтече.

Ако съответния NIC (MAC) e активен, лиййза няма да повлияе

преди 7 минути, jtaggerx написа:

В такъв случай да се използват ръчно зададени IP

И това е пробвал човека

преди 7 минути, jtaggerx написа:

А и не е уточнено какво значи "мрежата се губи".

Ей тука е ключа за палатката! Залагам на проблем м/у клиента и сървъра на софтуерно ниво

преди 20 минути, teo-glavata написа:

Ако съответния NIC (MAC) e активен, лиййза няма да повлияе

Когато лийзът изтече, започва повторно процеса на получаване на адрес по DHCP. Дали рутерът ще даде същия адрес - зависи от самия рутер и от моментната ситуация. Принципно е възможна ситуация при която лийзът изтича, друг компютър заема този адрес, а даденият компютър взима друг адрес.
Човекът е написал, че "за компютъра е пробвано със статичен адрес". Да не се окаже, че сървърът и той бичи по DHCP.

преди 6 минути, jtaggerx написа:

Да не се окаже, че сървърът и той бичи по DHCP.

Е, то ако е така.....да ходи да съди направо инсталаторите   Това е безумие - няма как някой да го направи.... всъщност не знам -  има и такъв сценарий. И в такъв случай, "клиентските" компове си омат сурат тефтер, служителите са доволни.....мдааа. 

току-що, teo-glavata написа:

Е, то ако е така.....да ходи да съди направо инсталаторите   Това е безумие - няма как някой да го направи.... всъщност не знам -  има и такъв сценарий. И в такъв случай, "клиентските" компове си омат сурат тефтер, служителите са доволни.....мдааа. 

Няма проблем да е по DHCP, просто може да бъде резервиран по MAC адрес и с много дълъг период на валидност, няма драма в това.

преди 2 минути, plamen_petrov_80 написа:

Няма проблем да е по DHCP, просто може да бъде резервиран по MAC адрес и с много дълъг период на валидност, няма драма в това.

Освен ако не ти мигне тока и не ти се ресетне ТПЛинк-а. Тогава вече става лошо. Затова тача микротиците. Та най-умно е да сложиш статични адреси извън DHCP pool-а, като не пипаш мрежата зад NAT-а и работиш с default-ската такава. Т.е ако по подразбиране рутерът ти тръгва след ресет с 192.168.1.0 мрежа и с DHCP от 100 до 200, то слагаш важните неща на адреси под 100 или над 200 и не сменяш мрежата 192.168.1.0 с друга в настройките на рутера, защото след ресет всичко спира да работи.

преди 10 минути, jtaggerx написа:

Освен ако не ти мигне тока и не ти се ресетне ТПЛинк-а.

То ако така се губеха настройките ....

преди 1 час, jtaggerx написа:

Когато лийзът изтече, започва повторно процеса на получаване на адрес по DHCP. Дали рутерът ще даде същия адрес - зависи от самия рутер и от моментната ситуация. Принципно е възможна ситуация при която лийзът изтича, друг компютър заема този адрес, а даденият компютър взима друг адрес.

Затова, протоколът е направен така, че когато lease time е едва наполовина изтекъл, още тогава устройството, което е още онлайн, изпраща заявка към DHCP сървъра за подновяване на lease-а. А пък ако устройството е било изключено и повторно включено, тогава започва отначало процесът с DHCP discover, DHCP offer и т.н.

Единствената възможна ситуация друг да ти вземе адреса под носа, е когато ти си бил офлайн, лизингът ти е изтекъл, DHCP сървърът е върнал адреса ти обратно в pool-а със свободни IP-та и чак при тези обстоятелства има право да го зачисли на някой друг device.

По повод DHCP резервациите - това е твърд bind между MAC и IP адреси, лизингът там няма отношение. Дори да изтече lease time, адресът ти никога не отива в pool-а със свободните, така че няма кой да ти го вземе. Тук уловката е, че ако решиш да смениш IP адреса в резервацията на някое устройство, без да пипаш нищо по самото устройство, трябва да изчакаш да изцъка половината му lease time, за да си вземе автоматично новия адрес по резервация.

преди 1 час, Rammkopf написа:

Затова, протоколът е направен така, че когато lease time е едва наполовина изтекъл, още тогава устройството, което е още онлайн, изпраща заявка към DHCP сървъра за подновяване на lease-а. А пък ако устройството е било изключено и повторно включено, тогава започва отначало процесът с DHCP discover, DHCP offer и т.н.

Протоколът е направен така, само че въобще не е задължително на DHCPREQUEST да бъде своевременно отговорено. При настроени лийзове на относително малък интервал от време(ако имаме многобройни устройства и не искаме IP-та да висят неизползвани с лийзове от 24h+ - ако дръпнеш кабела на компютъра, хич няма да може да изпрати DHCP release и тоя IP ще виси докато лийза не изтече) или ограничен физически капацитет и претоварване на мрежата, дори бъг във фърмуъра на рутер - възможно е на DHCPREQUEST да не се отговори своевременно или преди да изтече лийза.
Достатъчно е ако маршрутизаторът не е защитен с UPS и токът мигне в момента, когато компютър изпраща DHCPREQUEST да се окаже, че дори самият DCHP сървър е офлайн, следователно не може да отрази тоя  DHCPREQUEST. Да, после ще опита пак - така е безспорно. Но подходяща опитна постановка с ненадеждна мрежа може да се създаде. 
Друг възможен сценарий е проблем с DHCP услугата на даден клиент. Софтуер на трети страни като антивирусни програми също може да доведе до проблеми с DHCP-то, като възпрепятства нормалния процес на получаване/присвояване на IP чрез използването на DHCP. 
По принцип DHCP е направен така, че веднъж раздаден определен IP, да не се повтаря целия процес на присвояване на IP адрес, а да продължава да се използва същия адрес като само лийза се подновява, но всъщност има много фактори, които не е толкова лесно да бъдат предвидени.
Поради изброените по-горе различни варианти, едва ли някога някой ще види сървър, който получава адрес по DHCP в production environment. 
DHCP е удобен за "преносими машини - клиенти", нулева конфигурация и т.н. Бучкаш кабела/натискаш connect to WLAN network и се надяваш всичко да е наред. По-често, отколкото не - всичко работи.

Що иде реч до DHCP резервациите или MAC/IP binding - не помня да съм споменавал нещо за лийзове там. За сметка на това при проблем с мрежово устройство, а съм настройвал повторно повече от един TPLink, който след смущения в захранаващата мрежа се връща към фабрични настройки - всичките настройки с MAC/IP binding отиват по дяволите. 
По тази причина, ако някъде има такива устройства нисък клас - просто използвам default-ската мрежа. И да се нулира, и да изгори - като се смени със същия модел устройство или подобно - всичко тръгва веднага. Новите TPLink по подразбиране са с мрежа 192.168.0.0. Ако не се променя, дори и да изгори и да сложиш друг TPLink - проблеми няма. Ако всичко ти е статично, то въобще можеш да минеш без рутер - и през суич ще си пеят локално. Но ако имаш лаптоп, на който си гледаш камерите и взима по DHCP, пък NVR-ът и IP камерите са ти със статични адреси и смениш рутера, ако мрежата на изгорелия е била различна от default-ската, с новия рутер лаптопът ще си вземе там IP, но няма да е в мрежата или с маската необходима да може да "вижда" NVR-а или камерите.
Друг съществен проблем с DHCP е т.нар DHCP exhaustion - т.е дали са се закачили много клиенти или злонамерено лице иска нови и нови IP като се представя за различен хост всеки път, резултатът е един и същ. Свършват ти IP, вързани са ти с лийзове, не се освобождават докато не изтекат - можеш да останеш без IP за раздаване и нови клиенти да се закачат - ядец. Това е като грозната DEAUTH атака на WLAN мрежите, която може да бъде голяма напаст и е достатъчно някой много бързо да цикли и да разкача клиентите - и в двата случая услуга за легитимните потребители няма. 
------
Що иде реч до автора на темата, очакваме информация кога се проявява този проблем, има ли конкретен интервал от време или часове, какво е естеството на проблема - пълна загуба на мрежова свързаност или проблем с конректна програма, може да се пусне команда да пуска ping до сървъра или до сървър в интернет и да се логва в текстови файл. 

Влизаш в едни "ако" сценарии, където вече тезите граничат с "ами ако метачката в този момент се спъне в кабела?". Или "ако злият антивирус с файъруол ми блокира UDP 67 и 68, да не би случайно да си взема адрес?". Отплесваш се от темата на автора. То, по твойта логика, и DHCPACK не е задължително да се получи, примерно, ако докато дейтаграмите летят по телта, токът мигне и суичът забие. Само теория с паразитен authoritative DHCP не си разгледал! Човекът има 10-ина устройства в магазина си, ти къде го хвърли чак в pool exhaust ... Че и замеси deauth в схемата. Двете (deauth и pool exhaustion) са съвсем различни събития и се случват по коренно различни причини (дори когато deauth е легитимен фрейм от AP-то, искам да кажа, а не jtaggerx с kali-то в храстите  ). Единственото общо между тях е, че са досадни, защото клиентите висят без услуга, да.

Резервациите ги засегна Пламен, отговорът ми там беше към него.

TP-LINK открай време раздават 192.168.0.0/24, не са само новите. Освен ако "новите" не са от 2005-та насам.

преди 43 минути, jtaggerx написа:

Поради изброените по-горе различни варианти, едва ли някога някой ще види сървър, който получава адрес по DHCP в production environment. 

DHCP е удобен за "преносими машини - клиенти", нулева конфигурация и т.н. Бучкаш кабела/натискаш connect to WLAN network и се надяваш всичко да е наред. По-често, отколкото не - всичко работи.

Е, ти откри топлата вода! Dynamic Host Configuration Protocol се използва за устройства, които идват и си отиват. Сървърите, които спят в мазата ти с години, за какво да ползват динамичен адрес? Трябва администраторът да е пълен идиот, за да остави домейн контролер или файлов сървър, или дори апликейшън сървър, на произвола на DHCP-то, ако ще и да е с резервирани адреси.

преди 33 минути, Rammkopf написа:

TP-LINK открай време раздават 192.168.0.0/24, не са само новите. Освен ако "новите" не са от 2005-та насам.

  Старите раздаваха 192.168.1.0/24 WR340G, например. По-скоро към 2008 и нататък започнаха с 192.168.0.0/24. Както и да е.

преди 33 минути, Rammkopf написа:

Влизаш в едни "ако" сценарии, където вече тезите граничат с "ами ако метачката в този момент се спъне в кабела?". Или "ако злият антивирус с файъруол ми блокира UDP 67 и 68, да не би случайно да си взема адрес?"

Моята логика е, че ако има проблем(не говоря за конкретния, а по принцип), нищо не трябва да се приема като сигурно.

преди 33 минути, Rammkopf написа:

Единственото общо между тях е, че са досадни, защото клиентите висят без услуга, да.

Другото общо е, че докато има някакви механизми да се ограничат подобни действия, на практика в повечето мрежи те не са реализирани. 

преди 33 минути, Rammkopf написа:

Е, ти откри топлата вода! Dynamic Host Configuration Protocol се използва за устройства, които идват и си отиват. 

Не откривам топлата вода. Мхм. Казвам, че не е едно от най-надеждните неща, макар в преобладаващата част от случаите да работи безпроблемно.

преди 33 минути, Rammkopf написа:

Трябва администраторът да е пълен идиот, за да остави домейн контролер или файлов сървър, или дори апликейшън сървър, на произвола на DHCP-то, ако ще и да е с резервирани адреси.

Нагледал съм се на безброй простотии.

преди 33 минути, Rammkopf написа:

дори когато deauth е легитимен фрейм от AP-то, искам да кажа, а не jtaggerx с kali-то в храстите 

Моля? Смяташ ли, че съм от тия аматьори?  

преди 23 минути, jtaggerx написа:

  Старите раздаваха 192.168.1.0/24 WR340G, например. По-скоро към 2008 и нататък започнаха с 192.168.0.0/24. Както и да е.

По това време работех предимно с Linksys. Не съм запознат с WR340G, извинявай, ще те взема на доверие.

преди 23 минути, jtaggerx написа:

 Моята логика е, че ако има проблем(не говоря за конкретния, а по принцип), нищо не трябва да се приема като сигурно.

С това съм абсолютно съгласен, просто допълвам, че предлагането на абсурдни теории изобщо не помага на решението. Напротив, даже може да наклони "журито" непредумишлено в погрешна посока. Суров анализ му е майката.

преди 23 минути, jtaggerx написа:

Другото общо е, че докато има някакви механизми да се ограничат подобни действия, на практика в повечето мрежи те не са реализирани. 

Не разбрах за какви действия говориш и не мога да коментирам.

преди 23 минути, jtaggerx написа:

Не откривам топлата вода. Мхм. Казвам, че не е едно от най-надеждните неща, макар в преобладаващата част от случаите да работи безпроблемно.

Само като тръгнеш от факта, че можеш да имаш повече от един DHCP сървър в мрежата си, това само по себе си е достатъчно да разклати надеждността ѝ, прав си. Затова се разчита на компетенция от страна на инсталатора, нали? Това не прави системата ненадеждна като концепция и дизайн. Администраторът я прави такава.

преди 23 минути, jtaggerx написа:

Нагледал съм се на безброй простотии.

Моля? Смяташ ли, че съм от тия аматьори?  

Предполагам, че много от нас са се нагледали на простотии. Част от длъжностната ни характеристика е.

Аре, аре, дай да не се делим на аматьори и експерти. Както вика един колега: "Всеки батко си има батко".

преди 13 часа, teo-glavata написа:

Това ме навежда на мисълта, че се ползва софтуер тип СУПТО, като основната база е на сървъра

Това събитие, съпроводено ли е с някаква индикация/съобшение? Какво и кой реагира на проблема - самата ОС или сървърната част на използваната система? склад про на микроинвест имаше подобни ядове когато базата е mdb и е на отделен сървър в LAN - при слаб хардуер на сървъра. При преминаване към SQL база нещата се нормализираха. Каква е опорната LAN - 100 или гигабитова?

Да ползва се супто софтуер Орак рисконд са на потребителските компютри касата е ПОС.Работи с SQL.

През неопределено време мрежата пада и Рисконт ПОС пищи че няма връзка със сървъра както и с нито един компютър от мрежата,няма и ИП.

След като рестартирам или извадя и вкарам пак кабела в картата или рестартирам суича си взема пак ип-то и си работи.Другите компютри и у-ва нямат проблем в този момент.Лана е 10/100Mbps.