text:
# Grammatorcynus bicarinatus
El carite cazón (Grammatorcynus bicarinatus) es una especie de pez perciforme de la familia Scombridae.

## Morfología
Los machos pueden llegar alcanzar los 112 cm de longitud total y los 13,5 kg de peso.

## Distribución geográfica
Se encuentran en las costas septentrionales de Australia (Australia Occidental, Queensland y el norte de Nueva Gales del Sur), el Golfo de Papúa (Nueva Guinea) y las Islas de la Lealtad.

wikiname: eswiki

title: Grammatorcynus bicarinatus

in_language: es

wikitext:
{{Ficha de taxón
| name = Carite cazón
| image = Grbic u0.gif
| image_caption =
| image2_width = 250px
| image2_caption =
| regnum = [[Animalia]]
| phylum = [[Chordata]]
| classis = [[Actinopterygii]]
| subclassis = [[Neopterygii]]
| infraclassis = [[Teleostei]]
| superordo = [[Acanthopterygii]]
| ordo = [[Perciformes]]
| subordo = [[Scombroidei]]
| familia = [[Scombridae]]
| genus = [[Grammatorcynus]]
| species = '''G. bicarinatus'''
| binomial =  '''''Grammatorcynus bicarinatus'''''
| binomial_authority =  ([[Jean René Constant Quoy|Quoy]] & [[Joseph Paul Gaimard|Gaimard]], 1825)
| synonyms =
}}
El '''carite cazón''' ('''''Grammatorcynus bicarinatus''''') es una [[especie]] de [[pez]] [[perciforme]] de la [[familia (biología)|familia]] [[Scombridae]].<ref>{{ITIS |name = Grammatorcynus bicarinatus |id = 172472 }}</ref>

== Morfología ==
Los [[macho]]s pueden llegar alcanzar los 112 cm de longitud total y los 13,5 kg de peso.<ref>[http://fishbase.org/Summary/SpeciesSummary.php?id=103 FishBase] (en inglés)</ref>

== Distribución geográfica ==
Se encuentran en las costas septentrionales de [[Australia]] ([[Australia Occidental]], [[Queensland]] y el norte de [[Nueva Gales del Sur]]), el [[Golfo de Papúa]] ([[Nueva Guinea]]) y las [[Islas de la Lealtad]].

== Referencias ==
{{listaref}}

== Bibliografía ==

* Fenner, Robert M.: ''The Conscientious Marine Aquarist''. Neptune City, [[Nueva Jersey]], [[Estados Unidos]] : T.F.H. Publications, 2001.
* Helfman, G., B. Collette y D. Facey: ''The diversity of fishes''. Blackwell Science, Malden, Massachusetts, [[Estados Unidos]] , 1997.
* Hoese, D.F. 1986: . A M.M. Smith y P.C. Heemstra (eds.) Smiths' sea fishes. Springer-Verlag, [[Berlín]], [[Alemania]].
* Maugé, L.A. 1986.  A J. Daget, J.-P. Gosse y D.F.E. Thys van den Audenaerde (eds.) Check-list of the freshwater fishes of Africa (CLOFFA). ISNB [[Bruselas]]; MRAC, [[Tervuren]], [[Flandes]]; y ORSTOM, [[París]], [[Francia]]. Vol. 2.
* Moyle, P. y J. Cech.: ''Fishes: An Introduction to Ichthyology'', 4a. edición, Upper Saddle River, [[Nueva Jersey]], [[Estados Unidos]]: Prentice-Hall. Año 2000.
* Nelson, J.: ''Fishes of the World'', 3a. edición. [[Nueva York]], [[Estados Unidos]]: John Wiley and Sons. Año 1994.
* Wheeler, A.: ''The World Encyclopedia of Fishes'', 2a. edición, [[Londres]]: Macdonald. Año 1985.

== Enlaces externos ==
{{Traducido ref|ca|Grammatorcynus bicarinatus}}
{{commons|Grammatorcynus bicarinatus}}
{{Wikispecies}}[http://animaldiversity.ummz.umich.edu/site/accounts/classification/Grammatorcynus_bicarinatus.html Animal Diversity Web] (en inglés)

{{Control de autoridades}}
[[Categoría:Scombridae]]
[[Categoría:Taxones descritos por Jean René Constant Quoy]]
[[Categoría:Taxones descritos por Joseph Paul Gaimard]]
[[Categoría:Animales descritos en 1825]]
[[Categoría:Peces de Oceanía]]

title: Taxonomía

Reino: Animalia

Filo: Chordata

Clase: Actinopterygii

Subclase: Neopterygii

Infraclase: Teleostei

Superorden: Acanthopterygii

Orden: Perciformes

Suborden: Scombroidei

Familia: Scombridae

Género: Grammatorcynus

Especie: G. bicarinatus · (Quoy & Gaimard, 1825)


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:
# Sort (Lleida)
Sort ist die Hauptstadt der Comarca Pallars Sobirà in der Autonomen Gemeinschaft Katalonien, Spanien.

## Geographie
Sort liegt 692 Meter über dem Meer am Fluss Noguera Pallaresa, einem Zufluss des Segre. Die Einwohnerzahl beträgt 2.213 (Stand: 2024).

## Bevölkerung
| Bevölkerungsentwicklung |      |       |      |      |      |       |       |       |       |       |       |       |
| 1900                    | 1910 | 1920  | 1930 | 1940 | 1950 | 1960  | 1970  | 1981  | 1991  | 1996  | 2001  | 2005  |
| 946                     | 998  | 1.109 | 930  | 808  | 874  | 1.209 | 1.835 | 1.496 | 1.511 | 1.718 | 1.829 | 2.113 |

## Wirtschaft
Da Sort auf Katalanisch Glück bedeutet, zieht der Ort eine große Anzahl Touristen aus ganz Spanien an, die dort Lose für die jährliche Weihnachtslotterie für sich und Freunde kaufen wollen.
Tatsächlich gibt es überdurchschnittlich viele Gewinner unter den in Sort verkauften Losen. Innerhalb von zehn Jahren wurden dort fünf Mal Lose für den Hauptgewinn verkauft, zuletzt 2004. Dies hängt allerdings eher mit den außergewöhnlich hohen Verkaufszahlen dort zusammen.

## Museum
Das Museum „El Camí de la llibertat“ (Der Weg der Freiheit), untergebracht in einem alten Gefängnis, widmet sich seit Juli 2007 der Erinnerung an die vielen hundert Menschen, die auf ihrer Flucht vor den Nationalsozialisten während des Zweiten Weltkriegs durch Sort kamen.

## Veranstaltungen
Im Jahr 2010 wurde in Sort die Kanu Wildwasser-Weltmeisterschaft ausgetragen.

wikiname: dewiki

title: Sort (Lleida)

in_language: de

wikitext:
{{Infobox Gemeinde in Spanien
 |nombre = Sort
 |Bild = Sort.jpg
 |escudo = Escut de Sort.svg
 |latitude = 42/24/30/N
 |longitude = 01/07/45/E
 |isoreg = CT
 |ccaa = {{ES-CT}}
 |provincia = Lleida
 |isla =
 |comarca = Pallars Sobirà
 |fundación =
 |predoling = cat
 |superficie =
 |altitud = 692
 |cp = 25560
 |cod_ine = 25209
 |aeropuerto =
 |alcalde = Raimon Monterde Alberich
 |dirección =
 |web = https://sort.cat/
 |mapa = Localització de Sort.png
 |Kommunalschlüssel = 2520940003
}}
'''Sort''' ist die Hauptstadt der [[Comarca]] [[Pallars Sobirà]] in der Autonomen Gemeinschaft [[Katalonien]], [[Spanien]].

== Geographie ==

Sort liegt 692 Meter über dem Meer am Fluss [[Noguera Pallaresa]], einem Zufluss des [[Segre]]. Die Einwohnerzahl beträgt {{Einwohnerzahl Wikidata}} (Stand: {{Einwohnerzahl-Stand Wikidata|Q12690}}).

== Bevölkerung ==

[[Datei:Poblacion-Sort-1900-2005.png|mini|links|Bevölkerungsentwicklung Sort]]

{| class="wikitable"
|colspan="13" style="text-align:center" | '''Bevölkerungsentwicklung'''
|- style="background:#DDFFDD"
|- class="hintergrundfarbe6"
! 1900 !! 1910 !! 1920 !! 1930 !! 1940 !! 1950 !! 1960 !! 1970 !! 1981 !! 1991 !! 1996 !! 2001 !! 2005
|- style="text-align:center"
| 946 || 998 || 1.109 || 930 || 808 || 874 || 1.209 || 1.835 || 1.496 || 1.511 || 1.718 || 1.829 || 2.113
|}
{{Absatz|links}}

== Wirtschaft ==
Da Sort auf [[Katalanische Sprache|Katalanisch]] Glück bedeutet, zieht der Ort eine große Anzahl Touristen aus ganz Spanien an, die dort Lose für die jährliche [[Weihnachtslotterie]] für sich und Freunde kaufen wollen.
Tatsächlich gibt es überdurchschnittlich viele Gewinner unter den in Sort verkauften Losen. Innerhalb von zehn Jahren wurden dort fünf Mal Lose für den Hauptgewinn verkauft, zuletzt 2004. Dies hängt allerdings eher mit den außergewöhnlich hohen Verkaufszahlen dort zusammen.

== Museum ==
Das Museum „El Camí de la llibertat“ (Der Weg der Freiheit), untergebracht in einem alten Gefängnis, widmet sich seit Juli 2007 der Erinnerung an die vielen hundert Menschen, die auf ihrer Flucht vor den [[Nationalsozialisten]] während des [[Zweiter Weltkrieg|Zweiten Weltkriegs]] durch Sort kamen. <!--Quelle: span WP-->

== Veranstaltungen ==
Im Jahr 2010 wurde in Sort die Kanu Wildwasser-Weltmeisterschaft ausgetragen<ref>http://webfeed.swissolympic.ch/siclient/home/events_list.aspx?Keyword=&DateFrom=16.4.2011&DateTo=&SportsId=40&Country=&Search=1{{Toter Link|url=http://webfeed.swissolympic.ch/siclient/home/events_list.aspx?Keyword=&DateFrom=16.4.2011&DateTo=&SportsId=40&Country=&Search=1 |date=2019-04 |archivebot=2019-04-22 14:43:31 InternetArchiveBot }}</ref>.

== Weblinks ==
{{Commonscat|Sort}}

== Einzelnachweise ==
<references />

{{Navigationsleiste Gemeinden in Pallars Sobirà}}

{{Normdaten|TYP=g|GND=4472860-8|LCCN=n/84/56969|VIAF=130233491}}

[[Kategorie:Sort (Lleida)| ]]
[[Kategorie:Ort in Katalonien]]

title: Gemeinde Sort

Wappen: Karte von Spanien

title: Basisdaten

Land: Spanien

Autonome Gemeinschaft: Katalonien

Provinz: Lleida

Comarca: Pallars Sobirà

Gerichtsbezirk: Tremp

Höhe: 689 msnm

Bevölkerungsdichte: 21 Einw./km²

title: Verwaltung

Amtssprache: Kastilisch, Katalanisch

Bürgermeister: Raimon Monterde Alberich


text:
# Seconde bataille de Memphis
Guerre de Sécession
Batailles
Défense du Mississippi de Forrest
- Yazoo City
- Brice's Crossroads
- Tupelo
- 2e Memphis

La seconde bataille de Memphis est une bataille de la guerre de Sécession, survenue le 21 août 1864, dans le comté de Shelby, Tennessee.

## Bataille
À 4 heures du matin le 21 août 1864, le major général Nathan Bedford Forrest fait un raid audacieux contre Memphis, dans le Tennessee tenu par l'Union, mais ce n'est pas une tentative pour s'emparer de la ville, qui est occupée par 6 000 troupes fédérales. Le raid a trois objectifs : capturer trois généraux de l'Union ; libérer des prisonniers sudistes de la prison d'Irving Block ; entraîner le rappel des forces de l'Union du nord du Mississippi. Frappant le nord-ouest de Memphis avec 2 000 cavaliers, Forrest perd environ un quart de sa force en raison de l'épuisement des chevaux. La surprise est essentielle. Profitant d'un épais brouillard de l'aube et prétendant être une patrouille de l'Union revenant avec les prisonniers, les confédérés éliminent les sentinelles.
Galopant à travers les rues et échangeant des coups de feu avec les autres troupes de l'Union, les raiders se divisent pour poursuivre des missions distinctes. Un général de l'union n'est pas dans ses quartiers. Un autre, le général Cadwallader C. Washburn s'échappé vers le fort Pickering, vêtu en chemise de nuit. Forrest prend l'uniforme de Washburn, mais lui retourne plus tard sous un drapeau de trêve. Selon une légende de Memphis, les cavaliers confédérés entrent dans le hall de l'hôtel de luxe Gayoso House Hotel à la recherche d'officiers Yankees. Une rue de Memphis est nommée « General Washburn's Escape Alley » en commémoration de cette fuite. L'attaque sur la prison d'Irving Block échoue également lorsque les troupes de l'Union arrêtent le corps principal à l'université féminine de l'État (State Female College). Au bout de deux heures, Forrest décide de se retirer, coupant les fils télégraphiques, capturant 500 prisonniers, et de grandes quantités de fournitures, y compris de nombreux chevaux.

## Résultats
Bien que Forrest échoue à Memphis, son raid influence les forces de l'Union pour y retourner, à partir du nord du Mississippi, et fournir une protection. Le général de l'Union Hurlbut est cité par la suite comme ayant dit, « ll y va de nouveau ! Ils m'ont remplacé par Washburn parce que je ne pouvais pas maintenir Forrest hors du Tennessee de l'ouest, et Washburn ne peut pas le maintenir hors de sa propre chambre à coucher ! ».

## Liens Externes
- Mise à jour du rapport du CWSAC
- Gayoso House Hotel
- Base de données sur les soldats et marins du service des parcs nationaux

wikiname: frwiki

title: Seconde bataille de Memphis

in_language: fr

wikitext:
{{Ébauche|guerre de Sécession}}
{{Infobox Conflit militaire
 | conflit      = Seconde bataille de Memphis
 | guerre       = [[Guerre de Sécession]]
 | image        = Forrest Memphis Raid.jpg
 | légende      = Attaque contre la prison d'Irving Block
 | date         = {{date|21 août 1864}}
 | lieu         = [[Memphis (Tennessee)|Memphis]], État du [[Tennessee]]
 | casus        =
 | territoires  =
 | issue        = Victoire confédérée
 | combattants1 = {{États-Unis (1863-1865)}}
 | combattants2 = {{États confédérés d'Amérique 1863-1865}}
 | commandant1  = [[Cadwallader Colden Washburn|Cadwallader C. Washburn]]
 | commandant2  = [[Nathan Bedford Forrest]]
 | forces1      =  {{formatnum:6000}}<ref name=CWSS>National Park Service. [https://www.nps.gov/civilwar/search-battles-detail.htm?battleCode=TN031 "Memphis II"], ''[https://www.nps.gov/civilwar/soldiers-and-sailors-database.htm Civil War Soldiers and Sailors Database]''. Consulté le 6 novembre 2017.</ref>
 | forces2      = Garnison de Memphis
{{formatnum:2000}}<ref name=CWSS/>
 | pertes1      = Division de cavalerie de Forrest
480 <ref name=CWSS/>{{,}}<ref>La [https://www.nps.gov/civilwar/soldiers-and-sailors-database.htm description de la bataille par le NPS] répertorie 160 victime, mais ce chiffre est  incohérent avec le texte qui précise {{citation|Forrest a décidé de se retirer, coupant les lignes télégraphiques, faisant {{nombre|500|prisonniers}}}}.</ref>
 | pertes2      = 62 <ref name=CWSS/>
 | pertes       =
 | batailles    = {{Boîte déroulante/début|titre=Guerre de Sécession}}{{Guerre de Sécession}}{{Boîte déroulante/fin}}{{Défense du Mississippi de Forrest}}
 | notes        =
 | coordonnées  = {{coord|35.1446|-90.0540|display=title|region:US-TN_type:event}}
 | géolocalisation = États-Unis/Tennessee
}}

La '''seconde bataille de Memphis''' est une bataille de la [[guerre de Sécession]], survenue le {{date|21 août 1864}}, dans le [[Comté de Shelby (Tennessee)|comté de Shelby, Tennessee]].
== Bataille ==
[[Fichier:Memphis_II_Battlefield_Tennessee.jpg|droite|vignette|406x406px|La carte du champ de bataille de Memphis II et les zones d'étude par le [[American Battlefield Protection Program|programme de protection des champs de bataille américains]].]]
À {{unité|4|heures}} du matin le {{date|21 août 1864}}, le major général [[Nathan Bedford Forrest]] fait un raid audacieux contre [[Memphis (Tennessee)|Memphis, dans le Tennessee]] tenu par l'[[Union Army|Union]], mais ce n'est pas une tentative pour s'emparer de la ville, qui est occupée par {{nombre|6000|troupes}} fédérales. Le raid a trois objectifs : capturer trois généraux de l'Union ; libérer des prisonniers sudistes de la [[Irving Block prison|prison d'Irving Block]] ; entraîner le rappel des forces de l'Union du nord du Mississippi. Frappant le nord-ouest de Memphis avec {{nombre|2000|cavaliers}}, Forrest perd environ un quart de sa force en raison de l'épuisement des chevaux. La surprise est essentielle. Profitant d'un épais brouillard de l'aube et prétendant être une patrouille de l'Union revenant avec les prisonniers, les confédérés éliminent les sentinelles.

Galopant à travers les rues et échangeant des coups de feu avec les autres troupes de l'Union, les raiders se divisent pour poursuivre des missions distinctes. Un général de l'union n'est pas dans ses quartiers. Un autre, le général [[Cadwallader Colden Washburn|Cadwallader C. Washburn]] s'échappé vers le fort Pickering, vêtu en chemise de nuit. Forrest prend l'uniforme de Washburn, mais lui retourne plus tard sous un drapeau de trêve. Selon une légende de Memphis, les cavaliers confédérés entrent dans le hall de l'hôtel de luxe ''Gayoso House Hotel'' à la recherche d'officiers Yankees. Une rue de Memphis est nommée {{citation|General Washburn's Escape Alley}} en commémoration de cette fuite. L'attaque sur la prison d'Irving Block échoue également lorsque les troupes de l'Union arrêtent le corps principal à l'université féminine de l'État (State Female College). Au bout de deux heures, Forrest décide de se retirer, coupant les fils télégraphiques, capturant {{nombre|500|prisonniers}}, et de grandes quantités de fournitures, y compris de nombreux chevaux.

== Résultats ==
Bien que Forrest échoue à Memphis, son raid influence les forces de l'Union pour y retourner, à partir du nord du Mississippi, et fournir une protection. Le général de l'Union Hurlbut est cité par la suite comme ayant dit, {{citation|''ll y va de nouveau ! Ils m'ont remplacé par Washburn parce que je ne pouvais pas maintenir Forrest hors du Tennessee de l'ouest, et Washburn ne peut pas le maintenir hors de sa propre chambre à coucher !''}}.

== Références ==
{{Références}}
== Liens Externes ==
* [http://www.nps.gov/hps/abpp/CWSII/TennesseeBattlefieldProfiles/Memphis%20I%20to%20Murfreesboro%20II.pdf Mise à jour du rapport du CWSAC]
* [http://tennesseeencyclopedia.net/imagegallery.php?EntryID=G006 Gayoso House Hotel]
* [https://www.nps.gov/civilwar/search-battles-detail.htm?battleCode=TN031 Base de données sur les soldats et marins du service des parcs nationaux]

{{Portail|guerre de Sécession|forces armées des États-Unis}}

{{DEFAULTSORT:Memphis, 02}}
[[Catégorie:1864 aux États-Unis]]
[[Catégorie:Août 1864]]
[[Catégorie:Bataille du théâtre oriental de la guerre de Sécession]]
[[Catégorie:Victoire confédérée de la guerre de Sécession]]
[[Catégorie:Bataille de 1864]]
[[Catégorie:Comté de Shelby (Tennessee)]]

title: Informations générales

Lieu: Memphis, État du Tennessee

Issue: Victoire confédérée

title: Belligérants

États-Unis: États confédérés

title: Commandants

Cadwallader C. Washburn: Nathan Bedford Forrest

title: Forces en présence

Garnison de Memphis · 2 000

title: Pertes

title: Données clés

Coordonnées: 35° 08′ 41″ nord, 90° 03′ 14″ ouest


text:
# Chronic
Chronic è un film del 2015 diretto da Michel Franco.

## Trama
David è un infermiere che lavora con i malati terminali. È incredibilmente bravo e devoto nel suo lavoro, spesso sviluppa relazioni forti e anche intime con ogni persona di cui si prende cura. Ma al di fuori del suo lavoro, è un uomo inefficace, goffo, depresso e riservato. È chiaro che ha bisogno dei suoi pazienti quanto loro hanno bisogno di lui, perché a loro dà tutto se stesso.

## Distribuzione
Chronic è stato premiato il 22 maggio 2015 al Festival di Cannes ed è stato selezionato anche per competere per la Palma d'Oro. A Cannes, Franco ha vinto il premio come Miglior sceneggiatura.

## Accoglienza
Il film ha ricevuto recensioni positive dalla critica. Nel sito di recensioni Rotten Tomatoes, il film ha avuto un rating del 75%. PerMetacritic ha un resoconto di 68 su 100, basato su 16 critiche, a indicare "recensioni generalmente positive".

wikiname: itwiki

title: Chronic

in_language: it

wikitext:
{{Film
|titolo = Chronic
| immagine = Chronic.PNG
|titolo originale =Chronic
|paese = [[Messico]]
|paese 2 =[[Francia]]
|paese 3 =
|paese 4 =
|anno uscita = 2015
|durata = 93 min
|genere = drammatico
|genere 2 =
|regista = [[Michel Franco]]
|soggetto =
|sceneggiatore = [[Michel Franco]]
|attori =
* [[Tim Roth]] : David
* [[Tate Ellington]] : Greg
* [[Bitsie Tulloch]] : Lidia
* [[Maribeth Monroe]] e [[Cleo Monroe]] : Nipoti di Sarah
* [[Claire van der Boom]] : Alice
* [[David Dastmalchian]] : Bernard
* [[Sarah Sutherland]] : Nadia
* [[Robin Bartlett]] : Marta
* [[Michael Cristofer]] : John
* [[Joe Santos]] : Issac Sr.
* [[Nailea Norvind]] : Laura
* [[Kari Coleman]] : Sorella di Sarah
* [[Laura Niemi]] : Margaret
* [[Angela Bullock]] : Sylvia
* [[Rachel Pickup]] : Sarah
|fotografo = [[Yves Cape]]
|montatore = [[Julio Perez IV]]
|effetti speciali =
|musicista =
|scenografo =[[Matt Luem]], [[Nicolas Kelley]], [[Danielle Laubach]] e [[Madelaine Frezza]]
}}

'''''Chronic''''' è un [[film]] del [[2015]] diretto da [[Michel Franco]].

== Trama ==
David è un infermiere che lavora con i malati terminali. È incredibilmente bravo e devoto nel suo lavoro, spesso sviluppa relazioni forti e anche intime con ogni persona di cui si prende cura. Ma al di fuori del suo lavoro, è un uomo inefficace, goffo, depresso e riservato. È chiaro che ha bisogno dei suoi pazienti quanto loro hanno bisogno di lui, perché a loro dà tutto se stesso.

== Distribuzione ==
''Chronic'' è stato premiato il 22 maggio 2015 al [[Festival di Cannes]] ed è stato selezionato anche per competere per la [[Palma d'Oro]].<ref name="2015Cannes">{{cita web |url=http://www.festival-cannes.com/fr/article/61323.html |titolo=Complement to the Official Selection |accesso=23 aprile 2015 |data=23 aprile 2015 |sito=Cannes Film Festival |dataarchivio=5 maggio 2015 |urlarchivio=https://web.archive.org/web/20150505040811/http://www.festival-cannes.com/fr/article/61323.html |urlmorto=sì }}</ref><ref>{{cita web|url=http://www.festival-cannes.fr/en/article/61347.html|titolo=Screenings Guide|sito=Festival de Cannes|data=6 maggio 2015|accesso=8 maggio 2015}}</ref> A Cannes, Franco ha vinto il premio come [[Prix du scénario|Miglior sceneggiatura]].<ref>{{cita web |url=https://www.theguardian.com/film/live/2015/may/24/cannes-2015-palme-dor-announcement |titolo=Cannes 2015: Jacques Audiard's Dheepan wins the Palme d'Or |autore=Henry Barnes |data=24 maggio 2015 |accesso=24 maggio 2015 |editore=The Guardian}}</ref><ref>{{cita web |url=https://www.hollywoodreporter.com/news/cannes-2015-winners-announced-797340 |titolo=Cannes: 'Dheepan' Wins the Palme d'Or |autore=Rebecca Ford |data=24 maggio 2015 |accesso=24 maggio 2015 |sito=The Hollywood Reporter}}</ref>

== Accoglienza ==
Il film ha ricevuto recensioni positive dalla critica. Nel sito di recensioni [[Rotten Tomatoes]], il film ha avuto un rating del 75%.<ref>{{cita web | url=https://www.rottentomatoes.com/m/chronic_2015/ | titolo=Chronic (2015) | sito=[[Rotten Tomatoes]] | editore=[[Flixster]] | accesso=2 dicembre 2015}}</ref> Per[[Metacritic]] ha un resoconto di 68 su 100, basato su 16 critiche, a indicare "recensioni generalmente positive".<ref>{{cita web | url=http://www.metacritic.com/movie/chronic | titolo=Chronic reviews | sito=[[Metacritic]] | editore=[[CBS Interactive]] | accesso=2 dicembre 2015}}</ref>

== Note ==
<references />

== Collegamenti esterni ==
* {{Collegamenti esterni}}

{{Portale|cinema}}

[[Categoria:Film drammatici]]
[[Categoria:Film diretti da Michel Franco]]

title: Chronic

Titolo originale: Chronic

Paese di produzione: Messico, Francia

Durata: 93 min

Genere: drammatico

Regia: Michel Franco

Sceneggiatura: Michel Franco

Fotografia: Yves Cape

Montaggio: Julio Perez IV

Scenografia: Matt Luem, Nicolas Kelley, Danielle Laubach e Madelaine Frezza

title: Interpreti e personaggi

Interpreti e personaggi: - Tim Roth : David - Tate Ellington : Greg - Bitsie Tulloch : Lidia - Maribeth Monroe e Cleo Monroe : Nipoti di Sarah - Claire van der Boom : Alice - David Dastmalchian : Bernard - Sarah Sutherland : Nadia - Robin Bartlett : Marta - Michael Cristofer : John - Joe Santos : Issac Sr. - Nailea Norvind : Laura - Kari Coleman : Sorella di Sarah - Laura Niemi : Margaret - Angela Bullock : Sylvia - Rachel Pickup : Sarah


text:
# نماد اشلفلی
در هندسه، نماد اِشلَفْلی (انگلیسی: Schläfli symbol) نوعی نشانه‌گذاری به شکل {p,q،r,...} است که با آن می‌توان پلیتوپ‌های منتظم و شیوهٔ مفروش‌سازی آن‌ها را مشخص کرد. نماد اشلفلی نام خود را از ریاضی‌دان قرن نوزدهمی سوئیسی لودویگ اشلفلی گرفته‌است که از پیشگامان ایجاد قراردادهای نوشتاری برای فضاها در ابعاد بالاتر از سه بود.
نماد اشلفلی تعریفی بازگشتی دارد و با {p} برای یک چندضلعی منتظم محدب آغاز می‌شود. برای مثال {۳} نماد اشلفلی مثلث متساوی‌الاضلاع، {۴} مربع، {۵} پنج‌ضلعی منتظم و الی آخر است. چندضلعی‌های منتظم ستاره‌ای محدب نیستند و نماد اشلفلی آن‌ها به شکل {p/q} نوشته می‌شود که در این کسر تحویل‌ناپذیر p تعداد رئوس است. برای مثال نماد اشلفلی یک ستاره پنج‌پر {۵/۲} است.
چندوجهی منتظمی که به دور هر رأسش q وجه p-ضلعی داشته باشد، با نماد اشلفلی {p,q} نشان داده می‌شود. مثلاً در هر رأس مکعب ۳ مربع به هم می‌رسند؛ بنابراین نماد اشلفلی آن {۴٬۳} است.
پلیتوپ چهاربعدی‌ای که در هر ضلع آن r تا چندوجهی با نماد اشلفلی {p,q} به هم می‌رسند، با نماد اشلفلی {p,q،r} نشان داده می‌شود. مثلاً در هر ضلع یک تسرکت سه مکعب (با نماد اشلفلی {۴٬۳}) به هم می‌رسند؛ پس نماد اشلفلی آن {۴٬۳،۳} است.
به‌طور کلی، پلیتوپ {p,q،r,... ,y،z} به دور هر قلّه‌اش z تا وجه با نماد {p,q،r,... ,y} دارد. قله (peak) در چندوجهی رأس، در ۴-پلیتوپ ضلع، در ۵-پلیتوپ وجه، در ۶-پلیتوپ خانه و در n-پلیتوپ (n-3)-وجه است.

wikiname: fawiki

title: نماد اشلفلی

in_language: fa

wikitext:
[[پرونده:Dodecahedron.png|بندانگشتی|[[دوازده‌وجهی]] یک [[چندوجهی]] منتظم با نماد اشلفلی {۵٬۳} است.]]
در [[هندسه]]، '''نماد اِشلَفْلی''' ({{lang-en|Schläfli symbol}}) نوعی نشانه‌گذاری به شکل {p,q،r,...} است که با آن می‌توان [[پلیتوپ|پلیتوپ‌های]] منتظم و شیوهٔ [[مفروش‌سازی]] آن‌ها را مشخص کرد. نماد اشلفلی نام خود را از ریاضی‌دان قرن نوزدهمی سوئیسی [[لودویگ اشلفلی]] گرفته‌است که از پیشگامان ایجاد قراردادهای نوشتاری برای فضاها در [[بعد|ابعاد]] بالاتر از سه بود.

نماد اشلفلی [[تعریف بازگشتی|تعریفی بازگشتی]] دارد و با {p} برای یک [[چندضلعی منتظم]] [[مجموعه محدب|محدب]] آغاز می‌شود. برای مثال {۳} نماد اشلفلی [[مثلث متساوی‌الاضلاع]]، {۴} [[مربع]]، {۵} [[پنج‌ضلعی منتظم]] و الی آخر است. [[چندضلعی ستاره‌ای|چندضلعی‌های منتظم ستاره‌ای]] محدب نیستند و نماد اشلفلی آن‌ها به شکل {p/q} نوشته می‌شود که در این [[کسر تحویل‌ناپذیر]] p تعداد رئوس است. برای مثال نماد اشلفلی یک [[ستاره پنج‌پر]] {۵/۲} است.

[[چندوجهی منتظم]]ی که به دور هر رأسش q وجه p-ضلعی داشته باشد، با نماد اشلفلی {p,q} نشان داده می‌شود. مثلاً در هر رأس [[مکعب]] ۳ مربع به هم می‌رسند؛ بنابراین نماد اشلفلی آن {۴٬۳} است.

[[پلیتوپ]] چهاربعدی‌ای که در هر ضلع آن r تا چندوجهی با نماد اشلفلی {p,q} به هم می‌رسند، با نماد اشلفلی {p,q،r} نشان داده می‌شود. مثلاً در هر ضلع یک [[تسرکت]] سه مکعب (با نماد اشلفلی {۴٬۳}) به هم می‌رسند؛ پس نماد اشلفلی آن {۴٬۳،۳} است.

به‌طور کلی، پلیتوپ {p,q،r,... ,y،z} به دور هر قلّه‌اش z تا وجه با نماد {p,q،r,... ,y} دارد. قله (peak) در چندوجهی رأس، در ۴-پلیتوپ ضلع، در ۵-پلیتوپ وجه، در ۶-پلیتوپ خانه و در n-پلیتوپ (n-3)-وجه است.
[[پرونده:Regular star polygons.svg|600px|بندانگشتی|وسط|نماد اشلفلی چندضلعی‌های محدب و ستاره‌ای (دو بعد) از ۳ تا ۱۲ رأس]]

== منابع ==
{{پانویس|چپ‌چین=بله}}
* {{یادکرد-ویکی|پیوند =//en.wikipedia.org/w/index.php?title=Schläfli_symbol&oldid=862710403|عنوان = Schläfli symbol|زبان =انگلیسی|بازیابی =۲۴ نوامبر ۲۰۱۸}}
{{چپ‌چین}}
* {{cite book | first=Harold Scott MacDonald | last=Coxeter | author-link=هارولد اسکات مک‌دونالد کاکسیتر | title=Regular Polytopes | publisher = Dover Publications | edition=Third | oclc=798003 | date = 1973 | orig-year=1948 | isbn = 0-486-61480-8 | pages=14, 69, 149 | url=https://books.google.com/books?id=iWvXsVInpgMC&lpg=PP1&dq=Regular%20Polytopes&pg=PP1#v=onepage&q=&f=false}}
* ''[http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471010030.html Kaleidoscopes: Selected Writings of H.S.M. Coxeter]'', edited by F. Arthur Sherk, Peter McMullen, Anthony C. Thompson, Asia Ivic Weiss, Wiley-Interscience Publication, 1995, {{isbn|978-0-471-01003-6|en}}
** (Paper 22) H.S.M. Coxeter, ''Regular and Semi Regular Polytopes I'', [Math. Zeit. 46 (1940) 380-407, MR 2,10]
** (Paper 23) H.S.M. Coxeter, ''Regular and Semi-Regular Polytopes II'', [Math. Zeit. 188 (1985) 559-591]
** (Paper 24) H.S.M. Coxeter, ''Regular and Semi-Regular Polytopes III'', [Math. Zeit. 200 (1988) 3-45]
{{پایان چپ‌چین}}

== پیوند به بیرون ==
* {{mathworld | urlname = SchlaefliSymbol | title = Schläfli symbol}}
{{چپ‌چین}}
* [http://www.ac-noumea.nc/maths/polyhedr/names_.htm Polyhedral Names et Notations]{{پایان چپ‌چین}}

{{ریاضی-خرد}}

[[رده:پلیتوپ‌ها]]
[[رده:نشانه‌گذاری ریاضی]]


text:
# Julius Ebbinghaus
Julius Ebbinghaus (9 de novembro de 1885, Berlim - 16 de junho de 1981, Marburg an der Lahn) foi um filósofo alemão, um dos seguidores mais próximos de Immanuel Kant no século XX. Ele foi influenciado pela escola de neokantismo de Heidelberg de Wilhelm Windelband, e escreveu sobre filosofia do direito e o imperativo categórico. Professor na Universidade de Marburg (Philipps-Universität Marburg) desde 1940; 1954 professor emérito, continuando a lecionar até 1966. Em outubro de 1945, assumiu o cargo de Reitor Magnífico por ordem das forças de ocupação americanas. Ele era filho do famoso psicólogo Hermann Ebbinghaus.

## Obras
- Gesammelte Aufsätze, Vorträge und Reden. Wissenschaftliche Buchgesellschaft, Darmstadt 1968 (oito ensaios sobre Kant, cinco sobre a história da filosofia e um sobre a filosofia do direito)

Escritos coletados (editados em Bouvier por Hariolf Oberer e Georg Geismann ou Karlfriedrich Herb (volume 4)):
- Bd. 1: Sittlichkeit und Recht, Praktische Philosophie 1929–1954, Bonn 1986;
- Bd. 2: Philosophie der Freiheit, Praktische Philosophie 1955–1972, Bonn 1988;
- Bd. 3: Interpretation und Kritik, Schriften zur Theoretischen Philosophie und zur Philosophiegeschichte 1924–1972, Bonn 1990;
- Bd. 4: Studien zum Deutschen Idealismus, Schriften 1909–1924, Bonn 1994
- Philosophische Studien aus dem Nachlaß, Würzburg 2013

- Die Atombombe und die Zukunft des Menschen (zum gleichnamigen Werk von Karl Jaspers), in: Studium generale: Zeitschrift für interdisziplinäre Studien 10/3 (1957), S. 144–153.

wikiname: ptwiki

title: Julius Ebbinghaus

in_language: pt

wikitext:
'''Julius Ebbinghaus''' ([[9 de novembro]] de 1885, [[Berlim]] - [[16 de junho]] de 1981, [[Marburg an der Lahn]]) foi um filósofo alemão, um dos seguidores mais próximos de [[Immanuel Kant]] no século XX. Ele foi influenciado pela escola de [[neokantismo]] de Heidelberg de [[Wilhelm Windelband]], e escreveu sobre filosofia do direito e o [[imperativo categórico]]. Professor na [[Universidade de Marburgo|Universidade de Marburg]] (Philipps-Universität Marburg) desde 1940; 1954 professor emérito, continuando a lecionar até 1966. Em outubro de 1945, assumiu o cargo de Reitor Magnífico por ordem das forças de ocupação americanas. Ele era filho do famoso psicólogo [[Hermann Ebbinghaus]].<ref>Christian Weber: Max Kommerell: Eine Intellektuelle Biographie, de Gruyter, Berlin 2011, 253</ref>

== Obras ==

* ''Gesammelte Aufsätze, Vorträge und Reden''. Wissenschaftliche Buchgesellschaft, Darmstadt 1968 (oito ensaios sobre Kant, cinco sobre a história da filosofia e um sobre a filosofia do direito)

Escritos coletados (editados em Bouvier por Hariolf Oberer e Georg Geismann ou Karlfriedrich Herb (volume 4)):

* Bd. 1: ''Sittlichkeit und Recht, Praktische Philosophie 1929–1954'', [[Bona|Bonn]] 1986;
* Bd. 2: ''Philosophie der Freiheit, Praktische Philosophie 1955–1972'', Bonn 1988;
* Bd. 3: ''Interpretation und Kritik, Schriften zur Theoretischen Philosophie und zur Philosophiegeschichte 1924–1972'', Bonn 1990;
* Bd. 4: ''Studien zum Deutschen Idealismus, Schriften 1909–1924'', Bonn 1994
* Philosophische Studien aus dem Nachlaß, Würzburg 2013

* ''Die Atombombe und die Zukunft des Menschen'' (zum gleichnamigen Werk von [[Karl Jaspers]]), in: Studium generale: Zeitschrift für interdisziplinäre Studien 10/3 (1957), S. 144–153.

== Referências ==
<references />

== Ligações externas ==

* {{DNB-Portal|116319437}}
* {{LAGIS|ref=nein|DB=HBN|ID=116319437|titel=Ebbinghaus, Julius Karl Ludwig|datum=2020-05-13}}

[[Categoria:Filosofia]]


text:
# Tarvos (satélite)
Tarvos, ou Saturno XXI, é um satélite natural irregular de Saturno. Ele foi descoberto por John J. Kavelaars em 23 de setembro de 2000, e recebeu a designação temporária S/2000 S 4. Tarvos foi nomeado em agosto de 2003, e recebeu o nome de uma divindade gaulesa descrita como um deus touro levando três guindastes paralelamente à sua volta.
Tarvos orbita Saturno a uma distância média de 18 milhões de quilômetros em 926 dias e tem cerca de 15 km de diâmetro (assumindo um albedo de 0,04). É o satélite de Saturno com a maior excentricidade orbital.
É um membro do grupo gaulês de satélites irregulares.
Baseando-se em sua órbita e cor, pensa-se que Tarvos se originou da quebra de um progenitor comum, ou é um fragmento de Albiorix.

title: Tarvos (satélite)

wikitext:
{{info/Planeta |
 | nome               = Tarvos
 | imagem             =
 | categoria          = Satélite [[Saturno (planeta)|Saturno XXI]]
 | ref_órbita         = <ref name=JPL>{{citar web
  |data=2007-06-28
  |título=Planetary Satellite Mean Orbital Parameters
  |publicado=JPL/NASA
  |autor =Jacobson, R.A. (2007) SAT270, SAT271
  |url=http://ssd.jpl.nasa.gov/?sat_elem#saturn
  |acessodata=07/08/2010}}</ref>
 | eixo_sm            = 18 263 200 [[quilômetro|km]]
 | circunferência_orb =
 | excentricidade     = 0,5309
 | periastro          =
 | apoastro           =
 | período_rev        = 925,85 [[dia|d]] (2,53 [[ano|a]])
 | vel_orb            = ?
 | inclinação         = 35,949
 | arg_peri           = 277,448°
 | no_asc             = 89,356°
 | satélites          =
 | ref_físicas        =
 | diam_eq            = 15<ref name="Sheppard">{{citar web
  |título=Saturn's Known Satellites
  |publicado=Department of Terrestrial Magnetism
  |autor =Scott Sheppard
  |url=http://www.dtm.ciw.edu/users/sheppard/satellites/satsatdata.html
  |acessodata=07/08/2010}}</ref>
 | área_sup           = ?
 | volume             =
 | massa              = ?
 | densidade          = ?
 | gravidade          =
 | dia_sid            = ?
 | vel_escape         = ?
 | incli_axial        =
 | albedo             = 0,04
 | T_min              =
 | T_max              =
 | T_med              = ?
 | magnitude          = 22,1<ref name="Sheppard"/>
 | magnitude_abs      =
 | pressão_atm        = Inexistente
 | ref_atmosfera      =
 | atmosfera_perc     =
 | atmosfera_elem     =
}}

'''Tarvos''', ou '''Saturno XXI''', é um [[satélite natural]] irregular de [[Saturno (planeta)|Saturno]]. Ele foi descoberto por [[John J. Kavelaars]] em [[23 de setembro]] de [[2000]], e recebeu a designação temporária '''S/2000 S 4'''. Tarvos foi nomeado em [[agosto]] de [[2003]], e recebeu o nome de uma divindade gaulesa descrita como um [[mitologia|deus]] [[touro]] levando três guindastes paralelamente à sua volta.<ref>[http://cfa-www.harvard.edu/iauc/08100/08177.html IAUC 8177: ''Satellites of Jupiter, Saturn, Uranus''] 8 de agosto de 2003 (nomeando a lua)</ref>

Tarvos orbita Saturno a uma distância média de 18 milhões de [[quilômetro]]s em 926 [[dia]]s e tem cerca de 15 km de [[diâmetro]] (assumindo um albedo de 0,04).<ref name=JPL/><ref name="Sheppard"/> É o satélite de Saturno com a maior [[excentricidade orbital]].

É um membro do [[grupo gaulês]] de [[Satélite irregular|satélites irregulares]].

Baseando-se em sua [[órbita]] e cor, pensa-se que Tarvos se originou da quebra de um progenitor comum,<ref name="Grav2003">[[Tommy Grav|Grav, Tommy]]; [[Matthew J. Holman|Holman, Matthew J.]]; Gladman, Brett J.; [[Kaare Aksnes|Aksnes, Kaare]]; [http://arxiv.org/abs/astro-ph/0301016 ''Photometric survey of the irregular satellites''], Icarus, '''166''' (2003), pp. 33-45</ref><ref name="Gladman2001">Gladman, B. J.; [[Philip D. Nicholson|Nicholson, P. D.]]; Burns, J. A.; Kavelaars, J. J.; [[Brian G. Marsden|Marsden, B. G.]]; Holman, M. J.; Grav, T.; [[Carl W. Hergenrother|Hergenrother, C. W.]]; [[Jean-Marc Petit|Petit, J.-M.]]; [[Robert A. Jacobson|Jacobson, R. A.]]; and [[William J. Gray|Gray, W. J.]]; [http://www.nature.com/nature/journal/v412/n6843/abs/412163a0.html ''Discovery of 12 satellites of Saturn exhibiting orbital clustering''], Nature, '''412''' (July 12, 2001), pp. 163–166</ref> ou é um fragmento de [[Albiorix (satélite)|Albiorix]].<ref name="Grav2006">Grav, Tommy; and [[James Bauer|Bauer, J.]]; [http://arxiv.org/abs/astro-ph/0611590 ''A deeper look at the colors of Saturnian irregular satellites'']</ref>

== Referências ==

{{reflist}}

{{Luas de Saturno}}
{{esboço-satélite natural}}

[[Categoria:Luas de Saturno]]

title: Características orbitais

Velocidade orbital média: ? km/s

title: Características físicas

Diâmetro equatorial: 15 km

Área da superfície: ? km²

Massa: ? kg

Densidade média: ? g/cm³

Velocidade de escape: ? km/s

Temperatura: média: ? ºC

title: Composição da atmosfera

Pressão atmosférica: Inexistente


text:
# Millana
Millana est une commune d'Espagne de la province de Guadalajara dans la communauté autonome de Castille-La Manche.

title: Millana

wikitext:
{{Infobox Commune d'Espagne
|nom         = Millana
|image       = Millana-Casas,_calles_01.JPG
|légende     = Église Saint-Dimanche de Shiloh à Millana
|drapeau     =
|blason      =
|gentilé     =
|fondation   =
|commauto    = {{Castille-La Manche}}
|province    = {{Province de Guadalajara}}
|Comarque    =
|district    =
|cp          =
|superficie  = 27.81
|altitude    =
|distance    =
|population  =
|année_pop   =
|rivières    =
|mer         =
|longitude   =
|latitude    =
|géolocalisation =Espagne/Castille-La Manche
|st-patron   =
|unesco      =
|maire       =
|parti       =
|mandat maire=
|budget      =
|annéebud    =
|siteweb     =
|refgen      =
|refcul      =
|refgeo      =
|refpol      =
}}
'''Millana''' est une [[Municipalité (Espagne)|commune d'Espagne]] de la [[province de Guadalajara]] dans la [[Communautés autonomes d'Espagne|communauté autonome]] de [[Castille-La Manche]].

== Géographie ==
{{...}}

== Histoire ==
{{...}}

== Culture ==
{{...}}

{{Palette Communes de la province de Guadalajara}}

{{Portail|Castille-La Manche}}

[[Catégorie:Commune dans la province de Guadalajara]]

title: Administration

Pays: Espagne

Communauté autonome: Castille-La Manche

Province: Province de Guadalajara

title: Démographie

title: Géographie

Coordonnées: 40° 30′ 31″ nord, 2° 34′ 11″ ouest

title: Localisation

Localisation: modifier


text:
# Peter Petrovich Dolgorukov (general, born 1744)
Prince Peter Petrovich Dolgorukov (Russian: Князь Пётр Петрович Долгоруков, romanized: Knyaz Pyotr Petrovič Dolgorukov; 1744–1815) was a Russian infantry general. He served as governor of Kaluga and Moscow and commanded the Tula Arms Plant. He was the aide-de-camp of Alexander I as a young soldier. His three sons Vladimir, Peter and Mikhail were also all generals.
During the Orlov revolt, he led the failed siege of Modon.

wikiname: enwiki

in_language: en

wikitext:
{{Short description|Russian infantry general}}
{{Use dmy dates|date=August 2022}}
{{multiple issues|
{{more citations needed|date=May 2017}}
{{expand Russian|date=May 2023|topic=bio}}
}}
[[File:P.P.Dolgorukov.jpg|thumb|right|'''Peter Petrovich Dolgorukov''']]

'''Prince Peter Petrovich Dolgorukov''' ({{langx|ru|Князь Пётр Петрович Долгоруков|[[Knyaz]] Pyotr Petrovič Dolgorukov}}; 1744–1815) was a Russian infantry general. He served as governor of [[Kaluga]] and [[Moscow]] and commanded the [[Tula Arms Plant]]. He was the aide-de-camp of [[Alexander I of Russia|Alexander I]] as a young soldier. His three sons [[Vladimir Petrovich Dolgorukov|Vladimir]], [[Peter Petrovich Dolgorukov (1777-1806)|Peter]] and [[Mikhail Petrovich Dolgorukov|Mikhail]] were also all generals.<ref>{{cite web |url=https://ru.wikisource.org/wiki/%D0%AD%D0%A1%D0%91%D0%95/%D0%94%D0%BE%D0%BB%D0%B3%D0%BE%D1%80%D1%83%D0%BA%D0%BE%D0%B2%D1%8B_%D0%B8_%D0%94%D0%BE%D0%BB%D0%B3%D0%BE%D1%80%D1%83%D0%BA%D0%B8%D0%B5|title=ЭСБЕ/Долгоруковы и Долгорукие|website=ru.wikisource.org|language=ru|access-date=1 June 2023}}</ref>

During the [[Orlov revolt]], he led the [[Siege of Modon (1770)|failed]] siege of [[Methoni, Messenia|Modon]].

==References==
{{Reflist}}

==External links==
*{{Commons-inline}}
{{Authority control}}
{{DEFAULTSORT:Dolgorukov, Peter}}
[[Category:1744 births]]
[[Category:1815 deaths]]
[[Category:Dolgorukov family|Peter]]
[[Category:People of the Russo-Turkish War (1768–1774)]]
[[Category:Imperial Russian Army generals]]

{{Russia-mil-bio-stub}}


text:
# جاینت سیلوا
جاینت سیلوا (انگلیسی: Giant Silva؛ زادهٔ ۲۱ ژوئیهٔ ۱۹۶۲) بازیکن بسکتبال، ورزشکار هنرهای رزمی ترکیبی و کشتی‌گیر کشتی حرفه‌ای اهل برزیل است.

title: جاینت سیلوا

wikitext:
{{Infobox professional wrestler
| name = جاینت سیلوا
| image = Giant_Silva_3.jpg
| caption =
| birth_name =
| birth_date = {{birth date and age|1962|7|21}}
| birth_place = [[سائو پائولو]]
| resides =
| children =
| names =
| debut = ۱۹۹۷
| retired = ۲۰۱۱
| sport = [[بسکتبال]]
| nationality = [[برزیل]]
}}
'''جاینت سیلوا''' ({{lang-en|Giant Silva}}؛ زادهٔ {{birth date|1962|7|21}}) [[بازیکن بسکتبال]]، [[ورزشکار]] [[هنرهای رزمی ترکیبی]] و [[کشتی‌گیر کشتی حرفه‌ای]] اهل [[برزیل]] است.

== منابع ==
{{پانویس|چپ‌چین=بله}}
* {{یادکرد-ویکی|پیوند =//en.wikipedia.org/w/index.php?title=Giant_Silva&oldid=1080708496|عنوان = Giant Silva|زبان =انگلیسی|بازیابی =۹ آوریل ۲۰۲۲}}

{{-}}

== پیوند به بیرون ==
{{انبار-رده}}

{{بازیکن بسکتبال-خرد}}

{{ترتیب‌پیش‌فرض:سیلوا، جاینت}}
[[رده:افراد زنده]]
[[رده:افراد مبتلا به غول‌پیکری]]
[[رده:بازیکنان بسکتبال بازی‌های المپیک برزیل]]
[[رده:بازیکنان بسکتبال در المپیک تابستانی ۱۹۸۸]]
[[رده:بازیکنان بسکتبال مرد اهل برزیل]]
[[رده:بازیکنان سنتر (بسکتبال)]]
[[رده:رزمی‌کاران ترکیبی مرد اهل برزیل]]
[[رده:زادگان ۱۹۶۳ (میلادی)]]
[[رده:ورزشکاران جوجیتسو برزیلی اهل برزیل]]

title: جاینت سیلوا

زاده: ۲۱ ژوئیهٔ ۱۹۶۲ (۶۲ سال) · سائو پائولو

title: کشتی‌گیری حرفه‌ای

آغاز: ۱۹۹۷

بازنشستگی: ۲۰۱۱