Есть проблема с обновлением апгрейднутой версии.
Предустановлена была 8 для одного языка.
Ключем TechNet была обновлена до 8 Pro.
Стор предлагает скачать 8.1 для одного языка и выдает ошибку. Такое ощущение что он не ту редакцию видит.
Однако на другом компьютере с 8ProWMC нормально обновилось до 8.1ProWMC.
Ну в изначальных условия Arch который впереди планеты всей.
Можно обратить внимание что почти везде надо было использовать более старые (проверенные временем?) версии пакетов.
Тот же python2, make < 5.0
На ebay не очень большая проблема достать толстушку. Полгода назад отхватил в комплекте с Network Adapter баксов за 60. Вот только доставка в Россию еще столько же вышла. Правда NTSC но это даже лучше, многие игры в NTSC смотрятся лучше изза большей частоты развертки.
Ну между 3com и Juniper у меня были небольшие грабли, надо было в динамическом режиме настраивать на 3com. Хотя до этого при статическом определении портов работало в паре с FreeBSD LAGG.
Ожидал увидеть в обзоре еще Logitech G35, очень хорошая проводная гарнитура.
И гарантия производителя радует, недавно сломались(отвалилось ухо в месте крепления с дугой) после 2 лет активного использования, выслали новые.
Ну и конечно отличный софт, восьмиканальный звук, USB интерфейс.
Сейчас смотрю в направлении Logitech G930 — тоже самое но беспроводная, и крепление ушей сделали из металла вместо пластика(который ломается).
Насчет флуда. Если dst mac нету в FDB, то обычное поведение это отправить пакет на все порты чтобы начать процесс обучения. А так как по каким либо причинам он не может его обучить то во все порты (поднятые) постоянно льется трафик.
Не такая ли у вас ситуация получилась?
Коменты раз в 5 минут оставляют время на подумать.
Этот вопрос я изучал гдето год назад, некоторые вещи мог не правильно понять.
Но я себе представляю это так.
Приходит пакет.
Железка считает для него хэш и проверяет есть ли он в таблице форвардинга.
Если его нету, то она добавляет туда хэш, мак, порт, влан.
Приходит пакет с другого порта но хэш получается таким же.
Дальше все зависит от вендора — он может как перезаписать запись в таблице так и не трогать ее.
Получается что мак с другого порта может быть не выучен и соответственно он может как отбросить пакет, так и послать флудом на все порты.
В итоге получается что хотели сэкономить в памяти на железе (очевидно что хранить 8к записей по 8 байт дороже чем по 8к записей по 6байт). Ну и плюс операции поиска по идее должны быть быстрее на меньших объемах данных.
Хэш обычно считается как функция от мак, порт, влан.
Т.е. допустим мак+порт+влан имеют длину допустим 64бита.
А хэшфункция из них делает 48бит или меньше даже, за счет этого таблица форвардинга меньше но при поиске по ней два порта(точнее тройки мак, порт, влан) могут иметь одинаковый хэш и тогда возможны варианты, например флуд во все порты или зеркалирование трафика по двум портам у которых совпал хэш.
Предустановлена была 8 для одного языка.
Ключем TechNet была обновлена до 8 Pro.
Стор предлагает скачать 8.1 для одного языка и выдает ошибку. Такое ощущение что он не ту редакцию видит.
Однако на другом компьютере с 8ProWMC нормально обновилось до 8.1ProWMC.
Т.е. не копирайт разработчика а именно название игры.
А так оно вообще на первой картинке поста есть. :)
Можно обратить внимание что почти везде надо было использовать более старые (проверенные временем?) версии пакетов.
Тот же python2, make < 5.0
Не открыта разве?
В пакете по сути только начальный загрузчик.
И гарантия производителя радует, недавно сломались(отвалилось ухо в месте крепления с дугой) после 2 лет активного использования, выслали новые.
Ну и конечно отличный софт, восьмиканальный звук, USB интерфейс.
Сейчас смотрю в направлении Logitech G930 — тоже самое но беспроводная, и крепление ушей сделали из металла вместо пластика(который ломается).
Не такая ли у вас ситуация получилась?
Этот вопрос я изучал гдето год назад, некоторые вещи мог не правильно понять.
Но я себе представляю это так.
Приходит пакет.
Железка считает для него хэш и проверяет есть ли он в таблице форвардинга.
Если его нету, то она добавляет туда хэш, мак, порт, влан.
Приходит пакет с другого порта но хэш получается таким же.
Дальше все зависит от вендора — он может как перезаписать запись в таблице так и не трогать ее.
Получается что мак с другого порта может быть не выучен и соответственно он может как отбросить пакет, так и послать флудом на все порты.
В итоге получается что хотели сэкономить в памяти на железе (очевидно что хранить 8к записей по 8 байт дороже чем по 8к записей по 6байт). Ну и плюс операции поиска по идее должны быть быстрее на меньших объемах данных.
Т.е. допустим мак+порт+влан имеют длину допустим 64бита.
А хэшфункция из них делает 48бит или меньше даже, за счет этого таблица форвардинга меньше но при поиске по ней два порта(точнее тройки мак, порт, влан) могут иметь одинаковый хэш и тогда возможны варианты, например флуд во все порты или зеркалирование трафика по двум портам у которых совпал хэш.