EIGRP: Balanceamento de carga por métrica desigual

 

unequal cost load balancing

Loop de encaminhamento em R3 devolve o pacote a R1, porque o custo do link R3-R1 é menor que o cuso R3-R2.

 

Observe a figura acima: Suponha que R1 pretenda enviar pacotes para R2. Ele o poderá fazer pela rota de menor custo directamente por R1->R2. Poderá faze-lo também por R3, R1->R3->R2. Acontece que de R3->R2 o custo é de 100. E de R3->R1, o custo é de 20. Logo o pacote a caminho de R2 por R3, será devolvido a R1 que encaminhará novamente a R2 provavelmente por R3 . A esse acontecimento chamamos Routing Loop, ou laços de encaminhamento.

unequal cost load balancing 02
Observe a figura acima. Os custos para a chegada dos pacotes de E para A, pelas 03 rotas são os seguintes:

E->B->A=30
E->C->A=20
E->D->A=45

A rota com menor custo, conhecida como Feasible Distance (FD) é igual a 20 (E->C + C->A = 10+10 = 20). Se essa rota falha por qualquer motivo, uma rota alternativa, chamada de Feasible Sucessor Route, FS, é activada, e essa rota é E->B->A = 30, porque o custo anunciado pelo encaminhador B para alcançar A, ou seja a Reported Distance, RD = 10, é menor que a FD=20.

Redes sérias precisam necessariamente de ter algum bom esquema de balanceamento de carga. As vantagens são inúmeras. Por exemplo é sempre bom enviar pacotes por mais do que um caminho, desse modo pode-se diminuir a sobrecarga nos enlaces (desculpe mas não encontrei um termo mais PT-pt para link, diferente de ‘ligação’) de dados.

Outra vantagem é a rápida convergência em caso de quebra ou falha de um dos enlaces de dados. Nao é necessário esperar pelo processo de convergência, que pode ser moroso porque ja existe uma ou mais rotas alternativas na tabela de roteamento.

Configura-se o balanceamento de carga de rotas com desiguais métricas (deve ser assim que se pronuncia Unequal Metric Route Load Sharing) recorrendo ao comando Variance que multiplica o seu argumento que varia de 1 a 128 pelo valor da rota FD. Todas as rotas com custo menor a FD serão consideradas como rotas sucessoras FS.

Por exemplo. Configure-se uma variância de 02. O novo valor da métrica será FD = (10+10)*2 = 40. FS = (10*2) = 20 < FD.
Na linha de comando teríamos:

>router eigrp 33
>variance 2

O encaminhador irá adicionar todas rotas menores ou iguais a 40, valor de FD. E->D->A não é adicionado porque a RD de D = 25*2 = 50 > FD.

Anúncios

Abrangência IP e a sumarização de rotas

Existem motivos muito fortes pelos quais voce necessita sumarizar ou agregar rotas. Um factor é que o processo de encaminhamento, introduz uma grande sobrecarga no sistema. Tendo o encaminhador que calcular mais rotas, maior é a sobrecarga. Outro motivo para sumarizar rotas é que ela acelera o processo de convergência em protocolos IGP (Interior Gateway Protocol) como o protocolo EIGRP. Observe a figura abaixo:

Stuck in active

Se o encaminhador 1 perde uma rota ele envia uma mensagem de solicitação e aguarda por uma mensagem de resposta. Quanto maior o numero de encaminhadores a frente de 1, menor é a probabilidade dele receber uma mensagem de resposta em menor tempo e dessa forma convergir rapidamente. Ja ensinamos num artigo anterior como sumarizar rotas. O problema que se coloca aqui é quando estamos em presença de redes algo descontínuas. O gerente do projecto entrega a voce 4 (quatro) rotas e solicita a sua sumarização. Como proceder? O exemplo abaixo dá uma dica sobre o assunto:

An engineer plans to configure summary routes with the ip summary-address
eigrp asn prefix maskcommand. Which of the following, when added to such a
command, would create a summary that includes all four of the following subnets:
10.1.100.0/25, 10.1.101.96/27, 10.1.101.224/28, and 10.1.100.128 /25?
a.  10.1.0.0  255.255.192.0
b. 10.1.64.0  255.255.192.0
c.  10.1.100.0  255.255.255.0
d. 10.1.98.0  255.255.252.0

Como se observa, estamos perante 4 redes algo descontínuas. Qual das seguintes alíneas corresponde a uma rede que satisfaça a sumarização delas?

Uma forma fácil de verificar isso é por fazer uma analise de abrangência. Para isso voce deve lembrar para que serve uma mascara de sub-rede. Ela não apenas serve para indicar o endereço de rede fazendo a operação matemática de AND com um determinado e válido endereço IP, mas também para determinar os limites ou a abrangência da sub-rede.

Repare: Se voce tem uma rede com o endereço 10.0.0.0/8 qual é a sua abrangência? Eu que sou experiente neste calculo digo que é de 10.0.0.0/8 a 10.255.255.255. Como provar? Simples: subtraia a mascara de sub-rede pela mascara todos 1 (255.255.255.255). Fica assim:

255.255.255.255
– 255.  0  .   0. 0
________________
0    . 255 . 255 . 255

Somar (OR) o endereço IP (10.0.0.0) ao resultado da subtração do todos 1 com a mascara de sub-rede:

  10 . 0  . 0   . 0
+ 0 .255.255.255
________________
10 . 255.255.255

Ou seja a rede vai de 10.0.0.0/255.0.0.0 a 10.255.255.255/255.0.0.0.

Respondendo a pergunta destacada anteriormente, voce pode repetir os passos que fizemos agora nas quatro alíneas para obter a resposta. Observe as redes em análise:

10.1.100.0/25, 10.1.101.96/27, 10.1.101.224/28, and 10.1.100.128 /25

Nota-se que a rede mais a direita ou seja com o endereço IP maior é 10.1.101.224/28, logo temos de encontrar uma sub-rede que abranja este endereço. Analisando a alínea d) temos: 10.1.98.0  255.255.252.0. Qual é a sua abrangência?

255.255.255.255 – 255.255.252.0 = 0.0.3.255

Somando: 10.1.98.0 + 0.0.3.255 = 10.1.101.255

Ou seja a sua abrangência vai de 10.1.98.0 a 10.1.101.255.

O endereço 10.1.101.224 está dentro desse intervalo, logo a alínea d) está correcta.

 

 

 

 

 

 

 

 

Configurando serviço DHCPv6 Stateless

Similar ao protocolo DHCP, o protocolo DHCPv6 também faz uso do protocolo Internet Control Message Protocol, mas na sua versão 6, o ICMPv6, que por seu lado recorre a outro protocolo, o Neighbor Discovery (ND), que vem assim substituir o protocolo de descoberta e resolução ARP pertencente ao protocolo IP.

Ao contrario do serviço DHCPv6 Stateful, o serviço DHCPv6 Stateless não conserva o estado dos dispositivos a que ele atribui endereços. Geralmente o esquema é composto pela atribuição simples ao cliente do endereço DNSv6 e do Domain Name (DN) e do prefixo bem como seu tamanho.

O endereço IPv6 é obtido pela combinação do prefixo (64 bits) e do endereço MAC do dispositivo que sao 48 bits. Como o endereço IPv6 é composto por 128 bits isso significa que ainda restam (64-48)bits = 16 bits. Esses bits sao completados com a inserção da assinatura FFFE (onde o bit 70 é complementado) na metade dos 48 bits ou seja depois do bit 24 do MAC Address. A este tipo de técnica, denomina-se StateLess Address AutoConfiguration (SLAAC) e o formato do de endereço denomina-se EUI-64.

Os comandos ipv6 address autoconfig e ipv6 nd other-config-flag em modo de interface, habilitam a configuração automática do endereço IPv6 e a obtenção do outras configurações enviadas pelas mensagens RA (já falaremos disto parágrafo abaixo) dos servidores-encaminhadores (DHCPv6 Routers).

Aquando da obtenção da informação DHCPv6 o cliente e o servidor trocam mensagens ND. Geralmente um cliente envia uma mensagem Multicast Router Solicitation (RS) a todos agentes DHCPv6 que podem ser servidores-encaminhadores ou servidores de reencaminhamento (relay servers) ao endereço Multicast FF02::1:2 com escopo local, a solicitar uma mensagem Unicast Router Advertisement (RA) do servidor-encaminhador, que, por sua vez responde com o tal RA que também indica o seu tipo de configuração DHCPv6 (stateful ou stateless). O Default Router do cliente é o endereço de link local do servidor-encaminhador.

Geralmente configura-se o servidor-encaminhador para gerar e enviar Unicast RA’s com o comando ipv6 unicast-routing. Dessa forma, ele não irá proceder a geração e envio de mensagens RS.

A topologia abaixo é bastante elucidativa. Temos dois encaminhadores, nomeadamente R2, que faz o papel de servidor-encaminhador, e R3 que faz o papel de cliente. R2 é configurado como servidor DHCPv6 Stateless de modo que envia RA’s com informações sobre o seu prefixo, o seu tamanho, o endereco DNSv6 e o Domain Name.
o cliente R3 na sua interface fastethernet 0/0 por seu lado obtêm de R2 apenas o prefixo, de modo que estando configurado para autoconfiguração ela gera o seu endereço IPv6 por meio do método EUI-64 e obtêm de R2 apenas o DNSv6 e o Domain Name.

 

DHCPv6 Stateless
R2 Configuration

hostname R2

ipv6 unicast-routing

ipv6 dhcp pool SEQEUELE
address prefix 3111:1111:2222:3333::/64 lifetime infinite infinite
dns-server 2001:4860:4860::8888
domain-name http://www.snnangola.co.ao

interface FastEthernet0/0
no ip address
speed auto
duplex auto
ipv6 address 3111:1111:2222:3333::1/64
ipv6 dhcp server SEQEUELE rapid-commit
!
ip forward-protocol nd
!
no cdp advertise-v2

R3 Configuration

hostname Router

interface FastEthernet0/0
ipv6 address autoconfig
ipv6 nd other-config-flag
ipv6 dhcp client pd SEQEUELE rapid-commit

ip forward-protocol nd
!
no cdp log mismatch duplex

Testes

Interfaces associadas em R2

R2#sh ipv6 dhcp int
FastEthernet0/0 is in server mode
Using pool: SEQEUELE
Preference value: 0
Hint from client: ignored
Rapid-Commit: enabled

Confirmação da ausência de estado em R2

R2#sh ipv6 dhcp binding
R2#sh ipv6 dhcp database

Nao retorna qualquer informação de associação. Mas…

Interfaces associadas em R3

#sh ipv6 dhcp interface
FastEthernet0/0 is in client mode
State is SOLICIT
List of known servers:
Reachable via address: 3111:1111:2222:3333::1
DUID: 00030001CA0210EC0000
Preference: 0
Configuration parameters:
IA PD: IA ID 0x00040001, T1 60, T2 120
DNS server: 2001:4860:4860::8888
Domain name: http://www.snnangola.co.ao
Prefix name: SEQEUELE
Rapid-Commit: enabled

 

DHCPv6 um exemplo simples (I)

Nao quis terminar o ano 2015 sem publicar um artigo. O que era para ser um passeio tornou-se um pesadelo, próprio de quem andou algum tempo fora de assuntos técnicos. Entretanto a rapidez com que voltei a dominar os conceitos só provaram que afinal acabamos por não esquecer aquilo que bem aprendemos.

I Won’t finish the 2015 season without publish a post. The runawaylder was turned into a nightmare, because I wasn’t refreshed regarding to new Cisco IPv6 concepts. However after a self taught CCNP ROUTE lessons and packet tracer or GNS3 practises I’m sure that i never forgot the old concepts, so I’m feeling ready and confident now.

Como sabem o protocolo IPv6 está aos poucos a transformar-se no padrão the facto das transmissões em comutação de pacotes. Ja escrevi muitos artigos sobre IPv6, você pode consulta-los aqui e aqui. Quase a sete (7) anos atrás quando escrevi o primeiro artigo sobre IPv6 pensava-se sempre em implementações dual stack, ou seja hosts e servers com interfaces com endereços em IPv4 e IPv6. Ora, penso que isto deve ser de evitar no futuro. Em alguns casos, por questões de falta de interoperabilidade, obsolência, resistência a mudanças e segurança de aplicações, ainda se observa com alguma frequência este tipo de implementação.

As you know the IPv6 protocol is becoming bit by bit the the facto protocol for IP switching networks transmissions. I have wrote some articles about IPv6 standard, so you can check here and here. Almost a seven (7) years ago when i have wrote my first article about IPv6 we thought ever in dual stack implementations. Even thinking the public IPv4 numbers for AFRINic are exhausting we need to get ready for the changes that are becoming standard. There are cases where the IPv6 isn’t recommended such as those who insist to have hard control of some OSI or IP model layers. There are situations where we can face resistance for changes, lack of interoperability and some obsolency too.

O nosso exemplo é muito simples. Temos um encaminhador de pacotes (router) com duas sub-redes atras dele, que podem ser dois andares ou dois departamentos. Queremos que o nosso encaminhador Router0 seja o nosso servidor DHCPv6 e forneça os endereços IPv6, DNS e Domain Name:

The diagram below is quite simple. We have a Router with two (2) sub-networks behind them, who should be two floors or departments. We want Router0 to be our DHCPv6 server in order to supply the IPv6 address, DNS and Domain Name:

Sub-Redes tudo IPv6

Sub-Redes tudo IPv6

 

Temos duas sub-redes por detrás de Router0: Sub-Rede LUANDA  por detrás da interface Fa0/0 e Sub-Rede KILAMBA por detrás de Fa0/1. Um servidor DNS configurado como estático e um outro servidor também com endereçamento estático. Dois computadores pessoais. Um configurado para ser cliente (host) STATEFUL e outro para ser cliente (host) STATELESS. A razão porque fazemos isso é muito simples: verificar se mesmo com o server Router0 configurado para não enviar Router Advertisements (RA) com o comando ipv6 nd managed-config-flag , ou seja forçar os hosts a não obter endereçamento em autoconfiguration (SLAAC) e usar o DHCPv6 eles ainda assim procedem, gerando configuração IPv6 pelo método EUI-64 e obtendo de Router0 apenas o DNS e o Domain Name.

Endereçamento IPv6 (IPv6 Addressing):

Luanda Prefix -> 3111:1:2:4::/64
Router0, Fa0/0 -> 3111:1:2:4::1/64
Kilamba Prefix -> 3111:1:2:6::/64
Router0, Fa0/1 -> 3111:1:2:6::1/64
Luanda DNS Server -> 3111:1:2:4::3/64

Router0 Configuration:

Activar encaminhamento de pacotes IPv6 (Enable IPv6 packet forwarding between interfaces on Cisco Router)

ipv6 unicast-routing

 

Configurar duas pools de endereços para LUANDA e KILAMBA

ipv6 local pool STATEFUL-LUANDA 3111:1:2:4::/64 64
ipv6 local pool STATEFUL-KILAMBA 3111:1:2:6::/64 64

Configuração em modo global de DHCPv6 pool para LUANDA

ipv6 dhcp pool STATEFUL-LUANDA
prefix-delegation pool STATEFUL-LUANDA
dns-server 3111:1:2:4::2
domain-name http://www.snnangola.co.ao

Configuração em modo global de DHCPv6 pool para KILAMBA

ipv6 dhcp pool STATEFUL-KILAMBA
prefix-delegation pool STATEFUL-KILAMBA
dns-server 3111:1:2:4::2
domain-name http://www.snnangola.co.ao
!

Configuração de interface Fa0/0 como provedora de endereçamento a pool STATEFUL-LUANDA

interface FastEthernet0/0
no ip address
duplex auto
speed auto
ipv6 address 3111:1:2:4::1/64
ipv6 nd managed-config-flag
ipv6 dhcp server STATEFUL-LUANDA
!

Configuração de interface Fa0/1 como provedora de endereçamento a pool STATEFUL-KILAMBA

interface FastEthernet0/1

no ip address
duplex auto
speed auto
ipv6 address 3111:1:2:6::1/64
ipv6 nd managed-config-flag
ipv6 dhcp server STATEFUL-KILAMBA

PC1, configurado como autoconfig:

PC>ipv6config /all

FastEthernet0 Connection:(default port)

Physical Address…………….: 0090.0C7E.BD87
Link-local IPv6 Address………: FE80::290:CFF:FE7E:BD87
IPv6 Address………………..: 3111:1:2:4:290:CFF:FE7E:BD87/64
Default Gateway……………..: FE80::201:C9FF:FE09:E301
DNS Servers…………………: 3111:1:2:4::2
DHCPv6 IAID…………………: 249352694
DHCPv6 Client DUID…………..: 00-01-00-01-28-93-5C-6E-00-90-0C-7E-BD-87

PC2, configurado como DHCPv6 STATEFUL:

PC>ipv6config /all

FastEthernet0 Connection:(default port)

Physical Address…………….: 00E0.8FBE.4A06
Link-local IPv6 Address………: FE80::2E0:8FFF:FEBE:4A06
IPv6 Address………………..: 3111:1:2:4:2E0:8FFF:FEBE:4A06/64
Default Gateway……………..: FE80::201:C9FF:FE09:E301
DNS Servers…………………: 3111:1:2:4::2
DHCPv6 IAID…………………: 486531192
DHCPv6 Client DUID…………..: 00-01-00-01-27-86-D6-26-00-E0-8F-BE-4A-06

Verificando associação em Router0

RW0#sh ipv6 dhcp binding

Client: (FastEthernet0/0)
DUID: 00-01-00-01-27-86-D6-26-00-E0-8F-BE-4A-06
IA PD: IA ID 486531192, T1 0, T2 0
Prefix: 3111:1:2:4::/64
preferred lifetime 604800, valid lifetime 2592000
expires at janeiro 31 2016 2:44:3 am (2592000 seconds)

Client: (FastEthernet0/0)
DUID: 00-01-00-01-28-93-5C-6E-00-90-0C-7E-BD-87
IA PD: IA ID 249352694, T1 0, T2 0
Prefix: 3111:1:2:4::/64
preferred lifetime 604800, valid lifetime 2592000
expires at janeiro 31 2016 2:44:3 am (2592000 seconds)

Client: (FastEthernet0/1)
DUID: 00-01-00-01-E5-E7-A9-E6-00-05-5E-B8-5A-BD
IA PD: IA ID 825564713, T1 0, T2 0
Prefix: 3111:1:2:6::/64
preferred lifetime 604800, valid lifetime 2592000
expires at janeiro 31 2016 2:44:3 am (2592000 seconds)

Client: (FastEthernet0/1)
DUID: 00-01-00-01-A1-7C-76-89-00-D0-BC-02-4D-CE
IA PD: IA ID 774598856, T1 0, T2 0
Prefix: 3111:1:2:6::/64
preferred lifetime 604800, valid lifetime 2592000
expires at janeiro 31 2016 2:44:3 am (2592000 seconds)

Como podemos ver, houve associação. No próximo artigo vamos abordar aspectos mais profundos sobre DHCPv6.

Agregaçao de links Ethernet usando Etherchannel (II)

Na primeira parte vimos alguns conceitos básicos sobre a tecnologia Etherchannel. Interessa pois, abordar apenas um aspecto e depois a parte prática.

Quando dois comutadores pretender formar um agregado de links eles precisam estar configurados com um dos dois protocolos a seguir: PAgP (Port Aggregation Protocol) ou LACP (Link Aggregation Protocol).
O PAgP é um protocolo proprietário pertencente a Cisco (Quem mais?) e o LACP (802.3ad) foi criado como um padrão aberto pela IEEE permitindo que comutadores de diferentes fabricantes possam formar agregados.

Cada um destes protocolos possui diferentes modos de operação. A seguinte tabela resume-os:

Mode Description
on Mode that forces the LAN port to channel unconditionally. In the on mode, a usable EtherChannel exists only when a LAN port group in the on mode is connected to another LAN port group in the on mode. Because ports configured in the on mode do not negotiate, there is no negotiation traffic between the ports. You cannot configure the on mode with an EtherChannel protocol. If one end uses the on mode, the other end must also.
auto PAgP mode that places a LAN port into a passive negotiating state, in which the port responds to PAgP packets it receives but does not initiate PAgP negotiation. (Default)
desirable PAgP mode that places a LAN port into an active negotiating state, in which the port initiates negotiations with other LAN ports by sending PAgP packets.
passive LACP mode that places a port into a passive negotiating state, in which the port responds to LACP packets it receives but does not initiate LACP negotiation. (Default)
active LACP mode that places a port into an active negotiating state, in which the port initiates negotiations with other ports by sending LACP packets.

O nosso exemplo é um cenário onde dois escritórios, IT e RH pertencem as VLANs 10 e 20 respectivamente. Para aumentar o débito binário no envio de dados entre os dois escritórios, o administrador de rede, decidiu usar a tecnologia Etherchannel entre eles. Na camada de distribuição está disponível um comutador Cisco 3560 Layer 3 que realizará encaminhamento InterVLAN entre os dois escritórios:

Etherchannel com roteador L3 e vlans

Foi providenciada redundância na camada física também, de modo que mesmo perdendo-se comunicação entre os comutadores IT, RH e o comutadorL3 existe uma ligação física redundante entre os comutadores IT e RH.

A seguinte tabela fornece um resumo do que se consegue com este cenário:

Ligação Débito Conseguido por Canal Interfaces utilizadas Protocolo Usado Port Canal de um Extremo a outro
ComutadorL3 -> IT (Vice-Versa) 400 Mbps Fa0/1-4 -> Fa0/1-4 PAgP 1 – 2
Comutador L3 -> RH (Vice-Versa) 400 Mbps Fa0/5-8 -> Fa0/5-8 PAgP 2 – 2
IT -> RH (Vice-Versa) 200 Mbps Fa0/23-24 -> Fa0/23-24 PAgP 1 – 1

Para conseguirmos configurar o nosso cenário, são necessários os seguintes seis passos:

1 – Criar as VLANs 10 (IT), 20 (RH) e 1 (Nativa) no comutador comutadorL3. Nos comutadores IT e RH configurar VLAN 1 (Nativa).

ComutadorL3

interface Vlan1
ip address 192.168.1.1 255.255.255.0

interface Vlan10
ip address 192.168.10.1 255.255.255.0

interface Vlan20
ip address 192.168.20.1 255.255.255.0

IT

interface Vlan1
ip address 192.168.1.10 255.255.255.0

RH

interface Vlan1
ip address 192.168.1.20 255.255.255.0

2 – Activar Comutadores IT e RH em modo VTP client. Criar domínio VTP SNNANGOLA nos 3 comutadores.

IT

IT#sh vtp st
VTP Version                     : 2
Configuration Revision          : 4
Maximum VLANs supported locally : 255
Number of existing VLANs        : 7
VTP Operating Mode              : Client
VTP Domain Name                 : SNNANGOLA

RH

RH#sh vtp st
VTP Version                     : 2
Configuration Revision          : 4
Maximum VLANs supported locally : 255
Number of existing VLANs        : 7
VTP Operating Mode              : Client
VTP Domain Name                 : SNNANGOLA

ComutadorL3

ComutadorL3#sh vtp st
VTP Version                     : 2
Configuration Revision          : 4
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 7
VTP Operating Mode              : Server
VTP Domain Name                 : SNNANGOLA

3 – Activar Gateway de saída nos comutadores IT e RH a apontar para endereço de VLAN nativa no comutadorL3.

IT

ip default-gateway 192.168.1.1

RH

ip default-gateway 192.168.1.1

4 – Criar Port-Channel entre os comutadores.

ComutadorL3

interface FastEthernet0/1
channel-group 1 mode desirable
switchport trunk encapsulation dot1q
switchport mode trunk

interface FastEthernet0/2
channel-group 1 mode desirable
switchport trunk encapsulation dot1q
switchport mode trunk

interface FastEthernet0/3
channel-group 1 mode desirable
switchport trunk encapsulation dot1q
switchport mode trunk

interface FastEthernet0/4
channel-group 1 mode desirable
switchport trunk encapsulation dot1q
switchport mode trunk

interface FastEthernet0/5
channel-group 2 mode desirable
switchport trunk encapsulation dot1q
switchport mode trunk

interface FastEthernet0/6
channel-group 2 mode desirable
switchport trunk encapsulation dot1q
switchport mode trunk

interface FastEthernet0/7
channel-group 2 mode desirable
switchport trunk encapsulation dot1q
switchport mode trunk

interface FastEthernet0/8
channel-group 2 mode desirable
switchport trunk encapsulation dot1q
switchport mode trunk

IT

interface FastEthernet0/1
channel-group 2 mode desirable
switchport mode trunk

interface FastEthernet0/2
channel-group 2 mode desirable
switchport mode trunk

interface FastEthernet0/3
channel-group 2 mode desirable
switchport mode trunk

interface FastEthernet0/4
channel-group 2 mode desirable
switchport mode trunk

interface FastEthernet0/23
channel-group 1 mode desirable
switchport mode trunk

interface FastEthernet0/24
channel-group 1 mode desirable
switchport mode trunk

RH

interface FastEthernet0/5
channel-group 2 mode desirable
switchport mode trunk

interface FastEthernet0/6
channel-group 2 mode desirable
switchport mode trunk

interface FastEthernet0/7
channel-group 2 mode desirable
switchport mode trunk

interface FastEthernet0/8
channel-group 2 mode desirable
switchport mode trunk

interface FastEthernet0/23
channel-group 1 mode desirable
switchport mode trunk

interface FastEthernet0/24
channel-group 1 mode desirable
switchport mode trunk

5 – Activar encaminhamento IP em comutadorL3

ip routing

6 – Activar Em IT e RH interfaces fa0/10 em access mode.

IT

interface FastEthernet0/10
switchport access vlan 10
switchport mode access

RH

interface FastEthernet0/10
switchport access vlan 20
switchport mode access

Os resultados nao enganam ninguém:

Ping PC1(IT) a PC2(RH) :

PC>ping 192.168.20.20

Pinging 192.168.20.20 with 32 bytes of data:

Request timed out.
Reply from 192.168.20.20: bytes=32 time=37ms TTL=127
Reply from 192.168.20.20: bytes=32 time=12ms TTL=127
Reply from 192.168.20.20: bytes=32 time=23ms TTL=127

Ping statistics for 192.168.20.20:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 37ms, Average = 24ms

Ping PC2(RH) a PC1(IT) :

PC>ping 192.168.10.10

Pinging 192.168.10.10 with 32 bytes of data:

Reply from 192.168.10.10: bytes=32 time=23ms TTL=127
Reply from 192.168.10.10: bytes=32 time=17ms TTL=127
Reply from 192.168.10.10: bytes=32 time=21ms TTL=127
Reply from 192.168.10.10: bytes=32 time=13ms TTL=127

Ping statistics for 192.168.10.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 23ms, Average = 18ms

Agregaçao de links Ethernet usando Etherchannel (I)

As redes Ethernet sempre possuiram dois problemas:

1 – Debito binário ponto a ponto constante: Isso é uma verdade, pois os padrões Ethernet (10 Base-T, 100Base-T por exemplo) cresceram sempre numa magnitude pouco variável. Isto não representa um problema quando estamos tratando de ligações na camada de acesso. Mas se estamos falando por exemplo de ligações na camada de distribuição isso representa um problema sim. Pense na época em que o padrão GigabitEthernet (1000Base-X, 1000Base-T, 1000Base-CX) não havia sido criado. Mesmo se termos em conta que o padrão 100Base-FX por já permitia transmissao por meio de fibra óptica em ligações ethernet isso apenas garantia qualidade na recepção, menos erros durante a transmissao, diminuição da atenuação do sinal e menos bits perdidos.  Não garantia aumento do débito binário.

2 – Ponto de falha único: É muito normal na camada de acesso ter uma ligação desfeita. Isso na camada de distribuição ou de Core seria um autentico desastre para a eficiência das comunicações que se exige constante e infalível, além de constituir um bom motivo para te fazerem uma fita la na empresa.

Para dirimir estes problemas foram criadas tecnologias e protocolos de agregação de links. Confesso ter ficado maravilhado quando tomei conhecimento delas. Uma destas tecnologias é a tecnologia Etherchannel da Cisco. Basicamente o que ela faz é agregar o debito binário dum conjunto de ligações físicas (de 2 até 8 ligações) entre dois comutadores e criar um canal lógico entre elas cujo débito binário é a soma de todos os débitos dos canais físicos conectados ponto a ponto.
Isto quer dizer que se você tiver 8 portas FastEthernet você terá 8x100Mbps = 800Mbps de débito binário. Se forem 8 portas GigabitEthernet (GbE) você terá 8×10^9bps = 8Gbps. Se forem 8 portas 10GbE você terá 80Gbps de débito binário.

Exemplo dum ambiente onde se pode aplicar a tecnologia EtherChannel

 

No exemplo acima tempos depois da camada de acesso, a camada de distribuição onde podemos localizar dois comutadores Catalyst 3550 e 8500/6000 ou 4000. Note a existência de quatro ligações GbE. Consegue-se um débito de 4×10^9=4Gbps. Esse é o débito para CADA UMA das interfaces conectadas. Lembre-se que este débito sem a existência do Etherchannel era de 1 Gbps para cada uma das interfaces.

Isso representa um ganho e tanto em termos de débito binário, mas também em termos de redundância. Mesmo se um link perder a conexão os outros links ainda continuarão a transmitir (mesmo significando isso uma baixa em termos de débito binario).

No próximo artigo veremos um exemplo prático de configuração de Etherchannel.

Encaminhamento de Broadcast de VLAN’s a servidor DHCP por detrás de roteador usando ip helper-address

Visualize o cenário abaixo:

As VLANs necessitam de obter endereços pelo servidor DHCP

Este é um cenário muito comum, em algumas redes. O roteador serve de ponte de comunicação entre as VLAN 10 (IT) e 20 (FINANCE). O que as vezes é problemático é ter o servidor DHCP ‘atrás’ do roteador, ainda mais numa sub-rede que não pertence a qualquer uma das VLAN. Isso representa um problema porque sabemos bem como funciona o processo de obtenção de endereços IP pelo hosts em suma, seria impossível esses hosts se beneficiarem dos serviços DHCP porque o roteador não encaminha pedidos de Broadcast.

Alguns administradores evitam colocar roteadores a frente dos hosts. Outros situam servidores DHCP em sub-redes dos dos hosts. Bom, estas não são boas soluções, visto que algumas redes exigem mesmo cenários como o acima ou mesmo mais complexos, com muitos mais roteadores.

Nestes casos a Cisco providencia o comando de configuração de interface ip helper-address [endereço_do_servidor_dhcp]. Trata-se dum útil comando que permite ao administrador indicar a uma interface (a que recebe o broadcast) que ela pode encaminhar um pedido de broadcast dum host.

No nosso exemplo acima, como estamos usando um cenário de implementação de VLAN’s Router-On-A-Stick, então este comando necessita de ser aplicado nas sub-interfaces fa0/0.10 e fa0/0.20 pertencentes a interfaces fa0/0 que esta ligada directamente ao comutador (Switch0).

Deste modo o servidor DHCP consegue atender aos pedidos de quaisquer dispositivo que esteja ligado as VLAN 10 ou VLAN 20.

Comutador Switch0:

Switch0#sh run

interface FastEthernet0/1
switchport access vlan 10
switchport mode access

interface FastEthernet0/2
switchport access vlan 20
switchport mode access

interface FastEthernet0/3
switchport mode trunk

Encaminhador SNNANGOLA (Router0):

SNNANGOLA#sh run

hostname SNNANGOLA

interface FastEthernet0/0
no ip address
duplex auto
speed auto

interface FastEthernet0/0.10
encapsulation dot1Q 10
ip address 172.16.10.1 255.255.255.0
ip helper-address 172.16.30.2

interface FastEthernet0/0.20
encapsulation dot1Q 20
ip address 172.16.20.1 255.255.255.0
ip helper-address 172.16.30.2

interface FastEthernet0/1
ip address 172.16.30.1 255.255.255.0
duplex auto
speed auto