text:
# Virtual Extensible LAN
VXLAN (Virtual Extensible Local Area Network) es un protocolo de superposición de redes ideado para transportar tráfico de capa de enlace de datos sobre la capa de red, concretamente tráfico Ethernet sobre redes IP empleando encapsulación MAC-in-UDP.
Inicialmente fue ideado para proveer los mismos servicios que una red VLAN convencional aumentando la extensibilidad y la flexibilidad limitadas de este tipo de redes.
Actualmente se encuentra documentado por el IETF en el RFC 7348 en estado "Informational".

## Introducción
VXLAN surgió como propuesta por parte de fabricantes como Cisco, Arista Networks, Broadcom, Intel, VMware y otros para evitar algunos de los problemas que se daban en los centros de datos derivados del empleo de virtualización en los servidores, lo que impone la necesidad de trabajar en entornos con cientos de miles de máquinas virtuales en algunos casos. Trabajar con tantas máquinas genera problemas relacionados con el tamaño de las tablas de direcciones MAC, y en el caso del empleo de VLANs para agrupar estas máquinas aislándolas en grupos surge el problema del número limitado de VLANs que se pueden generar debido al VLAN ID de 12 bits, que permite un máximo de 4094 redes diferentes.
Otro problema importante de los centros de datos proviene del empleo de STP (Spanning Tree Protocol) para evitar los bucles en la capa de enlace, lo que conlleva al desuso de una gran cantidad de los enlaces disponibles (En ocasiones más de la mitad) al generarse la topología en forma de árbol.
Todos estos problemas impulsaron el desarrollo de una tecnología de red que permitiese emplear una red IP para la interconexión de los servidores físicos, lo que supondría el uso de protocolos de enrutamiento de capa 3. De esta forma se eliminarían los problemas de desuso de enlaces impuestos por STP, los bucles de capa 2 y se podrían emplear "estrategias" de enrutamiento como Equal-cost multi-path routing (ECMP), que ayuda a distribuir la carga de la red entre todos los enlaces. A pesar de todo esto seguiría siendo necesario el empleo de una red de capa 2 para la comunicación directa entre las máquinas virtuales.
Esto impulsó finalmente la aparición de VXLAN, que nos permite eliminar los problemas de escalabilidad de la red derivados del uso de VLAN mediante el empleo de un identificador de red (VNI) de 24 bits, pudiendo crear así más de 16 millones de redes virtuales que coexistan en el mismo dominio administrativo. En VXLAN se emplea encaminamiento de capa 3, lo que elimina los problemas de desuso de enlaces mencionados anteriormente y permite un uso más eficiente de estos enlaces. El empleo de protocolos de encaminamiento de capa de red también elimina los problemas del tamaño excesivo que alcanzaban tablas de direcciones MAC en los switches que interconectaban una red de capa 2 en un centro de datos, los cuales tenían que almacenar las direcciones MAC de todas las máquinas virtuales instaladas en los servidores que se encontraban interconectados mediante ese switch.

## Encapsulación y formato de paquete VXLAN
VXLAN emplea encapsulación MAC Address-in-User Datagram Protocol (MAC-in-UDP).  Al paquete de Capa de enlace enviado inicialmente, que contiene las direcciones MAC del host origen y del host destino, se le añade una cabecera VXLAN. El conjunto anterior se introduce en el campo de datos de un datagrama UDP y se emplea IP como protocolo de Capa de red. Finalmente el paquete que se manda a la red IP tiene como direcciones MAC origen y destino las correspondientes a los VTEPs tras los cuales se encuentran los hosts origen y destino. De esta forma es posible encaminar el paquete inicial sobre una red IP, de manera que este pueda alcanzar a todos los hosts de la VXLAN de igual forma que si se encontrasen en la misma LAN.

### Componentes de VXLAN
Cabecera VXLAN: Tiene una longitud de 8 bytes y está compuesta por cuatro campos:
- Flags: Campo de 8 bits que contiene la secuencia de flags “R-R-R-R-I-R-R-R”. El flag denominado “I” debe contener el valor “1” para indicar un VNI válido. El resto de bits (“R”) deben contener el valor “0” a la hora de transmitir la trama y son ignorados en la recepción.
- VXLAN Network Identifier (VNI o VNID): Se trata de un campo de 24 bits mediante el cual se identifica cada red de “Overlay”, lo que nos permite crear más de 16 millones de segmentos VXLAN en el mismo dominio administrativo. Cada VXLAN tiene un VNI diferente y cada máquina perteneciente a una VXLAN está identificada por su MAC y por su VNI, por lo que es posible tener máquinas con direcciones MAC duplicadas en distintas redes VXLAN.
- Campos reservados: Existen dos campos reservados en la cabecera VXLAN. Uno de ellos está situado entre el campo de flags y el campo VNI y el otro se encuentra situado al final de la cabecera VXLAN. Estos campos tienen una longitud de 24 y 8 bits respectivamente, ambos deben ser enviados con valor "0" y son ignorados en la recepción del paquete.[4][5]

VXLAN Tunnel End Point (VTEP): Se trata de una entidad que origina y termina “túneles”  VXLAN, y es la encargada de encapsular las tramas Ethernet de cada red física perteneciente a una VXLAN para transportarlas sobre una red IP hacia el resto de VTEPs pertenecientes al grupo multicast de la red virtual. De igual forma se encarga de desencapsular los paquetes IP recibidos y almacena las tablas de encaminamiento necesarias para la comunicación entre los hosts conectados a ese VTEP y el resto de hosts de la red virtual.
Cada VTEP tiene al menos dos interfaces: Una de ellas es la interfaz para el segmento de área local y se encarga de proveer servicio a los sistemas finales que están directamente conectados al VTEP. La otra es una interfaz IP que se encarga de encapsular las tramas del segmento de área local para poder transmitirlas sobre una red IP hacia el resto de VTEPs pertenecientes a la red virtual. Para ello es necesario que todos los dispositivos VTEP de una misma VXLAN se unan a un grupo multicast mediante el protocolo IGMP (Internet Group Management Protocol).
Al emplearse encaminamiento basado en la dirección IP externa de cada VTEP las diferentes redes locales físicas que forman una red VXLAN son independientes a la topología que las une y pueden comunicarse entre ellas como si se encontrasen en la misma red física.
VXLAN Gateways: Se trata de un dispositivo VTEP que permite la comunicación entre nodos que soportan y que no soportan el protocolo VXLAN. De esta manera los dispositivos que no soporten esta tecnología pueden permanecer en segmentos VLAN clásicos y emplear un VXLAN Gateway para formar un dominio común de capa de enlace con una red VXLAN. Un VXLAN Gateway también puede ofrecer servicios avanzados de conectividad y seguridad a la red VXLAN, como por ejemplo proporcionando funcionalidades de NAT (dando acceso hacia la red exterior), actuando como Firewall, servidor DHCP y DNS entre otras cosas.
Para formar un paquete VXLAN también son necesarias las siguientes cabeceras:
- Cabecera externa UDP que contenga el puerto origen del VTEP y el puerto destino (Definido por el IANA el puerto 4789 como puerto UDP por defecto en VXLAN).[8]
- Una cabecera externa IP que contenga las direcciones IP del VTEP origen y del VTEP destino necesarias para encaminar el paquete sobre la red IP. La dirección IP destino puede ser una dirección unicast o multicast dependiendo de si el VTEP origen conoce o no la dirección del VTEP al que pertenece el dispositivo al que va dirigido el paquete.
- Cabecera externa Ethernet que contiene las direcciones MAC origen y destino de los VTEP para que puedan comunicarse entre ellos.[9]

Tanto la cabecera UDP como IP proporcionan adicionalmente un campo checksum para verificar la integridad de los datos del paquete.
Por último, para establecer una red VXLAN es necesario que la red IP sobre la que se encaminen los paquetes soporte funcionalidades de encaminamiento multicast como IGMP y PIM, protocolos de encaminamiento como OSPF y BGP y protocolos de estado de enlace como IS-IS.

## Funcionamiento de VXLAN
El funcionamiento de VXLAN se basa principalmente en encapsular el tráfico de capa de enlace de una red de área local y transportarlo sobre una red IP hasta otra LAN física diferente, consiguiendo así que los hosts de ambas redes se puedan comunicar de igual manera que si se encontrasen en la misma red de área local. Para conseguir esto se emplean “túneles” entre los distintos VTEPs por los cuales se transmite el tráfico de “overlay”, de forma que este llegue al otro extremo en el mismo estado en el que se encontraba en la red LAN origen.
En cada red LAN los hosts pertenecientes a la VXLAN se encuentran conectados a un VTEP. Este dispositivo será el encargado de encapsular las tramas de los hosts de un segmento VXLAN y encaminarlas por la red IP para que lleguen al resto de dispositivos de la VXLAN.
Cada segmento VXLAN está identificado por su VNI (VXLAN Network Identifier). Sobre la base de este VNI el VTEP se encargará de que los paquetes solo sean enviadas a los hosts que pertenezcan a un mismo segmento VXLAN. Para ello se emplea el protocolo IGMP, todos los VTEP de un mismo segmento VXLAN se suscriben a un grupo multicast, de manera que solo se envíen entre ellos los paquetes relativos a ese segmento VXLAN.
Cada vez que un host de la VXLAN envía una trama cuyo destino es otro host del mismo segmento VXLAN: el VTEP encapsula la trama añadiéndole las cabeceras correspondientes y lo envía sobre la red IP de manera que alcance el VTEP tras el cual se encuentra el host destino.
Para realizar el encaminamiento sobre la red IP cada VTEP almacena en sus tablas de encaminamiento la correspondencia de cada MAC de un host con la IP del VTEP al que le debe enviar el paquete si quiere alcanzar dicho host. Esto hace que se puedan producir dos situaciones distintas a la hora de querer enviar un paquete a un host:
- El VTEP tiene almacenadas en sus tablas la IP del VTEP y la MAC del host destino: En este caso la comunicación es unicast y por tanto el VTEP origen envía la trama directamente al VTEP destino.
- El VTEP no conoce la correspondencia de la dirección MAC del host destino con la IP del VTEP destino: En este caso se lleva a cabo un envío multicast, de manera que el VTEP manda el paquete a todos los VTEP que pertenezcan a ese segmento VXLAN con el objetivo de alcanzar finalmente al host destino.

En el caso de emplear la comunicación multicast cada VTEP involucrado en la comunicación almacenará en sus tablas las direcciones correspondientes a ese intercambio de paquetes, de forma que los próximos paquetes podrán ser enviados empleando una comunicación unicast.

### Comunicación Unicast:[11][12][13]

#### Ejemplo de comunicación unicast en VXLAN
Basándonos en un esquema como el de la Figura 1, en el que existen dos hosts dentro de un mismo segmento VXLAN, encontrándose estos en diferentes redes de área local, y suponiendo que ambas máquinas conocen de antemano las direcciones de la otra máquina y cada VTEP sabe cómo comunicarse con el otro VTEP. Si uno de los hosts intentase comunicarse con el otro se seguiría la secuencia siguiente:
1. El Host-A envía sobre la red de área local una trama MAC cuya dirección MAC destino es la del Host-B, de igual manera que lo haría en un escenario LAN normal.
2. El VTEP-1 recibe la trama y comprueba el VNI que el Host-A tiene asociado. Tras esto se determina si la dirección MAC destino se encuentra en el mismo segmento de red o si existe una entrada en las tablas de encaminamiento que relacione esta dirección MAC con la de otro VTEP en cuya red física se encuentra la máquina destino.
3. El VTEP-1 encuentra en sus tablas que la dirección del Host-B se encuentra asignada a la dirección IP del VTEP-2. Por lo tanto añade a la trama original una cabecera VXLAN con el VNI de la red virtual a la que pertenecen los hosts, una cabecera IP con las direcciones IP externas del VTEP-1 y VTEP-2 como origen y destino respectivamente, y una cabecera MAC externa que contiene las direcciones MAC origen y destino de los VTEP. Finalmente reenvía la trama por la red IP hacia el VTEP-2.
4. El VTEP-2 recibe la trama y verifica si el VNI de la cabecera VXLAN es válido y si existe algún host en su red física que pertenezca a esa VXLAN y tenga como dirección MAC la dirección destino del paquete encapsulado en la trama recibida.
5. El VTEP-2 encuentra que el Host-B coincide con estos datos y por tanto desencapsula la trama recibida eliminando las cabeceras externas y reenvía el paquete al Host-B.
6. Adicionalmente el VTEP-2 aprende la relación entre la dirección MAC origen interna (Dirección del Host-A) y la dirección IP externa (Dirección del VTEP-1) y las guarda en su tabla de encaminamiento. De esta forma cuando el Host-B responda al mensaje no será necesario descubrir la correspondencia del Host-A con el VTEP-1.

En todo el proceso no es necesario que ninguno de los hosts sea consciente de que se está comunicando con una máquina que no se encuentra en su red física. Los hosts tampoco tienen por qué saber que forman parte de una VXLAN. El VTEP almacena el VNI correspondiente a cada host al que se encuentra conectado y por lo tanto es capaz de enviar los paquetes de un determinado host a otro de la red virtual a la que pertenece sin que ninguno de los puntos finales tenga que llevar a cabo un comportamiento distinto al que tendría en una red LAN clásica.

### Comunicación multicast:[14][15]
Consideraremos en este caso que la máquina que intenta comunicarse con otra no conoce la correspondencia MAC con IP destino y que el VTEP encargado de encaminar el paquete IP no tiene en sus tablas de encaminamiento la información necesaria para saber a que VTEP le tiene que reenviar la trama para que esta llegue al dispositivo destino. Para evitar inundar la red IP con tráfico broadcast se emplea tráfico multicast, de esta manera solo se envían paquetes a los VTEP que pertenecen a un grupo multicast determinado.
Dado que el dispositivo origen no conoce la MAC destino enviará una trama ARP request usando como dirección MAC destino la dirección de broadcast. El VTEP recibirá la trama, le añadirá la cabecera VXLAN conteniendo el VNI correspondiente a la red junto con las cabeceras IP y UDP y reenviará la trama al grupo multicast al que pertenece la red VXLAN.
Los VTEP pertenecientes al grupo multicast recibirán la trama y la reenviarán a sus redes locales, por lo que esta alcanzará finalmente al host destino. En todo el proceso los diferentes dispositivos intermedios habrán almacenado en sus tablas de encaminamiento todas las direcciones necesarias para poder comunicarse con el host origen, por lo tanto a la hora de encaminar la respuesta (ARP reply) se empleará una dirección IP unicast como destino.
Para que todo esto funcione es necesario que cada VTEP conozca la relación del VNI con el grupo multicast al que pertenece, lo que se consigue configurando cada VTEP por separado mediante un canal de administración. De esta manera un VTEP puede informar a su router de salida a la red IP sobre la unión a un nuevo grupo multicast o la salida de uno empleando el protocolo IGMP, lo que puede resultar interesante en un entorno en el que al VTEP se conectan y desconectan con frecuencia máquinas pertenecientes a distintos segmentos VXLAN. Un ejemplo práctico es la movilidad de las máquinas virtuales de un centro de datos.
Como protocolo de encaminamiento entre los miembros del grupo multicast se emplea PIM (Protocol Independent Multicast). Cabe mencionar que algunas de las implementaciones de VXLAN permiten a los VTEPs pertenecer a varios grupos multicast diferentes a la vez.

#### Ejemplo de comunicación multicast en VXLAN
En el esquema de la Figura 2 se pueden apreciar tres VTEP pertenecientes al mismo grupo multicast, lo que limitará la inundación de tramas a los dispositivos pertenecientes al mismo segmento VXLAN evitando así congestionar el resto de la red.
Secuencia de comunicación multicast en la que el Host-A quiere comunicarse con el Host-B basándonos en el esquema de la Figura 2:
1. El Host-A quiere comunicarse con el Host-B, pero no conoce su dirección MAC. Envía por tanto un ARP request con dirección destino IP-B sobre su red VXLAN de capa dos con el propósito de recibir un ARP reply por parte del Host-B del cual pueda aprender su dirección MAC.
2. El VTEP-1 recibe la trama y comprueba si conoce la correspondencia de la IP-B con la IP del VTEP tras el que se encuentra esta dirección. Como no la conoce encapsula la petición ARP en un paquete IP multicast y lo envía al grupo multicast de la red VXLAN. El paquete IP multicast tiene como dirección IP origen la del VTEP-1 y como dirección destino la del grupo multicast al que pertenece la VXLAN.
3. El paquete llega a todos los VTEPs que pertenecen al grupo multicast. Todos ellos desencapsulan el paquete y comprueban el VNI de la cabecera VXLAN. Como el VNI coincide con el de su segmento VXLAN los VTEP reenvían la petición ARP a sus redes de área local. Durante el proceso cada VTEP del grupo multicast aprende la dirección IP del VTEP-1 que contiene la cabecera IP externa, e inspeccionan la cabecera interna para aprender la dirección MAC del Host-A. Finalmente guardan esta correspondencia en sus tablas de direcciones.
4. El Host-B recibe el ARP request que le ha enviado el VTEP-2 y responde a la petición con un ARP reply que contiene su dirección MAC. En el proceso el Host-B ha aprendido la dirección MAC del Host-A, por lo que la dirección MAC destino ya no es la de broadcast.
5. El VTEP-2 recibe la respuesta del Host-B. Ahora conoce la correspondencia de la MAC del Host-A con la IP del VTEP-1, por lo que encapsula el paquete del Host-B y lo reenvía como un paquete unicast hacia el VTEP-1. Este paquete tiene como dirección IP origen la del VTEP-2.
6. El VTEP-1 recibe la respuesta ARP encapsulada enviada por el VTEP-2 y aprende su dirección IP de la cabecera IP externa. Desencapsula el paquete y reenvía la respuesta ARP al Host-A.
7. El Host-A recibe el ARP reply y aprende la dirección MAC del Host-B, por lo que ya se puede comunicar con este host.

Los siguientes paquetes que se envíen entre los Hosts A y B serán reenviados como paquetes unicast por los VTEPs 1 y 2 debido a que estos han aprendido las direcciones necesarias para no tener que volver a emplear reenvío multicast. De manera opcional, dado que los VTEPs 1 y 2 han aprendido las direcciones MAC de los hosts B y A respectivamente pueden actuar como Proxy ARP, evitando así nuevas peticiones de las MAC de estos dos hosts.

## Consideraciones de seguridad
Por norma general una red local de capa de enlace solo puede ser atacada por un nodo malicioso que se encuentre dentro de la red. En el caso de una red VXLAN el hecho de transportar el tráfico de capa dos sobre una red IP hace que la red sea susceptible a ser atacada por nodos maliciosos que no pertenezcan a la red local.
Un posible peligro es que un atacante se suscriba al grupo multicast de un segmento VXLAN y por tanto pueda recibir el tráfico multicast enviado por la red o insertar paquetes con destino ese grupo multicast en la red de transporte.
Para aumentar la seguridad de la red de transporte se proponen medidas como el empleo de IPsec en los paquetes que se envían por la red, lo que permite autenticar y cifrar el tráfico VXLAN, impidiendo así los problemas mencionados anteriormente.
Otra recomendación para el aumento de la seguridad en el ámbito local de una VXLAN es designar una VLAN sobre la que se envíe el tráfico VXLAN que se genera entre los VTEPs y los hosts de la red local. De esta manera solo los hosts configurados para pertenecer a la VLAN tendrán acceso al tráfico VXLAN de la red de área local, a diferencia de si se emplease una LAN clásica. También sería necesario tener un buen control por parte de una entidad administrativa de los hosts que pertenecen a la red LAN.

title: Virtual Extensible LAN

wikitext:
'''VXLAN''' ('''Virtual Extensible Local Area Network''') es un protocolo de [[Overlay network|superposición de redes]] ideado para transportar tráfico de [[capa de enlace de datos]] sobre la [[capa de red]], concretamente tráfico [[Ethernet]] sobre redes [[Internet Protocol|IP]] empleando encapsulación ''MAC-in-UDP''.
Inicialmente fue ideado para proveer los mismos servicios que una red [[VLAN]] convencional aumentando la extensibilidad y la flexibilidad limitadas de este tipo de redes.

Actualmente se encuentra documentado por el IETF en el RFC 7348 en estado ''[[Request for Comments#.22Informational.22|"Informational"]]''.

== Introducción ==

VXLAN surgió como propuesta por parte de fabricantes como [[Cisco]], [[Arista Networks]], [[Broadcom]], [[Intel]], [[VMware]]<ref>{{cite web |url=http://www.theregister.co.uk/2011/08/30/vmware_cisco_vxlan_spec/ |title=VMware, Cisco stretch virtual LANs across the heavens |author=Timothy Prickett Morgan |publisher=The Register |date=30 de agosto de 2011 |accessdate=20 de noviembre de 2016}}</ref><ref>{{cite web |url=http://www.aristanetworks.com/media/system/pdf/TechBulletins/VXLAN_Overview.pdf |title=Arista and VMware have coauthored a new standard in cloud networking: the Virtual eXtensible LAN (VXLAN) |accessdate=20 de noviembre de 2016}}</ref> y otros para evitar algunos de los problemas que se daban en los centros de datos derivados del empleo de [[Servidor virtual|virtualización en los servidores]], lo que impone la necesidad de trabajar en entornos con cientos de miles de máquinas virtuales en algunos casos. Trabajar con tantas máquinas genera problemas relacionados con el tamaño de las tablas de direcciones MAC, y en el caso del empleo de [[Virtual LAN|VLANs]] para agrupar estas máquinas aislándolas en grupos surge el problema del número limitado de VLANs que se pueden generar debido al ''VLAN ID'' de 12 bits, que permite un máximo de 4094 redes diferentes.

Otro problema importante de los centros de datos proviene del empleo de [[Spanning tree|STP]] (Spanning Tree Protocol) para evitar los bucles en la [[Capa de enlace de datos|capa de enlace]], lo que conlleva al desuso de una gran cantidad de los enlaces disponibles (En ocasiones más de la mitad) al generarse la topología en forma de árbol.

Todos estos problemas impulsaron el desarrollo de una tecnología de red que permitiese emplear una red IP para la interconexión de los servidores físicos, lo que supondría el uso de protocolos de enrutamiento de [[Capa de red|capa 3]]. De esta forma se eliminarían los problemas de desuso de enlaces impuestos por [[Spanning tree|STP]], los bucles de [[Capa de enlace de datos|capa 2]] y se podrían emplear "''estrategias''" de enrutamiento como [[Equal-cost multi-path routing]] (ECMP), que ayuda a distribuir la carga de la red entre todos los enlaces.<ref name="9e774c73">{{cite web |url=http://www.cisco.com/c/en/us/products/collateral/switches/nexus-5000-series-switches/white-paper-c11-733618.html |title=Virtual Extensible LAN (VXLAN) Best Practices White Paper |accessdate=20 de noviembre de 2016}}</ref> A pesar de todo esto seguiría siendo necesario el empleo de una red de capa 2 para la comunicación directa entre las máquinas virtuales.

Esto impulsó finalmente la aparición de VXLAN, que nos permite eliminar los problemas de escalabilidad de la red derivados del uso de VLAN mediante el empleo de un identificador de red ('''VNI''') de 24 bits, pudiendo crear así más de 16 millones de redes virtuales que coexistan en el mismo dominio administrativo.<ref name="9e774c73" /> En VXLAN se emplea encaminamiento de capa 3, lo que elimina los problemas de desuso de enlaces mencionados anteriormente y permite un uso más eficiente de estos enlaces. El empleo de protocolos de encaminamiento de capa de red también elimina los problemas del tamaño excesivo que alcanzaban tablas de direcciones MAC en los [[Conmutador (dispositivo de red)|switches]] que interconectaban una red de capa 2 en un centro de datos, los cuales tenían que almacenar las direcciones MAC de todas las máquinas virtuales instaladas en los servidores que se encontraban interconectados mediante ese switch.

== Encapsulación y formato de paquete VXLAN ==

'''VXLAN''' emplea encapsulación ''MAC Address-in-User Datagram Protocol'' (MAC-in-UDP).  Al paquete de [[Capa de enlace]] enviado inicialmente, que contiene las direcciones MAC del host origen y del host destino, se le añade una cabecera VXLAN. El conjunto anterior se introduce en el campo de datos de un datagrama [[UDP]] y se emplea [[Internet Protocol|IP]] como protocolo de [[Capa de red]]. Finalmente el paquete que se manda a la red IP tiene como direcciones MAC origen y destino las correspondientes a los VTEPs tras los cuales se encuentran los hosts origen y destino. De esta forma es posible encaminar el paquete inicial sobre una red IP, de manera que este pueda alcanzar a todos los hosts de la VXLAN de igual forma que si se encontrasen en la misma LAN.
[[Archivo:Paquete-encapsulado.png|marco|centro|Encapsulación VXLAN]]

===Componentes de VXLAN===
[[Archivo:Cabecera-VXLAN.png|300px|miniaturadeimagen|derecha|Cabecera VXLAN]]
'''Cabecera VXLAN:''' Tiene una longitud de 8 bytes y está compuesta por cuatro campos:
* Flags: Campo de 8 bits que contiene la secuencia de flags “R-R-R-R-I-R-R-R”. El flag denominado “I” debe contener el valor “1” para indicar un VNI válido. El resto de bits (“R”) deben contener el valor “0” a la hora de transmitir la trama y son ignorados en la recepción.
* VXLAN Network Identifier ('''VNI''' o '''VNID'''): Se trata de un campo de 24 bits mediante el cual se identifica cada red de “[[Red superpuesta |Overlay]]”, lo que nos permite crear más de 16 millones de segmentos VXLAN en el mismo dominio administrativo. Cada VXLAN tiene un VNI diferente y cada máquina perteneciente a una VXLAN está identificada por su MAC y por su VNI, por lo que es posible tener máquinas con direcciones MAC duplicadas en distintas redes VXLAN.
* Campos reservados: Existen dos campos reservados en la cabecera VXLAN. Uno de ellos está situado entre el campo de flags y el campo VNI y el otro se encuentra situado al final de la cabecera VXLAN. Estos campos tienen una longitud de 24 y 8 bits respectivamente, ambos deben ser enviados con valor "0" y son ignorados en la recepción del paquete.<ref>{{cite web |url=https://vcloudopia.wordpress.com/2014/09/11/vxlan-conceptos-funcionamiento-e-implementacion-12/ |  title=VXLAN: conceptos, funcionamiento e implementación (1/2)  |accessdate=26 de noviembre de 2016}}</ref><ref>{{cite web |url=http://www.cisco.com/c/en/us/products/collateral/switches/nexus-5000-series-switches/white-paper-c11-733618.html#_Toc439799766 |  title=VXLAN Encapsulation and Packet Format  |accessdate=26 de noviembre de 2016}}</ref>

'''VXLAN Tunnel End Point (VTEP):''' Se trata de una entidad que origina y termina ''“túneles”''  VXLAN, y es la encargada de encapsular las tramas [[Ethernet]] de cada red física perteneciente a una VXLAN para transportarlas sobre una red IP hacia el resto de VTEPs pertenecientes al grupo multicast de la red virtual. De igual forma se encarga de desencapsular los paquetes IP recibidos y almacena las tablas de encaminamiento necesarias para la comunicación entre los hosts conectados a ese VTEP y el resto de hosts de la red virtual.

Cada VTEP tiene al menos dos interfaces: Una de ellas es la interfaz para el segmento de área local y se encarga de proveer servicio a los sistemas finales que están directamente conectados al VTEP. La otra es una interfaz IP que se encarga de encapsular las tramas del segmento de área local para poder transmitirlas sobre una red IP hacia el resto de VTEPs pertenecientes a la red virtual. Para ello es necesario que todos los dispositivos VTEP de una misma VXLAN se unan a un grupo multicast mediante el protocolo [[IGMP]] (Internet Group Management Protocol).
Al emplearse encaminamiento basado en la [[dirección IP]] externa de cada VTEP las diferentes redes locales físicas que forman una red VXLAN son independientes a la topología que las une y pueden comunicarse entre ellas como si se encontrasen en la misma red física.<ref>{{cite web |url=http://hispavirt.com/2013/01/02/entendiendo-vxlan/ |title=Entendiendo VXLAN |accessdate=26 de noviembre de 2016 |urlarchivo=https://web.archive.org/web/20161127022827/http://hispavirt.com/2013/01/02/entendiendo-vxlan/ |fechaarchivo=27 de noviembre de 2016 }}</ref>

'''VXLAN Gateways:''' Se trata de un dispositivo VTEP que permite la comunicación entre nodos que soportan y que no soportan el protocolo VXLAN. De esta manera los dispositivos que no soporten esta tecnología pueden permanecer en segmentos [[VLAN]] clásicos y emplear un ''VXLAN Gateway'' para formar un dominio común de [[capa de enlace]] con una red VXLAN. Un ''VXLAN Gateway'' también puede ofrecer servicios avanzados de conectividad y seguridad a la red VXLAN, como por ejemplo proporcionando funcionalidades de NAT (dando acceso hacia la red exterior), actuando como Firewall, servidor DHCP y DNS entre otras cosas.<ref>{{cite web |url=https://tools.ietf.org/html/rfc7348#section-6| author= M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright | title=RFC7348: Section 6: VXLAN Deployment Scenarios | date=August 2014 |accessdate=26 de noviembre de 2016}}</ref>

Para formar un paquete VXLAN también son necesarias las siguientes cabeceras:

* Cabecera externa [[UDP]] que contenga el puerto origen del VTEP y el puerto destino (Definido por el IANA el puerto 4789 como puerto UDP por defecto en VXLAN).<ref>{{cite web |url=https://tools.ietf.org/html/rfc7348#section-5 | author= M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright | title=RFC7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks  | date=August 2014 |accessdate=26 de noviembre de 2016}}</ref>
* Una cabecera externa IP que contenga las direcciones IP del VTEP origen y del VTEP destino necesarias para encaminar el paquete sobre la red IP. La dirección IP destino puede ser una dirección unicast o multicast dependiendo de si el VTEP origen conoce o no la dirección del VTEP al que pertenece el dispositivo al que va dirigido el paquete.
* Cabecera externa [[Ethernet]] que contiene las direcciones MAC origen y destino de los VTEP para que puedan comunicarse entre ellos.<ref>{{cite web |url=https://tools.ietf.org/html/rfc7348#section-5| author= M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright | title=RFC7348: Section 5:  VXLAN Frame Format | date=August 2014 |accessdate=26 de noviembre de 2016}}</ref>

Tanto la cabecera UDP como IP proporcionan adicionalmente un campo [[suma de control|checksum]] para verificar la integridad de los datos del paquete.

Por último, para establecer una red VXLAN es necesario que la red IP sobre la que se encaminen los paquetes soporte funcionalidades de encaminamiento multicast como [[IGMP]] y [[Protocol Independent Multicast|PIM]], protocolos de encaminamiento como [[OSPF]] y [[BGP]] y protocolos de estado de enlace como [[IS-IS]].

== Funcionamiento de VXLAN ==

El funcionamiento de VXLAN se basa principalmente en encapsular el tráfico de [[capa de enlace]] de una [[red de área local]] y transportarlo sobre una red IP hasta otra LAN física diferente, consiguiendo así que los hosts de ambas redes se puedan comunicar de igual manera que si se encontrasen en la misma red de área local. Para conseguir esto se emplean ''“túneles”'' entre los distintos VTEPs por los cuales se transmite el tráfico de ''“overlay”'', de forma que este llegue al otro extremo en el mismo estado en el que se encontraba en la red LAN origen.
[[Archivo:VXLAN-Tunnel.png|400px|miniaturadeimagen|derecha|Túnel entre dos VTEP]]

En cada red LAN los hosts pertenecientes a la VXLAN se encuentran conectados a un VTEP. Este dispositivo será el encargado de encapsular las tramas de los hosts de un segmento VXLAN y encaminarlas por la red IP para que lleguen al resto de dispositivos de la VXLAN.

Cada segmento VXLAN está identificado por su VNI (VXLAN Network Identifier). Sobre la base de este VNI el VTEP se encargará de que los paquetes solo sean enviadas a los hosts que pertenezcan a un mismo segmento VXLAN. Para ello se emplea el protocolo [[IGMP]], todos los VTEP de un mismo segmento VXLAN se suscriben a un grupo [[multicast]], de manera que solo se envíen entre ellos los paquetes relativos a ese segmento VXLAN.

Cada vez que un host de la VXLAN envía una trama cuyo destino es otro host del mismo segmento VXLAN: el VTEP encapsula la trama añadiéndole las cabeceras correspondientes y lo envía sobre la red IP de manera que alcance el VTEP tras el cual se encuentra el host destino.

Para realizar el encaminamiento sobre la red IP cada VTEP almacena en sus tablas de encaminamiento la correspondencia de cada MAC de un host con la IP del VTEP al que le debe enviar el paquete si quiere alcanzar dicho host. Esto hace que se puedan producir dos situaciones distintas a la hora de querer enviar un paquete a un host:
*El VTEP tiene almacenadas en sus tablas la IP del VTEP y la MAC del host destino: En este caso la comunicación es [[unicast]] y por tanto el VTEP origen envía la trama directamente al VTEP destino.
*El VTEP no conoce la correspondencia de la dirección MAC del host destino con la IP del VTEP destino: En este caso se lleva a cabo un envío [[multicast]], de manera que el VTEP manda el paquete a todos los VTEP que pertenezcan a ese segmento VXLAN con el objetivo de alcanzar finalmente al host destino.

En el caso de emplear la comunicación multicast cada VTEP involucrado en la comunicación almacenará en sus tablas las direcciones correspondientes a ese intercambio de paquetes, de forma que los próximos paquetes podrán ser enviados empleando una comunicación unicast.<ref>{{cite web |url=https://tools.ietf.org/html/rfc7348#section-4| author= M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright | title=RFC7348: Section 4: VXLAN | date=August 2014 |accessdate=3 de diciembre de 2016}}</ref>

=== Comunicación Unicast:<ref>{{cite web |url=https://www.arista.com/assets/data/pdf/Whitepapers/VXLAN_Scaling_Data_Center_Designs.pdf| author=Arista Networks, | title=VXLAN Overview |  |accessdate=27 de noviembre de 2016}}</ref><ref>{{cite web | url=http://patriciocerda.com/2015/11/nsx-modos-de-replicacion-vxlan.html | author=Patricio Cerda | title=NSX: Modos de replicación VXLAN | date=9 de noviembre de 2016 | accessdate=27 de noviembre de 2016 | urlarchivo=https://web.archive.org/web/20161202233855/http://patriciocerda.com/2015/11/nsx-modos-de-replicacion-vxlan.html | fechaarchivo=2 de diciembre de 2016 }}</ref><ref>{{cite web |url=https://tools.ietf.org/html/rfc7348#section-4.1| author= M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright | title=RFC7348: Section 4.1: Unicast VM-to-VM Communication | date=August 2014 |accessdate=27 de noviembre de 2016}}</ref> ===
==== Ejemplo de comunicación unicast en VXLAN ====

Basándonos en un esquema como el de la ''Figura 1'', en el que existen dos hosts dentro de un mismo segmento VXLAN, encontrándose estos en diferentes redes de área local, y suponiendo que ambas máquinas conocen de antemano las direcciones de la otra máquina y cada VTEP sabe cómo comunicarse con el otro VTEP. Si uno de los hosts intentase comunicarse con el otro se seguiría la secuencia siguiente:
[[Archivo:VXLAN-Unicast-2.png|450px|thumb|izquierda|Figura 1: Ejemplo de red VXLAN con reenvío unicast]]

#El Host-A envía sobre la red de área local una trama MAC cuya dirección MAC destino es la del Host-B, de igual manera que lo haría en un escenario LAN normal.
#El VTEP-1 recibe la trama y comprueba el VNI que el Host-A tiene asociado. Tras esto se determina si la dirección MAC destino se encuentra en el mismo segmento de red o si existe una entrada en las tablas de encaminamiento que relacione esta dirección MAC con la de otro VTEP en cuya red física se encuentra la máquina destino.
#El VTEP-1 encuentra en sus tablas que la dirección del Host-B se encuentra asignada a la dirección IP del VTEP-2. Por lo tanto añade a la trama original una cabecera VXLAN con el VNI de la red virtual a la que pertenecen los hosts, una cabecera IP con las direcciones IP externas del VTEP-1 y VTEP-2 como origen y destino respectivamente, y una cabecera MAC externa que contiene las direcciones MAC origen y destino de los VTEP. Finalmente reenvía la trama por la red IP hacia el VTEP-2.
#El VTEP-2 recibe la trama y verifica si el VNI de la cabecera VXLAN es válido y si existe algún host en su red física que pertenezca a esa VXLAN y tenga como dirección MAC la dirección destino del paquete encapsulado en la trama recibida.
#El VTEP-2 encuentra que el Host-B coincide con estos datos y por tanto desencapsula la trama recibida eliminando las cabeceras externas y reenvía el paquete al Host-B.
#Adicionalmente el VTEP-2 aprende la relación entre la dirección MAC origen interna (Dirección del Host-A) y la dirección IP externa (Dirección del VTEP-1) y las guarda en su tabla de encaminamiento. De esta forma cuando el Host-B responda al mensaje no será necesario descubrir la correspondencia del Host-A con el VTEP-1.

En todo el proceso no es necesario que ninguno de los hosts sea consciente de que se está comunicando con una máquina que no se encuentra en su red física. Los hosts tampoco tienen por qué saber que forman parte de una VXLAN. El VTEP almacena el VNI correspondiente a cada host al que se encuentra conectado y por lo tanto es capaz de enviar los paquetes de un determinado host a otro de la red virtual a la que pertenece sin que ninguno de los puntos finales tenga que llevar a cabo un comportamiento distinto al que tendría en una red LAN clásica.

=== Comunicación multicast:<ref>{{cite web |url=http://www.cisco.com/c/en/us/products/collateral/switches/nexus-5000-series-switches/white-paper-c11-733618.html#_Toc439799770|author=Cisco |title=Layer 2 Mechanisms for Broadcast, Unknown Unicast, and Multicast Traffic |accessdate=2 de diciembre de 2016}}</ref><ref>{{cite web |url=https://tools.ietf.org/html/rfc7348#section-4.2| author= M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright | title=RFC7348: Section 4.2: Broadcast Communication and Mapping to Multicast| date=August 2014 |accessdate=2 de diciembre de 2016}}</ref> ===
Consideraremos en este caso que la máquina que intenta comunicarse con otra no conoce la correspondencia MAC con IP destino y que el VTEP encargado de encaminar el paquete IP no tiene en sus tablas de encaminamiento la información necesaria para saber a que VTEP le tiene que reenviar la trama para que esta llegue al dispositivo destino. Para evitar inundar la red IP con tráfico [[Difusión amplia|broadcast]] se emplea tráfico [[multicast]], de esta manera solo se envían paquetes a los VTEP que pertenecen a un grupo multicast determinado.

Dado que el dispositivo origen no conoce la MAC destino enviará una trama ''[[Protocolo de resolución de direcciones|ARP]] request'' usando como dirección MAC destino la dirección de broadcast. El VTEP recibirá la trama, le añadirá la cabecera VXLAN conteniendo el VNI correspondiente a la red junto con las cabeceras IP y UDP y reenviará la trama al grupo [[multicast]] al que pertenece la red VXLAN.

Los VTEP pertenecientes al grupo multicast recibirán la trama y la reenviarán a sus redes locales, por lo que esta alcanzará finalmente al host destino. En todo el proceso los diferentes dispositivos intermedios habrán almacenado en sus tablas de encaminamiento todas las direcciones necesarias para poder comunicarse con el host origen, por lo tanto a la hora de encaminar la respuesta (''ARP reply'') se empleará una dirección IP unicast como destino.

Para que todo esto funcione es necesario que cada VTEP conozca la relación del VNI con el grupo multicast al que pertenece, lo que se consigue configurando cada VTEP por separado mediante un canal de administración. De esta manera un VTEP puede informar a su [[router]] de salida a la red IP sobre la unión a un nuevo grupo multicast o la salida de uno empleando el protocolo [[IGMP]], lo que puede resultar interesante en un entorno en el que al VTEP se conectan y desconectan con frecuencia máquinas pertenecientes a distintos segmentos VXLAN. Un ejemplo práctico es la movilidad de las máquinas virtuales de un centro de datos.

Como protocolo de encaminamiento entre los miembros del grupo multicast se emplea [[Protocol Independent Multicast|PIM]] (Protocol Independent Multicast). Cabe mencionar que algunas de las implementaciones de VXLAN permiten a los VTEPs pertenecer a varios grupos multicast diferentes a la vez.
==== Ejemplo de comunicación multicast en VXLAN ====

En el esquema de la ''Figura 2'' se pueden apreciar tres VTEP pertenecientes al mismo grupo [[multicast]], lo que limitará la inundación de tramas a los dispositivos pertenecientes al mismo segmento VXLAN evitando así congestionar el resto de la red.

Secuencia de comunicación multicast en la que el Host-A quiere comunicarse con el Host-B basándonos en el esquema de la ''Figura 2'':
[[Archivo:VXLAN-Multicast-2.png|500px|thumb|left|Figura 2: Ejemplo de red VXLAN con reenvío multicast]]
#El Host-A quiere comunicarse con el Host-B, pero no conoce su dirección MAC. Envía por tanto un ''[[Protocolo de resolución de direcciones|ARP]] request'' con dirección destino IP-B sobre su red VXLAN de capa dos con el propósito de recibir un ''ARP reply'' por parte del Host-B del cual pueda aprender su dirección MAC.
#El VTEP-1 recibe la trama y comprueba si conoce la correspondencia de la IP-B con la IP del VTEP tras el que se encuentra esta dirección. Como no la conoce encapsula la petición ARP en un paquete IP [[multicast]] y lo envía al grupo multicast de la red VXLAN. El paquete IP multicast tiene como dirección IP origen la del VTEP-1 y como dirección destino la del grupo multicast al que pertenece la VXLAN.
#El paquete llega a todos los VTEPs que pertenecen al grupo multicast. Todos ellos desencapsulan el paquete y comprueban el VNI de la cabecera VXLAN. Como el VNI coincide con el de su segmento VXLAN los VTEP reenvían la petición ARP a sus redes de área local. Durante el proceso cada VTEP del grupo multicast aprende la dirección IP del VTEP-1 que contiene la cabecera IP externa, e inspeccionan la cabecera interna para aprender la dirección MAC del Host-A. Finalmente guardan esta correspondencia en sus tablas de direcciones.
#El Host-B recibe el ''ARP request'' que le ha enviado el VTEP-2 y responde a la petición con un ''ARP reply'' que contiene su dirección MAC. En el proceso el Host-B ha aprendido la dirección MAC del Host-A, por lo que la dirección MAC destino ya no es la de broadcast.
#El VTEP-2 recibe la respuesta del Host-B. Ahora conoce la correspondencia de la MAC del Host-A con la IP del VTEP-1, por lo que encapsula el paquete del Host-B y lo reenvía como un paquete [[unicast]] hacia el VTEP-1. Este paquete tiene como dirección IP origen la del VTEP-2.
#El VTEP-1 recibe la respuesta ARP encapsulada enviada por el VTEP-2 y aprende su dirección IP de la cabecera IP externa. Desencapsula el paquete y reenvía la respuesta ARP al Host-A.
#El Host-A recibe el ''ARP reply'' y aprende la dirección MAC del Host-B, por lo que ya se puede comunicar con este host.

Los siguientes paquetes que se envíen entre los Hosts A y B serán reenviados como paquetes unicast por los VTEPs 1 y 2 debido a que estos han aprendido las direcciones necesarias para no tener que volver a emplear reenvío multicast. De manera opcional, dado que los VTEPs 1 y 2 han aprendido las direcciones MAC de los hosts B y A respectivamente pueden actuar como ''[[Proxy ARP]]'', evitando así nuevas peticiones de las MAC de estos dos hosts.

== Consideraciones de seguridad ==

Por norma general una red local de [[capa de enlace]] solo puede ser atacada por un nodo malicioso que se encuentre dentro de la red. En el caso de una red VXLAN el hecho de transportar el tráfico de capa dos sobre una red IP hace que la red sea susceptible a ser atacada por nodos maliciosos que no pertenezcan a la red local.

Un posible peligro es que un atacante se suscriba al grupo [[multicast]] de un segmento VXLAN y por tanto pueda recibir el tráfico multicast enviado por la red o insertar paquetes con destino ese grupo multicast en la red de transporte.

Para aumentar la seguridad de la red de transporte se proponen medidas como el empleo de [[IPsec]] en los paquetes que se envían por la red, lo que permite autenticar y cifrar el tráfico VXLAN, impidiendo así los problemas mencionados anteriormente.

Otra recomendación para el aumento de la seguridad en el ámbito local de una VXLAN es designar una [[VLAN]] sobre la que se envíe el tráfico VXLAN que se genera entre los VTEPs y los hosts de la red local. De esta manera solo los hosts configurados para pertenecer a la VLAN tendrán acceso al tráfico VXLAN de la red de área local, a diferencia de si se emplease una LAN clásica. También sería necesario tener un buen control por parte de una entidad administrativa de los hosts que pertenecen a la red LAN.<ref>{{cite web |url=https://tools.ietf.org/html/rfc7348#section-7| author= M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright | title=RFC7348: Section 7: Security Considerations| date=August 2014 |accessdate=3 de diciembre de 2016}}</ref>

== Referencias ==
{{Listaref|30em}}
== Enlaces externos ==
*[https://www.arista.com/assets/data/pdf/TechBulletins/Arista_VXLAN_Technical_Brief.pdf Arista VXLAN Technical Brief] (En inglés)
*[https://web.archive.org/web/20161220113145/http://patriciocerda.com/2015/11/nsx-introduccion-a-vxlan.html NSX: Introducción a VXLAN]
*[https://web.archive.org/web/20161202233855/http://patriciocerda.com/2015/11/nsx-modos-de-replicacion-vxlan.html NSX: Modos de replicación VXLAN ]
*[https://tools.ietf.org/html/rfc7348 RFC7348] (En inglés)
*[https://www.arista.com/assets/data/pdf/Whitepapers/Arista_Design_Guide_DCI_with_VXLAN.pdf Arista Design Guide DCI with VXLAN] (En inglés)
*[https://www.arista.com/assets/data/pdf/White_Paper_Design_VMware_Arista.pdf White Paper Design VMware & Arista](En inglés)
*[http://www.cisco.com/c/en/us/products/collateral/switches/nexus-5000-series-switches/white-paper-c11-733618.html Virtual Extensible LAN (VXLAN) Best Practices White Paper](En inglés)

{{Control de autoridades}}
[[Categoría:Protocolos de Internet]]
[[Categoría:Protocolos de tunelización]]


text:
# Peter Hansen (regatista)
Peter Hansen (4 de octubre de 1977) es un deportista danés que compitió en vela en la clase 49er. Ganó dos medallas de plata en el Campeonato Europeo de 49er, en los años 2005 y 2006.

## Palmarés internacional
| \| Campeonato Europeo \| Campeonato Europeo \| Campeonato Europeo \| Campeonato Europeo \| \| Año \| Lugar \| Medalla \| Clase \| \| ------------------ \| ---------------------- \| ------------------ \| ------------------ \| \| 2005 \| Vallensbæk (Dinamarca) \| Medalla de plata \| 49er \| \| 2006 \| Weymouth (Reino Unido) \| Medalla de plata \| 49er \| |                        |                  |       |
| Campeonato Europeo                                                                                |                        |                  |       |
| Año                                                                                | Lugar                  | Medalla          | Clase |
| 2005                                                                                | Vallensbæk (Dinamarca) | Medalla de plata | 49er  |
| 2006                                                                                | Weymouth (Reino Unido) | Medalla de plata | 49er  |

wikiname: eswiki

title: Peter Hansen (regatista)

in_language: es

wikitext:
{{distinguir|[[Peter Hansen]], militar chileno de origen alemán}}
{{Ficha de deportista
|nombre              = Peter Hansen
|lugar nacimiento    =
|fecha nacimiento    = {{Fecha|4|10|1977|edad}}
|lugar fallecimiento =
|fecha fallecimiento =
|representante       = {{DEN}}
|deporte             = [[Vela (deporte)|Vela]]
|medallista olímpico =
|medallas            =
{{Medalla deportiva|[[49er]] masculino}}
{{Tabla de medallas
| [[Campeonato Europeo de 49er|Campeonato Europeo]] |0|2|0
}}
}}
'''Peter Hansen''' (4 de octubre de 1977) es un deportista [[Dinamarca|danés]] que compitió en [[Vela (deporte)|vela]] en la clase [[49er]]. Ganó dos medallas de plata en el [[Campeonato Europeo de 49er]], en los años [[Campeonato Europeo de 49er|2005]] y [[Campeonato Europeo de 49er|2006]].{{dataisaf|id=57258|fechaacceso=15 de mayo de 2024}}

==Palmarés internacional==
{{columnas}}
{| class="wikitable center col2izq" style="text-align:center;width:445px;"
|+[[49er]]
! colspan=4| [[Campeonato Europeo de 49er|Campeonato Europeo]]
|-
! Año
! Lugar
! Medalla
! Clase
|-
| [[Campeonato Europeo de 49er|2005]]
| [[Vallensbæk]] {{CdP|DEN}}
| {{Med-p}}
| 49er
|-
| [[Campeonato Europeo de 49er|2006]]
| [[Weymouth]] {{CdP|GBR}}
| {{Med-p}}
| 49er
|}
{{final columnas}}

==Referencias==
{{listaref}}

{{NF|1977||Hansen, Peter}}
[[Categoría:Regatistas de Dinamarca]]
[[Categoría:Regatistas de la clase 49er]]

title: Datos personales

Nacimiento: 4 de octubre de 1977 (47 años)

title: Carrera deportiva

Representante de: Dinamarca

Deporte: Vela

title: 49er masculino

Evento: O · P · B


text:
# Instituto Latinoamericano de Comercio Electrónico
El Instituto Latinoamericano de Comercio Electrónico (también denominado eCommerce Institute) es una asociación civil sin fines de lucro de Argentina que se desempeña dentro del ámbito de la economía digital. Fue fundado en 2005. El principal propósito del Instituto es promocionar y desarrollar el Comercio Electrónico y el e-business en los distintos países de América Latina. El Instituto se ocupa de realizar eventos relacionados al comercio electrónico como eCommerce LATAM, eCommerce Day y eCommerce Award, ofrecer capacitaciones y certificaciones y elaborar informes sobre el estado de la economía digital a través de un observatorio económico. La sede actualmente se encuentra en 25 de Mayo 611, Buenos Aires.

## Principales iniciativas
- eCommerce Latam y eCommerce Day. Son tours anuales de eventos en distintos países de América Latina que reúne a capacitadores, empresas, emprendedores y profesionales del eCommerce.[11][12][13][14]
- eCommerce Award. Es una premiación anual que reconoce a las empresas más innovadoras de la región por su labor en los negocios dentro de la industria digital.[15][16]
- eCommerce StartUP Competition. Competición para emprendimientos digitales relacionados al ecommerce.[17]
- Cursos cortos, certificaciones, posgrados y maestrías sobre marketing digital, negocios por internet, comercio electrónico y mercados masivos en línea.[18][19][20]
- Centro de observatorio para la economía digital. Estudios de casos, estadísticas, indicadores, definiciones, buenas prácticas sobre economía digital, el comercio electrónico y los negocios por Internet en América Latina.[21]
- Resolución electrónica de disputas. red de centros de mediación y arbitrajes.[22]

wikitext:
{{Ficha de organización
| logo = ECommerce Institute.png
| tipo = [[Organización sin fines de lucro]]
| fundación = 2005
| sede = 25 de Mayo 611, [[Buenos Aires]]
| administración = Marcos Pueyrredon (Presidencia)

| wikidata = Q66763625
}}

El '''Instituto Latinoamericano de Comercio Electrónico''' (también denominado eCommerce Institute) es una asociación civil sin fines de lucro de [[Argentina]] que se desempeña dentro del ámbito de la [[economía digital]].<ref>{{Cita web|url=https://www.forbes.com.mx/ecommerce-terreno-inexplorado-en-mexico/|título=E-commerce, terreno inexplorado en México • Forbes México|fechaacceso=15 de agosto de 2019|apellido=Staff|nombre=Forbes|fecha=4 de abril de 2013|sitioweb=Forbes México|idioma=es-MX}}</ref><ref>{{Cita web|url=http://iadb.libguides.com/Innovacion_comercio/e_comercio|título=LibGuides: Innovación y Comercio: Comercio electrónico|fechaacceso=24 de agosto de 2019|apellido=Huart|nombre=Carolina|sitioweb=iadb.libguides.com|idioma=en|fechaarchivo=19 de agosto de 2019|urlarchivo=https://web.archive.org/web/20190819184212/http://iadb.libguides.com/Innovacion_comercio/e_comercio|deadurl=yes}}</ref> Fue fundado en 2005. El principal propósito del Instituto es promocionar y desarrollar el [[Comercio Electrónico]] y el [[Negocio electrónico|e-business]] en los distintos países de [[América Latina]].<ref>{{Cita web|url=https://elsiglo.com.gt/2019/03/25/entrevista-a-marcos-pueyrredon-presidente-del-instituto-latinoamericano-de-comercio-electronico-ecommerce-institute-global-vp-hispanic-markets-vtex/|título=Entrevista a Marcos Pueyrredon, presidente del Instituto Latinoamericano de Comercio Electrónico eCommerce Institute & Global VP Hispanic Markets VTEX|fechaacceso=24 de agosto de 2019|apellido=elsiglogt|fecha=25 de marzo de 2019|sitioweb=El Siglo Guatemala|idioma=es}}</ref><ref>{{Cita web|url=https://observatorioecommerce.com/latinoamerica-crecimiento-ecommerce/|título=Latinoamérica se prepara para un “fuerte crecimiento” eCommerce|fechaacceso=24 de agosto de 2019|apellido=eCommerce|nombre=Observatorio|fecha=17 de diciembre de 2015|sitioweb=Observatorio eCommerce|idioma=es|fechaarchivo=14 de agosto de 2019|urlarchivo=https://web.archive.org/web/20190814203531/https://observatorioecommerce.com/latinoamerica-crecimiento-ecommerce/|deadurl=yes}}</ref><ref>{{Cita web|url=https://pulsosocial.com/2017/11/10/habitos-los-consumidores-comercio-electronico-america-latina/|título=Hábitos de los consumidores de comercio electrónico en América Latina|fechaacceso=24 de agosto de 2019|fecha=10 de noviembre de 2017|sitioweb=PulsoSocial|idioma=es-ES}}</ref> El Instituto se ocupa de realizar eventos relacionados al comercio electrónico como eCommerce LATAM, eCommerce Day y eCommerce Award, ofrecer capacitaciones y certificaciones y elaborar informes sobre el estado de la [[economía digital]] a través de un observatorio económico.<ref>{{Cita web|url=https://www.tecnopymes.cl/index.php/2019/04/15/con-gran-convocatoria-finalizo-el-ecommerce-day-santiago-2019/|título=Con gran convocatoria finalizó el eCommerce Day Santiago 2019|fechaacceso=25 de agosto de 2019|apellido=Carrasco|nombre=Francisco|fecha=15 de abril de 2019|sitioweb=Tecno Pymes|idioma=es-MX}}</ref><ref>{{Cita web|url=https://www.infobae.com/espacio-no-editorial/2019/03/22/tecnologia-y-negocios-como-fue-el-evento-de-ecommerce-que-se-llevo-a-cabo-en-el-pais/|título=Tecnología y negocios: cómo fue el evento de eCommerce que se llevó a cabo en el país|fechaacceso=24 de agosto de 2019|apellido=De 2019|nombre=22 De Marzo|sitioweb=Infobae|idioma=es-ES}}</ref><ref>{{Cita web|url=https://www.iae.edu.ar/es/LaEscuela/IAEHoy/Paginas/Un-premio-con-mucho-potencial-.aspx|título=Un premio con mucho potencial|fechaacceso=24 de agosto de 2019|sitioweb=IAE Business School|idioma=es-AR|fechaarchivo=19 de agosto de 2019|urlarchivo=https://web.archive.org/web/20190819184201/https://www.iae.edu.ar/es/LaEscuela/IAEHoy/Paginas/Un-premio-con-mucho-potencial-.aspx|deadurl=yes}}</ref><ref>{{Cita web|url=https://www.utdt.edu/ver_nota_prensa.php?id_nota_prensa=11118&id_item_menu=6|título=Usar la experiencia de otros, clave para el éxito en el e-commerce|fechaacceso=24 de agosto de 2019|sitioweb=www.utdt.edu}}</ref><ref>{{Cita web|url=https://tecno.americaeconomia.com/articulos/que-paises-lideran-el-boom-del-e-commerce-en-latina|título=¿Qué países lideran el boom del e-commerce en A. Latina? {{!}} tecno.americaeconomia.com {{!}} AETecno - AméricaEconomía|fechaacceso=24 de agosto de 2019|sitioweb=tecno.americaeconomia.com}}</ref> La sede actualmente se encuentra en 25 de Mayo 611, [[Buenos Aires]].

== Principales iniciativas ==

* eCommerce Latam y eCommerce Day. Son tours anuales de eventos en distintos países de América Latina que reúne a capacitadores, empresas, emprendedores y profesionales del eCommerce.<ref>{{Obra citada|título=Rueda de prensa E-Commerce Day CCG e Instituto Latinoamericano de Comercio Electrónico|idioma=es|url=https://www.youtube.com/watch?v=6tbXYTjB8nY|fechaacceso=24 de agosto de 2019}}</ref><ref>{{Cita web|url=https://www.latinspots.com/sp/noticia/as-pas-el-ecommerce-day-santiago-2019/50543|título=Así pasó el eCommerce Day Santiago 2019|fechaacceso=24 de agosto de 2019|apellido=LatinSpots.com|sitioweb=Latinspots.com|idioma=en}}</ref><ref>{{Cita web|url=https://www.krugercorp.com/boletines-prensa/ecommerce-day-ecuador-2015/|título=e-Commerce Day Ecuador 2015|fechaacceso=24 de agosto de 2019|apellido=Kruger|fecha=28 de junio de 2015|sitioweb=Kruger|idioma=es-ES|fechaarchivo=19 de agosto de 2019|urlarchivo=https://web.archive.org/web/20190819185705/https://www.krugercorp.com/boletines-prensa/ecommerce-day-ecuador-2015/|deadurl=yes}}</ref><ref>{{Cita web|url=https://fortuna.perfil.com/2017-08-22-191079-la-evolucion-del-comercio-on-line/|fechaacceso=24 de agosto de 2019|sitioweb=fortuna.perfil.com}}</ref>
* eCommerce Award. Es una premiación anual que reconoce a las empresas más innovadoras de la región por su labor en los negocios dentro de la industria digital.<ref>{{Cita web|url=https://www.iprofesional.com/tecnologia/298564-e-commerce-comercio-electronico-marketing-digital-Estas-empresas-fueron-elegidas-las-mejores-del-ecommerce-Latinoamericano|título=Estas empresas fueron premiadas como las mejores del ecommerce en Latinoamérica|fechaacceso=24 de agosto de 2019|sitioweb=https://www.iprofesional.com/tecnologia/298564-e-commerce-comercio-electronico-marketing-digital-Estas-empresas-fueron-elegidas-las-mejores-del-ecommerce-Latinoamericano}}</ref><ref>{{Cita web|url=https://blog.icommkt.com/email-automation-marketing-mejor-empresa-de-marketing-online-de-latinoamerica-icommkt/|título=ICOMMKT es ganador de los eCommerce Award Latam! {{!}} ICOMMKT|fechaacceso=24 de agosto de 2019|idioma=es-AR}}</ref>
* eCommerce StartUP Competition. Competición para emprendimientos digitales relacionados al ecommerce.<ref>{{Cita web|url=https://www.apertura.com/emprendedores/Los-emprendedores-ya-se-pueden-incsribir-en-la-ECommerce-Start-Up-Competition-20150820-0001.html|fechaacceso=24 de agosto de 2019|sitioweb=www.apertura.com}}</ref>
* Cursos cortos, certificaciones, posgrados y maestrías sobre marketing digital, negocios por internet, comercio electrónico y mercados masivos en línea.<ref>{{Cita web|url=http://www.economicas.uba.ar/posgrado/posgrados/marketing-digital-negocios-internet/|título=Marketing Digital y Negocios por InternetPosgrados FCE – Universidad de Buenos Aires {{!}} Posgrados FCE - Universidad de Buenos Aires|fechaacceso=25 de agosto de 2019|idioma=es|fechaarchivo=21 de agosto de 2019|urlarchivo=https://web.archive.org/web/20190821071043/http://www.economicas.uba.ar/posgrado/posgrados/marketing-digital-negocios-internet/|deadurl=yes}}</ref><ref>{{Cita web|url=http://www.ucaece.edu.ar/2017/04/26/2da-edicion-del-programa-ejecutivo-de-retail-ecommerce-entrega-de-certificados/|título=2da edición del Programa Ejecutivo de Retail eCommerce {{!}} Entrega de certificados|fechaacceso=25 de agosto de 2019|apellido=Robol|nombre=María Laura|sitioweb=Universidad CAECE|idioma=es|fechaarchivo=25 de agosto de 2019|urlarchivo=https://web.archive.org/web/20190825130711/http://www.ucaece.edu.ar/2017/04/26/2da-edicion-del-programa-ejecutivo-de-retail-ecommerce-entrega-de-certificados/|deadurl=yes}}</ref><ref>{{Cita web|url=https://blog.portinos.com/el-dato/la-universidad-caece-lanzara-el-primer-posgrado-en-retail-e-commerce|título=La Universidad CAECE lanzará el primer Posgrado en Retail e-Commerce|fechaacceso=25 de agosto de 2019|apellido=Agencia|fecha=4 de septiembre de 2018|sitioweb=Portinos|idioma=es}}</ref>
* Centro de observatorio para la economía digital. Estudios de casos, estadísticas, indicadores, definiciones, buenas prácticas sobre economía digital, el comercio electrónico y los negocios por Internet en [[América Latina]].<ref>{{Cita web|url=https://www.latinspots.com/sp/noticia/as-pas-el-ecommerce-day-santiago-2019/50543|título=Así pasó el eCommerce Day Santiago 2019|fechaacceso=25 de agosto de 2019|apellido=LatinSpots.com|sitioweb=Latinspots.com|idioma=en}}</ref>
* Resolución electrónica de disputas. red de centros de mediación y arbitrajes.<ref>{{Cita web|url=https://www.iprofesional.com/legales/37662-El-e-commerce-cambia-la-forma-en-que-se-resuelven-conflictos|título=El e-commerce cambia la forma en que se resuelven conflictos|fechaacceso=25 de agosto de 2019|sitioweb=https://www.iprofesional.com/legales/37662-El-e-commerce-cambia-la-forma-en-que-se-resuelven-conflictos}}</ref>

== Referencias ==
{{Listaref}}

{{Control de autoridades}}

Tipo: Organización sin fines de lucro

Sede central: 25 de Mayo 611, Buenos Aires

Administración: Marcos Pueyrredon (Presidencia)


text:
# Centranthus macrosiphon
Centranthus macrosiphon es una especie de plantas de la familia de las valerianáceas.

## Descripción
Hierba anual, de color verde o rosado. Los tallos de hasta 50 cm de altura, ramificados. Las hojas con limbo de hasta 5 (-7) × 3 (-5) cm, ovado o anchamente elíptico; las basales pecioladas, dentadas o crenadas, rara vez pinnatífidas; las más superiores de cortamente pecioladas a subsentadas, pinnatífidas, con lóbulos enteros o dentados. Las inflorescencias con ramas cortas, densas. Corola fresa o rosa dara; con tubo de 5-8 mm con espolón de 1-1.5 mm que sobrepasa a la base de la corola. Los frutos de 2.5-3.5 mm, ovoideos, glabros o hirsutos, con cáliz persistente de c. 0.5 mm; a veces con algún fruto con cáliz formado por setas plumosas de 3-4 mm. Florece de marzo a junio (julio).

## Distribución y hábitat
Se encuentra en herbazales en suelos nitrificados de baldíos, arcenes, bordes de camino, y alcornocales, encinares, quejigales y coscojares, en situaciones termófilas; a una altitud de 10-1720 m s. n. m. (metros sobre el nivel del mar) en España y Norte de África (Marruecos y Argelia); naturalizado en el oeste de Italia, Grecia y Australia.

## Taxonomía
Centranthus macrosiphon fue descrita por Pierre Edmond Boissier y publicado en Diagn. Pl. Orient. ser. 1, 3: 57, en el año 1843.
Etimología
Centranthus: nombre genérico que deriva de las palabras griegas:
kéntron = ‘aguijón’, ‘espolón’, etc.; y ánthos = ‘flor’. Las flores, en este género, tienen espolón.
macrosiphon: epíteto latino que significa ‘con un gran tubo’.
Citología
El número de cromosomas es de: 2n = 32.
Sinonimia
- Centranthus cadevallii Sennen
- Centranthus dasycarpus Kunze
- Ocymastrum macrosiphon Kuntze
- Valeriana macrosiphon Bailly[5]

## Nombre común
- Castellano: cata, disparates, valeriana mayor.[6]

title: Centranthus macrosiphon

wikitext:
{{Ficha de taxón
| name = ''Centranthus macrosiphon''
| image = Centranthus macrosiphon Paxton 067.jpg
| image_caption =
| regnum = [[Plantae]]
| subregnum = [[Tracheobionta]]
| divisio = [[Magnoliophyta]]
| classis = [[Magnoliopsida]]
| ordo = [[Dipsacales]]
| familia = [[Valerianaceae]]
| genus = [[Centranthus]]
| species = '''''Centranthus macrosiphon'''''
| binomial_authority = [[Boiss.]]
}}
'''''Centranthus macrosiphon''''' es una [[especie]] de plantas de la [[familia (biología)|familia]] de las [[valerianáceas]].

== Descripción ==
Hierba anual, de color verde o rosado. Los tallos de hasta 50{{esd}}cm de altura, ramificados. Las hojas con limbo de hasta 5 (-7) × 3 (-5){{esd}}cm, ovado o anchamente elíptico; las basales pecioladas, dentadas o crenadas, rara vez pinnatífidas; las más superiores de cortamente pecioladas a subsentadas, pinnatífidas, con lóbulos enteros o dentados. Las [[inflorescencia]]s con ramas cortas, densas. [[Corola]] fresa o rosa dara; con tubo de 5-8{{esd}}mm con espolón de 1-1.5{{esd}}mm que sobrepasa a la base de la corola. Los [[fruto]]s de 2.5-3.5{{esd}}mm, ovoideos, glabros o hirsutos, con cáliz persistente de c. 0.5{{esd}}mm; a veces con algún fruto con cáliz formado por setas plumosas de 3-4{{esd}}mm. Florece de marzo a junio (julio).<ref>[http://www.floravascular.com/index.php?spp=Centranthus%20macrosiphon ''Centranthus macrosiphon''] en floravascular.com.</ref>

== Distribución y hábitat ==
Se encuentra en [[herbazal]]es en suelos nitrificados de [[baldíos]], [[arcen]]es, bordes de camino, y [[alcornocal]]es, [[encinar]]es, [[quejigal]]es y [[Quercus ilex|coscojares]], en situaciones [[termófila]]s; a una altitud de 10-1720{{esd}}[[Metros sobre el nivel del mar|{{esd|m s. n. m.}}]] (metros sobre el nivel del mar) en [[España]] y [[Norte de África]] ([[Marruecos]] y [[Argelia]]); naturalizado en el oeste de [[Italia]], [[Grecia]] y [[Australia]].

== Taxonomía ==
''Centranthus macrosiphon'' fue descrita por [[Pierre Edmond Boissier]] y publicado en ''Diagn. Pl. Orient. ser. 1, 3: 57,'' en el año 1843.<ref>[http://www.tropicos.org/Name/33500033 ''Centranthus macrosiphon''] en tropicos.org.</ref>

;[[Etimología]]:
'''''Centranthus''''': nombre genérico que deriva de las palabras [[idioma griego|griegas]]:
''kéntron'' = ‘aguijón’, ‘espolón’, etc.; y ''ánthos'' = ‘flor’. Las flores, en este género, tienen espolón.<ref>[http://www.floravascular.com/index.php?familia=Valerianaceae Familia Valerianaceae] en floravascular.com.</ref>

'''''macrosiphon''''': [[epíteto]] [[latín|latino]] que significa ‘con un gran tubo’.<ref>[http://www.winternet.com/~chuckg/dictionary/dictionary.117.html En Epítetos Botánicos.]</ref>

;[[Citología]]:
El número de [[cromosoma]]s es de: 2n = 32.

;[[Sinonimia (biología)|Sinonimia]]:
* ''Centranthus cadevallii'' [[Sennen]]
* ''Centranthus dasycarpus'' [[Kunze]]
* ''Ocymastrum macrosiphon'' [[Kuntze]]
* ''Valeriana macrosiphon'' [[Bailly]]<ref>[http://www.theplantlist.org/tpl/record/kew-2709030 ''Centranthus macrosiphon''] en theplantlist.org.</ref>

== Nombre común ==
* Castellano: cata, disparates, valeriana mayor.<ref name = RJB>{{cita web |url=http://www.anthos.es/v22/index.php?set_locale=es |título= ''Centranthus macrosiphon''|fechaacceso=28 de diciembre de 2011 |formato= |obra= Real Jardín Botánico: Proyecto Anthos}}</ref>

== Referencias ==
{{listaref}}

== Enlaces externos ==
{{wikispecies|Centranthus macrosiphon|''Centranthus macrosiphon''}}
{{commonscat|Centranthus macrosiphon|''Centranthus macrosiphon''}}
{{control de autoridades}}

[[Categoría:Centranthus|macrosiphon]]
[[Categoría:Flora de la cuenca mediterránea]]
[[Categoría:Plantas descritas en 1843]]
[[Categoría:Plantas descritas por Boissier]]

title: Taxonomía

Reino: Plantae

Subreino: Tracheobionta

División: Magnoliophyta

Clase: Magnoliopsida

Orden: Dipsacales

Familia: Valerianaceae

Género: Centranthus

Especie: Centranthus macrosiphon · Boiss.


text:
# Pelusios
Pelusios es un género de tortugas de agua dulce africanas. Varias especies han sido descritas y existen probablemente numerosas especies no descritas. La taxonomía del género es muy confusa ya que estas especies presentan muchas variaciones locales. Se encuentran a lo largo del África subsahariana, Madagascar e islas Seychelles.

## Etimología
El nombre latino Pelusios significa "barro" o "arcilla",[cita requerida] y se le denominó de este modo, debido a que estas tortugas buscan refugio y comida en ellos.

## Especies
- Pelusios adansonii (Schweigger, 1812) - Tortuga africana del barro de Adanson.
- Pelusios bechuanicus (FitzSimons, 1932) - Tortuga del barro del Okavango.
- Pelusios broadleyi (Bour, 1986) - Tortuga del barro de Turkana
- Pelusios carinatus (Laurent, 1956) - Tortuga africana del barro quillada.
- Pelusios castaneus (Schweigger, 1812) - Tortuga del barro de África del Oeste.
- Pelusios castanoides (Hewitt, 1931) - Tortuga africana del barro de vientre amarillo.
  - Pelusios castanoides castanoides (Hewitt, 1931) - Tortuga de vientre amarillo africana.
  - Pelusios castanoides intergularis (Bour, 1983) - Tortuga de vientre amarillo de las Seychelles.
- Pelusios chapini (Laurent, 1965) - Tortuga del barro de África Central.
- Pelusios cupulatta (Bour & Maran, 2003) - Tortuga del barro de Costa de Marfil.
- Pelusios gabonensis (Duméril, 1856) - Tortuga africana de bosque.
- Pelusios marani (Bour, 2000) - Tortuga del barro de Gabón.
- Pelusios nanus (Laurent, 1956) - Tortuga africana del barro enana.
- Pelusios niger (Duméril & Bibron, 1835) - Tortuga negra de África del Oeste.
- Pelusios rhodesianus (Hewitt, 1927) - Tortuga africana del barro variable; Tortuga del barro de Rhodesia.
- Pelusios sinuatus (Smith, 1838) - Tortuga africana del barro serrada.
  - Pelusios sinuatus bottegi (Boulenger, 1895)[1] - Tortuga serrada del Este de África.
  - Pelusios sinuatus sinuatus (Smith, 1838)[1] - Tortuga serrada de Sudáfrica.
- Pelusios subniger (Lacépède, 1789) - Tortuga negra de África del Este.
  - Pelusios subniger subniger (Lacépède, 1789).
  - Pelusios subniger parietalis (Bour, 1983) - Tortuga negra de las Islas Seychelles.
- Pelusios upembae (Broadley, 1981) - Tortuga del barro de Upemba.
- Pelusios williamsi (Laurent, 1965) - Tortuga africana del barro de William.
  - Pelusios williamsi williamsi (Laurent, 1965) - Tortuga del barro del Lago Victoria.
  - Pelusios williamsi laurenti (Bour, 1984) - Tortuga del barro de la Isla Ukerewe.
  - Pelusios williamsi lutescens (Laurent, 1965) - Tortuga del barro del Nilo Blanco.

title: Pelusios

wikitext:
{{Ficha de taxón
| name = ''Pelusios''
| image = Pelusios castaneus.jpg
| image_width = 240px
| image_caption = ''[[Pelusios castaneus]]''
| regnum = [[Animalia]]
| phylum = [[Chordata]]
| classis = [[Reptilia]]
| ordo = [[Testudines]]
| familia = [[Pelomedusidae]]
| genus = '''''Pelusios'''''
| genus_authority = [[Wagler]], 1830
| subdivision_ranks = Species
| subdivision =
| synonyms =
''Sternothaerus'' - Bell, 1825

''Anota'' - Gray,1863

''Notoa'' - Gray,1863

''Tanoa'' - Gray,1863
| synonyms_ref
}}

'''''Pelusios''''' es un [[Género (biología)|género]] de [[Testudines|tortugas]] de agua dulce africanas. Varias especies han sido descritas y existen probablemente numerosas especies no descritas. La [[taxonomía]] del género es muy confusa ya que estas especies presentan muchas variaciones locales. Se encuentran a lo largo del [[África subsahariana]], [[Madagascar]] e islas [[Seychelles]].

==Etimología==
El nombre latino ''Pelusios'' significa "barro" o "arcilla",{{Citation needed|date=August 2014}} y se le denominó de este modo, debido a que estas tortugas buscan refugio y comida en ellos.

== Especies ==
*''[[Pelusios adansonii]]'' ([[August Friedrich Schweigger|Schweigger]], 1812) - Tortuga africana del barro de Adanson.
*''[[Pelusios bechuanicus]]'' ([[Vivian Frederick Maynard FitzSimons|FitzSimons]], 1932) - Tortuga del barro del Okavango.
*''[[Pelusios broadleyi]]'' ([[Roger Bour|Bour]], 1986) - Tortuga del barro de Turkana
*''[[Pelusios carinatus]]'' ([[Raymond Ferdinand Laurent|Laurent]], 1956) - Tortuga africana del barro quillada.
*''[[Pelusios castaneus]]'' ([[August Friedrich Schweigger|Schweigger]], 1812) - Tortuga del barro de África del Oeste.
*''[[Pelusios castanoides]]'' ([[John Hewitt (Herpetólogo)|Hewitt]], 1931) - Tortuga africana del barro de vientre amarillo.
**''[[Pelusios castanoides castanoides]]'' ([[John Hewitt (Herpetólogo)|Hewitt]], 1931) - Tortuga de vientre amarillo africana.
**''[[Pelusios castanoides intergularis]]'' ([[Roger Bour|Bour]], 1983) - Tortuga de vientre amarillo de las Seychelles.
*''[[Pelusios chapini]]'' ([[Raymond Ferdinand Laurent|Laurent]], 1965) - Tortuga del barro de África Central.
*''[[Pelusios cupulatta]]'' ([[Roger Bour|Bour]] & [[Jérome Maran|Maran]], 2003) - Tortuga del barro de Costa de Marfil.
*''[[Pelusios gabonensis]]'' ([[André Marie Constant Duméril|Duméril]], 1856) - Tortuga africana de bosque.
*''[[Pelusios marani]]'' ([[Roger Bour|Bour]], 2000) - Tortuga del barro de Gabón.
*''[[Pelusios nanus]]'' ([[Raymond Ferdinand Laurent|Laurent]], 1956) - Tortuga africana del barro enana.
*''[[Pelusios niger]]'' ([[André Marie Constant Duméril|Duméril]] & [[Gabriel Bibron|Bibron]], 1835) - Tortuga negra de África del Oeste.
*''[[Pelusios rhodesianus]]'' ([[John Hewitt (Herpetólogo)|Hewitt]], 1927) - Tortuga africana del barro variable; Tortuga del barro de Rhodesia.
*''[[Pelusios sinuatus]]'' (Smith, 1838) - Tortuga africana del barro serrada.
**''[[Pelusios sinuatus bottegi]]'' ([[George Albert Boulenger|Boulenger]], 1895)<ref name=":0">{{Cita libro|título=Phylogeography of the East African Serrated Hinged Terrapin Pelusios sinuatus (Smith, 1838) and resurrection of Sternothaerus bottegi Boulenger, 1895 as a subspecies of P. sinuatus|url=http://worldcat.org/oclc/1267933014|fechaacceso=2021-10-12|oclc=1267933014|nombre=Vamberger, Melita. Hofmeyr, Margaretha D. Cook, Courtney A. Netherlands, Edward C. Fritz,|apellidos=Uwe.}}</ref> - Tortuga serrada del Este de África.
**''[[Pelusios sinuatus sinuatus]]'' ([[Andrew Smith (zoólogo)|Smith]], 1838)<ref name=":0" /> - Tortuga serrada de Sudáfrica.
*''[[Pelusios subniger]]'' ([[Bernard de Lacépède|Lacépède]], 1789) - Tortuga negra de África del Este.
**''[[Pelusios subniger subniger]]'' ([[Bernard de Lacépède|Lacépède]], 1789).
** ''[[Pelusios subniger parietalis]]'' ([[Roger Bour|Bour]], 1983) - Tortuga negra de las Islas Seychelles.
*''[[Pelusios upembae]]'' ([[Donald George Broadley|Broadley]], 1981) - Tortuga del barro de Upemba.
*''[[Pelusios williamsi]]'' ([[Raymond Ferdinand Laurent|Laurent]], 1965) - Tortuga africana del barro de William.
**''[[Pelusios williamsi williamsi]]'' ([[Raymond Ferdinand Laurent|Laurent]], 1965) - Tortuga del barro del Lago Victoria.
**''[[Pelusios williamsi laurenti]]'' ([[Roger Bour|Bour]], 1984) - Tortuga del barro de la Isla Ukerewe.
**''[[Pelusios williamsi lutescens]]'' ([[Raymond Ferdinand Laurent|Laurent]], 1965) - Tortuga del barro del Nilo Blanco.

== Referencias ==
{{Listaref}}
* Rhodin 2011, p. 000.215
* Fritz 2007, pp. 345-346
* Bruce G. Marcot, "Two Turtles from Western Democratic Republic of the Congo: Pelusios chapini and Kinixys erosa." Includes photos.
* Wagler, 1830 : ''Natürliches System der Amphibien, mit vorangehender Classification der Säugthiere und Vögel. Ein Beitrag zur vergleichenden Zoologie''. J. G. Cotta, München, p. 1-354 ([http://www.archive.org/details/natrlichessyste00waglgoog texto integral]).

== Enlaces externos ==
{{commons category}}
*ARKive - [https://web.archive.org/web/20070427110756/http://www.arkive.org/species/GES/reptiles/Pelusios_subniger/ images and movies of the East African black mud turtle ''(Pelusios subniger)'']

{{Control de autoridades}}
[[Categoría:Pelomedusidae]]
[[Categoría:Reptiles de África]]

title: Taxonomía

Reino: Animalia

Filo: Chordata

Clase: Reptilia

Orden: Testudines

Familia: Pelomedusidae

Género: Pelusios · Wagler, 1830

title: Sinonimia

Sinonimia: Sternothaerus - Bell, 1825 · Anota - Gray,1863 · Notoa - Gray,1863 · Tanoa - Gray,1863