none
NIC Team,Hyper-V и VLAN. RRS feed

  • Вопрос

  • Добрый день коллеги!

    Тут не совсем понятно вот такое вот примечание из статьи на MVA:

    Примечание. Не следует использовать сетевые карты tNIC с ИД VLAN для виртуальных машин Hyper-V. Для Hyper-V важно использовать tNIC по умолчанию в группе и выполнить разделение VLAN в коммутаторе Hyper-V; в противном случае ВМ могут не получать сетевые пакеты.

    Не совсем понятно, что имеется в виду.

    Вот на моем примере:

     Два сервера WS 2012 R2 c Hyper-V находятся в VLAN 123.Так же есть еще два VLAN-на 121 и 122- где будут находится виртуальные машины (ВМ) и для взаимодействия между собой.На соответствующем физическом коммутаторе CISCO поднят порт-который имеет состояние Trank и через который проходят все эти три VLAN-на.

     На каждом сервере WS 2012 R2 c Hyper-V, которые  физически находятся в VLAN 123 создан NIC Team из двух физических NIC. После объединения получился multiplexorНО я данный адаптер по умолчанию (как его называют выше tNIC-по умолчанию), не привязывал к Extensible Virtual Switch и более того не назначал ему IP адреса.Я создал три tNIC c VLAN ID 123, 121 и 122. Адаптеру tNIC c VLAN ID 123 я назначил статический айпи адрес для сервера WS 2012 R2 с Hyper-V. Два остальных tNIC с VLAN ID 121 и 122  я привязал к Extensible Virtual Switch, указал VLAN ID для каждого вновь созданного Extensible Virtual Switch, а так же для каждой ВМ-которая будет находится в своем VLAN. Все замечательно функционирует. 

    Вопрос:

    Не могу уловить логики в словах:Не следует использовать сетевые карты tNIC с ИД VLAN для виртуальных машин Hyper-V. Для Hyper-V важно использовать tNIC по умолчанию в группе и выполнить разделение VLAN в коммутаторе Hyper-V

    Что сие значит, я как раз и создал tNIC и каждый со своим VLAN ID и которые привязаны к нескольким виртуальным свичам. Как я могу разделить несколько VLAN на одном виртуальном свиче, ведь в один момент времени я могу привязать только один NIC  к соответствующему свичу и указать в свойстве виртуального коммутатора Hyper-V только один-определенный VLAN ID!

    Да и еще непонятно утверждение из статьи Aidana Finn http://www.aidanfinn.com/?p=13997

    The team interface has a device name of Microsoft Network Adapter Multiplexor Driver.  This is the device that you:

    • Configure TCP/IP on
    • Connect a Hyper-V virtual switch to

    A team can have many team interfaces, BUT the team must have only 1 team interface if you are going to use the team to connect and external virtual switch.  The NIC team must be dedicated to the external virtual switch – no exceptions

      То есть тут имеется в виду, либо я использую multiplexor для назначения статичного айпишника сервера, либо для привязки к виртуальному свичу (то есть привязки самого multiplexora- если нет VLAN, либо несколькиъ tNIC на его основе в случае нескольких VLAN-ов)? 

    Может я что-то не уловил ? 

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!






    • Изменено rеstless 12 ноября 2013 г. 2:23
    8 ноября 2013 г. 5:49

Ответы

  • External Switch является "прослойкой" между ВМ и Вашей физикой. Все пакеты будут проходить через физику..фильтровать только будет extension от hyper-v на физ.адаптере.  Если был бы Internal/Private, то весь траффик был бы "внутри хоста", а в данном случае при External все уходит на физику. Все это обеспечивается за счет взаимодействия вирт.машин + VMBus, обеспечеченный Integration Services. Если нет поддержки на уровне гостевой машины, то иногда исп-ют Legacy Adapters. к примеру, hyper-v 2008 r2 + freebsd

    а) для функционирования VLAN необходима поддержка 802.1 Q на физ.адаптере

    б) Теггируются на уровне hyper-v switch/vm adapters ..потом уходит в "физику" ..далее на коммутатор/switch и т.д. От ВМ свитч получает source,destination + vlan tagging ID , если свитч внутренний, то отправляет на порты virtual switch, если external, то на адаптер, к которому он замаплен.

    в) галочка говорит о том, что родительский адаптер будет в определенном VLAN'е и все вирт.машины, по умолчанию, будут уходить в этот VLAN. Если мы ставим и на свитче, и на ВМ , то хост (если есть sharing с ними) и ВМ будут в разных VLAN.

    У Вас был конкретный вопрос по поддержке Nic Team для External Switch. Единственное требование, как писал ранее, для External Switch должен быть 1 выделенный Team Interface без назначения на ЭТОМ интерфейсе VLAN'ов. VLAN'ы назначаются на уровне Hyper-V в в таком случае.

    Коллеги, если где-то ошибаюсь, то поправьте,пожалуйста. 


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com




    • Изменено R.LevchenkoMVP 11 ноября 2013 г. 6:02
    • Помечено в качестве ответа rеstless 11 ноября 2013 г. 6:21
    11 ноября 2013 г. 5:51
  • Очевидных вариантов траблшутинга, кроме проверки разрешения нужных VLAN на физическом оборудовании в транковом режиме, нет. Проще всего это проверить, погружая дефолтный тимовый интерфейс (подключенный через "транковые" физические адаптеры) в тот или иной VLAN и пытаясь получить к нему доступ из других виртуальных сетей. Например, погрузить интерфейс в 121 VLAN, и попытаться получить доступ к серверной ОС с рабочей станции, подключенной в 122  VLAN. Если доступа нет — разбираться с сетевиками.

    Если доступ есть, разбираться весь тиминг и начинать работу над ошибками. Лучше в новой теме.

    • Помечено в качестве ответа rеstless 12 ноября 2013 г. 11:50
    12 ноября 2013 г. 11:34
    Модератор

Все ответы

  • Когда мы делаем тиминг и добавляем туда наши адаптеры, то получается 1 Team Interface , который будет работать в Default Mode/Default VLAN ,если при создании Вы указываете VLAN ID , то будем VLAN Mode. Вы можете это посмотреть , исп-я lbfoadmin.exe - > Adapters and Interfaces -> Team Interfaces -> Add Interface .. там же можно добавить доп.интерфейс. Необходимо, если есть > 1 VLAN, но!

    Вы чуть обрезали цитату: 

    A team can have many team interfaces, BUT the team must have only 1 team interface if you are going to use the team to connect and external virtual switch.  The NIC team must be dedicated to the external virtual switch – no exceptions; Microsoft and the NIC team don’t care what your budget or bosses demands are.

    =Microsoft будет поддерживать решение только в том случае, если Team Interface будет использоваться исключительно для External Switch и не более. Т.е. должен быть ТОЛЬКО 1 тиминг интерфейс без конфигурации VLAN и т.д. = Default Mode/Default VLAN на этом NIC Team.


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com


    • Предложено в качестве ответа R.LevchenkoMVP 8 ноября 2013 г. 11:00
    • Изменено R.LevchenkoMVP 8 ноября 2013 г. 11:09
    8 ноября 2013 г. 11:00
  • Когда мы делаем тиминг и добавляем туда наши адаптеры, то получается 1 Team Interface , который будет работать в Default Mode/Default VLAN ,если при создании Вы указываете VLAN ID , то будем VLAN Mode. Вы можете это посмотреть , исп-я lbfoadmin.exe - > Adapters and Interfaces -> Team Interfaces -> Add Interface .. там же можно добавить доп.интерфейс. Необходимо, если есть > 1 VLAN, но!

    Вы чуть обрезали цитату: 

    A team can have many team interfaces, BUT the team must have only 1 team interface if you are going to use the team to connect and external virtual switch.  The NIC team must be dedicated to the external virtual switch – no exceptions; Microsoft and the NIC team don’t care what your budget or bosses demands are.

    =Microsoft будет поддерживать решение только в том случае, если Team Interface будет использоваться исключительно для External Switch и не более. Т.е. должен быть ТОЛЬКО 1 тиминг интерфейс без конфигурации VLAN и т.д. = Default Mode/Default VLAN на этом NIC Team.


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com


    Так тогда что мне делать если у меня три VLAN и мне надо связать множество виртуалок между этими тремя VLAN , опять сторонние решения использовать ?

     

     

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!


    • Изменено rеstless 8 ноября 2013 г. 12:08
    8 ноября 2013 г. 12:06
  • Когда мы делаем тиминг и добавляем туда наши адаптеры, то получается 1 Team Interface , который будет работать в Default Mode/Default VLAN ,если при создании Вы указываете VLAN ID , то будем VLAN Mode. Вы можете это посмотреть , исп-я lbfoadmin.exe - > Adapters and Interfaces -> Team Interfaces -> Add Interface .. там же можно добавить доп.интерфейс. Необходимо, если есть > 1 VLAN, но!

    Вы чуть обрезали цитату: 

    A team can have many team interfaces, BUT the team must have only 1 team interface if you are going to use the team to connect and external virtual switch.  The NIC team must be dedicated to the external virtual switch – no exceptions; Microsoft and the NIC team don’t care what your budget or bosses demands are.

    =Microsoft будет поддерживать решение только в том случае, если Team Interface будет использоваться исключительно для External Switch и не более. Т.е. должен быть ТОЛЬКО 1 тиминг интерфейс без конфигурации VLAN и т.д. = Default Mode/Default VLAN на этом NIC Team.


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com


    Так тогда что мне делать если у меня три VLAN и мне надо связать множество виртуалок между этими тремя VLAN ?

     

     

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    Определять VLAN ID на самих VM

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    8 ноября 2013 г. 12:08
  • Странно, но из темы я понял, что можно "нарезать" тиминг группу на дополнительные tNIC. 

    Вот только что ходил в ЦОД и пробовал сделать следующее.

     Создал NIC Teaming группу из двух физических NIC -в результате получился один тиминг интерфейс Default Mode. Далее создал виртуальный свич и привязал его к тиминг интерфейсу. Далее я указал VILAN ID на самих ВМ, но не на свиче! И в итоге я ничего не получил, трафик между ВМ не ходит..

     Тогда зачем сделали функционал в NIC Team для создания tNIC c указанием Vlan ID , я просто не пойму ? 

    Либо я так понял Майкрософт говорит: либо вы создаете тиминг группу Default Mode, либо VLAN Mode,но не обе ? Так ?  

     


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!







    • Изменено rеstless 8 ноября 2013 г. 12:23
    8 ноября 2013 г. 12:14
  • Вот только что ходил в ЦОД и пробовал сделать следующее.

     Создал NIC Teaming группу из двух физических NIC -в результате получился один тиминг интерфейс Default Mode. Далее создал виртуальный свич и привязал его к тиминг интерфейсу. Далее я указал VILAN ID на самих ВМ, но не на свиче! И в итоге я ничего не получил, трафик между ВМ не ходит..

     Тогда зачем сделали функционал в NIC Team для создания tNIC c указанием Vlan ID , я просто не пойму ?

     


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    Для поддержки несколько VLANов на одном NIC Team. Полезен, если данный nic team используется не для ext.v.sw .  У Вас маршрутизация между VLAN'ами как таковая работает? На физ.уровне? Физика в какой VLAN уходит?

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com


    8 ноября 2013 г. 12:32
  •  Странно, чем функционал с одним NIC Team с "нарезанием" tNIC  для каждого VLAN и привязкой к Ex.V.SW не угодил Майкрософт.Сам сервер физически в VLAN 123 и из физики все хосты находящиеся в других подсетях и VLAN-х ( как физические, так и виртуальные) пингуются успешно.

    Я начинаю наверное понимать, что данный механизмы реализовываются для разных физических топологий сети по разному , то есть схема (когда используя только один NIC Team-как вы и описали выше) при определенном условии физической коммутации, когда достаточно всего одного Ex.V.SW и VLAN ID указываются только для виртуалок. То есть получается что тегирование пакета происходит не на уровне Ex.V.SW, а на уровне физических NIC-которые обьеденены в транк, может я ошибаюсь ?

     Но у меня получается схема физики немного другая, при которой весь исходящий трафик от ВМ должен дойти до определенного физического коммутатора CISCO на котором порт установлен в режим транка и на нем же разрешены все VLAN  и на нем же входящий трафик должен быть уже тегированный и тегирован он был именно  с помощью EX.V.SW (при указании галочки VLAN ID на свиче) из определенной виртуальной машины (ВМ) привязанной к определенному VLAN ID.

    То есть тут получается схема которую поддерживает Майкрософт- но при условии что коммутация должна быть настроена определенным образом ? Пока к сожалению до конца я не могу это понять! Уже кучу статей перелопатил на "буржуйском" и все как то крутят, вертят и именно почему то с "нарезкой" tNIC.

    Да к стати вопрос для самообразованности:-))- а я могу данный вариант как ни будь наиграть дома на своем стенде. Беда в том, что у меня есть почти все оборудования для виртуализации , но к сожалению нет физически умного коммутатора-который бы поддерживал и создавал VLAN,LACP и т.д..Как то по другому можно наиграть данную схему с меж VLAN-ным обменом ВМ ?

     Заранее благодарен за понимание!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!









    • Изменено rеstless 8 ноября 2013 г. 17:51
    8 ноября 2013 г. 17:43
  • К стати если взять вот эту статью по которой у нас примерно и было настроен NIC Team в Windows Serevr 2008 R2 для виртуальных машин, то как раз и получается что после создания Team на сетевом адаптере ставится галочка для режима VLAN Promiscuous что и означает некий транк и соответственно мы настраиваем один единственный  NIC Team для виртуального коммутатора Hyper-V и далее нам достаточно указать VLAN ID только для ВМ но не в самом виртуальном коммутаторе.

     То есть еще раз хочу заметить разницу в настройках, как я это понял:

    1.единственная Team группа c единственным tNIC в режиме Defaul Mode для виртуального коммутатора Hyper-V - в случае когда на самих физических NIC сервера настроен транк.

    2.единственная Team группа c дополнительными "нарезанными" tNIC в режиме VLAN Mode и каждый для своего виртуального коммутатора на каждый из которых  указан VLAN ID для тегирования трафика, который должен попасть на транковый порт управляемого физического коммутатора. 

    По крайней мере я логически так себе это представляю.Поправьте, если это не так.

     

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!



    • Изменено rеstless 8 ноября 2013 г. 20:05
    8 ноября 2013 г. 20:02
  •  Доброе утро Уважаемые коллеги! Не сочтите за демагогию, но для меня нет ничего хуже чем что-то "не взять в толк"и поэтому хочу разобраться в правильности своих убеждений спросив у вас как у экспертов.Давайте попробую по другому обрисовать ситуацию.PVLAN не берем, так как у подрядчика физика настроена именно так и никак иначе.

    Вариант 1. Есть один хост с Hyper-V на котором работают две ВМ из одной подсети. Виртуальный коммутатор настроен в режиме External. Трафик отправленный с исходной ВМ на целевую ограничится только лишь одним хостом Hyper-V пройдя только через виртуальный коммутатор так ?

    Вариант 2. Есть один хост с Hyper-V на котором работают две ВМ из разных подсетей. Коммутатор настроен с той же конфигурацией, но теперь что бы трафику попасть на целевую ВМ в другой подсетки требуется как минимум некий роутинг.Допустим есть третья ВМ которая играет роль маршрутизатора, тогда трафик опять же ограничится только лишь одним хостом Hyper-V и за его перделы не выйдет (образно говоря.)Либо если у меня есть некая "железка" в сети, то соответственно трафик с хоста Hyper-V уйдет на железку и возвратится на хост на целевую ВМ находящуюся в другой подсетке, так ?

    Вариант 3. Есть один хост с Hyper-V на котором работают две ВМ из разных VLAN.В сети есть циска с настроенным портом как транк и разрешены все VLAN.Еще есть некий маршрутизатор, для того что бы сделать роутинг между VLAN.

    а) Физические NIC на хосте Hyper-V не понимают 802.1Q (то есть в транк их не объединить).В данной ситуации как осуществляется тегирование пакета исходящего из исходной ВМ (галочка VLAN ID включена на уровне ВМ) ? После тегирования пакет уходит с хоста Hyper-V на циску в поисках своего VLAN и далее после цики возвращается в целевую ВМ которая находится в другом VLAN так ?

    б) Физические NIC на хосте Hyper-V понимают 802.1Q и объеденены в транк. На каком уровне здесь происходит тегирование пакета для того что бы пакет попал в другую ВМ в другом VLAN ?

    в) Галочка VLAN ID на виртуальном коммутаторе говорит о том, что бы я мог отправить пакет в другой VLAN ID из родительского раздела ?

    Хотелось бы услышать ваше мнение по данным вопросам. То что поддерживает майкрософт в части NIC Team, тогда должно подпадать только под вариант б) ?

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!






    • Изменено rеstless 11 ноября 2013 г. 5:26
    11 ноября 2013 г. 5:21
  • External Switch является "прослойкой" между ВМ и Вашей физикой. Все пакеты будут проходить через физику..фильтровать только будет extension от hyper-v на физ.адаптере.  Если был бы Internal/Private, то весь траффик был бы "внутри хоста", а в данном случае при External все уходит на физику. Все это обеспечивается за счет взаимодействия вирт.машин + VMBus, обеспечеченный Integration Services. Если нет поддержки на уровне гостевой машины, то иногда исп-ют Legacy Adapters. к примеру, hyper-v 2008 r2 + freebsd

    а) для функционирования VLAN необходима поддержка 802.1 Q на физ.адаптере

    б) Теггируются на уровне hyper-v switch/vm adapters ..потом уходит в "физику" ..далее на коммутатор/switch и т.д. От ВМ свитч получает source,destination + vlan tagging ID , если свитч внутренний, то отправляет на порты virtual switch, если external, то на адаптер, к которому он замаплен.

    в) галочка говорит о том, что родительский адаптер будет в определенном VLAN'е и все вирт.машины, по умолчанию, будут уходить в этот VLAN. Если мы ставим и на свитче, и на ВМ , то хост (если есть sharing с ними) и ВМ будут в разных VLAN.

    У Вас был конкретный вопрос по поддержке Nic Team для External Switch. Единственное требование, как писал ранее, для External Switch должен быть 1 выделенный Team Interface без назначения на ЭТОМ интерфейсе VLAN'ов. VLAN'ы назначаются на уровне Hyper-V в в таком случае.

    Коллеги, если где-то ошибаюсь, то поправьте,пожалуйста. 


    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com




    • Изменено R.LevchenkoMVP 11 ноября 2013 г. 6:02
    • Помечено в качестве ответа rеstless 11 ноября 2013 г. 6:21
    11 ноября 2013 г. 5:51
  • Спасибо за ответ, по NIC Team все ясно! Тогда мне мои другие вопросы переводить в другой топик ?

     Значит в моем случае одна созданная Team группа привязывается к виртуальному коммутатору связанному с физическим интерфейсам.Далее в свойствах виртуальных машин-виртуального адаптера, мне необходимо указать соответствующие VLAN ID.Сделал именно так! К сожалению нет взаимодействия трафика между ВМ из разных VLAN.:-((

    Предварительный вывод:

    Либо сервер подключен к другому порту циски-который не входит в транк.

    Либо что менее вероятно физические NIC непонимают 802.1q- в чем я сомневаюсь.

    P.S. Два предыдущих сервера работают по принципу, который я описал ранее, а именно создано несколько виртуальных коммутаторов и к ним привязаны адаптеры.VLAN ID назначены как для ВМ, так и для каждого виртуального коммутатора (потому как сам хост находится в VLAN 123 а оcтальные VM в VLAN 121 и 122 ).При такой настройке все прекрасно взаимодействует. Отсюда вопрос-почему именно в такой схеме?:-))Либо изначально неправильно спроектировано должное взаимодействие ?

    Спасибо еще раз! Сейчас еще почитаю по внимательней вот ЭТУ статейку.Жаль конечно , что на домашнем стенде данную ситуёвину не наиграть:-(( 


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!











    • Изменено rеstless 11 ноября 2013 г. 6:30
    11 ноября 2013 г. 6:16
  • Проверьте на стороне cisco сначала, а потом уже hyper-v смотреть будем

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

    11 ноября 2013 г. 7:18
  • Проверьте на стороне cisco сначала, а потом уже hyper-v смотреть будем

    Roman Levchenko, MCITP, MCTS http://www.rlevchenko.com

     Ок, проверим на счет того подключен ли сервер вообще в транковый порт, к сожалению через недельку только , потому как сейчас не имею физической возможности там находится.Но могу точно сказать,что касается cisco- то там все в полном порядке, так как предыдущие два сервера по сей день трудятся справно!

    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    11 ноября 2013 г. 9:30
  • Да, еще на всякий случай выкладываю скрины, как это у нас сейчас работает:

     


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    12 ноября 2013 г. 2:25

  • Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    12 ноября 2013 г. 2:26
  • Мне кажется, что с точки зрения упрощения администрирования нужно на мультипрексорный адаптер повесить виртуальный коммутатор с разрешением его использования родительским разделом, доставить на физические порты с физических коммутаторов транковое подключение, и далее тегировать уже интерфейсы виртуальных машин.

    Если Вам по каким-то причинам кажется правильным использовать несколько виртуальных коммутаторов с виртуальными интерфейсами, нарезанными с тимингового адаптера, то лучше разместить сами виртуальные интерфейсы в консоли LBFO в нужные VLAN, чтобы уже не тегировать интерфейсы каждой ВМ.

    12 ноября 2013 г. 7:18
    Модератор
  • Мне кажется, что с точки зрения упрощения администрирования нужно на мультипрексорный адаптер повесить виртуальный коммутатор с разрешением его использования родительским разделом, доставить на физические порты с физических коммутаторов транковое подключение, и далее тегировать уже интерфейсы виртуальных машин.

    Если Вам по каким-то причинам кажется правильным использовать несколько виртуальных коммутаторов с виртуальными интерфейсами, нарезанными с тимингового адаптера, то лучше разместить сами виртуальные интерфейсы в консоли LBFO в нужные VLAN, чтобы уже не тегировать интерфейсы каждой ВМ.

     Денис вы будете смеяться, но я именно так и хотел сделать, даже не зная изначально, что Майкрософт поддерживает только такое решение (в случае Hyper-V) и именно сконфигурировав изначально так как требуется, но увы-нет пинга между VLAN:-).

     По второму вашему ответу- то в данном случае и в дополнительных-нарезанных tNIC на основе Team  уже изначально указан VLAN (там просто другого и не выбрать)+ все то, что я уже предоставил на скринах. И ведь самое "поганое" что ведь работает и если бы транк не отдавался, то и коммуникации между виртуалками в разных VLAN-ах не было бы ? 

    Могу еще раз по порядку рассказать что я делал для изначального варианта-ка должно быть:

    - Поучил уведомление от подрядчика что данные сервера "уходят" в транковый порт;

    - Создал NIC Team из двух физических NIC (при этом в свойствах сетевого подключения появился multiplexor-которому я назначил статичный айпишник для сервера );

    - Далее создал виртуальный коммутатор для External сети и привязал к нему данный multiplexor;

    - Далее на основе данного виртуального коммутатора отдал vNIC виртуальным машинам из разных VLAN и указал в свойствах vNIC свой VLAN ID, а так же на самом коммутаторе указал VLAN ID - номер того вилана где находится сам хост виртуализации (хотя может так неправильно, но я так же снимал галочку с коммутатора для эксперимента)- результат отрицательный!

     Я согласен, что все делалось на скорую руку и я просто мог что-то упустить...вот что именно ? Я пока не готов сказать..


    P.S. Честно говоря меня совсем не устраивает и не кажется правильным, то как сейчас работает!!! Я уже себе весь мозг вынес честно говоря и если бы не подрядчик,я бы уже знал всю физику коммутации воочию,но к сожалению приходиться на слово верить;-((

    Вопрос:

     Что еще можно проверить  ?

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!






    • Изменено rеstless 12 ноября 2013 г. 9:54
    12 ноября 2013 г. 9:48
  • Очевидных вариантов траблшутинга, кроме проверки разрешения нужных VLAN на физическом оборудовании в транковом режиме, нет. Проще всего это проверить, погружая дефолтный тимовый интерфейс (подключенный через "транковые" физические адаптеры) в тот или иной VLAN и пытаясь получить к нему доступ из других виртуальных сетей. Например, погрузить интерфейс в 121 VLAN, и попытаться получить доступ к серверной ОС с рабочей станции, подключенной в 122  VLAN. Если доступа нет — разбираться с сетевиками.

    Если доступ есть, разбираться весь тиминг и начинать работу над ошибками. Лучше в новой теме.

    • Помечено в качестве ответа rеstless 12 ноября 2013 г. 11:50
    12 ноября 2013 г. 11:34
    Модератор
  • Спасибо всем! Очень верю и надеюсь, что топика с траблшутингом не наступит:-)))

    Но если что,то такой топик всплывет.


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    12 ноября 2013 г. 11:51
  • Очевидных вариантов траблшутинга, кроме проверки разрешения нужных VLAN на физическом оборудовании в транковом режиме, нет. Проще всего это проверить, погружая дефолтный тимовый интерфейс (подключенный через "транковые" физические адаптеры) в тот или иной VLAN и пытаясь получить к нему доступ из других виртуальных сетей. Например, погрузить интерфейс в 121 VLAN, и попытаться получить доступ к серверной ОС с рабочей станции, подключенной в 122  VLAN. Если доступа нет — разбираться с сетевиками.

    Если доступ есть, разбираться весь тиминг и начинать работу над ошибками. Лучше в новой теме.

    Да, все хотел спросить, ни как нельзя данную тему дома наиграть. ТО есть все оборудование есть, но нет физического коммутатора-который бы отдавал транк. Может есть программная циска, либо еще некая хитрая штука, уж очень меня эта тема подстегнула ?

    Спасибо!


    Люди тратят здоровье, что бы заработать $, а затем тратят $, что бы вернуть здоровье!

    12 ноября 2013 г. 11:53
  • Случайно зашел в тему. 

    Программная Cisco, к слову, есть. Но это в режиме фермы cisco.. пускать во внешку данный тестовыйстенд - никак. Все манипулиции, свзяанные с настройкой Cisco, выполняются в 1 приложении и в рамках только него. Своего рода симуляция конфигурации cisco, но с использованием реального Cisco IOS для конкретного устройства.

    http://www.gns3.net/ 


    Roman Levchenko, MCSA, MCITP, MCTS http://www.rlevchenko.com

    21 июня 2014 г. 6:09