Como muitos já devem ter percebido o brainwork oferece um Feed para que seja possível acompanhar o blog através de agregadores RSS. Assim basta adicionar o endereço www.brainwork.com.br/blog/feed ao seu agregador preferido para receber as atualização automaticamente. Usando o mesmo formato podemos integrar o brainwork ao Outlook, e passar a receber as atualização no mail client. Para isso, no Outlook 2007, que conta com um agregador RSS nativo, basta clicar na opção RSS Feeds com o botão direito e adicionar o link acima. Configurando o Outlook 2007 para receber as atualizações RSS Feed do blog 1°) Clique com o botão direito no RSS Feeds e escolha Adicionar Novo RSS Feed. 2°) Coloque o endereço do RSS Feed do brainwork (www.brainwork.com.br/blog/feed). 3°) Confirme a inscrição. 4°) Pronto! As atualizações começarão a chegar. No Outlook 2003 ou Express é necessário instalar um plugin para receber o RSS. O RSS Popper é uma opção (freeware), e pode ser baixado no site http://www.paradisoft.com/rsspopper/download.asp Configurando o Outlook 2003 para receber as atualizações RSS Feed do blog 1°) Após fazer o download do RSS Popper, com o Outlook fechado, instale o plugin (tecnologia NNF – next > next > finish). Depois abra o Outlook e veja que foi adicionada a barra do RSS Popper. 2°) Clique em RSS Popper e em Edit Feeds. 3°) Na opção New selecione RSS/Atom Feed e na janela que abrirá coloque o link do blog (www.brainwork.com.br/blog/feed). Depois clique no botão Get From Feed e selecione a pasta onde o Feed deverá ser salvo (Browse). Garanta que a opção Enable está selecionada e clique em Ok e novamente Ok. 4°) De volta ao Outlook clique na opção RSS is OFF, para habilitar o plugin. 5°) Pronto. Os Feeds serão salvos na pasta indicada. Até a próxima.
Hospital Albert Einstein inova com tecnologia Cisco
O Hospital Albert Einstein (São Paulo), que é referencia na américa latina quanto ao uso de tecnologia em seus processos, passa a utilizar o Integrated Medical-Grade Network, da Cisco. O projeto serviu para consolidar quatro redes distintas (dados, voz, imagens/exames e equipamento de monitoramento vital) em uma única plataforma, de onde é possível acessar informações e serviços, de dentro do hospital e de outras sete localidades. Além de switches e roteadores, que fornecem conectividade local e remota, são utilizados firewall e IPS no perímetro da rede e ainda VPN, garantindo a segurança dos dados de médicos e pacientes. A integração das redes de forma segura permitiu a introdução de novas aplicações, para diferentes funções, que agora podem ser acessadas pelos usuários autorizados de qualquer local. E também há a integração com a telefonia IP wireless, que permite total mobilidade para médicos e enfermeiras. A direção do hospital acredita que haverá um crescimento de 30% a 40% no número de leitos, nos próximos três anos, e prevê ainda a construção de um hospital “dia”, entre outros, e o Medical-Grade está preparado para este crescimento, fornecendo conectividade, segurança, disponibilidade e integração. Notícia completa aqui. Até a próxima.
Fazendo o ASA aparecer em um tracert/traceroute
Por razões de segurança, o ASA/PIX não aparece quando fazemos um tracert (ou traceroute). Ele fica “invisível” para este tipo de tráfego deixando o pacote passar sem decrementar o TTL. Exemplo: Com a configuração padrão o usuário não consegue ver o ASA como um dos “hops”. C:\>tracert 200.221.11.100 Rastreando a rota para brahms.uol.com.br [200.221.11.100] com no máximo 30 saltos: 1 1 ms <1 ms <1 ms 200.1.1.1 <—- O roteador é o primeiro “hop” 2 * * * Esgotado o tempo limite do pedido. 3 * * * Esgotado o tempo limite do pedido. 4 * 27 ms 28 ms 201.0.5.121 5 60 ms 57 ms 59 ms 201.63.253.154 6 84 ms 121 ms 152 ms 201.63.253.182 7 27 ms 47 ms 60 ms 189.109.69.74] 8 28 ms 26 ms 28 ms 200.221.136.102 9 26 ms 25 ms 26 ms brahms.uol.com.br [200.221.11.100] Rastreamento concluído. C:\> Apesar deste ser o comportamento padrão do firewall, muitas vezes precisamos que todos os “hops” do caminho sejam identificados. Para isso é necessário configurar o ASA/PIX para que ele passe a decrementar o TTL, e assim ser identificado no tracert. Nas versões mais recentes (a partir da versão 8.0 (3)) basta entrar no policy-map padrão, depois na class-default e colocar o comando set connection decrement-ttl. Configuração: Decrementando TTL no tráfego layer 3 que passa pelo ASA/PIX. BrainFW01# conf t BrainFW01(config)# policy-map global_policy BrainFW01(config-pmap)# class class-default BrainFW01(config-pmap-c)# set connection decrement-ttl BrainFW01(config-pmap-c)# end BrainFW01# Com a configuração acima o ASA/PIX começará a “aparecer” no tracert. C:\>tracert 200.221.11.100 Rastreando a rota para brahms.uol.com.br [200.221.11.100] com no máximo 30 saltos: 1 1 ms <1 ms <1 ms 200.1.1.2 <—- IP da outside do ASA 2 <1 ms * <1 ms 200.1.1.1 3 * * * Esgotado o tempo limite do pedido. 4 * * * Esgotado o tempo limite do pedido. 5 * 28 ms 28 ms 201.0.5.121 6 60 ms 57 ms 59 ms 201.63.253.154 7 84 ms 101 ms 152 ms 201.63.253.182 8 27 ms 101 ms 27 ms 189.109.69.74] 9 28 ms 26 ms 28 ms 200.221.136.102 10 26 ms 25 ms 26 ms brahms.uol.com.br [200.221.11.100] Rastreamento concluído. C:\> Além desta configuração, para que o ASA/PIX aceite o tracert, é preciso liberar o ICMP nas access-lists aplicadas nas interfaces outside e inside (caso exista uma). Mais detalhes neste link, e até a próxima.
Rota configurada para next-hop ou interface de saída?
Uma rota estática deve ser configura sempre apontando para o IP do next-hop. Isso é o que diz as melhores práticas para configuração de roteamento… Mas qual a diferença na prática?? Bom, sabemos que quando a rota é configurada apontando para a interface, ela tem distância administrativa 0 (diretamente conectada) e apontando para um IP terá distância administrativa será 1 (padrão para rota estática). Rota configurada: ip route 192.168.1.0 255.255.255.0 f0/0 Entrada na tabela de roteamento: S 192.168.1.0/24 is directly connected, FastEthernet0/0 Rota configurada: ip route 192.168.1.0 255.255.255.0 172.16.1.10 Entrada na tabela de roteamento: S 192.168.1.0/24 [1/0] via 172.16.1.10 Isso pode ser bom ou mau, dependendo da sua necessidade. Mas vamos ver algumas situações onde (e porque) existem diferenças entre configurar uma rota estática para o IP do next-hop ou para a interface de saída. 1°) Imagine que você tem 10 rotas apontando para a S0/0 (interface de saída), e foi necessário mudar a interface (deu problema na interface e o link foi conectado na S0/1, por exemplo) teríamos que mudar também todas as rotas. 2°) Este problema ocorre com freqüência quando utilizamos a interface de saída na rota em conexões NÃO ponto a ponto. Por exemplo uma conexão entre um roteador e um switch, que recebe ainda a conexão de diversos dispositivos. Se você aponta a rota para sua interface de saída, o equipamento vai enviar o pacote para quem? Na teoria o roteador BrainRT01 vai enviar um broadcast layer2 e o roteador BrainRT02 responderá (proxy-ARP). Porém isso nem sempre funciona (algum equipamento pode bloquear a requisição,por exemplo)…E se não for ethernet? Ai fica pior, e são grandes as chances do tráfego não ir para lugar nenhum. 3°) Proxy-ARP em redes do tipo broadcast. Quando configuramos a rota para a interface, o equipamento envia uma mensagem broadcast para descobrir para onde o tráfego deve ser enviando, como vimos acima. Ele fará isso para todo IP buscado através daquela rota. Por sua vez o roteador que conhece este IP ou rede (BrainRT02, no exemplo abaixo) responderá todas as requisições, fazendo o proxy-ARP (enviará o seu mac-address da interface F0/1). Com esta resposta o roteador que fez a requisição (BrainRT01) cadastra o mac-address do roteador que respondeu (BrainRT02) em sua tabela ARP, associando ao IP. Exemplo: Rotas estáticas configuradas apontando a interface de saída. Rotas configuradas no BrainRT01: ip route 1.1.1.0 255.255.255.252 FastEthernet0/1 ip route 2.1.1.0 255.255.255.252 FastEthernet0/1 ip route 3.1.1.0 255.255.255.252 FastEthernet0/1 ip route 4.1.1.0 255.255.255.252 FastEthernet0/1 Do BrainRT01 vamos pingar as redes de BrainRT02, e depois ver como ficou a tabela ARP. BrainRT01#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms BrainRT01#ping 2.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/9 ms BrainRT01#ping 3.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms BrainRT01#ping 4.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 4.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms BrainRT01# BrainRT01# BrainRT01#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 1.1.1.1 0 001b.d4c9.77d7 ARPA FastEthernet0/1 Internet 3.1.1.1 0 001b.d4c9.77d7 ARPA FastEthernet0/1 Internet 2.1.1.1 0 001b.d4c9.77d7 ARPA FastEthernet0/1 Internet 4.1.1.1 0 001b.d4c9.77d7 ARPA FastEthernet0/1 Internet 172.16.1.5 – 0019.aa80.28c2 ARPA FastEthernet0/1 Internet 172.16.1.6 79 001b.d4c9.77d7 ARPA FastEthernet0/1 Internet 172.16.1.1 79 000c.ce36.fb00 ARPA FastEthernet0/0 Internet 172.16.1.2 – 0019.aa80.28c1 ARPA FastEthernet0/0 BrainRT01# Cada ping criou uma requisição ARP. Isso pode causar excesso de broadcast na rede, principalmente se a rota em questão, que está configurada apontando para a interface, for a rota default. Veja a diferença na tabela ARP quando usamos rotas com o IP do next-hop: Rotas configuras no BrainRT01: ip route 1.1.1.0 255.255.255.0 172.16.1.6 ip route 2.1.1.0 255.255.255.0 172.16.1.6 ip route 3.1.1.0 255.255.255.0 172.16.1.6 ip route 4.1.1.0 255.255.255.0 172.16.1.6 BrainRT01#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms BrainRT01#ping 2.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms BrainRT01#ping 3.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms BrainRT01#ping 4.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 4.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/9 ms BrainRT01# BrainRT01#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.16.1.5 – 0019.aa80.28c2 ARPA FastEthernet0/1 Internet 172.16.1.6 5 001b.d4c9.77d7 ARPA FastEthernet0/1 Internet 172.16.1.1 236 000c.ce36.fb00 ARPA FastEthernet0/0 Internet 172.16.1.2 – 0019.aa80.28c1 ARPA FastEthernet0/0 BrainRT01# Desta forma o roteador BraintRT01 precisa identificar apenas o mac-address do next-hop, e colocá-lo em sua tabela ARP, como mostrado acima. 4°) Agora imagine que na topologia abaixo temos configurado protocolo de roteamento, além das rotas estáticas. Se configurarmos as rotas estáticas para a interface e ela ficar down a rota é removida da tabela de roteamento. Por outro lado, se a rota for configurada com o IP do next-hop, mesmo que a interface F0/1 do BrainRT01 fique down, o IP do next-hop será aprendido pelo protocolo de roteamento, e a rota estática continuará na tabela de roteamento. Exemplo: Rotas estáticas configuradas para a interface + EIGRP (todas as redes) Rotas estáticas configuradas no BrainRT01: ip route 1.1.1.0 255.255.255.0 FastEthernet0/1 ip route 2.1.1.0 255.255.255.0 FastEthernet0/1 ip route 3.1.1.0 255.255.255.0 FastEthernet0/1 ip route 4.1.1.0 255.255.255.0 FastEthernet0/1 BrainRT01#sh ip route Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area N1
Parabéns Internet
Acho que praticamente tudo foi dito sobre o 40° aniversário da Internet, comemorado hoje, mas não podíamos deixar passar em branco essa data. No dia 2 de setembro de 1969, em uma universidade da Califórnia – EUA, testes foram realizados pela ARPANET (rede militar americana), com dois computadores trocando informações. Era o início da grande rede (bem diferente da Internet que conhecemos, é claro). A Internet, mais ou menos como é hoje, só apareceu na década de 90, popularizando-se a partir de 1995. Nestes 40 anos muitas coisas mudaram, para melhor e para pior. Muitas empresas/marcas/programas, verdadeiros ícones surgiram, sumiram, reapareceram… e teve a bolha da Internet, bolhado do .com, bug do milênio e agora temos a bolha imobiliária ou seria bancária? E a “nuvem” fica maior! Enfim, PARABÉNS INTERNET. Obs. No site da Discovery tem uma página legal sobre a Internet.
Wireless Cisco em Ipanema e Leblon
A Cisco fornecerá equipamentos para a expansão do projeto Orla Digital, no Rio de Janeiro. O projeto, do Governo do Estado e COPPE (Coordenação dos Programas de Pós-Graduação em Engenharia), da Universidade Federal do Rio de Janeiro tem o objetivo de fornecer acesso gratuito a Internet, em alta velocidade. O Orla Digital começou em 2008 e agora, na segunda fase, serão utilizados 20 equipamentos Wireless Mesh, da Cisco, para fornecer a infra-estrutura em Ipanema e Leblon. Com esta implementação, o Rio de Janeiro passa a ter 8,5 quilômetros de extensão da orla coberta com sinal de Internet sem fio. Deste total 6 quilômetros serão cobertos pelos equipamentos Cisco. Com esta nova fase são possíveis até duas mil conexões simultâneas, e são atendidas cerca de 2 milhões de pessoas, que vivem e transitam na região. Além de fornecer acesso a Internet o projeto Orla Digital deve agregar outros serviços no futuro, como localização dos usuários e câmeras de vídeo para segurança pública. Notícia completa aqui. Site do projeto: http://www.orladigital.coppe.ufrj.br/ Até a próxima.
