The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
DHCP дата и время, !*! Bumbucha, 26-Дек-13, 17:52  [смотреть все]
Есть ли связь даты, времени DHCP клиента и DHCP сервера при выдаче в аренду IP адреса.  Допустим, на dhcp сервере (catalyst2960) стоит кривая дата - 1993 год, а на клиентах дата 2013 год.  Есть ли в этом проблема выдачи адресов? Или искать проблему где-то в другом месте?
  • DHCP дата и время, !*! Merridius, 22:10 , 26-Дек-13 (1)
    > Есть ли связь даты, времени DHCP клиента и DHCP сервера при выдаче
    > в аренду IP адреса.  Допустим, на dhcp сервере (catalyst2960) стоит
    > кривая дата - 1993 год, а на клиентах дата 2013 год.
    >  Есть ли в этом проблема выдачи адресов? Или искать проблему
    > где-то в другом месте?

    Нет, проблем не должно быть.

    • DHCP дата и время, !*! Bumbucha, 09:07 , 27-Дек-13 (3)
      >> Есть ли связь даты, времени DHCP клиента и DHCP сервера при выдаче
      >> в аренду IP адреса.  Допустим, на dhcp сервере (catalyst2960) стоит
      >> кривая дата - 1993 год, а на клиентах дата 2013 год.
      >>  Есть ли в этом проблема выдачи адресов? Или искать проблему
      >> где-то в другом месте?
      > Нет, проблем не должно быть.

      Спасибо

  • DHCP дата и время, !*! rusadmin, 08:30 , 27-Дек-13 (2)
    > Есть ли связь даты, времени DHCP клиента и DHCP сервера при выдаче
    > в аренду IP адреса.  Допустим, на dhcp сервере (catalyst2960) стоит
    > кривая дата - 1993 год, а на клиентах дата 2013 год.
    >  Есть ли в этом проблема выдачи адресов? Или искать проблему
    > где-то в другом месте?

    Выдача производится НА КОЛ-ВО секунд, а не на период с 1 декабря 93 по 2 декабря 93.
    P.S. Не считаю нормальной практикой разворачивать DHCP сервер на L2 коммутаторах

    • DHCP дата и время, !*! Merridius, 10:01 , 27-Дек-13 (4)
      > P.S. Не считаю нормальной практикой разворачивать DHCP сервер на L2 коммутаторах

      Согласен, большое количество юникаст/броадкаст на слабенький контрол-плейн, вполне может привести к отказу в работе других контрол-плейн протоколов, типа STP.

      • DHCP дата и время, !*! universite, 11:38 , 27-Дек-13 (5)
        >> P.S. Не считаю нормальной практикой разворачивать DHCP сервер на L2 коммутаторах
        > Согласен, большое количество юникаст/броадкаст на слабенький контрол-плейн, вполне может
        > привести к отказу в работе других контрол-плейн протоколов, типа STP.

        А можете примеры привести?

        • DHCP дата и время, !*! Merridius, 21:41 , 27-Дек-13 (6)
          >>> P.S. Не считаю нормальной практикой разворачивать DHCP сервер на L2 коммутаторах
          >> Согласен, большое количество юникаст/броадкаст на слабенький контрол-плейн, вполне может
          >> привести к отказу в работе других контрол-плейн протоколов, типа STP.
          > А можете примеры привести?

          Какие примеры вас интересуют? Как какой-нибудь dlink загибается от банального arp flooding?
          Суть-то в том, что на коммутаторах слабенький процессор и тратя свое процессорное время на одно, он может не выполнить другое.
          Конечно я понимаю, что есть такие вещи как CoPP, которые как раз и созданы для решения таких проблем, вот только далеко не все оборудование это умеет, да и мало кто это настраивает. Понятно, что сеть из 50 хостов - это одно, а из 5 тысяч это другое.
          В любом случае, как вы наверное понимаете, одно из самых главных правил при создании инженерной системы - это предсказуемость. Если хотя бы одно звено системы ведет себя не предсказуемо, то диагностировать и решить проблему становится гораздо сложнее.

          • DHCP дата и время, !*! universite, 22:09 , 27-Дек-13 (7)
            >>>> P.S. Не считаю нормальной практикой разворачивать DHCP сервер на L2 коммутаторах
            >>> Согласен, большое количество юникаст/броадкаст на слабенький контрол-плейн, вполне может
            >>> привести к отказу в работе других контрол-плейн протоколов, типа STP.
            >> А можете примеры привести?
            > Какие примеры вас интересуют? Как какой-нибудь dlink загибается от банального arp flooding?

            Как нагрузка на коммутатор (arp шторм/флуд, много pps) влияют на другой функционал?
            Не работает STP? Замыкается кольцо STP? потеря пакетов при маршрутизации? потеря пакетов при коммутации? Разрыв TCP сессий?

            Мне желательно узнать ваши примеры "странного" поведения коммутаторов под нагрузкой.

            • DHCP дата и время, !*! Merridius, 22:33 , 27-Дек-13 (8)
              >>>>> P.S. Не считаю нормальной практикой разворачивать DHCP сервер на L2 коммутаторах
              >>>> Согласен, большое количество юникаст/броадкаст на слабенький контрол-плейн, вполне может
              >>>> привести к отказу в работе других контрол-плейн протоколов, типа STP.
              >>> А можете примеры привести?
              >> Какие примеры вас интересуют? Как какой-нибудь dlink загибается от банального arp flooding?
              > Как нагрузка на коммутатор (arp шторм/флуд, много pps) влияют на другой функционал?
              > Не работает STP? Замыкается кольцо STP? потеря пакетов при маршрутизации? потеря пакетов
              > при коммутации? Разрыв TCP сессий?
              > Мне желательно узнать ваши примеры "странного" поведения коммутаторов под нагрузкой.

              Процессор тратит время на обработку запросов (команд), если все его процессорное время занято одним процессом, то он не может выполнить следующие, поступающие в него команды от другого процесса.

              Это основы основ. Такое не знать стыдно должно быть.

              Вывод один, если проц под 100 от одного процесса, то любой другой контрол-плейн процесс, не сможет выполнить посланные на проц комманды вовремя. Соответственно может, например, так получится, что STP не отправит вовремя BPDU и подумает, что связь с рутом потерялась.

              • DHCP дата и время, !*! universite, 23:28 , 27-Дек-13 (9)

                > Процессор тратит время на обработку запросов (команд), если все его процессорное время
                > занято одним процессом, то он не может выполнить следующие, поступающие в
                > него команды от другого процесса.
                > Это основы основ. Такое не знать стыдно должно быть.

                Это все в теории. Что вам на практике случалось наблюдать?

                • DHCP дата и время, !*! Merridius, 00:01 , 28-Дек-13 (10)
                  >> Процессор тратит время на обработку запросов (команд), если все его процессорное время
                  >> занято одним процессом, то он не может выполнить следующие, поступающие в
                  >> него команды от другого процесса.
                  >> Это основы основ. Такое не знать стыдно должно быть.
                  > Это все в теории. Что вам на практике случалось наблюдать?

                  Статистику что-ли собираете перед начальством, чтоб денег дали на новое железо?
                  У меня было, помню, BGP нейборы отваливались на роутерах. Еще телнет, хттп, отваливался из-за arp.
                    

                  • DHCP дата и время, !*! universite, 00:07 , 28-Дек-13 (11)
                    >>> Процессор тратит время на обработку запросов (команд), если все его процессорное время
                    >>> занято одним процессом, то он не может выполнить следующие, поступающие в
                    >>> него команды от другого процесса.
                    >>> Это основы основ. Такое не знать стыдно должно быть.
                    >> Это все в теории. Что вам на практике случалось наблюдать?
                    > Статистику что-ли собираете перед начальством, чтоб денег дали на новое железо?
                    > У меня было, помню, BGP нейборы отваливались на роутерах. Еще телнет, хттп,
                    > отваливался из-за arp.

                    Типа того. :)




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру