¿En que consiste Q in Q?
Q in Q consiste en hacer un tunnel, el cual permite que usando como transporte una única VLAN(Vlan que estará en la red del operador) transportar todas las VLAN de un trunk 802.1q de un cliente. Es simplemente un sistema de VPN de nivel 2 para cliente, que usa como transporte una red de nivel 2 en el lado de operador.
¿Como funciona?
Intentando no hacer un artículo infumable diremos que lo que hace es añadir doble etiquetado de VLAN, osea a parte del etiquetado de 802.1q que usa el cliente, nosotros volvemos a poner nuestro etiquetado de 802.1q, de este modo cuando los paquetes atraviesan la red del operador lo único a lo que se va a hacer caso es al etiquetado 802.1q de operador, y cuando se llega al otro extremo del tunnel se quita ese etiquetado, y se entrega un trunk normal y corriente.
¿Seguridad?
Tu estás en una red, tu tráfico se encapsula sin prestar atención a lo que hay dentro, es a todos los efectos una VPN de nivel 2.
¿VPLS o Q-in-Q?
VPLS se basa sobre MPLS, el backbone MPLS permite provisionar circuitos de nivel 2 o 3 a nivel nacional, internacional, o lo que abarque el operador. Q-in-Q esta pensado para entornos MAN, en los cuales el operador transporta el tráfico sobre enlaces de nivel 2, no hablamos de MPLS, ni de routing ni nada. Es el ejemplo claro de MetroEthernet. Dicho lo cual, se pueden combinar MPLS y Q-in-Q, pero eso es otra historia.
Ejemplo de configuración:
PE del Site 1:
int gi1/1 <----contra el cliente A en el site 1
switchport access vlan 10 <---vlan de operador sobre la que transportaremos el trunk
switchport mode dot1q-tunnel
l2protocol-tunnel cdp <----los protocolos son a nivel del tunel, por tanto simplemente hacemos bypass de ellos
l2protocol-tunnel stp
l2protocol-tunnel vtp
int gi1/2 <----contra el cliente B en el site 1
switchport access vlan 20<---vlan de operador sobre la que transportaremos el trunk
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel stp
l2protocol-tunnel vtp
int Tengiga 1/1<---interfaz sobre la que transportaremos nuestras vlanes de operador
switchport mode trunk
switchport trunk allowed vlan 10,20<--- vlanes de operador, cada una transporta una VPN de cliente
PE del Site 2:
int gi1/1 <----contra el cliente B en el site 2¿Implicaciones de Spanning Tree?
switchport access vlan 20 <---vlan de operador sobre la que transportaremos el trunk
switchport mode dot1q-tunnel
l2protocol-tunnel cdp <----los protocolos son a nivel del tunel, por tanto simplemente hacemos bypass de ellos
l2protocol-tunnel stp
l2protocol-tunnel vtp
int gi1/2 <----contra el cliente A en el site2
switchport access vlan 10<---vlan de operador sobre la que transportaremos el trunk
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel stp
l2protocol-tunnel vtp
int Tengiga 1/1<---interfaz sobre la que transportaremos nuestras vlanes de operador
switchport mode trunk
switchport trunk allowed vlan 10,20<--- vlanes de operador, cada una transporta una VPN de cliente
El cliente interactuará entre sus lans como si fuesen switches directamente conectados, a efectos prácticos es como una LAN. Por tanto el cliente con su STP, y el operador con el suyo propio, por supuesto cualquier cambio de STP en el proveedor afecta al cliente en forma de corte.
bien ahi man con la info!!
ResponderEliminarqueria consultarte si sabes algo de HVPLS??
Estimado amigo, muchas gracias por compartir tu conocimiento. Me haz clarificado mucho el tema de Q-in-Q. Una consulta adicional: un cliente que es un Operador, me está solicitando unos Media Converter que soporten Q-in-Q para la adición o remoción del Tag de la VLAN. Si el "taggueo" lo hace el switch... para que se va requerir que un Media Converter haga el trabajo que un switch hace mejor?... podrías clarificarme por favor. Te agradezco tu respuesta a patricio.chiani@gmail.com
ResponderEliminarHola Patricio, siento no haber contestado antes, pero desde que aprobé he estado un poco desconectado.
ResponderEliminarRespondiendo a tu pregunta:
Por lo que yo entiendo, lo que pasa es que tu operador te esta ofreciendo una única VLAN, y lo que quiere es que sea tu Switch o Media Converter el que cree el QinQ.
Si miras el dibujo que he puesto en este mismo artículo, lo que pasaría es que tu operador te daría una VLAN como la Vlan10 del dibujo, y el operador dejaría su puerto en access en esa misma vlan, luego sería el media converter o un switch el que haría el QinQ.
En España esa labor que se suele hacer en los PE suele hacerla el operador, y tan solo hay que conectar un switch que tendría un trunk con las vlans del cliente, hay otros paises en los que el cliente debe hacer el doble etiquetado.
Te pongo un link con un media converter que hace QinQ, y explica un poco como lo hace, si te fijas lo que hace aquí el media converter es la labor que tiene el PE en mi dibujo.
http://www.ctsystem.com/newsroom/NewsHistoryDtl.aspx?NewsID=158
Te envío un mail con esto, y si tienes otra duda no dudes en preguntar, que he vuelto al blog, y para quedarme.
Saludos amigo una pregunta yo trabajo con Switch de la empresa ZTE y deseo saber si existe protocolo parecido a VTP para unir 2 Switch y que uno haga la función de servidor y el otro de cliente pero que puedan interactuar las vlan de ambos switch, cuando yo configure un puerto Trunk en uno de los Switch pueda tener acceso a una vlan ubicada en el otro Switch.
ResponderEliminarNetworkers del mundo: Tengo una duda-problema.
ResponderEliminarTengo mis switch con soporte QinQ en ambos extremos de una red L2 (switches y radios) -que no soportan QinQ, solo vlanas 802.1q, que yo no administro y que me darán solo UNA vlan- La consulta; Mi "supervlan" por llamarlas de una forma, que contienen todas mis VLANs, pueden ser transportadas por LA unica Vlan que me da esta red. Ojo; La red NO soporta QinQ, solo los mis switch en ambos extremos.
Si, porque la trama no es afectada. Para los equipos que no soportan QnQ solo vera 1 VLAN.
Eliminarexcelente explicacion, muchas gracias. PD: algo que me entrevara un poco es porque un operador en el backbone usaria un enlace QinQ entre 2 de sus switches, en lugar de usar un trunk comun.
ResponderEliminarSaludos!
Puede utiliza QinQ entre los switches para cambiar las VLANs externas, pero no afectaría las VLANs internas. Esto se hace ha veces porque las VLANs en el operador pueden estar ya utilizadas en sus equipos (Vlans externas) para otro cliente.
Eliminarexcelente explicacion, muchas gracias. PD: algo que me entrevara un poco es porque un operador en el backbone usaria un enlace QinQ entre 2 de sus switches, en lugar de usar un trunk comun.
ResponderEliminarSaludos!
Ramiro3331, eso te lo puedo responder yo:
ResponderEliminarNosotros somos un ISP que estamos adentrándonos en ser operadores con un proyecto de CWDM. Este protocolo nos permite sobre la misma capa de switches, entregar enlaces redundados a nuestros clientes de conexión entre dos CPDs independientemente de las VLANs que usen.
Si utilizarámos trunk para entrega de esos enlaces, existiría la posibilidad de que las VLANs de varios clientes (cliente A y cliente B) fueran las mismas, y tuviéramos conflictos de VLANs y seguridad.
Ivan, excelente artículo.
"¿Implicaciones de Spanning Tree?
ResponderEliminarEl cliente interactuará entre sus lans como si fuesen switches directamente conectados, a efectos prácticos es como una LAN. Por tanto el cliente con su STP, y el operador con el suyo propio, por supuesto cualquier cambio de STP en el proveedor afecta al cliente en forma de corte."
Citando este texto, por lo que estuve investigando, existe la manera de denegar el STP del operador en el trafico del cliente.
Quitando esto, el articulo me gusto mucho. Saludos!
GRACIAS!
ResponderEliminar