Projetando redes stub de larga escala com ODR
Contents
Introduction
O ODR (Roteamento Sob Demanda) é um aperfeiçoamento do CDP (Cisco Discovery Protocol), um protocolo usado para descobrir outros dispositivos Cisco em mídia de transmissão ou não transmissão. Com a ajuda do CDP, é possível encontrar o tipo de dispositivo, o endereço IP, a versão do Cisco IOS® em execução no dispositivo Cisco vizinho, os recursos do dispositivo vizinho e assim por diante. No Cisco IOS Software Release 11.2, o ODR foi adicionado ao CDP para anunciar o prefixo IP conectado de um roteador stub via CDP. Esse recurso utiliza cinco bytes extras para cada rede ou subrede, quatro bytes para o endereço IP e um byte para anunciar a máscara de subrede junto com o IP. O ODR pode transportar informações de Máscara de Sub-Rede de Tamanho Variável (VLSM).
O ODR foi projetado para clientes varejistas empresariais que não desejam usar sua largura de banda de rede para atualizações do Routing Protocol. Em um ambiente X.25, por exemplo, geralmente é muito caro executar um protocolo de roteamento sobre esse link. O roteamento estático é uma boa opção, mas há overhead demais para se manterem as rotas estáticas manualmente. O ODR não exige muita CPU e é usado para propagar rotas IP dinamicamente via Camada 2.
O ODR não é um protocolo de roteamento e não deve ser tratado como tal ao configurá-lo. As configurações tradicionais para diferentes protocolos de IP Routing não funcionarão no ODR, pois este usa CDP no Layer 2. Para configurar o ODR, utilize o comando router odr no roteador de hub. O projeto, a implementação e a interação do ODR com outros protocolos de roteamento IP podem ser difíceis.
O ODR não será executado em Cisco 700 Series Routers ou via links ATM com exceção de emulação de LAN (LANE).
Redes stub versus redes de trânsito
Quando nenhuma informação está passando pela rede, é uma rede stub. A topologia hub-and-spoke é um exemplo ideal de rede stub. Grandes organizações com muitas estações conectadas a um centro de dados usam esse tipo de topologia.
Os roteadores de extremidade baixa como os Cisco 2500, 1600, e 1000 Series Routers são usados no lado de spoke. Se as informações passarem pelos roteadores de raio com destino a uma outra rede, esse roteador de stub torna-se um roteador de trânsito. Essa configuração ocorre quando um spoke está conectado a outro roteador além do roteador de hub.
Uma preocupação comum é o tamanho de uma atualização de ODR que um raio pode enviar. Geralmente, os spokes são conectados a um hub. Se os spokes estiverem conectados a outros roteadores, eles não serão mais stubs e se tornarão uma rede de trânsito. Caixas low-end geralmente têm uma ou duas interfaces LAN. Por exemplo, o Cisco 2500 pode suportar duas interfaces LAN. Em situações normais, o pacote de 10 bytes é enviado (caso haja duas LANs no lado de raio) como parte do CDP. O CDP está habilitado por padrão e, portanto, não há problemas com relação há sobrecarga adicional. Nunca haverá uma situação em que haja uma grande atualização do ODR. O tamanho das atualizações de ODR não será problema em um verdadeiro ambiente de hub e spoke.
Redes de hub-and-spoke e ODR
Uma rede de hub e spoke é uma rede típica em que um hub (roteador avançado) serve muitos spokes (roteadores simples). Em casos especiais, pode haver mais de um hub, para fins de redundância ou para suportar spokes adicionais através de um hub separado. Nesta situação, habilite o ODR nos dois hubs. Também é necessário ter um Routing Protocol para trocar informações de ODR Routing entre os dois hubs.
Figura 1: Topologia hub-and-spoke 
Comunica-se com um único ponto de saída
Na Figura 1 acima, os spokes são conectados a um hub para que possam confiar no gateway padrão em vez de receber todas as informações de roteamento para o hub com um ponto de saída. Não é necessário transmitir todas as informações aos spokes, pois um spoke não precisará tomar uma decisão de roteamento inteligente. Um spoke sempre enviará o tráfego para o hub, de modo que os spokes precisem apenas de uma rota padrão apontando para um hub.
Deve haver uma forma de as informações da sub-rede de raio serem enviadas ao concentrador. Antes do Cisco IOS 11.2, a única maneira de alcançar isto era habilitando um Routing Protocol no spoke. Usando ODR, no entanto, os protocolos de roteamento não precisam ser ativados no lado do spoke. Com o ODR, somente o Cisco IOS 11.2 e uma rota estática padrão apontando para um hub são necessários no spoke.
Comunica-se com vários pontos de saída
Um raio pode ter várias conexões para o concentrador com fins de redundância ou de backup, caso o link primário falhe. Um hub separado freqüentemente é requerido para esta redundância. Nessa situação, os spokes têm vários pontos de saída. O ODR também funciona bem nesta rede.
Os spokes devem ser ponto a ponto, caso contrário, a rota padrão estática flutuante não funcionará. Em uma configuração multiponto, como em um meio de difusão, não há como detectar uma falha do próximo salto.
Balanceamento de carga ou backup com um único hub
Para realizar o balanceamento de carga, defina duas rotas padrão estáticas nos spokes com a mesma distância e o spoke realizará o balanceamento da carga entre esses dois caminhos. Se houver dois caminhos para o destino, o ODR manterá ambas as rotas na tabela de roteamento e realizará o balanceamento de carga no hub.
Para backups, defina as duas rotas estáticas padrão com uma distância de uma melhor do que a outra. O roteador spoke usará o link principal e, quando o link principal ficar inativo, a rota estática flutuante será ativado. No roteador de hub, utilize o comando distance para cada endereço vizinho do CDP e faça uma distância melhor que a outra. Com essa configuração, as rotas ODR obtidas por meio de um enlace terão preferência em relação às outras. Essa configuração é útil em um ambiente em que existem links primários rápidos e links de backup lentos (largura de banda lenta) e em que o balanceamento de carga não é desejável.
Observação: atualmente, não há outro método no lado do spoke para preferir um link em relação ao outro em uma situação de hub único, exceto conforme descrito acima. Se estiver usando o IOS 12.0.5T ou mais recente, o hub enviará automaticamente a rota padrão através dos dois links, o spoke não distinguirá entre os dois caminhos e os instalará na tabela de roteamento. A única forma de escolher uma rota padrão em detrimento da outra é utilizar uma rota estática padrão no spoke que tenha um caminho com uma distância administrativa inferior para a rota preferida. Isso substitui automaticamente as rotas padrão que estão chegando nos spokes via ODR. Atualmente, a idéia de fornecer um botão ao spoke, onde ele pode preferir um enlace a outro, está em consideração.
Figura 2: Comunica-se com vários pontos de saída e um único hub 
Balanceamento de carga ou backup com vários hubs
Essas configurações também podem ser utilizadas para o balanceamento de carga ou backups quando há vários hubs. Todos os hubs devem estar totalmente engrenados de modo que, se um dos links dos spokes falhar, o destino ainda possa ser alcançado através de um segundo hub. Consulte a seção ODR vs. Outros Protocolos de Roteamento deste documento para obter uma explicação mais detalhada. Da mesma forma, no caso de vários hubs, se o IOS 12.0.5T ou posterior estiver em uso, os hubs enviam as rotas padrão ODR para spokes e spokes instalam ambos na tabela de roteamento. Um aprimoramento futuro permitirá que um ponto remoto prefira um concentrador a outro. Atualmente, isso pode ser feito por meio de uma rota padrão estática definida no roteador do spoke e do uso de admin distance no comando static route para preferir um hub ao outro. Isso não afeta situações de balanceamento de carga.
Figura 3: Comunica-se com vários pontos de saída e vários hubs 
ODR versus outros protocolos de roteamento
A maior vantagem do ODR sobre o IP Routing é que o roteador de hub aprenderá os prefixos IP sem habilitar os Routing Protocol no Layer 3. As atualizações de ODR fazem parte do CDP, na Camada 2.
ODR versus EIGRP
Em um verdadeiro ambiente hub e spoke, é necessário passar as informações de roteamento para todos os spokes. O link lento causa desperdício de largura de banda nas atualizações de roteamento e na manutenção de relações com vizinhos. Ao habilitar o Enhanced Interior Gateway Routing Protocol (EIGRP) nos raios, as atualizações de roteamento são enviadas aos raios. Em grandes redes, essas atualizações se tornam imensas, desperdiçam largura de banda de CPU e podem exigir mais memória nos roteadores spoke.
Uma abordagem melhor com o EIGRP é aplicar filtros no hub. As informações de roteamento são controladas para que os hubs apenas enviem dinamicamente uma rota padrão aos spokes. Estes filtros ajudam a reduzir o tamanho da tabela de roteamento no lado do spoke, mas se o hub perder um vizinho, ele enviará consultas para todos os outros vizinhos. Essas consultas são desnecessárias, pois o hub jamais obterá resposta de um vizinho.
A melhor metodologia é eliminar a sobrecarga de consultas EIGRP e manutenção de vizinhos usando ODR. Ajustando os cronômetros ODR, o tempo de convergência pode ser aumentado.
Hoje, temos um novo recurso no EIGRP que dimensiona o EIGRP muito melhor em uma situação de hub e spoke. Consulte Enhanced IGRP Stub Routing para obter mais informações sobre o recurso de stub do EIGRP.
ODR versus OSPF
O OSPF (Open Shortest Path First) oferece várias opções para os ambientes de hub-and-spoke, e a opção stub no-summary possui um menor overhead.
É possível que sejam encontrados problemas na execução do OSPF em redes hub-and-spoke em larga escala. Os exemplos nessa seção usam o Frame Relay porque se trata da topologia de hub-and-spoke mais comum.
Redes stub ponto-a-ponto de OSPF
Neste exemplo, o OSPF é ativado em 100 spokes conectados por uma configuração ponto-a-ponto. Primeiramente, há diversos endereços IP desperdiçados, mesmo se realizarmos uma sub-rede com uma máscara de rede /30. Em segundo lugar, se incluirmos esses 100 spokes em um área e um spoke não estiver sincronizado, o algoritmo SPF será executado e poderá se tornar intensivo no CPU. Essa situação é especialmente válida para roteadores spoke se o link estiver continuamente não sincronizado. Um número maior de vizinhos sincronizados pode causar problemas a ponto de envolver roteadores de spoke.
Em OSPF, a área é de stub, e não a interface. Se houver 100 roteadores em uma rede stub, é necessário mais memória nos raios para conter o grande banco de dados. Esse problema pode ser resolvido dividindo uma grande área de stub em pequenas áreas. No entanto, um flap em uma área de stub ainda disparará o SPF para ser executado nos spokes, de modo que essa sobrecarga não pode ser curada fazendo uma pequena área de stub sem resumo e sem externalidades.
Outra opção é incluir cada link em uma única área. Com esta opção, o roteador do hub terá de funcionar em um algoritmo de SPF separado para cada área e criar um LSA (anúncio de estado de enlace) de resumo para os roteadores na área. Esta opção pode prejudicar o desempenho do roteador do hub.
A atualização para uma plataforma melhor não é uma solução permanente; no entanto, o ODR oferece uma solução. As rotas aprendidas via ODR podem ser redistribuídas para OSPF a fim de informar outros roteadores de hub sobre essas rotas.
Redes auxiliares OSPF de ponto a multiponto.
Nas redes de ponto para vários pontos, o espaço do endereço IP é salvo colocando cada raio na mesma sub-rede. Além disso, o tamanho do hub LSA do roteador que é gerado será dividido, uma vez que irá gerar apenas um link de stub para todos os links de ponto-a-ponto. Uma rede ponto-a-multiponto forçará toda a sub-rede a ser incluída em uma única área. No caso de perda de sincronia do enlace, o spoke executará o SPF, que pode ser intensivo da CPU.
A tempestade de saudação
Os pacotes de saudação de OSPF são pequenos, mas, se houver vizinhos demais, seu tamanho pode crescer. Visto que as saudações são multicast, o roteador processa os pacotes. O hub OSPF envia e recebe pacotes de saudação compostos de 20 bytes de cabeçalho IP, 24 bytes de cabeçalho OSPF, 20 bytes de parâmetros de saudação e 4 bytes para cada vizinho visto. Um pacote OSPF hello de um hub em uma rede ponto-para-multiponto com 100 vizinhos pode ficar com 464 bytes e será inundado para todos os concentradores a cada 30 segundos.
Tabela 1: Pacote hello OSPF para 100 vizinhos| cabeçalho IP de 20 bytes |
| cabeçalho OSPF de 24 bytes |
| Parâmetros de saudação de 20 bytes |
| 4 bytes cada ID de roteador vizinho (RID) |
| . . . |
| . . . |
| . . . |
| . . . |
| . . . |
A sobrecarga está resolvida no ODR pois nenhuma informação adicional está sendo enviada do hub para os spokes. Os spokes enviam o prefixo IP de 5 bytes por sub-rede ao roteador de hubs. Considerando o tamanho do pacote de saudações, compare os 5 bytes em ODR (as informações de envio do spoke de uma sub-rede conectada) com os 68 bytes de OSPF (o menor tamanho de pacote de saudações incluindo um cabeçalho IP enviado do spoke para o hub) mais 68 bytes (o menos pacote de saudação enviado do hub para o spoke) durante um intervalo de 30 segundos. Além disso, as saudações de OSPF ocorrem na camada 3 enquanto as atualizações de ODR ocorrem na camada 2. Com o ODR, muito menos informações são enviadas, por isso a largura de banda do link pode ser usada para dados importantes.
ODR versus RIPv2
O protocolo RIPv2 também é uma boa opção para ambientes de hub-and-spoke. Para projetar o RIPv2, envie a rota padrão do hub para os concentradores. Os spokes então anunciam sua interface conectada via RIP. O RIPv2 é usado quando há endereços secundários nos spokes que necessitam de anúncio, quando vários roteadores de fornecedores estão em uso ou quando a situação não é realmente do tipo hub e spoke.
RIPv2 em circuito sob demanda
A versão 2 tem algumas modificações, mas não altera o protocolo drasticamente. Esta seção aborda alguns aperfeiçoamentos em RIP para circuitos de demanda.
As inter-redes do presente estão caminhando na direção de redes dialup ou backups de enlaces primários para fornecer conexões a uma grande quantidade de estações remotas. Esses tipos de conexões podem passar muito pouco ou nenhum tráfego de dados durante a operação normal.
O comportamento periódico do RIP causa problemas nesses circuitos. O RIP tem problemas com interfaces ponto-a-ponto de largura de banda baixa. Atualizações são enviadas a cada 30 segundos com amplas tabelas de roteamento que usam alta largura de banda. Nesta situação, é melhor usar o RIP disparado.
RIP disparado
O Triggered RIP (RIP Disparado) foi projetado para os roteadores que trocam informações de roteamento com seu vizinho. Se ocorrerem alterações no roteamento, apenas as alterações serão propagadas ao vizinho. O roteador receptor aplica as alterações imediatamente.
Atualizações de RIP disparadas são enviadas apenas quando:
-
Uma solicitação de atualização de roteamento é recebida.
-
Novas informações são recebidas.
-
O destino foi alterado de descer para subir no circuito.
-
O roteador é ligado pela primeira vez.
Segue-se um exemplo de configuração para RIP disparado:
Spoke# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Spoke(config)# int s0.1
Spoke(config-if)# ip rip triggered
Spoke(config)# int s0.2
Spoke(config-if)# ip rip triggered
interface serial 0
encapsulation frame-relay
interface serial 0.1 point /* Primary PVC */
ip address 10.x.x.x 255.255.255.0
ip rip triggered
frame-relay interface-dlci XX
interface serial 0.2 point /* Secondary PVC */
ip address 10.y.y.y 255.255.255.0
ip rip triggered
frame-relay interface-dlci XX
router rip
network 10.0.0.0
Spoke# show ip protocol
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 23 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Triggered RIP Key-chain
Ethernet0 1 1 2
Serial0.1 1 1 2 Yes
Serial0.2 1 1 2 Yes
Routing for Networks:
10.0.0.0
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 120)
O comando ip rip trigger deve ser configurado na interface do roteador do hub que se conecta aos spokes.
Ao comparar RIPv2 com ODR, o ODR é a melhor opção porque o RIPv2 funciona na Camada 3 e o ODR ocorre na Camada 2. Quando o hub envia atualizações de RIPv2 para mais de 1000 spokes, ele tem que replicar o pacote na Camada 3 para cada spoke. O ODR não envia nada do hub, exceto a atualização normal do CDP a cada minuto na Camada 2, o que não é, de nenhum modo, pesado para a CPU. O envio de informações de sub-rede conectada na Camada 2, a partir do spoke, implica uma utilização muito menos intensiva de CPU do que o envio de RIPv2 na Camada 3.
Design de rede em grande escala com ODR
O ODR funciona melhor em uma rede de grande escala do que qualquer outro protocolo de roteamento. A maior vantagem do ODR é que os protocolos de roteamento não precisam ser habilitados nos links seriais conectados. Atualmente, não existem protocolos de roteamento capazes de enviar informações de rotas sem ativá-las na interface conectada.
ODR com EIGRP em execução nos hubs
Ao executar o EIGRP, faça uma conexão de interface passiva com uma rede hub-and-spoke para que ela não envie saudações EIGRP desnecessárias no link. Se possível, é melhor não colocar instruções de rede em redes entre o hub e os spokes porque, se o link ficar inativo, o EIGRP não enviará consultas desnecessárias aos vizinhos centrais. Sempre escolha uma rede falsa entre o hub e os spokes para que esses links não sejam incluídos no domínio do EIGRP porque você não colocará instruções de rede nas configurações.
Redundância e resumo
Em uma situação de hub único, nenhuma configuração extra é necessária. Resuma as sub-redes específicas e conectadas aos spokes e deixe-as vazar pelo núcleo. Os overheads de consultas, no entanto, sempre estarão lá. Se rotas específicas forem perdidas de um dos spokes, envie as consultas para todos os vizinhos nos roteadores principais.
No caso de vários hubs, é muito importante que ambos os hubs estejam conectados e que o EIGRP esteja em execução entre os hubs. Se for possível, este enlace deverá ser uma rede principal exclusiva, de modo que não interfira nos demais enlaces que estão indo para os spokes. Esta configuração é necessária porque o EIGRP não pode ser habilitado em uma interface específica, mesmo se tornarmos a interface passiva, ela ainda será anunciada via EIGRP. Se a interface for resumida, as consultas serão enviadas para fora caso um spoke seja perdido. Desde que o link entre os dois hubs não esteja na mesma rede principal que os spokes, a configuração deve funcionar corretamente.
Figura 4: Redundância e resumo: O núcleo está recebendo rotas resumidas 
Um vantagem do EIGRP é que este recurso pode resumir no nível da interface, portanto, a rota resumida das sub-redes de spokes será enviada para o núcleo que, por sua vez, enviará uma rota mais específica ao outro hub. Se o link entre um hub e um spoke ficar inativo, é possível alcançar o destino através do segundo hub.
ODR com OSPF em execução nos hubs
Nesse cenário, o OSPF não precisa ser habilitado no enlace que conecta os spokes. Em um cenário normal, se o OSPF estiver ativado no link e um link específico estiver constantemente oscilando, ele poderá causar vários problemas, incluindo a execução de SPF, regeneração de LSA do roteador, regeneração de LSA de resumo e assim por diante. Ao executar o ODR, não inclua o link serial conectado no domínio OSPF. A principal preocupação é receber as informações do segmento de LAN dos spokes. Essas informações podem ser obtidas por meio de ODR. Se um enlace estiver constantemente fora de sincronização, ele não interferirá no Routing Protocol no roteador do hub.
Redundância e resumo
Todos os enlaces específicos podem ser resumidos antes de vazarem no núcleo para impedir o cálculo da rota, caso uma das interfaces conectadas de um spoke falhe. Ele não pode ser detectado se as informações do roteador central estiverem resumidas.
Figura 5: Redundância e resumo: O roteador base está recebendo rotas resumidas 
Neste exemplo, é muito importante que concentadores estejam conectados entre si para fins de redundância. Essa conexão também resumirá as sub-redes conectadas por spoke antes de vazar no centro OSPF.
NSSA com melhoria futura
Eventualmente haverá um recurso de áreas de não muito stub (NSSA) de OSPF que permitirá não apenas o resumo no núcleo, mas também a obtenção de informações mais específicas no hub através do enlace NSSA. A vantagem de executar NSSA é que as rotas resumidas podem ser enviadas para o núcleo. Em seguida, o centro pode enviar o tráfego a qualquer um dos hubs para chegar ao destino do spoke. Se o link entre um hub e um spoke for desconectado, haverá um LSA Tipo 7 mais específico em ambos os hubs para chegar ao destino por meio do outro hub.
Veja a seguir um exemplo de configuração usando NSSA:
N2507: Hub 1
router odr
timers basic 8 24 0 1
!
router ospf 1
redistribute odr subnets
network 1.0.0.0 0.255.255.255 area 1
area 1 nssa
N2504: Hub 2
router odr
timers basic 8 24 0 1
!
router ospf 1
redistribute odr subnets
network 1.0.0.0 0.255.255.255 area 1
area 1 nssa
N2507# 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 not set
C 1.0.0.0/8 is directly connected, Serial0
C 2.0.0.0/8 is directly connected, Serial1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Ethernet0
o 150.0.0.0/16 [160/1] via 3.3.3.2, 00:00:23, Ethernet0
o 200.1.1.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0
o 200.1.2.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0
N2504# 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 not set
C 1.0.0.0/8 is directly connected, Serial0
C 2.0.0.0/8 is directly connected, Serial1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.4.0 is directly connected, TokenRing0
C 5.0.0.0/8 is directly connected, Loopback0
C 6.0.0.0/8 is directly connected, Loopback1
O N2 150.0.0.0/16 [110/20] via 1.0.0.1, 00:12:06, Serial0
O N2 200.1.1.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0
O N2 200.1.2.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0
Sumarização e futura melhoria com NSSA
Atribua um bloco contíguo de sub-redes para os spokes, de modo que as sub-redes possam ser resumidas adequadamente no centro de OSPF, conforme mostrado no exemplo a seguir. Se as sub-redes não são resumidas e uma sub-rede conectada é desativada, todo o núcleo a detecta e recalcula as rotas. Ao enviar a rota de sumário de um bloco contíguo, se a sub-rede de raio não sincronizar, o centro não a detectará.
N2504# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
N2504(config)# router ospf 1
N2504(config-router)# summary-address 200.1.0.0 255.255.0.0
N2504# show ip ospf database external
OSPF Router with ID (6.0.0.1) (Process ID 1)
Type-5 AS External Link States
LS age: 1111
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 200.1.0.0 (External Network Number )
Advertising Router: 6.0.0.1
LS Seq Number: 80000001
Checksum: 0x2143
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 127
Metric: 16777215
Forward Address: 0.0.0.0
External Route Tag: 0
Problema de distância
Neste exemplo, informações mais específicas são recebidas de ambos os hubs. Como a distância OSPF é 110 e a distância ODR é 160, as informações interferem com ODR quando são recebidas do outro hub sobre a mesma sub-rede. O outro hub terá sempre a preferência para obter o destino do spoke, o que causará um roteamento não ideal. Para corrigir a situação, diminua a distância ODR para menos de 110 com o comando distance, de modo que a rota ODR sempre seja preferencial em relação à rota OSPF. Se a rota ODR falhar, a rota externa OSPF será instalada na tabela de roteamento do banco de dados.
N2504(config)# router odr
N2504(config-router)# distance 100
N2504(config-router)# end
N2504# 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 not set
C 1.0.0.0/8 is directly connected, Serial0
C 2.0.0.0/8 is directly connected, Serial1
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.4.0 is directly connected, TokenRing0
C 5.0.0.0/8 is directly connected, Loopback0
C 6.0.0.0/8 is directly connected, Loopback1
o 150.0.0.0/16 [100/1] via 3.3.4.1, 00:00:39, TokenRing0
o 200.1.1.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0
o 200.1.2.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0
O 200.1.0.0/16 is a summary, 00:04:38, Null0
As rotas N2 ainda estão no banco de dados e ficarão ativas se o link do hub principal com o spoke ficar desativado.
N2504# show ip ospf database nssa
OSPF Router with ID (6.0.0.1) (Process ID 1)
Type-7 AS External Link States (Area 1)
LS age: 7
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 150.0.0.0 (External Network Number )
Advertising Router: 6.0.0.1
LS Seq Number: 80000002
Checksum: 0x965E
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 1.0.0.2
External Route Tag: 0
Com a melhoria para o NSSA, o LSA mais específico do Tipo 7 estará no banco de dados NSSA. Em vezes de uma rota resumida, a saída do banco de dados NSSA aparecerá como mostra a seguir:
LS age: 868
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 200.1.1.0 (External Network Number)
Advertising Router: 3.3.3.1
LS Seq Number: 80000001
Checksum: 0xDFE0
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 1.0.0.1
External Route Tag: 0
LS age: 9
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 200.1.2.0 (External Network Number)
Advertising Router: 3.3.3.1
LS Seq Number: 80000002
Checksum: 0xFDC3
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 1.0.0.2
External Route Tag: 0
Circuito de demanda
O circuito de demanda é um recurso do Cisco IOS 11.2 que também pode ser usado em redes hub-and-spoke. Geralmente, esse recurso é útil em cenários de backup de discagem e nos ambientes SVC (Circuito Virtual Comutado) X.25 ou Frame Relay. Veja a seguir um exemplo de configuração de um circuito de demanda:
router ospf 1
network 1.1.1.0 0.0.0.255 area 1
area 1 stub no-summary
interface Serial0 /* Link to the hub router */
ip address 1.1.1.1 255.255.255.0
ip ospf demand-circuit
clockrate 56000
Spoke#show ip o int s0
Serial0 is up, line protocol is up
Internet Address 1.1.1.1/24, Area 1
Process ID 1, Router ID 141.108.4.2, Network Type POINT_TO_POINT, Cost: 64
Configured as demand circuit.
Run as demand circuit.
DoNotAge LSA not allowed (Number of DCbitless LSA is 1).
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:06
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 130.2.4.2
Suppress hello for 0 neighbor(s)
Usar o recurso de circuito de demanda em uma rede do tipo hub-e-spoke fará com que o circuito seja ativado e forme uma nova adjacência caso exista qualquer alteração na topologia. Por exemplo, se houver uma subrede em um spoke sincronizado, o circuito de demanda criará a adjacência e deixará essas informações fluírem. Em um ambiente de área "stubby", essas informações serão inundadas nessa área de stub. O ODR soluciona esse problema não permitindo que essas informações vazem para outros spokes. Consulte o recurso Circuito de demanda OSPF para obter mais informações.
ODR com redes ponto-a-ponto
O status atual do Cisco IOS 12.0 nos limites do Interface Descriptor Block (IDB) é o seguinte:
| Router | Limite |
|---|---|
| 1000 | 300 |
| 2600 | 300 |
| 3600 | 800 |
| 4x00 | 300 |
| 5200 | 300 |
| 5300 | 700 |
| 5800 | 3000 |
| 7200 | 3000 |
| RSP | 1000 |
Antes do IOS 12.0, o número máximo de spokes que um hub poderia suportar era 300 devido aos limites do IDB. Se uma rede exigia mais de 300 spokes, a configuração ponto a ponto não era uma boa opção. Além disso, um pacote CDP separado foi gerado para cada link. A complexidade de tempo para enviar atualizações de CDP em links ponto-a-ponto é n2. A tabela acima apresenta os limites de IDB para diferentes plataformas. O número máximo de spokes suportados em cada plataforma varia, mas o overhead de criação de um pacote de CDP separado para cada enlace ainda é uma emissão. Portanto, em uma situação de hub e spoke grandes, configurar uma interface ponto a multiponto é uma solução melhor do que uma interface ponto a ponto.
ODR com redes ponto a multiponto
Em uma rede de ponto para multiponto em que um hub oferece suporte para vários spokes, existem três problemas essenciais:
-
O hub pode suportar facilmente mais de 300 spokes. Por exemplo, uma rede 10.10.0.0/22 seria capaz de suportar 1024-2 spokes com uma interface multiponto.
-
Em um ambiente multiponto, um pacote CDP é gerado para todos os vizinhos e é replicado na camada 2. A complexidade de tempo da atualização do CDP é reduzida a n.
-
Em uma configuração ponto a multiponto, você pode atribuir apenas uma sub-rede a todos os spokes.
ODR e vários fornecedores
Um conceito equivocado comum é que o ODR não funcionará se vários fornecedores forem usados. O ODR funcionará enquanto a rede for uma rede de hub-and-spoke verdadeira. Por exemplo, se houver uns 100 spokes e dois deles forem roteadores de um fornecedor diferente, então será possível ativar um Routing Protocol nos links que se conectam aos roteadores diferentes e ainda executar o ODR nos 98 spokes Cisco restantes.
Figura 6: ODR com vários fornecedores 
O roteador de hub conectado aos 98 roteadores Cisco receberá atualizações de sub-rede por meio do ODR e receberá atualizações de protocolo de roteamento dos dois roteadores restantes diferentes. Os enlaces que conectam roteadores diferentes devem estar em diferentes sub-redes ponto a ponto e ponto a multipontos.
Problemas de crescimento futuro
Se uma organização estiver executando o ODR em 100 spokes, ela pode querer alterar sua topologia de uma rede hub-and-spoke. Por exemplo, ela pode decidir atualizar um spoke para uma plataforma maior, tornando esse spoke um hub por 20 outros novos spokes.
Figura 7: Crescimento futuro 
É possível executar um Routing Protocol no novo hub e ainda manter o design ODR como está. Se o novo hub oferecer suporte para 20 ou mais novos spokes, o ODR poderá ser executado no novo hub. O novo hub pode detectar essas novas sub-redes de spoke por meio do ODR e redistribuir essas informações ao hub original por meio de outro Routing Protocol.
Essa situação é semelhante àquela em que o ODR inicia com dois hubs. Não há sobrecarga de protocolos de alteração. Basicamente, ODR pode ser executado, desde que o roteador seja um stub.
Desempenho
Várias configurações podem ser ajustadas para convergência mais rápida e melhor desempenho ao executar o ODR.
Ajuste de cronômetro para convergência mais rápida
Em um ambiente ODR grande, ajuste os temporizadores de ODR para convergência mais rápida e aumente os temporizadores atualização de CDP, a partir do hub, para que o spoke minimize o desempenho da CPU do hub.
Roteador de Hub
O cronômetro de atualização de CDP deve assumir 60 segundos como padrão para reduzir a quantidade de tráfego do hub para os spokes. O tempo de espera deve ser aumentado até o máximo (255 segundos). Como o roteador do hub precisa manter várias tabelas de adjacência de CDP e no caso de alguns vizinhos serem desativados, não exclua as entradas CDP da memória por 255 segundos (o tempo de holddown máximo permitido). Essa configuração proporcionará flexibilidade ao roteador de hub porque se o vizinho entrar em backup dentro de quatro minutos, as adjacências de CDP não terão que ser recriadas. A antiga entrada na tabela pode ser usada e o temporizador de holdown pode ser atualizado.
Este é um exemplo de molde de configuração IP para um roteador central:
cdp holdtime 255
router odr
timers basic 8 24 0 1 /* odr timer's are update, invalid, hold down, flush
router eigrp 1
network 10.0.0.0
redistribute odr
default-metric 1 1 1 1 1
Há três circuitos virtuais permanentes (PVCs) em cada local remoto (depósito, região e estação). Dois dos PVCs vão para roteadores centrais separados. O terceiro PVC vai para o roteador PayPoint. É obrigatório usar a rota PVC para PayPoint para o tráfego destinado à rede PayPoint. Os outros dois PVCs servem funções primárias e de backup para todo o tráfego restante. Com base nesses requisitos, consulte o modelo de configuração abaixo para cada roteador remoto.
É muito importante ajustar os temporizadores de ODR, tais como invalid, holddown e flush, para uma convergência mais rápida. Mesmo quando o CDP não envia um prefixo IP após a configuração do roteador odr, o temporizador de atualização de ODR deve coincidir com o temporizador de atualização de CDP vizinho, pois o temporizador de convergência só poderá ser configurado se houver um temporizador de atualização. Esse temporizador é diferente do temporizador do CDP e só pode ser utilizado para convergências mais rápidas.
Spoke Router
Como os raios estão enviando atualizações ORD em pacotes CDP, o cronômetro de atualizações CDP deverá ser mantido bem pequeno para convergência mais rápida. Em um ambiente de raio verdadeiro, não há restrição para o tempo de holddown para o CDP vizinho, uma vez que há apenas algumas entradas para o raio manter em sua tabela de CDP. O tempo de retenção máximo de 255 segundos é recomendado para que se o PVC do hub ficar inativo e voltar dentro de quatro minutos, nenhuma adjacência CDP nova seja necessária porque a entrada da tabela antiga pode ser usada.
Veja a seguir um exemplo de um modelo de configuração IP para um site remoto:
cdp timer 8
cdp holdtime 255
interface serial 0
encapsulation frame-relay
cdp enable
interface serial 0.1 point /* Primary PVC */
ip address 10.x.x.x 255.255.255.0
frame-relay interface-dlci XX
interface serial 0.2 point /* Secondary PVC */
ip address 10.y.y.y 255.255.255.0
frame-relay interface-dlci XX
interface bri 0
interface BRI0
description Backup ISDN for frame-relay
ip address 10.c.d.e 255.255.255.0
encapsulation PPP
dialer idle-timeout 240
dialer wait-for-carrier-time 60
dialer map IP 10.x.x.x name ROUTER2 broadcast xxxxxxxxx
ppp authentication chap
dialer-group 1
isdn spid1 xxxxxxx
isdn spid2 xxxxxxx
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 LIST 101
/* following are the static routes that need to be configured on the remote routers
ip route 0.0.0.0 0.0.0.0 10.x.x.x
ip route 0.0.0.0 0.0.0.0 10.y.y.y
ip route 0.0.0.0 0.0.0.0 bri 0 100
ip classless
As rotas estáticas padrão são serão necessárias se você estiver usando o IOS 12.0.5T ou posterior, pois o roteador de hub envia a rota padrão automaticamente em direção a todos os spokes.
Filtro e sumarização das rotas ODR
Rotas ODR podem ser filtradas antes de vazarem para o centro. Use a lista de distribuição no comando. Todas as sub-redes conectadas dos spokes deve ser resumidas durante o vazamento no centro. Se a sumarização não for possível, as rotas desnecessárias poderão ser filtradas no roteador de hub. Em várias redes de hub, os spokes podem anunciar a interface conectada que é o link para outro hub.
Nessa situação, o comando distribute-list deve ser aplicado para que o hub não coloque essas rotas na tabela de roteamento. Quando o ODR é redistribuído no hub, tal informação não é vazada para o centro.
Ajuste do cronômetro Telco
É importante ajustar o temporizador da empresa de telecomunicações para aumentar o tempo de convergência dos spokes. Se o PVC do lado do hub diminuir, os spokes deverão ser capazes de detectar isso rapidamente para comutar para o segundo hub.
Desempenho da CPU
O processo ODR não exige muita utilização da CPU. ODR foi testado em cerca de 1.000 vizinhos com 3 a 4% de utilização da CPU. A configuração do cronômetro assertivo do ODR no hub é util para convergência mais rápida. Se as configurações padrão forem usadas, a utilização da CPU permanecerá entre 0 e 1 por cento.
Mesmo com cronômetros agressivos ODR e CDP, a saída a seguir mostra que não havia uma utilização alta da CPU. Este teste foi realizado com um processador de 150 MHz em um Cisco 7206.
Hub# show proc cpu
CPU utilization for five seconds: 4%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11588036 15783316 734 0.73% 1.74% 1.95% 0 CDP Protocol
.
.
48 3864 5736 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11588484 15783850 734 2.21% 1.83% 1.96% 0 CDP Protocol
.
.
48 3864 5736 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11588676 15784090 734 1.31% 1.79% 1.95% 0 CDP Protocol
.
.
48 3864 5736 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 1%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11588824 15784283 734 0.65% 1.76% 1.94% 0 CDP Protocol
.
.
48 3864 5737 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11589004 15784473 734 1.96% 1.85% 1.95% 0 CDP Protocol
.
.
48 3864 5737 673 0.00% 0.00% 0.00% 0 ODR Router
Hub# show proc cpu
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
.
.
18 11589188 15784661 734 1.63% 1.83% 1.94% 0 CDP Protocol
.
.
48 3864 5737 673 0.00% 0.00% 0.00% 0 ODR Router
Melhorias
A versão do ODR antes do Cisco IOS 12.0.5T tinha algumas limitações. A seguir é apresentada a lista de aperfeiçoamentos no Cisco IOS 12.0.5T e posterior:
-
Antes de CSCdy48736, as sub-redes secundárias são anunciadas como /32 em uma atualização de CDP. Isso será corrigido na versão 12.2.13T e mais recente.
-
Os hubs CDP agora propagam rotas padrão para os spokes, portanto, não há nenhuma necessidade de adicionar rotas padrão estáticas aos spokes. O tempo de convergência aumenta significativamente. Quando o próximo salto é desativado, o spoke o detecta rapidamente via ODR e converge. Esse recurso é adicionado em 12.0.5T através do bug CSCdk91586.
-
Se o enlace entre o concentrador e os pontos remotos for IP não numerado, a rota padrão enviada pelo concentrador pode não ser vista nos pontos remotos. Este erro, CSCdx66917, é corrigido no IOS 12.2.14, 12.2.14T e posteriores.
-
Para aumentar/diminuir a distância ODR nos spokes, de modo que eles possam preferir um hub em relação ao outro, foi feita uma sugestão que está sendo rastreada via CSCdr35460. O código já foi testado e estará disponível em breve para os clientes.
Feedback