IP : On-Demand Routing (ODR)

Projetando redes stub de larga escala com ODR

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

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 de Um ou Mais Servidores Cisco ICM NT, a versão do½ do¿Â do Cisco IOSï que é executado no dispositivo Cisco vizinho, as capacidades 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 de stub através do 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 levar a informação da máscara de sub-rede de comprimento variável (VLS).

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, é frequentemente 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 esta'n ao configurar-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 aplicação, e a interação do ODR com outros protocolos de IP Routing 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 através da 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. Esta configuração ocorre quando um spoke é conectado a um 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. As caixas Low-end têm geralmente uma ou dois interfaces de 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 onde haja uma grande atualização 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, lá pode estar mais de um hub, para fins de redundância ou apoiar o spokes adicional através de um concentrador 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

odrhs.jpg

Comunica-se com um único ponto de saída

Em figura 1 acima, o spokes é conectado a um hub de modo que possam confiar no gateway padrão em vez de receber toda a informação de roteamento para o hub com um ponto de saída. Não é necessário passar toda a informação ao spokes, desde que um spoke não terá que fazer uma decisão inteligente de roteamento. Um spoke enviará sempre o tráfego ao hub, assim que a necessidade do spokes somente uma rota padrão que aponta 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 o ODR, contudo, os protocolos de roteamento não precisam de ser permitidos no lado de raio. Com ODR, somente o Cisco IOS 11.2 e uma rota padrão estática que aponta para um hub são precisados 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.

O spokes deve ser ponto a ponto, se não a rota padrão da 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 spoke utilizará o enlace primário e, quando este cair, a rota estática de flutuação passará a funcionar. 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.

Nota: Hoje, não há nenhum outro método no lado de raio para preferir um link sobre o outro em uma situação do concentrador único, exceto como 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. Isto cancela automaticamente as rotas padrão que estão vindo no spokes através do 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

/image/gif/paws/13710/odr3.jpg

Balanceamento de carga ou backup com diversos concentradores

Essas configurações também podem ser utilizadas para o balanceamento de carga ou backups quando há vários hubs. Todo o Hubs deve inteiramente ser engrenado de modo que se um dos links do spokes falha, o destino possa ainda ser alcançado através de um segundo hub. Veja o ODR contra. A outra seção dos protocolos de roteamento deste documento para mais explicação detalhada. Similarmente, no caso do Hubs múltiplo, se os IO estão 12.0.5T ou mais tarde no usado, o Hubs envia as rotas padrão ODR ao spokes e o spokes instala ambos na tabela de roteamento. Um aprimoramento futuro permitirá que um ponto remoto prefira um concentrador a outro. Atualmente, isto pode ser feito através de uma rota padrão estática definida no roteador e no uso do raio da distância administrativa no comando da rota estática preferir um hub sobre o 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

/image/gif/paws/13710/odr4.jpg

ODR contra. 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. Largura de banda do desperdício do spokes do enlace lento nas atualizações de roteamento e em relacionamentos vizinho de manutenção. 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, nós temos uns novos recursos no EIGRP que escala o EIGRP muito melhor em uma situação do hub and spoke. Refira o roteamento de stub do IGRP aprimorado para obter mais informações sobre da característica do stub 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 é permitido em 100 spokes conectados por uma configuração Point-to-Point. 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. Contudo, um flap em uma área de stub ainda provocará o SPF para ser executado no spokes, assim que estas despesas gerais não podem ser curadas fazendo uma área de stub pequena sem o sumário e os nenhuns externals.

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.

Promover a uma plataforma melhor não é uma solução permanente; contudo, o ODR fornece 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.

Olá! a tempestade

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 os pacotes Hello compreendidos de 20 bytes do cabeçalho IP, dos 24 encabeçamentos dos bytes de OSPF, dos 20 bytes dos parâmetros de hello, e dos 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 de hello de OSPF para 100 vizinhos

cabeçalho IP de 20 bytes
24 cabeçalhos de OSPF dos 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. Tais tipos de conexão podem passar a qualquer um muito quase nenhum tráfego de dados durante a operação normal.

O comportamento periódico do RIP causa problemas nesses circuitos. O RASGO tem problemas com largura de banda baixa, interfaces Point-to-Point. 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.

Triggered RIP

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 é girado primeiramente sobre.

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 triggered deve ser configurado na relação do roteador de hub que conecta ao spokes.

Ao comparar o RIPv2 ao ODR, o ODR é uma escolha melhor porque o RIPv2 trabalha 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 trabalha melhor em uma rede em larga escala do que todo o 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. Escolha sempre uma rede falsa entre o hub e o spokes assim que aqueles links não serão incluídos no domínio de EIGRP porque você não porá 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 as rotas específicas são perdidas de um do spokes, mande as perguntas a todos os vizinhos nos roteadores centrais.

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. Enquanto o link entre os dois Hubs não está na mesma rede principal que o spokes, a configuração deve trabalhar corretamente.

Figura 4: Redundância e resumo: O núcleo está recebendo rotas resumidas

/image/gif/paws/13710/odr7.jpg

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 and spoke vai para baixo, é 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 é permitido no link, e em um link específico está batendo constantemente, ele pode causar diversos problemas, incluindo a execução de SPF, regeneração do LSA de roteador, regeneração do LSA sumário, e assim por diante. Ao executar o ODR, não inclua o enlace serial conectado no domínio de OSPF. A preocupação principal é receber a informação do segmento de LAN do 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. Não pode ser detectada se a informação do roteador central é resumida.

Figura 5: Redundância e resumo: O roteador base está recebendo rotas resumidas

/image/gif/paws/13710/odr6.jpg

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 aprimoramento futuro

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.

Seguir é um exemplo de configuração usando o 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, uma informação mais específica é recebida de ambo o Hubs. Desde que a distância OSPF é 110 e a distância ODR é 160, a informação interferirá com o ODR quando é recebida da outra sub-rede mais ou menos idêntica do hub. O outro hub terá sempre a preferência para obter o destino do spoke, o que causará um roteamento não ideal. Para remediar a situação, diminua a distância ODR a menos de 110 com o comando distance, de modo que a rota ODR seja preferida sempre sobre a rota de OSPF. Se a rota ODR falha, a rota externa OSPF estará instalada na tabela de roteamento do base 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 da procura

O circuito da procura é uma característica do Cisco IOS 11.2 que possa igualmente ser usada nas redes de 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 de IO 12.0, o número máximo de spoke que um hub poderia apoiar era 300 devido aos limites IDB. Se uma rede exigiu mais de 300 spokes, a seguir a configuração de ponto a ponto não era uma boa escolha. Além disso, um pacote CDP separado foi gerado para cada link. A complexidade de tempo para enviar atualizações de CDP nos link de 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. Consequentemente, em uma grande situação do hub and spoke, configurar uma interface ponto a multiponto é uma solução melhor do que uma interface Point-to-Point.

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 de CDP é gerado para todos os vizinhos e replicated 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 somente uma sub-rede a todo o spokes.

ODR e vários fornecedores

Uma concepção errada comum é que o ODR não trabalhará se os fornecedores múltiplos são 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

odr10.jpg

O roteador de hub conectado aos 98 roteadores Cisco receberá atualizações da sub-rede com o ODR e receberá atualizações de protocolo de roteamento dos dois Roteadores diferentes permanecendo. 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 está executando o ODR em 100 spokes, eventualmente podem querer mudar sua topologia de uma rede de 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

/image/gif/paws/13710/odr9.jpg

É 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á nenhuma carga adicional 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. Baseado nestas exigências, veja o gabarito 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 máximo de holddown de 255 segundos é recomendado de modo que se o hub PVC vai para baixo e volta dentro de quatro minutos, nenhuma adjacência de CDP nova seja precisada porque a entrada de tabela idosa pode ser usada.

Seguir é um exemplo de um molde da configuração IP para um local 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 redes do hub múltiplo, o spokes pode anunciar a interface conectada que é o link a um 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 toma o lote da utilização 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 executado com um processador de mhz 150 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 salto seguinte vai para baixo, o spoke detecta-o rapidamente através do ODR e convirge-o. Esta característica é adicionada em 12.0.5T através do erro 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/diminua a distância ODR no spokes assim que podem preferir um hub sobre o outro, uma sugestão foram feitos que esteja sendo seguida através de CSCdr35460. O código já tem sido testado e estará disponível logo para clientes.


Informações Relacionadas


Document ID: 13710