{"id":73232,"date":"2020-03-08T08:42:18","date_gmt":"2020-03-08T05:42:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay"},"modified":"2020-03-08T08:42:18","modified_gmt":"2020-03-08T05:42:18","slug":"vxlan-v-nsx-v-trablshutim-underlay","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","title":{"rendered":"VXLAN i NSX-V - feils\u00f8king av underlay","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hei, og f\u00f8rst litt lyrikk. Jeg misunner noen ganger kolleger som jobber eksternt \u2013 for det er fantastisk \u00e5 kunne jobbe fra hvor som helst i den internett-tilkoblede verden, ferier n\u00e5r som helst, ansvar for prosjekter og frister, i stedet for \u00e5 v\u00e6re p\u00e5 kontoret fra 8 til 17. Min stilling og arbeidsoppgaver utelukker nesten muligheten for langvarig frav\u00e6r fra datasenteret. Men \u2013 av og til skjer det interessante saker, som beskrevet nedenfor \u2013 og jeg forst\u00e5r at det finnes f\u00e5 stillinger hvor det er s\u00e5 mye rom for kreativt uttrykk fra den indre troubleshooter'en.
\n<\/a><\/noindex>
\nEn liten disclaimere - p\u00e5 tidspunktet for skrivingen av artikkelen er saken fortsatt ikke l\u00f8st, men med tanke p\u00e5 responstiden fra leverand\u00f8rene, kan det ta m\u00e5neder f\u00f8r det er helt l\u00f8st, og jeg \u00f8nsker \u00e5 dele mine funn allerede n\u00e5. Jeg h\u00e5per, kj\u00e6re lesere, at dere tilgir meg for denne hastverket. Men nok med vann \u2013 hva er status p\u00e5 saken? <\/p>\n

F\u00f8rst litt bakgrunn: det er et selskap (hvor jeg jobber som nettverksingeni\u00f8r) som hoster kundel\u00f8sninger i en privat sky p\u00e5 VMWare. De fleste nye l\u00f8sninger kobles til VXLAN-segmenter, som styres av NSX-V - jeg vil ikke vurdere hvor mye tid denne l\u00f8sningen har gitt meg, men kort sagt \u2013 mye. Jeg har til og med klart \u00e5 l\u00e6re opp kolleger i konfigurasjonen av NSX ESG, og sm\u00e5 kundel\u00f8sninger settes opp uten min deltakelse. Viktig \u00e5 merke seg - kontrollplanet v\u00e5rt har unicast-replikering. Hypervisorene er koblet redundant via to grensesnitt til forskjellige fysiske Juniper QFX5100 svitsjer (satt sammen i Virtual Chassis) og med en rute-policy basert p\u00e5 opprinnelig virtuell port \u2013 dette for \u00e5 f\u00e5 helhetsbildet.<\/p>\n

Kundens l\u00f8sninger er sv\u00e6rt varierte: fra Windows IIS, hvor alle komponentene for webserveren er installert p\u00e5 \u00e9n maskin, til ganske store - for eksempel lastbalanserte Apache web-fronter + LB MariaDB i Galera + delte servere synkronisert med GlusterFS. Praktisk talt hver server m\u00e5 overv\u00e5kes separat, og offentlige adresser er ikke tilgjengelige for alle komponenter - hvis du har st\u00f8tt p\u00e5 denne oppgaven og har mer elegante l\u00f8sninger, vil jeg gjerne h\u00f8re r\u00e5d.
\nMine overv\u00e5kningsl\u00f8sning g\u00e5r ut p\u00e5 \u00e5 \u00abkoble til\u00bb brannmuren (Fortigate) til hvert internt kundnettverk (+SNAT og selvsagt strenge begrensninger p\u00e5 type tillatt trafikk) og overv\u00e5ke interne adresser \u2014 slik oppn\u00e5s en form for enhetlighet og forenkling av overv\u00e5kningen. Selve overv\u00e5kningen skjer fra en klynge av PRTG-servere. Overv\u00e5kningsskjemaet er omtrent slik:<\/p>\n

\"VXLAN
\n
\nS\u00e5 lenge vi bare jobbet med VLAN, fungerte alt ganske normalt og forutsigbart, som et klokkeverk. Etter implementeringen av NSX-V og VXLAN st\u00f8tte vi p\u00e5 sp\u00f8rsm\u00e5let \u2014 kan vi fortsette overv\u00e5kningen som f\u00f8r? P\u00e5 dette tidspunktet var den \u00abraskeste\u00bb l\u00f8sningen \u00e5 sette opp NSX ESG og koble VXLAN trunk-grensesnittet til VTEP-nettverket. Rask i anf\u00f8rselstegn \u2014 ettersom bruken av GUI for \u00e5 konfigurere kundnettverk, SNAT og brannmurregler kan forene administrasjonen i det samme grensesnittet i vSphere, men etter min mening er det ganske kl\u00f8nete og begrenser dessuten verkt\u00f8yene for feils\u00f8king. De som har brukt NSX ESG som en erstatning for en \u00abekte\u00bb brannmur, tror jeg vil v\u00e6re enige. Selv om det kanskje ville v\u00e6rt en mer stabil l\u00f8sning \u2014 for alt skjer innenfor en enkelt leverand\u00f8r.<\/p>\n

En annen l\u00f8sning er \u00e5 bruke NSX DLR i bro-modus mellom VLAN og VXLAN. Her tror jeg det er ganske klart \u2013 man mister enkelt gevinsten ved \u00e5 bruke VXLAN, for i s\u00e5 fall m\u00e5 man fortsatt trekke VLAN til overv\u00e5kningsinstallasjonen. For \u00f8vrig st\u00f8tte jeg p\u00e5 et problem i prosessen med \u00e5 implementere denne l\u00f8sningen, hvor DLR-broen ikke sendte pakker til den virtuelle maskinen som den befant seg p\u00e5 samme vert som. Jeg vet, jeg vet \u2013 i b\u00f8ker og guider om NSX-V st\u00e5r det klart at NSX Edge m\u00e5 tildeles en egen klynge, men det er i b\u00f8kene... Uansett, etter et par m\u00e5neder med support klarte vi ikke \u00e5 l\u00f8se problemet. Generelt forsto jeg logikken i handlingsforl\u00f8pet \u2013 kjernemodulen til hypervisoren, ansvarlig for innkapslingen av VXLAN, ble ikke aktivert hvis DLR og den overv\u00e5kede serveren befant seg p\u00e5 samme vert, ettersom trafikken ikke forlot verten og logisk sett burde v\u00e6rt koblet til VXLAN-segmentet \u2013 innkapsling er ikke n\u00f8dvendig. Sammen med support fokuserte vi p\u00e5 den virtuelle grensesnittet vdrPort, som logisk sammenf\u00f8yer uplinks og som ogs\u00e5 utf\u00f8rer broing\/innkapsling \u2013 der ble det observert en uoverensstemmelse i den inng\u00e5ende trafikken, som jeg tok med meg for behandling i den aktuelle saken. Men som nevnt, jeg fullf\u00f8rte ikke denne saken, da jeg ble overf\u00f8rt til et annet prosjekt, og denne grenen var opprinnelig en blindvei, s\u00e5 det var ikke mye lyst til \u00e5 utvikle den. Hvis jeg ikke tar feil, ble problemet observert i versjoner NSX 6.1.4 og 6.2. <\/p>\n

Og her \u2013 bingo! Fortinet annonserer innebygd st\u00f8tte for VXLAN<\/a><\/noindex>. Og ikke bare point-to-point eller VXLAN-over-IPSec, ikke programvarebroing VLAN-VXLAN \u2013 alt dette begynte de \u00e5 implementere allerede fra versjon 5.4 (og er representert hos andre leverand\u00f8rer<\/a><\/noindex>), og ekte st\u00f8tte for unicast control plane. Da jeg implementerte l\u00f8sningen, st\u00f8tte jeg p\u00e5 et annet problem \u2013 de kontrollerte serverne forsvant av og til fra overv\u00e5kingen, selv om selve VM-en var oppe. \u00c5rsaken var at jeg hadde glemt \u00e5 tillate Ping p\u00e5 VXLAN-grensesnittet. Under rebalanseringen av klusterne, ble VM-ene flyttet, og Ping ble brukt til \u00e5 avslutte vMotion for \u00e5 indikere den nye ESXI-vert hvor maskinen hadde blitt flyttet. En dumhet fra min side, men dette problemet svekket tilliten til produsentens support \u2013 i dette tilfellet Fortinet. Jeg nevner ikke engang at hver sak relatert til VXLAN begynner med sp\u00f8rsm\u00e5let \u00abhvor har dere VLAN-VXLAN-innstillingene deres?\u00bb Denne gangen ble jeg r\u00e5det til \u00e5 endre MTU \u2013 dette for Ping, som er 32 byte. S\u00e5 \u00ablek med\u00bb tcp-send-mss og tcp-receive-mss i policyene \u2013 for VXLAN, som er innkapslet i UDP. Puh, unnskyld \u2013 det har bygget seg opp. Uansett, jeg l\u00f8ste dette problemet p\u00e5 egen h\u00e5nd. <\/p>\n

Etter \u00e5 ha testet trafikken, ble det bestemt at denne l\u00f8sningen skulle implementeres. Og i produksjon viste det seg at etter en dag eller to, begynte alt som ble overv\u00e5ket gjennom VXLAN gradvis \u00e5 falle bort. Deaktivering\/aktivering av grensesnittet hjalp, men bare for en periode. Med tanke p\u00e5 den trege st\u00f8tten fra produsenten, tok jeg fatt p\u00e5 feils\u00f8king p\u00e5 min side \u2014 tross alt, mitt selskap, mitt nettverk \u2014 mitt ansvar. <\/p>\n

Under spoileren finnes fremdriften av feils\u00f8kingen. De som er lei av bokstaver og skryting \u2014 hopp over og g\u00e5 til etteranalysen.<\/p>\n

Fremdrift av feils\u00f8kingen<\/b>Takk for at du fortsatte \u00e5 lese \u2014 la oss fortsette!<\/p>\n

S\u00e5, overv\u00e5kingen fungerer en stund, f\u00f8r den faller bort av seg selv. Det betyr at det sannsynligvis ikke er noe problem med brannmurpolitikkene. Men, siden jeg har st\u00f8tt p\u00e5 problemet med hengende systemprosesser i Fortigate versjoner 5.6+, ser vi f\u00f8rst p\u00e5 \u00abdiagnose debug flow\u00bb \u2014 som forventet blir trafikken tillatt og g\u00e5r ut av grensesnittet, mens ingenting kommer tilbake. S\u00e5 vi graver videre nedover i stakken. Jeg m\u00e5 dessverre skjule adresser, selv om det er RFC1918, men jeg h\u00e5per \u00e5 s\u00f8rge for tilstrekkelig beskrivelse for forst\u00e5else. Serveren inne i VXLAN har adressen x.x.x.15, Fortigate-grensesnittet er x.x.x.254, alle andre adresser tilh\u00f8rer VTEP-nettverket.<\/p>\n

For the successful transmission of VXLAN-encapsulated packets, correct information must be available in several tables. For overlay, this is ARP and OVSDB; for underlay, ARP and CAM. In the case of Fortigate, the VXLAN FDB is OVSDB. That\u2019s where we will start:<\/p>\n

 fortigate (root) #diag sys vxlan fdb list vxlan-LS\nmac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=\u0443.\u0443.\u0443.47 port=4789 vni=5008 ifindex=7\n<\/code><\/pre>\n
\nIt's quite simple here \u2014 the virtual machine's MAC address must be on the VTEP with the address \u0443.\u0443.\u0443.47. After reviewing the contents and settings of the ESXI cluster, I find that the virtual machine's MAC is correct, and the VTEP address is also correct. I check the CAM\/ARP table on the Fortigate \u2014 again, everything matches the settings of the ESXI host:<\/p>\n
fortigate (root) #get sys arp | grep \u0443.\u0443.\u0443.47\n\u0443.\u0443.\u0443.47 0 00:50:56:65:f6:2c dmz\n<\/code><\/pre>\n
\nTabellene er korrekte og trafikken g\u00e5r ut \u2013 kanskje problemet ikke ligger hos Fortigate? Jeg droppet med vilje analysen av trafikkombinering p\u00e5 Juniper \u2013 logisk sett burde neste trinn i feils\u00f8king gj\u00f8res der, men nettverket mitt er enkelt \u2013 bare ett VLAN for VTEP og alle komponentene er koblet direkte. Dessuten husker jeg saken med DLR-broen, VDR og forsvinnende trafikk \u2013 jeg g\u00e5r for \u00e5 sniffe p\u00e5 ESXI-vert, og samtidig oppretter jeg en sak til VMWare. Nedenfor tilh\u00f8rer MAC \u00ab97:6e\u00bb Forti, vmnic1 \u2013 dette er grensesnittet som har VTEP med adressen u.u.u.47, og vi sniffer i begge retninger \"\u2014dir 2\".<\/p>\n
pktcap-uw --uplink vmnic1 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o \/tmp\/monitor.pcap\n<\/code><\/pre>\n
\n\"VXLAN
\n
\nProgress \u2014 in the sniff, I see an ARP request and the incoming response. I\u2019m only providing the ARP response and everything is correct there. I didn\u2019t mention that throughout this time the monitoring server is pinging the address \u0445.\u0445.\u0445.15 \u2014 where is the ICMP traffic? I remember that I have two uplinks. One might argue that the virtual source port is the same (my teaming policy), meaning the same uplink should be selected for the same vNIC, but since I\u2019m on the host, checking the other uplink is not a problem:<\/p>\n
pktcap-uw --uplink vmnic4 --vni 5008 --mac 90:6c:ac:a9:97:6e --dir 2 -o \/tmp\/monitor.pcap\n<\/code><\/pre>\n
\n\"VXLAN
\n
\nDet kommer foresp\u00f8rselar fr\u00e5 Fortigate, men det kjem ingen svar. Alts\u00e5, problemet ligg ikkje hos Fortigate. Vel, tenker eg \u2014 det er igjen det same problemet med tapt trafikk p\u00e5 VDR, igjen nokre m\u00e5nader med \u00e5 leite opp saken. Etter nokre dagar, n\u00e5r eg har roe meg ned, og ikkje vil godta det hengande, bestemte eg meg for \u00e5 samle fleire sniffar for supportteamet, for \u00e5 f\u00e5 prosessen til \u00e5 g\u00e5 raskare. Og her \u00abtilfeldigvis\u00bb falt blikket mitt p\u00e5 Ethernet-kapsling underlay. Kongen er ikkje ekte, og MAC-adressa til VTEP samsvarer ikkje med IP-en hans. Eg nullstiller, sniffer, graver \u2014 det er rett at det ikkje er rett. Eg legg ved ARP-tabellen slik at det er enklare \u00e5 samanlikne. V\u00e6r merksam p\u00e5 den f\u00f8rste Ethernet-kapslinga p\u00e5 bildet ovanfor:<\/p>\n
fortigate (root) #get sys arp | grep u.u.u.47\nu.u.u.47 0 00:50:56:65:f6:2c dmz\nfortigate (root) #get sys arp | grep u.u.u.42\nu.u.u.42 0 00:50:56:6a:78:86 dmz\n<\/code><\/pre>\n
\nS\u00e5, kva har vi til slutt \u2014 etter migrering av den virtuelle maskinen, pr\u00f8ver Fortigate \u00e5 sende trafikk til VTEP fr\u00e5 (korrekte) VXLAN FDB, men bruker feil DST MAC, og trafikken vert forventa avvist av grensesnittet i hypervisoren som mottar den. I eitt av fire tilfeller h\u00f8yrde denne MAC-en til den opprinnelege hypervisoren som vi starta migreringa fr\u00e5.<\/p>\n
I g\u00e5r fekk eg ei e-post fr\u00e5 Fortinet si tekniske st\u00f8tte \u2014 dei har opna ein feil i mitt case, 615586. Eg veit verkeleg ikkje om eg skal vere glad eller trist: p\u00e5 den eine sida \u2014 problemet ligg ikkje i innstillingane, p\u00e5 den andre \u2014 fixen kjem f\u00f8rst med ein firmware-oppgradering, i beste fall neste gong. Eg har ogs\u00e5 funne ei anna feil som held p\u00e5 \u00e5 varme opp egoet mitt, som eg oppdaga i forrige m\u00e5nad, denne gongen i HTML5 GUI vSphere. Verkeleg som eit lokalt QA-team for leverand\u00f8rar\u2026<\/p>\n
Eg vil t\u00f8rre \u00e5 anta f\u00f8lgjande:<\/p>\n
1 \u2014 multicast control plane vil mest sannsynleg ikkje vere utsett for det beskrevne problemet \u2014 sidan MAC-adressene til VTEP blir henta fr\u00e5 IP-adressa til gruppa som grensesnittet er abonnera p\u00e5. <\/p>\n
2 \u2014 det er sannsynleg at problemet til Fortigate ligg i offloadinga av sesjonar til Network Processor (tilsvarande CEF) \u2014 dersom kvart pakke blir sendt gjennom CPU, vil tabellene som inneheld korrekt \u2014 i alle fall visuelt \u2014 informasjon bli brukt. Det st\u00f8ttar denne antagelsen at det hjelper \u00e5 lukke\/opne grensesnittet eller \u00e5 vente ei lita stund \u2014 meir enn 5 minutt. <\/p>\n
3 \u2014 endring av teaming policy, til d\u00f8mes til explicit failover, eller innf\u00f8ring av LAG vil ikkje l\u00f8ysa problemet, sidan det har vore observert \u00abhefting\u00bb av MAC-adressa til den opprinnelege hypervisoren i innkapsla pakkar.<\/p>\n
I lys av dette kan eg dele at eg nyleg har oppdaga blogg<\/a><\/noindex>, hvor det i en af artiklerne blev h\u00e6vdet, at stateful firewalls og cacheable dataoverf\u00f8rselsmetoder er en slags n\u00f8dl\u00f8sninger. N\u00e5, jeg er ikke s\u00e5 erfaren inden for IT, at jeg vil g\u00f8re s\u00e5danne p\u00e5stande, og jeg er heller ikke straks enig i alle p\u00e5stande fra blogartiklerne. Men noget fort\u00e6ller mig, at der er en portion sandhed i Ivans ord.<\/p>\n
Tak for opm\u00e6rksomheden! Jeg ser frem til at besvare sp\u00f8rgsm\u00e5l og h\u00f8re konstruktiv kritik.
\n
Kilde: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u0438\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e, \u0438 \u0441\u043f\u0435\u0440\u0432\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043b\u0438\u0440\u0438\u043a\u0438. \u042f \u0438\u043d\u043e\u0433\u0434\u0430 \u0437\u0430\u0432\u0438\u0434\u0443\u044e \u043a\u043e\u043b\u043b\u0435\u0433\u0430\u043c, \u0440\u0430\u0431\u043e\u0442\u0430\u044e\u0449\u0438\u043c \u0443\u0434\u0430\u043b\u0451\u043d\u043d\u043e \u2014 \u0432\u0435\u0434\u044c \u044d\u0442\u043e \u043f\u0440\u0435\u043a\u0440\u0430\u0441\u043d\u043e \u0438\u043c\u0435\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0438\u0437 \u043b\u044e\u0431\u043e\u0433\u043e \u043a\u043e\u043d\u0446\u0430 \u043f\u043e\u0434\u043a\u043b\u044e\u0447\u0451\u043d\u043d\u043e\u0433\u043e \u043a Internet \u043c\u0438\u0440\u0430, \u043a\u0430\u043d\u0438\u043a\u0443\u043b\u044b \u0432 \u043b\u044e\u0431\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0441\u0442\u044c \u0437\u0430 \u043f\u0440\u043e\u0435\u043a\u0442\u044b \u0438 \u0434\u0435\u0434\u043b\u0430\u0439\u043d\u044b, \u0430 \u043d\u0435 \u043d\u0430\u0445\u043e\u0436\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u0444\u0438\u0441\u0435 \u0441 8 \u0434\u043e 17. \u041c\u043e\u044f \u043f\u043e\u0437\u0438\u0446\u0438\u044f \u0438 \u0440\u0430\u0431\u043e\u0447\u0438\u0435 \u043e\u0431\u044f\u0437\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438 \u0438\u0441\u043a\u043b\u044e\u0447\u0430\u044e\u0442 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0434\u043e\u043b\u0433\u043e\u0433\u043e \u043e\u0442\u0441\u0443\u0442\u0441\u0442\u0432\u0438\u044f \u0432 \u0434\u0430\u0442\u0430\u0446\u0435\u043d\u0442\u0440\u0435. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":73233,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-73232","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47VXLAN i NSX-V - vi fejlfinder underlaget | ProHoster","description":"Velkommen, og f\u00f8rst lidt lyrik.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47VXLAN \u0432 NSX-V \u2014 \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u043c underlay | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e, \u0438 \u0441\u043f\u0435\u0440\u0432\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u043b\u0438\u0440\u0438\u043a\u0438.","og:url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-08T05:42:18+00:00","article:modified_time":"2020-03-08T05:42:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"73232","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:36:23","updated":"2022-09-27 15:26:08","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/73232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=73232"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/73232\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/73233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=73232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=73232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=73232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}