Monthly Archives: November 2013

Notas IPv6

IPv6 128 bits
IPv4 32 bits

Atribuição de Prefixos:

Registry Prefix -> Assignado pelo IANA a um RIR e.x. 2310::/12
ISP Prefix -> Assignado pelo RIR a um ISP e.x. 2310:1111:/32
Site Prefix ou Global Prefix-> Assignado por um ISP ou registry a o customer(site) e.x. 2310:1111:2222::/48
Subnet Prefix-> Assignado por um Engineer a um link e.x. 2310:1111:2222:3333::/64

Tipos de Endereços IPv6:

Address Type  Range  Application RFC
Aggregatable global unicast 2000::/3 Host-to-host communication; same as IPv4 unicast. RFC 3587
RFC 3177
Multicast  FF00::/8 One-to-many and many-to-many communication; same as IPv4 multicast.
Anycast  Same as Unicast Application-based, including load balancing,
optimizing traffic for a particular service, and
redundancy. Relies on routing metrics to
determine the best destination for a particular
host.
 RFC 2526
Link-local unicast  FE80::/10 Connected-link communications.
Solicited-node multicast  FF02::1:FF00:0/104 Neighbor solicitation.

Aggregatable global unicast

Os Aggregatable global address prefixes são estruturados de forma a serem sumarizados e agregados sob uma hierarquia consistente, com base no RFC 3177, começam após os primeiros 3 bits no prefixo:

  • Os 45 bits seguintes representam o global routing prefix
  • Os últimos 16 bits no prefixo antes do Interfacede ID, são os referentes ao Site Level Level Aggregator (SLA). Estes bits devem ser usados pela organização no seu endereçamento hierárquico interno. Este campo é conhecido como Subnet ID

Os restantes 64 bits representam o interface ID

2000(3bits)+GlobalPrefix(48bits)+SLA(16bits)+InterfaceID(64bits)

Link-Local Addresses

O endereço Link-local começa sempre com FE80::/10. O interface ID deriva do formato EUI-64. Os restantes 54 bits no prefixo são sempre definidos como 0.

Nas interfaces Ethernet o MAC-Add é a base do Interafce ID no Link-Local, para outros tipos de interfaces é utilizado uma pool de endereços MAC virtual para gerar os Interface ID. Por definição o endereço link-local não é roteavel.

Multicast

Uma vez que o IPv6 não tem o conceito de broadcast, usa multicast em todas as funções á semelhança do broascast no IPv4. Por exemplo, o DHCP IPv6 usa multicast para envar tráfego para um host desconhecido na rede local.

IPv6 Multicast Address Format

Os endereços Multicast no IPv6 começam sempre com FF no 1º octecto do endereço, ou FF00::/8. O 2º octecto especifica o lifetime e scope do grupo multicast. O Lifetime pode ser permanente ou temporário.

O Scope pode ser local para qualquer um dos seguintes:

  • Node (bin 0001)
  • Link (bin 0010)
  • Site (bin 0101)
  • Organization (bin 1000)
  • Global (bin 1110)

FF(8bits)+Lifetime(4bits)+Scope(4bits)+000….(48bits)+InterfaceID(64bits)

Function Multicast Group IPv4 Equivalent
All hosts FF02::1 Subnet broadcast address
All Routers FF02::2 224.0.0.2
OSPFv3 routers FF02::5 224.0.0.5
OSPFv3 designated routers FF02::6 224.0.0.6
RIP v2 FF02::9 224.0.0.9
EIGRP routers FF02::A 224.0.0.10
PIM routers FF02::D 224.0.0.13
DHCP relay agents (routers that forward to the DHCP server) FF02:1:2 N/A
DHCP servers (site scope) FF05::1:3 N/A
ALL NTP servers (site scope) FF05::101 N/A

Anycast

O formato dos endereços anycast é igual aos do unicast. O RFC 2526 recomenda um range de endereços a usar para aplicações Anycast.

The Unspecified Address

Este endereço representa-se desta forma ::. . O Unspecified Address é sempre usado como source address por uma interface que ainda não aprendeu o seu endereço unicast. Este não pode ser assignado a uma interface e usado como endereço de destino.

Method  Dynamic or Static Prefix and length learned from… Host  learned from… Default router  learned from… DNS addresses learned from…
Stateful DHCP Dynamic DHCP Server DHCP Server Router, using NDP (Stateful) DHCP Server
Stateless autoconfig Dynamic Router, using NDP Derived from MAC Router, using NDP Stateless DHCP
Static config Static Local config Local config Router, using NDP Stateless DHCP
Static config with EUI-64 Static Local config Derived from MAC Router, using NDP Stateless DHCP

Learning the Prefix/Length and Default Router with NDP Router Advertisements

O Neighbor Discovery Protocol (NDP) tem diversas funções. Uma das funções permite aos Hosts enviar uma mensagem multicast para os routers no link anunciarem: o Default gateway e os prefixos IPv6 no link. Este processo utiliza mensagens ICMPv6, estas têm o nome de Router Solicitation (RS) e Router Advertisement (RA).

O IPv6 define endereços multicast para diferentes funções, por exemplo, as mensagens RS (com destino FF02::2) apenas são recebidas/processadas pelos Routers sendo que as RA (com destino FF02::1) são enviadas pelos routers e recebidas/processadas apenas pelos hosts IPv6.

Message RS RA
Multicast destination FF02::2 FF02::1
Meaning of Multicast address  All routers on this link All IPv6 nodes on this link

Calculating the Interface ID Using EUI-64

Para criar automaticamente um único Interface ID, o IPv6 define o método para calcular o interface ID (64 bits) derivado do Mac-Address.
O processo EUI-64 utiliza os 6 bytes (48bits) do Mac-Address e expande-o até 64 bits, os 2 bytes (16 bits) são o valor hex FFFE e este é inserido no meio do Mac-Address. É necessário mudar o “universal/local bit” (bit 7 da esquerda para a direita) para o valor 1.

RFC 4291 – IP Version 6 Addressing Architecture

Mac-Address do Host – 0034:5678:9ABC

Interface ID formato EUI-64

00000000 (1ºs 8 bits do Mac-Address)

00000010 (mudando o “universal/local bit” para 1)

00000010 -> 02 hex Resultado: 0234:56FF:FE78:9ABC

Feature Stateful DHCP Stateless DHCP
Remembers IPv6 address Yes Yes
Assigns IPv6 address to client Yes Yes
Supplies useful information, such as DNS server IP addresses Yes No
Most useful in conjunction with stateless autoconfiguration No No

 Unicast IPv6 Addresses

O IPv6 suporta 3 tipos de unicast:

  • Link local
  • Global unicast
  • Unique local

Unique Local IPv6 Addresses

O Unique Local Unicast tem a mesma função que o RFC 1918 no IPv4, relativo a endereços privados. O RFC 4193 refere que este endereços devem ser usados apenas internamente (rede privada) e não advertidos para a internet. Estes endereços começam como FD00::/8

O Interface ID poderá ser criado através de config estática ou através do EUI-64

Link Local Unicast Addresses

O IPv6 usa o Link Local para enviar e receber pacotes IPv6 numa única subnet. Existem diversas utilizações possíveis, apontando algumas:

  • Usado como source address para as mensagens RS & RA
  • Usado pelo Neighbor Discovery (equivalente ao ARP para o IPv6)
  • IP Next-Hop para routing

By default, os routers utilizam um scope de Link Local para os pacotes enviados para um IP Link Local. Conforme o nome indica, os pacotes não saiem do Local Link, subnet. Caso o router receba pacotes com destino a outra subnet este não encaminha o tráfego.

Cada elemento da rede (host,router,etc) calcula o seu Local Link antes de enviar qualquer tráfego para a rede. Após calculado envia uma mensagem RS tendo como source o Link Local.

O Link Local começa com o range FE80::/10, sendo apenas os 1ºs 10 bits. O range pode variar entre FE80::/10, FE90::/10; FEA0::/10; FEB0::/10

IPv6 Unicast Address Summary

RFCs anteriores do IPv6 definiam o Site Local address Type como redes privadas á semelhança do IPv4. Este address Type foi descontinuado (RFC 3879)

Type of Address  Purpose  Prefix  Easily Seen Hex Prefix(es)
Global unicast  Unicast packets sent through the public Internet 2000::/3  2 or 3
Unique local  Unicast packets inside one organization FD00::/8  FD
Link local  Packets sent in the local subnet FE80::/10  FE8
Site local Deprecated; originall meant to be used like private IPv4 addresse FECO::/1  FEC, FED, FEE, FEF
Unspecified An address used when a host has no usable IPv6 address ::/128  N/A
Loopback Used for software testing, like IPv4’s 127.0.0.1 ::1/128  N/A

Neighbor Discovery Protocol for Layer 2 Mapping

Se o MAC não for conhecido, o host/router utiliza o Neighbor Discovery Protocol para dinamicamente descobrir o mesmo. O ND é definido no RFC 2461
O processo funciona como o ARP no IPv4, mas com diferentes detalhes. Neste caso o PC1, envia uma mensagem multicast de nome Neighbor Solicitation (NS) ICMP message, pergunta ao R1 pelo seu Mac-Address. O R1 envia uma mensagem ICMP Neighbor Advertisement (NA), em unicast de retorno ao PC1, listando o seu Mac-address.

As mensagens NS usam um endereço multicast especial de nome Solicited Node Multicast. Em qualquer link, o endereço Solicited Node Multicast representa todos os hosts com os últimos 24 bits nos seus endereços IPv6.Enviando pacotes para o Solicited Node Multicast, o pacote chega ao host correcto, mas também chega a outros hosts. (Nota: Os pacotes enviados para o Solicited Node Multicast têm um scope Link Local).

O Solicited Node Multicast tem o endereço FF02::1:FF:0/104. Os últimos 24 bits (6 digitos Hex) do endereço são formados adicionando os últimos 24 bits do endereço IPv6 para o qual a mensagem está a ser enviada. Esta conceção permite convenientemente o uso de endereços multicast na LAN, que comece com 01005E Hex seguido por um valor 0 (binário) e os restantes 23 bits.

Neste exemplo o endereço IPv6 do R1: 2340:1111:AAAA:1:213:19FF:FE7B:5004, a mensagem de NS é enviada com o endereço FF02::1:FF:7B:5004

Nota: O MAC Ethernet correspondente seria 0100.5E7B.5004

As major roles do IPv6 ND incluem o seguinte:

  • Stateless address autoconfiguration (detailed in RFC 2462)
  • Duplicate address detection (DAD)
  • Router discovery
  • Prefix discovery
  • Parameter discovery (link MTU, hop limits)
  • Neighbor discovery
  • Neighbor address resolution (replaces ARP, both dynamic and static)
  • Neighbor and router reachability verification
Message Type Information Sought or Sent  Source Address Destination Address ICMP Type, Code
Router
Solicitation
(RS)
Hosts query for the
presence of routers on the
link
Address assigned to
querying interface, if
assigned, or :: if not
assigned
FF02::2 133,0
Router
Advertisement
(RA)
Routers advertise their
presence and link
prefixes, MTU, and hop
limits.
Router’s link-local
address
FF02::1 for periodic
broadcasts; address of
querying host for
responses to an RS
134,0
Neighbor Solicitation (NS) Hosts query for other
nodes’ link-layer
addresses. Used for
duplicate address
detection and to verify
neighbor reachability.
Address assigned to
querying interface, if
assigned, or :: if not
assigned
Solicited-node multicast
address or the target
node’s address, if known
135,0
Neighbor Advertisement (NA) Sent in response to NS
messages and
periodically to provide
information to neighbors.
Configured or
automatically
assigned address of
originating interface
Address of node
requesting the NA or
FF02::1 for periodic
advertisements
136,0
Redirect Sent by routers to inform
nodes of better next-hop
routers.
Link-local address of
originating node
Source address of
requesting node
137,0

Neighbor Solicitation

Os nodos IPv6 enviam NS messages para encontra o link-layer do neighbor específico. Esta message é usada para 3 operações:

  • Duplicate address detection (DAD)
  • Neighbor reachability verification
  • Layer 3 to Layer 2 address resolution (as a replacement for ARP)

A resposta é NS message é a Neighbor Advertisement (NA).

Router Advertisement and Router Solicitation

Quando é configurado o comando ipv6 unicast-routing os routers iniciam o envio de mensagens RA, o intervalo de envio é de 200 segundos (by default). Este intervalo pode ser alterado usando o comando ipv6 nd ra-interval. Os RA incluem todos os prefixos configurados na interfave do router.

By Default, o router Cisco adverte-se como sendo o candidato a default gateway. Para não adverter o router como candidato usa-se o comando ipv6 nd ra-lifetime 0. O envio de RA com lifetime=0, informa os hosts para não usar este router.O comando ipv6 nd suppress-ra suprime o envio de RAs.

Se um host não tiver ainda endereço configurado, envia um RS com source unspecified address, caso contrário usa o endeço configurado.

Os hosts enviam RS messages para aprender os endereços dos routers no link.

Duplicate Address Detection (DAD)

Quando uma interface fica operacional, esta efectua o teste de DAD. O propósito é verificar se existe o endereço em causa já se encontra em uso por outro host.
Para efectuar esta verificação a interface utiliza uma mensagem NS (Neighbor Solicitation) para com algumas alterações.Para verificar o seu próprio IP, o host envia uma mensagem NS para o endereço Solicited Node Multicast (destination) baseado no seu próprio endereço IPv6. A source usada é unspecified address (::.), se existe um reply é mensagem estamos perante uma duplicação de IPs.

Na NS message é incluído o field Target Address (endereço a analisar).

Os hosts IPv6 usam este processo para verificar os endereços configurados estaticaticamente ou autoconfigured

Por exemplo: Um host com o IP 2001:128:1F:633:207:85FF: FE80:71B8, envia uma NS message para solicited-node address FF02::1:FE80:71B8/104.  Na ausência de resposta não existe duplicação.

Neighbor Unreachability Detection

Existem 2 formas de confirmar o reachability (two-way) a um nodo:

  • O host envia probes para o solicited-node multicast address e recebe RA/NA em resposta.
  • A comunicação com um host onde existe TCP ACK

ICMPv6

RFC 2463 – Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

As mensagens ICMPv6 foram classificadas em 2 grupos: error reporting messages e informational messages. Para conservar largura de banda, o RFC 2463 sugere o rate-limit ICMPv6 error messages. O Cisco IOS permite rate-limiting definido o intervalo mínimo entre error messages permitindo um token bucket

R1(config)#ipv6 icmp error-interval

Intervalo Default (100ms), e o default token-bucket size são 10 tokens

Com esta config, um novo token (até um máx de 10) é adicionado ao bucket a cada 100ms. Quando o token bucket está full, podem ser enviadas no máx 10 ICMPv6 error messages. Uma vez o token bucket vazio, o router não pode enviar adicionalmente ICMPv6 error messages até um token ser adicionado ao bucket.

DNS

IPv6, RFC 1886 AAAA records
RFC 1886 e RFC 2874 DNS extensions.

DHCP

RFC 3315Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Existem 2 condições para que o host use DHCPv6:

  • O Host é configurado explicitamente para usar DHCPv6
  • O router IPV6 adverte nas RA messages que os hosts devem usar DHCPv6. O router define a M flag (Managed Address Configuration) no RA

Na config Stateful autoconfiguration, o host envia um request DHCP para um dos endereços IPv6 conhecidos na porta UDP 547:

  • FF02::1:2, all DHCP relay agents and servers
  • FF05::1:3, all DHCP servers

O reply do server ao cliente é feito na porta UDP 546.

Configurar pool DHCPv6 no router

ipv6 dhcp server pool-name (comm interface)

Access Lists and Filter-traffic

A conceitos de filtragem de tráfego em IPv4 e IPv6 mantém-se, devem existir alguns cuidados da aplicação de access-lists para os network layer protocols:

  • A sintaxe do uso de access-lists em IPv6 difere um pouco de IPv4, comando  ipv6 traffic-filter access-list-name  { in  |  out}
  • As access-lists são sempre named, não podem ser numéricas (a menos que seja usado o n como name)

R1(config)#ipv6 access-list restrict-telnet
R1(config-ipv6-acl)#  permit tcp any 2001:1:2:3::/64 eq telnet dscp cs1 log
R1(config-ipv6-acl)#  deny tcp any any log-input
R1(config-ipv6-acl)#  line vty 0 4

R1(config-line)# access-class restrict-telnet in
R1#  show access-lists
IPv6 access list restrict-telnet
permit tcp any 2001:1:2:3::/64 eq telnet dscp cs1 log (1 match) sequence 10
deny ipv6 any any log-input (2 matches) sequence 20
R1#

!Filtragem de trafego IPv6
R2(config)# ipv6 access-list no-web
R2(config-ipv6-acl)#  deny tcp any eq www 2001:8:128::/64
R2(config-ipv6-acl)#  permit ipv6 any any
R2(config)# interface FastEthernet0/0
R2(config-int)#  ipv6 traffic-filter no-web in
R2# show ipv6 access-list
IPv6 access list no-web
deny tcp any eq www 2001:8:128::/64 log-input (12 matches) sequence 10
permit ipv6 any any (119 matches) sequence 20

Inverse Neighbor Discovery

O Protocolo ND conhece o endereço IPv6 e procura descobrir o Link Layer Address usado por esse endereço IPv6. Em redes do tipo Frame-Relay ou outros tipos de WAN (Data Link Protocolos), a ordem de discovery é inversa. O Router começa por saber qual o Link Layer Address e necessita de aprender o endereço IPv6 do neighbor. No IPv4 á utilizado o ARP (LAN) e InverseARP (Frame-Relay), o IPv6 utiliza o ND e Inverser Neighbor Discovery (IND), como parte do protocolo ICMPv6 é definido a mensagem Inverse NS (INS) e Inverse NA (INA). A mensagem INS sabe qual o endereço do Link Layer do Neighbor (DLCI do Frame-Relay), e “pergunta “ pelo endereço IPv6 do neighbor. Os detalhes da mensagem INS incluem:

  • Origem IPv6:IPv6 Unicast de quem enviou
  • Destino IPv6: FF02::1 ( Todos os Hosts IPv6 Multicast)
  • Endereços Link Layer
  • Request:  Please reply with your IPv6 address(es)

O reply do IND lista todos os endereços IPv6.

Configuring IPv6 Addresses on Cisco Routers

Sintaxe:

ipv6 address address/length
ipv6 address prefix /length eui-64
ipv6 address autoconfig
ipv6 address dhcp
ipv6 unnumbered interface-type number
ipv6 enable
ipv6 address address link-local
ipv6 address address/length anycast

Configuring Static IPv6 Addresses on Routers

O routing static funciona em IPv4 exatamente como no IPv4, mas com algumas alterações:

  • Rota estática em IPv6 para uma interface tem métrica AD 1, e não zero como no IPv4
  • Rota estática em IPv6 para uma interface do tipo broadcast (tipo ethernet), é obrigatório especificar o endereço IPv6 do next-hop pelas razões apresentadas de seguida

Conforme mencionado, as rotas estáticas IPv6 que apontam para interface do tipo broadcast (ethernet) devem especificar o next-hop. Isto deve-se ao IPv6 não usar ARP, não existem conceito de proxy-ARP no IPv6. O router next-hop não faz proxy para um destino diferente da Subnet.

A utilização do Comando debug ipv6 routing (antes de efetuar static/dynamic routing) é sem dúvida importante quando existe uma corrida contra o tempo.

Facto “There are no shortcuts to success, and don’t waste time looking them”

Depois de ler o livro “Cisco Frame Relay Solutions Guide“, não poderia deixar passar em branco esta nota do autor da qual também sou seguidor convicto.

There are no shortcuts to success, and don’t waste time looking them.

These words come from one of my personal heroes, retired General Colin Powell. His words of
advice ring true for soldiers as well as anyone striving to become a CCIE. There exists no
single source of CCIE knowledge, no all-in-one book, including this text, that will get you into
the ranks of the CCIEs. And as Powell’s words echo, “don’t waste time looking for them.” At
the time of this writing, September 2001, Cisco states that there are 6678 active CCIEs in the
world. When you compare this number to how Cisco predominates the market, the ranks of
the CCIEs still remain very slim.

No tags for this post.

Mapear IP Multicast Addresses em MAC Addresses

O MAC address é gerado com base endereço Multicast

Como calcular o endereço MAC address?

01005E + 0 (24º bit) + 23 bits do endereço multicast

Exemplos:

Interface: 192.168.196.1 — 0x38
Internet Address Physical Address Type
192.168.196.255 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.252 01-00-5e-00-00-fc static
239.255.255.250 01-00-5e-7f-ff-fa static

Fim do “The Internet Protocol Journal”

É com grande tristeza que hoje recebi este email da Cisco, decidiram terminar talvez com uma das revistas da especialidade mais interessantes que li até ao dias de hoje “the Internet Protocol Jounal”, onde li vários artigos interessantes sobre tecnologias e ideias na sua grande maioria agnósticas ao fabricante. Escritores? Foram muitos os que deram alma a esta revista, alguns conhecidos outros nem tanto. A Cisco decidiu manter a versão online aqui. Outrora, a revista Packet Magazine fez as delicias de muitos Networkers sendo o seu seu ultimo lançado em 2006.

November 2013

Dear Subscriber,

At this time, Cisco Systems, Inc. has decided not to continue
publishing The Internet Protocol Journal (IPJ) effective
immediately.

We thank all of our loyal readers for your support during the last
15 years. Your feedback has been a key part of making this
publication a success.

Cisco also wishes to thank the authors of the published articles,
and all those who submitted articles. A special note of thanks goes
to the IPJ Editorial Advisory Board and the article reviewers who
have helped to maintain the very high standards of journalistic and
technical quality of IPJ.

The online version of the Internet Protocol Journal will remain
available for reference, including all back issues in PDF and HTML
format as well as the index files. The IPJ website remains at:
http://www.cisco.com/ipj

While no new issues will be produced by Cisco, we are not closing
the subscription database and you can continue to provide updates by
means of your subscription ID and e-mail address as before. For the
time being, you may use the ipj@cisco.com address for such updates
if you do not have access to your registered e-mail address or have
forgotten your subscription ID.

Discussions are underway to find a new home for IPJ and if this
happens we will certainly inform you of the details. The IPJ
subscriber list will not be used for anything other than
notifications about IPJ.

In the meantime, if you have any questions and comments, please feel
free to contact me directly at: olejacobsen@me.com

—Ole J. Jacobsen, Editor and Publisher

 

Volume 16

  • Number 1, March 2013
  • Number 2, June 2013

Volume 15

  • Number 1, March 2012
  • Number 2, June 2012
  • Number 3, September 2012
  • Number 4, December 2012

Volume 14

  • Number 1, March 2011
  • Number 2, June 2011
  • Number 3, September 2011
  • Number 4, December 2011

Volume 13

  • Number 1, March 2010
  • Number 2, June 2010
  • Number 3, September 2010
  • Number 4, December 2010

Volume 12

  • Number 1, March 2009
  • Number 2, June 2009
  • Number 3, September 2009
  • Number 4, December 2009

Volume 11

  • Number 1, March 2008
  • Number 2, June 2008
  • Number 3, September 2008
  • Number 4, December 2008

Volume 10

  • Number 1, March 2007
  • Number 2, June 2007
  • Number 3, September 2007
  • Number 4, December 2007

Volume 9

  • Number 1, March 2006
  • Number 2, June 2006
  • Number 3, September 2006
  • Number 4, December 2006

Notas Network Address Translation (NAT)

O NAT é definido no RFC 1631

Name Location of Host Represented by Address IP Address Space in Which Address Exists
Inside Local address Inside the enterprise network Part of the enterprise IP address space;typically a private IP address
Inside Global address Inside the enterprise network Part of the public IP address space
Outside Local address In the public Internet; or, outside the enterprise network Part of the enterprise IP address space; typically a private IP address
Outside Global address In the public Internet; or, outside the enterprise network Part of the public IP address space

Ligações:

R1——-s2/1-(outside)R2-(Inside)f0/1———-f0/0-R3

Exemplo 1:

Usando Static NATs

R2(config)#
ip route 0.0.0.0 0.0.0.0 192.168.2.1

interface FastEthernet0/1
ip address 192.168.20.2 255.255.255.0
 ip nat inside

interface Serial2/1
ip address 192.168.2.2 255.255.255.0
 ip nat outside

ip nat inside source static 1.1.1.1 2.2.2.1

R3(config)#
ip route 0.0.0.0 0.0.0.0 192.168.20.2
interface FastEthernet0/0
ip address 192.168.20.1 255.255.255.0

interface Loopback11
ip address 1.1.1.1 255.255.255.255
interface Loopback14
ip address 1.1.1.4 255.255.255.255
interface Loopback15
ip address 1.1.1.5 255.255.255.255
interface Loopback16
ip address 1.1.1.6 255.255.255.255
interface Loopback17
ip address 1.1.1.7 255.255.255.255
interface Loopback18
ip address 1.1.1.8 255.255.255.255
interface Loopback19
ip address 1.1.1.9 255.255.255.255
interface Loopback20
ip address 1.1.1.10 255.255.255.255

R3#ping 192.168.10.1 so loop11

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/40/48 ms

R2#sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 2.2.2.1:5         1.1.1.1:5          192.168.10.1:5     192.168.10.1:5

Exemplo 2:

Usando Dynamic NAT

R2(config)#

!Identificar as origens que usam o NAT
access-list 1 permit 1.1.1.4 0.0.0.3

!Criar a pool de IPs
ip nat pool Pool1 2.2.2.4 2.2.2.7 prefix-length 30

ip nat inside source list 1 pool Pool1

R3#ping 192.168.10.1 so loop11

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/40/48 ms

R3#telnet 192.168.10.1 /source-interface loop15
Trying 192.168.10.1 … Open

R2#sh ip nat statistics
Total active translations: 5 (1 static, 4 dynamic; 2 extended)
Outside interfaces:
Serial2/1
Inside interfaces:
FastEthernet0/1
Hits: 108  Misses: 0
CEF Translated packets: 104, CEF Punted packets: 2
Expired translations: 6
Dynamic mappings:
— Inside Source
[Id: 1] access-list 1 pool Pool1 refcount 4
 pool Pool1: netmask 255.255.255.252
        start 2.2.2.4 end 2.2.2.7
        type generic, total addresses 4, allocated 2 (50%), misses 0
Appl doors: 0
Normal doors: 0
Queued Packets: 0

R2#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
tcp 2.2.2.6:52716      1.1.1.5:52716      192.168.10.1:23    192.168.10.1:23
— 2.2.2.6            1.1.1.5            —                —
icmp 2.2.2.5:2         1.1.1.6:2          192.168.10.1:2     192.168.10.1:2
— 2.2.2.5            1.1.1.6            —                —
— 2.2.2.1            1.1.1.1            —                —

Exemplo 3:

Usando NAT overload

!Overload atraves de uma Pool

access-list 2 permit 1.1.1.8
ip nat pool Pool_GLOBAL 2.2.2.8 2.2.2.11 netmask 255.255.255.252
ip nat inside source list 2 pool Pool_GLOBAL overload

R3#telnet 192.168.10.1 /source-interface loop18

R2#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
— 2.2.2.1            1.1.1.1            —                —
tcp 2.2.2.10:39915     1.1.1.8:39915      192.168.10.1:23    192.168.10.1:23
tcp 192.168.2.2:19724  1.1.1.9:19724      192.168.10.1:23    192.168.10.1:23
tcp 192.168.2.2:51357  1.1.1.10:51357     192.168.10.1:23    192.168.10.1:23

Usando NAT overload da interface Outside

 

!Identificar as origens que usam o NAT
access-list 3 permit 1.1.1.9
access-list 3 permit 1.1.1.10

ip nat inside source list 3 interface Serial 2/1 overload

R3#telnet 192.168.10.1 /source-interface loop19
R3#telnet 192.168.10.1 /source-interface loop20

R2#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
— 2.2.2.1            1.1.1.1            —                —
tcp 2.2.2.10:39915     1.1.1.8:39915      192.168.10.1:23    192.168.10.1:23
tcp 192.168.2.2:19724  1.1.1.9:19724      192.168.10.1:23    192.168.10.1:23
tcp 192.168.2.2:51357  1.1.1.10:51357     192.168.10.1:23    192.168.10.1:23

Notas AAA Authentication

O termo authentication, authorization, e accounting (AAA) refere-se a uma variedade comum de features de segurança.

O método + forte de autenticação é através de TACACS+ ou RADIUS.

Quando os routers/switchs recebem o user/password enviam-no encriptado para o servidor, recebendo uma resposta accept/reject do user em causa.

  RADIUS   TACACS+
Scope of Encryption: packet payload or just the password Password only  Entire payload
Layer 4 Protocol UDP  TCP
Well-Known Port/IOS Default Port Used for authentication 1812/1645* 49/49
Standard or Cisco-Proprietary RFC 2865  Proprietary

*Radius originally defined port 1645 as the well-known port, which was later changed to port 1812.

Usando Métodos default na Autenticação

Um conjunto de métodos de autenticação, será usado cada um por ordem até um dos métodos retornar uma resposta da autenticação, como accept/reject o user.

Uma config simples de AAA define um conjunto default de métodos de autenticação, + um segundo conjunto default de métodos de autenticação usado pelo comando enable

Os métodos default de autenticação do login aplicam-se á console, vty, e aux. Os métodos default de autenticação usados quando é utilizado o comando enable, indicam o que o IOS deve fazer quando o user digita este comando.

Descrição dos passos:

  1. Ativar o AAA com o comando global aaa new-model
  2. Definir o IP e key de encriptação para o tipo de servidor em questão: radius-server host ,  radius-server key,  tacacs-server  host , e tacacs-server key
  3. Definir por default o conjunto de métodos de autenticação para o acesso ao CLI usando o comando aaa authentication login default
  4. Definir por default o conjunto de métodos de autenticação para o acesso enable-mode usando o comando aaa authentication enable default

No exemplo seguinte, são usados 2 servidores RADIUS, um configurado com a porta default do Cisco IOS 1645 e a outra com a 1812. Com base neste pressuposto autenticação é feita da seguinte forma:

  • Quando é feita uma tentativa de login, o Cisco IOS testa a autenticação usando o 1º Server RADIUS; Se não existir resposta, o IOS tenta o 2º Server. Se não existir qualquer resposta, o acesso é permitido ao user (authentication mode none)

Quando qualquer user executa o comando enable, o router tenta usar os servers RADIUS, por ordem. Se não existir qualquer resposta, o router aceita o login de um user/password local no router cisco/cisco

enable secret 5 $1$Gvzt$ux/PhTwSscDNOyNIyr5Be/
username cisco password 0 ciscoaaa new-model
aaa authentication enable default group radius local
aaa authentication login default group radius none
!
radius-server host 10.1.1.1 auth-port 1812 acct-port 1646
radius-server host 10.1.1.2 auth-port 1645 acct-port 1646
radius-server key cisco
!
line con 0
password cisco
line vty 0 4
password cisco

Usando Multiplos Métodos de Autenticação

O comando aaa authentication suporta até 4 métodos num único comando. Adicionalmente não existe limite do nº de servidores RADIUS/TACACS+ referenciados por grupo RADIUS/TACACS+.

A lógica do Cisco IOS usada para estes métodos é:

  • Os métodos são executados por ordem segundo o comando. Quando o 1º método falha, é executado o 2º, e assim em diante. É usado o 1º método que recebe a decisão de allow ou reject
  • Se o método definir um grupo de servidores, é usado o 1º da lista. Caso este não responder, são usados os seguintes de forma sequencial. É usado o 1º server que receba a decisão de allow ou reject

Se não existir nenhuma resposta para qualquer método, o request é rejeitado.

Method  Meaning 
group radius Use the configured RADIUS servers
group tacacs+ Use the configured TACACS+ servers
group  name Use a defined group of either RADIUS or TACACS+ servers
enable Use the enable password, based on enable secret  or  enable password commands
line Use the password defined by the password command in  line  configuration mode
local Use  username commands in the local configuration; treats the username as case sensitive, but the password as case sensitive
local-case Use  username commands in the local configuration; treats both the username and password as case sensitive
none No authentication required; user is automatically authenticated

Grupos de AAA Servers

By default o Cisco IOS agrupa os servers de RADIUS e TACACS configurados em grupos, aplicando o nome de radius e tacacs+. O comando aaa authentication inclui as palavras group radius ou group tacacs+ referindo-se aos grupos default.

Pode existir a necessidade de criar grupos específicos de RADIUS/TACACS+ para diferentes fins.

aaa new-model
!
aaa group server radius ccie
server 10.1.1.3 auth-port 1645 acct-port 1646
server 10.1.1.4 auth-port 1645 acct-port 1646
!
aaa authentication enable default group ccie local
aaa authentication login default group ccie none

A console, vty, e aux (apenas nos routers) lines podem sobrepor-se ao uso do login authentication default através do comando login authentication name.

  • console—tenta usar os servers RADIUS, e usa a password definida na line caso não exista resposta
  • vty— tenta usar os servers RADIUS, usa os usernames/passwords locais caso não exista resposta
  • aux — tenta usar os servers RADIUS, não autentica caso não exista resposta

Após definido os diferentes métodos de authentication, é necessário aplicá-los a cada line respetiva.

aaa authentication login on-console group radius line
aaa authentication login on-vty group radius local
aaa authentication login on-aux group radiusline con 0
password 7 PF73TGMDRQ1U
 login authentication on-console
line aux 0
 login authentication on-aux
line vty 0 4
password 7 PF3RUQGXMDS8
 login authentication on-vty

Notas 802.1x

O IEEE 802.1X define os detalhes de autenticação dos users na LAN, usando o Extensible Authentication Protocol (EAP), RFC 3748.

O EAP inclui mensagens do protocolo pelo que o user pode ser desafiado a fornecer uma password, bem como os flows para a criação de one-time passwords (OTPs) RFC 2889

As EAP messages são encapsuladas diretamente em frames ethernet entre 802.1X supplicant (user device) e o 802.1X authenticator (switch). Estas frames chamam-se EAP over LAN (EAPoL). O RADIUS espera por EAP messages com uma estrutura chamada de RADIUS Attribute, com estes atributos dentro de uma mensagem normal de RADIUS. Para suportar os 2 protocolos o switch faz translate de mensagens EAPoL e RADIUS que necessitem de fluir entre o supplicant e o authentication server. A VLAN na porta do switch é assignada com base nos atributos enviados pelo RADIUS server, específico do Vendor:

–[64] Tunnel-Type = VLAN

–[65] Tunnel-Medium-Type = 802

–[81] Tunnel-Private-Group-ID = VLAN name or VLAN ID

Attribute [64] must contain the value VLAN (type 13). Attribute [65] must contain the value 802 (type 6). Attribute [81] specifies the VLAN name or VLAN ID assigned to the 802.1X-authenticated user.

A figura seguinte mostra uma vista simplista dos fluxos do processo de authentication. O switch e o supplicant criam uma OTP usando uma key temporária, com o switch a fazer forwading da authentication request para o server authentication.

8021.x

Os roles 802.1x na acima sumarizam-se em:

  • Supplicant  — The 802.1X driver that supplies a username/password prompt to the user and sends/receives the EAPoL messages
  • Authenticator — Faz a translação entre as mensagens EAPoL e o RADIUS em ambas as direções, e ativa/desativa as portas com base no resultado (success/failure) obtido da authentication
  • Authentication server  — guarda os usernames/passwords e verifica se os valores enviados estão corretos antes de autenticar o user

O Switch trata a authentication do user 802.1X como outra opção para a authentication AAA, seguindo os passos:

  1. Config do comando aaa new-model
  2. Definir os IPs dos RADIUS e Keys através do comando radius-server host e radius-server key
  3. Definir o método de authentication (o único método disponível é o RADIUS) usando o comando aaa authentication dot1x default ou, para múltiplos grupos aaa authentication dot1x group name
  4. Ativar o 802.1X globalmente através do comando dot1x system auth-control
  5. Definir em interface o comando dot1x port-control {auto  |  force-authorized |  force-unauthorized} para usar 1 dos 3 métodos:
    • Usar 802.1X (auto )
    • Não usa o 802.1X, mas a interface é autorizada automaticamente (force-authorized) (default)
    • Não usa o 802.1X, mas a interface não é autorizada automaticamente, ficando no estado não autorizado permanentemente (force-unauthorized)

!Permite varios hosts 802.1x na mesma porta
dot1x host-mode multi-host

!Re-autenticar manualmente um cliente
dot1x re-authenticate interface interface-id

!Ativar a re-autenticacao do cliente(disabled by default)
interface interface-id
dot1x reauthentication
dot1x timeout reauth-period seconds

!Configurar VLAN Guest
dot1x guest-vlan
vlan-id

Exemplo:

Ligações:

Cliente————-f1/1-Sw01Sem_802.1x——-f1/2-Sw01
BLACK_PORT——-f1/2-Sw01

Sw01(config)#

aaa new-model

radius-server host 192.168.50.10 auth-port 1645 acct-port 1646 key CCIE

aaa authentication dot1x 802.1X group radius

dot1x system-auth-control

interface FastEthernet1/1
switchport mode access
dot1x port-control auto
!
interface FastEthernet1/2
switchport mode access
dot1x port-control force-authorized
!
interface FastEthernet1/3
switchport mode access
dot1x port-control force-unauthorized

R3#show dot1x all
Sysauthcontrol              Enabled
Dot1x Protocol Version            2

Dot1x Info for FastEthernet1/1
———————————–
PAE                       = AUTHENTICATOR
PortControl               = AUTO
ControlDirection          = Both
HostMode                  = SINGLE_HOST
ReAuthentication          = Disabled
QuietPeriod               = 60
ServerTimeout             = 30
SuppTimeout               = 30
ReAuthPeriod              = 3600 (Locally configured)
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 30
RateLimitPeriod           = 0

Dot1x Info for FastEthernet1/2
———————————–
PAE                       = AUTHENTICATOR
PortControl               = FORCE_AUTHORIZED

ControlDirection          = Both
HostMode                  = SINGLE_HOST
ReAuthentication          = Disabled
QuietPeriod               = 60
ServerTimeout             = 30
SuppTimeout               = 30
ReAuthPeriod              = 3600 (Locally configured)
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 30
RateLimitPeriod           = 0

Dot1x Info for FastEthernet1/3
———————————–
PAE                       = AUTHENTICATOR
PortControl               = FORCE_UNAUTHORIZED
ControlDirection          = Both
HostMode                  = SINGLE_HOST
ReAuthentication          = Disabled
QuietPeriod               = 60
ServerTimeout             = 30
SuppTimeout               = 30
ReAuthPeriod              = 3600 (Locally configured)
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 30
RateLimitPeriod           = 0

!Re-autenticar manualmente
dot1x re-authenticate interface fastethernet0/1

Notas Web Cache Communication Protocol (WCCP)

O Web Cache Communication Protocol (WCCP)  é uma tecnologia content-routing proprietária da Cisco que permite integrar cache-engines na rede.
Para aliviar os links WAN do congestionamento em redes com diversos hosts, a Cisco desenvolveu o WCCP para coordenar o trabalho dos edge routes e content engines (conhecidos como cache engines). O Content engine captura com frequência os dados acessados, usualmente tráfego HTTP, localmente, portanto quando os users tentam aceder novamente ás mesmas páginas, o conteúdo é “descarregado” diretamente da cache engine em vez de atravessar a WAN.
O WCCP difere da operação de um proxy uma vez que os hosts não têm conhecimento que o content engine está envolvido na transação.

Usando o WCCP (usa a porta UDP 2048), um router e um content engine, ou uma pool de content engines (conhecida como cluster) ficam conscientes um do outro. Num cluster de content engines, estes comunicam também entre si usando o WCCP. Podem comunicar com o router até 32 content engines usando o WCCPv1. Se existir mais do que um contente engine presente, será elected o com IP + baixo.
No WCCPv1 apenas um router pode redirecionar tráfego para um content engine, ou um cluster de content engines.
No WCCPv2, múltiplos routers e multipos content engines podem ser configurados como WCCP service group.

O WCCPv1 suporta apenas HTTP, enquanto que o WCCPv2 suporta outros tipos de tráfego e features comparativamente ao v1:

  • Suporta tráfego TCP e UDP além do porto 80, incluindo FTP caching, FTP proxy handling, web caching para os ports além do 80, Real Audio, vídeo, e telephony.
  • Permitir a segmentação dos caching services disponibilizado por um caching cluster para um protocolo em particular ou protocolos, e usa uma priority system para decidir que cluster usar para um cached protocol
  • Suporta multicast para simplificar a config
  • Suporta múltiplos routers (até 32 por cluster) para redundância e load distribution (todos os contente engines num cluster devem ser config para comunicar com todos os routers nesse cluster)
  • Permito o uso de MD5 na comunicação WCCP através do comando ip wccp password password
  • Permite load distribution
  • Suporta transparent error handling

By default, após ativar o WCCP no router a versão usada é a v2, todas as interfaces são afetadas por esta config global. Os routers e content engines podem simultaneamente participar em mais do que um service group. Estas definições de WCCP são config por interface.

O WCCP permite usar access-lists para filtrar tráfego apenas para alguns clientes usando o ip wccp web-cache redirect-list access-list . O WCCP permite também usar ACLs para determinar que tipos de tráfego o router deve aceitar apartir dos content engines, usando o comando ip wccp web-cache group-list access-list

Exemplo:

Fazer Redirect de todo o tráfego, excepto com destino ao 10.10.10.10 na interface Serial 2/1.
A interface Fastethernet 0/0 deve ser excluida do redirect

access-list 100 deny ip any host 10.10.10.10
access-list 100 permit ip any any

R2(config)#
ip wccp web-cache
ip wccp version 2
!Redirect de todo o tráfego, excepto com destino ao 10.10.10.10
ip wccp web-cache redirect-list 100
!
interface Serial2/1
ip wccp web-cache redirect in

!Efectua bypass ao cache-engine
interface Fastethernet 0/0
ip wccp redirect exclude in

R2#sh ip wccp interfaces detail
WCCP interface configuration details:
FastEthernet0/0
Output services: 0
Input services:  0
Mcast services:  0
      Exclude In:      TRUE

Serial2/1
Output services: 0
        Input services:  1
        Static:          Web-cache
Dynamic:         None
Mcast services:  0
Exclude In:      FALSE

R2#sh ip wccp web-cache
Global WCCP information:
Router information:
Router Identifier:                   -not yet determined-
Protocol Version:                    2.0

Service Identifier: web-cache
Number of Service Group Clients:     0
Number of Service Group Routers:     0
Total Packets s/w Redirected:        0
Process:                           0
Fast:                              0
CEF:                               0
Service mode:                        Open
Service access-list:                 -none-
Total Packets Dropped Closed:        0
Redirect access-list:                100
Total Packets Denied Redirect:       0
Total Packets Unassigned:            0
Group access-list:                   -none-
Total Messages Denied to Group:      0
Total Authentication failures:       0
Total Bypassed Packets Received:     0

Notas Zone-Based Firewall (ZBFW)

As policies do classic IOS inspection aplicam-se a todo o tréfego na interface, não é possível aplicar policies distintas a diferentes grupos de users. O Zone-based firewall (ZFW), disponivel apartir da IOS Release 12.4(6)T já o permite.

O tráfego pode circular livremente entre interface da mesma zone, mas é bloqueado by default entre zones.

As Zone Policies são configuradas usando o Class-Based Policy Language (CPL), que é muito similar á CLI do Modular QoS Command Line Interface (MQC) que usa class/policy maps.

Foi introduzida uma nova class e policy map type (inspect  type) para usar nas zone-based firewalls.

O ZBF permite o inspection e controlos de diversos protocolos tais como:

  • HTTP e HTTPS
  • SMTP, Extended SMTP (ESMTP), POP3 e IMAP
  • Aplicações Peer-to-peer, com a habilidade para usar heuristics to track port hopping
  • Instant messaging applications (AOL, Yahoo!, and MSM)
  • Remote Procedure Calls (RPC)

Passos para configurar o ZFW:

  1. Decidir as zones necessárias, e criá-las no router
  2. Decidir que tráfego deve circular entre as zones, e criar as zone-pairs no router
  3. Criar class maps para identificar o tráfego a ser inspect pelo firewall entre zones
  4. Assignar policies ao tráfego criando policy maps e associando class maps
  5. Assignar policy maps ás zone-pair apropriados
  6. Assignar as interfaces ás zones. Uma interface apenas pode pertencer a uma security zone

O router cria automaticamente uma zona para o seu próprio tráfego, de nome self zone. Todo o tráfego de/para esta zona é permitido, pode no entanto ser alterado.

As Policy maps podem tomar as seguintes acções para cada class:

  • Drop — Drop the packet
  • Inspect — Use Context-based Access Control Engine
  • Pass — Pass the packet
  • Police — Police the traffic
  • Service-policy — Use Deep Packet Inspection Engine
  • Urlfilter — Use URL Filtering Engine

Podem ser usados parameters maps para gerar alertas, audit trails, e controlar os parâmetros de sessão p.ex. o nº sessões half-open, Idle das sessões,etc.

Exemplo:

Ligações:

R1——s2/1-R2-f0/1———-f0/0-R3

Acessos:

Garantir o telnet e http apartir do R3 para qualquer destino, devem ser ainda inspecionados os requests GET no http e gerado log.Qualquer acesso apartir do INSIDE excluindo os mencionados anteriormente, devem ter o idle-timeout para 100 segundos. Será ainda possível ter respostas ao PING apartir do OUTSIDE

zone security INSIDE
zone security OUTSIDE

Interface S2/1
zone-member security OUTSIDE

Interface F0/1
zone-member security INSIDE

zone-pair security INSIDE-OUTSIDE source INSIDE destination OUTSIDE
zone-pair security OUTSIDE-INSIDE source OUTSIDE destination INSIDE

ip access-list extended TELNET
permit tcp any any eq telnet

ip access-list extended other_Traffic
permit ip any any

parameter-map type inspect TIMEOUT
udp idle-time 100
tcp idle-time 100

class-map type inspect match-all other_Traffic
match access-group name other_Traffic

class-map type inspect match-all TELNET
match access-group name INSIDE-OUTSIDE
match protocol telnet

! Os requests Get no protocolo HTTP serao inspect
class-map type inspect http method_HTTP
 match  request method get

class-map type inspect match-all _HTTP
match protocol http
!
!Esta policy para DPI tem que ser criada separadamente
policy-map type inspect http DPI_HTTP
class type inspect http method_HTTP
log

policy-map type inspect zbf_INSIDE-OUTSIDE
class type inspect TELNET
inspect
 class type inspect _HTTP
  inspect
 service-policy http DPI_HTTP
class type inspect other_Traffic
inspect TIMEOUT
!
!Definir os acessos apartir do OUTSIDE
zone-pair security INSIDE-OUTSIDE source INSIDE destination OUTSIDE

class-map type inspect match-all ICMP
match protocol icmp

policy-map type inspect zbf_OUTSIDE-INSIDE
class type inspect ICMP
inspect

zone-pair security OUTSIDE-INSIDE source OUTSIDE destination INSIDE
 service-policy type inspect zbf_OUTSIDE-INSIDE

R2#sh zone security
zone self
Description: System defined zone

zone INSIDE
Member Interfaces:
FastEthernet0/1

zone OUTSIDE
Member Interfaces:
Multilink1

R2#sh parameter-map type inspect

parameter-map type inspect TIMEOUT
audit-trail off
alert on
max-incomplete low  unlimited
max-incomplete high unlimited
one-minute low  unlimited
one-minute high unlimited
udp idle-time 100
icmp idle-time 10
dns-timeout 5
tcp idle-time 100
tcp finwait-time 5
tcp synwait-time 30
tcp max-incomplete host unlimited block-time 0
sessions maximum 2147483647

R2#sh policy-map type inspect zone-pair
Zone-pair: INSIDE-OUTSIDE

Service-policy inspect : zbf_INSIDE-OUTSIDE

Class-map: TELNET (match-all)
Match: access-group name INSIDE-OUTSIDE
Match: protocol telnet
Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [0:43]

Session creations since subsystem startup or last reset 2
Current session counts (estab/half-open/terminating) [1:0:0]
Maxever session counts (estab/half-open/terminating) [1:1:1]
Last session created 00:00:02
Last statistic reset never
Last session creation rate 1
Maxever session creation rate 1
Last half-open session total 0

Class-map: _HTTP (match-all)
Match: protocol http
Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [1:32]
http packets: [0:6]

Session creations since subsystem startup or last reset 2
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [1:1:1]
Last session created 00:41:05
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 1
Last half-open session total 0
Deep packet inspection
        Policy: http DPI_HTTP
        3 packets, 72 bytes

Class-map: other_Traffic (match-all)
Match: access-group name other_Traffic
Inspect
Session creations since subsystem startup or last reset 0
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [0:0:0]
Last session created never
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 0
Last half-open session total 0

Class-map: class-default (match-any)
Match: any
Drop (default action)
30 packets, 2400 bytes
Zone-pair: OUTSIDE-INSIDE

Service-policy inspect : zbf_OUTSIDE-INSIDE

Class-map: ICMP (match-all)
Match: protocol icmp
Inspect
Packet inspection statistics [process switch:fast switch]
icmp packets: [0:1054]

Session creations since subsystem startup or last reset 2
Current session counts (estab/half-open/terminating) [1:0:0]
Maxever session counts (estab/half-open/terminating) [1:1:0]
Last session created 00:00:23
Last statistic reset never
Last session creation rate 1
Maxever session creation rate 1
Last half-open session total 0

Class-map: class-default (match-any)
Match: any
Drop (default action)
0 packets, 0 bytes

!Ping R3
R1#ping 192.168.20.1 re 2
Success rate is 100 percent (2/2), round-trip min/avg/max = 44/52/60 ms

!!Telnet R1

R3#telnet 192.168.10.1
Trying 192.168.10.1 … Open

User Access Verification

Password:
R2#sh policy-map type inspect zone-pair sessions
Zone-pair: INSIDE-OUTSIDE

Service-policy inspect : zbf_INSIDE-OUTSIDE

Class-map: TELNET (match-all)
Match: access-group name INSIDE-OUTSIDE
Match: protocol telnet
Inspect
   Established Sessions
         Session 670375D0 (192.168.20.1:21612)=>(192.168.10.1:23) telnet SIS_OPEN
Created 00:00:08, Last heard 00:00:07
Bytes sent (initiator:responder) [24:113]

Class-map: _HTTP (match-all)
Match: protocol http
Inspect
Deep packet inspection
Policy: http DPI_HTTP
3 packets, 72 bytes

Class-map: other_Traffic (match-all)
Match: access-group name other_Traffic
Inspect

Class-map: class-default (match-any)
Match: any
Drop (default action)
30 packets, 2400 bytes
Zone-pair: OUTSIDE-INSIDE

Service-policy inspect : zbf_OUTSIDE-INSIDE

Class-map: ICMP (match-all)
Match: protocol icmp
Inspect
Established Sessions
         Session 67037898 (192.168.2.1:8)=>(192.168.20.1:0) icmp SIS_OPEN
Created 00:00:26, Last heard 00:00:00
ECHO request
Bytes sent (initiator:responder) [36360:36288]

Class-map: class-default (match-any)
Match: any
Drop (default action)
0 packets, 0 bytes

Notas Network Time Protocol (NTP)

O sistema inicia o relógio no momento em que este também inicia e mantém o registo da data/hora.

O relógio do sistema pode ser atualizado das seguintes formas:

  • NTP
  • Simple Network Time Protocol (SNTP)
  • Virtual Integrated Network Service (VINES) Time Service
  • Manual configuration

O NTP permitem garantir a sincronização da data/hora entre os vários elementos, este pode ser configurado nos seguintes modos:

  •    Client/Server
  •     Symmetric Active/Passive – Grupo de peers low stratum operam como backups uns dos outros. Cada peer usa as suas referencias primarias e em caso de falha usa os peers, esta operação e descrita como push-pull. Um peer é configurado em modo  Symmetric Active usando o comando peer. O outro peer também deve ser configurado da mesma forma.
    Nota: Se o outro peer não for configurado com o comando peer, a associacao e feita em Symmetric Passive quando é recebida uma mensagem Symmetric Active.
  •     Broadcast

Exemplo:

Ligações:

R1——-s2/1-R2-f0/1———-f0/0-R3

Autenticar o NTP entre o R1/R3
O R1 deve estar em Symmetric Active mode
O R3 recebe o NTP via broadcast

R1(config)#
ntp authentication-key 1 md5 CCIE
ntp authenticate
ntp trusted-key 1
ntp server 192.168.2.2
ntp peer 192.168.2.2

R2(config)#
ntp authentication-key 1 md5 CCIE
ntp authenticate
ntp trusted-key 1
ntp master 2

R3(config)#
int f0/1
ntp broadcast client

R2#sh ntp associations

address         ref clock     st  when  poll reach  delay  offset    disp
*~127.127.7.1      .LOCL.            1     5    64  377     0.0    0.00     0.0
* master (synced), # master (unsynced), + selected, – candidate, ~ configured

R2#sh ntp status
Clock is synchronized, stratum 2, reference is 127.127.7.1
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24
reference time is D62E1DCD.301D493F (15:48:29.187 UTC Wed Nov 13 2013)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.02 msec, peer dispersion is 0.02 msec

R1#sh ntp associations de
192.168.2.2 configured, our_master, sane, valid, stratum 2
ref ID 127.127.7.1, time D62E1E4D.301CB65E (15:50:37.187 UTC Wed Nov 13 2013)
our mode active, peer mode passive, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.03, reach 377, sync dist 25.284
delay 12.12 msec, offset 6.2250 msec, dispersion 19.20
precision 2**24, version 3
org time D62E1E63.80060ECC (15:50:59.500 UTC Wed Nov 13 2013)
rcv time D62E1E63.7FCF0483 (15:50:59.499 UTC Wed Nov 13 2013)
xmt time D62E1E63.747ED2BE (15:50:59.455 UTC Wed Nov 13 2013)
filtdelay =    44.14   19.94   47.94   12.12   39.92   40.07   27.91   36.16
filtoffset =   22.92  -16.03    3.07    6.23   11.91   -4.44   -2.76    0.59
filterror =     0.02    0.99    1.97    2.94    3.92    4.90    5.87    6.85

R3#sh ntp associations

address         ref clock     st  when  poll reach  delay  offset    disp
* 192.168.20.2     127.127.7.1       2    18    64  376    16.1   13.55    15.9
* master (synced), # master (unsynced), + selected, – candidate, ~ configured

R3#sh ntp ass detail
192.168.20.2 dynamic, our_master, sane, valid, stratum 2
ref ID 127.127.7.1, time D62E1E8D.301D95DD (15:51:41.187 UTC Wed Nov 13 2013)
our mode bdcast client, peer mode bdcast, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 0.03, reach 376, sync dist 24.002
delay 16.07 msec, offset 13.5468 msec, dispersion 15.95
precision 2**24, version 3
org time D62E1E9C.301B1A0A (15:51:56.187 UTC Wed Nov 13 2013)
rcv time D62E1E9C.2CA64C21 (15:51:56.174 UTC Wed Nov 13 2013)
xmt time 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
filtdelay =    16.07   16.07   16.07   16.07   16.07   16.07   16.07   16.07
filtoffset =   13.55    1.73   25.91  -16.53   -5.48   -6.40    1.73  -12.14
filterror =     0.99    1.97    2.94    3.92    4.90    5.87    6.85    7.83