Networking on Cisco Redes

BLOG – Podcast Cisco Champion – Unfiltered: Vida de um Cisco Champion

Tue, 04 May 2021 00:00:00 +0000

Olá Pessoal,

Como todos sabem e provavelmente já observaram em nosso site, que cada vez mais está aparecendo esses episódios, ou melhor dizendo o canal de Podcast do Cisco Champion. Isso se deve a estarmos mais ativo nesse canal participando junto com a comunidade, portanto sempre teremos mais posts nesse sentido.

Conforme havia mencionado em nosso último post falando sobre o Catalyst 8000, hoje venho aqui para notificar sobre uma nova ideia que está surgindo na comunidade de falarmos um pouco sobre tópicos variados, e não somente trazendo os conteúdos técnicos ou novidades que estão surgindo do lado da Cisco.

Devido a isso, foi mencionado que vamos seguir com a menção de um conteúdo sem filtros ( rs! ), e já temos vários temas na pauta que serão discutidos durante esse ano. A idéia que tenhamos um podcast nesse estilo a cada 2 meses.

Segue nosso bate papo abaixo:

Se tiver alguma dúvida sobre o programa, ou até mesmo sugerir ou mencionar algo, fique a vontade para me notificar, enviar uma mensagem que sempre temos um canal aberto com os ” managers ” do programa e toda idéia é sempre vista para construir cada vez mais uma comunidade forte e obviamente possamos compartilhar ítens interessantes.

Abs,
Rodrigo

BLOG – Primeiro post sobre Python

Tue, 23 Jun 2020 00:00:00 +0000

Olá Pessoal,

Como podem observar pelo título, digo que hoje será nosso primeiro post efetivamente relacionado a Python, e de fato tenho que mencionar que vocês também estão certo, pois podemos começar uma nova jornada aqui em nosso BLOG.

Como vocês podem notar em nosso BLOG, eu sempre tento desenvolver algo que de fato é motivacional para mim buscar a informação, pesquisar, desenvolver, concluir, testar e depois tento compartilhar com vocês essa ideia, que por sua vez pode ajudar algum de vocês e também sempre aprendo algo à mais com vocês.

Projeto

Esse papo iniciou-se em um dos grupos e acabei me interessando na ideia, pois de momento pensei em 4 formas para poder utilizar essas facilidades:

Ambiente corporativo tanto a nível de TI Interno, como também para empresas de terceiros, que em muitos casos precisamos executar troubleshooting.
Nível de usuario domestico, para ter algum historico e avaliar se esta de acordo com os planos contratados.
Executar um teste em guest shell em roteadores Cisco rodando diretamente o script Python.
Para aprendizagem sobre os conceitos de Python.

SpeedTest

Acredito que a maioria de vocês em algum momento já utilizou o site do SpeedTest ou qualquer outra variação nesse sentido ( Fast – Netflix, Brasil Banda Larga, OKLA, Cloudflare, etc ).

Talvez muitos de vocês vão achar que estou sendo maluco, pois esses testes muito das vezes não significam muito em troubleshooting, pois nem sempre os valores indicados são reais, já que sempre irá buscar o servidor mais proximo de seu ponto, depende também da disponibilidade desse provedor, não tem preferência esse tráfego, os servidores que estão medindo esse tráfego nem sempre estão disponivéis em estruturas dedicadas, etc.

Também concordo nesses ítens, mas foi um aprendizado para eu aplicar algo em Python, então sempre olhe com outra perspectiva seu aprendizado. Pode ser, que para alguma situação de um leitor, isso possa ser útil, então por isso resolvi compartilhar e não guardar a informação comigo. 🙂

Devemos lembrar que temos uma biblioteca Python definida como speedtest-cli, ou seja, não iremos precisar utilizar um navegador para obter os valores.

Lab

Nesse laboratório utilizei alguns outros conceitos que depois posso detalhar em outros posts, pois a ideia é que esse teste fique em execução, assim pode-se fazer a validação conforme sua necessidade, ou seja, para nosso exemplo eu fiz com que meu script execute automaticamente a cada 30 minutos.

Após esse período, ele irá passar as informações desejadas para um dashboard, onde iremos poder consultar essas informações através da Internet. Esse ambiente que temos é free, porém temos algumas ressalvas, pois a base de dados que fica guardada no dashboard é de 30 dias, podemos ter apenas 3 devices cadastrados e no máximo cada dashboard desses devices pode ter 10 gráficos. A ferramenta que utilizei foi da Ubidots, mas como informado o plano free atende muito bem para estruturar seus testes e ” brincadeiras…rs “.

Segue a estrutura:

Docker Ubuntu – image 18.04
1. Python 2.7
2. Crontab
3. speedtest-cli
4. Python Library request
Conta na Ubidots
Link de Internet ( rsrs )

Código

Conforme mencionando anteriormente iremos utilizar algumas bibliotecas do Python, e a partir dela iremos utilizar as variáveis para construir nosso código. Não tenho também a ideia de explicar toda a estrutura do Python neste momento, pois espero publicar mais ” 101 – Python “ para trazer testes mais lógico e simples.

Com isso, segue o código definido para essa tarefa. Se observarem o código também já esta explicando cada funcionalidade.

#!/usr/bin/python
import speedtest
import requests

#Global variables
ENDPOINT = "things.ubidots.com" #URL related webpage to create dashboard
DEVICE_LABEL = "raspberry-pi" #Not necessary to be raspeberry and can use any linux inside container or run in your machine
VARIABLE_LABEL = "city" #Variable created inside Ubidots portal
TOKEN = "YOUR TOKEN"

#Get value related your connection using library SpeedTest
st = speedtest.Speedtest()

#Get values related class of server near of your provider
st.get_best_server()

#Execute Post Related City and Provider of SpeedTest
def post_var(payload_ci_sp, url=ENDPOINT, device=DEVICE_LABEL, token=TOKEN):
    url = "http://{}/api/v1.6/devices/{}".format(url, device)
    headers = {"X-Auth-Token": TOKEN, "Content-Type": "application/json"}

    if VARIABLE_LABEL == 'city':
        req = requests.post(url=url, headers=headers, json=payload_ci_sp)

    else:
        print("Error with variable City")

#Main function to capture payload each variable(city,provider)
def main():
    # Builds Payload and topic
    payload_ci_sp = {VARIABLE_LABEL: {"value": 30, "context": {"city": st.best['name'], "provider": st.best['sponsor']}}}

    #Send Data
    post_var(payload_ci_sp)

#It only to execute main function + post_var
if __name__ == "__main__":
    main()

#Capture all values related your connection
payload = {'Download': round(st.download() / 1000000, 2) , 'Upload': round(st.upload() / 1000000, 2), 'Ping': round(st.results.ping, 2)}

#Execute post of values
r = requests.post('http://things.ubidots.com/api/v1.6/devices/raspberry-pi/?token='TOKEN'', data=payload)

Dashboard

Após essa estrutura iremos avaliar se de fato as informações estão sendo populadas no portal da Ubidots. Vale lembrar que é necessário abrir uma conta no portal e também gerar uma ” API Key “, pois é através dessa API que você irá conseguir popular suas informações.

Uma outra dica é que para esse dashboard, as variáveis serão populadas através da estrutura como sendo um ” Raspberry PI “, porém como explicado acima não existe a necessidade de ter o equipamento, pois você pode executar através de qualquer equipamento baseando-se em Python 2.7 e versões posteriores.

Isso foi uma forma de utilizar essa facilidade de APIs do fabricante, que já disponibiliza isso através de seu dashboard.

Após obter as informações populadas, você pode montar seu dashboard da forma que achar mais interessante. Eu acabei colocando desta forma.

PS.: Eu coloquei também diferença de cores para simbolizar alguns limites que podem demonstrar para você, como amarelo o threshold 1 já excedeu.

Neste caso acima estou populado os valores bem como mostrando as variavéis que escolhi no meu código Python para representar ” City “ e ” Provider “.

Conclusão

Neste desenvolvimento tentei de fato mais aprender a trabalhar com o Python, bem como tentar transferir informações para outras plataformas, do que propriamente o fato de ser o teste do SpeedTest. Acho que isso de alguma forma incentivou para usar uma situação real e transformar ela em algo mais palpável, do que visualizar isso através de um Browser.

O que vocês acharam? Qual sua opinião sobre a utilização do SpeedTest? Tem pensando em alguma facilidade utilizando Python?

Descreva abaixo em nossos comentários. 🙂

Vale ressaltar que esses códigos eu já havia populado no Github, então se deseja ter mais detalhes ou se deseja contribuir mais com o código fique a vontade. Vai lá para dar uma conferida -> Inet_Validation_Speed

PS.: Um dos testes que estou achando bem mais interessante hoje é da CloudFlare, que tem mostrando o jitter e as variações por banda.

Abs,
Rodrigo

BLOG – Meraki IPSEC + Oracle OCI IPSEC – Parte 2

Tue, 02 Jun 2020 00:00:00 +0000

Olá Pessoal,

Conforme detalhado em nosso post anterior, hoje iremos fazer algumas tratativas relacionado a criação de uma conectividade entre meu ambiente de homelab com a Oracle Cloud ( OCI ).

Talvez vocês se perguntem o que seria isso? Eu já fiz um post onde eu trazia esse mesmo conceito para uma utilização de infra-estrutura dentro da Azure, desta forma vamos fazer nossa tratativa hoje para executar o procedimento e avaliar as facilidades para Oracle.

Topologia

Temos essa topologia simplificada apenas para que vocês tenham em mente o que de fato iremos construir dentro das estruturas, e a forma de que como isso esta se conectando.

Conceito

Hoje em dia muitas estruturas estão sendo movidas para dentro das clouds, podendo denominar-se como públicas e privadas, ou seja, terá momentos que você irá expor seu serviço para Internet, como também você irá ter apenas serviços denominados para funcionarem internamente em sua empresa, desta forma isso não irá precisar ser visto pelo mundo externo.

Pois bem, em nosso teste iremos tratar como sendo uma VCN ( Virtual Cloud Network ) privada, ou seja, todo esse endereçamento irá responder internamente dentro de meu ambiente. Vale lembrar que por default no ambiente Cloud teremos nossa rede interna sendo definida dentro de uma classe A ( 10.0.0.0/16 ), com isso foi definido neste ambiente cloud que nossas máquinas pertencem a rede ( 10.0.1.0/24 ).

Para que isso ocorra temos a necessidade de efetuar uma conexão ( Site-to-Site ) através de nosso conhecido e famoso IPSEC, entre meu ambiente Meraki e a Cloud Oracle ( OCI ). Portanto, eu irei ter acesso diretamente a qualquer ” Server ” ou ” Client “, sendo acessado diretamente via minha rede Interna Meraki.

Passos para Configuração

Vale lembrar que nesse momento não irei detalhar como executar a criação de instâncias ( VMs ) dentro do ambiente Oracle, e também a criação padrão da VCN, pois isso será explicado em outro post, portanto devo notificar que temos 1 host definido internamente no ambiente Cloud com o IP: 10.0.1.2/24.

A partir desse momento devemos seguir alguns passos para efetuar configuração de conectividade entre os ambientes. Segue abaixo o procedimento:

Criar um CPE ( Customer Premises Equipment )\
Criar um Dynamic Routing Gateways\
Criar o tunnel IPSEC

Configuração passo 1

Por definição a cloud exige que você configure um CPE para termos associações atreladas a esta conectividade, com isso eu criei utilizando uma opção como sendo equipamento Cisco ( temos mais vendor associados ), e posteriormente qual seria o IOS ( ASA ou IOS ), que por sua vez selecione 15.1. Vale lembrar que de fato estou utilizando Meraki ( MX64 ), portanto não faz relação com o IOS selecionado, porém minha opinião que isso seria apenas para atrelar algum vendor e de fato posteriormente ele apresenta ” janelas ” que leva a você ao fabricante, para observar e definir as configurações necessárias para esse vendor. Segue abaixo a configuração:

Após concluir os passos podemos observar que nosso CPE foi criado.

Mais detalhes consulte a documentação Oracle – CPE Configuration.

Escolhemos efetuar as configurações com roteamento estático, pois dentro do ambiente Meraki não temos a opção de subir uma sessão BGP via o tunnel IPSEC ( site-to-site )

Configuração passo 2

Na sequência devemos configurar nosso ” Gateway “, que irá fazer associação ao CPE criado, com isso posteriormente iremos definir ambos os componentes para configuração de nosso próximo passo. Segue abaixo:

Após iniciar ficaremos desta forma as configurações. Neste momento não estou utilizando ” tags “, mas isso para crescimento de sua estrutura pode facilitar para selecionar os serviços corretos.

Configuração Passo 3

Enfim, agora vamos definir nosso tunnel IPSEC com os outros dois componentes criados anteriormente. Para isso devemos ir em Networking -> IPSEC Connections.

No ítem 4 da figura acima é a rota estática que iremos definir para que essa infra-estrutura Cloud possa acessar minha rede local do homelab ( portanto redes atrás do MX ), se tiver mais sub-redes você pode adicionar.

Após isso clique em ” Show Advanced Options ” para selecionar alguns ítens essenciais para seu IPSEC. Um recurso interessante que pode facilitar é que temos como definir via ” FQDN ” seu CPE remoto.

Após isso precisamos definir ” Tunnel ” agregando uma “ shared key ” e a versão do IKE ( já comentado acima ). Vale lembrar que não teremos uma interface tunnel para nosso Meraki, pois iremos criar o tunelamento apenas via o IPSEC.

Após finalizar, pode observar que vai levar uns 5 minutos para o ambiente provisionar essas configurações e logo após você já pode verificar que o status fica ” Available “.

Caso esteja tudo correto em ambos os lados ( Oracle + Meraki ) você poderá observar seu IPSEC está ” UP “.

PS.: Por padrão o dashboard Oracle cria automaticamente dois tunneis para efetuar configuração, tendo dois IP Públicos distintos, porém em nosso lab irei definir apenas 1 tunnel. Oracle usa roteamento assimétrico entre os diferentes tuneis, ou seja, sua VCN pode usar os canais operacionais para devolver para sua estrutura on-premises, ou seja, você precisa controlar esse trafego. Se estiver utilizando BGP você manipula sua metricas.

TIPS: Após a finalização dessa configuração , certifique-se que a ” Security List ” de sua VCN está liberando acesso ao protocolo ICMP “ Ingress ” em sua estrutura.

Configuração MERAKI

Como já exposto em nosso ambiente Meraki, irei definir o MX como sendo um HUB, e após isso devo definir a metodologia ( Phase 1 e Phase 2 ). Para isso, recomendo observar a documentação da Oracle sobre o hash e encriptação para o IPSEC.

Tendo isso em mãos fiz a configuração de uma police “ Custom “, atrelando a ” share Key ” já definida no ambiente de Cloud.

Feito dessa forma iremos ter as informações associadas em nosso ” Dashboard ” como (non-Meraki VPN Peers).

Bem como devemos confirmar qual rede local do meu homelab irá trafegar por essa VPN.

Como demonstrado no dashboard Oracle, aqui também podemos consolidar o status dessa conectividade. Se tudo estiver correto teremos o status “ verde ” 🙂

Consolidação

Nada melhor do que consolidar através de nossas ferramentas essenciais que é o PING e TRACEROUTE ( rsrs ).

Via maquina da homelab ( 192.168.0.0/24 )

Via maquina Oracle Cloud to homelab ( 10.0.1.0/24 )

Conclusão

De fato eu achei bem intuitivo as configurações relacionados ao IPSEC, e consegui estruturar rapidamente para que esse tunel entre os vendor estivessem operacionais. As documentações que precisei pesquisar estavam coerentes e sendo direta ao ponto, sem precisar ficar navegando em diversas abas para obter a informação.

De fato a unica fonte encontrada foi do fabricante, ou seja, não temos ainda muita documentação ou testes executados por esse mundo afora ( rs ). O fato é que cada vez mais está aumentando as informações desse fabricante devido ao seu crescimento nesse segmento.

Em nosso proximo post vou demonstrar como habilitar um serviço http e balancear entre esses servidores. Fique ligado!

Att,
Rodrigo