PACKET TRACER CISCO Laboratório de Configuração
VLSM – Rotas Estáticas e Default
2014
Carlos Rodrigues
Digitally signed by Carlos Rodrigues DN: cn=Carlos Rodrigues, o=carlosrodrigues.it, ou=carlosrodrigues.it, email=geral@carlosrodrigues.i t, c=BR Date: 2014.03.31 22:33:51 -03'00'
Carlos M.S. Rodrigues
Copyright
2014 carlosrodrigues.it
Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e Editora.
Site de autor: carlosrodrigues.it Fórum do autor: carlosrodrigues.it/forum Email do autor: geral@carlosrodrigues.it Facebook do autor: facebook.com/carlosrodrigues.it Exemplar editado e impresso em Abril de 2014 – Primeira Impressão
Carlos M.S. Rodrigues
Dedico esta apresentação a:
Saulo Lobato, para que a memĂłria dele nunca seja esquecida, entre todos os seus amigos e colegas da turma 3001
Carlos M.S. Rodrigues
SUMÁRIO
INTRODUÇÃO ............................................................................................................ 2 1 PERGUNTAS .......................................................................................................... 3 1.1 RESPOSTAS ...................................................................................................... 4 2 PACKET TRACER ................................................................................................. 5 2.1 ESQUEMA DE REDE LÓGICA ........................................................................... 6 2.2 ESQUEMA DE REDE FÍSICA ........................................................................... 10 2.3 ENDEREÇAMENTO DE SUB-REDES .............................................................. 14 2.4 ROTEAMENTO DE ROTAS ESTÁTICAS ......................................................... 22 2.5 ROTEAMENTO DE ROTAS DEFAULT ............................................................. 39 2.6 SERVIÇO DE DHCP ......................................................................................... 45 CONCLUSÃO OU CONSIDERAÇÕES FINAIS ........................................................ 52 REFERÊNCIAS ........................................................................................................ 54 ANEXO ..................................................................................................................... 55
Carlos M.S. Rodrigues
2
INTRODUÇÃO
Uma empresa chamada Empreendimentos Farmacêuticos Ltda necessita de um projeto de interligação de redes. Um esboço da futura topologia deles é mostrada a seguir.
Figura 1 – Rede Lógica proposta
Uma vez que a empresa terá acesso direto a Internet, e seus dispositivos usarão endereços IP válidos, o provedor de serviços (ISP) forneceu um bloco inteiro de endereços classe C: 201.25.78.0 /24.
Como mostra a topologia são 11 redes, então 11 diferentes sub-redes do bloco de endereços IP devem ser criadas.
Carlos M.S. Rodrigues
3
Uma análise mais cuidadosa mostra ainda que das 11 sub-redes necessárias, nem todas as 11 redes terão o mesmo número de hosts.
Os links seriais, por exemplo, somente necessitarão de dois endereços válidos. Um planejamento de endereços usando VLSM deve ser feito, para permitir que subredes com diferentes tamanhos coexistam dentro de um domínio.
1
PERGUNTAS
1- Construção da topologia mostrada acima usando um simulador de rede.
2- Endereçamento dos computadores baseando-se nos seguintes requisitos:
a) Todos os 11 segmentos de rede devem ser endereçados. b) Cada rede interna (LAN) individual da Empreendimentos Farmacêuticos Ltda necessitará de no máximo 13 endereços válidos (para PCs de usuários, servidores e equipamentos de rede). c) Somente o bloco classe C fornecido pelo provedor, 201.25.78.0 /24, está disponível. O planejamento das subredes deve ser feito de forma a evitar ao máximo o desperdício de endereços.
3- Fornecer conectividade entre as redes, utilizando configuração de rotas estáticas e “default”.
Carlos M.S. Rodrigues
4
1.1 RESPOSTAS
1- A construção da topologia proposta está criada e disponível para download em: http://www.carlosrodrigues.it/projectos/cisco/av1.2.pkt
2- Para iniciarmos a apresentação do trabalho proposto neste artigo, devemos considerar
que
a
rede
apresentada
possui
várias
formas
diferente
de
endereçamento lógico e posicionamento do que respeita às diversas formas de abordagem de racocínio, é importante entender que não existe apenas uma forma de se configurar esta topologia proposta e mesmo a limitação imposta de configuração de somente rotas estáticas e de default, podem ter mais do que uma abordagem diferente ao problema, sendo a que vamos apresentar a nosso ver é a mais funcional na prespectiva de se conseguir uma maior fluidez de tráfego de rede e velocidades alcançadas.
No ponto 2.1 de endereçamento lógico seram descriminadas todas as 6 sub-redes para suportar 13 “hosts” cada uma, 1 sub-rede para suportar 3 “hosts” e 4 sub-redes para suportar 2 “hosts”, num total de 11 sub-redes de 91 IP´s válidos entre “hosts” e interfaces ethernet e serial. Sendo que 5 destes IP´s foram reservados para os servidores de DHCP que iram disponibilizar o endereçamento dinâmico para os computadores clientes nas 6 sub-redes LAN (Local Area Network). A parte de Internet como é um extra à proposta apresentada vai ser descriminada só no ponto 2.5.
3- A configuração de rotas estáticas seram apresentadas por tabela de roteamento no ponto 2.4 e no 2.5 seram apresentadas as rotas “default”. Sendo que, como já foi referido, é possível a existência de mais de uma forma de abordagem do problema proposto.
Carlos M.S. Rodrigues
5
2
PACKET TRACER
2.1 ESQUEMA DE REDE LÓGICA
O esquema de rede de topologia Lógica proposto para esta atividade, resultou na Fig. 1.1 apresentada em baixo, apenas alguns pontos se devem mencionar antes de passarmos para o endereçamento propriamente dito, pois estes não estão na base do layout apresentado inicialmente.
Figura 1.1 – Rede Lógica packet tracer reduzido
Carlos M.S. Rodrigues
6
Figura 1.2 – Rede Lógica packet tracer aumentada
Carlos M.S. Rodrigues
7
1. Foram adicionados 5 servidores de DHCP para atender a todos os pedidos de endereçamento dos computadores “DHCP client”. Sendo que o servidor de “hostname” DHCPbackup serve somente os clientes das sub-redes 201.25.78.0 / 28, 201.25.78.16 / 28, 201.25.78.32 / 28 e 201.25.78.48 / 28, caso exista a falha de algum dos “DHCP server´s”, que estão nas zonas diretamente ligados e a receber os pedidos dos clientes de DHCP.
2. Foi considerado que a sub-rede 201.25.78.116 / 30 tinha clientes de missão crítica, como departamentos de administração e TI, logo foi colocado 2 servidores de DHCP para atenderem aos pedidos das sub-redes respectivas 201.25.78.64 / 28 e 201.25.78.80 / 28.
3. No router R6 foi criada uma sub-rede que o interliga ao ROUTER-ISP que em teoria representa a internet, sendo que foi utilizada a rede 201.25.78.120 / 30. O ROUTER-ISP tem mais uma sub-rede também de apenas 2 “hosts” válidos para ligar um computador, afim de se efetuarem testes de conectividade. A sub-rede utilizada foi a 192.168.1.0 / 30. 4. Os “interfaces” que ligam os roteadores R1, R2, R3, R4, R5 e R6, receberam interfaces serial WIC-2T, com o encapsulamento padrão da CISCO o “HDLC High-Level Data Link Control”, afim de representarem áreas WAN (wide area network) que interligam locais distantes entre si, por tecnologias como o Frame Relay ou ATM.
Para explicar a escolha do ponto 4 passamos à seguinte explanação dos factos: Como é necessário para ligações “serial”, de se ter um CSU/DSU (Channel Service Unit/Data Service Unit) que é um dispositivo que converte os sinais digitais provenientes dos computadores para sinais digitais utilizados em comunicações síncronas normalmente em linhas WAN do tipo T1 / E1 ou T3 / E3, que se ligam
Carlos M.S. Rodrigues
8
normalmente por meio de cabos serial do tipo V35, X21 ou outro definido pela EIA/TIA, como se pode ver na imagem em baixo:
Figura 1.3 – Cabo serial padrão V.35 para redes síncronas
Foi definido em projecto que a interface Serial0/0/0 do router R1, com IP 201.25.78.114 / 30, seria considerado o DCE (Data Communications Equipment, Data Circuit-terminating Equipment ) e a interface Serial0/0/1 do router R4, seria considerada o DTE (Data Terminal Equipment ).
No router R2, a interface s0/0/1 com IP 201.25.78.105 / 30, seria considerado o DCE (Data Communications Equipment, Data Circuit-terminating Equipment ) e a interface Serial0/0/1 do router R1, seria considerada o DTE (Data Terminal Equipment ). Ainda a interface s/0/0/0 do R2, com IP 201.25.78.110 / 30, seria considerado o DCE (Data Communications Equipment, Data Circuit-terminating Equipment ) e a interface Serial0/0/1 do router R3, seria considerada o DTE (Data Terminal Equipment ).
Carlos M.S. Rodrigues
9
Pretendemos centralizar as DCE´s nos router´s R1 e R2 por uma questão de alinhamento lógico de tarefas, mas nada impede que o router R3 e R4 tomem este papel no futuro. O DCE permite determinar a frequência de clock, a determinação dos erros de transmissão e a codificação a ser utilizada, que na prática é a definição de como se envia e como se recebem os dados do outro lado. O packet tracer permite que um roteador possa tomar o papel de um DCE, desde que esteja devidamente configurado, para tal foi necessário usar o comando em baixo em ambos os router´s.
# clock rate 64000
Podemos também observar na Fig 1.4 que os router´s permitem escolher uma vasta gama de valores para transmissões em velocidade de bits por segundo. Sendo as mais utilizadas as 56000 e 64000 em esquemas de teste piloto, por serem velocidade intermédias.
Figura 1.4 – Velocidade em bits por segundo para interfaces serial
Carlos M.S. Rodrigues
10
Os interfaces serial que são DCE estão devidamente descriminados junta a todos os router´s como pode visualizar na topologia lógica Fig 1.1.
2.2 ESQUEMA DE REDE FÍSICA
Figura 1.5 – Topologia Física Packer Tracer
Podemos observar pela Fig. 1.5 produzida pelo programa Packer Tracer da CISCO que foi definido um armário de telecomunicações geral, geralmente conhecido como
Carlos M.S. Rodrigues
11
DGT (Distribuidor Geral de telecomunicações) ou DG, ele é responsável por interligar todos os cabos da rede primária de telefonia e dados aos cabos da Rede de Entrada de Facilidades (provenientes do Distribuidor da Entrada de Facilidades e das portas de tronco). No caso de redes dedicadas, o DG pode interligar cabos da rede interna de telefonia (que tem como destino a caixa de conectores de acesso de telefonia ao usuário).
E cinco mais pequenos armários de telecomunicações, geralmente conhecidos como Wiring Closet ou “RACK”, que na prática seriam um espaço destinado à transição entre o caminho primário e secundário, com conexão cruzada ou interconexão, podendo ou não abrigar equipamento ativo.
Vale aqui ressaltar que esta configuração é puramente ilustrativa ao esquema apresentado, sendo que muitos outros componente e conceitos de cabeamento estruturado (Cabeamento Horizontal e Vertical), não vão ser discutidos nesta apresentação, pois iria envolver muitos outros conceitos pelos quais estão muito além deste exercício de simulador no packet tracer, perdendo totalmente o foco central.
O programa packet tracer gera detalhadamente, conforme o mostrado na Fig. 1.6 como seriam as ligações e a disposição física dos equipamentos de rede, como se trata-se de uma “rack” real a ser instalada no cliente, para atender a todas as ligações necessárias, afim de se colocar a rede toda em funcionamento.
Com este tipo de pormenor e apresentação podemos verificar onde se ligam os cabos “ethernet” e “serial”, que portas estão a ser utilizadas e os “interfaces” respectivos. Interessante ressaltar o facto dos switch´s terem todos a porta fa0/24 ligada, pois por padrão definimos em projecto que a última porta do switch seria utilizada para ligar à porta da “default gateway”, que neste caso são os roteadores de borda de cada sub-rede respectiva, salvo na sub-rede 201.25.78.96 / 29 que interliga 3 router´s. Podemos também verificar que o roteador R1 e R2 têm dois
Carlos M.S. Rodrigues
12
cabos, cada um, de serial ligados com o módulo de interface WIC-2T pois ele é quem faz a ligação entre ambos os roteadores R3 e R4.
Figura 1.6 – Apresentação de Rack criada pelo programa Packer Tracer da CISCO
Carlos M.S. Rodrigues
13
Figura 1.6 – Apresentação de Rack criada pelo programa Packer Tracer da CISCO (Continuação)
Carlos M.S. Rodrigues
14
2.3 ENDEREÇAMENTO DE SUB-REDES
Para a esquematização de todas as redes, vamos dividir as mesmas por Router´s, sendo que vamos analisar as sub-redes primeiramente dos router´s R1, R2, R3, R4, R5 e R6 separadamente, de seguida a sub-rede “ethernet” formada entre o R3 com R4 e o R5, e por último as sub-redes “serial” formadas entre R2 com R3, R2 com R1, R1 com R4 e R5 com R6, numa amostragem da esquerda para a direita.
O ISP (Internet Service Provider) do esquema tinha fornecido um bloco inteiro de endereços de class C, com o IP 201.25.78.0 e máscara de sub-rede 255.255.255.0, logo para criarmos as 11 sub-redes pretendidas pela pergunta 2, garantido o menor desperdício possívels de IP, é necessário um planejamento VLSM (Variable Lenght Subnet Mask) de forma a termos as sub-redes contíguas umas às outras, sem sobreposição de IP´s para correcto funcionamento da rede num todo.
Em baixo no quadro apresentamos as sub-redes para os roteadores R1, R2, R3, R4, R5 e R6, que sofreram uma alteração para uma máscara de rede 255.255.255.240 de forma a terem 14 “hosts” válidos por sub-rede, lembrando que este tipo de máscara vai criar 16 sub-redes, das quais só vamos estar a utilizar 6.
A conta matemática para se calcular as sub-redes é elevar à potência de 2, quantos bits do 4 octetos foram gastos ou dispensados, que no caso foram 2^4 bits que é igual a 16 redes.
Rede
IP Inicial
IP Final
“Bits” Octeto 4
R2 - 201.25.78.0 / 28
201.25.78.1
201.25.78.14
11110000 - .240
R3 - 201.25.78.16 / 28
201.25.78.17
201.25.78.30
11110000 - .240
R1 - 201.25.78.32 / 28
201.25.78.33
201.25.78.46
11110000 - .240
R4 - 201.25.78.48 / 28
201.25.78.49
201.25.78.62
11110000 - .240
Carlos M.S. Rodrigues
15
R5 - 201.25.78.64 / 28
201.25.78.65
201.25.78.78
11110000 - .240
R6 - 201.25.78.80 / 28
201.25.78.81
201.25.78.94
11110000 - .240
201.25.78.96 / 28
201.25.78.97
201.25.78.110
11110000 - .240
201.25.78.112 / 28
201.25.78.113
201.25.78.126
11110000 - .240
201.25.78.128 / 28
201.25.78.129
201.25.78.142
11110000 - .240
201.25.78.144 / 28
201.25.78.145
201.25.78.158
11110000 - .240
201.25.78.160 / 28
201.25.78.161
201.25.78.174
11110000 - .240
201.25.78.176 / 28
201.25.78.177
201.25.78.190
11110000 - .240
201.25.78.192 / 28
201.25.78.193
201.25.78.206
11110000 - .240
201.25.78.208 / 28
201.25.78.209
201.25.78.222
11110000 - .240
201.25.78.224 / 28
201.25.78.225
201.25.78.238
11110000 - .240
201.25.78.240 / 28
201.25.78.241
201.25.78.254
11110000 - .240
Redes utilizadas
Redes desperdiçadas
A máscara de sub-rede /24 sofreu uma váriação para /28 e se apresenta da seguinte forma em código binário:
11111111.11111111.11111111.11110000
Logo, podemos observar que o 4 octeto é o que está a ser dividido para formar as sub-rede de igual tamanho.
Carlos M.S. Rodrigues
16
O IP final apresentado é o último IP válida para ser endereçado a um “host”, sendo o próximo e último IP de “broadcast”. Este último IP válido, ou IP final por convenção neste exercício foi o atribuido às interfaces dos router´s R1, R2, R3, R4, R5 e R6 para funcionar como rota de saída padrão, ou “default gateway”.
Por convenção também utilizamos o antepenúltimo IP válido nas sub-redes de R1, R2, R3 e R4 para endereçar os servidores de DHCP.
Nas sub-redes 201.25.78.64 e 201.25.78.80 não foi utilizado o antepenúltimo IP válido para os servidores de DHCP pois foi utilizado um outro esquema de endereçamento dinâmico, embora os IP´s destas redes sejam também obtidos de forma
automática.
Foram criados
2
servidores redundantes
na
sub-rede
201.25.78.96 / 29 para atenderem aos pedidos dos clientes de DHCP, destas 2 subredes referenciadas. O serviço de DHCP vai ser explicado mais à frente no ponto 2.6.
Como foi necessário criar uma única sub-rede para interligar 3 roteadores, o R3, R4 e R5, tivemos de aumentar a máscara de sub-rede para 255.255.255.248 afim de atender à próxima rede a ser criada, a 201.25.78.96 / 29.
Na tabela abaixo descriminamos todas as redes possíveis com esta máscara e identificamos a rede a ser utilizada, assim como as redes que já sofriam uma sobreposição à anterior máscara 255.255.255.240.
Rede
IP Inicial
IP Final
“Bits” Octeto 4
201.25.78.0 / 29
201.25.78.1
201.25.78.6
11111000 - .248
201.25.78.8 / 29
201.25.78.9
201.25.78.14
11111000 - .248
201.25.78.16 / 29
201.25.78.17
201.25.78.22
11111000 - .248
201.25.78.24 / 29
201.25.78.25
201.25.78.30
11111000 - .248
Carlos M.S. Rodrigues
17
201.25.78.32 / 29
201.25.78.33
201.25.78.38
11111000 - .248
201.25.78.40 / 29
201.25.78.41
201.25.78.46
11111000 - .248
201.25.78.48 / 29
201.25.78.49
201.25.78.54
11111000 - .248
201.25.78.56 / 29
201.25.78.57
201.25.78.62
11111000 - .248
201.25.78.64 / 29
201.25.78.65
201.25.78.70
11111000 - .248
201.25.78.72 / 29
201.25.78.73
201.25.78.78
11111000 - .248
201.25.78.80 / 29
201.25.78.81
201.25.78.86
11111000 - .248
201.25.78.88 / 29
201.25.78.89
201.25.78.94
11111000 - .248
201.25.78.96 / 29
201.25.78.97
201.25.78.102
11111000 - .248
201.25.78.104 / 29
201.25.78.105
201.25.78.110
11111000 - .248
201.25.78.112 / 29
201.25.78.113
201.25.78.118
11111000 - .248
201.25.78.120 / 29
201.25.78.121
201.25.78.126
11111000 - .248
201.25.78.128 / 29
201.25.78.129
201.25.78.134
11111000 - .248
201.25.78.136 / 29
201.25.78.137
201.25.78.142
11111000 - .248
201.25.78.144 / 29
201.25.78.145
201.25.78.150
11111000 - .248
201.25.78.152 / 29
201.25.78.153
201.25.78.158
11111000 - .248
201.25.78.160 / 29
201.25.78.161
201.25.78.166
11111000 - .248
201.25.78.168 / 29
201.25.78.169
201.25.78.174
11111000 - .248
201.25.78.176 / 29
201.25.78.177
201.25.78.182
11111000 - .248
Carlos M.S. Rodrigues
18
201.25.78.184 / 29
201.25.78.185
201.25.78.190
11111000 - .248
201.25.78.192 / 29
201.25.78.193
201.25.78.198
11111000 - .248
201.25.78.200 / 29
201.25.78.201
201.25.78.206
11111000 - .248
201.25.78.208 / 29
201.25.78.209
201.25.78.214
11111000 - .248
201.25.78.216 / 29
201.25.78.217
201.25.78.222
11111000 - .248
201.25.78.224 / 29
201.25.78.225
201.25.78.230
11111000 - .248
201.25.78.232 / 29
201.25.78.233
201.25.78.238
11111000 - .248
201.25.78.240 / 29
201.25.78.241
201.25.78.246
11111000 - .248
201.25.78.248 / 29
201.25.78.249
201.25.78.254
11111000 - .248
Redes utilizadas
Redes desperdiçadas
Redes sobrepostas
Se observarmos o IP 201.25.78.xxx é de Classe C e a máscara de sub-rede padrão sofreu uma váriação, de /24 para /28 bits, de seguida para não desperdicar mais IP´s, utilizamos mais 1 bit do 4 octeto, que se apresenta da seguinte forma em código binário: 11111111.11111111.11111111.00000000 – 24 bits de máscara 11111111.11111111.11111111.11110000 – 28 bits de máscara 11111111.11111111.11111111.11111000 – 29 bits de máscara
Logo, podemos observar que o 4 octeto é o que vai definir as sub-redes de igual tamanho, sendo que 2^5 bits é igual a 32 redes possíveis, sendo que as primeiras
Carlos M.S. Rodrigues
19
sub-redes de 201.25.78.0 / 28 até 201.25.78.88 estão a ser utilizada pelos router´s R1, R2, R3, R4, R5 e R6 para endereçar os seus clientes nas LAN´s, sendo a próxima sub-rede disponível a 201.25.78.96 / 29, conforme pode visualizar na tabela em cima. Esta sub-rede serviu para interligar os roteadores R3, R4 e R5, os “interfaces” dos mesmos receberam os 3 primeiros IP´s válidos ao contário do que aconteceu no endereçamento anterior, que por convenção utilizamos os últimos IP´s para funcionar como rota de saída padrão, ou “default gateway”.
Os últimos 3 IP´s foram atribuidos aos servidores de DHCP, mas seram descriminados detalhadamente mais à frente, quando formos apresentar o planejamento do serviço de endereçamento dinâmico.
Para terminar esta parte de endereçamento lógico, fica só por apresentar as subredes que foram utilizadas para conectar os interfaces serial dos roteadores entre R1, R2, R3 e R4, conforme Fig 1.7 em baixo.
Figura 1.7 – Enlace Serial entre R1, R2, R3 e R4
Carlos M.S. Rodrigues
20
E entre os router´s R5 e R6 conforme Fig 1.8 em baixo:
Figura 1.8 – Enlace Serial entre R5 e R6
Para não tornar esta apresentação demasiado exaustiva, apenas vamos fazer referência às redes utilizadas, sendo que a mesma lógica de obtenção de 1 bit a mais foi utilizado da mesma forma, como já apresentado anteriormente.
O IP 201.25.78.xxx que inicialmente era de Classe C, com a máscara de sub-rede padrão sofreu uma váriação, de /24 para /28 bits e posteriormente para /29, como as ligações “serial” apenas necessitam de 2 IP´s válidos, normalmente por convenção é atribuido uma máscara de sub-rede /30 de forma a não desperdiçar nenhum IP válido, aumentando também por outro lado a segurança do enlace físico.
Se utilizarmos mais 1 bit do 4 octeto, acabamos por criar a máscara de sub-rede /30, que se apresenta da seguinte forma em código binário:
11111111.11111111.11111111.00000000 – 24 bits de máscara 11111111.11111111.11111111.11110000 – 28 bits de máscara
Carlos M.S. Rodrigues
21
11111111.11111111.11111111.11111000 – 29 bits de máscara 11111111.11111111.11111111.11111100 – 30 bits de máscara
Logo, podemos observar que o 4 octeto que está a ser dividido, que corresponde a 6 bits emprestados, forma 64 sub-redes possíveis de iguais tamanho, o cálculo matemático é de 2^6 bits, igual a 64 redes.
Rede
IP Inicial
IP Final
“Bits” Octeto 4
201.25.78.104 / 30
201.25.78.105
201.25.78.106
11111100 - .252
201.25.78.108 / 30
201.25.78.109
201.25.78.110
11111100 - .252
201.25.78.112 / 30
201.25.78.113
201.25.78.114
11111100 - .252
201.25.78.118 / 30
201.25.78.119
201.25.78.120
11111100 - .252
ISP- 201.25.78.120 / 28
201.25.78.121
201.25.78.122
11111100 - .252
Redes utilizadas
Formação de Sub-redes entre router´s:
Entre R1 e R2 foi utilizada a sub-rede 201.25.78.104 / 30.
Entre R1 e R4 foi utilizada a sub-rede 201.25.78.112 / 30.
Entre R2 e R3 foi utilizada a sub-rede 201.25.78.108 / 30.
Entre R5 e R6 foi utilizada a sub-rede 201.25.78.116 / 30.
Carlos M.S. Rodrigues
22
2.4 ROTEAMENTO DE ROTAS ESTÁTICAS
Os Roteadores de “hostname” R1, R2, R3, R4, R5 e R6 depois de ligados e configurados a nível dos interfaces, apresentam as tabelas de roteamento apresentados nas Fig. 1.9, 2.0, 2.1, 2.2, 2.3 e 2.4. Podemos observar que todos os roteadores apresentam o código “C” à frente de cada sub-rede, que representa que estam conectados diretamente aos seus “interfaces” respectivos.
Deste modo todos os roteadores neste ponto inicial de configuração, não têm como conhecer onde ficam o resto das outras sub-redes. Para tal, vamos de seguida começar a configurar rotas estáticas nos router´s.
Router R1 (Route table)
Figura 1.9 – tabela de rotas em roteador R1
Carlos M.S. Rodrigues
23
Router R2 (Route table)
Figura 2.0 – tabela de rotas em roteador R2
Router R3 (Route table)
Figura 2.1 – tabela de rotas em roteador R3
Carlos M.S. Rodrigues
24
Router R4 (Route table)
Figura 2.2 – tabela de rotas em roteador R4
Router R5 (Route table)
Figura 2.3 – tabela de rotas em roteador R5
Carlos M.S. Rodrigues
25
Router R6 (Route table)
Figura 2.4 – tabela de rotas em roteador R6
Como a sumarização de rotas não foi mencionada, não vamos proceder à sua avaliação, apenas vamos configurar rotas estáticas router a router, fazendo esta pequena ressalva, pois a sumarização ajuda imenso os router´s a nível de aumentarem o seu desempenho e “performance”, pois utilizam menos CPU e conseguem decidir mais rapidamente por onde devem encaminhar os pacotes que chegam a seu “buffer” de entrada.
Analisando a quantidade de rotas que vão ter que ser inseridas manualmente pelo administrador de redes, podemos verificar desde já que os Router´s R1, R2, R3, R4 e R5 precisam de aprender por onde enviar pacotes para 8 sub-redes diferentes, das quais já conhecem em suas tabelas de rotas e R6, tem que conhecer para onde enviar pacotes para 9 sub-redes diferentes.
Vamos dar inicio às configurações entrando em modo global de configuração no router R1 inserindo as rotas, com os seguintes comandos:
R1(config)#ip route 201.25.78.0 255.255.255.240 s/0/0/1 R1(config)#ip route 201.25.78.108 255.255.255.252 s/0/0/1 R1(config)#ip route 201.25.78.16 255.255.255.240 s/0/0/1 R1(config)#ip route 201.25.78.48 255.255.255.240 s/0/0/0
Carlos M.S. Rodrigues
26
R1(config)#ip route 201.25.78.96 255.255.255.248 s/0/0/0 R1(config)#ip route 201.25.78.116 255.255.255.252 s/0/0/0 R1(config)#ip route 201.25.78.64 255.255.255.240 s/0/0/0 R1(config)#ip route 201.25.78.80 255.255.255.240 s/0/0/0
Router R1 (Route table)
Figura 2.5 – tabela de rotas em roteador R1
De seguida entramos em modo global de configuração no router R2 inserindo as rotas, com os seguintes comandos:
R2(config)#ip route 201.25.78.32 255.255.255.240 s/0/0/1 R2(config)#ip route 201.25.78.112 255.255.255.252 s/0/0/1 R2(config)#ip route 201.25.78.16 255.255.255.240 s/0/0/0 R2(config)#ip route 201.25.78.48 255.255.255.240 s/0/0/1 R2(config)#ip route 201.25.78.96 255.255.255.248 s/0/0/0 R2(config)#ip route 201.25.78.116 255.255.255.252 s/0/0/0
Carlos M.S. Rodrigues
27
R2(config)#ip route 201.25.78.64 255.255.255.240 s/0/0/0 R2(config)#ip route 201.25.78.80 255.255.255.240 s/0/0/0
Router R2 (Route table)
Figura 2.6 – tabela de rotas em roteador R2
De seguida entramos em modo global de configuração no router R3 inserindo as rotas, com os seguintes comandos:
R3(config)#ip route 201.25.78.0 255.255.255.240 s/0/0/1 R3(config)#ip route 201.25.78.104 255.255.255.252 s/0/0/1 R3(config)#ip route 201.25.78.112 255.255.255.252 s/0/0/1 R3(config)#ip route 201.25.78.32 255.255.255.240 s/0/0/1 R3(config)#ip route 201.25.78.48 255.255.255.240 s/0/0/1 R3(config)#ip route 201.25.78.116 255.255.255.252 fa0/0 R3(config)#ip route 201.25.78.64 255.255.255.240 fa0/0 R3(config)#ip route 201.25.78.80 255.255.255.240 fa0/0
Carlos M.S. Rodrigues
28
Router R3 (Route table)
Figura 2.7 – tabela de rotas em roteador R3
De seguida entramos em modo global de configuração no router R4 inserindo as rotas, com os seguintes comandos:
R3(config)#ip route 201.25.78.32 255.255.255.240 s/0/0/1 R3(config)#ip route 201.25.78.104 255.255.255.252 s/0/0/1 R3(config)#ip route 201.25.78.0 255.255.255.240 s/0/0/1 R3(config)#ip route 201.25.78.108 255.255.255.252 s/0/0/1 R3(config)#ip route 201.25.78.16 255.255.255.240 s/0/0/1 R3(config)#ip route 201.25.78.116 255.255.255.252 fa0/0 R3(config)#ip route 201.25.78.64 255.255.255.240 fa0/0 R3(config)#ip route 201.25.78.80 255.255.255.240 fa0/0
Carlos M.S. Rodrigues
29
Router R4 (Route table)
Figura 2.8 – tabela de rotas em roteador R4
Antes de avançarmos mais nas configurações de rotas estáticas, vamos fazer uma pausa e analisar se a nossa rede do lado esquerdo mostrado na Fig. 2.9 está a funcionar correctamente, uma vez que do lado direito, o pacote só vai conhecer a rota de ida.
Figura 2.9 – Topologia Lógica dividida ao meio
Carlos M.S. Rodrigues
30
Podemos visualizar pela Fig. 3.0 a troca de pacotes ICMP entre o PC2 da sub-rede 201.25.78.16 / 28 localizados em R3 com as 3 restantes sub-redes localizadas em R2, R1 e R4 respectivamente.
Figura 3.0 – Pacote ICMP enviado de PC2 para PC1, PC4 e PC6
Agora podemos visualizar pela Fig. 3.1 a troca de pacotes ICMP entre o PC1 da subrede 201.25.78.0 / 28 localizados em R2 com as 3 restantes sub-redes localizadas em R3, R1 e R4 respectivamente.
Figura 3.1 – Pacote ICMP enviado de PC1 para PC2, PC4 e PC6
Pela Fig. 3.2 podemos visualizar a troca de pacotes ICMP entre o PC4 da sub-rede 201.25.78.32 / 28 localizados em R1 com as 3 restantes sub-redes localizadas em R4, R2 e R3 respectivamente.
Figura 3.2 – Pacote ICMP enviado de PC4 para PC6, PC0 e PC3
Carlos M.S. Rodrigues
31
Por último, podemos visualizar pela Fig. 3.3 a troca de pacotes ICMP entre o PC7 da sub-rede
201.25.78.32 / 28 localizados em R4 com as 3 restantes sub-redes
localizadas em R1, R2 e R3 respectivamente.
Figura 3.3 – Pacote ICMP enviado de PC7 para PC5, PC1 e PC3
Concluindo que esta porção da rede está a funcionar correctamente, conforme podemos verificar com o modo de simulação do programa packet tracer da CISCO.
Vamos agora configurar as rotas estáticas nos router´s R5 e R6, para tal, entramos no modo de configuração global no router R5 e inserimos as rotas apresentadas, com os seguintes comandos:
R5(config)#ip route 201.25.78.80 255.255.255.240 s0/0/0 R5(config)#ip route 201.25.78.48 255.255.255.240 fa0/0 R5(config)#ip route 201.25.78.112 255.255.255.252 fa0/0 R5(config)#ip route 201.25.78.32 255.255.255.240 fa0/0 R5(config)#ip route 201.25.78.104 255.255.255.252 fa0/0 R5(config)#ip route 201.25.78.0 255.255.255.240 fa0/0 R5(config)#ip route 201.25.78.108 255.255.255.252 fa0/0 R5(config)#ip route 201.25.78.16 255.255.255.240 fa0/0
Carlos M.S. Rodrigues
32
Router R5 (Route table)
Figura 3.4 – tabela de rotas em roteador R5
De seguida entramos em modo global de configuração no router R6 inserindo as rotas, com os seguintes comandos:
R6(config)#ip route 201.25.78.64 255.255.255.240 s0/0/1 R6(config)#ip route 201.25.78.96 255.255.255.248 s0/0/1 R6(config)#ip route 201.25.78.48 255.255.255.240 s0/0/1 R6(config)#ip route 201.25.78.112 255.255.255.252 s0/0/1 R6(config)#ip route 201.25.78.32 255.255.255.240 s0/0/1 R6(config)#ip route 201.25.78.104 255.255.255.252 s0/0/1 R6(config)#ip route 201.25.78.0 255.255.255.240 s0/0/1 R6(config)#ip route 201.25.78.108 255.255.255.252 s0/0/1 R6(config)#ip route 201.25.78.16 255.255.255.240 s0/0/1
Carlos M.S. Rodrigues
33
Router R6 (Route table)
Figura 3.5 – tabela de rotas em roteador R6
Importante neste ponto referir mais uma questão pertinente que se prende com as chamadas rotas de “Recursive Lookup”, que segunda a CISCO, se utilizar a configuração de rotas estáticas com o IP em vez do “interface” de saída, o router tem sempre que analisar a tabela duas vezes, antes de enviar o pacote no enlace, isto porque ele tem que descobrir o interface onde o IP de saída que foi configurado se encontra, logo é boa prática configurar o interface em vez do IP.
Figura 3.6 – Exemplo da CISCO que demonstra a recursividade
Carlos M.S. Rodrigues
34
Ainda que se possa deduzir por uma abordagem mais superficial que o roteador R5 necessita de saber o IP exacto de destino da “interface” fa0/0 do router R3 e o “interface” de destino fa0/0 do R4, a verdade é que podemos simplesmente configurar ambas as rotas apenas com o auxílio da “interface” fa0/0, que é a porta de “outbound” dos pacotes que são encaminhados para essas mesmas rotas, quando acontece o “recursive lookup” interno.
Pois se analisarmos exatamente o que acontece no momento de decisão, de envio do pacote para a rede, entendemos que, como o pacote para atingir ambas as rotas tem que sair pelo mesmo interface, que é o fa0/0, a configuração em baixo funciona perfeitamente: R5(config)#ip route 201.25.78.48 255.255.255.240 fa0/0 R5(config)#ip route 201.25.78.16 255.255.255.240 fa0/0
Figura 3.7 – Pacote ICMP enviado de PC9 e PC8 para PC7 e PC3
Contudo e após uma abordagem ainda mais atenta, em modo “Simulation”, conseguimos observar que o pacote nem sempre trafega pelo caminho mais curto, recorrentemente foi efetuado o teste que comprovou, que se o pacote era enviado para a sub-rede 201.25.78.16 / 28, quase sempre escolhia o caminho mais curto, mas quando o pacote era enviado para a sub-rede 201.25.78.48 / 28 ele fazia o trajecto mais longo normalmente, tendo também em alguns testes escolhido o caminho preferencial, no entanto e como estamos a analisar o percurso dos pacotes, recolhemos uma imagem que comprova que o caminho mais curto nem sempre é o escolhido, como pode ser visualizado na Fig. 3.7.
Carlos M.S. Rodrigues
35
Figura 3.8 – Pacote ICMP enviado da rede 201.25.78.64 / 28 para 201.25.78.48 / 28
A CISCO recomenda que nestes casos, quando o acesso “ethernet” é de multiplo acesso, existe uma forma de eliminar a recursividade, como se pode ler pelo excerto do texto original, retirado do curso oficial da academia da CISCO CCNP.
“Configuring static routes without recursive lookups can also be done over multiaccess networks like Ethernet. In this instance, using only an exit-interface instead of an intermediate address causes a problem. Because the network is multiaccess, there most likely are multiple devices, receivers, and so on, sharing this network.
In order to avoid the recursive route lookup, the solution is to use both an intermediate address and an exit interface. When using both the intermediate address and the exit interface, only a single lookup is needed in the routing table lookup process.”
Carlos M.S. Rodrigues
36
Devido as limitações do próprio simulador não é possível configurar no simulador o comando pretendido, assim como também o sub-comando CEF (Cisco Express Forwarding), não nos foi possível executar, o que poderia ajudar a visualizar as escolhas exactas do roteador em questão, contudo na Fig. 3.9 em um router de produção podemos ver algumas das escolhas que o roteador realiza internamente, se verificarmos com atenção, ele associa uma rota a um determinado “interface”.
Figura 3.9 – Tabela de CEF em roteador CISCO
Após a adordagem deste tema e devido às limitações do simulador, foi inserido no router R5 os seguintes comandos: R5(config)#ip route 201.25.78.48 255.255.255.240 201.25.78.99 R5(config)#ip route 201.25.78.16 255.255.255.240 201.25.78.98
Carlos M.S. Rodrigues
37
Os comandos recomendados pela CISCO, afim de evitar a recursividade, seriam:
R5(config)#ip route 201.25.78.48 255.255.255.240 fa0/0 201.25.78.99 R5(config)#ip route 201.25.78.16 255.255.255.240 fa0/0 201.25.78.98
Como não foi possível digitar os comandos recomendados pela CISCO, acabamos por inserir os IP´s das “interfaces” das sub-redes em questão. Esta medida foi tomada, para que o router R5, na hora da escolha, envia-se sempre o pacote pela rota mais curta, como já tivemos a oportunidade de mencionar anteriormente, nem sempre este caso se verificava. Ficando a tabela de roteamento de R5 “route table”, com o seguinte aspecto:
Router R5 (Route table)
Figura 4.0 – tabela de rotas em roteador R5 após inserção de rota estática
Carlos M.S. Rodrigues
38
Se repararmos neste momento que inserimos a rota estática para a sub-rede 201.25.78.48 / 28 e 201.25.78.16 / 28, aparece em baixo [1 / 0] via 201.25.78.99 e [1 / 0] via 201.25.78.98 respectivamente, que nos informa que a AD, ou seja a distância administrativa é igual a 1, que é o valor padrão para quando se configura rotas estáticas, com uma métrica igual a 0.
Sendo este um assunto mais complexo, não o vamos abordar nesta apresentação, pois teriamos de apresentar vários cálculos para podermos chegar a uma entendimento aceitável, porém neste momento o que é podemos referir é que a distância administrativa mais baixa, associado à métrica mais baixa, normalmente é a aceite pelo router, mas nem sempre se pode verificar esta analogia de comparações.
Para o nosso teste de simulação, efetuamos de novo um PING e observamos que o caminho mais curto, agora era sempre o escolhido, finalizando aqui esta nossa abordagem de rotas estáticas.
Figura 4.1 – Pacote ICMP enviado da rede 201.25.78.64 / 28 para 201.25.78.48 / 28 após modificação de tabela de roteamento estático
Carlos M.S. Rodrigues
39
2.4 ROTEAMENTO DE ROTAS DEFAULT
Depois de abordarmos as rotas estáticas e estar tudo a funcionar correctamente, a configuração de uma rota “default” pode parecer não se aplicar a nosso esquema de roteamento.
Contudo e embora neste momento todos os pacotes saibam sair da sua sub-rede e alcançar as redes de destino para as quais são enviados, se pensarmos que basta um pacote ter no cabeçalho do IP de destino, uma rota diferente de todas as que estão configuradas nas tabelas de roteamento estaticamente, para entendermos a importância deste ponto 2.4, na apresentação.
Como dificilmente uma topologia é fixa todo o tempo, ainda para mais uma baseada na que estamos a apresentar, onde se insere uma empresa com acesso direto à internet, é de extrema importância que uma rota padrão seja configurada, para tal, o seguinte comando foi inserido em todos os roteadores, conforme se segue: Router(config)#Ip route 0.0.0.0 0.0.0.0 <interface>
Por <interface> entenda-se o dispositivo que fornece a saída da rede, se imaginarmos que um pacote tráfega, sentido da esquerda para a direita, via modem ADSL. Assim deste modo, esta rota “default” configurada em todos os roteadores, permite existir comunicações com outras redes e infraestruturas na Internet, sem que o pacote seja descartado, pois a rota padrão sempre vai encaminhar o pacote para o roteador R6 que está diretamente ligado com a Internet.
Para descrevermos a rede que não consta na topologia proposta, vamos apresentar a Fig. 4.2.
Carlos M.S. Rodrigues
40
Figura 4.2 – Rede simbólica que pretende representar o ISP da empresa
Para esta configuração utilizamos mais uma sub-rede para endereçar o interface fa0/1 ao router do provedor de serviço de internet, com o “hostname” ROUTER-ISP, conforme tabela em baixo.
Rede
IP Inicial
IP Final
“Bits” Octeto 4
ISP - 201.25.78.120 / 28
201.25.78.121
201.25.78.122
11111100 - .252
Rede utilizada
Carlos M.S. Rodrigues
41
Sendo que a tabela do router R6 sofreu uma ligeira alteração para manifestar esta alteração, como se pode visualizar na Fig. 4.3. Router R6 (Route table)
Figura 4.3 – tabela de rotas em roteador R6 após inserção de rota default
Por sua vez o roteador do ISP, de “hostname” ROUTER-ISP, como nesta apresentação não tem nenhuma aplicação específica, nem existe nenhuma consideração especial sobre o mesmo, apenas foi configurado uma rota “default”, afim de fornecer conectividade com o resto das sub-redes da topologia lógica.
Ficando a tabela de roteamento do ISP, com o seguinte aspecto:
Carlos M.S. Rodrigues
42
Router ROUTER-ISP (Route table)
Figura 4.4 – tabela de rotas em roteador ROUTER-ISP
Podemos observar que para este roteador, basta possuir as rotas que ele interliga, mais uma rota “default”, para estabelecer conectividade sem problemas, isto porque depois do pacote chegar ao router R6, o pacote ao ser analisado é encaminhado para o seu IP de destino, pois este router tem configurado nele todas as rotas estáticas da topologia apresentada, podemos assim concluir que este router, seria o roteador de borda que separa a empresa da Internet.
Neste router, seriam configuradas listas de controlo de acesso (ACL´s), serviço de NAT (Network Address Translation) e políticas de segurança e firewall, porém como nesta apresentação estes conceitos saem totalmente do escopo da análise de rede, estes temas não seram abordados. Para se concluir o ponto 2.4, vamos visualizar alguns pacotes ICMP enviados do computador ,de nome “Internet Client”, para as sub-redes da empresa.
Com as Fig.4.5 e 4.6, podemos concluir que todas as sub-redes da empresas são alcançadas com sucesso e não existe nenhum erro de configuração.
Carlos M.S. Rodrigues
43
Figura 4.5 – Pacote ICMP enviado da Internet para PC7, PC9 e PC11
Figura 4.6 – Pacote ICMP enviado da Internet para PC1, PC3 e PC5
2.5 SERVIÇO DE DHCP
Para o endereçamento de todas as sub-redes, com excepção da rede 201.25.78.96 / 29, 201.25.78.104 / 30, 201.25.78.108 / 30, 201.25.78.108 / 30 e 201.25.78.100 / 30, foram configurados servidores de DHCP (Dynamic Host Configuration Protocol) de forma a atribuir IP´s dinâmicamente a todos os PC´s das sub-redes respectivas.
Na rede 201.25.78.96 / 29, foram colocados 2 servidores de DHCP para atender os clientes de DHCP, das sub-redes 201.25.78.80 /28 e 201.25.78.80 / 28, cada subrede deve atender 13 clientes por rede, a Microsoft recomenda o seguinte:
“Você pode usar a regra de design 80/20 para equilibrar a distribuição do escopo de endereços, onde vários servidores DHCP são implantados para atender o mesmo escopo.
Usando mais de um servidor DHCP na mesma sub-rede, fornece maior tolerância a falhas para atender a clientes DHCP localizados nela. Com dois servidores DHCP,
Carlos M.S. Rodrigues
44
se um servidor estiver indisponível, o outro servidor pode tomar o seu lugar e continuar a alocar novos endereços ou renovar clientes existentes.
Uma prática comum quando o balanceamento de uma única rede e faixa de escopo de endereços entre dois servidores DHCP é ter 80 por cento dos endereços distribuídos por um servidor DHCP e os 20 por cento restantes fornecido por um segundo.”
Vale lembrar que esta recomendação é de à 10 anos atrás, sendo este modelo mais apropriado, quando se implamentava um servidor DHCP em um escritório remoto com largura de banda limitada e um outro servidor DHCP no escritório principal.
Hoje em dia o mais normal é se configurar 2 servidores, 1 redundante ao outro, para balanceamento de cargas e “fault tolerance” , numa prespectiva de 50 / 50.
Isto garante por si só, que se um dos servidores falhar, o outro assume de imediato, a atribuição de IP´s novos ou a renovação de antigos clientes da rede.
Durante o tempo de falha, conceito conhecido como MTTR (Mean Time To Repair), verificado em um dos servidores, é possível garantir o serviço no outro e nenhum cliente ficar sem conectividade com a sua rede de trabalho, logo que o outro servidor esteja de novo operacional na rede, toda a estrutura fica de novo operacional 100 por cento. De seguida nas Fig. 4.7 e Fig. 4.8, vamos apresentar as “scopes” criadas em ambos os servidores com o nome, DHCP1 e DHCP2. Para os nomes dos escopos seguimos uma política que identifica-se o nome da “pool” à sub-rede em questão.
Carlos M.S. Rodrigues
45
Figura 4.7 – Servidor DHCP1 com 2 escopos activos
Figura 4.8 – Servidor DHCP2 com 2 escopos activos
Carlos M.S. Rodrigues
46
Podemos observar que os escopos são referentes às sub-redes 201.25.78.64 / 28 e 201.25.78.64 / 28, no entanto os servidores estão fora das redes respectivas, sendo o protocolo DHCP majoritariamente um pacote “broadcast”, tivemos de fazer uns ajustes e configurações nos roteadores R5 e R6 para o protocolo ficar a funcionar correctamente, para tal os seguintes comandos foram inseridos em modo de configuração global, como apresentado em baixo:
Na interface fa0/1 do roteador R5
R5(config)#ip helper-address 201.25.78.100 R5(config)#ip helper-address 201.25.78.101
Na interface fa0/0 do roteador R6 R6(config)#ip helper-address 201.25.78.100 R6(config)#ip helper-address 201.25.78.101 Este commando “ip helper-address”, faz o encaminhamento do pacote “broadcast” em “unicast”, para 8 diferente portas UDP (User Datagram Protocol), por padrão:
TFTP (porta 69)
DNS (porta 53)
Time Service (porta 37)
NetBIOS name server (port 137)
NetBIOS datagram server (porta 138)
Boot Protocol (BOOTP) cliente e servidor (portas UDP 67 e 68)
TACACS service (porta 49)
Por motivos de segurança é aconselhável após a configuração deste comando, se utilizar o comando em baixo, para fechar as portas que não vão ser utilizadas na rede, afim de se eliminar possíveis vulnerabilidades:
Carlos M.S. Rodrigues
47
Router(config)#no ip forward-protocol udp <porta>
Em <porta> deve-se colocar um dos números de portas mencionados em cima.
Como o tema de segurança não foi abordado nesta apresentação, não vamos fazer essa configuração especial, embora o simulador packet tracer da CISCO, permita a configuração deste requisito.
De volta às configurações dos servidores de DHCP e ainda na sub-rede 201.25.78.96 / 29, podemos verificar que existe um terceiro servidor de DHCP, este servidor apenas vai entrar em funcionamento se um dos quatro servidores que se encontram nas sub-redes localmente deixarem de funcionar por algum motivo, em baixo apresenta-se as “scopes” que são oferecidas por ele:
Figura 4.9 – Servidor DHCPbackup com 4 escopos activos
Carlos M.S. Rodrigues
48
Agora passamos a análise das quatro sub-redes restantes, a começar pela 201.25.78.0 / 28, depois a 201.25.78.16 / 28, 201.25.78.32 / 28 e 201.25.78.48 / 28, respectivamente.
Figura 5.0 – Servidor DHCP3 que atende na sub-rede 201.25.78.0 / 28
Figura 5.1 – Servidor DHCP4 que atende na sub-rede 201.25.78.16 / 28
Carlos M.S. Rodrigues
49
Figura 5.2 – Servidor DHCP5 que atende na sub-rede 201.25.78.32 / 28
Figura 5.3 – Servidor DHCP6 que atende na sub-rede 201.25.78.48 / 28
Carlos M.S. Rodrigues
50
Cada um destes servidores atendem localmente os seus clientes de DHCP e cada um só tem uma “scope” configurada. Se um destes servidores deixar de funcionar, os clientes podem ser servidos pelo “DHCPbackup” que já tivemos a oportunidade de o descrever.
Faltando apenas neste momento, configurar uma linha de comando nos quatro roteadores destas sub-redes, para este “backup” de endereços dinâmicos ficarem salvaguardados, ver comandos em baixo, para R1, R2, R3 e R4:
Na interface fa0/0 do roteador R1 R5(config)#ip helper-address 201.25.78.102
Na interface fa0/0 do roteador R2 R5(config)#ip helper-address 201.25.78.102
Na interface fa0/1 do roteador R3 R5(config)#ip helper-address 201.25.78.102
Na interface fa0/1 do roteador R4
R5(config)#ip helper-address 201.25.78.102
Depois de se configurar todos os servidores de DHCP correctamente, é a vez de se activar nas propriedades dos PC´s clientes o serviço de DHCP,
como se pode
verificar no exemplo da imagem em baixo:
Carlos M.S. Rodrigues
51
Figura 5.4 â&#x20AC;&#x201C; Computador PC5 na sub-rede 201.25.78.32 / 28
Carlos M.S. Rodrigues
52
CONCLUSÃO OU CONSIDERAÇÕES FINAIS
Este teste piloto apresentado por meio de simulador packet tracer da CISCO, ajudou a demonstrar como uma rede empresarial pode funcionar, quando se tem apenas uma faixa de endereçamentos de IP´s disponíveis e não se pode desperdiçar nenhum IP válido, além de que, demostrou como servidores de DHCP podem ser configurados e alocados na rede, afim de servirem os clientes de forma transparente e fácil. Foi também possível, verificar a configuração de vários comandos nos roteadores que iam bastante além da proposta apresentada, mas que ajudaram a criar uma rede sólida, sem erros de funcionamento e apta para entrar em produção.
É necessário fazer uma chamada de atenção, pois embora a rede pode-se teoricamente ser implementada, nenhum aspecto a nível de segurança de redes foi configurado e o serviço de NAT (Network Address Translation) não foi implementado, o que tornaria os clientes vulneráveis na internet, até porque o endereçamento proposto tinha precisamente o requesito de ter IP´s públicos e não privados, logo para atender às necessidades apresentadas, foi necessário fazer uma “série” de considerações e de assumir um risco cálculado.
Por outro lado também podemos verificar que a administração de rotas estáticas é considerado “time cosuming”, pois leva imenso tempo a serem planejadas e especialmente a serem administradas, pois qualquer alteração tem que ser realizado manualmente, pórem a nível de segurança uma rota estática fornece uma maior segurança ao administrador, pois um usuário mal intencionado pode introduzir um roteador na rede e realizar um “routing update” de forma a “envenenar” o roteamento, para uma determinada sub-rede, ou desviar o tráfego para ser analisado à posterior. Esta forma de ataque “man-in-the-middle” pode ser utilizado com rotas dinâmicas, mas nunca com rotas estáticas. Por outro lado podemos considerar que o roteamento estático fornece menos segurança na óptica de uma alteração da rede,
Carlos M.S. Rodrigues
53
mas penso que aqui o problema não é uma questão de segurança de redes mas sim de administração, contudo este tipo de roteamento só se verifica em redes de pequeno porte e nunca em redes de elevado porte, pois seria impossível alterar rotas de missões críticas em um espaço de tempo aceitável para cumprir com obrigações e contratos de serviço (SLA).
Carlos M.S. Rodrigues
REFERÊNCIAS
KUROSE, James F. e ROSS, Keith W. Redes de Computadores e a Internet: uma abordagem top-down, 5. ed., São Paulo: Addison Wesley, 2010. TANENBAUM, Andrew S. Redes de Computadores, 4.ed., Rio de Janeiro, 2003 SAMUEL H.B. BRITO, Laboratórios de Tecnologias CISCO em Infraestruturas de Redes, Novatec, 2014. WENDELL ODOM, Guia oficial de Certificações, CCENT/CCNA ICND1, ciscopress.com, 2014. WENDELL ODOM, Official Certification Guide, CCNP ROUTE 642-902, ciscopress.com, 2012. CISCO ACADEMY CCNA discovery CISCO ACADEMY CCNA exploration CISCO ACADEMY CCNP v5.0
Carlos M.S. Rodrigues
IP Addressing and Subnetting for New Users Document ID: 13788
Contents Introduction Prerequisites Requirements Components Used Additional Information Conventions Understanding IP Addresses Network Masks Understanding Subnetting Examples Sample Exercise 1 Sample Exercise 2 VLSM Example VLSM Example CIDR Appendix Sample Config Host/Subnet Quantities Table Related Information
Introduction This document gives you basic information needed in order to configure your router for routing IP, such as how addresses are broken down and how subnetting works. You learn how to assign each interface on the router an IP address with a unique subnet. There are many examples to help tie everything together.
Prerequisites Requirements Cisco recommends that you have knowledge of these topics: • Basic understanding of binary and decimal numbers.
Components Used This document is not restricted to specific software and hardware versions.
Additional Information If definitions are helpful to you, use these vocabulary terms to get you started: • AddressThe unique number ID assigned to one host or interface in a network. • SubnetA portion of a network sharing a particular subnet address. • Subnet maskA 32−bit combination used to describe which portion of an address refers to the subnet
and which part refers to the host. • InterfaceA network connection. If you have already received your legitimate address(es) from the Internet Network Information Center (InterNIC), you are ready to begin. If you do not plan to connect to the Internet, Cisco strongly suggests that you use reserved addresses from RFC 1918 .
Conventions Refer to Cisco Technical Tips Conventions for more information on document conventions.
Understanding IP Addresses An IP address is an address used in order to uniquely identify a device on an IP network. The address is made up of 32 binary bits, which can be divisible into a network portion and host portion with the help of a subnet mask. The 32 binary bits are broken into four octets (1 octet = 8 bits). Each octet is converted to decimal and separated by a period (dot). For this reason, an IP address is said to be expressed in dotted decimal format (for example, 172.16.81.100). The value in each octet ranges from 0 to 255 decimal, or 00000000 − 11111111 binary. Here is how binary octets convert to decimal: The right most bit, or least significant bit, of an octet holds a value of 20. The bit just to the left of that holds a value of 21. This continues until the left−most bit, or most significant bit, which holds a value of 27. So if all binary bits are a one, the decimal equivalent would be 255 as shown here: 1 1 1 1 1 1 1 1 128 64 32 16 8 4 2 1 (128+64+32+16+8+4+2+1=255)
Here is a sample octet conversion when not all of the bits are set to 1. 0 1 0 0 0 0 0 1 0 64 0 0 0 0 0 1 (0+64+0+0+0+0+0+1=65)
And this is sample shows an IP address represented in both binary and decimal. 10. 1. 23. 19 (decimal) 00001010.00000001.00010111.00010011 (binary)
These octets are broken down to provide an addressing scheme that can accommodate large and small networks. There are five different classes of networks, A to E. This document focuses on addressing classes A to C, since classes D and E are reserved and discussion of them is beyond the scope of this document. Note: Also note that the terms "Class A, Class B" and so on are used in this document to help facilitate the understanding of IP addressing and subnetting. These terms are rarely used in the industry anymore because of the introduction of classless interdomain routing (CIDR). Given an IP address, its class can be determined from the three high−order bits. Figure 1 shows the significance in the three high order bits and the range of addresses that fall into each class. For informational purposes, Class D and Class E addresses are also shown. Figure 1
In a Class A address, the first octet is the network portion, so the Class A example in Figure 1 has a major network address of 1.0.0.0 − 127.255.255.255. Octets 2, 3, and 4 (the next 24 bits) are for the network manager to divide into subnets and hosts as he/she sees fit. Class A addresses are used for networks that have more than 65,536 hosts (actually, up to 16777214 hosts!). In a Class B address, the first two octets are the network portion, so the Class B example in Figure 1 has a major network address of 128.0.0.0 − 191.255.255.255. Octets 3 and 4 (16 bits) are for local subnets and hosts. Class B addresses are used for networks that have between 256 and 65534 hosts. In a Class C address, the first three octets are the network portion. The Class C example in Figure 1 has a major network address of 192.0.0.0 − 233.255.255.255. Octet 4 (8 bits) is for local subnets and hosts − perfect for networks with less than 254 hosts.
Network Masks A network mask helps you know which portion of the address identifies the network and which portion of the address identifies the node. Class A, B, and C networks have default masks, also known as natural masks, as shown here: Class A: 255.0.0.0 Class B: 255.255.0.0 Class C: 255.255.255.0
An IP address on a Class A network that has not been subnetted would have an address/mask pair similar to: 8.20.15.1 255.0.0.0. To see how the mask helps you identify the network and node parts of the address, convert the address and mask to binary numbers. 8.20.15.1 = 00001000.00010100.00001111.00000001 255.0.0.0 = 11111111.00000000.00000000.00000000
Once you have the address and the mask represented in binary, then identifying the network and host ID is easier. Any address bits which have corresponding mask bits set to 1 represent the network ID. Any address bits that have corresponding mask bits set to 0 represent the node ID. 8.20.15.1 = 00001000.00010100.00001111.00000001 255.0.0.0 = 11111111.00000000.00000000.00000000 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− net id | host id netid = 00001000 = 8 hostid = 00010100.00001111.00000001 = 20.15.1
Understanding Subnetting Subnetting allows you to create multiple logical networks that exist within a single Class A, B, or C network. If you do not subnet, you are only able to use one network from your Class A, B, or C network, which is unrealistic. Each data link on a network must have a unique network ID, with every node on that link being a member of the same network. If you break a major network (Class A, B, or C) into smaller subnetworks, it allows you to create a network of interconnecting subnetworks. Each data link on this network would then have a unique network/subnetwork ID. Any device, or gateway, connecting n networks/subnetworks has n distinct IP addresses, one for each network / subnetwork that it interconnects. In order to subnet a network, extend the natural mask using some of the bits from the host ID portion of the address to create a subnetwork ID. For example, given a Class C network of 204.17.5.0 which has a natural mask of 255.255.255.0, you can create subnets in this manner: 204.17.5.0 − 11001100.00010001.00000101.00000000 255.255.255.224 − 11111111.11111111.11111111.11100000 −−−−−−−−−−−−−−−−−−−−−−−−−−|sub|−−−−
By extending the mask to be 255.255.255.224, you have taken three bits (indicated by "sub") from the original host portion of the address and used them to make subnets. With these three bits, it is possible to create eight subnets. With the remaining five host ID bits, each subnet can have up to 32 host addresses, 30 of which can actually be assigned to a device since host ids of all zeros or all ones are not allowed (it is very important to remember this). So, with this in mind, these subnets have been created. 204.17.5.0 255.255.255.224 204.17.5.32 255.255.255.224 204.17.5.64 255.255.255.224 204.17.5.96 255.255.255.224 204.17.5.128 255.255.255.224 204.17.5.160 255.255.255.224 204.17.5.192 255.255.255.224 204.17.5.224 255.255.255.224
host host host host host host host host
address address address address address address address address
range range range range range range range range
1 to 30 33 to 62 65 to 94 97 to 126 129 to 158 161 to 190 193 to 222 225 to 254
Note: There are two ways to denote these masks. First, since you are using three bits more than the "natural" Class C mask, you can denote these addresses as having a 3−bit subnet mask. Or, secondly, the mask of 255.255.255.224 can also be denoted as /27 as there are 27 bits that are set in the mask. This second method is used with CIDR. With this method, one of these networks can be described with the notation prefix/length. For example, 204.17.5.32/27 denotes the network 204.17.5.32 255.255.255.224. When appropriate the prefix/length notation is used to denote the mask throughout the rest of this document. The network subnetting scheme in this section allows for eight subnets, and the network might appear as: Figure 2
Notice that each of the routers in Figure 2 is attached to four subnetworks, one subnetwork is common to both routers. Also, each router has an IP address for each subnetwork to which it is attached. Each subnetwork could potentially support up to 30 host addresses. This brings up an interesting point. The more host bits you use for a subnet mask, the more subnets you have available. However, the more subnets available, the less host addresses available per subnet. For example, a Class C network of 204.17.5.0 and a mask of 255.255.255.224 (/27) allows you to have eight subnets, each with 32 host addresses (30 of which could be assigned to devices). If you use a mask of 255.255.255.240 (/28), the break down is: 204.17.5.0 − 11001100.00010001.00000101.00000000 255.255.255.240 − 11111111.11111111.11111111.11110000 −−−−−−−−−−−−−−−−−−−−−−−−−−|sub |−−−
Since you now have four bits to make subnets with, you only have four bits left for host addresses. So in this case you can have up to 16 subnets, each of which can have up to 16 host addresses (14 of which can be assigned to devices). Take a look at how a Class B network might be subnetted. If you have network 172.16.0.0 ,then you know that its natural mask is 255.255.0.0 or 172.16.0.0/16. Extending the mask to anything beyond 255.255.0.0 means you are subnetting. You can quickly see that you have the ability to create a lot more subnets than with the Class C network. If you use a mask of 255.255.248.0 (/21), how many subnets and hosts per subnet does this allow for? 172.16.0.0 − 10101100.00010000.00000000.00000000 255.255.248.0 − 11111111.11111111.11111000.00000000 −−−−−−−−−−−−−−−−−| sub |−−−−−−−−−−−
You are using five bits from the original host bits for subnets. This allows you to have 32 subnets (25). After using the five bits for subnetting, you are left with 11 bits for host addresses. This allows each subnet so have 2048 host addresses (211), 2046 of which could be assigned to devices. Note: In the past, there were limitations to the use of a subnet 0 (all subnet bits are set to zero) and all ones subnet (all subnet bits set to one). Some devices would not allow the use of these subnets. Cisco Systems devices allow the use of these subnets when theip subnet zero command is configured.
Examples Sample Exercise 1 Now that you have an understanding of subnetting, put this knowledge to use. In this example, you are given two address / mask combinations, written with the prefix/length notation, which have been assigned to two devices. Your task is to determine if these devices are on the same subnet or different subnets. You can do this
by using the address and mask of each device to determine to which subnet each address belongs. DeviceA: 172.16.17.30/20 DeviceB: 172.16.28.15/20
Determining the Subnet for DeviceA: 172.16.17.30 − 255.255.240.0 − subnet =
10101100.00010000.00010001.00011110 11111111.11111111.11110000.00000000 −−−−−−−−−−−−−−−−−| sub|−−−−−−−−−−−− 10101100.00010000.00010000.00000000 = 172.16.16.0
Looking at the address bits that have a corresponding mask bit set to one, and setting all the other address bits to zero (this is equivalent to performing a logical "AND" between the mask and address), shows you to which subnet this address belongs. In this case, DeviceA belongs to subnet 172.16.16.0. Determining the Subnet for DeviceB: 172.16.28.15 − 255.255.240.0 − subnet =
10101100.00010000.00011100.00001111 11111111.11111111.11110000.00000000 −−−−−−−−−−−−−−−−−| sub|−−−−−−−−−−−− 10101100.00010000.00010000.00000000 = 172.16.16.0
From these determinations, DeviceA and DeviceB have addresses that are part of the same subnet.
Sample Exercise 2 Given the Class C network of 204.15.5.0/24, subnet the network in order to create the network in Figure 3 with the host requirements shown. Figure 3
Looking at the network shown in Figure 3, you can see that you are required to create five subnets. The largest subnet must support 28 host addresses. Is this possible with a Class C network? and if so, then how? You can start by looking at the subnet requirement. In order to create the five needed subnets you would need to use three bits from the Class C host bits. Two bits would only allow you four subnets (22). Since you need three subnet bits, that leaves you with five bits for the host portion of the address. How many hosts does this support? 25 = 32 (30 usable). This meets the requirement. Therefore you have determined that it is possible to create this network with a Class C network. An example of how you might assign the subnetworks is: netA: 204.15.5.0/27 netB: 204.15.5.32/27 netC: 204.15.5.64/27
host address range 1 to 30 host address range 33 to 62 host address range 65 to 94
netD: 204.15.5.96/27 netE: 204.15.5.128/27
host address range 97 to 126 host address range 129 to 158
VLSM Example In all of the previous examples of subnetting, notice that the same subnet mask was applied for all the subnets. This means that each subnet has the same number of available host addresses. You can need this in some cases, but, in most cases, having the same subnet mask for all subnets ends up wasting address space. For example, in the Sample Exercise 2 section, a class C network was split into eight equalâ&#x2C6;&#x2019;size subnets; however, each subnet did not utilize all available host addresses, which results in wasted address space. Figure 4 illustrates this wasted address space. Figure 4
Figure 4 illustrates that of the subnets that are being used, NetA, NetC, and NetD have a lot of unused host address space. It is possible that this was a deliberate design accounting for future growth, but in many cases this is just wasted address space due to the fact that the same subnet mask is being used for all the subnets. Variable Length Subnet Masks (VLSM) allows you to use different masks for each subnet, thereby using address space efficiently.
VLSM Example Given the same network and requirements as in Sample Exercise 2 develop a subnetting scheme with the use of VLSM, given:
netA: netB: netC: netD: netE:
must must must must must
support support support support support
14 hosts 28 hosts 2 hosts 7 hosts 28 host
Determine what mask allows the required number of hosts. netA: requires a /28 (255.255.255.240) mask to support 14 hosts netB: requires a /27 (255.255.255.224) mask to support 28 hosts netC: requires a /30 (255.255.255.252) mask to support 2 hosts netD*: requires a /28 (255.255.255.240) mask to support 7 hosts netE: requires a /27 (255.255.255.224) mask to support 28 hosts * a /29 (255.255.255.248) would only allow 6 usable host addresses therefore netD requires a /28 mask.
The easiest way to assign the subnets is to assign the largest first. For example, you can assign in this manner: netB: netE: netA: netD: netC:
204.15.5.0/27 204.15.5.32/27 204.15.5.64/28 204.15.5.80/28 204.15.5.96/30
host host host host host
address address address address address
range range range range range
1 to 30 33 to 62 65 to 78 81 to 94 97 to 98
This can be graphically represented as shown in Figure 5: Figure 5
Figure 5 illustrates how using VLSM helped save more than half of the address space.
CIDR Classless Interdomain Routing (CIDR) was introduced to improve both address space utilization and routing scalability in the Internet. It was needed because of the rapid growth of the Internet and growth of the IP routing tables held in the Internet routers. CIDR moves way from the traditional IP classes (Class A, Class B, Class C, and so on). In CIDR , an IP network is represented by a prefix, which is an IP address and some indication of the length of the mask. Length means the number of left竏知ost contiguous mask bits that are set to one. So network 172.16.0.0 255.255.0.0 can be represented as 172.16.0.0/16. CIDR also depicts a more hierarchical Internet architecture, where each domain takes its IP addresses from a higher level. This allows for the summarization of the domains to be done at the higher level. For example, if an ISP owns network 172.16.0.0/16, then the ISP can offer 172.16.1.0/24, 172.16.2.0/24, and so on to customers. Yet, when advertising to other providers, the ISP only needs to advertise 172.16.0.0/16. For more information on CIDR, see RFC 1518
and RFC 1519
.
Appendix Sample Config Routers A and B are connected via serial interface. Router A hostname routera ! ip routing ! int e 0 ip address 172.16.50.1 255.255.255.0 !(subnet 50) int e 1 ip address 172.16.55.1 255.255.255.0 !(subnet 55) int t 0 ip address 172.16.60.1 255.255.255.0 !(subnet 60) int s 0 ip address 172.16.65.1 255.255.255.0 (subnet 65) !S 0 connects to router B router rip network 172.16.0.0
Router B hostname routerb ! ip routing ! int e 0 ip address 192.1.10.200 255.255.255.240 !(subnet 192) int e 1 ip address 192.1.10.66 255.255.255.240 !(subnet 64) int s 0 ip address 172.16.65.2 (same subnet as router A's s 0) !Int s 0 connects to router A router rip network 192.1.10.0
network 172.16.0.0
Host/Subnet Quantities Table Class B # bits −−−−−−− 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Mask −−−−−−−−−−−−−−− 255.255.128.0 255.255.192.0 255.255.224.0 255.255.240.0 255.255.248.0 255.255.252.0 255.255.254.0 255.255.255.0 255.255.255.128 255.255.255.192 255.255.255.224 255.255.255.240 255.255.255.248 255.255.255.252
Effective Subnets −−−−−−−−− 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384
Effective Hosts −−−−−−−−− 32766 16382 8190 4094 2046 1022 510 254 126 62 30 14 6 2
Class C # bits −−−−−−− 1 2 3 4 5 6
Mask −−−−−−−−−−−−−−− 255.255.255.128 255.255.255.192 255.255.255.224 255.255.255.240 255.255.255.248 255.255.255.252
Effective Subnets −−−−−−−−− 2 4 8 16 32 64
Effective Hosts −−−−−−−−− 126 62 30 14 6 2
*Subnet all zeroes and all ones included. These might not be supported on some legacy systems. *Host all zeroes and all ones excluded.
Related Information • IP Subnet Calculator (registered customers only) • IP Routing Protocols Technology Support • Subnet Zero and the All−Ones Subnet • Host and Subnet Quantities • Technical Support & Documentation − Cisco Systems
Contacts & Feedback | Help | Site Map © 2012 − 2013 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of Cisco Systems, Inc.
Updated: Sep 26, 2005
Document ID: 13788
What Is Administrative Distance? Document ID: 15986
Contents Introduction Prerequisites Requirements Components Used Conventions Select the Best Path Default Distance Value Table Other Applications of Administrative Distance Related Information
Introduction Most routing protocols have metric structures and algorithms that are not compatible with other protocols. In a network with multiple routing protocols, the exchange of route information and the capability to select the best path across the multiple protocols are critical. Administrative distance is the feature that routers use in order to select the best path when there are two or more different routes to the same destination from two different routing protocols. Administrative distance defines the reliability of a routing protocol. Each routing protocol is prioritized in order of most to least reliable (believable) with the help of an administrative distance value.
Prerequisites Requirements Cisco recommends that you have knowledge of these topics: â&#x20AC;˘ Basics of the routing process. Refer to Routing Basics.
Components Used This document is not restricted to specific software and hardware versions.
Conventions Refer to Cisco Technical Tips Conventions for more information on document conventions.
Select the Best Path Administrative distance is the first criterion that a router uses to determine which routing protocol to use if two protocols provide route information for the same destination. Administrative distance is a measure of the trustworthiness of the source of the routing information. Administrative distance has only local significance, and is not advertised in routing updates.
Note: The smaller the administrative distance value, the more reliable the protocol. For example, if a router receives a route to a certain network from both Open Shortest Path First (OSPF) (default administrative distance − 110) and Interior Gateway Routing Protocol (IGRP) (default administrative distance − 100), the router chooses IGRP because IGRP is more reliable. This means the router adds the IGRP version of the route to the routing table. If you lose the source of the IGRP−derived information (for example, due to a power shutdown), the software uses the OSPF−derived information until the IGRP−derived information reappears.
Default Distance Value Table This table lists the administrative distance default values of the protocols that Cisco supports: Default Distance Values
Route Source
Connected interface Static route Enhanced Interior Gateway Routing Protocol (EIGRP) summary route External Border Gateway Protocol (BGP) Internal EIGRP IGRP OSPF Intermediate System−to−Intermediate System (IS−IS) Routing Information Protocol (RIP) Exterior Gateway Protocol (EGP) On Demand Routing (ODR) External EIGRP Internal BGP Unknown*
0 1 5 20 90 100 110 115 120 140 160 170 200 255
* If the administrative distance is 255, the router does not believe the source of that route and does not install the route in the routing table. When you use route redistribution, occasionally you need to modify the administrative distance of a protocol so that it takes precedence. For example, if you want the router to select RIP−learned routes (default value 120) rather than IGRP−learned routes (default value 100) to the same destination, you must increase the administrative distance for IGRP to 120+, or decrease the administrative distance of RIP to a value less than 100. You can modify the administrative distance of a protocol through the distance command in the routing process subconfiguration mode. This command specifies that the administrative distance is assigned to the routes learned from a particular routing protocol. You need to use this procedure generally when you migrate the network from one routing protocol to another, and the latter has a higher administrative distance. However, a change in the administrative distance can lead to routing loops and black holes. So, use caution if
you change the administrative distance. Here is an example that shows two routers, R1 and R2, connected through Ethernet. The loopback interfaces of the routers are also advertised with RIP and IGRP on both the routers. You can observe that the IGRP routes are preferred over the RIP routes in the routing table because the administrative distance is 100. R1#show ip route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 1 subnets C 172.16.1.0 is directly connected, Ethernet0 I 10.0.0.0/8 [100/1600] via 172.16.1.200, 00:00:01, Ethernet0 C 192.168.1.0/24 is directly connected, Loopback0 R2#show ip route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 1 subnets C 172.16.1.0 is directly connected, Ethernet0 C 10.0.0.0/8 is directly connected, Loopback0 I 192.168.1.0/24 [100/1600] via 172.16.1.100, 00:00:33,
In order to enable the router to prefer RIP routes to IGRP, configure the distance command on R1 like this: R1(config)#router rip R1(configâ&#x2C6;&#x2019;router)#distance 90
Now look at the routing table. The routing table shows that the router prefers the RIP routes. The router learns RIP routes with an administrative distance of 90, although the default is 120. Note that the new administrative distance value is relevant only to the routing process of a single router (in this case R1). R2 still has IGRP routes in the routing table. R1#show ip route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 1 subnets C 172.16.1.0 is directly connected, Ethernet0 R 10.0.0.0/8 [90/1] via 172.16.1.200, 00:00:16, Ethernet0 C 192.168.1.0/24 is directly connected, Loopback0 R2#show ip route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 1 subnets C 172.16.1.0 is directly connected, Ethernet0 C 10.0.0.0/8 is directly connected, Loopback0 I 192.168.1.0/24 [100/1600] via 172.16.1.100, 00:00:33,
There are no general guidelines to assign administrative distances because each network has varied requirements. You must determine a reasonable matrix of administrative distances for the network as a whole.
Other Applications of Administrative Distance One common reason to change the administrative distance of a route is when you use Static Routes to backup and existing IGP route. This is normally used to bring up a backup link when the primary fails.
For example, assume that you use the routing table from R1. However, in this case, there is also an ISDN line that you can use as a backup if the primary connection fails. Here is an example of a Floating Static for this route: ip route 10.0.0.0 255.0.0.0 Dialer 1 250 !−−− Note: The Administrative Distance is set to 250.
If the Ethernet interfaces fail, or if you manually bring down the Ethernet interfaces, the floating static route is installed into the routing table. All traffic destined for the 10.0.0.0/8 network is then routed out of the Dialer 1 interface and over the backup link. The routing table appears similar to this after the failure: R1#show ip route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 1 subnets C 172.16.1.0 is directly connected, Ethernet0 S 10.0.0.0/8 is directly connected, Dialer1 C 192.168.1.0/24 is directly connected, Loopback0
For more detailed information on the use of Floating Static routes, refer to these documents: • Using Floating Static Routes and Dial−on−Demand routing • Configuring ISDN Back With Floating Statics • Evaluating Backup Interfaces, Floating Static Routes, and Dialer Watch for DDR Backup
Related Information • Configuring IP Routing Protocols • Route Selection in Cisco Routers • IP Routing Support Page • IP Routed Protocols Support Page • Technical Support & Documentation − Cisco Systems
Contacts & Feedback | Help | Site Map © 2012 − 2013 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of Cisco Systems, Inc.
Updated: May 08, 2013
Document ID: 15986
Configuring a Gateway of Last Resort Using IP Commands Document ID: 16448
Contents Introduction Prerequisites Requirements Components Used Conventions ip default−gateway ip default−network Flag a Default Network Use Different Routing Protocols ip route 0.0.0.0 0.0.0.0 Summary Related Information
Introduction Default routes are used to direct packets addressed to networks not explicitly listed in the routing table. Default routes are invaluable in topologies where learning all the more specific networks is not desirable, as in case of stub networks, or not feasible due to limited system resources such as memory and processing power. This document explains how to configure a default route, or gateway of last resort. These IP commands are used: • ip default−gateway • ip default−network • and ip route 0.0.0.0 0.0.0.0
Prerequisites Requirements There are no specific requirements for this document.
Components Used This document is not restricted to specific software and hardware versions. The command outputs shown are from the Cisco 2500 Series routers running Cisco IOS® Software Release 12.2(24a). The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
Conventions For more information on document conventions, see the Cisco Technical Tips Conventions.
ip default−gateway The ip default−gateway command differs from the other two commands. It should only be used when ip routing is disabled on the Cisco router. For instance, if the router is a host in the IP world, you can use this command to define a default gateway for it. You might also use this command when your low end Cisco router is in boot mode in order to TFTP a Cisco IOS® Software image to the router. In boot mode, the router does not have ip routing enabled. This example defines the router on IP address 172.16.15.4 as the default route: ip default−gateway 172.16.15.4
ip default−network Unlike the ip default−gateway command, you can use ip default−network when ip routing is enabled on the Cisco router. When you configure ip default−network the router considers routes to that network for installation as the gateway of last resort on the router. For every network configured with ip default−network, if a router has a route to that network, that route is flagged as a candidate default route. This network diagram displays the routing table taken from router 2513:
2513#show ip route Codes: C − connected, S − static, I − IGRP, R − RIP, M − mobile, B − BGP D − EIGRP, EX − EIGRP external, O − OSPF, IA − OSPF inter area N1 − OSPF NSSA external type 1, N2 − OSPF NSSA external type 2 E1 − OSPF external type 1, E2 − OSPF external type 2, E − EGP i − IS−IS, su − IS−IS summary, L1 − IS−IS level−1, L2 − IS−IS level−2 ia − IS−IS inter area, * − candidate default, U − per−user static route o − ODR, P − periodic downloaded static route Gateway of last resort is not set
C C
161.44.0.0/24 is subnetted, 1 subnets 161.44.192.0 is directly connected, Ethernet0 131.108.0.0/24 is subnetted, 1 subnets 131.108.99.0 is directly connected, Serial0
S
198.10.1.0/24 [1/0] via 161.44.192.2
Note the static route to 198.10.1.0 via 161.44.192.2 and that the gateway of last resort is not set. If you configure ip default−network 198.10.1.0, the routing table changes to this: 2513#show ip route Codes: C − connected, S − static, I − IGRP, R − RIP, M − mobile, B − BGP D − EIGRP, EX − EIGRP external, O − OSPF, IA − OSPF inter area N1 − OSPF NSSA external type 1, N2 − OSPF NSSA external type 2 E1 − OSPF external type 1, E2 − OSPF external type 2, E − EGP i − IS−IS, su − IS−IS summary, L1 − IS−IS level−1, L2 − IS−IS level−2 ia − IS−IS inter area, * − candidate default, U − per−user static route o − ODR, P − periodic downloaded static route Gateway of last resort is 161.44.192.2 to network 198.10.1.0
C
161.44.0.0/24 is subnetted, 1 subnets 161.44.192.0 is directly connected, Ethernet0 131.108.0.0/24 is subnetted, 1 subnets 131.108.99.0 is directly connected, Serial0 198.10.1.0/24 [1/0] via 161.44.192.2
C S* R1# 2513#show ip protocols 2513#
The gateway of last resort is now set as 161.44.192.2. This result is independent of any routing protocol, as shown by the show ip protocols command at the bottom of the output. You can add another candidate default route by configuring another instance of ip default−network: 2513#configure terminal Enter configuration commands, one per line. End with CNTL/Z. 2513(config)#ip route 171.70.24.0 255.255.255.0 131.108.99.2 2513(config)#ip default−network 171.70.24.0 2513(config)#^Z 2513#show ip route Codes: C − connected, S − static, I − IGRP, R − RIP, M − mobile, B − BGP D − EIGRP, EX − EIGRP external, O − OSPF, IA − OSPF inter area N1 − OSPF NSSA external type 1, N2 − OSPF NSSA external type 2 E1 − OSPF external type 1, E2 − OSPF external type 2, E − EGP i − IS−IS, su − IS−IS summary, L1 − IS−IS level−1, L2 − IS−IS level−2 ia − IS−IS inter area, * − candidate default, U − per−user static route o − ODR, P − periodic downloaded static route Gateway of last resort is 161.44.192.2 to network 198.10.1.0
S S C C S*
171.70.0.0/16 is variably subnetted, 2 subnets, 2 masks 171.70.0.0/16 [1/0] via 171.70.24.0 171.70.24.0/24 [1/0] via 131.108.99.2 161.44.0.0/24 is subnetted, 1 subnets 161.44.192.0 is directly connected, Ethernet0 131.108.0.0/24 is subnetted, 1 subnets 131.108.99.0 is directly connected, Serial0 198.10.1.0/24 [1/0] via 161.44.192.2
After the ip default−network command was entered in the output above, the network was not flagged as a default network. The Flag a Default Network section explains why.
Flag a Default Network Note: The ip default−network command is classful. This means that if the router has a route to the subnet indicated by this command, it installs the route to the major net. At this point neither network has been flagged as the default network. The ip default−network command must be issued again, using the major net, in order to flag the candidate default route. 2513#configure terminal Enter configuration commands, one per line. End with CNTL/Z. 2513(config)#ip default−network 171.70.0.0 2513(config)#^Z 2513#show ip route Codes: C − connected, S − static, I − IGRP, R − RIP, M − mobile, B − BGP D − EIGRP, EX − EIGRP external, O − OSPF, IA − OSPF inter area N1 − OSPF NSSA external type 1, N2 − OSPF NSSA external type 2 E1 − OSPF external type 1, E2 − OSPF external type 2, E − EGP i − IS−IS, su − IS−IS summary, L1 − IS−IS level−1, L2 − IS−IS level−2 ia − IS−IS inter area, * − candidate default, U − per−user static route o − ODR, P − periodic downloaded static route Gateway of last resort is 171.70.24.0 to network 171.70.0.0 * S* S C C S*
171.70.0.0/16 is variably subnetted, 2 subnets, 2 masks 171.70.0.0/16 [1/0] via 171.70.24.0 171.70.24.0/24 [1/0] via 131.108.99.2 161.44.0.0/24 is subnetted, 1 subnets 161.44.192.0 is directly connected, Ethernet0 131.108.0.0/24 is subnetted, 1 subnets 131.108.99.0 is directly connected, Serial0 198.10.1.0/24 [1/0] via 161.44.192.2
If the original static route had been to the major network, the extra step of configuring the default network twice would not have been necessary. There are still no IP protocols running here. Without any dynamic protocols running, you can configure your router to choose from a number of candidate default routes based on whether the routing table has routes to networks other than 0.0.0.0/0. The ip default−network command allows you to configure robustness into the selection of a gateway of last resort. Rather than configuring static routes to specific next−hops, you can have the router choose a default route to a particular network by checking in the routing table. If you lose the route to a particular network, the router selects the other candidate default. You can remove the lost route by removing the static route in the configuration as follows: 2513#configure terminal Enter configuration commands, one per line.
End with CNTL/Z.
2513(config)#no ip route 171.70.24.0 255.255.255.0 131.108.99.2 2513(config)#^Z 2513# %SYS−5−CONFIG_I: Configured from console by console
After you remove the static route to the default network, the routing table looks like this: 2513#show ip route Codes: C − connected, S − static, I − IGRP, R − RIP, M − mobile, B − BGP D − EIGRP, EX − EIGRP external, O − OSPF, IA − OSPF inter area N1 − OSPF NSSA external type 1, N2 − OSPF NSSA external type 2 E1 − OSPF external type 1, E2 − OSPF external type 2, E − EGP
i − IS−IS, su − IS−IS summary, L1 − IS−IS level−1, L2 − IS−IS level−2 ia − IS−IS inter area, * − candidate default, U − per−user static route o − ODR, P − periodic downloaded static route Gateway of last resort is 161.44.192.2 to network 198.10.1.0 161.44.0.0/24 is subnetted, 1 subnets 161.44.192.0 is directly connected, Ethernet0 131.108.0.0/24 is subnetted, 1 subnets 131.108.99.0 is directly connected, Serial0 198.10.1.0/24 [1/0] via 161.44.192.2
C C S* 2513#
Use Different Routing Protocols Gateways of last resort selected using the ip default−network command are propagated differently depending on which routing protocol is propagating the default route. For IGRP and EIGRP to propagate the route, the network specified by the ip default−network command must be known to IGRP or EIGRP. This means the network must be an IGRP− or EIGRP−derived network in the routing table, or the static route used to generate the route to the network must be redistributed into IGRP or EIGRP, or advertised into these protocols using the network command. RIP advertises a route to 0.0.0.0 if a gateway of last resort is selected using the ip default−network command. This network specified in the ip default−network command need not be explicitly advertised under RIP. For example, note that the gateway of last resort on this router was learned using the combination of the ip route and ip default−network commands. If you enable RIP on this router, RIP advertises a route to 0.0.0.0 (although not to the Ethernet0 network because of split−horizon): 2513(config)#router rip 2513(config−router)#network 161.44.0.0 2513(config−router)#network 131.108.0.0 2513(config−router)#^Z 2513# %SYS−5−CONFIG_I: Configured from console by console 2513#debug ip rip *Mar *Mar *Mar *Mar *Mar *Mar *Mar
2 2 2 2 2 2 2
07:39:35.504: 07:39:35.508: 07:39:35.508: 07:39:35.512: 07:39:35.516: 07:39:35.520: 07:39:35.524:
RIP: sending v1 update to 255.255.255.255 via Ethernet0 (161.44.192.1 RIP: build update entries network 131.108.0.0 metric 1 RIP: sending v1 update to 255.255.255.255 via Serial0 (131.108.99.1) RIP: build update entries subnet 0.0.0.0 metric 1 network 161.44.0.0 metric 1
The default route announced using the ip default−network command is not propagated by Open Shortest Path First (OSPF). For more detailed information on behavior of default routes with OSPF, refer to How Does OSPF Generate Default Routes?. The default route announced using the ip default−network command is not propagated by IS−IS.
ip route 0.0.0.0 0.0.0.0 Creating a static route to network 0.0.0.0 0.0.0.0 is another way to set the gateway of last resort on a router. As with the ip default−network command, using the static route to 0.0.0.0 is not dependent on any routing protocols. However, ip routing must be enabled on the router. Note: IGRP does not understand a route to 0.0.0.0. Therefore, it cannot propagate default routes created using the ip route 0.0.0.0 0.0.0.0 command. Use the ip default−network command to have IGRP propagate a
default route. EIGRP propagates a route to network 0.0.0.0, but the static route must be redistributed into the routing protocol. In earlier versions of RIP, the default route created using the ip route 0.0.0.0 0.0.0.0 was automatically advertised by RIP routers. In Cisco IOS Software Release 12.0T and later, RIP does not advertise the default route if the route is not learned via RIP. It may be necessary to redistribute the route into RIP. The default routes created using the ip route 0.0.0.0 0.0.0.0 command are not propagated by OSPF and IS−IS. Additionally, this default cannot be redistributed into OSPF or IS−IS using the redistribute command. Use the default−information originate command to generate a default route into an IS−IS or OSPF routing domain. For more detailed information on behavior of default routes with OSPF, refer to How Does OSPF Generate Default Routes? This is an example of configuring a gateway of last resort using the ip route 0.0.0.0 0.0.0.0 command: router−3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router−3(config)#ip route 0.0.0.0 0.0.0.0 170.170.3.4 router−3(config)#^Z router−3# router−3#show ip route Codes: C − connected, S − static, I − IGRP, R − RIP, M − mobile, B − BGP D − EIGRP, EX − EIGRP external, O − OSPF, IA − OSPF inter area N1 − OSPF NSSA external type 1, N2 − OSPF NSSA external type 2 E1 − OSPF external type 1, E2 − OSPF external type 2, E − EGP i − IS−IS, L1 − IS−IS level−1, L2 − IS−IS level−2, * − candidate default U − per−user static route, o − ODR Gateway of last resort is 170.170.3.4 to network 0.0.0.0 170.170.0.0/24 is subnetted, 2 subnets C 170.170.2.0 is directly connected, Serial0 C 170.170.3.0 is directly connected, Ethernet0 S* 0.0.0.0/0 [1/0] via 170.170.3.4 router−3# router−3#
Note: If you configure multiple networks as candidate default routes using the ip default−network command, the network that has the lowest administrative distance is chosen as the network for the gateway of last resort. If all the networks have the same administrative distance then the network listed first in the routing table (show ip route lists the routing table) is chosen as the network for the gateway of last resort. If you use both the ip default−network and ip route 0.0.0.0 0.0.0.0 commands to configure candidate default networks, and the network used by the ip default−network command is known statically, the network defined with the ip default−network command takes precedence and is chosen for the gateway of last resort. Otherwise if the network used by the ip default−network command is derived by a routing protocol, the ip route 0.0.0.0 0.0.0.0 command, which has a lower administrative distance, takes precedence and is chosen for the gateway of last resort. If you use multiple ip route 0.0.0.0 0.0.0.0 commands to configure a default route, traffic is load−balanced over the multiple routes.
Summary Use the ip default−gateway command when ip routing is disabled on a Cisco router. Use the ip default−network and ip route 0.0.0.0 0.0.0.0 commands to set the gateway of last resort on Cisco routers that have ip routing enabled. The way in which routing protocols propagate the default route information varies for each protocol.
Related Information • IP Routed Protocols Technology Support Page • Technical Support − Cisco Systems
Contacts & Feedback | Help | Site Map © 2012 − 2013 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of Cisco Systems, Inc.
Updated: Aug 10, 2005
Document ID: 16448
Specifying a Next Hop IP Address for Static Routes Document ID: 27082
Contents Introduction Prerequisites Requirements Components Used Background Theory Conventions Problem Solution Related Information
Introduction This document introduces basic concepts about static routes. This document uses a problem scenario to demonstrate the circumstances under which it is desirable to specify the interface through which the next hop IP address can be reached when you configure a static route.
Prerequisites Requirements There are no specific requirements for this document.
Components Used This document is not restricted to specific software and hardware versions.
Background Theory The ability to configure a static route was introduced in Cisco IOSÂŽ Software Release 10.0. Static routes are used for a variety of reasons and are often used when there is no dynamic route to the destination, or when you run a dynamic routing protocol is not feasible. By default, static routes have an administrative distance of one, which gives them precedence over routes from dynamic routing protocols. When you increase the administrative distance to a value greater than that of a dynamic routing protocol, the static route can be a safety net in the event that dynamic routing fails. For example, Interior Gateway Routing Protocol (IGRP)â&#x2C6;&#x2019;derived routes have a default administrative distance of 100. In order to configure a static route that is overridden by an IGRP route, specify an administrative distance greater than 100 for the static route. This kind of static route is called "floating" static. It is installed in the routing table only when the preferred route disappears. For example, ip route 172.31.10.0 255.255.255.0 10.10.10.2 101. Note: An administrative distance of 255 is considered unreachable and static routes with an administrative distance of 255 are never entered in the routing table.
If you point a static route to a broadcast interface, the route is inserted into the routing table only when the broadcast interface is up. This configuration is not recommended because when the next hop of a static route points to an interface, the router considers each of the hosts within the range of the route to be directly connected through that interface. For example, ip route 0.0.0.0 0.0.0.0 Ethernet0. With this type of configuration, a router performs Address Resolution Protocol (ARP) on the Ethernet for every destination the router finds through the default route because the router considers all of these destinations as directly connected to Ethernet 0. This kind of default route, especially if it is used by a lot of packets to many different destination subnets, can cause high processor utilization and a very large ARP cache (along with attendant memory allocation failures). Specifying a numerical next hop on a directly connected interface prevents the router from performing ARP or each destination address. However, if the interface with the next hop goes down and the numerical next hop is reachable through a recursive route, you should specify both the next hop IP address and the interface through which the next hop should be found. For example, ip route 0.0.0.0 0.0.0.0 Serial 3/3 192.168.20.1.
Conventions Refer to Cisco Technical Tips Conventions for more information on document conventions.
Problem In this network diagram, there are two static routes to the same destination (172.31.10.0/24). One route is a floating static, it is the "backup" or redundant path to the destination network on the LAN. The problem in the scenario is that the floating static route never gets installed in the routing table when the primary link is shut down. R1 has a default route that points to the Internet Service Provider (ISP) router for Internet access. R1 has two links to R2. The T1 is the primary link and 56 K is the backup link. R1 has a static route for 172.31.10.0/24 which points to the R2 Serial 0 IP address (10.10.10.2) as the nextâ&#x2C6;&#x2019;hop. R1 also has a floating static route for 172.131.10.0/24 which points to the R2 Serial 1 IP address (192.168.20.2), the administrative distance for the floating static route is 250. The idea is for packets to flow over the 56 K line in both directions only if the primary link fails.
This example shows the R1 configuration: R1 hostname R1 ! ip subnet−zero no ip domain−lookup ! controller E1 2/0 ! controller E1 2/1 ! interface Serial3/0 description ISP Link ip address 192.168.10.1 255.255.255.252 clockrate 64000 ! interface Serial3/1 no ip address shutdown ! interface Serial3/2 description Primary Link to R2 ip address 10.10.10.1 255.255.255.252 ! interface Serial3/3 description Backup Link to R2 ip address 192.168.20.1 255.255.255.252 clockrate 64000 ! ip classless ip route 0.0.0.0 0.0.0.0 Serial3/0 !−−−This is the default route to ISP router. ip route 172.31.10.0 255.255.255.0 10.10.10.2 !−−−This is the preferred route to the LAN. ip route 172.31.10.0 255.255.255.0 192.168.20.2 250 !−−−This is the floating route to the LAN.
This example shows the R1 routing table: R1 Routing Table R1#show ip route Codes: C − connected, S − static, I − IGRP, R − RIP, M − mobile, B − BGP D − EIGRP, EX − EIGRP external, O − OSPF, IA − OSPF inter area N1 − OSPF NSSA external type 1, N2 − OSPF NSSA external type 2 E1 − OSPF external type 1, E2 − OSPF external type 2, E − EGP i − IS−IS, L1 − IS−IS level−1, L2 − IS−IS level−2, * − candidate default U − per−user static route, o − ODR Gateway of last resort is 0.0.0.0 to network 0.0.0.0
C C
10.0.0.0/30 is subnetted, 1 subnets 10.10.10.0 is directly connected, Serial3/2 192.168.10.0/30 is subnetted, 1 subnets 192.168.10.0 is directly connected, Serial3/0 192.168.20.0/30 is subnetted, 1 subnets
C S
192.168.20.0 is directly connected, Serial3/3 172.31.0.0/24 is subnetted, 1 subnets 172.31.10.0 [1/0] via 10.10.10.2
!−−− The preferred static route to the LAN through the T1. S*
0.0.0.0/0 is directly connected, Serial3/0
!−−− The static default route to the Internet.
This example shows the R2 configuration: R2 hostname R2 ! enable password ww ! ! ! ! ! ip subnet−zero no ip finger no ip domain−lookup ! ! ! interface Ethernet0 description Local LAN ip address 172.31.10.2 255.255.255.0 ! interface Serial0 description Primary Link to R1 ip address 10.10.10.2 255.255.255.252 clockrate 56000 ! interface Serial1 description Backup Link to R1 ip address 192.168.20.2 255.255.255.252 ! interface TokenRing0 no ip address shutdown ! ip classless ip route 0.0.0.0 0.0.0.0 10.10.10.1 !−−− This is the primary default route. ip route 0.0.0.0 0.0.0.0 192.168.20.1 250 !−−− The floating default route to be used if the T1 fails. no ip http server ! ! line con 0 exec−timeout 0 0 transport input none line aux 0 line vty 0 4 password ww login
! end
R2 has the default route installed through 10.10.10.1 and when you use the traceroute command from R2 to the ISP router, the packets use the T1 link. R2 can send pings to the Internet host 192.168.30.1 sourced from 172.31.10.2. The route to 192.168.30.1 is through the default route 0.0.0.0 0.0.0.0. R2 Routing Table R2#show ip route Codes: C − connected, S − static, I − IGRP, R − RIP, M − mobile, B − BGP D − EIGRP, EX − EIGRP external, O − OSPF, IA − OSPF inter area N1 − OSPF NSSA external type 1, N2 − OSPF NSSA external type 2 E1 − OSPF external type 1, E2 − OSPF external type 2, E − EGP i − IS−IS, L1 − IS−IS level−1, L2 − IS−IS level−2, ia − IS−IS inter area * − candidate default, U − per−user static route, o − ODR P − periodic downloaded static route Gateway of last resort is 10.10.10.1 to network 0.0.0.0
C C C S*
172.31.0.0/24 is subnetted, 1 subnets 172.31.10.0 is directly connected, Ethernet0 192.168.20.0/30 is subnetted, 1 subnets 192.168.20.0 is directly connected, Serial1 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks 10.10.10.0/30 is directly connected, Serial0 0.0.0.0/0 [1/0] via 10.10.10.1
!−−− This is the primary default route. R2#traceroute 192.168.10.2 Type escape sequence to abort. Tracing the route to 192.168.10.2 1 10.10.10.1 16 msec 20 msec 16 msec 2 192.168.10.2 32 msec * 32 msec R2#ping Protocol [ip]: Target IP address: 192.168.30.1 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 172.31.10.2 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100−byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round−trip min/avg/max = 32/32/32 ms
If you shut down Serial 3/2 on R1 to test the failover, you should expect R1 to install the floating static route to the local LAN 172.31.10.0 and for R2 to install the floating static route to 0.0.0.0 through 192.168.20.1. You would expect traffic to flow over the 56K link. R1
R1#show ip interface brief Interface IP−Address Serial3/0 192.168.10.1 Serial3/1 unassigned Serial3/2 10.10.10.1 Serial3/3 192.168.20.1
OK? YES YES YES YES
Method manual unset manual manual
Status Protocol up up administratively down down up up up up
R1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)#int s3/2 R1(config−if)#shut R1(config−if)#end 2d21h: %LINEPROTO−5−UPDOWN: Line protocol on Interface Serial3/2, changed state to down 2d21h: %LINK−5−CHANGED: Interface Serial3/2, changed state to administratively down R1#show ip interface brief Interface IP−Address Serial3/0 192.168.10.1 Serial3/1 unassigned Serial3/2 10.10.10.1 Serial3/3 192.168.20.1
OK? YES YES YES YES
Method manual unset manual manual
Status Protocol up& up administratively down down administratively down down up up
R1#show ip route Codes: C − connected, S − static, I − IGRP, R − RIP, M − mobile, B − BGP D − EIGRP, EX − EIGRP external, O − OSPF, IA − OSPF inter area N1 − OSPF NSSA external type 1, N2 − OSPF NSSA external type 2 E1 − OSPF external type 1, E2 − OSPF external type 2, E − EGP i − IS−IS, L1 − IS−IS level−1, L2 − IS−IS level−2, * − candidate default U − per−user static route, o − ODR Gateway of last resort is 0.0.0.0 to network 0.0.0.0
C C S
192.168.10.0/30 is subnetted, 1 subnets 192.168.10.0 is directly connected, Serial3/0 192.168.20.0/30 is subnetted, 1 subnets 192.168.20.0 is directly connected, Serial3/3 172.31.0.0/24 is subnetted, 1 subnets 172.31.10.0 [1/0] via 10.10.10.2
!−−− The static route through the T1 remains in the routing table. !−−− This is not what was expected to happen when Serial 3/2 was shut. S*
0.0.0.0/0 is directly connected, Serial3/0
!−−− The static default route to the Internet. R2#show ip route Codes: C − connected, S − static, I − IGRP, R − RIP, M − mobile, B − BGP D − EIGRP, EX − EIGRP external, O − OSPF, IA − OSPF inter area N1 − OSPF NSSA external type 1, N2 − OSPF NSSA external type 2 E1 − OSPF external type 1, E2 − OSPF external type 2, E − EGP i − IS−IS, L1 − IS−IS level−1, L2 − IS−IS level−2, ia − IS−IS inter area * − candidate default, U − per−user static route, o − ODR P − periodic downloaded static route Gateway of last resort is 192.168.20.1 to network 0.0.0.0
C C S*
172.31.0.0/24 is subnetted, 1 subnets 172.31.10.0 is directly connected, Ethernet0 192.168.20.0/30 is subnetted, 1 subnets 192.168.20.0 is directly connected, Serial1 0.0.0.0/0 [250/0] via 192.168.20.1
!−−− It is no longer possible to ping the Internet host 192.168.20.1 if the ping
!−−− is sourced from the LAN on R2 because R1 tries to send the replies !−−− via the Serial 3/2, which is down. R2#ping Protocol [ip]: Target IP address: 192.168.30.1 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 172.31.10.2 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100−byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
The floating static route was not installed on R1 and the primary static route is still in the routing table of R1 even though the Serial 3/2 link is shut down. The reason this happens is because static routes are recursive in nature. You always keep the static route in the routing table as long as you have a route to the next hop. In this case, R1 thinks it can get to 10.10.10.2 through 192.168.10.2 because 192.168.10.2 is the next hop for 0.0.0.0 0.0.0.0. The route to a next hop can be a more specific, a less specific, or a default route. In this problem scenario, you would think that since the link is down you should not have a route to 10.10.10.2, but if you look at the routing table on R1, you see that there is a static default route pointing to the ISP router. R1, therefore believes that it can reach the next hop (10.10.10.2) for 172.31.10.0/24 through this default route, so the static route to 172.31.10.0/24 through 10.10.10.2 remains in the routing table and the floating static route never gets installed. There is a better way to configure static routes that would allow you to avoid this problem. If you specify the interface through which the next hop should be found, you will install the floating static route only if the next hop IP address is reachable through the specified interface. Before the solution to this problem is presented, you will bring the Serial 3/2 interface on R1 back up again. R1 R1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)#int s 3/2 R1(config−if)#no shut R1(config−if)#end R1# 2d22h: %LINK−3−UPDOWN: Interface Serial3/2, changed state to up 2d22h: %LINEPROTO−5−UPDOWN: Line protocol on Interface Serial3/2, changed state to up 2d22h: %SYS−5−CONFIG_I: Configured from console by console
R1#show ip int brief Interface Serial3/0& Serial3/1 Serial3/2 Serial3/3
IP−Address 192.168.10.1 unassigned 10.10.10.1 192.168.20.1
OK? YES YES YES YES
Method manual unset manual manual
Status Protocol up up administratively down down up up up up
R1#show ip route Codes: C − connected, S − static, I − IGRP, R − RIP, M − mobile, B − BGP D − EIGRP, EX − EIGRP external, O − OSPF, IA − OSPF inter area N1 − OSPF NSSA external type 1, N2 − OSPF NSSA external type 2 E1 − OSPF external type 1, E2 − OSPF external type 2, E − EGP i − IS−IS, L1 − IS−IS level−1, L2 − IS−IS level−2, * − candidate default U − per−user static route, o − ODR Gateway of last resort is 0.0.0.0 to network 0.0.0.0
C C C S S* R1#
10.0.0.0/30 is subnetted, 1 subnets 10.10.10.0 is directly connected, Serial3/2 192.168.10.0/30 is subnetted, 1 subnets 192.168.10.0 is directly connected, Serial3/0 192.168.20.0/30 is subnetted, 1 subnets 192.168.20.0 is directly connected, Serial3/3 172.31.0.0/24 is subnetted, 1 subnets 172.31.10.0 [1/0] via 10.10.10.2 0.0.0.0/0 is directly connected, Serial3/0
Solution The solution is to remove the old static routes to the LAN (172.31.10.0) and configure new static routes, this time specifying the interface through which the next hop must be reached. This allows the floating static route on R1 to get installed when the Serial 3/2 interface is shut. R1 R1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)#no ip route 172.31.10.0 255.255.255.0 10.10.10.2 R1(config)#no ip route 172.31.10.0 255.255.255.0 192.168.20.2 250 R1(config)#ip route 172.31.10.0 255.255.255.0 Serial3/2 10.10.10.2 R1(config)#ip route 172.31.10.0 255.255.255.0 Serial3/3 192.168.20.2 250 R1(config)#end R1# 2d22h: %SYS−5−CONFIG_I: Configured from console by console
The static route to 172.31.10.0 through 10.10.10.2 is installed in the routing table of R1 if 10.10.10.2 is seen through Serial 3/2. If this condition is not met, the static route through 10.10.10.2 is removed from the routing table and the floating static route to 172.31.10.0 through Serial 3/3 with next hop 192.168.20.2 is installed. In order to test how this works and bring the T1 link down, shut down Serial 3/2 and see if the floating static route gets installed in the routing table. R1 R1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)#int s 3/2 R1(config−if)#shut R1(config−if)#end R1# 3d00h: %LINEPROTO−5−UPDOWN: Line protocol on Interface Serial3/2, changed state to down 3d00h: %SYS−5−CONFIG_I: Configured from console by console 3d00h: %LINK−5−CHANGED: Interface Serial3/2, changed state to administratively down R1#show ip interface brief Interface IP−Address Serial3/0 192.168.10.1
OK? Method Status YES manual up
Protocol up
Serial3/1 Serial3/2 Serial3/3
unassigned 10.10.10.1 192.168.20.1
YES unset administratively down down YES manual administratively down down YES manual up up
R1#show ip route Codes: C − connected, S − static, I − IGRP, R − RIP, M − mobile, B − BGP D − EIGRP, EX − EIGRP external, O − OSPF, IA − OSPF inter area N1 − OSPF NSSA external type 1, N2 − OSPF NSSA external type 2 E1 − OSPF external type 1, E2 − OSPF external type 2, E − EGP i − IS−IS, L1 − IS−IS level−1, L2 − IS−IS level−2, * − candidate default U − per−user static route, o − ODR Gateway of last resort is 0.0.0.0 to network 0.0.0.0
C C S S* R1#
192.168.10.0/30 is subnetted, 1 subnets 192.168.10.0 is directly connected, Serial3/0 192.168.20.0/30 is subnetted, 1 subnets 192.168.20.0 is directly connected, Serial3/3 172.31.0.0/24 is subnetted, 1 subnets 172.31.10.0 [250/0] via 192.168.20.2, Serial3/3 0.0.0.0/0 is directly connected, Serial3/0
Now R1 can ping the Internet host 192.168.20.1 with packets sourced from the LAN. R2 R2#ping Protocol [ip]: Target IP address: 192.168.20.1 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 172.31.10.2 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100−byte ICMP Echos to 192.168.20.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round−trip min/avg/max = 32/32/32 ms
The floating static route gets installed as expected.
Related Information • BGP Support Page • RIP Support Page • EIGRP Support Page • IGRP Support Page • IS−IS Support Page • OSPF Support Page • Technical Support & Documentation − Cisco Systems
Contacts & Feedback | Help | Site Map
© 2012 − 2013 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of Cisco Systems, Inc.
Updated: Oct 30, 2006
Document ID: 27082
Configuring the Cisco IOS DHCP Relay Agent Last Updated: April 30, 2012 All Cisco routers that run Cisco software include a DHCP server and the relay agent software. A DHCP relay agent is any host or IP router that forwards DHCP packets between clients and servers. This module describes the concepts and tasks needed to configure the Cisco IOS DHCP relay agent. • • • • • • • •
Finding Feature Information, page 1 Prerequisites for Configuring the Cisco IOS DHCP Relay Agent, page 1 Information About the DHCP Relay Agent, page 2 How to Configure the DHCP Relay Agent, page 2 Configuration Examples for the Cisco IOS DHCP Relay Agent, page 24 Additional References, page 27 Feature Information for the Cisco IOS DHCP Relay Agent, page 28 Glossary, page 31
Finding Feature Information Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information Table at the end of this document. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Prerequisites for Configuring the Cisco IOS DHCP Relay Agent • •
Before you configure the DHCP relay agent, you should understand the concepts documented in the “DHCP Overview” module. The Cisco IOS DHCP server and relay agent are enabled by default. You can verify whether they have been disabled by checking your configuration file. If they have been disabled, the no service dhcp
Americas Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
DHCP Relay Agent Overview Information About the DHCP Relay Agent
•
command will appear in the configuration file. Use the service dhcp command to reenable the functionality if necessary. The Cisco IOS DHCP relay agent will be enabled on an interface only when the ip helper-address command is configured. This command enables the DHCP broadcast to be forwarded to the configured DHCP server.
Information About the DHCP Relay Agent •
DHCP Relay Agent Overview, page 2
DHCP Relay Agent Overview A DHCP relay agent is any host that forwards DHCP packets between clients and servers. Relay agents forward requests and replies between clients and servers when they are not on the same physical subnet. Relay agent forwarding is distinct from the normal forwarding of an IP router, where IP datagrams are switched between networks somewhat transparently. In contrast, when relay agents receive DHCP messages, the agents generate a new DHCP message to send out through another interface. The relay agent sets the gateway IP address (the giaddr field of the DHCP packet) and, if configured, adds the relay agent information option (option 82) to the packet and forwards the packet to the DHCP server. The reply from the server is forwarded back to the client after removing option 82. The Cisco IOS DHCP relay agent supports the use of unnumbered interfaces, including the use of smart relay agent forwarding. For DHCP clients that are connected though unnumbered interfaces, the DHCP relay agent automatically adds a static host route after the DHCP client obtains an address, specifying the unnumbered interface as the outbound interface. The route is automatically removed once the lease time expires or when the client releases the address.
How to Configure the DHCP Relay Agent • Specifying the Packet Forwarding Address, page 2 • Configuring Support for the Relay Agent Information Option, page 5 • Configuring Per-Interface Support for the Relay Agent Information Option, page 8 • Configuring the Subscriber Identifier Suboption of the Relay Agent Information Option, page 11 • Configuring DHCP Relay Class Support for Client Identification, page 12 • Configuring DHCP Relay Agent Support for MPLS VPNs, page 15 • Configuring Support for Relay Agent Information Option Encapsulation, page 18 • Setting the Gateway Address of the DHCP Broadcast to a Secondary Address Using Smart Relay Agent Forwarding, page 21 • Configuring Support for Private and Standard Suboption Numbers, page 22 • Troubleshooting the DHCP Relay Agent, page 23
Specifying the Packet Forwarding Address DHCP clients need to use UDP broadcasts to send their initial DHCPDISCOVER messages because the clients do not have information about the network to which they are attached. If the client is on a network segment that does not include a server, UDP broadcasts are not usually forwarded because most routers are
2
Specifying the Packet Forwarding Address How to Configure the DHCP Relay Agent
configured to not forward broadcast traffic. When the DHCP client broadcasts a DHCPDISCOVER message, the relay agent sends the broadcast message toward the server, which may create Address Resolution Protocol (ARP) entries due to unnecessary ARP checks performed by the client after receiving the ACK message. If there are two entries in the ARP table, one times out after the ARP timeout. You can remedy this situation by configuring the interface of your router that is receiving the broadcasts to forward certain classes of broadcasts to a helper address. You can use more than one helper address per interface. When a router forwards these address assignment/parameter requests, it acts as a DHCP relay agent. The Cisco router implementation of the DHCP relay agent is provided through the ip helper-address interface configuration command. In the figure below, the DHCP client broadcasts a request for an IP address and additional configuration parameters on its local LAN. Router B, acting as a DHCP relay agent, picks up the broadcast and generates a new DHCP message to send out on another interface. As part of this DHCP message, the relay agent inserts the IP address of the interface containing the ip helper-address command into the gateway IP address (giaddr) field of the DHCP packet. This IP address enables the DHCP server to determine which subnet should receive the packet. The DHCP relay agent sends the local broadcast, through IP unicast, to the DHCP server address 172.16.1.2 that is specified by the ip helper-address interface configuration command. Forwarding UDP Broadcasts to a DHCP Server Using a Helper Address DHCP client
DHCP server
172.16.1.2 172.16.1.1
Router A
172.31.1.1
ip helper-address 172.16.1.2
Router B
127132
Figure 1
Perform this task to configure the DHCP relay agent to forward packets to a DHCP server.
SUMMARY STEPS 1. enable 2. configure terminal 3. interface type number 4. ip helper-address address 5. exit 6. ip dhcp relay prefer known-good-server 7. exit
3
Specifying the Packet Forwarding Address How to Configure the DHCP Relay Agent
DETAILED STEPS Command or Action Step 1 enable
Purpose Enables privileged EXEC mode. •
Enter your password if prompted.
Example: Device> enable
Step 2 configure terminal
Enters global configuration mode.
Example: Device# configure terminal
Step 3 interface type number
Configures an interface and enters interface configuration mode.
Example: Device(config)# interface FastEthernet0/0
Step 4 ip helper-address address
Forwards UDP broadcasts, including BOOTP and DHCP. •
Example: Device(config-if)# ip helper-address 172.16.1.2
Step 5 exit
•
The address argument can be a specific DHCP server address, or it can be the network address if other DHCP servers are on the destination network segment. The network address enables other servers to respond to DHCP requests. If you have multiple servers, you can configure one helper address for each server.
Exits interface configuration mode and returns to global configuration mode.
Example: Device(config-if)# exit
Step 6 ip dhcp relay prefer known-good-server
Example: Device(config)# ip dhcp relay prefer known-good-server
4
(Optional) Reduces the frequency with which the DHCP clients change their addresses and forwards client requests to the server that handled the previous request. •
The DHCP relay agent deletes the ARP entries for addresses offered to the DHCP client on unnumbered interfaces.
Configuring Support for the Relay Agent Information Option How to Configure the DHCP Relay Agent
Command or Action Step 7 exit
Purpose Returns to privileged EXEC mode.
Example: Device(config)# exit
Configuring Support for the Relay Agent Information Option Automatic DHCP address allocation is typically based on an IP address, which may be either the gateway IP address (giaddr field of the DHCP packet) or the incoming interface IP address. In some networks, additional information may be required to further determine the IP addresses that need to be allocated. By using the relay agent information option (option 82), the Cisco IOS relay agent can include additional information about itself when forwarding client-originated DHCP packets to a DHCP server. Cisco software supports this functionality by using the ip dhcp relay information option command. The relay agent will automatically add the circuit identifier suboption and the remote ID suboption to the relay agent information option and forward them to the DHCP server. The DHCP server can use this information to assign IP addresses, perform access control, and set quality of service (QoS) and security policies (or other parameter-assignment policies) for each subscriber of a service provider network. The figure below shows how the relay agent information option is inserted into the DHCP packet as follows: 1 The DHCP client generates a DHCP request and broadcasts it on the network. 2 The DHCP relay agent intercepts the broadcast DHCP request packet and inserts the relay agent information option (option 82) into the packet. The relay agent information option contains related suboptions. 3 The DHCP relay agent unicasts the DHCP packet to the DHCP server. 4 The DHCP server receives the packet, uses the suboptions to assign IP addresses and other configuration parameters to the packet, and forwards the packet back to the client.
5
Configuring Support for the Relay Agent Information Option How to Configure the DHCP Relay Agent
5 The suboption fields are stripped off of the packet by the relay agent while forwarding the packet to the client. Figure 2
Operation of the Relay Agent Information Option
Clients broadcast for DHCP requests
Option 82 Append remote ID + circuit ID
1
2
DHCP server If Option 82 aware, use appended information 3
ip helper-address command Takes DHCP requests and unicasts to DHCP server DHCP server
5
4
Strip-off option 82, implement policy and forward IP address assignment
Based on appended information, return IP address and policies
DHCP client
127133
DHCP client
A DHCP relay agent may receive a message from another DHCP relay agent that already contains relay information. By default, the relay information from the previous relay agent is replaced. If this behavior is not suitable for your network, you can use the ip dhcp relay information policy {drop | keep | replace} global configuration command to change it. To ensure the correct operation of the reforwarding policy, disable the relay agent information check by using the no ip dhcp relay information check global configuration command. It is important to understand how DHCP options work. See the “DHCP Overview” module for more information.
Note
• •
•
If the ip dhcp relay information command is configured in global configuration mode but not configured in interface configuration mode, the global configuration is applied to all interfaces. If the ip dhcp relay information command is configured in both global configuration mode and interface configuration mode, the interface configuration command takes precedence over the global configuration command. However, the global configuration is applied to interfaces without the interface configuration. If the ip dhcp relay information command is not configured in global configuration mode but is configured in interface configuration mode, only the interface with the configuration option applied is affected. All other interfaces are not impacted by the configuration.
See the “Configuring Relay Agent Information Option Support per Interface” section for more information on per-interface support for the relay agent information option.
6
Configuring Support for the Relay Agent Information Option How to Configure the DHCP Relay Agent
SUMMARY STEPS 1. enable 2. configure terminal 3. ip dhcp relay information option 4. ip dhcp relay information check 5. ip dhcp relay information policy {drop | keep | replace} 6. ip dhcp relay information trust-all 7. end 8. show ip dhcp relay information trusted-sources
DETAILED STEPS Command or Action Step 1 enable
Purpose Enables privileged EXEC mode. •
Enter your password if prompted.
Example: Device> enable
Step 2 configure terminal
Enters global configuration mode.
Example: Device# configure terminal
Step 3 ip dhcp relay information option
Example:
Enables the system to insert the DHCP relay agent information option (option-82 field) in BOOTREQUEST messages forwarded to a DHCP server. •
This function is disabled by default.
Device(config)# ip dhcp relay information option
Step 4 ip dhcp relay information check
Example: Device(config)# ip dhcp relay information check
(Optional) Configures DHCP to check whether the relay agent information option in forwarded BOOTREPLY messages is valid. •
By default, DHCP verifies whether the option-82 field in DHCP reply packets that it receives from the DHCP server is valid. If an invalid message is received, the relay agent drops the packet. If a valid message is received, the relay agent removes the option-82 field and forwards the packet. Use the ip dhcp relay information check command to reenable this functionality if it has been disabled.
7
Configuring Per-Interface Support for the Relay Agent Information Option How to Configure the DHCP Relay Agent
Command or Action
Purpose
Step 5 ip dhcp relay information policy {drop (Optional) Configures the reforwarding policy (that specifies what a relay agent should do if a message already contains relay information) for a DHCP | keep | replace} relay agent. Example: Device(config)# ip dhcp relay information policy replace
Step 6 ip dhcp relay information trust-all
(Optional) Configures all interfaces on a router as trusted sources of the DHCP relay information option. •
Example: Device(config)# ip dhcp relay information trust-all
•
•
Step 7 end
By default, if the gateway address is set to all zeros in the DHCP packet and the relay agent information option is already present in the packet, the DHCP relay agent will discard the packet. Use the ip dhcp relay information trust-all command to override this behavior and accept the packets. This command is useful if there is a switch placed between the client and the relay agent that may insert option 82. Use this command to ensure that these packets do not get dropped. You can configure an individual interface as a trusted source of the DHCP relay information option by using the ip dhcp relay information trusted interface configuration mode command.
Returns to privileged EXEC mode.
Example: Device(config)# end
Step 8 show ip dhcp relay information trusted-sources
(Optional) Displays all interfaces that are configured to be a trusted source for the DHCP relay information option.
Example: Device# show ip dhcp relay information trusted-sources
Configuring Per-Interface Support for the Relay Agent Information Option The interface configuration allows a Cisco router to reach subscribers with different DHCP option 82 requirements on different interfaces. It is important to understand how DHCP options work. See the “DHCP Overview” module for more information.
8
Configuring Per-Interface Support for the Relay Agent Information Option How to Configure the DHCP Relay Agent
Note
• •
•
If the ip dhcp relay information command is configured in global configuration mode but not configured in interface configuration mode, the global configuration is applied to all interfaces. If the ip dhcp relay information command is configured in both global configuration mode and interface configuration mode, the interface configuration command takes precedence over the global configuration command. However, the global configuration is applied to interfaces without the interface configuration. If the ip dhcp relay information command is not configured in global configuration mode but is configured in interface configuration mode, only the interface on which the configuration option is applied is affected. All other interfaces are not impacted by the configuration.
SUMMARY STEPS 1. enable 2. configure terminal 3. interface type number 4. ip dhcp relay information option-insert [none] 5. ip dhcp relay information check-reply [none] 6. ip dhcp relay information policy-action {drop | keep | replace} 7. exit 8. Repeat Steps 3 through 7 to configure relay agent information settings on different interfaces.
DETAILED STEPS Command or Action Step 1 enable
Purpose Enables privileged EXEC mode. •
Enter your password if prompted.
Example: Device> enable
Step 2 configure terminal
Enters global configuration mode.
Example: Device# configure terminal
Step 3 interface type number
Configures an interface and enters interface configuration mode.
Example: Device(config)# interface FastEthernet0/0
9
Configuring Per-Interface Support for the Relay Agent Information Option How to Configure the DHCP Relay Agent
Command or Action Step 4 ip dhcp relay information option-insert [none]
Example:
Purpose Enables the system to insert the DHCP relay agent information option (option-82 field) in forwarded BOOTREQUEST messages to a DHCP server. •
Device(config-if)# ip dhcp relay information option-insert
•
Step 5 ip dhcp relay information check-reply [none]
Configures a DHCP server to validate the relay information option in forwarded BOOTREPLY messages. •
Example: Device(config-if)# ip dhcp relay information check-reply
•
Step 6 ip dhcp relay information policy-action {drop | keep | replace}
This function is disabled by default. However, if support for the relay agent information option is configured in global configuration mode, but not configured in interface configuration mode, the interface inherits the global configuration. The ip dhcp relay information option-insert none interface configuration command is saved in the running configuration. This command takes precedence over any global relay agent information configuration.
By default, DHCP verifies whether the option-82 field in the DHCP reply packets that it receives from the DHCP server is valid. If an invalid message is received, the relay agent drops the packet. If a valid message is received, the relay agent removes the option-82 field and forwards the packet. Use the ip dhcp relay information check-reply command to reenable this functionality if it has been disabled. The ip dhcp relay information check-reply none interface configuration command option is saved in the running configuration. This command takes precedence over any global relay agent information configuration.
Configures the information reforwarding policy (that specifies what a relay agent should do if a message already contains relay information) for a DHCP relay agent.
Example: Device(config-if)# ip dhcp relay information policy-action replace
Step 7 exit
Exits interface configuration mode.
Example: Device(config-if)# exit
Step 8 Repeat Steps 3 through 7 to configure relay — agent information settings on different interfaces.
10
Configuring the Subscriber Identifier Suboption of the Relay Agent Information Option How to Configure the DHCP Relay Agent
Configuring the Subscriber Identifier Suboption of the Relay Agent Information Option Perform this task to enable an ISP to add a unique identifier to the subscriber identifier suboption of the relay agent information option. The unique identifier enables an ISP to identify a subscriber, assign specific actions to that subscriber (for example, assignment of the host IP address, subnet mask, and domain name system [DNS]), and trigger accounting. Before the introduction of the subscriber identifier suboption, if a subscriber moved from one Network Access Server to another, each ISP had to be informed of the change and all ISPs had to reconfigure the DHCP settings for the affected customers at the same time. Even if the service was not changed, every move involved administrative changes in the ISP environment. With the introduction of the subscriber identifier suboption, if a subscriber moves from one Network Access Server to another, there is no need for a change in the configuration on the DHCP server or the ISPs. You should configure a unique identifier for each subscriber. The new configurable subscriber identifier suboption should be configured on the interface that is connected to the client. When a subscriber moves from one Network Access Server to another, the interface configuration should also be changed. The server should be able to recognize the new suboption.
SUMMARY STEPS 1. enable 2. configure terminal 3. ip dhcp relay information option 4. interface type number 5. ip dhcp relay information option subscriber-id string 6. end
DETAILED STEPS Command or Action Step 1 enable
Purpose Enables privileged EXEC mode. â&#x20AC;˘
Enter your password if prompted.
Example: Device> enable
Step 2 configure terminal
Enters global configuration mode.
Example: Device# configure terminal
11
Configuring DHCP Relay Class Support for Client Identification How to Configure the DHCP Relay Agent
Command or Action Step 3 ip dhcp relay information option
Example:
Purpose Enables the system to insert the DHCP relay agent information option (option-82 field) in forwarded BOOTREQUEST messages to a DHCP server. •
This function is disabled by default.
Router(config)# ip dhcp relay information option
Step 4 interface type number
Configures an interface and enters interface configuration mode.
Example: Device(config)# interface atm4/0.1
Step 5 ip dhcp relay information option subscriber-id string
Specifies that a DHCP relay agent add a subscriber identifier suboption to the relay information option. Note The ip dhcp relay information option subscriber-id
command is disabled by default to ensure backward capability.
Example: Device(config-if)# ip dhcp relay information option subscriber-id newsubscriber123
Step 6 end
Returns to privileged EXEC mode.
Example: Device(config-if)# end
Configuring DHCP Relay Class Support for Client Identification DHCP relay class support for client identification allows the Cisco relay agent to forward client-generated DHCP messages to different DHCP servers based on the content of the following four options: • • • •
Option 60: vendor class identifier Option 77: user class Option 124: vendor-identifying vendor class Option 125: vendor-identifying vendor-specific information
Each option identifies the type of client that is sending the DHCP message. Relay pools provide a method to define DHCP pools that are not used for address allocation. These relay pools can specify that DHCP messages from clients on a specific subnet should be forwarded to a specific DHCP server. These relay pools can be configured with relay classes inside the pool that help determine the forwarding behavior. For example, after receiving the option in a DHCP DISCOVER message, the relay agent will match and identify the relay class from the relay pool and then direct the DHCP DISCOVER message to the DHCP server associated with that identified relay class.
12
Configuring DHCP Relay Class Support for Client Identification How to Configure the DHCP Relay Agent
In an example application, a Cisco router acting as a DHCP relay agent receives DHCP requests from two VoIP services (H.323 and the Session Initiation Protocol [SIP]). The requesting devices are identified by option 60. Both VoIP services have a different back-office infrastructure, so they cannot be serviced by the same DHCP server. Requests for H.323 devices must be forwarded to the H.323 server, and requests from SIP devices must be forwarded to the SIP server. The solution is to configure the relay agent with relay classes that are configured to match option 60 values sent by the client devices. Based on the option value, the relay agent will match and identify the relay class, and forward the DHCP DISCOVER message to the DHCP server associated with the identified relay class. The Cisco IOS DHCP server examines the relay classes that are applicable to a pool and then uses the exact match class regardless of the configuration order. If the exact match is not found, the DHCP server uses the first default match found. It is important to understand how DHCP options work. See the “DHCP Overview” module for more information. You must know the hexadecimal value of each byte location in the options to be able to configure the option hex command. The format may vary from product to product. Contact the relay agent vendor for this information.
SUMMARY STEPS 1. enable 2. configure terminal 3. ip dhcp class class-name 4. option code hex hex-pattern [*][mask bit-mask-pattern] 5. exit 6. Repeat Steps 3 through 5 for each DHCP class that you need to configure. 7. ip dhcp pool name 8. relay source ip-address subnet-mask 9. class class-name 10. relay target [vrf vrf-name | global] ip-address 11. exit 12. Repeat Steps 9 through 11 for each DHCP class that you need to configure.
DETAILED STEPS Command or Action Step 1 enable
Purpose Enables privileged EXEC mode. •
Enter your password if prompted.
Example: Device> enable
13
Configuring DHCP Relay Class Support for Client Identification How to Configure the DHCP Relay Agent
Command or Action Step 2 configure terminal
Purpose Enters global configuration mode.
Example: Device# configure terminal
Step 3 ip dhcp class class-name
Defines a DHCP class and enters DHCP class configuration mode.
Example: Device(config)# ip dhcp class SIP
Step 4 option code hex hex-pattern [*][mask bit-mask-pattern]
Enables the relay agent to make forwarding decisions based on DHCP options inserted in the DHCP message.
Example: Device(dhcp-class)# option 60 hex 010203
Step 5 exit
Exits DHCP class configuration mode.
Example: Device(dhcp-class)# exit
Step 6 Repeat Steps 3 through 5 for each DHCP class that you need to configure.
â&#x20AC;&#x201D;
Step 7 ip dhcp pool name
Configures a DHCP pool on a DHCP server and enters DHCP pool configuration mode.
Example: Device(config)# ip dhcp pool ABC
Step 8 relay source ip-address subnet-mask
Configures the relay source. â&#x20AC;˘
Example: Device(dhcp-config)# relay source 10.2.0.0 255.0.0.0
Step 9 class class-name
Example: Device(dhcp-config)# class SIP
14
This command is similar to the network command in a normal DHCP network pool, because it restricts the use of the address pool to packets arriving on the interface whose configured IP address and mask match the relay source configuration.
Associates a class with a DHCP pool and enters DHCP pool class configuration mode.
Configuring DHCP Relay Agent Support for MPLS VPNs How to Configure the DHCP Relay Agent
Command or Action Step 10 relay target [vrf vrf-name | global] ip-address
Purpose Configures an IP address for a DHCP server to which packets are forwarded.
Example: Device(config-dhcp-pool-class)# relay target 10.21.3.1
Step 11 exit
Exits DHCP pool class configuration mode.
Example: Device(config-dhcp-pool-class)# exit
Step 12 Repeat Steps 9 through 11 for each DHCP class that you need to configure.
—
Configuring DHCP Relay Agent Support for MPLS VPNs DHCP relay support for Multiprotocol Label Switching (MPLS) VPNs enables a network administrator to conserve address space by allowing overlapping addresses. The relay agent can support multiple clients on different VPNs, and many of these clients from different VPNs can share the same IP address. Configuring VPNs involves an adjustment to the usual DHCP host IP address designation. VPNs use private address spaces that might not be unique across the Internet. In some environments, a relay agent resides in a network element that also has access to one or more MPLS VPNs. A DHCP server that provides service to DHCP clients on those different VPNs must locate the VPN in which each client resides. The network element that contains the relay agent typically captures the VPN association of the DHCP client and includes this information in the relay agent information option of the DHCP packet. DHCP relay support for MPLS VPNs allows the relay agent to forward this necessary VPN-related information to the DHCP server using the following three suboptions of the DHCP relay agent information option: • • •
VPN identifier Subnet selection Server identifier override
The VPN identifier suboption is used by the relay agent to inform the DHCP server about the VPN for every DHCP request that the relay agent passes on to the DHCP server; the VPN identifier suboption is also used to properly forward any DHCP reply that the DHCP server sends back to the relay agent. The VPN identifier suboption contains the VPN ID configured on the incoming interface to which the client is connected. If you configure the VPN routing and forwarding (VRF) name but not the VPN ID, the VRF name is used as the VPN identifier suboption. If the interface is in the global routing space, VPN suboptions are not added. The subnet selection suboption allows the separation of the subnet, where the client resides, from the IP address used to communicate with the relay agent. In typical DHCP processing, the gateway address specifies both the subnet on which a DHCP client resides and the IP address that the server can use to communicate with the relay agent. Situations exist where the relay agent needs to specify the subnet on
15
Configuring DHCP Relay Agent Support for MPLS VPNs How to Configure the DHCP Relay Agent
which a DHCP client resides that is different from the IP address that the server can use to communicate with the relay agent. The subnet selection suboption is included in the relay agent information option and passed on to the DHCP server. The gateway address is changed to the outgoing interface of the relay agent toward the DHCP server. The DHCP server uses this gateway address to send reply packets back to the relay agent. The server identifier override suboption value is copied in the reply packet from the DHCP server instead of the normal server ID address. The server identifier override suboption contains the incoming interface IP address, which is the IP address on the relay agent that is accessible from the client. Using this information, the DHCP client sends all renew and release packets to the relay agent. The relay agent adds all the VPN suboptions to the packets and forwards the packets to the original DHCP server. After adding these suboptions to the DHCP relay agent information option, the gateway address is changed to the outgoing interface of the relay agent toward the DHCP server. When the packets are returned from the DHCP server, the relay agent removes the relay agent information options from the packets and forwards the packets to the DHCP client on the correct VPN. The figure below shows a VPN scenario where the DHCP relay agent and DHCP server can recognize the VPN within which each client resides. DHCP client 1 is part of VPN green, and DHCP client 2 is part of VPN red, and both have the same private IP address 192.168.1.0/24. Because the clients have the same IP address, the DHCP relay agent and DHCP server use the VPN identifier, subnet selection, and server identifier override suboptions of the relay agent information option to distinguish the correct VPN of the client. Figure 3
VPN DHCP Configuration
VPN blue/192.168.1.0/24 DHCP client 1 in "green"
VPN red/192.168.1.0/24
DHCP client 2 in "red"
172.27.180.232
172.27.181.73
DHCP relay agent on router
121983
192.168.1.1
DHCP server
Before configuring DHCP relay support for Multiprotocol Label Switching (MPLS) VPNs, you must configure standard MPLS VPNs.
16
Configuring DHCP Relay Agent Support for MPLS VPNs How to Configure the DHCP Relay Agent
Note
•
•
•
If the ip dhcp relay information option vpn global configuration command is configured and the ip dhcp relay information option vpn-id interface configuration command is not configured, the global configuration is applied to all interfaces. If the ip dhcp relay information option vpn global configuration command is configured and the ip dhcp relay information option vpn-id interface configuration command is also configured, the interface configuration command takes precedence over the global configuration command. However, the global configuration is applied to interfaces without the interface configuration. If the ip dhcp relay information option vpn global configuration command is not configured and the ip dhcp relay information option vpn-id interface configuration command is configured, only the interface on which the configuration option is applied is affected. All other interfaces are not impacted by the configuration.
SUMMARY STEPS 1. enable 2. configure terminal 3. ip dhcp relay information option vpn 4. interface type number 5. ip helper-address vrf name [global] address 6. ip dhcp relay information option vpn-id [none] 7. end
DETAILED STEPS Command or Action Step 1 enable
Purpose Enables privileged EXEC mode. •
Enter your password if prompted.
Example: Device> enable
Step 2 configure terminal
Enters global configuration mode.
Example: Device# configure terminal
Step 3 ip dhcp relay information option vpn
Example: Device(config)# ip dhcp relay information option vpn
Enables the system to insert VPN suboptions into the DHCP relay agent information option in forwarded BOOTREQUEST messages to a DHCP server and sets the gateway address to the outgoing interface toward the DHCP server. •
The VPN suboptions are also added to the BOOTP broadcast packets when the command is configured.
17
Configuring Support for Relay Agent Information Option Encapsulation How to Configure the DHCP Relay Agent
Command or Action Step 4 interface type number
Purpose Configures an interface and enters interface configuration mode.
Example: Device(config)# interface FastEthernet0/0
Step 5 ip helper-address vrf name [global] address
Forwards UDP broadcasts, including BOOTP, received on an interface. •
Example:
If the DHCP server resides in a different VRF or global space that is different from the VPN, the vrf name or global options allow you to specify the name of the VRF or the global space in which the DHCP server resides.
Device(config-if)# ip helperaddress vrf vrf1 172.27.180.232
Step 6 ip dhcp relay information option vpn- (Optional) Enables the system to insert VPN suboptions into the DHCP relay agent information option in forwarded BOOTREQUEST messages to a DHCP id [none] server and sets the gateway address to the outgoing interface toward the DHCP server. Example:
•
Device(config-if)# ip dhcp relay information option vpn-id
•
•
Step 7 end
The VPN suboptions are also added to the BOOTP broadcast packets when the command is configured. The ip dhcp relay information option vpn-id none command allows you to disable the VPN functionality on the interface. The only time you need to use this command is when the ip dhcp relay information option vpn global configuration command is configured and you want to override the global configuration. The no ip dhcp relay information option vpn-id command removes the configuration from the running configuration. In this case, the interface inherits the global configuration, which may or may not be configured to insert VPN suboptions.
Returns to privileged EXEC mode.
Example: Device(config-if)# end
Configuring Support for Relay Agent Information Option Encapsulation When two relay agents are relaying messages between the DHCP client and the DHCP server, the relay agent closer to the server, by default, replaces the first option 82 information with its own option 82. The remote ID and circuit ID information from the first relay agent is lost. In some deployment scenarios, it is necessary to maintain the initial option 82 from the first relay agent, in addition to the option 82 from the second relay agent, for example, in a situation where an Intelligent Services Gateway (ISG) acting as a second relay agent is connected to a Layer 2 device. The Layer 2 device connects to the household and identifies the household with its own option 82.
18
Configuring Support for Relay Agent Information Option Encapsulation How to Configure the DHCP Relay Agent
The DHCP Relay Option 82 Encapsulation feature allows the second relay agent to encapsulate option 82 information in a received message from the first relay agent if the second relay agent is configured to add its own option 82 information. This configuration allows the DHCP server to use option 82 information from both relay agents. The DHCP server can use the VPN information from the second relay agent, along with the option 82 information from the first relay agent, to send correct address assignments and other configuration parameters for the client devices based on the VRF, option 60, and encapsulated option 82. The reply message from the DHCP server to the DHCP client traverses the same path as the request messages through the two relay agents to the DHCP client. The figure below shows the processing that occurs on the two relay agents and the DHCP server when this feature is configured: 1 The DHCP client generates a DHCP message (including option 60) and broadcasts it on the network. 2 The first DHCP relay agent intercepts the broadcast DHCP request packet and inserts its own option 82 in the packet. 3 The relay agent automatically adds the circuit ID suboption and the remote ID suboption to option 82 and forwards them to the second relay agent. 4 The second relay agent encapsulates the first relay agentâ&#x20AC;&#x2122;s option 82 and inserts its own option 82. 5 The gateway IP address (giaddr) is set to the incoming interface on the second relay agent and the original giaddr from the first relay agent is encapsulated. 6 The second DHCP relay agent unicasts the DHCP packet to the DHCP server. 7 The DHCP server receives the packet and uses the VPN suboption information from the second relay agent, along with the option 82 information from the first relay agent, to assign IP addresses and other configuration parameters and forwards the packet back to the second relay agent. 8 When the second relay agent receives the reply message from the server, it restores the encapsulated option 82 and prior giaddr from the first relay agent. The reply message is then sent to the prior giaddr. 9 The first relay agent strips option 82 off from the packet before forwarding the packet to the client. Figure 4
Processing DHCP Relay Agent Information Option Encapsulation Support
2, 3
4, 5, 6
DHCP client
1
9
Second DHCP relay agent
8
DHCP server
7
204909
First DHCP relay agent
DHCP client
19
Configuring Support for Relay Agent Information Option Encapsulation How to Configure the DHCP Relay Agent
SUMMARY STEPS 1. enable 2. configure terminal 3. ip dhcp relay information option 4. ip dhcp relay information option vpn 5. ip dhcp relay information policy encapsulate 6. interface type number 7. ip dhcp relay information policy-action encapsulate 8. end
DETAILED STEPS Command or Action Step 1 enable
Purpose Enables privileged EXEC mode. •
Enter your password if prompted.
Example: Device> enable
Step 2 configure terminal
Enters global configuration mode.
Example: Device# configure terminal
Step 3 ip dhcp relay information option
Example:
Enables the system to insert the DHCP relay agent information option (option-82 field) in forwarded BOOTREQUEST messages to a DHCP server. •
This function is disabled by default.
Device(config)# ip dhcp relay information option
Step 4 ip dhcp relay information option vpn
Example: Device(config)# ip dhcp relay information option vpn
Step 5 ip dhcp relay information policy encapsulate
Example: Device(config)# ip dhcp relay information policy encapsulate
20
(Optional) Enables the system to insert VPN suboptions into the DHCP relay agent information option in forwarded BOOTREQUEST messages to a DHCP server and sets the gateway address to the outgoing interface toward the DHCP server. •
The VPN suboptions are also added to the BOOTP broadcast packets when the command is configured.
Enables the system to encapsulate the DHCP relay agent information option (option-82 field) received from a prior relay agent in forwarded BOOTREQUEST messages to a DHCP server. •
Option 82 information from both relay agents will be forwarded to the DHCP server.
Setting the Gateway Address of the DHCP Broadcast to a Secondary Address Using Smart Relay Agent Forwarding How to Configure the DHCP Relay Agent
Command or Action Step 6 interface type number
Purpose (Optional) Configures an interface and enters interface configuration mode. â&#x20AC;˘
Example:
If you configure the global configuration command, there is no need to configure the interface configuration command unless you want to apply a different configuration on a specific interface.
Device(config)# interface FastEthernet0/0
Step 7 ip dhcp relay information policy-action (Optional) Enables the system to encapsulate the DHCP relay agent information option (option-82 field) received on an interface from a prior relay encapsulate agent in forwarded BOOTREQUEST messages to a DHCP server on an interface. Example:
â&#x20AC;˘
Device(config-if)# ip dhcp relay information policy-action encapsulate
Step 8 end
This function is disabled by default. This command has precedence over the global configuration command. However, if the relay agent information option encapsulation support is configured in global configuration mode, but not in interface configuration mode, the interface inherits the global configuration.
Returns to privileged EXEC mode.
Example: Device(config-if)# end
Setting the Gateway Address of the DHCP Broadcast to a Secondary Address Using Smart Relay Agent Forwarding You only need to configure helper addresses on the interface where the UDP broadcasts that you want to forward to the DHCP server are being received. You only need to configure the ip dhcp smart-relay command if you have secondary addresses on that interface and you want the router to step through each IP network when forwarding DHCP requests. If smart relay agent forwarding is not configured, all requests are forwarded using the primary IP address on the interface. If the ip dhcp smart-relay command is configured, the relay agent counts the number of times that the client retries sending a request to the DHCP server when there is no DHCPOFFER message from the DHCP server. After three retries, the relay agent sets the gateway address to the secondary address. If the DHCP server still does not respond after three more retries, then the next secondary address is used as the gateway address. This functionality is useful when the DHCP server cannot be configured to use secondary pools.
SUMMARY STEPS 1. enable 2. configure terminal 3. ip dhcp smart-relay 4. exit
21
Configuring Support for Private and Standard Suboption Numbers How to Configure the DHCP Relay Agent
DETAILED STEPS Command or Action Step 1 enable
Purpose Enables privileged EXEC mode. â&#x20AC;˘
Enter your password if prompted.
Example: Device> enable
Step 2 configure terminal
Enters global configuration mode.
Example: Device# configure terminal
Step 3 ip dhcp smart-relay
Allows the DHCP relay agent to switch the gateway address (giaddr field of a DHCP packet) to a secondary address when there is no DHCPOFFER message from a DHCP server.
Example: Device(config)# ip dhcp smart-relay
Step 4 exit
Returns to privileged EXEC mode.
Example: Device(config)# exit
Configuring Support for Private and Standard Suboption Numbers Some features that are not standardized will use the private Cisco relay agent suboption numbers. After the features are standardized, the relay agent suboptions are assigned the Internet Assigned Numbers Authority (IANA) numbers. Cisco software supports both private and IANA numbers for these suboptions. Perform this task to configure the DHCP client to use private or IANA standard relay agent suboption numbers.
SUMMARY STEPS 1. enable 2. configure terminal 3. ip dhcp compatibility suboption link-selection {cisco | standard} 4. exit
22
Troubleshooting the DHCP Relay Agent How to Configure the DHCP Relay Agent
DETAILED STEPS Command or Action Step 1 enable
Purpose Enables privileged EXEC mode. â&#x20AC;˘
Enter your password if prompted.
Example: Device> enable
Step 2 configure terminal
Enters global configuration mode.
Example: Device# configure terminal
Step 3 ip dhcp compatibility suboption link-selection {cisco | standard}
Configures the DHCP client to use private or IANA standard relay agent suboption numbers.
Example: Device(config)# ip dhcp compatibility suboption linkselection standard
Step 4 exit
(Optional) Exits global configuration mode and returns to privileged EXEC mode.
Example: Device(config)# exit
Troubleshooting the DHCP Relay Agent The show ip route dhcp command is useful to help troubleshoot issues with the DHCP relay agent that adds routes to clients from unnumbered interfaces. This command displays all routes added to the routing table by the DHCP server and the relay agent.
SUMMARY STEPS 1. enable 2. show ip route dhcp 3. show ip route dhcp ip-address 4. show ip route vrf vrf-name dhcp 5. clear ip route [vrf vrf-name] dhcp [ip-address]
23
Troubleshooting the DHCP Relay Agent Configuration Examples for the Cisco IOS DHCP Relay Agent
DETAILED STEPS Command or Action Step 1 enable
Purpose Enables privileged EXEC mode. •
Enter your password if prompted.
Example: Device> enable
Step 2 show ip route dhcp
Displays all routes added by the Cisco IOS DHCP server and relay agent.
Example: Device# show ip route dhcp
Step 3 show ip route dhcp ip-address
Displays all routes added by the Cisco IOS DHCP server and relay agent associated with the specified IP address.
Example: Device# show ip route dhcp 172.16.1.3
Step 4 show ip route vrf vrf-name dhcp
Displays all routes added by the Cisco IOS DHCP server and relay agent associated with the named VRF.
Example: Device# show ip route vrf vrf1 dhcp
Step 5 clear ip route [vrf vrf-name] dhcp [ip-address] Removes routes from the routing table added by the DHCP server and relay agent for DHCP clients on unnumbered interfaces. Example: Device# clear ip route dhcp
Configuration Examples for the Cisco IOS DHCP Relay Agent • Example: Configuring Support for the Relay Agent Information Option, page 25 • Example: Configuring Per-Interface Support for the Relay Agent Information Option, page 25 • Example: Configuring the Subscriber Identifier Suboption of the Relay Agent Information Option, page 25 • Example: Configuring DHCP Relay Class Support for Client Identification, page 26 • Example: Configuring DHCP Relay Agent Support for MPLS VPNs, page 26 • Example: Configuring Support for Relay Agent Information Option Encapsulation, page 26 • Example: Setting the Gateway Address of the DHCP Broadcast to a Secondary Address Using Smart Relay Agent Forwarding, page 27
24
Example: Configuring Support for the Relay Agent Information Option Configuration Examples for the Cisco IOS DHCP Relay Agent
Example: Configuring Support for the Relay Agent Information Option The following example shows how to enable the DHCP server, the relay agent, and the insertion and removal of the DHCP relay information option (option 82). Note that the Cisco IOS DHCP server is enabled by default. In this example, the DHCP server is disabled: ! Reenables the DHCP server. service dhcp ip dhcp relay information option ! interface ethernet0/0 ip address 192.168.100.1 255.255.255.0 ip helper-address 10.55.11.3
Example: Configuring Per-Interface Support for the Relay Agent Information Option The following example shows that for subscribers who are being serviced by the same aggregation router, the relay agent information option for ATM subscribers must be processed differently from that for Ethernet digital subscribers. For ATM subscribers, the relay agent information option is configured to be removed from the packet by the relay agent before forwarding the packet to the client. For Ethernet subscribers, the connected device provides the relay agent information option, and the option is configured to remain in the packet and be forwarded to the client. ip dhcp relay information trust-all interface Loopback0 ip address 10.16.0.1 255.255.255.0 ! interface ATM3/0 no ip address ! interface ATM3/0.1 ip helper-address 10.16.1.2 ip unnumbered loopback0 ip dhcp relay information option-insert ! interface Loopback1 ip address 10.18.0.1 255.255.255.0 ! interface Ethernet4 no ip address ! interface Ethernet4/0.1 encapsulation dot1q 123 ip unnumbered loopback1 ip helper-address 10.18.1.2 ip dhcp relay information policy-action keep
Example: Configuring the Subscriber Identifier Suboption of the Relay Agent Information Option The following example shows how to add a unique identifier to the subscriber-identifier suboption of the relay agent information option: ip dhcp relay information option ! interface Loopback0 ip address 10.1.1.129 255.255.255.192 !
25
Example: Configuring DHCP Relay Class Support for Client Identification Configuration Examples for the Cisco IOS DHCP Relay Agent
interface ATM4/0 no ip address ! interface ATM4/0.1 point-to-point ip helper-address 10.16.1.2 ip unnumbered Loopback0 ip dhcp relay information option subscriber-id newperson123 atm route-bridged ip pvc 88/800 encapsulation aal5snap
Example: Configuring DHCP Relay Class Support for Client Identification In the following example, DHCP messages are received from DHCP clients on subnet 10.2.2.0. The relay agent will match and identify the relay class from the relay pool and forward the DHCP message to the appropriate DHCP server identified by the relay target command. ! ip dhcp class H323 option 60 hex 010203 ! ip dhcp class SIP option 60 hex 040506 ! ! The following is the relay pool: ip dhcp pool pool1 relay source 10.2.2.0 255.255.255.0 class H323 relay target 192.168.2.1 relay target 192.168.3.1 ! class SIP relay target 192.168.4.1
Example: Configuring DHCP Relay Agent Support for MPLS VPNs In the following example, the DHCP relay agent receives a DHCP request on Ethernet interface 0/1 and sends the request to the DHCP server located at IP helper address 10.44.23.7, which is associated with the VRF named vrf1: ip dhcp relay information option vpn ! interface ethernet 0/1 ip helper-address vrf vrf1 10.44.23.7 !
Example: Configuring Support for Relay Agent Information Option Encapsulation In the following example, DHCP relay agent 1 is configured globally to insert the relay agent information option into the DHCP packet. DHCP relay agent 2 is configured to add its own relay agent information option, including the VPN information, and to encapsulate the relay agent information option received from DHCP relay agent 1. The DHCP server receives the relay agent information options from both the relay agents, uses this information to assign IP addresses and other configuration parameters, and forwards them back to the client. DHCP Relay Agent 1 ip dhcp relay information option
26
Example: Setting the Gateway Address of the DHCP Broadcast to a Secondary Address Using Smart Relay Agent Forwarding Additional References
DHCP Relay Agent 2 ip dhcp relay information option ip dhcp relay information option vpn ip dhcp relay information option encapsulation
Example: Setting the Gateway Address of the DHCP Broadcast to a Secondary Address Using Smart Relay Agent Forwarding In the following example, the router will forward the DHCP broadcast received on Ethernet interface 0/0 to the DHCP server (10.55.11.3), by inserting 192.168.100.1 in the giaddr field of the DHCP packet. If the DHCP server has a scope or pool configured for the 192.168.100.0/24 network, the server will respond; otherwise, it will not respond. Because the ip dhcp smart-relay global configuration command is configured, if the router sends three requests using 192.168.100.1 in the giaddr field and does not get a response, the router will move on and start using 172.16.31.254 in the giaddr field instead. Without the smart relay functionality, the router uses only 192.168.100.1 in the giaddr field. ip dhcp smart-relay ! interface ethernet0/0 ip address 192.168.100.1 255.255.255.0 ip address 172.16.31.254 255.255.255.0 ip helper-address 10.55.11.3 !
Additional References Related Documents Related Topic
Document Title
Cisco IOS commands
Cisco IOS Master Commands List, All Releases
DHCP commands: complete command syntax, Cisco IOS IP Addressing Services Command command modes, command history, defaults, usage Reference guidelines, and examples DHCP conceptual information
“DHCP Overview” module in the IP Addressing: DHCP Configuration Guide
DHCP server configuration
“Configuring the Cisco IOS DHCP Server” module in the IP Addressing: DHCP Configuration Guide
DHCP client configuration
“Configuring the Cisco IOS DHCP Client” module in the IP Addressing: DHCP Configuration Guide
DHCP server on-demand address pool manager configuration
“Configuring the DHCP Server On-Demand Address Pool Manager” module in the IP Addressing: DHCP Configuration Guide
27
Example: Setting the Gateway Address of the DHCP Broadcast to a Secondary Address Using Smart Relay Agent Forwarding Feature Information for the Cisco IOS DHCP Relay Agent
Related Topic
Document Title
DHCP advanced features
“Configuring DHCP Services for Accounting and Security” module in the IP Addressing: DHCP Configuration Guide
DHCP enhancements for edge-session management “Configuring DHCP Enhancements for Edgeconfiguration Session Management” module in the IP Addressing: DHCP Configuration Guide DHCP options
“DHCP Options” appendix in the Network Registrar User’s Guide, Release 6.1.1
DHCP for IPv6
“Implementing DHCP for IPv6” module in the IP Addressing: DHCP Configuration Guide
Standards and RFCs Standard/RFC
Title
RFC 951
Bootstrap Protocol (BOOTP)
RFC 1542
Clarifications and Extensions for the Bootstrap Protocol
RFC 2131
Dynamic Host Configuration Protocol
RFC 2685
Virtual Private Networks Identifier
RFC 3046
DHCP Relay Information Option
RFC 5460
DHCPv6 Bulk Leasequery
Technical Assistance Description
Link
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.
http://www.cisco.com/cisco/web/support/ index.html
Feature Information for the Cisco IOS DHCP Relay Agent The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software
28
Example: Setting the Gateway Address of the DHCP Broadcast to a Secondary Address Using Smart Relay Agent Forwarding Feature Information for the Cisco IOS DHCP Relay Agent
release train. Unless noted otherwise, subsequent releases of that software release train also support that feature. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. Table 1
Feature Information for the Cisco IOS DHCP Relay Agent
Feature Name
Releases
Feature Information
DHCP Class Support for Client Identification
12.4(11)T
The DHCP Class Support for Client Identification feature enhances the DHCP class mechanism to support options 60, 77, 124, and 125. These options identify the type of client that is sending the DHCP message. The DHCP relay agent can make forwarding decisions based on the content of the options in the DHCP message sent by the client. The following command was introduced by this feature: option hex.
DHCP Relay MPLS VPN Support
12.2(8) 12.2(28)SB 12.2(33)SRC
DHCP relay support for MPLS VPNs enables a network administrator to conserve address space by allowing overlapping addresses. The relay agent can support multiple clients on different VPNs, and many of these clients from different VPNs can share the same IP address. The following commands were modified by this feature: ip dhcp relay information option, and ip helper address.
29
Example: Setting the Gateway Address of the DHCP Broadcast to a Secondary Address Using Smart Relay Agent Forwarding Feature Information for the Cisco IOS DHCP Relay Agent
Feature Name
Releases
Feature Information
DHCP Relay Option 82 Encapsulation
12.2(33)SRD
This feature allows a second DHCP relay agent to encapsulate the relay agent information option (option 82) from a prior relay agent, to add its own option 82, and to forward the packet to the DHCP server. The DHCP server can use the VPN information from the second relay agent, along with the option 82 information from the first relay agent, to send correct address assignments and other configuration parameters for the client devices based on the VRF, option 60, and encapsulated option 82. The following commands were modified by this feature: ip dhcp relay information policy, and ip dhcp relay information policyaction.
DHCP Relay Option 82 per Interface Support
12.2(31)SB2 12.2(33)SRC 12.4(6)T
This feature enables support for the DHCP relay agent information option (option 82) on a per-interface basis. The interface configuration allows different DHCP servers, with different DHCP option 82 requirements to be reached from one Cisco router. The following commands were introduced by this feature: ip dhcp relay information checkreply, ip dhcp relay information option-insert, and ip dhcp relay information policy-action.
DHCP Subscriber Identifier Suboption of Option 82
12.2(28)SB 12.2(33)SRB 12.3(14)T
This feature enables an ISP to add a unique identifier to the subscriber-identifier suboption of the relay agent information option. The following command was introduced by this feature: ip dhcp relay information option subscriber-id.
30
Example: Setting the Gateway Address of the DHCP Broadcast to a Secondary Address Using Smart Relay Agent Forwarding Glossary
Feature Name
Releases
Feature Information
DHCPv4 Relay per Interface VPN ID Support
12.4(11)T
The DHCPv4 Relay per Interface VPN ID Support feature allows the Cisco IOS DHCP relay agent to be configured per interface to override the global configuration of the ip dhcp relay information option vpn command. This feature allows subscribers with different relay information option VPN ID requirements on different interfaces to be reached from one Cisco router. The following command was introduced by this feature: ip dhcp relay information option vpn-id.
DHCPv6 Bulk Lease Query
15.1(1)S
The Cisco IOS DHCPv6 relay agent supports bulk lease query in accordance with RFC 5460. The following commands were introduced or modified by this feature: debug ipv6 dhcp relay and ipv6 dhcp-relay bulk-lease.
Glossary client—A host that is trying to configure its interface (obtain an IP address) using DHCP or BOOTP protocols. DHCP—Dynamic Host Configuration Protocol. A network protocol that automatically provides an IP host with an IP address and other related configuration information (for example, subnet mask and default gateway). giaddr—gateway IP address. The giaddr field of the DHCP message provides the DHCP server with information about the IP address subnet on which the client is to reside. It also provides the DHCP server with an IP address where the response messages are to be sent. MPLS—Multiprotocol Label Switching. Industry standard upon which tag switching is based. relay agent—A router that forwards DHCP and BOOTP messages between a server and a client on different subnets. server—A DHCP or BOOTP server. VPN—Virtual Private Network. Enables IP traffic to use tunneling to travel securely over a public TCP/IP network. VRF—VPN routing and forwarding instance. A VRF consists of an IP routing table, a derived forwarding table, a set of interfaces that use the forwarding table, and a set of rules and routing protocols that determine what goes into the forwarding table. In general, a VRF includes the routing information that
31
Example: Setting the Gateway Address of the DHCP Broadcast to a Secondary Address Using Smart Relay Agent Forwarding
defines a customer VPN site that is attached to a Provider Edge (PE) router. Each VPN that is instantiated on the PE router has its own VRF.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. Š 2012 Cisco Systems, Inc. All rights reserved.
32
CH A P T E R
1
Configuring Static Routing This chapter describes how to configure static routing on the switch. This chapter includes the following sections: •
Information About Static Routing, page 1-1
•
Licensing Requirements for Static Routing, page 1-3
•
Prerequisites for Static Routing, page 1-3
•
Guidelines and Limitations, page 1-3
•
Default Settings, page 1-4
•
Configuring Static Routing, page 1-4
•
Verifying the Static Routing Configuration, page 1-6
•
Configuration Examples for Static Routing, page 1-6
•
Additional References, page 1-6
Information About Static Routing Routers forward packets using either route information from route table entries that you manually configure or the route information that is calculated using dynamic routing algorithms. Static routes, which define explicit paths between two routers, cannot be automatically updated; you must manually reconfigure static routes when network changes occur. Static routes use less bandwidth than dynamic routes. No CPU cycles are used to calculate and analyze routing updates. You can supplement dynamic routes with static routes where appropriate. You can redistribute static routes into dynamic routing algorithms but you cannot redistribute routing information calculated by dynamic routing algorithms into the static routing table. You should use static routes in environments where network traffic is predictable and where the network design is simple. You should not use static routes in large, constantly changing networks because static routes cannot react to network changes. Most networks use dynamic routes to communicate between routers but may have one or two static routes configured for special cases. Static routes are also useful for specifying a gateway of last resort (a default router to which all unroutable packets are sent). This section includes the following topics: •
Administrative Distance, page 1-2
•
Directly Connected Static Routes, page 1-2
Cisco Nexus 5600 Series NX-OS Unicast Routing Configuration Guide, Release 7.x OL-31642-01
1-1
Chapter 1
Configuring Static Routing
Information About Static Routing
•
Fully Specified Static Routes, page 1-2
•
Floating Static Routes, page 1-2
•
Remote Next Hops for Static Routes, page 1-3
•
BFD, page 1-3
•
Virtualization Support, page 1-3
Administrative Distance An administrative distance is the metric used by routers to choose the best path when there are two or more routes to the same destination from two different routing protocols. An administrative distance guides the selection of one routing protocol (or static route) over another, when more than one protocol adds the same route to the unicast routing table. Each routing protocol is prioritized in order of most to least reliable using an administrative distance value. Static routes have a default administrative distance of 1. A router prefers a static route to a dynamic route because the router considers a route with a low number to be the shortest. If you want a dynamic route to override a static route, you can specify an administrative distance for the static route. For example, if you have two dynamic routes with an administrative distance of 120, you would specify an administrative distance that is greater than 120 for the static route if you want the dynamic route to override the static route.
Directly Connected Static Routes You need to specify only the output interface (the interface on which all packets are sent to the destination network) in a directly connected static route. The router assumes the destination is directly attached to the output interface and the packet destination is used as the next hop address. The next hop can be an interface, only for point-to-point interfaces. For broadcast interfaces, the next-hop must be an IPv4or IPv6 address.
Fully Specified Static Routes You must specify either the output interface (the interface on which all packets are sent to the destination network) or the next-hop address in a fully specified static route. You can use a fully specified static route when the output interface is a multi-access interface and you need to identify the next-hop address. The next-hop address must be directly attached to the specified output interface.
Floating Static Routes A floating static route is a static route that the router uses to back up a dynamic route. You must configure a floating static route with a higher administrative distance than the dynamic route that it backs up. In this instance, the router prefers a dynamic route to a floating static route. You can use a floating static route as a replacement if the dynamic route is lost.
Note
By default, a router prefers a static route to a dynamic route because a static route has a smaller administrative distance than a dynamic route.
Cisco Nexus 5600 Series NX-OS Unicast Routing Configuration Guide, Release 7.x
1-2
OL-31642-01
Chapter 1
Configuring Static Routing Virtualization Support
Remote Next Hops for Static Routes You can specify the next-hop address of a neighboring router that is not directly connected to the router for static routes with remote (nondirectly attached) next hops. If a static route has remote next hops during data-forwarding, the next hops are recursively used in the unicast routing table to identify the corresponding directly attached next hop(s) that have reachability to the remote next hops.
BFD Bidirectional forwarding detection (BFD) is supported for static routes. BFD is a detection protocol that provides fast forwarding-path failure detection times. BFD provides subsecond failure detection between two adjacent devices and can be less CPU-intensive than protocol hello messages because some of the BFD load can be distributed onto the data plane on supported modules. See the Cisco Nexus 6000 Series NX-OS Interfaces Configuration Guide, Release 7.x for more information.
Virtualization Support Static routes support Virtual Routing and Forwarding instances (VRFs).
Licensing Requirements for Static Routing The following table shows the licensing requirements for this feature: Product
License Requirement
Cisco NX-OS
Static routing requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide. Make sure the LAN Base Services license is installed on the switch to enable Layer 3 interfaces.
Note
Prerequisites for Static Routing Static routing has the following prerequisites: â&#x20AC;˘
The next-hop address for a static route must be reachable or the static route will not be added to the unicast routing table.
Guidelines and Limitations Static routing has the following configuration guidelines and limitations: â&#x20AC;˘
You can specify an interface as the next-hop address for a static route only for point-to-point interfaces such as GRE tunnels.
Cisco Nexus 5600 Series NX-OS Unicast Routing Configuration Guide, Release 7.x OL-31642-01
1-3
Chapter 1
Configuring Static Routing
Default Settings
Default Settings Table 1-1 lists the default settings for static routing parameters. Table 1-1
Default Static Routing Parameters
Parameters
Default
administrative distance
1
Configuring Static Routing This section includes the following topics:
Note
â&#x20AC;˘
Configuring a Static Route, page 1-4
â&#x20AC;˘
Configuring Virtualization, page 1-5
If you are familiar with the Cisco IOS CLI, be aware that the Cisco NX-OS commands for this feature might differ from the Cisco IOS commands that you would use.
Configuring a Static Route You can configure a static route on the router.
SUMMARY STEPS 1.
configure terminal
2.
ip route {ip-prefix | ip-addr ip-mask} {[next-hop | nh-prefix] | [interface next-hop | nh-prefix]} [tag tag-value [pref]]
3.
(Optional) show ip static-route
4.
(Optional) copy running-config startup-config
DETAILED STEPS
Step 1
Command
Purpose
configure terminal
Enters configuration mode.
Example: switch# configure terminal switch(config)#
Step 2
ip route {ip-prefix | ip-addr ip-mask} {[next-hop | nh-prefix] | [interface next-hop | nh-prefix]} [tag tag-value [pref]
Configures a static route and the interface for this static route. You can optionally configure the next-hop address. The preference value sets the administrative distance. The range is from 1 to 255. The default is 1.
Example: switch(config)# ip route 192.0.2.0/8 ethernet 1/2 192.0.2.4
Cisco Nexus 5600 Series NX-OS Unicast Routing Configuration Guide, Release 7.x
1-4
OL-31642-01
Chapter 1
Configuring Static Routing Configuring Static Routing
Step 3
Command
Purpose
show {ip static-route
(Optional) Displays information about static routes.
Example: switch(config)# show ip static-route
Step 4
copy running-config startup-config
(Optional) Saves this configuration change.
Example: switch(config)# copy running-config startup-config
This example shows how to configure a static route: switch# configure terminal switch(config)# ip route 192.0.2.0/8 192.0.2.10 switch(config)# copy running-config startup-config
Use the no ip static-route command to remove the static route.
Configuring Virtualization You can configure a static route in a VRF.
SUMMARY STEPS 1.
configure terminal
2.
vrf context vrf-name
3.
ip route {ip-prefix | ip-addr ip-mask} {next-hop | nh-prefix | interface} [tag tag-value [pref]]
4.
(Optional) show ip static-route vrf vrf-name
5.
(Optional) copy running-config startup-config
DETAILED STEPS
Step 1
Command
Purpose
configure terminal
Enters configuration mode.
Example: switch# configure terminal switch(config)#
Step 2
Creates a VRF and enters VRF configuration mode.
vrf context vrf-name Example: switch(config)# vrf context StaticVrf
Step 3
ip route {ip-prefix | ip-addr ip-mask} {next-hop | nh-prefix | interface} [tag tag-value [pref] Example: switch(config-vrf)# ip route 192.0.2.0/8 ethernet 1/2
Configures a static route and the interface for this static route. You can optionally configure the next-hop address. The preference value sets the administrative distance. The range is from 1 to 255. The default is 1.
Cisco Nexus 5600 Series NX-OS Unicast Routing Configuration Guide, Release 7.x OL-31642-01
1-5
Chapter 1
Configuring Static Routing
Verifying the Static Routing Configuration
Step 4
Command
Purpose
show ip static-route vrf vrf-name
(Optional) Displays information on static routes.
Example: switch(config-vrf)# show ip static-route
Step 5
copy running-config startup-config
(Optional) Saves this configuration change.
Example: switch(config-vrf)# copy running-config startup-config
This example shows how to configure a static route: switch# configure terminal switch(config)# vrf context StaticVrf switch(config-vrf)# ip route 192.0.2.0/8 192.0.2.10 switch(config-vrf)# copy running-config startup-config
Verifying the Static Routing Configuration To display the static routing configuration information, use this command: Command
Purpose
show ip static-route
Displays the configured static routes.
Configuration Examples for Static Routing This example shows how to configure static routing: configure terminal ip route 192.0.2.0/8 192.0.2.10 copy running-config startup-config
This example shows how to configure static routing for IPv6: configure terminal ipv6 route 43::/64 42::2 copy running-config startup-config
Additional References For additional information related to implementing static routing, see the following sections: â&#x20AC;˘
Related Documents, page 1-7
Cisco Nexus 5600 Series NX-OS Unicast Routing Configuration Guide, Release 7.x
1-6
OL-31642-01
Chapter 1
Configuring Static Routing
Related Documents Related Topic
Document Title
Static Routing CLI
Cisco Nexus 6000 Series Command Reference, Cisco NX-OS Releases 7.x
Cisco Nexus 5600 Series NX-OS Unicast Routing Configuration Guide, Release 7.x OL-31642-01
1-7
Chapter 1
Configuring Static Routing
Cisco Nexus 5600 Series NX-OS Unicast Routing Configuration Guide, Release 7.x
1-8
OL-31642-01