{"id":99,"date":"2026-08-26T23:08:19","date_gmt":"2026-08-27T04:08:19","guid":{"rendered":"https:\/\/tecno-experts.com\/fransilvablog\/?p=99"},"modified":"2026-08-27T21:20:19","modified_gmt":"2026-08-28T02:20:19","slug":"troubleshooting-l2vpn-vmnic-flapping-y-failed-criteria-128-en-una-plataforma-iaas","status":"publish","type":"post","link":"https:\/\/tecno-experts.com\/fransilvablog\/nsx\/troubleshooting-l2vpn-vmnic-flapping-y-failed-criteria-128-en-una-plataforma-iaas\/","title":{"rendered":"Troubleshooting L2VPN: vmnic flapping y Failed Criteria 128 en una plataforma IaaS"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Hola, en este nuevo post vamos a revisar un caso bastante interesante de <strong>troubleshooting de red en una plataforma IaaS<\/strong>, donde el requerimiento inicial parec\u00eda sencillo: extender una red de capa 2 mediante un t\u00fanel L2VPN.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sin embargo, al habilitar el tr\u00e1fico comenzaron a presentarse eventos de <strong>flapping sobre una vmnic de los hosts ESXi<\/strong>, afectando la conectividad.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Lo interesante de este caso es que el problema inicialmente pod\u00eda apuntar a varias capas: driver, firmware, SFP+, cableado, switch f\u00edsico o incluso a la forma en que estaba circulando el tr\u00e1fico dentro de la infraestructura virtual.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Vamos a revisar c\u00f3mo se identific\u00f3 el problema y qu\u00e9 soluci\u00f3n permiti\u00f3 estabilizar el ambiente.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Escenario<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La plataforma IaaS utilizaba una arquitectura de red definida por software mediante <strong>NSX<\/strong>, donde las redes de organizaci\u00f3n de los clientes estaban soportadas mediante segmentaci\u00f3n l\u00f3gica.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">El requerimiento consist\u00eda en establecer una <strong>L2VPN utilizando una herramienta de terceros<\/strong> para extender una red entre la nube y la infraestructura on-premises del cliente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En este caso particular, la herramienta utilizada para realizar el t\u00fanel requer\u00eda habilitar las siguientes pol\u00edticas de seguridad:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Promiscuous Mode<\/strong><\/li>\n\n\n\n<li><strong>MAC Address Changes<\/strong><\/li>\n\n\n\n<li><strong>Forged Transmits<\/strong><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">El inconveniente era que estas configuraciones no pod\u00edan aplicarse directamente sobre la red l\u00f3gica utilizada por el cliente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por esta raz\u00f3n fue necesario buscar un workaround.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Aparece el flapping de la vmnic<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Al generar tr\u00e1fico sobre la red extendida se observ\u00f3 que la interfaz f\u00edsica utilizada por los hosts ESXi comenzaba a presentar cambios de estado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Revisando los logs apareci\u00f3 un evento similar al siguiente:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#91;netCorrelator]\n&#91;vob.net.dvport.uplink.transition.down]\nUplink: vmnic3 is down.\n0 uplinks up.\nFailed criteria: 128<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">El dato importante aqu\u00ed era:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Failed criteria: 128<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando encontramos este tipo de eventos no es recomendable asumir inmediatamente que el problema est\u00e1 en VMware.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tenemos que revisar toda la ruta del tr\u00e1fico.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">\u00bfQu\u00e9 significa Failed Criteria 128?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">De acuerdo con el KB oficial de Broadcom <strong>Network adapter (vmnic) is down or fails with a Failed Criteria Code<\/strong>, el c\u00f3digo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>128<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">significa:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Link state reported by the driver<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Es decir, el <strong>driver est\u00e1 reportando que el estado del enlace f\u00edsico est\u00e1 DOWN<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Broadcom tambi\u00e9n indica que, cuando esta ca\u00edda no ha sido provocada intencionalmente, se deben revisar diferentes componentes de la infraestructura, entre ellos:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Driver de la NIC.<\/li>\n\n\n\n<li>Firmware.<\/li>\n\n\n\n<li>M\u00f3dulo SFP+.<\/li>\n\n\n\n<li>Cableado.<\/li>\n\n\n\n<li>Switchport del switch f\u00edsico.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Este punto es importante porque el log por s\u00ed solo muestra el <strong>efecto observado por ESXi<\/strong>, pero no necesariamente identifica directamente la causa ra\u00edz.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Para mayor informaci\u00f3n: <a href=\"https:\/\/knowledge.broadcom.com\/external\/article\/318898\/network-adapter-vmnic-is-down-or-fails-w.html\">https:\/\/knowledge.broadcom.com\/external\/article\/318898\/network-adapter-vmnic-is-down-or-fails-w.html<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Primeras validaciones<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Una de las primeras verificaciones que podemos realizar desde ESXi es revisar el estado de las interfaces f\u00edsicas.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Podemos utilizar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>esxcli network nic list<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Este comando nos permite visualizar informaci\u00f3n como:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Name\nDriver\nLink Status\nSpeed\nDuplex\nMAC Address\nMTU\nDescription<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Si necesitamos revisar una interfaz espec\u00edfica con mayor detalle podemos ejecutar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>esxcli network nic get -n vmnic#<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Por ejemplo:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>esxcli network nic get -n vmnic3<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Aqu\u00ed podemos obtener datos importantes como:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Driver\nFirmware Version\nDriver Version\nLink Status\nBus Info<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Con esta informaci\u00f3n podemos comenzar a comparar el estado actual del hardware con las versiones compatibles para nuestra versi\u00f3n de ESXi.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Validaci\u00f3n de driver y firmware<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Otro de los KB utilizados durante el an\u00e1lisis fue <strong>Determining Network\/Storage firmware and driver version in ESXi<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Broadcom recomienda identificar correctamente la tarjeta utilizando los valores:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VID \u2014 Vendor ID.<\/li>\n\n\n\n<li>DID \u2014 Device ID.<\/li>\n\n\n\n<li>SVID \u2014 Sub-Vendor ID.<\/li>\n\n\n\n<li>SDID \u2014 Sub-Device ID.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Para obtener esta informaci\u00f3n podemos utilizar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>vmkchdev -l | grep vmnic<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Tambi\u00e9n es importante identificar exactamente la versi\u00f3n del host ESXi:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>vmware -vl<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Con esta informaci\u00f3n podemos realizar la validaci\u00f3n correspondiente en el <strong>Broadcom Compatibility Guide<\/strong>: <a href=\"https:\/\/knowledge.broadcom.com\/external\/article\/323110\/determining-networkstorage-firmware-and.html\">https:\/\/knowledge.broadcom.com\/external\/article\/323110\/determining-networkstorage-firmware-and.html<\/a><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Este paso es importante.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Antes de modificar configuraciones de red o reemplazar componentes f\u00edsicos conviene confirmar que la combinaci\u00f3n entre:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>ESXi + driver + firmware + adaptador f\u00edsico<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">sea compatible. <\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Entonces, \u00bfqu\u00e9 estaba sucediendo?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s de realizar las verificaciones con VMware\/Broadcom y con la contraparte responsable de los servidores f\u00edsicos, se encontr\u00f3 un comportamiento importante dentro del flujo de red.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">El tr\u00e1fico proveniente de la <strong>red de vApp de organizaci\u00f3n<\/strong> utilizado para el L2 extendido estaba regresando hacia la NIC f\u00edsica del servidor.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Esto generaba un comportamiento de bucle sobre la red.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Como consecuencia, la interfaz f\u00edsica utilizada por el perfil de red del servidor terminaba perdiendo conectividad.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Aqu\u00ed estaba realmente el punto cr\u00edtico del caso.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">No se trataba simplemente de observar:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Failed criteria: 128<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">y reemplazar una NIC.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Hab\u00eda que entender <strong>qu\u00e9 estaba provocando que el enlace terminara report\u00e1ndose como DOWN<\/strong>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Soluci\u00f3n aplicada<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La soluci\u00f3n fue crear un <strong>portgroup ad-hoc<\/strong> destinado espec\u00edficamente al tr\u00e1fico del t\u00fanel.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">El objetivo era evitar que el tr\u00e1fico generado por la red de vApp de organizaci\u00f3n pudiera salir hacia el entorno f\u00edsico y regresar nuevamente hacia la interfaz del servidor.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Una consideraci\u00f3n importante: afinidad<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">El workaround resolv\u00eda el requerimiento, pero introduc\u00eda una consideraci\u00f3n operativa.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Las m\u00e1quinas virtuales que utilizaban esta red deb\u00edan permanecer dentro del <strong>mismo host ESXi<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Por esta raz\u00f3n fue necesario utilizar <strong>reglas de afinidad<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si una de estas VMs cambiaba de host, pod\u00eda perder conectividad con la red utilizada para el L2 extendido.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Esto significa que el workaround era funcional, pero tambi\u00e9n introduc\u00eda una dependencia con la ubicaci\u00f3n de las m\u00e1quinas virtuales dentro del cl\u00faster.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Y este es precisamente uno de esos puntos que debemos analizar antes de considerar un workaround como una soluci\u00f3n definitiva.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">\u00bfQu\u00e9 podemos aprender de este caso?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Una de las cosas m\u00e1s importantes durante un troubleshooting de red en virtualizaci\u00f3n es no quedarse \u00fanicamente con el primer mensaje de error.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando observamos algo como:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>vmnic down\nFailed criteria: 128<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">podr\u00edamos pensar inmediatamente en:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>NIC\nDriver\nFirmware\nSFP\nCable\nSwitch<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">y efectivamente todos esos componentes deben ser revisados.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Pero tambi\u00e9n tenemos que analizar:<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"562\" src=\"https:\/\/tecno-experts.com\/fransilvablog\/wp-content\/uploads\/2026\/08\/flujotroubleshootingcriteria128-1024x562.png\" alt=\"\" class=\"wp-image-112\" srcset=\"https:\/\/tecno-experts.com\/fransilvablog\/wp-content\/uploads\/2026\/08\/flujotroubleshootingcriteria128-1024x562.png 1024w, https:\/\/tecno-experts.com\/fransilvablog\/wp-content\/uploads\/2026\/08\/flujotroubleshootingcriteria128-300x165.png 300w, https:\/\/tecno-experts.com\/fransilvablog\/wp-content\/uploads\/2026\/08\/flujotroubleshootingcriteria128-767x421.png 767w, https:\/\/tecno-experts.com\/fransilvablog\/wp-content\/uploads\/2026\/08\/flujotroubleshootingcriteria128-1536x843.png 1536w, https:\/\/tecno-experts.com\/fransilvablog\/wp-content\/uploads\/2026\/08\/flujotroubleshootingcriteria128.png 1693w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">En ambientes donde tenemos <strong>Cloud Director + NSX + vSphere Networking + networking f\u00edsico<\/strong>, el troubleshooting debe realizarse de extremo a extremo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La frontera entre la red virtual y la f\u00edsica es precisamente donde muchos problemas pueden volverse dif\u00edciles de identificar.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Recomendaciones<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Despu\u00e9s de analizar este caso, considero importantes los siguientes puntos:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>1. Revisar siempre los logs antes de realizar cambios.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En este caso <code>vobd.log<\/code> permiti\u00f3 identificar el evento sobre la vmnic y el c\u00f3digo asociado.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>2. No interpretar Failed Criteria 128 como una causa ra\u00edz autom\u00e1tica.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">El c\u00f3digo nos indica que el driver report\u00f3 el enlace como DOWN. A partir de all\u00ed debemos determinar qu\u00e9 provoc\u00f3 ese cambio.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>3. Validar driver y firmware.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Utilizar las herramientas de ESXi y el Broadcom Compatibility Guide para comprobar la combinaci\u00f3n instalada.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>4. Revisar tambi\u00e9n la infraestructura f\u00edsica.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">SFP+, cableado, switchport y eventos registrados por el switch deben formar parte del troubleshooting.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>5. Entender completamente el flujo de tr\u00e1fico.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En este caso, seguir el recorrido del tr\u00e1fico permiti\u00f3 identificar que este estaba regresando hacia la NIC del servidor.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>6. Documentar las limitaciones de cualquier workaround.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Si una soluci\u00f3n requiere reglas de afinidad y evita que ciertas m\u00e1quinas virtuales puedan moverse libremente entre hosts, esa condici\u00f3n debe quedar claramente documentada.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>7. Evaluar alternativas nativas para L2VPN.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cuando sea posible, conviene evaluar mecanismos que eviten depender de configuraciones como Promiscuous Mode, Forged Transmits y MAC Address Changes. Para este ambiente, una de las recomendaciones del an\u00e1lisis fue evaluar la funcionalidad de <strong>L2VPN mediante NSX<\/strong>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusi\u00f3n<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Este caso comenz\u00f3 como un requerimiento para extender una red mediante L2VPN y termin\u00f3 convirti\u00e9ndose en un interesante troubleshooting entre networking virtual y networking f\u00edsico.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">El evento:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Failed criteria: 128<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">fue una pista importante, pero no era suficiente para determinar por s\u00ed solo la causa del problema.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La revisi\u00f3n completa del flujo permiti\u00f3 identificar que el tr\u00e1fico del L2 extendido estaba interactuando con la red f\u00edsica de una forma que terminaba afectando el uplink del servidor.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Finalmente, el uso de un <strong>portgroup espec\u00edfico para aislar este tr\u00e1fico<\/strong> permiti\u00f3 estabilizar la soluci\u00f3n, considerando adicionalmente las restricciones de afinidad requeridas por las m\u00e1quinas virtuales.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Como siempre, en virtualizaci\u00f3n no todo problema que aparece en ESXi necesariamente comienza en ESXi.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A veces hay que seguir el paquete.!!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>En este post revisaremos un caso real de troubleshooting durante la implementaci\u00f3n de una red L2 extendida mediante L2VPN. El tr\u00e1fico comenz\u00f3 a generar flapping sobre una vmnic de ESXi y en los logs apareci\u00f3 Failed Criteria: 128. Revisaremos el s\u00edntoma, las validaciones realizadas y el workaround utilizado para aislar el tr\u00e1fico dentro del entorno virtual.<\/p>\n","protected":false},"author":1,"featured_media":110,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[13,95,91,93,15,37,94,30,92],"class_list":["post-99","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-nsx","tag-esxi","tag-iaas","tag-l2vpn","tag-networking","tag-nsx","tag-troubleshooting","tag-vmnic","tag-vmwareclouddirector","tag-vsphere"],"_links":{"self":[{"href":"https:\/\/tecno-experts.com\/fransilvablog\/wp-json\/wp\/v2\/posts\/99","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tecno-experts.com\/fransilvablog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tecno-experts.com\/fransilvablog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tecno-experts.com\/fransilvablog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tecno-experts.com\/fransilvablog\/wp-json\/wp\/v2\/comments?post=99"}],"version-history":[{"count":6,"href":"https:\/\/tecno-experts.com\/fransilvablog\/wp-json\/wp\/v2\/posts\/99\/revisions"}],"predecessor-version":[{"id":113,"href":"https:\/\/tecno-experts.com\/fransilvablog\/wp-json\/wp\/v2\/posts\/99\/revisions\/113"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tecno-experts.com\/fransilvablog\/wp-json\/wp\/v2\/media\/110"}],"wp:attachment":[{"href":"https:\/\/tecno-experts.com\/fransilvablog\/wp-json\/wp\/v2\/media?parent=99"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tecno-experts.com\/fransilvablog\/wp-json\/wp\/v2\/categories?post=99"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tecno-experts.com\/fransilvablog\/wp-json\/wp\/v2\/tags?post=99"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}