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

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.

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

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]

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:

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)

Security - Parte II (Layer 2)

Antes de mais nada, existe um link da cisco com muitas informaçòes sobre segurança no caso de duvidas. aqui ( http://www.cisco.com/en/US/netsol/ns954/index.html )

Principais recomendações
1 - Desabilitar CDP e DTP sempre que possivel.
2 - Deixar as portas sempre como access ports.
3 - Ativar BPDU Guard e Root Guard (spanning-tree { guard root | bpduguard ena }) em access ports
4 - Ativar o port security:

O port security não encaminha frames quando o numero de endereços MAC é excedido ou ele não está autorizado.
A limitação dos endereços pode ser:
-Estática
-Dinamica (Até o limite configurado) mas ele não salva os endereços no caso de um reload.
-Dinamica e o sw salva os endereços na running-config (Chamado de stick learning)

switchport port-secutity mac-address xxxx.xxxx.xxxx
switchport port-secutity maximum valor
switchport port-secutity mac-address sticky
switchport port-secutity [aging] [violation {protect | restrict | shutdown}]
*protect: faz o PS, restrict: faz o PS, log e envia traps snmp, shutdown poe a porta em err-disable

5 - Habilitar o dhcp snooping e o ip verify source
6 - Utilizar a autenticação 802.1X

Existem outras recomendações na documentação do SAFE.

Security - Parte I (Local)

A primeira parte de segurança deve ser ao acesso aos equipamentos (Telnet, console e AUX)
Pra relembrar, voltemos ao CCNA
Ex:
line con 0 // line vty 0 15
login #habilita o login :)
username USUARIO password MINHASENHA

existe o service password-encryption que codifica a senha que está armazenada em clear text para algo codificado, lembrando que se retirarmos esse comando a senha continua criptografada até ser salva uma senha por cima. Porem essa codificação é fraca e qualquer pessoa pode fazer ou achar um prograa para descodificar, serve apenas para evitar curiosos de ver as senhas por eventualizade.

Para o acesso enable (Modo privilegiado) podemos setar uma segurança melhor ao invez de codificar podemos fazer um hash MD5 que não é tão simples de quebrar (Por ser um Hash).

enable password SENHA
enable secret SENHASECRETA

Lembrando que o enable secret tem prioridade a senha de enable comum.

AAA (Authentication, authorization and accounting)

Além de localmente a autenticação pode ser feita utilizando um servidor RADIUS ou TACACS+ :









1 - Habilite o AAA com aaa new-model

2- Informe o endereço dos servidores (radius ou tacacs):
tacacs-server host x.x.x.x
tacacs-server key SENHA
radius-server host x.x.x.x
radius-server key SENHA

3- Defina o método de authenticação default ou por acesso (console,vty ou aux) para o login:
aaa authentication login {default | for-console | for-vty | for-aux} method

4- Defina o método de authenticação default ou por acesso (console,vty ou aux) para enable:
aaa authentication enable {default | for-console | for-vty | for-aux} method

BGP - Tabela de Roteamento IP

Rotas eBGP

As rotas que saem da BGP table e vão para IP routing table, devem ser:
- Se eBGP, a rota tem que ser considerada "best"
-Se o mesmo prefixo foi aprendido por outro IGP a AD do BGP tem que ser menor.

Para alterar a AD do BGP podemos usar:
- O comando "distance bgp external internal local"
- distance ipadd mask [ip-list]

Backdoor Routes

Caso você aprenda uma rota via IGP e por eBGP e queira usar o IGP, é possivel configurar essa rede como backdoor, com o comado network x.x.x.x backdoor. Fazendo isso o BGP:

-Seta o AD dessa rota para 200
-Não propaga essa rota.

Rotas iBGP

As rotas que saem da BGP table e vão para IP routing table, devem ser:
- A rota tem que ser considerada "best"
-Se o mesmo prefixo foi aprendido por outro IGP a AD do BGP tem que ser menor.

Ao adicionar rotas iBGP na routing table devemos lembrar do conceito do BGP synchronization, para evitar problemas com o IGP.

Porém ao se trabalhar com iBGP você precisa ter uma rede full mesh, porque um peer iBGP não propaga rotas aprendidas por iBGP a outro peer iBGP, então é necessário um grande número de conexoes entre peers. Para reduzir esse número de peers podemos usar duas ferramentas BGP: Confederations e Route reflector.

Confederations

Definida pela RFC 3065 ele utiliza os parametros CONFED_SEQ e CONFED_SET (como no aggregate-address), quebrando um AS em sub-AS, onde os roteadores dentro de um sub-AS funcionam normalmente como iBGP (tendo de ser full mesh e não divulgando iBGP a outros peers iBGP) e as conexões entre sub-AS como eBGP.
Como demonstra o exemplo do livro.

Para configurar:
router bgp sub-AS
bgp confederation identifier AS
bgp confederation peers sub-AS














Route Reflectors

O router reflector concentra as informações em um unico router que age coo eBGP para os clients e iBGP para os non-clients, então se um non-cliente enviar um prefixo a um RR server ele encaminhará para os clients (eBGP) porém não encaminhará a outros non-clients (iBGP).

A configuração é tranquila, no cliente é configurado como um iBGP normal.
no RR bata adiciona:

bgp cluster-id numero
neighbor x.x.x.x route-reflector-client

BGP - Tabela BGP

A tabela da topologia BGP é chamada de RIB (Routing information Base), aonde é adicionado o NLRI (Network reachability information) e seus respectivos PAs. O NLRI é o prefixo IP e seu tamanho. (ex: 10.0.0.0/8)

Como nos IGPs. para inserir uma rede em sua RIB, basta apenas indicar com o comando network dentro do processo BGP, além do comando network, podemos redistribuir as rotas de redes diretamente conectadas, configuradas estaticamente ou vindas de outros protocolos, alémd e aplicar route maps na hora de redistribuir essas rotas, tudo isso com o comando redistribute.

Observe que o comando auto-summary funciona diferente para o comando redistribute e network.
Para o redistribute, ele irá anunciar a rede como classfull ao primeiro match de qualquer subnetwork.
Já para o comando network com o "no auto-summary", você precisa indicar a rede exata para o BGP poder divulgar, com o comando "auto-summary" ele divulga todas as subnetworks em formato classless que façam match com a rede divulgada pelo comando network.

Você também pode controlar as rotas sumarizadas utilizando o aggregate-address, para maiores informações aqui ( http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml#cidragg )
*Prestando atenção na diferença do AS_SEQ e AS_SET

O Atributo ORIGIN PATH

Nota: Quando o aggregate-address é usado o Origin pode variar:
-Se o as-set não for usado: i
-Se usado e todas as subnets estiverem presentes e forem i: i
-Se usado e alguma subnet for ? : ?



O anúncio de Rotas pelo BGP

O anúncio de rotas é feito pelo BGP Update message.
Quando um NLRI tem o mesmo PA ele é anunciado em um mesmo Update message, isso economiza banda e CPU. Se o NLRI tiver PA diferente ele é anunciado em uma outra Update message.

Existem algumas regras de quais rotas serão incluidas no BGP Update message.

BGP

O BGP efetua troca de informações sobre a topologia para encontrar o melhor caminho para um prefixo de IP a decisão do melhor caminho é feita utilizando atributos (BGP path attributes ou PAs).



Antes de efetuar qualquer troca de informação o BGP utiliza a famosa maquina de estado para estabelecer uma conexão TCP na porta 179 e fechar um relacionamento com um neighbor.
















No entando alguns requerimentos são necessário para se fechar um peering BGP


1- O roteador necessita receber uma solicitação TCP de uma origem que seja seu neighbor, caso contrário a conexão é recusada, por exemplo, se você usa uma loopback como neighbor o endereço de origem será a interface diretamente conectada e o roteador não reconhecera esse endereço, pois espera receber como origem o endereço de loopback do router remoto, então você configura o BGP do router remoto para enviar como endereço de origem o endereço da loopback.
2- O endereço de AS tem que ser igual com o configurado, senão eles não se tornarão neighbors.
3-O BGP RID tem que ser diferentes.
4-Se a autenticação MD5 estiver configurada ela precisa acontecer.

Comandos BGP

router bgp 123
##Os 3 proximos comandos são defaults em IOS > =12.3##
no synchronization
bgp log neighbor-changes
no auto-summary ## O comando no synchronization divulga rotas a um outro AS mesmo que o IGP não tenha as mesmas rotas que o BGP, caso contrário ele aguarda a sincronização, Maiores detalhes aqui ( http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml#synch )

bgp router-id 10.10.10.10 #Configura o RID ou o maior endereço UP/UP de loopback, depois maior endereço de interface UP/UP (No momento do estabelecimento do processo).

neighbor 2.2.2.2 remote-as 123 #Configura um iBGP devido ao mesmo AS
* neighbor 2.2.2.2 update-source Loopback1 #Indica que o end de origem deve ser da Loopback1
* neighbor 2.2.2.2 password Minhasenha #Habilita a autenticaçào entre neighbors (MD5)
neighbor 3.3.3.3 remote-as 456 #Configura o eBGP devido ao AS diferente
* neighbor 3.3.3.3 password Minhasenha
* neighbor 3.3.3.3 update-source Loopback1

Percerbam que os comandos marcados com * são os mesmos depois do endereço do neighbor, se tiver que configurar diversos neighbors com os mesmo parametros basta criar um peer-group com as configurações que são iguais e aplicar no neighbor, as configurações diferentes podem ser adicionadas normalmente. Ex:

neighbor MEUGRUPO peer-group
neighbor MEUGRUPO update-source Loopback1
neighbor MEUGRUPO password Minhasenha

neighbor 2.2.2.2 peer-group MEUGRUPO
neighbor 2.2.2.2 remote-as 123

neighbor 3.3.3.3 peer-group MEUGRUPO
neighbor 3.3.3.3 remote-as 456


E pra relembrar, a maquina de estados do BGP: