segunda-feira, 29 de março de 2010

Existem dois tipos de roteamento multicast:

Dense-Mode
Sparse-Mode

Multicast Forwarding Using Dense Mode


Dense-mode routers não recebem pacotes de um grupo multicast especifico se ambas as condições forem verdadeiras:
■ O roteador não tem nenhum router downstream que precisa receber pacotes do grupo.
■ O Roteador não tem nenhuma subnet conectada que ingressou naquele grupo.

DVMRP, PIM-DM, e o MOSPF são os protocolos dense-mode.



Multicast Forwarding Using Sparse Mode


A diferença fundamental entre dense-mode e sparse-mode é seu comportamento padrão.
Por default os protocolos dense-mode sempre encaminham tráfego a não ser que o downstream router envie uma menssagem informando que não deseja receber aquele tráfego. Os Protocolos Sparse-mode
não encaminha tráfego do grupo a não ser que ele receba uma menssagem solicitando tráfego de determinado grupo multicast.





TTL Scoping

Quando um pacote chega no roteador e tem que ser encaminhado a outras interfaces o roteador compara o se o TTL do pacote é maior ou igual ao TTL da interface, se sim ele o encaminha.
Por default o TTL na cisco é Zero.









Protocolos Dense-mode

PIM-DM - Protocol Independent Multicast Dense Mode

Diferente do DVMRP e do MOSPF ele utiliza a tabela de roteamento para realizar o RPF check.
O PIM estabelece relacionamento com seus vizinhos utilizando mensagens Hello que são enviadas a cada 30 segundos utilizando o protocolo IP 103 e o endereço 224.0.0.13 (All-PIM-Routers), oHoldtimer geralmente é três vezes o tempo do Hello.
O PIM utiliza uma arvore STP para cada grupo multicast com base na origem e nos hosts que recebem o tráfego multicast.
Para habilitar o PIM bastam 2 comandos:
Global - ip multicast-routing
Em cada interface - ip pim dense-mode










Para verificar a routing table multicast: show ip mroute

Onde ele mostra o ip de origem 10.1.1.10 (S) e o grupo multicast de destino 226.1.1.1 (G) no formato da entrada (S,G).
R3#show ip mroute
Mostra que a entrada está ativa fazem 12 segundos e que se R3 não encaminhar nenhum pacote dentro de 2:48 a entradá irá expirar.
O Flag C indica que existe um host interessado no tráfego 226.1.1.1 diretamente conectado. A Flag T indica que o tráfego é encaminhado pelo STP.

Prune Message
Quando R3 recebe mensagens dessa entrada do R2, ele realiza o RPF check e envia ao R2 uma Prune Message, então R2 aguarda 30 segundos e não encaminha mais tráfego dessa entrada ao R3.

Prune override
Caso exista algum router R4 no mesmo seguimento que deve receber o tráfego, esse router R4 ao receber tambem o Prune message (por que esta no mesmo seguimento) envia uma mensagem chamada Prune override informando que apesar do R3 não querer tráfego, tem alguem ali naquele seguimento que quer.

*Quando RPF nbr é 0.0.0.0 significa que o router está diretamente conectado a origem (10.1.1.10)

R2#show ip mroute
Como ele está trabalhando com o DM se o Prune timer (2:52) chegar a zero a interface vai para Forward novamente, a não ser que R3 envie uma state refresh message ao R2 de tempos em tempos antes do Prune Timer expirar em R2.

Graft message

Caso o router receba um IGMP Join nesse meio tempo ele envia uma Graft message solicitando o unpruning da porta, fazendo com que ele comece a receber o tráfego imediatamente sem ter que esperar os 3 minutos.

2 routers conectados diretamente num mesmo seguimento


















Assert Messages

Caso existam 2 routers conectados diretamente num mesmo seguimento onde existe um router interessado, é efetuado um critério de desempate para apenas um enviar o trafégo multicast, evitando assim desperdicio de banda, através de Assert Messages, os critérios são:
1- Quem usa o protocolo com a menor distância administrativa.
2- No empate, a menor métrica.
3- No empate, o router com o maior IP na LAN.

Designated Router
Caso existam 2 routers conectados diretamente num mesmo seguimento é eleito um router para gerenciar as menssagens IGMP. o IGMPv2 elege o router com o menor IP da LAN.
*Por causa disso geralmente o designated Router não é o mesmo rotuer que envia o tráfego multicast.

RESUMO DAS MENSAGENS PIM-DM

quarta-feira, 10 de março de 2010

Otimizando o uso Multicast na LAN


Como IGMP trabalha na camada 3, para evitar o uso de recursos desnecessários na LAN é possivel usar:
IGMP Snooping
Cisco Group Management Protocol (CGMP).










CGMP - Cisco Group Management Protocol

Protocolo proprietário da Cisco.
Apenas o Router gera mensagens e o Switch apenas as escuta
As mensagens CGMP são enviadas ao endereço de multicast 0100.0cdd.dddd contendo os seguintes campos:
GDA - Group Destination Adress
USA - Unicast Source Adress

O router envia a Router Join Message (GTA = 0, USA= Próprio MAC), para informar ao Switch que aquela porta está conectada a um router multicast e são renovadas a cada 60 segundos.
Igualmente ele pode enviar uma mensagem tipo Leave, tambem no mesmo formato (GTA = 0, USA= Próprio MAC). para liberar a porta Router CGMP.

Quando um host ingressa a um grupo multicast o roteador envia uma mensagem CGMP(GTA = End Multicast, USA= MAC do Host) ao Switch informando que o mac address do host irá receber mensagens de determinado grupo multicast, então o Switch relaciona a porta do Host com o Grupo Multcast em uma tabela.
Do mesmo modo é possível informar ao SW que o host não recebe mais tráfego multicast.

Também é possivel limpar as entradas CGMP com o comando clear ip cgmp.



Segue uma tabela com o resumo das mensagens:










IGMP Snooping

Parecido com o CGMP, só que faz com que o SWITCH escute as mensagens IGMP e monte a tabela ao invés de aguardar mensagens CGMP do roteador. O Leave Group message só é encaminhada ao roteador quando não existir nenhuma outra porta associada ao endereço de multicast na tabela do Switch.

terça-feira, 23 de fevereiro de 2010

Multicast II - IGMP

IGMP Internet Group Management Protocol

Para maiores detalhes consulte as RFCs:
IGMPv1 - http://www.ietf.org/rfc/rfc1112.txt
IGMPv2 - http://www.ietf.org/rfc/rfc2236.txt
IGMPv3 - http://www.ietf.org/rfc/rfc3376.txt

O CCIE foca no IGMPv2, então é onde vou concentrar esforços.

O maior objetivo do IGMP é informar o roteador multicast local que um host:
-Deseja receber o tréfeco multicast ingressando em um grupo.
-Deseja deixar o grupo multicast.

Como o IGMP tem um significado local (Host - Router), ele não é propagado a outro roteador, logo seu TTL é setado como 1.

Para multicast L2 é usado outros protocolos (IGMP Snooping, CGMP e RGMP

Existem 4 tipos de menssagens:
-Membership Query (0x11) - O Router Multicast envia essa mensagem depois de receber um "Leave Group" para verificar se existe mais algum Host no segmento, que ainda deseja receber tráfego Multicast.
- V1 MS Report (0x12) - Para compatibilidade com o IGMPv1
- V2 MS Report (0x16) - Informa ao Router Multicast que o host deseja receber tráfego, seja em resposta a MS Query ou enviado sem esperar a MS Query.
- Leave Group (0x17) - Informa ao Router Multicast que o host não deseja mais receber tráfego.

O processo é bem simples.
Aplicação configura o host a ingresar em um grupo multicast, calcula o endereço de MAC de multicast e o host passa a "escutar" o tráfego camada 2 para esse MAC multicast e seu MAC (BIA)
Ou eles enviam um MS Report direto ou aguardam para enviar em resposta ao MS Query.
Quando recebem um MS Query eles enviam o MS Report no tempo aleatório entre 0.1 e MRT (Maximum response time) se um host receber o MS report de outro router ele suprime o envio de seu MS report para evitar envios de MS report desnecessários, uma vez que o router apenas envia ou não tráfego para um determinado segmento.
Quando o host sai do grupo multicast e envia o Leave Group o router multicast envia uma mensagem MS query no segmento para verificar se existe algum host que ainda deseja receber tráfego dai voltamos ao processo de resposta do MS Query.
Se nenhum host responder dentro do MRT o host repete o processo o numero de vezes definido no "Last Member Query Count" Então o tempo que o router demora para parar de enviar tráfego multicast depois de receber o MS Leave do ultimo host é o MRT x LMQC.

Fácil :)

*Afim de evitar ataques de DoS o IGMPv3 utiliza um recurso chamado SSM (Source-Specifc Multicast.
















Comparação entre as versões IGMP.

Multicast


Quando falamos em Multicast estamos falando em exibir um fluxo de dado a muitos destinos otimizando os recursos da rede, não criando um fluxo unicast para cada destino, mas sim um fluxo unico que diferente do broadcast é enviado somente a segmentos interessados da rede.

A IANA definiu que o grupo Multicast deve usar a classe D de endereços IP (224.0.0.0 - 239.255.255.255).

Dentro da classe D a IANA definiu 4 ranges:

1 - quando o 3 octeto é 0 não deve ser roteado, quando 1 sim (Ex: Auto-RP)
2 - Usa o protocolo SSM
3- Usado para transformar o numero do AS em end Multicast (Ex AS 5663 em binario (00010110 00011111) Separando em 2 octetos e transformando em decimal temos respectivamente 22 e 31, então o endereço de multicast ficaria (233.22.31.0)
4- Endereços para serem usados dentro do AS. Como os endereços privados 192.168.0.0/16 por ex.

Resumindo:

















Os endereços Multicast geram um endereço MAC, segundo os 5 passos do processo a seguir, o administrador apenas deve ter cuidado ao usar um endereço Multicast para não gerar o mesmo numero MAC para aplicações distintas.

















No proximo post vou falar sobre os protocolos que administram os grupos Multicast. IGMP, CGMP e RGMP

sábado, 23 de janeiro de 2010

MPLS

O protocolo MPLS encaminha os pacotes baseados em Labels ao invez de usar a tabela de roteamento. Ele trabalha junto com o CEF, o CEF coleta informações da RIB (Routing information Base) e cria uma tabela chamada FIB (Forward IB) então o MPLS com base na FIB cria uma base chamada LFIB (Label FIB) com base nessa tabela o MPLS efetua o processo de Push and Pop dos labels no MPLS header (4 Bytes).

LDP (Label Distribution Protocol)

Para o controle das Labels é utilizado o LDP, toda vez que o roteador aprende uma nova rede e faz a busca na RIB e cria a LFIB ele informa aos roteadores adjacentes qual label ele irá usar para aquela rota e assim sucessivamente:
















































MPLS TTL propagation


Quando efetuamos um tracert o MPLS usa o campo TTL do header MPLS para fazer esse controle.
Do mesmo modo podemos desabilitar o decremento do TTL de pacotes vindos do CPE (Forwarded) de modo que o cliente veja toda a rede MPLS apenas como um salto. Ou desabilitar o TTL de pacotes originados de um PE (local) escondendo o endereço dos roteadores da nuvem (Não recomendado para troubleshoting), com o comando no mpls ip ttl-propagation [local|forwarded]

sexta-feira, 22 de janeiro de 2010

Frame Relay


Antes das VPNs e MPLS havia o Frame Relay. Ele utiliza conexões virtuais (VC) para estabelecer uma rede dentro de uma nuvem atravéz de DLCI (Data link connection identifiers) que são cabeçalhos, geralmente de 10 bits.
Dentro da interface frame relay é trocado mensagens atravez de LMI (Link management Interface) que troca informações sobre o status do VC e informações sobre o DLCI geralmente a cada 10 segundos e a cada 6 mensagens ele troca uma full status message que contem informações mais detalhadas sobre o VC. Para desabilitar o LMI basta desativar o Keepalive da interface frame relay.







Configuração:

quarta-feira, 20 de janeiro de 2010

Security - Parte III (Layer 3)

Recomendações:
1 - Considerar o uso de SSH ao Telnet comum
2 - Habilitar segurança de SNMP (v3)
3 - Desabilita serviços desnecessários
4 - Habilitar syslog
5 - Habilitar autenticação dos IGP

Smurf attacks, Directed Broadcasts e RPF (Reverse Path Forwarding) check




Por default(IOS > 12.0) as interfaces usam o no ip direct-broadcast para prevenir esse tipo de ataque.











Além disso o RPF pode ser usado nas interfaces com o comando
ip verify unicast source reachable-via
{rx|any} [allow-default] [allow-self-ping]
rx - strict, verifica se a rota para a rede de origem aponta pra interface de onde o pacote veio.
any - Loose, verifica se existe qualquer rota para a rede.
allow-default - considera inclui a rota default
allow-self-ping - verifica se o host está acesivel por ping (não recomendado)

O livro fala muito de access-lists (Li por cima e acabei pulando essa parte)

Além disso ele recomenda a leitura sobre :
CBAC: Context-Based Access Control aqui ( http://www.cisco.com/en/US/docs/ios/12_0/security/configuration/guide/sccbac.html )

DMVPN: Dunamic Multipont VPN aqui ( http://www.cisco.com/en/US/products/ps6658/index.html )

Agora praticamente falta:
WAN (Frame-Relay), MPLS, IPV6 e Multicast.
Vamos ver se faço um por dia (quinta, sexta, sabado e domingo)