Documentacion Cloud Connect

Version 1.0

Autores: Ivan Fortunesky, Juan Moleon, Leonardo Gonzalez, Cristian Ramos y Agustin Paulo
Tabla de contenido

1. Definicion Servicio Cloud Connect

2. Topologia de Alto nivel
3. Mellanox y Cumulus
4. Troubleshooting básico.
Definición Servicio Cloud Connect

Cloud Connect es un servicio de conectividad a la nube otorgado por un proveedor de Cloud computing
(Amazon, Google, Azure, etc) a sus clientes para que los mismos a través de uno o más enlaces
dedicados puedan conectar uno o más sitios directamente a dicho proveedor, así el usuario final pueda
hacer uso de las herramientas ofrecidas por el Cloud provider.

Neutrona es partner directo con AWS (Amazon), Azure (Microsoft) y Google, los cuales tienen presencia
y conexión directa con Neutrona en USA y Brasil. Esto con el fin de ser uno de los proveedores de
transporte entre los proveedores de Cloud anteriormente mencionados y el cliente final en cualquier
parte de Latinoamérica, como se muestra en la ilustración 1.

Ilustración 1 Diagrama general de la conexón al proveedor de Cloud.

Para más información sobre que proveedores son partners directos en cada continente, ingresar a los
siguientes links:

https://aws.amazon.com/es/directconnect/partners/

La solución puede abarcar desde conexiones punto a punto, punto – multipunto, transporte L3 o L2 y
con dobles conexiones entre dos o más proveedores de Cloud; cada solución puede variar según las
necesidades del cliente.

Como se puede observar en la Ilustración 2, el circuito se divide en tres partes:

 Cloud Connectivity: Segmento de conexión entre Neutrona y el proveedor de Cloud.

 Backbone: Segmento de transporte entre el proveedor de Cloud y el cliente final.
 Access: Es el último tramo del circuito donde el proveedor local correspondiente al país se
encarga de transportar la información hasta el cliente final.
 Ilustración 2 Diagrama de alta escala de un circuito

Que vende Neutrona?

Neutrona vende el servicio de transporte entre los proveedores de Cloud y el cliente final a través de la
plataforma de los mismos. Dentro de las soluciones que ofrece Neutrona se encuentran las siguientes:

 Single and MultiCloud – Fiber to customer premises.

Esta solución consta de una o múltiples conexiones a diferentes proveedores de Cloud hacia un
cliente final con una o varias sedes en uno o más países dentro Latinoamérica. En este caso el
transporte es realizado por Neutrona hasta el PoP local que conecta a un proveedor de última
milla que llega al sitio del cliente con fibra.
Single and MultiCloud – Bring your own Access (SDWAN)

Esta solución permite brindarle al cliente conectividad a uno o mas proveedores de Cloud y
realizar el transporte hacia los diferentes PoPs a través del backbone de Neutrona, el como
punto diferencial para tener en cuenta es que el transporte local lo realiza el cliente final a
través de su propio enlace de internet, recibiendo un equipo Citrix SD-WAN mediante el cual se
levanta el túnel sobre internet a un concentrador en el POP más cercano, donde se tiene un
concentrador
(Mas información sobre SD-WAN en el próximo programa, espero que les haya gustado)

Nota: En esta configuración se elimina la demora generada por la contratación y despliegue de

la última milla, todo va a depender de la calidad del enlace de internet que el cliente tenga.
  Inter Cloud Connectivity – (Intra and Inter-region)

Esta solución transporta el enlace de Cloud para los diferentes proveedores dentro de una
misma región o entre diferentes regiones. Básicamente, es un circuito de transporte de Cloud a
Cloud.

Cloud Exchange Service (DCI)

Este es un producto usado para brindarle a un cliente con prescencia en un POP, transito a
través de nuestro backbone hacia los Cloud providers.
Topologia

Salvo la excepción del Pop de Miami, donde tenemos 4 switches (2 por rack), en los Pops que son parte
del proyecto tenemos 2 Mellanox SN2100, actualmente con Cumulus OS 3.4, redundantes Activo-
Backup.

Las conexiones con los Cloud provider’s se encuentran en los siguientes POPs:
Los POPs que son parte de la red overlay de Cloud Connect son los siguientes:

PAIS POP Hostname primary Hostname Secondary

1 ARGENTINA LEVEL3 ARGBUELVLCC1SP1A ARGBUELVLCC1SP1B

2 SP2 BRASAOSP2CC1SP1A BRASAOSP2CC1SP1B

BRAZIL
3 SP4 BRASAOSP4CC1SP1A BRASAOSP4CC1SP1B

4 CHILE LEVEL3 CHISCLLVLCC1SP1A CHISCLLVLCC1SP1B

5 PERU LEVEL3 PERLIMLVLCC1SP1A PERLIMLVLCC1SP1B

6 COLOMBIA WBP COLBOGWBPCC1SP1A COLBOGWBPCC1SP1B

7 COSTA RICA UFINET CRCSJOUFICC1SP1A CRCSJOUFICC1SP1B

CIUDAD DE
8 MEXINTINTCC1SP1A MEXINTINTCC1SP1B
MEXICO MEXICO

9 QUERETARO MEXQROQROCC1SP1A MEXQROQROCC1SP1B

LAX USALAXLA1CC1SP1A USALAXLA1CC1SP1B

10

USA
MIA RACK 1 USAMIAMI1CC1SP1A USAMIAMI1CC1SP1B
11
MIA RACK 2 USAMIAMI1CC2SP1A USAMIAMI1CC2SP1B

Pueden encontrar el sumario de con toda la información sobre los POPs, racks y equipos en el siguiente
link:

https://www.dropbox.com/home/Cloud%20Connect%20Project/2.%20Product%20Definition/Hostname
%20convention?preview=Hostname+sumary+-+phase1.xlsx
Por el momento, como no tenemos clientes ni ultimas millas directamente conectados (Por cuestiones
técnicas especificas del software) tenemos un uplink de 10Gb, interfaz que esta pinchada dentro de una
VRF de transporte en nuestro backbone y un downlink de 1Gb, que estra dentro de un Aggregate
Ethernet en el JunOs, donde se configuran los servicios.}

Ejemplo de la conexión MX-Mellanox en Los Angeles.

Ejemplo de la conexión final para un servicio en Azure (NNI Side).

Cada switch tiene su propio sistema autónomo privado, el cual se usa para una sesión eBGP contra el
MX del POP a donde están conectados, y una sesión eBGP hacia todos los otros switches en la red (Full
mesh).

La sesión BGP entre Cumulus usa la familia EVPN, con la cual levanta un túnel de capa 2 (Similar a una
VPLS) para el transporte de MACs. A cada túnel le corresponde una VNI (Simil vlan) por lo que para ver la
mac que tenemos en un servicio, podemos ver la que aprende una VNI especifica (Detallado mas
adelante en el capítulo de troubleshooting).

Esta nueva red lógica es una red “Overlay”, siendo el “Underlay” nuestro backbone MPLS, por donde se
transporta el trafico a través de una VRF

VRF Transporte: vrf-CLOUD_CONNECT

VRF MGMT: vrf-NNI-CC_MGMT

Mellanox y Cumulus

¿Qué es Cumulus Linux?

Cumulus Linux como su nombre lo indica es una distribución del Sistema Operativo Linux. A diferencia
de otras distribuciones Linux, Cumulus esta específicamente creada para ser utilizada en White boxes
(dispositivos de Networking que no poseen sistema operativo, es decir, solo el hardware).

En nuestro caso la marca de la “White box” que vamos a utilizar va a ser Mellanox.

Al igual que toda distribución Linux, Cumulus, está dentro de la comunidad GNU open source, lo cual
quiere decir, entre otras cosas, que no posee algún tipo de licencia para habilitar características en el
SO.

¿Para qué se usa?

Cumulus es simplemente el sistema operativo que vamos a poner en los equipos Mellanox, de la misma
manera que tenemos JunOS en los equipos Juniper y IOS en los equipos Cisco. Si bien es un SO diseñado
para networking, al igual que el resto, vamos a tener un poco más de visibilidad sobre las capacidades
del SO a comparación con otros. En simples palabras entraremos en la Shell o línea de comandos del
sistema operativo y desde allí administraremos protocolos, interfaces y demás configuración necesaria,
pero siempre dentro del SO, no como por ejemplo JunOS, que tiene montada una interfaz de comandos
(CLI = Command Line Interface), que en si está dentro de un FreeBSD.

En resumidas cuentas, Utilizaremos el sistema operativo Cumulus para administrar el equipo, no con
una interfaz de comandos sino con binarios (es decir una aplicación dentro del SO para administrar a la
cual llamaremos cada vez que tengamos que agregar alguna línea de configuración o hacer un Tshoot) o
bien modificando los archivos del sistema operativo, ya sea para interfaces o protocolos.
¿Como acceder?

Para acceder a los Cumulus, es necesario primero ingresar por ssh a un jump host. Por el momento el
que vamos a usar es el Ubuntu 7.188.101.212 (User: ubuntu Pass: Neutrona1)

Las IPs de management de los equipos están por DHCP, por lo que tendremos que entrar por hostname.

Una vez adentro del Jumphost, usamos la IP del equipo que queremos entrar con el comando SSH en el
Shell de Linux, usando -l para especificar el usuario.

Todos los Cumulus en la red actualmente tiene las siguientes credenciales locales.

User: cumulus

Pass: CumulusLinux!

Lista de hostnames:

Hostname primary Hostname Secondary

ARGBUELVLCC1SP1A ARGBUELVLCC1SP1B

BRASAOSP2CC1SP1A BRASAOSP2CC1SP1B

BRASAOSP4CC1SP1A BRASAOSP4CC1SP1B

CHISCLLVLCC1SP1A CHISCLLVLCC1SP1B

PERLIMLVLCC1SP1A PERLIMLVLCC1SP1B

COLBOGWBPCC1SP1A COLBOGWBPCC1SP1B

CRCSJOUFICC1SP1A CRCSJOUFICC1SP1B

MEXINTINTCC1SP1A MEXINTINTCC1SP1B

MEXQROQROCC1SP1A MEXQROQROCC1SP1B

USALAXLA1CC1SP1A USALAXLA1CC1SP1B
 USAMIAMI1CC1SP1A USAMIAMI1CC1SP1B

USAMIAMI1CC2SP1A USAMIAMI1CC2SP1B

En caso de no funcionar el servidor DNS, podemos ver las IPs de management por ARP en los MX de
cada POP.

Usamos LLDP para saber que IP corresponde a que equipo (A (primario) o B(secundario))
El sistema operativo y NCLU

Como mencionamos anteriormente, al ingresar al SO, este nos brindara un Shell en el cual
podremos configurar el equipo en cuestión, pero, a diferencia de otros SO de equipos este no nos
brindara una interfaz para poder configurar y mostrar las características de networking.

Para esto el SO utiliza un binario llamado NCLU (Network Command Line Utility ). Esto es,
simplemente un conjunto de comandos simplificados que con una línea de configuración modifican
archivos dentro del sistema y por consiguiente el comportamiento del equipo, pero de manera
simplificada.

El NCLU esta basado en comandos básicos de networking, la única diferencia es que antepone la
palabra NET para cada comando.

net show configuration

net commit

net add interface swp7

net show bgp

Vale aclarar que todo lo que se puede hacer a través de una sencilla línea con NCLU también se puede
hacer modificando archivos en el SO, pero claramente es mas engorroso.

Archivos de configuración del SO (Cumulus Linux)

Si bien el NCLU nos simplifica la configuración y administración del equipo en cuestión, algunas veces es
necesario modificar ciertos atributos relacionados a la configuración ya sean cuestiones físicas o lógicas
a través del SO. Esto lo haremos en los archivos de configuración, para lo cual utilizaremos NANO, un
editor de texto básico y estándar del sistema operativo Cumulus Linux. Ej.:

cumulus@CHISCLLVLCC1SP1A:mgmt-vrf:~$ nano /etc/network/interfaces

Nos da acceso a la pantalla de edición del archivo interfaces, que esta en la ruta /etc/network/
Los archivos de configuración usados más frecuentemente en Networking son los siguientes:
Troubleshooting the Switches Mellanox con SO Cumulus Networks 3.4

Una vez adentro de la caja, podemos empezar revisando que los sensores de PSU y Hardware tengan
valores normales. Como de momento no tenemos casos reales con servicios en producción para mostrar
un troubleshooting, vamos a ver los principales comandos que podemos usar para encontrar un
problema en la caja y con un servicio de prueba.

Ya que los servicios en los Cumulus son configurados por un proceso automatizado, no debería de haber
errores de configuración y como la sintaxis es bastante diferente a lo que estamos acostumbrados, nos
vamos a centrar principalmente en comandos de diagnóstico.

Recordar que es probable, al ser Linux, necesitemos anteponer el comando “Sudo” a los comandos para
conseguir los permisos necesarios.

Estado de las PSU

Nos devuelve el estado actual de las fuentes redundantes de los Mellanox.

CUMULUS @CHISCLLVLCC1SP1A: MGMT - VRF :~$ SMONCTL -V -S PSU1

PSU1: OK

CUMULUS @CHISCLLVLCC1SP1A: MGMT - VRF :~$ SMONCTL -V -S PSU2

PSU2: OK

Sensors

Nos muestra los valores actuales de los sensores de voltaje y temperatura del hardware.

cumulus@CHISCLLVLCC1SP1A:mgmt-vrf:~$ sensors
mlnx-a2d-mnb-drv-i2c-4-6d
Adapter: i2c-2-mux (chan_id 1)
ddr3_0.675: +1.66 V (min = +0.61 V, max = +0.74 V)
cpu_0.9: +1.66 V (min = +0.81 V, max = +0.99 V)
sys: +3.28 V (min = +2.97 V, max = +3.63 V)
Para ver los niveles de señal en las interfaces opticas podemos usar la utilidad ethtool, con la siguiente
sintaxis. La misma se puede grepear para obtener un dato en especifico

sudo ethtool -m swp7

sudo ethtool -m swp7 | grep Receiver

sudo ethtool -m swp7 | grep output

Net show interface

Net show interfaces

Comando tipico para ver el estado de las interfaces.

CUMULUS @CHISCLLVLCC1SP1A: MGMT - VRF :~$ NET SHOW INTERFACE

NAME MASTER SPEED MTU MODE REMOTE HOST R EMOTE PORT

SUMMARY

-- ------------- -------- ------- ----- ------------- ---------------- ----

UP LO N/A 65536 LOOPBACK IP:

127.0.0.1/8, 10.100.32.11/32, 10.100.64.6/32,

UP ETH0 MGMT 1G 1500 MGMT CHISCLLVL1R1-RE 0 GE -0/1/7

IP: 10.100.3.33/26(DHCP)
ETHTOOL: Niveles de potencia en las SFP
La utilidad ETHTOOL -M XXX nos da información sobre el transceiver y los valores de voltaje y potencia.

(Ejemplo resumido)

CUMULUS @CHISCLLVLCC1SP1A: MGMT - VRF :~$ SUDO ETHTOOL -M SWP 7

IDENTIFIER : 0X 03 (SFP)

EXTENDED IDENTIFIER : 0X 04 (GBIC/SFP DEFINED BY 2- WIRE INTERFACE

CONNECTOR : 0X 07 (LC)

TRANSCEIVER CODES : 0X 20 0X00 0X00 0X00 0X00 0X 00 0X00 0X00

TRANSCEIVER TYPE : 10G ETHERNET: 10G BASE-LR

……

LASER BIAS CURRENT : 50.068 MA

LASER OUTPUT POWER : 0.6673 MW / -1.76 DBM

RECEIVER SIGNAL AVERAGE OPTICAL POWER : 0.5286 MW / -2.77 DBM

MODULE TEMPERATURE : 41.08 DEGREES C / 105.95 DEGREES F

MODULE VOLTAGE : 3.3081 V

LASER BIAS CURRENT HIGH ALARM THRESHOLD : 85.000 MA

LASER BIAS CURRENT LOW ALARM THRESHOLD : 15.000 MA

LASER BIAS CURRENT HIGH WARNING THRESHOLD : 80.000 MA

LASER BIAS CURRENT LOW WARNING THRESHOLD : 20.000 MA

LASER OUTPUT POWER HIGH ALARM THRESHOLD : 1.5849 MW / 2.00 DBM

LASER OUTPUT POWER LOW ALARM THRESHOLD : 0.1585 MW / -8.00 DBM

LASER OUTPUT POWER HIGH WARNING THRESHOLD : 1.2589 MW / 1.00 DBM

LASER OUTPUT POWER LOW WARNING THRESHOLD : 0.1995 MW / -7.00 DBM

LASER RX POWER HIGH ALARM THRESHOLD : 1.7783 MW / 2.50 DBM

LASER RX POWER LOW ALARM THRESHOLD : 0.0100 MW / -20.00 DBM

LASER RX POWER HIGH WARNING THRESHOLD : 1.5849 MW / 2.00 DBM

LASER RX POWER LOW WARNING THRESHOLD : 0.0158 MW / -18.01 DBM

Loggin

FRR
Nos permite ver el log de eventos del Daemon de routeo FRR (Sesiones BGP)

CUMULUS @CHISCLLVLCC1SP1A: MGMT - VRF :~$ SUDO CAT /VAR /LOG/FRR/FRR.LOG

2018-03-20T21:49:17.984065+00:00 CHISCLLVLCC1SP1A BGPD[1671]: %NOTIFICATION:

RECEIVED FROM NEIGHBOR 10.100.32.21 4/0 (H OLD T IMER E XPIRED ) 0 BYTES

2018-03-20T21:49:17.984551+00:00 CHISCLLVLCC1SP1A BGPD[1671]: %ADJCHANGE: NEIGHBOR

10.100.32.21(BRASAOSP2CC1SP1A) IN VRF DEFAULT DOWN BGP NOTIFICATION RECEIVED

2018-03-20T21:49:20.636270+00:00 CHISCLLVLCC1SP1A BGPD [1671]: %ADJCHANGE: NEIGHBOR

10.100.32.21(BRASAOSP2CC1SP1A) IN VRF DEFAULT UP

Linkstate
Nos permite ver los logs de cambio de estado de las interfaces.

CUMULUS @CHISCLLVLCC1SP1A: MGMT - VRF :~$ SUDO CAT /VAR /LOG/LINKSTATE

2018-03-13T21:09:29.090828+00:00 CHISCLLVLCC1SP1A SWITCHD [1189]: SYNC _ BASE . C :601

BRIDGE INTERFACE VNI 90162, IFINDEX 33, CREATED

2018-03-13T21:09:29.566050+00:00 CHISCLLVLCC1SP1A SWITCHD [1189]: SYNC _ BASE . C :621

VNI 90162: IFINDEX 33, ADMIN UP , PROTODOWN ON

2018-03-13T21:09:29.566637+00:00 CHISCLLVLCC1SP1A SWITCHD [1189]: SYNC _ BASE . C :621

BRIDGE _ PORT : VNI 90162: IFINDEX 33, ADMIN UP

2018-03-13T21:09:30.437509+00:00 CHISCLLVLCC1SP1A SWITCHD [1189]: SYNC _ BASE . C :629

BRIDGE _ PORT : VNI 90162: IFINDEX 33, OPER UP

2018-03-13T21:09:30.438870+00:00 CHISCLLVLCC1SP1A SWITCHD [1189]: SYNC _ BASE . C :629

VNI 90162: IFINDEX 33, OPER UP

Net show bgp summary

Resumen del estado actual de las sesiones BGP configuradas.

CUMULUS @CHISCLLVLCC1SP1A: MGMT - VRF :~$ NET SHOW BGP SUMMARY

SHOW BGP IPV 4 UNICAST SUMMARY

=============================
Net show evpn mac vni all

Nos muestra las MACs que aprendemos por VNI (Similar a ver las MACs en una VPLS, cada VNI
corresponde a un circuito).
 CUMULUS @CHISCLLVLCC1SP1A: MGMT - VRF :~$ NET SHOW EVPN MAC VNI ALL

VNI 90162 #MACS (LOCAL AND REMOTE ) 3

MAC TYPE I NTF/REMOTE VTEP VLAN

28:6F:7F:01:D2:30 REMOTE 10.100.64.1

00:15:AD:40:54:47 LOCAL BOND 0 MX 1002

3C:8A:B0:8E:96:D 0 LOCAL BOND 0 MX 1002

VNI 66666 #MACS (LOCAL AND REMOTE ) 1

MAC TYPE I NTF/REMOTE VTEP VLAN

40:A6:77:A2:F1:5B LOCAL BOND 0 MX 1001

VNI 1023 #MACS ( LOCAL AND REMOTE ) 1

MAC TYPE I NTF/REMOTE VTEP VLAN

40:A6:77:A2:F1:5B LOCAL BOND 0 MX 1000

Net show bridge macs

Nos muestra la table de MACs de todos los bridges configurados.

CUMULUS @CHISCLLVLCC1SP1A: MGMT - VRF :~$ NET SHOW BRIDGE MACS

VLAN MASTER INTERFACE MAC TUNNELDEST S TATE FLAGS

LASTSEEN

-------- -------- ----------- ----------------- ------------ --------- -----

-------- -----------------

1000 BRIDGE BOND 0 MX 40:A6:77: A2:F1:5B

00:00:09

1001 BRIDGE BOND 0 MX 40:A6:77: A2:F1:5B

00:00:09

1002 BRIDGE BOND 0 MX 00:15:AD:40:54:47

00:01:40

1002 BRIDGE BOND 0 MX 3C:8A:B0:8E:96:D0

00:01:40

1002 BRIDGE VNI 90162 28:6F:7F :01:D2:30 OFFLOAD 1

DAY , 02:22:06

UNTAGGED VNI 1023 00:00:00:00:00:00 10.100.64.1 PERMANENT SELF

38 DAYS , 02:28:31

UNTAGGED VNI 1023 00:00:00:00:00:00 10.100.64.2 PERMANENT SELF

38 DAYS , 02:28:31

UNTAGGED VNI 66666 00:00:00:00:00:00 10.100.64.3 PERMANENT SELF

43 DAYS , 02:17:55

UNTAGGED VNI 90162 00:00:00:00:00:00 10.100.64.1 PERMANENT SELF

7 DAYS , 00:50:09

UNTAGGED VNI 90162 00:00:00:00:00:00 10.100.64.2 PERMANENT SELF

7 DAYS , 00:50:09

UNTAGGED VNI 90162 28:6F:7F:01:D2:30 10.100.64.1 SELF , OFFLOAD

1 DAY , 02:22:06

UNTAGGED BRIDGE BOND 0 MX EC :0 D :9 A :4 E : D 3:04 PERMANENT 38

DAYS , 02:41:50

UNTAGGED BRIDGE PEERLINK EC :0 D :9 A :4 E : D 3:3 C PERMANENT 46

DAYS , 02:11:21

UNTAGGED BRIDGE VNI 1023 F 6: BA :0 A : C 8:95: F 1 PERMANENT 38

DAYS , 02:32:51

UNTAGGED BRIDGE VNI 66666 12:42:39:41:86:D 7 PERMANENT 43

DAYS , 02:18:00

UNTAGGED BRIDGE VNI 90162 9E:8D:80:9D:26:C 9 PERMANENT 7

DAYS , 00:50:11