Есть ли связь даты, времени DHCP клиента и DHCP сервера при выдаче в аренду IP адреса. Допустим, на dhcp сервере (catalyst2960) стоит кривая дата - 1993 год, а на клиентах дата 2013 год. Есть ли в этом проблема выдачи адресов? Или искать проблему где-то в другом месте?
> Есть ли связь даты, времени DHCP клиента и DHCP сервера при выдаче
> в аренду IP адреса. Допустим, на dhcp сервере (catalyst2960) стоит
> кривая дата - 1993 год, а на клиентах дата 2013 год.
> Есть ли в этом проблема выдачи адресов? Или искать проблему
> где-то в другом месте?Нет, проблем не должно быть.
>> Есть ли связь даты, времени DHCP клиента и DHCP сервера при выдаче
>> в аренду IP адреса. Допустим, на dhcp сервере (catalyst2960) стоит
>> кривая дата - 1993 год, а на клиентах дата 2013 год.
>> Есть ли в этом проблема выдачи адресов? Или искать проблему
>> где-то в другом месте?
> Нет, проблем не должно быть.Спасибо
> Есть ли связь даты, времени DHCP клиента и DHCP сервера при выдаче
> в аренду IP адреса. Допустим, на dhcp сервере (catalyst2960) стоит
> кривая дата - 1993 год, а на клиентах дата 2013 год.
> Есть ли в этом проблема выдачи адресов? Или искать проблему
> где-то в другом месте?Выдача производится НА КОЛ-ВО секунд, а не на период с 1 декабря 93 по 2 декабря 93.
P.S. Не считаю нормальной практикой разворачивать DHCP сервер на L2 коммутаторах
> P.S. Не считаю нормальной практикой разворачивать DHCP сервер на L2 коммутаторахСогласен, большое количество юникаст/броадкаст на слабенький контрол-плейн, вполне может привести к отказу в работе других контрол-плейн протоколов, типа STP.
>> P.S. Не считаю нормальной практикой разворачивать DHCP сервер на L2 коммутаторах
> Согласен, большое количество юникаст/броадкаст на слабенький контрол-плейн, вполне может
> привести к отказу в работе других контрол-плейн протоколов, типа STP.А можете примеры привести?
>>> P.S. Не считаю нормальной практикой разворачивать DHCP сервер на L2 коммутаторах
>> Согласен, большое количество юникаст/броадкаст на слабенький контрол-плейн, вполне может
>> привести к отказу в работе других контрол-плейн протоколов, типа STP.
> А можете примеры привести?Какие примеры вас интересуют? Как какой-нибудь dlink загибается от банального arp flooding?
Суть-то в том, что на коммутаторах слабенький процессор и тратя свое процессорное время на одно, он может не выполнить другое.
Конечно я понимаю, что есть такие вещи как CoPP, которые как раз и созданы для решения таких проблем, вот только далеко не все оборудование это умеет, да и мало кто это настраивает. Понятно, что сеть из 50 хостов - это одно, а из 5 тысяч это другое.
В любом случае, как вы наверное понимаете, одно из самых главных правил при создании инженерной системы - это предсказуемость. Если хотя бы одно звено системы ведет себя не предсказуемо, то диагностировать и решить проблему становится гораздо сложнее.
>>>> P.S. Не считаю нормальной практикой разворачивать DHCP сервер на L2 коммутаторах
>>> Согласен, большое количество юникаст/броадкаст на слабенький контрол-плейн, вполне может
>>> привести к отказу в работе других контрол-плейн протоколов, типа STP.
>> А можете примеры привести?
> Какие примеры вас интересуют? Как какой-нибудь dlink загибается от банального arp flooding?Как нагрузка на коммутатор (arp шторм/флуд, много pps) влияют на другой функционал?
Не работает STP? Замыкается кольцо STP? потеря пакетов при маршрутизации? потеря пакетов при коммутации? Разрыв TCP сессий?Мне желательно узнать ваши примеры "странного" поведения коммутаторов под нагрузкой.
>>>>> P.S. Не считаю нормальной практикой разворачивать DHCP сервер на L2 коммутаторах
>>>> Согласен, большое количество юникаст/броадкаст на слабенький контрол-плейн, вполне может
>>>> привести к отказу в работе других контрол-плейн протоколов, типа STP.
>>> А можете примеры привести?
>> Какие примеры вас интересуют? Как какой-нибудь dlink загибается от банального arp flooding?
> Как нагрузка на коммутатор (arp шторм/флуд, много pps) влияют на другой функционал?
> Не работает STP? Замыкается кольцо STP? потеря пакетов при маршрутизации? потеря пакетов
> при коммутации? Разрыв TCP сессий?
> Мне желательно узнать ваши примеры "странного" поведения коммутаторов под нагрузкой.Процессор тратит время на обработку запросов (команд), если все его процессорное время занято одним процессом, то он не может выполнить следующие, поступающие в него команды от другого процесса.
Это основы основ. Такое не знать стыдно должно быть.
Вывод один, если проц под 100 от одного процесса, то любой другой контрол-плейн процесс, не сможет выполнить посланные на проц комманды вовремя. Соответственно может, например, так получится, что STP не отправит вовремя BPDU и подумает, что связь с рутом потерялась.
> Процессор тратит время на обработку запросов (команд), если все его процессорное время
> занято одним процессом, то он не может выполнить следующие, поступающие в
> него команды от другого процесса.
> Это основы основ. Такое не знать стыдно должно быть.Это все в теории. Что вам на практике случалось наблюдать?
>> Процессор тратит время на обработку запросов (команд), если все его процессорное время
>> занято одним процессом, то он не может выполнить следующие, поступающие в
>> него команды от другого процесса.
>> Это основы основ. Такое не знать стыдно должно быть.
> Это все в теории. Что вам на практике случалось наблюдать?Статистику что-ли собираете перед начальством, чтоб денег дали на новое железо?
У меня было, помню, BGP нейборы отваливались на роутерах. Еще телнет, хттп, отваливался из-за arp.
>>> Процессор тратит время на обработку запросов (команд), если все его процессорное время
>>> занято одним процессом, то он не может выполнить следующие, поступающие в
>>> него команды от другого процесса.
>>> Это основы основ. Такое не знать стыдно должно быть.
>> Это все в теории. Что вам на практике случалось наблюдать?
> Статистику что-ли собираете перед начальством, чтоб денег дали на новое железо?
> У меня было, помню, BGP нейборы отваливались на роутерах. Еще телнет, хттп,
> отваливался из-за arp.Типа того. :)