Gerência de Redes Avançadas Com FreeBSD

Gerenciando
Redes Avançadas com

FreeBSD e Software Livre
Agenda
•  Objetivos
•  Introdução
–  Redes Avançadas
–  NOCs – Network Operations Centers
–  Gerência de Redes
•  FreeBSD e Software Livre

–  Aplicações
–  Ferramentas para gerenciamento de redes
BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

Objetivos
•  O uso de Software Livre e gratuito é viável
como plataforma para gerência de redes,
avançadas ou tradicionais.
•  O FreeBSD, dentre os sistemas operacionais
de código aberto, atende as atividades de
engenharia e operações de redes e é usado em
funções importantes das redes de pesquisa e
educação, em várias áreas de P&D.
•  Mostrar algumas Ferramentas de Software
Livre usadas em NOCs, na operação de redes
IP, em P&D nas redes avançadas.
Redes Avançadas

Redes Avançadas
Características das Redes de P&E (NRENs)
•  Precisam ser construídas e operadas para ter o seu
melhor desempenho e alta disponibilidade.
•  Serviços avançados são demandados pelos usuários,
como IPv6, Multicast, VoIP, Vídeo etc.
•  Usuários com aplicações exigentes em termos de
latência e largura de banda. O consumo de banda
pode chegar ao máximo, consumido por um único
usuário, com uma única aplicação.
•  Engenharia e NOC devem oferecer suporte específico
a projetos e experimentos de P&E de sua comunidade
de usuários, e que podem impactar no desempenho
da rede.
Classificação das Redes Avançadas
•  A Internet pode ser classificada em 3 gerações,
de acordo com as tecnologias usadas e
aplicações suportadas:
Primeira Segunda Terceira
geração Geração geração
• Não confiável • IPv6 • Uso de DWDM e

• IPv4 • Multicast outras tecnologias
• Sem QoS • QoS ópticas
• Sem garantia de • Multimídia, • Uso de
banda VoIP roteamento e
• Baixas comutação em
velocidades camada óptica
Desempenho das Redes Avançadas
•  O padrão atual é 10Gbps, por limitação da atual
tecnologia usada nos roteadores, nas conexões
de longa distância (WAN) [1].
Redes Núcleo (Core)
Abilene, CA*net4, Géant 10Gbps (OC-192 / STM-64)
RedCLARA 155Mbps (OC-3 / STM-1)
RNP 10Gbps (OC-192 / STM-64)
2.5Gbps (OC-48 / STM-16) [2]
[1] Existem tecnologias de maior capacidade (ex.: 40Gbps)

para redes locais e regionais
[2] Previsão para o último trimestre de 2005
Aplicações das Redes Avançadas
•  Uso de tecnologias IPv6, MPLS, VPNs, QoS etc.
•  Videoconferência, transmissão de vídeo
(streaming) e vídeo sob demanda
•  Indexação e Busca
•  Middleware (segurança, diretórios, PKI)
•  Mobilidade
•  Computação em Grade (Grid Computing)
•  Tele-medicina, astronomia, física (luz
síncrotron, grid etc.), educação à distância,
HDTV sobre IP etc.
Consórcios de Redes Avançadas (P&E)
•  APAN – Asian-Pacific Advanced Network (Ásia)
•  Internet2 (EUA)
•  CLARA – Cooperação Latino-Americana de
Redes Avançadas (América Latina)
•  TERENA – Trans-European Research and
Education Networking Association (Europa)

APAN (Ásia)

RedCLARA (Am. Latina)

Géant (Europa)

Internet 2 (EUA)

Principais Redes Avançadas (P&E)
•  AARNet - Australia's Research and Education Network
•  Abilene (EUA)
•  CA*Net4 (Canadá)
•  RedCLARA (América Latina)
•  Dante/Géant (Europa)
•  ESnet (EUA)
•  JGN-II - Japanese Gigabit Network 2 (Japão)
•  NLR – National Lambda Rail (EUA)
•  RNP – Rede Nac. de Ensino e Pesquisa (Brasil)
•  The Quilt (EUA)
•  UKERNA (Reino Unido)
RNP – A Rede Acadêmica Brasileira
RNP – A primeira rede nacional de acesso à

Internet
•  Começou como um projeto do Min. da Ciência e
Tecnologia (comunidade acadêmica e Governo)
•  Modelo da rede acadêmica brasileira - 3 níveis:
–  backbone nacional
–  redes regionais
–  redes institucionais
•  Implementação da rede iniciada em 1991

RNP
•  Institucionalização em 1999, como associação
privada, sem fins lucrativos
•  Convênio: Programa Interministerial de
Implantação e Manutenção da Rede Nacional
para Ensino e Pesquisa (PI-MEC/MCT) em 1999
•  Em 2002, a AsRNP foi qualificada pelo governo
federal como uma Organização Social e firmou
um contrato de gestão com o MCT

RNP
•  27 Pontos de Presença (PoPs): 1 em cada
estado brasileiro e mais 1 no Distrito Federal
•  Mais de 200 instituições conectadas –
Universidades Federais, Institutos Federais de
Pesquisa e outras instituições de ensino e pesq.
•  Mais de 1 milhão de usuários
•  O backbone nacional RNP fornece:
–  Interconexões entre redes regionais
–  Conexões com backbones nacionais e internacionais
(acadêmicos e comerciais)

GLIF – O Futuro das Redes Avançadas
GLIF - Global Lambda Integrated Facility (SURFnet e Univ. of Amsterdam)
•  Consórcio para implementar um LambdaGrid
•  Banda prevista das NRENs, a serem disponibilizadas para experimentos
previamente agendados de pesquisa e aplicações

Network Operation Center
NOC

NOC
•  Local a partir do qual é exercido o controle de
redes de comunicações.
•  O suporte (help desk ou service desk) de um

NOC geralmente oferece:
–  Suporte e foco em coordenação, comunicações e
controle entre provedores de serviços de rede e
usuários.

NOC
•  Dentre os serviços prestados pelos NOCs,
destacam-se:
–  Elaboração de procedimentos operacionais e
respectiva documentação
–  Resolução de problemas
–  Gerenciamento e implementação de mudanças
–  Implementação e monitoramento da segurança
–  Monitoramento, avaliação e melhoria do
desempenho
–  Gerenciamento de comunicações
–  Coordenação de atividades operacionais
–  Geração de relatórios.
NOCs das Redes Avançadas
•  GlobalNOC – Indiana University (IU) (EUA)
–  Gerencia conexões com redes de P&E da Ásia,
Europa, Rússia e América do Sul ao STAR TAP e a
outras redes como: Abilene, vBNS e ESnet.
•  Abilene NOC – IU (EUA)
•  APAN JP NOC – (Japão)
•  NLR NOC – National Lambda Rail NOC (EUA)
•  ARDNOC – Advanced Research and Development
Network Operations Center – CA*net 3 e 4 (Canadá)
•  CLARA-NOC - RedCLARA (América Latina)
•  CEO – Centro de Engenharia e Operações RNP (Brasil)
Global NOC (I.U.)
Global NOC – Univ. de Indiana
•  Maior NOC de redes avançadas.
•  Redes atendidas:
–  Redes STAR TAP/Euro-Link/TransPAC
–  Abilene (Internet2)
–  MIRnet (conexão com a Rússia)
–  AMPATH (América do Sul)
–  Redes do campus da Univ. de Indiana
•  Operação.
–  Mantém estatísticas de todas as redes gerenciadas:
•  Paradas programadas e não programadas e a duração.

Gerência de Redes

Gerência e Operação de Redes
•  Praticamente todas as infra-estruturas de redes
precisam de operação, em várias aplicações:
–  Backbones acadêmicos e comerciais;
–  Redes metropolitanas
–  Provedores de acesso Internet (ISPs)
–  Pontos de Troca de Tráfego (PTT, NAPs, IXPs)
–  Datacenters
–  Redes corporativas
•  Assim, cada vez mais:
•  São exigidos maior qualidade dos serviços,
•  Aumenta a criticidade da operação.
•  É requerido o uso de boas e confiáveis ferramentas de
apoio.
Gerência de Redes
•  Um conjunto de procedimentos, equipamentos
e operações, planejados para manter uma rede
operando próximo de sua máxima eficiência,
pelo maior tempo possível, economizando
custos e recursos.
•  Sobrecargas eventuais ou falhas podem causar
congestionamentos, funcionamento ineficiente
prejudicando os usuários (clientes).
•  Adicionalmente, podem ocorrer necessidades
de provisionamentos de recursos sob demanda
Monitoramento e Operação de Redes
•  Monitoramento - acompanhamento dos
eventos de uma rede, a fim de diagnosticar
problemas e determinar quando e quais
procedimentos de contingência devem ser
aplicados, bem como obter estatísticas para
administração e otimizações de desempenho.
•  Operação - Gerenciamento integrado de
redes, usando sistemas de informação e
recursos que forneçam um cenário comum de
operação.
Desafios para os NOCs
•  Maior foco em demandas de segurança e em
gerenciamento de rede
•  Maior quantidade de elementos a serem
monitorados
•  Redes mais complexas (VPNs, Voz, Vídeo etc.)
•  Maior quantidade de serviços mais complexos
dependem da rede.

Padrões para Gerência de Redes
•  FCAPS – acrônimo referente às áreas funcionais de
gerenciamento definidas no modelo ISO de
gerenciamento de redes
  Falhas (Fault)
  Configuração (Configuration)
  Contabilização (Accounting)
  Desempenho (Performance)
  Segurança (Security)
•  ITIL – Biblioteca de Infra-estrutura de T.I.
(Information Technology Infrastructure Library)
Considerações Operacionais
Manutenção
•  Evitar ao máximo alterações em uma rede em
produção
•  Deve-se estabelecer os períodos (horários) das
manutenções, que devem ser publicados via
web e divulgados por e-mail aos interessados,
para estabelecer as expectativas e evitar
surpresas.
•  Os dias mais interessantes são, em geral,
terça-feira e quinta-feira.
•  Evitar qualquer alteração nas configurações dos
equipamentos de rede fora destes períodos.
Operações de Rede x Suporte aos Clientes
•  São atividades distintas e deve-se evitar que a
mesma equipe execute as duas tarefas.
•  Com uma única equipe, a operação da rede
será negligenciada em favor das demandas dos
usuários.
•  Em casos de falha na rede, vão gastar mais
tempo atendendo telefonemas do que
consertando o problema.
•  Geralmente os contatos do NOC são diferentes
evitar contato direto dos clientes e manter o
foco na resolução de problemas da rede.
Engenharia
•  Desenha a rede, planeja os próximos passos, e
efetua correções que o NOC não teve condições
de resolver.
•  Geralmente são usadas estruturas de divisões
em Sistemas e Engenharia de Rede e, esta
última área, em Engenharia e Operações.

Gerência de Mudanças
•  Documenta:
–  o que será feito na rede,
–  os impactos,
–  os procedimentos de contingência,
–  o tempo das alterações;

•  A documentação assegura que:
–  operadores poderão executar alterações
remotamente
–  a rede está documentada
–  há histórico das mudanças
–  a origem de novos problemas que surgirem poderá
ser detectada mais facilmente.
–  nenhuma parte do processo está sendo
negligenciada há mais chances da alteração correr
como esperado.

Uso do FreeBSD em
Pesquisa e Desenvolvimento
(P&D)

P&D com FreeBSD
O sistema operacional FreeBSD é empregado, há
muitos anos, em pesquisa e desenvolvimento
de novas tecnologias.
•  Protocolos
–  Multicast IPv4/IPv6: PIM-SM, MLDv2, IGMPv3
(KAME, XORP)
–  Implementação de roteador IPv6 de baixo custo em
redes (FreeBSD, Zebra/Quagga)
–  Available Bandwidth Estimator (ABwE) – Abilene

P&D com FreeBSD
Vantagens
•  Alta disponibilidade (uptime):
helm:~$ date; uptime
Tue Aug 9 21:55:38 BRT 2005
9:55PM up 1488 days, 13:51, 1 user, load averages: 0.00, 0.00, 0.00
helm:~$
•  Capacidade para atualizações do S.O. com baixo

tempo de parada (downtime)
•  Alta flexibilidade para otimizações
•  Maduro e robusto:
–  derivado do código Unix original
–  desenvolvido há mais de 20 anos.
–  Pilha TCP/IP madura, utilizada em diversos produtos
comerciais
P&D com FreeBSD
•  Vantagens (cont.)
–  Suporte a todos os principais serviços e aplicações
Internet (www, ftp, smtp, pop3, imap, ntp, dns,
bootp, tftp, rpc, ssh, sftp, etc… e mais: whois, )
–  Usado pela NASA para pesquisa com QoS
(ALTQ, CBQ)
•  Desvantagens
–  Administração arcaica e não intuitiva (qual UNIX
não é?), por outro lado, quem precisa de GUIs?

P&D com FreeBSD
FreeBSD em Projetos da Internet2 (cont.)
•  Bandwidth Control (BWCTL)
http://e2epi.internet2.edu/bwctl/
•  Network Diagnostic Tester (NDT)
http://e2epi.internet2.edu/ndt/
•  One-way Latency Measurement (OWAMP)
http://e2epi.internet2.edu/owamp/
•  iperf
http://dast.nlanr.net/Projects/Iperf/
•  thrulay - network capacity tester
http://www.internet2.edu/~shalunov/thrulay/
•  IPv6
http://ipv6.internet2.edu/lincoln/ipv6-mgp.html
•  High-End Video Transmission over IP
http://events.internet2.edu/2005/fall-mm/sessionDetails.cfm?session=2256&event=239

P&D com FreeBSD
FreeBSD em Projetos da Internet2
•  Abilene Observatory (25 projetos beneficiados)
http://abilene.internet2.edu/observatory/
•  Cada nó da rede Abilene tem dois racks, sendo um para

equipamentos de roteamento e outro para servidores do
projeto e resto do espaço disponível para “co-location” de
outros hardwares de projetos de pesquisa aprovados (ex.:
Projetos PlanetLab, AMP e www.internettrafficreport.com).
•  Especificações dos servidores (NMS hosts) Observatório
–  CPU: (2x)1.26 Ghz Xeons
–  SO: FreeBSD (Linux as option)
–  Memória: 1 GB Memory
–  Discos: (2x)18GB SCSI
–  NICs: Conexões de Fibra GigEth (NMS-1 e NMS-2) ou FastEth
–  Alimentação DC
•  Internet2 End to End Performance Initiative Tools http://
e2epi.internet2.edu/tools_list.html
Network Management
and
Network Operations
I have a network, now what?

Outline
•  What is network management?
•  Fault Management
–  Fault detection and tracking
–  Basic Network Operations
–  What are typical network problems?
•  Other parts of network management

Outline (con)
•  Network Management Tools
–  what do I need?
–  what is available?
–  Pros and Cons of various tools
•  A day in the life of a typical NOC

Network Management - What is it?
•  Making sure the network is up, running and
performing well
•  Parts of Network Management
–  fault management
–  performance management
–  security management
–  trouble tracking
–  statistics and accounting

Fault Management
•  one of the most important parts of network
management
•  detect network problems
–  transient/persistent
–  failure/overload
•  examples: router down, serial link down
•  detect server problems
•  isolating problems

Fault Management (con)
•  reporting mechanism
–  link to help desk
–  notify on-call personnel
•  setup & control alarm procedures
•  repair/recovery procedures
•  ticket system

Fault Management - Fault
Detection
•  Who notices a problem with the network?
–  Network Operations Center w/ 24x7 operations staff
•  open trouble ticket to track problem
•  preliminary troubleshooting
•  escalate to engineer or call carrier

Fault Management -
Fault Detection (con)
•  How can you tell if there is a problem with
the network?
–  Network Monitoring Tools
•  common utilities
–  ping
–  traceroute
–  snmp
–  Report state or unreachability
•  detect node down
•  routing problems

Fault Management -
Fault Detection (con)
–  “Alert” shows up for NOC
•  rover
•  spectrum
•  NOCol
•  HP Openview
•  other
–  Other methods
•  customer complaint via phone/email
•  another ISP notices problem

Fault Detection Example -
Using Rover
•  Rover = network monitoring system
–  http://www.merit.edu/internet.tools/rover/
•  Keep it Simple
•  add nodes and tests to hostfile
•  run Display to see status
•  NOC notices alert on board for failed node
–  opens ticket
–  investigates

The Alert Display Program
Place for status updates

Name of Test that failed
IPAddress as in hostfile
Name as in hostfile
Time of Alert that failed

Command line: ‘Help’ Problem #1

Fault Management -
Ticket System (Why all the fuss?)
•  Very Important!
•  Need mechanism to track:
–  failures
–  current status of outage
–  carrier ticket #s

Fault Management -
Ticket Systems (Why all the
fuss?)
•  system provides for:
–  short term memory & communication
–  scheduling and work assignment
–  referrals and dispatching
–  oversight
–  statistical analysis
–  long term accountability

Fault Management -
Ticket Systems (Why all the
fuss?)
•  Goal: make your NOC the communication
and coordination center!
•  Central repository for all information
–  current status
–  troubleshooting information
•  Engineers can coordinate their work through
the NOC

Fault Management - Ticket Usage
•  create a ticket on ALL calls
•  create a ticket on ALL problems
•  create a ticket for ALL scheduled events
•  copy of ticket mailed to reporter and mailing
list(s)
•  all milestones in resolution of problem create a
new ticket entry with reference to original
•  ticket stays "open" until problem resolved
according to problem reporter
Fault Management - Ticket
Example
•  sample opening ticket
TT0000033975 has been OPENED. Here is the trouble ticket contents:
Create-date : 06/09/99 12:46:42

Ticket ID : TT0000033975
Node + : rs2.mae-west.rsng.net
Equipment Type : host
NOC Customer : RA
Trouble Reported : Unreachable
Next Action : Investigate
Next Action Date : 06/09/99 12:46:42
Outage type : unscheduled
Source of Report : Noc/roverStatus :
Assigned
Assigned-to : Noc
Contact Name : rsng
Group Member :
Contact pager#/email address :
Contact Phone : .
Carrier Ticket History :
Carrier :
Carrier Phone :
Ticket information log :
06/09/99 12:46:42 noc-op
toppingb@facesofdeath.ns.itd.umich.edu said ...
11 Wed12:23 rs2MW_O/C 198.32.136.2 PING

Example
•  sample progress ticket
TT0000033975 has been MODIFIED. Here are the fields that have been
changed:
CopyOfTime : 5
TTC Temp : 0
Ticket information log : toppingb@facesofdeath.ns.itd.umich.edu said ...
While I was investigating this, Debbie from UUNet called (via Merit
main
number) to tell us they were seeing it down. She can be reached at
xxx-xxxx. The UUNet ticket is xxxxx..

Example
•  sample closing ticket
–  includes previous ticket contents plus resolution
T0000033975 has been CLOSED. Here is the trouble ticket contents:

01/15/99 12:50:06 noc-op

mgf@wonka.ns.itd.umich.edu said ...
Email response from Abha suggesting contacting peers directly -- see

internal log.
01/15/99 14:25:22 noc-op
aubinc@augustus2.ns.itd.umich.edu said ...
The alerts cleared shortly before 14:00. I called MCI/Worldcom for an

update, and found out their ticket was closed. According to them the
outage was due solely to a power problem.
Closing.
Last-modified-by : noc-op
Modified-date : 01/15/99 14:25:22
Submitter : btracy

Fault Management - typical
failures
•  Node unpingable
–  no ip connectivity to router
–  possible reasons:
•  serial link down
–  call telco
•  router down/hardware problem
–  call engineer
•  routing problem
–  troubleshoot with traceroute
–  routeviews machine

Performance Management
•  evaluate the behavior of network elements
•  information used in planning
•  interface stats
•  throughput
•  error rates
•  software stats
•  usage
•  queues
•  system load
•  disk space
•  percent availability

Security Management
•  tends to be host-based
•  protect your stats, data and NOC info
•  protect other services
•  security required to operate network and
protect managed objects
•  security services
–  Kerberos
–  PGP key server
–  secure time

Security Management (con)
•  security tools
–  cops - host configuration checker (www.cert.org)
–  swatch - email reports of activity on machine
–  tcpwrappers
–  ssh/skey
–  tripwire
•  distribute security information
–  bug reports
•  CERT advisories
–  bug fixes
–  intruder alerts

Security Management (con)
•  reporting procedure for security events
–  e.g. break-ins
–  abuse email address for customers to report
complaints (abuse@your-isp.net)
•  control internal and external gateways
–  control firewalls (external and internal)
•  security logs
•  privacy issues a conflict

Security Management
•  Network based security
–  Types of attacks
•  DOS - Denial of Service
–  ping floods
–  smurf
–  attacks that make your network unusable
•  Spoofing
–  packets with “spoofed” source address

What types of problems?
•  Blocking and tracing denial of service attacks
•  Tracing incoming forged packets back to their
source
•  Blocking outgoing forged packets
•  Most other security problems are not specific to
backbone operators
•  Deal with complaints

smurf
•  attacker sends many ping request packets:
–  from forged (victim) source address
–  to broadcast address on “amplifier” network
•  many ping responses from systems on amplifier
network
•  attacker on dialup modem can saturate victim’s
T1 using a T3-connected amplifier
•  http://users.quadrunner.com/chuegen/smurf/

Protection against smurf
•  configure “no directed-broadcast” on all
interfaces
–  so you can’t be used as an amplifier
•  trace forged packets back, hop by hop
•  block outgoing forged packets from your
customers
•  limit the bandwidth that can be used by ICMP
traffic

Smurf Attack
132.34.65.1
victim
src IP=132.34.65.1 253*5*100

dst IP= 215.23.16.255
5*100 byte packets
amplifier
attacker
24.3.2.1
215.23.16.0/24
SYN flooding
•  attacker sends many TCP SYN packet from
forged source address
•  victim sends SYN+ACK packets to invalid
address
–  gets no response
–  connection hangs in half open state
–  wastes OS resources, possibly crashing system

Protection against SYN flooding
•  Make operating system more robust
–  not a backbone problem, except on routers
•  Trace and block forged packets
•  Limit bandwidth that can be used by TCP SYN
traffic

Syn attack
230.55.65.1
src IP=230.55.65.1
dst IP=132.16.12.5 Replies go to
connection request packets spoofed IP
( syn packets)
attacker victim
24.13.51.2 132.16.12.5

Notice a pattern?
•  Forged packets
•  Need a way of preventing customers from
sending forged packets
•  Need a way of tracing where forged packets
really come from

Tracing forged packets
•  Start on router near victim
•  Find how packets get to that router
•  Repeat on next router
•  Continue until edge of your AS
•  Ask next AS to trace further
•  Need cooperation
•  IMPORTANT - Should have a 24hour security
contact!

Security Management
•  Protecting your network
–  traffic shapers
•  use CAR to limit ICMP traffic
–  anti-spoofing filters
•  RFC 2267 (Network Ingress Filtering)
•  for singly-homed customers
–  IF packet's source address from within your network
–  THEN forward as appropriate
–  IF packet's source address is anything else
–  THEN deny packet
•  Filter on the outbound

Preventing forged packets from
•  packet filters! customers
•  you know what IP addresses are used (at least
for dialup and statically routed customers)
•  make a filter for each customer that denies
other source addresses
•  very recent cisco code has “ip verify source-
address”

Preventing forged packets from
you to outside world
•  you might know all the IP addresses that are
used in your AS
–  if your connections to the outside world and your
transit arrangements are not too complicated
•  make a filter that denies other source
addresses
•  apply that filter to all links from you to other
Ases

Configuration and Name
Management
•  track network vitals
–  ip addresses, interfaces, console phone numbers,
etc
•  NOC needs valid contact info for nodes
•  network state information
–  network topology
–  operation status of network elements
•  including resources
–  network element configuration

Management
•  control network elements
–  start/stop
–  modification of network attributes
–  addition of new features
•  configuration modification
–  allocation and addition of network resources
–  reconfiguration if dictated by link outages

Management
•  inventory management
–  database of network elements
–  history of changes & problems
•  directory maintenance
–  all hosts & applications
–  nameserver database
•  host and service naming coordination
–  "Information is not information if you can't find it"

Config. Mgmt. - Network State
Info.
•  e.g. SNMP driven display
wjh12 mghgw husc6
generali harvard
talcott
wjhgw1
harvisr
huelings
geo
pitirium
nnhvd nngw
oitgw1 sphgw1
lmagw1
dfch tch tch

Network Management Tools
•  many use SNMP
•  ping
•  traceroute
•  References:
–  MON - http://www.kernel.org/software/mon/
–  NOCol - ftp://ftp.navya.com/pub/vikas/nocol.tar.gz
–  Sysmon - ftp://puck.nether.net/pub/jared
–  Rover - http://www.merit.edu/~rover
–  Concord - http://www.concord.com

What is SNMP? (the quick
version...)
•  Simple Network Management Protocol
•  query - response system
–  can obtain status from a device
–  standard queries
–  enterprise specific
•  uses database defined in MIB
–  management information base

What do we use SNMP for?
•  query routers for:
–  in and out bytes per second
–  CPU load
–  uptime
–  BGP peer session status
•  query hosts for:
–  network status

SNMP Network Management
Tools
•  mrtg (http//:www.ee.ethz.ch/~oetiker/
webtools/mrtg
–  why we like it
•  simple to use and configure
•  quickly determine spikes/drops in traffic
–  ping floods
–  in/out bps
–  uptime
–  supplement to monitoring tools

MRTG

Spectrum
•  commercial package
•  Used by various networks
•  configurable alarms
•  GUI interface - view network topology
•  auto-discovery
•  difficult to use

Netscarf/Scion
•  free
•  snmp collector and analyzer package
–  collects snmp data
–  display on web pages
•  http://www.merit.net/~netscarf

Other Network Tools
•  netflow
–  cflowd (http://www.caida.org/Tools/Cflowd)
–  collects flow information from cisco routers
–  AS to AS information
–  src and destination ip and port information
–  useful for accounting and statistics
–  how much of my traffic is port 80?
–  how much of my traffic goes to AS237?

Netflow examples
•  Top ten lists (or top five)
##### Top 5 AS's based on number of bytes #######
srcAS dstAS pkts bytes
6461 237 4473872 3808572766
237 237 22977795 3180337999
3549 237 6457673 2816009078
2548 237 5215912 2457515319
##### Top 5 Nets based on number of bytes ######

Net Matrix
----------
number of net entries: 931777
SRCNET/MASK DSTNET/MASK PKTS BYTES
165.123.0.0/16 35.8.0.0/13 745858 1036296098
207.126.96.0/19 198.108.98.0/24 708205 907577874
206.183.224.0/19 198.108.16.0/22 740218 861538792
35.8.0.0/13 128.32.0.0/16 671980 467274801
##### Top 10 Ports #######

input output
port packets bytes packets bytes
119 10863322 2808194019 5712783 427304556
80 36073210 862839291 17312202 1387817094
20 1079075 1100961902 614910 62754268
7648 1146864 419882753 1147081 414663212
25 1532439 97294492 2158042 722584770

More Tools!
•  http://www.caida.org/Tools/
–  OC3Mon/Coral
•  http://www.merit.edu/~ipma
–  RouteTracker
–  IRRj
–  ASExplorer
•  http://www.geektools.com/
•  http://www.merit.edu/ipma/tools/other.html

ASexplorer

Route Flap Stats

Looking Glass Tools
•  http://www.merit.edu/~ipma/tools/
lookingglass.html
route-views.oregon-ix.net>show ip bgp 35.0.0.0
BGP routing table entry for 35.0.0.0/8, version 56135569
Paths: (17 available, best #12)
11537 237
198.32.8.252 from 198.32.8.252
Origin incomplete, localpref 100, valid, external
Community: 11537:900 11537:950
2914 5696 237
129.250.0.3 (inaccessible) from 129.250.0.3
Origin IGP, metric 0, localpref 100, valid, external
Community: 2914:420
2914 5696 237
129.250.0.1 (inaccessible) from 129.250.0.1
Origin IGP, metric 0, localpref 100, valid, external
Community: 2914:420
3561 237 237 237
204.70.4.89 from 204.70.4.89
Origin IGP, localpref 100, valid, external
267 1225 237
204.42.253.253 from 204.42.253.253
Origin IGP, localpref 100, valid, external
Community: 267:1225 1225:237

More Looking Glass Tools
•  Traceroute servers
•  http://www.merit.edu/ipma/tools/trace.html
Query: trace
Addr: www.isoc.org
Translating "www.isoc.org"...domain server (206.205.242.132) [OK]
Type escape sequence to abort.

Tracing the route to info.isoc.org (198.6.250.9)
1 iad1-core2-fa5-0-0.atlas.digex.net (165.117.129.2) 0 msec 0 msec 4 msec

2 dca5-core2-s5-0-0.atlas.digex.net (165.117.53.41) 0 msec 4 msec 0 msec
3 dca5-core1-fa5-1-0.atlas.digex.net (165.117.56.117) 4 msec 0 msec 4 msec
4 Hssi3-1-0.BR1.DCA1.ALTER.NET (209.116.159.98) 0 msec 0 msec 4 msec
5 101.ATM2-0.XR1.DCA1.ALTER.NET (146.188.160.226) [AS 701] 4 msec 0 msec 4 msec
6 195.ATM7-0.XR1.TCO1.ALTER.NET (146.188.160.102) [AS 701] 4 msec 0 msec 0 msec
7 193.ATM8-0-0.GW1.TCO1.ALTER.NET (146.188.160.33) [AS 701] 4 msec 4 msec 4 msec
8 charlie.isoc.org (198.6.250.1) [AS 701] 8 msec 8 msec 8 msec
9 info.isoc.org (198.6.250.9) [AS 701] 8 msec * 12 msec

Importance of Network Statistics
•  Accounting
•  Troubleshooting
•  Long-term trend analysis
•  Capacity Planning
•  Two different types
–  active measurement
–  passive measurement
•  Management Tools have statistical functionality

Management for Real
•  A few basic tools
•  echo request
–  ping on IP
–  checks path & basic node function
–  can return round trip time
–  normally not higher node function
oolbeans% ping -s www.cisco.com
PING cio-sys.cisco.com: 56 data bytes
64 bytes from cio-sys.cisco.com (192.31.7.130): icmp_seq=0. time=69. ms
^C
----cio-sys.cisco.com PING Statistics----
5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms) min/avg/max = 68/68/70

Management for Real, Cont.
•  traceroute - finds path to node with delays
–  detect reachability
–  detect routing problems
•  example of routing loop (next slide)

dfalk@unagi [Thu 15:07] 5 /usr/home/jdfalk>traceroute -m 255 www.monkeys.com
traceroute to www.monkeys.com (207.212.142.41), 255 hops max, 40 byte packets
1 thermal-detonator.explosive.net (209.133.38.1) 3.428 ms 2.032 ms 2.915
ms
2 explosive-gate.bungi.com (207.126.96.81) 14.158 ms 6.082 ms 6.239 ms
3 above-gw1.above.net (207.126.96.249) 18.889 ms 23.423 ms 13.275 ms
4 core2-main.sjc.above.net (207.126.96.133) 20.749 ms 22.295 ms 26.260 ms
5 pbnap.ibm.net (198.32.128.49) 31.658 ms 21.513 ms 10.753 ms
6 sfra1sr1-4-0-0.ca.us.ibm.net (165.87.13.5) 22.046 ms 46.370 ms 11.730 ms
7 sfo-pacbell-pop-sc.ca.us.ibm.net (165.87.225.9) 14.978 ms 31.752 ms
15.835 ms
8 ded1-fa0-1-0.pbi.net (216.102.176.229) 16.619 ms 26.949 ms 14.992 ms
9 pbi.scrm01.foothill.net (206.13.15.82) 47.453 ms 41.492 ms 55.562 ms
10 inyo.E0.foothill.net (206.170.175.12) 25.009 ms 42.198 ms 46.245 ms
11 fhaub.foothill.net (207.212.142.2) 26.434 ms 26.344 ms 28.052 ms
12 aub2-aub.foothill.net (207.212.142.18) 124.096 ms 101.107 ms 116.097 ms
13 yellowstone.foothill.net (209.77.125.7) 60.986 ms 65.366 ms 62.531 ms
14 black.foothill.net (209.77.125.5) 54.999 ms 54.907 ms 75.083 ms
15 den-edge-03.inet.qwest.net (205.171.2.81) 60.018 ms 65.658 ms 70.363 ms
16 den-core-01.inet.qwest.net (205.171.16.101) 74.909 ms 65.983 ms 53.476
ms
17 kcm-core-01.inet.qwest.net (205.171.5.49) 122.825 ms 122.386 ms 109.227
ms
18 chi-core-03.inet.qwest.net (205.171.5.209) 105.897 ms 124.867 ms *
19 chi-brdr-01.inet.qwest.net (205.171.20.66) 157.154 ms 135.603 ms 112.038
ms
20 ameritech-nap.ibm.net (198.32.130.48) 97.206 ms 287.921 ms 118.020 ms
21 scha1br2-0-0-0.il.us.ibm.net (165.87.34.162) 127.120 ms 94.150 ms
108.502 ms
22 sfra1br2-at-2-0-1-4.ca.us.ibm.net (165.87.230.238) 121.666 ms 106.453 ms
137.678 ms
23 sfra1sr1-12-0-0.ca.us.ibm.net (165.87.13.9) 134.660 ms 121.347 ms
134.990 ms
24 sfo-pacbell-pop-sc.ca.us.ibm.net (165.87.225.9) 110.007 ms 118.412 ms
25 ded1-fa0-1-0.pbi.net (216.102.176.229) 110.922 ms 121.757 ms 120.744 ms
26 pbi.scrm01.foothill.net (206.13.15.82) 168.531 ms 120.297 ms 126.005 ms
27 inyo.E0.foothill.net (206.170.175.12) 139.673 ms 132.929 ms 127.300 ms
28 fhaub.foothill.net (207.212.142.2) 141.649 ms 122.945 ms 129.213 ms
•  network monitors/analyzers
•  local systems
–  take unit to problem
–  don't depend on working network
–  wide range of cost & function
•  remote systems
–  leave unit on problem or key network
–  remote control & viewing of information
•  privacy & security issues

•  management agents
–  SNMP agents in all "gateway" devices
–  SNMP agents in all servers
–  binary + "analog" reports
•  need something that knows what it is looking at
it

Management for Real
•  Which tools should I use? What do I really
need?
–  Keep it simple!
–  Need to consider engineers working remotely
–  Don’t want to spend too much time maintaining the
tool (it should be helping you!)
–  Different tools for NOC and engineers
–  Different tools for statistics
–  RELIABILITY!

Monitoring
•  simple monitoring tools do 95% of task
–  e.g. ftp://ndtl.harvard.edu/pub/SNMPoll
–  e.g. http://www.merit.edu/internet.tools/rover/
•  monitor should be both poll & trap based for

best reliability
–  but just polling will do better than just traps
–  and will work fine other than response latency
•  simple, terse, messages on problems

A Day in the Life of Merit’s NOC
•  running rover
–  prefer because easy to tell when change occurs
–  quickly can determine type of problem
–  no sifting through GUIs
–  quick screen display
•  alert appears on screen
•  27 Wed02:07 MCH_MSU:S6/1/7.6-->STOCKBRIDG 198.109.177.41 PING
•  28 Tue16:00 MCH_STOCKBRIDGE:S0.2-->JACKSO 198.109.177.46 PING
•  29 Tue16:00 MCH_STOCKBRIDGE:E0-GW 207.74.125.129 PING
•  30 Tue16:00 MCH_STOCKBRIDGE:S0.1-->MSU 198.109.177.42 PING

A Day in the Life of Merit’s NOC
•  open ticket
•  investigate
–  the two most important questions:
•  can you ping it?
•  can you trace to it?
–  get to the the node from somewhere else in the
network?
–  dial-in to the router?
–  serial line problem? call telco
•  If necessary, escalate to engineer
Another example - Sluggishness
•  customer calls NOC - reports sluggishness
•  open ticket
•  investigate
–  check mrtg
•  more traffic now than normal?
–  use netflow to determine what type of traffic
•  possible denial of service attack
–  circuit problem?
•  call telco to test
•  always call customer back to get okay to close
Another example - DOS
•  Customer reports possible Denial of Service
•  Open ticket
•  Investigate
–  notice a large amount of packets from one
destination?
•  log onto router
•  ip accounting
•  sho ip route cache flow
–  install packet filter
–  report to offending ISP

Tracing packets on cisco -
interface
•  cisco access list access-group
–  permit everything, but log packets from 10.2.3.4 to
195.176.0.0/16
•  access-list 199 permit ip 10.2.3.4 0.0.0.0 195.176.0.0
0.0.255.255 log-input
255.255.255.255
•  apply access-list to interface
•  interface serial3
•  ip access-group 199 out

Tracing packets on cisco - debug
ip packet
•  cisco access list
–  permit packets from 10.2.3.4 to 195.176.0.0/16,
deny others
0.0.255.255 log-input
•  access-list 199 deny ip 0.0.0.0 255.255.255.255 0.0.0.0
255.255.255.255
•  use access-list with “debug ip packet”
•  debug ip packet 199

Limiting bandwidth
•  access-list matches a class of traffic (e.g. ICMP)
•  use bandwidth management techniques to limit
amount of traffic in that class
–  cisco CAR or traffic-shaping

Things to Look For
•  duplicate addresses
•  network/link load
•  router/bridge
–  CPU load
–  errors
–  drops!!
–  interface resets
–  collisions (if CSMA/CD network)

Things to Do (Defensive)
•  Filter!!! Filter!!! Filter!
•  Use the Internet Routing Registry!
–  register your routes
–  register your policy
–  configure your routers off of the database!
•  tools available
•  http://www.isi.edu/ra/RAToolSet
•  use the Route Servers!

Route Filtering
BBN Planet
MIT
MCI
dial-up
provider
in VA
NAP
SPRINT

Things Not to Do
•  tunnel
•  complex routing
•  reconfig on the fly

Problems
•  we are early in the internet management game
–  there is still a lot to learn
•  prices still high for functionality
–  many new NMSs will be on the market soon, will
help lower price and expand capabilities
•  data networks are not "plug and play" with
large scale
•  nefarious people

More Problems
•  not so good at provoking simple, easy to
understand, warning to non-gurus
•  should have database & logic about when to
cry wolf
–  critical vs, noncritical device, access restrictions,
who to call when
•  needs to be usable by "normal" people
•  needs to say when users will complain

Even more Problems
•  training your Network Operations Staff
•  keeping your database up-to-date
–  router configs
–  contact information
•  communication with the telco

More things you can do!
•  secure your router
–  tacacs
–  radius
–  restrict login and snmp access
•  enable syslog logging
–  security
–  debugging

•  Filtering
–  generate your filters off of the IRR
–  anti-spoofing filters
–  filter private networks (RFC 1918)
–  recommended filter list
•  http://www.merit.edu/ipma/docs/help.html

•  educate your NOC
–  provide adequate documentation
–  escalation procedures
•  register your routers in DNS
–  traceroutes easier to follow
coolbeans% traceroute www.above.net

traceroute to www.above.net (207.126.96.163), 30 hops max, 40 byte packets
1 eth0-2.michnet1.mich.net (198.108.61.1) 1.074 ms 0.888 ms 0.696 ms
2 hssi1-0-0.msu.mich.net (198.108.22.102) 77.602 ms 75.356 ms 12.437 ms
3 aads.above.net (198.32.130.71) 9.981 ms 15.098 ms 11.342 ms
4 chicago-core1.ord.above.net (209.249.0.129) 9.634 ms 9.834 ms 9.590 ms
5 sjc-chicago-oc3.above.net (209.249.0.125) 71.261 ms 71.232 ms 71.305 ms
6 main2-core1-oc3-3.sjc.above.net (209.133.31.97) 123.499 ms 71.512 ms 71.8
7 www.above.net (207.126.96.163) 72.861 ms 72.624 ms 74.529 ms

•  Prevent excessive route-flapping
–  enable route-flap dampening
–  use CIDR
–  use filters

References
•  http://www.merit.edu/ipma/docs/isp.html
•  http://www.nanog.org
•  http://www.caida.org
•  http://www.nlanr.net
•  http://www.cisco.com
•  http://www.amazing.com/internet/
•  http://www.isp-resource.com/
•  http://www.merit.edu/ipma
•  http://www.ripe.net
Uso do FreeBSD
em NOCs

FreeBSD em NOCs
•  Diversos NOCs de NRENs utilizam o FreeBSD
em sua infra-estrutura
•  RNP
•  Registro.BR
•  APAN JP NOC
–  Serviços: DNS, email, web, squid,
–  Monitoração: OC3mon, OC12mon, GPS,
http://www.jp.apan.net/NOC/implementation/servers.shtml

FreeBSD em NOCs
Tokyo XP NOC Tools
•  OC3mon •  BGP route view
traces the traffic of views the BGP routes
ATM links advertised/received on
•  Surveyor the WEB
measures one-way •  Multicast Session view
delay, developed by
ANS views the SD session
on the WEB
•  Skitter
measures the •  Pchar/Netperf
reachability, measure bandwidth
developed by CAIDA
•  MRTG
monitor the traffic
Ferramentas para
Gerência de Redes

Ferramentas
Nome URL
Cacti www.cacti.net
fping www.fping.com
H.323 Beacon Tool www.osc.edu/oarnet/itecohio.net/beacon/
Iperf dast.nlanr.net/Projects/Iperf/
Ipplan iptrack.sourceforge.net
LG – Looking Glass www.version6.net/LG
More.groupware www.moregroupware.org
MRTG www.mrtg.org
mtr www.bitwizard.nl/mtr/
Multicast Beacon dast.nlanr.net/Projects/Beacon/
Nagios www.nagios.org
NeDi nedi.web.psi.ch

Ferramentas
Nome URL
Network Weathermap netmon.grnet.gr/weathermap/
ping /sbin/ping
Plone www.plone.org
RT – Request Tracker www.bestpractical.com
RANCID www.shrubbery.net/rancid/
rrdtool people.ee.ethz.ch/~oetiker/webtools/rrdtool/
SmokePing people.ee.ethz.ch/~oetiker/webtools/smokeping/
Stager software.uninett.no/stager/
traceroute /usr/sbin/traceroute
Webmin www.webmin.com

Ferramentas
Atendimento e suporte
•  Request Tracker (RT) - Sistema para
atendimento e acompanhamento de
solicitações (helpdesk)
http://www.bestpractical.com
•  Groupware
–  more.groupware
www.moregroupware.org
•  Documentação
–  Wiki: Moinmoin, Kwiki, Mediawiki
–  CMS (Content Management System): Plone
Cacti
http://www.cacti.net
•  Cacti - é uma interface gráfica web feita em
PHP para a ferramenta RRDTool, que coleta
dados via SNMP, armazena informações sobre
os gráficos de estatísticas, contas de usuários e
demais configurações em uma base de dados
MySQL.
•  Ports:
cd /usr/ports/net/cacti && make install clean

Cacti - Interface

Cacti – Gerenciando Dispositivos

Cacti – Consulta por período

Cacti – Funções Monitoradas

fping
http://www.fping.com
•  fping – similar ao ping, usa ICMP para obter
respostas de hosts. É possível especificar
qualquer quantidade de hosts em uma mesma
consulta, que são feitas em paralelo (threads).
•  Saída preparada para uso em scripts e por
outros softwares.
•  Ports:
cd /usr/ports/net/fping && make install clean
•  Uso: fping [opções] [hosts...]

fping
Ex.:
#  fping www.rnp.br www.geant2.net \
www.internet2.edu www.terena.org
www.rnp.br is alive
www.geant2.net is alive
www.internet2.edu is alive
www.terena.org is alive

fping
Ex.:
•  fping -C 1 www.rnp.br www.geant2.net
www.internet2.edu www.terena.org
www.rnp.br : [0], 84 bytes, 0.29 ms (0.29 avg, 0% loss)
www.geant2.net : [0], 84 bytes, 252 ms (252 avg, 0% loss)
www.internet2.edu : [0], 84 bytes, 320 ms (320 avg, 0% loss)
www.terena.org : [0], 84 bytes, 390 ms (390 avg, 0% loss)
www.rnp.br : 0.29
www.geant2.net : 252.15
www.internet2.edu : 320.83
www.terena.org : 390.06

iperf
http://dast.nlanr.net/Projects/Iperf/
•  Aplicação cliente/servidor para medições de
desempenho TCP e UDP
–  Mede a banda TCP máxima
–  Facilita ajuste fino de parâmetros TCP e UDP
–  Reporta banda, jitter, e perda de pacotes
•  Ports:
cd /usr/ports/benchmarks/iperf && \
make install clean
•  Uso:
–  No servidor, digite:
iperf -fk -i30 -u -s
(f)ormato reporta em kbps / (i)ntervalo para reportes = 30 seg.
(u)dp / (s)ervidor
iperf
–  No cliente, digite:
iperf -u -b800k -t3600 -c [servidor]
(u)dp / (b)andwidth = 800kbps / (t)empo de execução = 3600 seg.
(c)liente / [servidor] = servidor a ser acessado
•  Resultado:
[dodpears@vc-iperf iperf]$ iperf -fk -i30 -u -s
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 149.166.197.80 port 5001 connected with 129.79.92.230 port 1031
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-30.0 sec 3000 KBytes 819 Kbits/sec 0.300 ms 0/ 2090 (0%)
[...]

LG
http://www.version6.net/LG
•  LG - é uma ferramenta para implementar um
Looking Glass.
•  CGI script escrito em perl
•  Executa comandos de protocolo BGP, ping e
traceroute em roteadores, ou repassa
comandos a outros looking glasses.
•  Suporta IPv4 e IPv6
•  Usa ssh, telnet ou rsh para acessar o roteador
•  Testado com roteadores Cisco, Juniper e Zebra
•  Ports: N/D
MRTG
http://www.mrtg.org/
•  MRTG - Ferramenta para coletar informações e gerar
estatísticas
•  Usada para registrar tráfego de rede
•  Gera páginas HTML com imagens PNG
•  Fornece uma representação visual do tráfego
•  Permite monitorar e analisar diversas funções
(roteadores, servidores, latência, utilização,
temperatura etc.)
•  Diversas formas de visualização de dados
•  Licença: GPL
•  Autor: Tobias Oetiker

mtr – “My Traceroute”
http://www.bitwizard.nl/mtr/
•  O mtr combina "traceroute" e "ping" em uma
mesma ferramenta de diagnóstico.
•  Autores:
–  Matt Kimball (autor original)
–  Roger Wolff (atual mantenedor)
•  Ports:
cd /usr/ports/net/mtr
•  Uso: mtr <hostname|end.IP>
ex.:
mtr www.internet2.edu

mtr

mtr

Nagios
http://www.nagios.org
O que é Nagios?
•  Aplicação de código aberto (GPL) para monitoramento de redes
•  Plataformas: FreeBSD, Linux, Solaris, etc.
•  Monitora hosts e serviços de uma rede
•  Fornece uma visão geral do estado dos sistemas da rede
•  Notifica quando em caso de problemas
•  Permite ações rápidas para resolução de problemas
•  Fornece relatórios de disponibilidade para SLAs etc.
•  Originalmente chamava-se “NetSaint” (netsaint.org)
•  Nome trocado para “Nagios” em 2001 por questões de marca
registrada
•  N.A.G.I.O.S. = “Nagios Ain't Gonna Insist On Sainthood”

Nagios
•  Projetado de forma modular
•  Daemon contém a lógica de monitoramento e
escalonador
•  CGIs permitem aos usuários visualizar status via web
•  Aplicações externas cuidam do trabalho de
monitoramento de baixo nível
•  Comandos externos podem ser disparados para
tratamento de alertas, mudanças de estados e
informações de monitoramento
•  Possui facilidades para integração com outras
aplicações

Nagios
O que pode ser monitorado?
•  Servidores, estações de trabalho, impressoras,
roteadores etc.
•  Genericamente, qualquer coisa que:
–  Tem ou é associada com um endereço de algum tipo
–  É “alcançavel” pela rede
•  Nagios não sabe ou se importa com protocolos de
rede ou endereços
•  Não é limitado a monitorar equipamentos de rede e
serviços
•  Alvos de monitoramento
–  Hosts
–  Serviços
Nagios
•  Hosts
–  Geralmente hardware: servidores, switches,
roteadores, printers etc.
–  Podem haver relações de dependência com outros
hosts
–  Podem fornecer um ou mais serviços
•  Serviços
–  Coisas associadas com, ou fornecidas por um host
–  Serviços tangíveis (e.g. uso de disco, toner de
impressora)
–  Serviços intangíveis (ex.: HTTP, SMTP, IMAP, POP3,
DNS)
Nagios

Nagios

Nagios

Nagios

NeDi
http://nedi.web.psi.ch
•  NeDi – Network Discovery Suite, um sistema em perl
para descoberta e administração de equipamentos
Cisco.
•  Características
–  Gerenciamento centralizado de configurações de dispositivos
–  Interface web
–  Geração de mapas
–  Listagens de dispositivos
–  Suporta “discovery” de equipamentos Cisco e outros que
suportem o protocolo CDP (Cisco Discovery Protocol).
•  Autor: Remo Rickli

NeDi

NeDi
•  Integração com Cacti e administração de contas e
perfis de usuários em desenvolvimento

NeDi
•  Geração automática de mapas

RANCID
http://www.shrubbery.net/rancid/
rancid – “Really Awesome Network ConfIg Differ”
•  Entrada de dados:
–  Diversos comandos “show(…)” em roteadores
•  Saída de dados:
–  Saída dos comandos show é processda, e
armazenada em CVS
–  diffs são enviados por email
•  Combinado com cvsweb, se obtém uma
interface web para visualização dos diffs.

Network Weathermap
http://netmon.grnet.gr/weathermap
•  Network Weathermap –Software livre e

gratuito, feito em script perl
•  Autor: Panagiotis Christias
•  Licença: GPL (General Public License)
•  Linguagem: Perl
•  Características:
–  Facilidade de implementação e de manutenção
–  Poucos requerimentos de hardware e software

Weathermaps
•  Network Weathermaps apresentam dados complexos
de forma sumarizada.
•  Estendem a metáfora meteorológica de representação
da Internet em forma de nuvem (escondendo sua
complexidade), baseada nos mapas de tempo e clima
dos noticiários e jornais, que mostram chuvas,
tempestades e previsões climáticas.
•  São uma forma de visualização gráfica do tráfego de
uma rede em um determinado momento.
•  Mostram, em mapas, retratos do tráfego de uma rede,
com atualizações periódicas. Geralmente estes mapas
também exibem estatísticas detalhadas e outras
informações.

Aplicações dos Weathermaps
•  Rápida visualização do tráfego em uma rede
•  Permite fácil visualização do uso quantitativo e
qualitativo nos enlaces da rede
(congestionamentos)
•  Ferramenta de apoio às atividades de
Traffic Engineering, Capacity Planning e
de Segurança - visualização de ataques
DoS/DDoS.

Network Weathermap da RNP

Outras Ferramentas
•  Stager – http://software.uninett.no/stager/
–  Ferramenta web para armazenamento, agregação e
apresentação de estatísticas de rede, usando NetFlow,
MPing e SNMP.
•  Zabbix – http://zabbix.sourceforge.net/
–  Aplicação web para monitorar aplicações e redes, que
suporta coleta via polling e recebimento de traps . Possui
recurso para envio de alertas de eventos por email. Suporta
SNMP (v1,v2 e v3).

Conclusões
•  Diversas opções de ferramentas disponíveis
•  Acesso ao código fonte
•  Gerenciamento de funções operacionais de uma
console centralizada ou distribuída.
•  Possibilidade de se criar soluções sob medida para
necessidades particulares
•  Sem custo de licenciamento (por sessão, usuário etc.)
•  Suporte comercial disponível para muitos softwares
•  Possibilidade de melhor retorno de investimento do
que as alternativas comerciais.

Referências
Redes Avançadas
–  Dante – http://www.dante.net/
–  Géant – http://www.geant.net/
–  Géant2 – http://www.geant2.net
–  Internet2 – http://www.internet2.edu/
–  GLIF - http://www.glif.is/
–  Global Next Generation Internet Initiatives
http://www.cse.wustl.edu/~jain/cis788-99/ftp/testbeds/index.html
NOCs
•  IU Global NOC - http://globalnoc.iu.edu/
•  Abilenet NOC - http://www.abilene.iu.edu/
FIM
Muito obrigado!
Alex Moura
alex@rnp.br

Gerência de Redes Avançadas Com FreeBSD

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Gerência de Redes Avançadas Com FreeBSD

Hochgeladen von

Copyright:

Verfügbare Formate

Gerenciando

Redes Avançadas com

• FreeBSD e Software Livre

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

• Não confiável • IPv6 • Uso de DWDM e

[1] Existem tecnologias de maior capacidade (ex.: 40Gbps)

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

RNP – A primeira rede nacional de acesso à

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

• O suporte (help desk ou service desk) de um

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

• Capacidade para atualizações do S.O. com baixo

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

• Cada nó da rede Abilene tem dois racks, sendo um para

I have a network, now what?

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

Place for status updates

Time of Alert that failed

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

Create-date : 06/09/99 12:46:42

11 Wed12:23 rs2MW_O/C 198.32.136.2 PING

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

01/15/99 12:50:06 noc-op

Email response from Abha suggesting contacting peers directly -- see

The alerts cleared shortly before 14:00. I called MCI/Worldcom for an

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

BSDDAY - São Paulo - 13 de agosto de 2005 - Alex Moura

•  FreeBSD e Software Livre

• Não confiável • IPv6 • Uso de DWDM e

•  O suporte (help desk ou service desk) de um

•  Capacidade para atualizações do S.O. com baixo

•  Cada nó da rede Abilene tem dois racks, sendo um para

src IP=132.34.65.1 2535100

•  Filter on the outbound

•  monitor should be both poll & trap based for