{"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\/nl\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","title":{"rendered":"VXLAN in NSX-V \u2014 Troubleshooting underlay","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo, eerst een beetje po\u00ebzie. Soms ben ik jaloers op mijn collega's die op afstand werken \u2014 het is geweldig om de mogelijkheid te hebben om vanuit elke uithoek van de wereld met internetverbinding te werken, vakanties op elk moment te nemen, verantwoordelijk te zijn voor projecten en deadlines, en niet gewoon van 8 tot 17 in een kantoor te zitten. Mijn functie en verantwoordelijkheden sluiten praktisch de mogelijkheid uit om lange tijd afwezig te zijn in het datacenter. Echter \u2014 af en toe komen er interessante gevallen voor, zoals hieronder beschreven \u2014 en ik begrijp dat er weinig posities zijn waar zo veel ruimte is voor creatieve expressie van de interne troubleshooter.
\n<\/a><\/noindex>
\nEen kleine disclaimer \u2014 op het moment van schrijven is de case volledig niet opgelost, maar gezien de snelheid van de reacties van de leveranciers kan het volledige oplossen nog maanden duren, en ik wil mijn bevindingen nu al delen. Ik hoop dat, geachte lezers, u me deze haast vergeeft. Maar genoeg gepraat \u2014 wat is er met de case? <\/p>\n

Eerst een inleiding: er is een bedrijf (waar ik werk als netwerkingenieur) dat klantoplossingen host in een priv\u00e9 VMware-cloud. De meeste nieuwe oplossingen worden verbonden met VXLAN-segmenten die door NSX-V worden beheerd \u2014 ik zal niet beoordelen hoeveel tijd deze oplossing me heeft bespaard, kort gezegd \u2014 veel. Ik heb zelfs mijn collega's kunnen opleiden in het configureren van NSX ESG, en kleine klantoplossingen worden zonder mijn betrokkenheid uitgerold. Een belangrijke opmerking \u2014 het control plane is met unicast-replicatie. De hypervisors zijn redundant verbonden met twee interfaces aan verschillende fysieke Juniper QFX5100-switches (samengesteld in een Virtual Chassis) en met de policy van timen route based on originating virtual port \u2014 dit voor de volledigheid.<\/p>\n

De klantoplossingen zijn zeer divers: van Windows IIS, waar alle components van de webserver op \u00e9\u00e9n machine zijn ge\u00efnstalleerd, tot behoorlijk grote oplossingen \u2014 bijvoorbeeld load-balanced Apache webfronten + LB MariaDB in Galera + shared servers die zijn gesynchroniseerd met GlusterFS. Bijna elke server moet afzonderlijk worden gemonitord, en niet alle components hebben publieke adressen \u2014 als u met deze taak te maken heeft gehad en een eleganter oplossing hebt, zou ik blij zijn met uw advies.
\nMijn monitoringoplossing bestaat uit het 'verbinden' van de firewall (Fortigate) met elk intern klantnetwerk (+SNAT en uiteraard strikte beperkingen op het soort verkeer dat is toegestaan) en het observeren van interne adressen \u2014 op deze manier wordt enige uniformiteit en vereenvoudiging van de monitoring bereikt. De monitoring zelf vindt plaats vanuit een cluster van PRTG-servers. Het schema voor monitoring ziet er ongeveer als volgt uit:<\/p>\n

\"VXLAN
\n
\nZolang we alleen met VLAN opereerden, was alles tamelijk normaal en werkte het als een klok. Na de implementatie van NSX-V en VXLAN stuitten we echter op de vraag \u2014 kunnen we de monitoring op de oude manier voortzetten? Op het moment van deze vraag was de 'snelste' oplossing het implementeren van NSX ESG en het aansluiten van de VXLAN trunk-interface in het VTEP-netwerk. Snel tussen aanhalingstekens \u2014 omdat het gebruik van de GUI voor het configureren van klantnetwerken, SNAT en firewallregels misschien het beheer centraliseert in \u00e9\u00e9n interface van vSphere, maar naar mijn mening behoorlijk omslachtig is en bovendien de set van tools voor troubleshooting beperkt. Diegenen die NSX ESG hebben gebruikt als vervanging voor een 'echte' firewall, zullen het daar vermoedelijk mee eens zijn. Hoewel zo'n oplossing misschien stabieler zou zijn \u2014 alles gebeurt immers binnen \u00e9\u00e9n leverancier.<\/p>\n

Een andere oplossing is het gebruik van NSX DLR in bridge-modus tussen VLAN en VXLAN. Hier is het denk ik duidelijk \u2014 het voordeel van het gebruik van VXLAN gaat verloren, want in dit geval moet je alsnog VLAN naar de monitoring-installatie trekken. Trouwens, tijdens de afhandeling van deze oplossing stuitte ik op een probleem waarbij de DLR-bridge geen pakketten naar de virtuele machine verstuurde die zich op dezelfde host bevond. Ik weet het, ik weet het \u2014 in boeken en gidsen over NSX-V staat duidelijk dat voor NSX Edge een aparte cluster moet worden toegewezen, maar dat staat in de boeken... Hoe dan ook, na een paar maanden met de support hebben we het probleem niet opgelost. In principe begreep ik de logica van de actie \u2014 de kernelmodule van de hypervisor, verantwoordelijk voor de encapsulatie van VXLAN, werd niet ingeschakeld als DLR en de geobserveerde server op dezelfde host bevonden, omdat het verkeer de host niet verliet en volgens de logica \u043f\u043e\u0434\u043a\u043b\u044e\u0447\u0435\u043d\u043e moest zijn aan het VXLAN-segment \u2014 encapsulatie was niet nodig. Met de support kwamen we uit op de virtuele interface vdrPort, die logisch de uplinks verenigt en ook het bridgen\/encapsuleren uitvoert \u2014 daar werd een onverenigbaarheid in het binnenkomende verkeer opgemerkt, die ik heb meegenomen in de huidige case. Maar zoals gezegd, ik heb deze case niet verder uitgewerkt, aangezien ik naar een ander project werd overgeplaatst en bovendien was de tak aanvankelijk doodlopend en had ik er niet echt de drang om deze verder te ontwikkelen. Als ik me niet vergis, werd het probleem waargenomen in de versies NSX 6.1.4 en 6.2. <\/p>\n

En daar \u2014 bingo! Fortinet kondigt native ondersteuning voor VXLAN<\/a><\/noindex>. En niet alleen point-to-point of VXLAN-over-IPSec, geen softwarematige bridging VLAN-VXLAN \u2014 dit alles is al ge\u00efmplementeerd sinds versie 5.4 (en is gepresenteerd door andere leveranciers<\/a><\/noindex>), en echte ondersteuning van het unicast control plane. Bij de implementatie van de oplossing kwam ik nog een probleem tegen \u2014 de servers die gecontroleerd werden verdwenen af en toe uit de monitoring, terwijl de virtuele machine zelf alive en kicking was. De reden was dat ik vergat om Ping op de VXLAN-interface toe te staan. Tijdens het herbalance van de clusters werden de virtuele machines verplaatst, en de vMotion eindigde met Ping om het nieuwe ESXi-host aan te geven waar de machine naartoe was verplaatst. Mijn domheid, maar dit probleem ondermijnde nogmaals het vertrouwen in de fabrikantsondersteuning \u2014 in dit geval Fortinet. Ik zeg er maar bij dat elke casus met VXLAN begint met de vraag \u201cwaar is uw software-switch VLAN-VXLAN-configuratie?\u201d Dit keer werd me aangeraden om de MTU te veranderen \u2014 dat is voor Ping, dat 32 bytes is. Vervolgens \u201cspeel\u201d met tcp-send-mss en tcp-receive-mss in het beleid \u2014 voor VXLAN, dat in UDP is ingekapseld. Pfoe, sorry \u2014 ik moest het even van me afschrijven. In ieder geval heb ik dit probleem zelf opgelost. <\/p>\n

Nadat ik met succes testverkeer had gedraaid, werd besloten om deze oplossing te implementeren. En in productie bleek dat, na een dag of twee, alles wat via VXLAN werd gemonitord, geleidelijk aan viel. Deactivering\/activatie van de interface hielp, maar slechts tijdelijk. Omd\u00e1t ik me de traagheid van de fabrikant-ondersteuning herinnerde, begon ik met troubleshooten aan mijn kant - tenslotte is mijn bedrijf, mijn netwerk - mijn verantwoordelijkheid. <\/p>\n

Onder de spoiler staat het verloop van de troubleshooting. Wie moe is van letters en opschepperij - sla deze sectie over en ga naar de post-analyse.<\/p>\n

Verloop van de troubleshooting<\/b>Bedankt voor het doorlezen - laten we verder gaan!<\/p>\n

Dus, de monitoring werkt een tijdje, daarna valt hij vanzelf uit. Dat betekent dat er waarschijnlijk geen problemen zijn in de firewall-beleid. Echter, omdat ik eerder te maken heb gehad met het probleem van vastlopende systeemprocessen in Fortigate versies 5.6+, kijken we eerst naar 'diagnose debug flow' - zoals verwacht, wordt het verkeer toegestaan en verlaat het de interface, en zoals verwacht komt er niets terug. Dat betekent dat we dieper in de stack moeten graven. Helaas moet ik de adressen verbergen, ook al zijn het RFC1918-adressen, maar ik hoop het proces van voldoende beschrijvingen te voorzien voor begrip. De server binnen de VXLAN heeft het adres x.x.x.15, de interface van de Fortigate x.x.x.254, alle andere adressen behoren tot het VTEP-netwerk.<\/p>\n

Voor een succesvolle overdracht van VXLAN-ingekapselde pakketten is het noodzakelijk om correcte informatie in verschillende tabellen te hebben. Voor overlay zijn dat ARP en OVSDB, voor underlay zijn dat ARP en CAM. In het geval van Fortigate is VXLAN FDB gelijk aan OVSDB. Laten we daar beginnen:<\/p>\n

 fortigate (root) #diag sys vxlan fdb list vxlan-LS\nmac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=xx.xx.xx.47 port=4789 vni=5008 ifindex=7\n<\/code><\/pre>\n
\nHier is alles vrij eenvoudig \u2014 het MAC-adres van de virtuele machine moet zich bevinden op de VTEP met adres xx.xx.xx.47. Bij het bekijken van de inhoud en instellingen van de ESXi-cluster ontdek ik dat het MAC-adres van de virtuele machine correct is, het adres van de VTEP ook. Ik controleer de CAM\/ARP-tabel op de Fortigate \u2014 weer allemaal overeenstemmend met de instellingen van de ESXi-host:<\/p>\n
fortigate (root) #get sys arp | grep xx.xx.xx.47\nxx.xx.xx.47 0 00:50:56:65:f6:2c dmz\n<\/code><\/pre>\n
\nDe tabellen zijn juist en het verkeer gaat weg \u2014 misschien ligt het probleem niet bij de Fortigate? Ik heb bewust de analyse van de verkeersswitching op Juniper overgeslagen \u2014 logischwijs moet de volgende stap in het troubleshooten daar plaatsvinden, maar mijn netwerk is eenvoudig \u2014 slechts \u00e9\u00e9n VLAN voor VTEP en alle componenten zijn direct aangesloten. Daarnaast herinner ik me de casus met de DLR-brug, VDR en het verdwijnende verkeer \u2014 ik ga sniffen op de ESXi-host, ondertussen maak ik een case aan bij VMware. Hieronder behoort MAC \"97:6e\" tot de Fortigate, vmnic1 \u2014 dit is de interface die VTEP met adres u.u.u.47 heeft. Sniffen in beide richtingen \"\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
\nVooruitgang \u2014 ik zie een ARP-verzoek en binnenkomend antwoord in de sniff. Ik geef alleen het ARP-antwoord en dat is alles correct. Ik heb het niet genoemd, maar de monitoringserver pingt ondertussen adres xx.xx.xx.15 \u2014 waar is het ICMP-verkeer? Ik herinner me dat ik twee uplinks heb. Hier kan gediscussieerd worden dat de virtuele poort van de bron dezelfde is (mijn teaming policy), wat betekent dat voor dezelfde vNIC dezelfde uplink moet worden gekozen, maar aangezien ik op de host ben, is het geen probleem om de andere uplink te controleren:<\/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
\nEr komen verzoeken binnen van de Fortigate, maar er is geen antwoord. Dus de probleem ligt niet bij de Fortigate. Nou, dacht ik \u2014 weer hetzelfde probleem met verdwijnend verkeer op de VDR, weer een paar maanden een case op de juiste manier moeten sturen. Na een paar dagen te zijn afgekoeld, en niet bereid om te berusten in de impasse, besloot ik meer sniffers voor de support te verzamelen om het proces te versnellen. En toen viel mijn blik \"toevallig\" op de Ethernet encapsulatie van de onderlaag. De koning is niet echt en het MAC adres van de VTEP komt niet overeen met zijn IP. Ik reset het naar nul, sniff, graaf dieper \u2014 klopt het, ja of nee. Ik geef de ARP-tabel ernaast, zodat het handiger is om te vergelijken. Let op de eerste Ethernet encapsulatie op de afbeelding bovenaan:<\/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
\nDus, wat hebben we uiteindelijk \u2014 na de migratie van de virtuele machine probeert de Fortigate verkeer naar de VTEP te sturen vanuit (juiste) VXLAN FDB, maar gebruikt het een onjuist DST MAC en het verkeer wordt zoals verwacht afgewezen door de interface van de hypervisor die het ontvangt. In \u00e9\u00e9n geval van de vier hoorde dit MAC bij de oorspronkelijke hypervisor waar we de migratie van de machine mee begonnen.<\/p>\n
Gisteren kreeg ik een e-mail van de technische ondersteuning van Fortinet \u2014 ze hebben een bug 615586 voor mijn case geopend. Ik weet niet of ik moet juichen of treuren: aan de ene kant is het probleem niet met de instellingen, aan de andere kant komt de fix pas met de firmware-update, in het beste geval bij de volgende. Mijn zelfvertrouwen wordt ook aangewakkerd door een andere bug die ik vorige maand ontdekte, maar deze keer in de HTML5 GUI van vSphere. Het lijkt wel een lokale QA afdeling van de verkopers...<\/p>\n
Ik waag het om het volgende te veronderstellen:<\/p>\n
1 \u2014 de multicast control plane zal waarschijnlijk niet onderhevig zijn aan het beschreven probleem \u2014 de MAC adressen van de VTEP worden verkregen uit het IP-adres van de groep waarop de interface is ingeschreven. <\/p>\n
2 \u2014 het probleem van de Fortigate ligt vermoedelijk in het offloaden van sessies naar de Network Processor (een soortgelijke functie als CEF) \u2014 als je elk pakket via de CPU laat gaan, zullen de tabellen worden gebruikt die de juiste \u2014 in elk geval visueel \u2014 informatie bevatten. Dit vermoeden ondersteunt dat het helpt om de interface te sluiten\/openen of een tijdje te wachten \u2014 meer dan 5 minuten. <\/p>\n
3 \u2014 het veranderen van de teaming policy, bijvoorbeeld naar expliciete failover, of het implementeren van LAG zal het probleem niet oplossen, aangezien het \u2018vastlopen\u2019 van het MAC-adres van de oorspronkelijke hypervisor in ingekapselde pakketten is waargenomen.<\/p>\n
In het licht hiervan kan ik delen dat ik recentelijk iets heb ontdekt. blog<\/a><\/noindex>, waar in een van de artikelen werd beweerd dat stateful firewalls en cachebare overdrachten een soort van noodoplossingen zijn. Nou, ik ben niet voldoende ervaren in IT om zoiets te beweren, en ik ben het ook niet meteen met alle stellingen van blogartikelen eens. Maar iets zegt me dat er waarheid in de woorden van Ivan zit.<\/p>\n
Dank voor uw aandacht! Ik beantwoord graag vragen en ontvang constructieve kritiek.
\n
Bron: 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 in NSX-V \u2014 troubleshooten underlay | ProHoster","description":"Welkom, en eerst een beetje po\u00ebzie.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/vxlan-v-nsx-v-trablshutim-underlay","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/73232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=73232"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/73232\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/73233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=73232"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=73232"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=73232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}