none
problem se vsitovymi kartami - spojovani a nemoznost se pripojit

    Dotaz

  • Ahoj,

    mám server a pod ním 3 virtuální stroje,

    ve virtual switchi mám 2 virtualni sitovky, jednu EXT s pristupem na intrnet, druhou INT jen pro komunikaci mezi serverem a virtualnimi stroji,

    bohuzel se mi stava ze po restartu se mi sitovky "spoji" v network and sharing center nejsou jako 2 aktivni, ale spoji se a me pak nejde se pripojit na virtualni stroje.

    Doufal jsem, ze to vyresi upgrade na server 2019, ale ted mi to dela i na serveru a po restartu se nedostanu na server.

    Mate s timto zkusenosti, jak to vyresit? Zajimave, ze to neni po kazdem restartu, ale jen nekdy tak 50/50.

    Taky se mi prepina INT sitovka na public, nastavuji ji sice PS scriptem na private, ale nekdy se neprepne, k tomuto bych taky potreboval poradit, jak ji nastavit na private natrvalo, jelikoz scriptem je to jen do restartu.

    script:

    $ProfileINT = Get-NetConnectionProfile -InterfaceAlias "vEthernet (INT)"
    $ProfileINT.NetworkCategory = "Private"
    Set-NetConnectionProfile -InputObject $ProfileINT

    Dekuji za rady

    úterý 22. ledna 2019 1:42

Odpovědi

  • Nasel jsem https://community.spiceworks.com/topic/446922-static-ip-devices-receiving-169-address-after-reboot

    VM startuje. Pres ARP zkusi zjistit, jestli pridelena staticka IP neni v konfliktu na siti. A protoze switch je CISCO, odpovi nejak podivne a VM na to zareaguje pridelenim APIPA.

    Reseni jsou : jiny switch, update FW ve switchi, nebo v OS zasah do testovani pres APR zmenou Registry.

    Zkus v tomto poradi, pokud je to mozne.

    Pak jsem nasel jeste osklive reseni - vypnuti APIPA mechanismu http://lyngtinh.blogspot.com/2011/12/how-to-disable-autoconfiguration-ipv4.html

    Ale to bych delal uplne jako posledni. Resit se ma pricina, nikoliv nasledek.



    úterý 29. ledna 2019 8:29

Všechny reakce

  • Asi nejak nechapu. Tj. mas dva vSwitche? VM sitova karta INT vede do jednoho a druhe EXT do druheho? Nebo jsem nejak nepochopil, jak v jednom vSwitchi mixujes internetovy a standarni provoz. Vlan?

    Nebo jinak: co je cilem? Oprosti se toho, jak to mas nastaveno, co si myslis, ale lidove slovne popis, ceho chces dosahnout. Treba postni obrazek, jak ma vypadat LOGICKE zapojeni.

    úterý 22. ledna 2019 7:20
  • Ahoj,

    fyzicky server:

    - virtual switch INT (Internal network pro komunikaci mezi fyzickym serverem virtualama)

    - virtual switch EXT (External network pro pristup k internetu)

    tim padem mam na fyzickem serveru fyzickou sitovku a 2 virtualni, na virtualech jen 2 virtualni

    normalne jsou v network and sharing centru takto:

    po restartu se ale stane neco takoveto (nemam bohuzel screen, vzdy to musim resit tak, ze obe sitovky musim disable a pak to zase ukaze normalne, kazda zvlast, kdyz jsou spojene nejde ani script, jelikoz ty sitovky nemaji aliasy):

    a fyzickému serveru ani virtualum nejde but internet, nebo pristup na sit, funguje jen jedna z tech dvou karet.

    Kdyz na fyzickem serveru nejde EXT, tak se na nej ani nedostanu, musim zadat o KVM, je to velmi neprijemne.

    úterý 22. ledna 2019 8:14
  • tak jsme se posunuli, ale jen malo :)

    fyz. server je clenem domeny? jak ma nastavenou IP vrstvu? Jak je nastaveny interni FW? Kam smeruji: po startu OS se vyhodocuje na zaklade IP site (adresa, maska, dns servery, GW, dostupnost DC) v jake siti jsem (public, private, domain).

    Pravdepodobne po startu OS na fyz. serveru v ruznych casech dopadne neco jinak. Napr. fyz.os je clenem domeny a DC je VM na nem samem = po restartu mistu domain dostanu public. Nebo fyz. server pouziva DHCP, ktere v dobe jeho restartu neni.

    Nebo jinak: az se fyz.server odmlci, pres KVM zjisti co nejvice informaci o sitove vrtve. Obrazek s Unidentified network je velmi malo. Tj minimalne udejel ipconfig -all. Tim muzes alespon zakladne diagnostikovat, co se deje.

    Stejne tak zjisti, jak dopadla IP vrstva v jednotlivych VM - pres konzoli v HyperV.

    NICMENE: to, ze fyz. server je v nezname public siti, by nemelo mit zadny vliv na chovani vSwitche EXT  = VM normalne komunikuje, pokud opet neni zavisle na necem mimo fyz.server (typicky DHCP)


    úterý 22. ledna 2019 9:11
  • radsi posli printscreeny z ncpa.cpl, nez z nepouzitelneho network and sharing center!

    asi bych take zacal dukladnym cistenim

    netsh *** reset
    netsh advfirewall reset

    MP

    úterý 22. ledna 2019 9:20
    Moderátor
  • no ono je to i divny problem... :-/

    fyz. server neni clenem domeny, je pouzivan bez domeny, stejne tak virtual-ove, fw je nastaveny tak, ze jsou pro public zakazane vsechny porty, krome potrebných a pro private, skoro default, obe sitovky maji nastavenou sit staticky napevno

    VM startuji s opozdenim min. 2 minut, obe sitovky jsou public a INT se scriptem po startu nastavi na private (protoze jsem nenasel zpusob, jak private pro INT nastavit trvale), DHCP se nepouziva nikde

    zkusim chybu reprodukovat a zjistit co nejvic, ale to az v noci, pres den to nejde

    PS: i kdyz je EXT na fyzickem serveru nefunkcni, sluzby na virtualech funguji, pokud je EXT funkcni na danem virtualu


    úterý 22. ledna 2019 10:52
  • printscreen z ncpa.cpl je zbytecny, jelikoz tam je vsechno ok (pri "spojeni", i v normalnem stavu je stav stejny), pres ncpa.cpl musim v pripade "spojeni" sitovky obe vypnout (disable) a pak zapnout (enable), pak uz se zase "rozdeli"

    zkusim jeste v noci problem reprodukovat a co nejvic zjistit a az pak cisteni, ale dekuji, ne ze bych nechtel cistit, ale mam z toto trochu strach :)




    úterý 22. ledna 2019 10:55
  • nejaky teaming na fyz. HW neni? Broadcom sitova karta?

    Divne problemy casto vedou na nizkourovnove SW vybaveni - fw sitove karty, ovladace sitove karty, , bios serveru.

    Pokud je to HP - aplikovat posledni SPP, pokud je to Dell - aplikovat posledni SUU. Pokud je to noname, podivat se po aktualizacich sam...


    úterý 22. ledna 2019 11:30
  • teaming ne,

    sitovka je Intel(R) Ethernet Connection I217-LM a server DELL, ale model ted nevim

    po aktualizaci podivam a vyzkousim

    nechci byt za "chytraka", kdyz zadam o radu, ale prijde mi to jak sw problem, nedela to totiz po kazdem restartu a to same to dela na fyzickem serveru (doufal jsem, ze se to upgradem z 2016 na 2019 "vyresi", ale situace se jeste zhorsila, predtim to delalo skoro vyhradne na viartualech, kde se k tomu slo aspon dostat, ted to zaclo delat po upgrade-u i na fyzickem, co je pak problem, protoze se k serveru ani nedostanu a musim volat support a pripojovat KVM) i virtualech

    jak budu mit vice info, dam vedet



    úterý 22. ledna 2019 13:39
  • Ahoj, tak se mi to asi podarilo vyresit, aktualizoval jsem BIOS a reinstaloval fyzicky server a uz to vypada, ze to nedela neplechu, virtualy zustali puvodni, ale uz taky nedelaji neplechu, cim to ale bylo, nevim.

    Dekuji za tipy a rady, nebylo to nakonec tak hrozne, jak jsem cekal (myslim, ten reinstall).

    pátek 25. ledna 2019 9:19
  • Ahoj, tak jsem se radoval predcasne, problem se aktualizaci a reinstalem nevyresil, objevil se zase.

    Mozna jsem ale objevil zdroj problemu, mam nastavene staticke IP na vsech sitovkach, ale nekdy po restartu mi pribude AutoConfig IP adresa, takze sitovka ma 2 IP adresy, statickou, kterou ma mit a taky AutoCOnfig adresu a pak je na karte omezene pripojeni.

    Mate s tim zkusenosti?

    Diky

    pondělí 28. ledna 2019 22:06
  • Nasel jsem https://community.spiceworks.com/topic/446922-static-ip-devices-receiving-169-address-after-reboot

    VM startuje. Pres ARP zkusi zjistit, jestli pridelena staticka IP neni v konfliktu na siti. A protoze switch je CISCO, odpovi nejak podivne a VM na to zareaguje pridelenim APIPA.

    Reseni jsou : jiny switch, update FW ve switchi, nebo v OS zasah do testovani pres APR zmenou Registry.

    Zkus v tomto poradi, pokud je to mozne.

    Pak jsem nasel jeste osklive reseni - vypnuti APIPA mechanismu http://lyngtinh.blogspot.com/2011/12/how-to-disable-autoconfiguration-ipv4.html

    Ale to bych delal uplne jako posledni. Resit se ma pricina, nikoliv nasledek.



    úterý 29. ledna 2019 8:29
  • Dekuji za info,

    jiny model switchu nepujde, vymenili mi ten samy model s aktualnim FW, ale stav stejny...

    otestuju jeste ARP, jestli to pomuze (predpokladam, ze jsi myslel ArpRetryCount nastavit na 0)

    stranou jsem otestoval i to vypnuti APIPA, autoconfig IP se po restartu stejne zapne a pri vypnutem DHCP klientovi nejde "network and sharing center", vypisuje, ze neni spustena potrebna sluzba, u hodin neni ikona se stavem site a na lock screenu stale sviti omezene pripojeni i kdyz vsechno jede, navic prijdu o vyhody typu siti (private, public) protoze tento stav s vypnutym DHCP klientem asi neexistuje, to pro me znamena prekonfigurovani firewallu (na druhou stranu, to ale vypada, ze v tomto stavu to nedela puvodni problemy)

    uvidim, co zjistim a napisu



    úterý 29. ledna 2019 10:49
  • jsem rikal, ze to druhe reseni mi prijde osklive :)

    Jeste me zaujal clanek https://kb.vmware.com/s/article/1028373 kde se krome Registry radi "poladit" ARP ze strany switche. Jestli je to mozno na switchi u vas je otazka. Muzu zkusit podebatit o tom se sitarem, kdyz se dozvim, co tam mate.

    úterý 29. ledna 2019 11:05
  • Ahoj, tak vypnuti ARP vypada pomohlo, po nekolika restartech vseho a nekolik dni testovani se problem uz nevyskytuje,

    co se tyce sitových prvku, moc moznosti zasahu do nich nemam,

    ale switch je Cisco Catalyst 3560G, kdyby nahodou sitar vedel o co jde.

    PS: a bohuzel jsem narazil na dalsi problem:

    po-ugradu-ws-2016-na-ws-2019-switch-se-vypina-port-storm-control


    úterý 5. února 2019 17:08
  • V případě Cisco je to v tom KB článku od Vmware. Ale pokud pomohlo nastavení v OS, pak je to jednodušší, než se dohadovat se síťaři.
    středa 6. února 2019 8:02