NESTA PÁGINA
Visão geral da configuração do pool de atribuição de endereços
Configurando um nome e endereços do pool de atribuição de endereços
Configurando uma faixa de endereço nomeada para atribuição dinâmica de endereços
Impedindo que endereços sejam alocados em um pool de endereços
Configuração de armadilhas de limite de uso do pool de atribuição de endereços
Configuração do hold-down do pool de atribuição de endereços
Configuração do pool de endereços local DHCP Rapidamente dreno
Configuração de proteção de endereço IPv4 duplicada para AAA
Pools de atribuição de endereços para gerenciamento de assinantes
Visão geral dos pools de atribuição de endereços
O pool de atribuição de endereços permite que você crie pools de endereçoS IPv4 e IPv6 centralizados independentemente dos aplicativos de clientes que usam os pools. O processo authd gerencia os pools e a alocação de endereços, sejam eles provenientes de pools locais ou de um servidor RADIUS.
Por exemplo, vários aplicativos de clientes, como o DHCP, podem usar o mesmo pool de atribuição de endereços para fornecer endereços para seus clientes em particular. Os aplicativos do cliente podem adquirir endereços para clientes autenticados ou não autenticados. O pool selecionado para um assinante, com base no servidor RADIUS ou correspondência de rede ou outra regra, é chamado de pool de correspondência para o assinante.
- Tipos de atribuição de endereços
- Faixas de endereço nomeadas no pool de atribuição de endereços
- Alocação de endereços de pools de endereços vinculados
- Estado de hold-down do pool de endereços
- Pool de atribuição de endereços para anúncio do roteador Neighbor Discovery
- Excluindo endereço ou faixa de endereço especificados
- Requisito de licenciamento
- Benefícios dos pools de atribuição de endereços
Tipos de atribuição de endereços
Os pools de atribuição de endereços oferecem suporte à atribuição dinâmica e estática de endereços. Na atribuição dinâmica do endereço, um cliente recebe automaticamente um endereço do pool de atribuição de endereços. Na atribuição de endereços estáticos, que é suportada apenas para pools IPv4, você reserva um endereço que é sempre usado por um cliente específico. Os endereços reservados para atribuição estática são removidos do pool de endereços dinâmico e não podem ser atribuídos a outros clientes.
Faixas de endereço nomeadas no pool de atribuição de endereços
Você pode configurar faixas de endereço nomeadas em um pool de atribuição de endereços. Uma faixa nomeada é um subconjunto da faixa de endereço geral. Um aplicativo de cliente pode usar faixas nomeadas para gerenciar a atribuição de endereços com base em critérios específicos do cliente. Por exemplo, para pools de atribuição de endereço IPv4, você pode criar uma faixa nomeada baseada em um valor específico da opção DHCP 82. Em seguida, quando uma solicitação de cliente DHCP corresponde ao valor especificado da opção 82, um endereço da faixa especificada é atribuído ao cliente.
Alocação de endereços de pools de endereços vinculados
Você pode vincular pools de atribuição de endereços juntos para fornecer pools de backup para atribuição de endereços. Quando nenhum endereço está disponível no pool de endereços principal ou correspondente, o dispositivo prossegue automaticamente para o pool de endereços vinculado (secundário) para procurar um endereço disponível para alocar.
Embora o primeiro pool em uma cadeia de pools vinculados seja geralmente considerado o pool principal, uma piscina de correspondência não é necessariamente o primeiro pool da cadeia.
A partir do Junos OS Release 18.1R1, o mecanismo de pesquisa de um endereço disponível prossegue por meio de uma cadeia de pools vinculados. Esse comportamento permite que o DHCP pesquise endereços contíguamente..
Vamos usar um exemplo de como o mecanismo de pesquisa funciona. Considere uma cadeia de três pools: A, B e C. Pool A é o pool principal, o Pool B é o pool de correspondência para determinados assinantes com base nas informações devolvidas pelo servidor RADIUS. A busca por um endereço disponível para esses assinantes usa a sequência a seguir:
Por padrão, o pool de correspondência (Pool B) é pesquisado primeiro.
A pesquisa se move para o primeiro pool (Pool A) na cadeia se o endereço não for encontrado.
A pesquisa prossegue pela cadeia (Pool C) até que um endereço disponível seja encontrado e alocado, ou até que a pesquisa determine que nenhum endereço seja gratuito.
Em cada pool, todas as faixas de endereços são totalmente pesquisadas em busca de um endereço.
Você pode configurar a linked-pool-aggregation declaração para começar a pesquisar em um bloco de endereços em cada faixa no pool de correspondência e, em seguida, sucessivamente através dos pools vinculados. Em seguida, a pesquisa volta para o primeiro pool da cadeia e pesquisa todos os endereços em todas as faixas em cada pool através do último pool da cadeia.
Estado de hold-down do pool de endereços
Você pode configurar um pool de atribuição de endereços em estado de espera. Quando o pool de endereços está em estado de espera, o pool não está mais disponível para alocar endereços IP para os assinantes. Essa configuração transforma graciosamente o pool ativo em um estado inativo à medida que os endereços alocados anteriormente são devolvidos ao pool. Quando o pool está inativo, você pode realizar a manutenção com segurança no pool sem afetar nenhum assinante ativo.
Pool de atribuição de endereços para anúncio do roteador Neighbor Discovery
Você pode alocar explicitamente um pool de atribuição de endereços para o Neighbor Discovery Router Advertisement (NDRA).
Excluindo endereço ou faixa de endereço especificados
A partir do Junos OS Release 18.1R1, você pode excluir um endereço ou variedade de endereços consecutivos especificados para evitar que eles sejam alocados em um pool de endereços.
Por exemplo, você pode querer reservar certos endereços ou faixas para serem usados apenas para assinantes estáticos. Quando você configura um endereço ou faixa a ser excluído, e o endereço ou um endereço dentro da faixa, já foi alocado, esse assinante está logado, o endereço é alocado no negócio e o endereço está marcado para exclusão.
Requisito de licenciamento
Esse recurso requer uma licença. Para entender mais sobre o licenciamento de acesso ao assinante, consulte a visão geral do licenciamento de acesso ao assinante. Consulte o Guia de Licenciamento da Juniper para obter informações gerais sobre o gerenciamento de licenças. Consulte as folhas de dados do produto para obter detalhes ou entre em contato com sua equipe de conta da Juniper ou com o Parceiro da Juniper.
Benefícios dos pools de atribuição de endereços
O recurso de pool de atribuição de endereços oferece suporte ao gerenciamento de assinantes e ao gerenciamento DHCP.
Você pode criar pools centralizados de endereços independentemente dos aplicativos dos clientes.
Você pode especificar blocos de endereços, faixas nomeadas, para que um determinado pool de endereços possa ser usado para fornecer endereços diferentes para diferentes aplicativos de clientes ou para assinantes que correspondam a diferentes conjuntos de critérios.
Você pode vincular pools juntos para garantir que os pools sejam pesquisados em busca de endereços gratuitos de maneira específica, contígua ou não.
Você pode fazer a transição graciosa de um pool de endereços de ativo para inativo, especificando que nenhum outro endereço é alocado no pool.
Alocação de endereços de pools de endereços vinculados
Você pode vincular pools de atribuição de endereço em uma cadeia para fornecer pools de backup para atribuição de endereços. O pool selecionado para um assinante, com base no servidor RADIUS ou correspondência de rede ou alguma outra regra, é chamado de pool correspondente ou combinado para o assinante. O pool de correspondência pode não ser o primeiro pool (principal) da cadeia. Quando não há endereços disponíveis para alocação no pool de endereços principal ou correspondente, o roteador ou switch prossegue automaticamente para outro pool de endereços para procurar um endereço disponível para alocar. Quando a pesquisa descobre nenhum endereço disponível em nenhum lugar, a pesquisa para e nenhum endereço é alocado para o assinante.
O comportamento da pesquisa determina não apenas como a pesquisa progride ao longo de uma cadeia de pools vinculados, mas quais faixas de endereço dentro de cada pool são pesquisadas. Dependendo de onde a pesquisa começa, sua configuração e se endereços alocados anteriormente foram liberados, a pesquisa pode continuar no próximo pool de endereços vinculados na cadeia ou voltar para o primeiro pool da cadeia.
A busca por um endereço disponível começa no pool que combina com o assinante. Em muitos casos, o pool de correspondência também é o primeiro pool da cadeia. Para alguns assinantes, o pool de correspondência está mais abaixo da cadeia. Por exemplo, você pode configurar o servidor RADIUS para especificar o segundo pool de uma cadeia em vez do primeiro com base em alguns critérios que ele combina durante a autenticação. Por outro exemplo, você pode especificar diferentes faixas de endereço para diferentes grupos de assinantes; se um pool específico corresponde a um assinante, então depende de quais pools estão configurados para as diferentes faixas de endereço.
Os termos a seguir são usados para explicar os detalhes do comportamento da pesquisa:
lowAddress — o endereço mais baixo em uma determinada faixa dentro de um pool de endereços.
highAddress — o endereço mais alto de uma determinada faixa em um pool de endereços.
nextAddress — O próximo endereço após o último endereço alocado em uma determinada faixa dentro de um pool de endereços. Este é o endereço esperado para ser alocado em seguida. Este endereço, bem como a última faixa usada, é salvo como um ponto de partida para pesquisas.
Por exemplo, suponha que o Pool A tenha uma única faixa que inclua os seguintes endereços: 192.0.2.1, 192.0.2.2, 192.0.2.3, 192.0.2.4. Nesse caso, 192.0.2.1 é o baixoAddress e 190.0.2.4 é o highAddress. Se 192.0.2.2.2 foi o último endereço alocado deste pool, o próximoAddress é 192.0.2.3.
A partir do Junos OS Release 18.1R1, você pode configurar pools vinculados a serem pesquisados de duas maneiras:
Alocação de endereço contíguo — Esse é o comportamento padrão. Todos os endereços de cada faixa de um pool são pesquisados. A busca começa na piscina combinada, depois muda para o primeiro pool da cadeia e, se necessário, continua por cada pool vinculado sucessivamente até o último pool da cadeia. Em cada pool, todos os endereços de todas as faixas são pesquisados por um endereço gratuito. Esse método permite que os endereços sejam atribuídos contíguamente; cada pool precisa estar cheio antes que outro pool seja pesquisado.
Alocação de endereço não consistente (agregada) — Comportamento quando a
linked-pool-aggregationdeclaração estiver configurada. Inicialmente, apenas certos endereços (do nextAddress ao highAddress) são pesquisados em cada faixa do pool combinado. A mesma pesquisa é realizada no pool vinculado e, se necessário, continua por cada pool vinculado sucessivamente até o último pool da cadeia.A pesquisa é reiniciada no primeiro pool da cadeia (não necessariamente no pool combinado). Desta vez, todos os endereços de todas as faixas são pesquisados, em todos os pools até o fim da cadeia.
Essa é a funcionalidade básica, mas os detalhes de ambas as pesquisas são bastante complexos. A Figura 1 mostra o comportamento padrão de pesquisa.
Por exemplo, suponha que as seguintes condições existam:
Os pools de endereços vinculados A, B, C e D. Pool C são combinados.
Cada pool tem três faixas de endereço, r1, r2, r3. A última faixa usada foi r2 em cada pool.
Se nenhum endereço gratuito for encontrado, a pesquisa prossegue assim: C > A > B > C > D, então pára.
O Pool C é pesquisado no nextAddress por highAddress na faixa r2.
O Pool C é pesquisado, com baixoadress por meio do nextAddress na faixa r2.
O Pool C é pesquisado no nextAddress por highAddress na faixa r3.
O Pool C é pesquisado, com baixoadress por meio do nextAddress na faixa r3.
O Pool C é pesquisado no próximoAddress por highAddress na faixa r1.
O Pool C é pesquisado, com baixoadress por meio do nextAddress na faixa r1.
Todas as faixas e endereços do grupo C foram pesquisados, então a pesquisa se move para o primeiro pool da cadeia, A.
O Pool A é pesquisado no nextAddress por highAddress na faixa r2.
O Pool A é pesquisado, com baixoaddress por meio do nextAddress na faixa r2.
O Pool A é pesquisado no nextAddress por highAddress na faixa r3.
O Pool A é pesquisado, com baixoadress por meio do nextAddress na faixa r3.
O Pool A é pesquisado no nextAddress por highAddress na faixa r1.
O Pool A é pesquisado, com baixoaddress por meio do nextAddress na faixa r1.
Todas as faixas e endereços do grupo A foram pesquisados, então a pesquisa passa para o próximo pool vinculado na cadeia, B.
Esse processo continua até que todos os endereços de todas as faixas em todos os pools tenham sido pesquisados. O pedido de pesquisa na piscina é C > A > B > C > D, e depois para. Dependendo de onde e se um endereço é encontrado, o pool de correspondência pode ser pesquisado duas vezes. Isso é verdade, a menos que o pool de correspondência seja o primeiro pool da cadeia. Por exemplo, se o pool A for o pool correspondente neste conjunto de condições, então a pesquisa completa (supondo que nenhum endereço seja encontrado) seria A > B > C > D.
A Figura 2 mostra o comportamento da pesquisa quando você inclui a linked-pool-aggregation declaração.
Por exemplo, considere que as mesmas condições existem como para o exemplo padrão:
Os pools de endereços vinculados A, B, C e D. Pool C são combinados.
Cada pool tem três faixas de endereço, r1, r2, r3. A última faixa usada foi r2 em cada pool.
Se nenhum endereço gratuito for encontrado, a pesquisa prossegue assim: C > D > A > B > C > D, então pára.
O Pool C é pesquisado no nextAddress por highAddress na faixa r2.
O Pool C é pesquisado no nextAddress por highAddress na faixa r3.
O Pool C é pesquisado no próximoAddress por highAddress na faixa r1.
Todas as faixas do pool C foram pesquisadas de nextAddress a highAddress, de modo que a pesquisa se move para o próximo pool vinculado na cadeia, D.
O Pool D é pesquisado no nextAddress por highAddress na faixa r2.
O Pool D é pesquisado no próximoAddress por highAddress na faixa r3.
O Pool D é pesquisado no próximoAddress por highAddress na faixa r1.
Todas as faixas do pool D foram pesquisadas desde o nextAddress até o highAddress. O Pool D é o último pool da cadeia, então a pesquisa se move para o primeiro pool da cadeia, A.
O Pool A é pesquisado, com baixoaddress por highAddress na faixa r2.
O Pool A é pesquisado, com baixoaddress por highAddress na faixa r3.
O Pool A é pesquisado e lowAddress por highAddress na faixa r1.
Todas as faixas e endereços do grupo A foram pesquisados, então a pesquisa passa para o próximo pool vinculado na cadeia, B.
O Pool B é pesquisado, com baixoaddress por highAddress na faixa r2.
O pool B é pesquisado, com baixoaddress por highAddress na faixa r3.
O Pool B é pesquisado, com baixoaddress por highAddress na faixa r1.
Todas as faixas e endereços do grupo B foram pesquisados, então a pesquisa se move para o próximo pool vinculado na cadeia, C.
Esse processo continua até que todos os endereços de todas as faixas em todos os pools tenham sido pesquisados. A ordem de pesquisa do pool é C > D > A > B > C > D, depois para. Dependendo de onde e se um endereço é encontrado, todas as piscinas podem ser pesquisadas duas vezes, mesmo quando a piscina de correspondência é o primeiro pool da cadeia. Por exemplo, se o pool A for o pool correspondente neste conjunto de condições, então a pesquisa completa (supondo que nenhum endereço seja encontrado) seria A > B > C > D > A > B > C > D.
Visão geral da configuração do pool de atribuição de endereços
O recurso de pool de atribuição de endereços oferece suporte à funcionalidade de gerenciamento de assinantes, permitindo que você crie pools de endereços que podem ser compartilhados por diferentes aplicativos de clientes. Um pool de atribuição de endereços pode oferecer suporte a endereçoS IPv4 ou endereços IPv6. Você não pode usar o mesmo pool para ambos os tipos de endereço.
Os pools de atribuição de endereços são completamente separados dos serviços L2TP LNS baseados em PIC, que você cria com a address-pool declaração no nível de [edit access] hierarquia e os pools NAT, que você cria com a pool declaração no nível de [edit services nat] hierarquia.
Para configurar um pool de atribuição de endereços:
Veja também
Configurando um nome e endereços do pool de atribuição de endereços
Para configurar um pool de atribuição de endereços, você deve especificar o nome do pool e configurar os endereços para o pool.
Para configurar um pool de atribuição de endereço IPv4:
Para configurar um pool de atribuição de endereço IPv6:
Configure o nome do pool e especifique a família IPv6.
[edit access] user@host# edit address-assignment pool isp_2 family inet6
Configure o prefixo de rede IPv6 para o pool de endereços. A especificação do prefixo é necessária quando você configura um pool de atribuição de endereço IPv6.
[edit access address-assignment pool isp_2 family inet6] user@host# set prefix 2001:db8:2008:2009::/32
Configurando uma faixa de endereço nomeada para atribuição dinâmica de endereços
Você pode configurar opcionalmente várias faixas ou subconjuntos nomeados de endereços em um pool de atribuição de endereços. Durante a atribuição dinâmica do endereço, um cliente pode receber um endereço de uma faixa específica nomeada. Para criar uma faixa nomeada, você especifica um nome para a faixa e define a faixa de endereço.
Para criar uma faixa nomeada dentro de um pool de atribuição de endereço IPv4:
Para criar uma faixa nomeada dentro de um pool de atribuição de endereço IPv6:
Especifique o nome do pool de atribuição de endereços e da família IPv6.
[edit access] user@host# edit address-assignment pool isp_2 family inet6
Configure o nome da faixa e defina o intervalo. Você pode definir a faixa com base nos limites inferior e superior dos prefixos da faixa, ou com base no comprimento dos prefixos na faixa.
[edit access address-assignment pool isp_2 family inet6] user@host# set range dsl-range low 2001:db8:2008:2010:2011:0100::/64 high 2001:db8:2008:2010:2011:ffff::/64 user@host# set range fiber-east prefix-length 48
Impedindo que endereços sejam alocados em um pool de endereços
Você pode excluir endereços ou faixas de endereço especificados para evitar que eles sejam alocados em um pool de endereços. Por exemplo, você pode querer reservar certos endereços ou faixas para serem usados apenas para assinantes estáticos. Quando você configura um endereço ou variedade de endereços a serem excluídos, e o endereço ou um endereço dentro da faixa já foi alocado, que o assinante alocado nesse endereço está logado, o endereço é alocado no negócio e o endereço está marcado para exclusão.
Para excluir um endereço ou variedade de endereços em um pool de endereços de serem alocados:
Especifique um endereço individual.
[edit access address-assignment pool-name family (inet | inet6)] user@host# set excluded-address ip-address
Especifique e nomeie uma variedade de endereços consecutivos.
[edit access address-assignment pool-name family (inet | inet6)] user@host# set excluded-range name low minimum-value high maximum-value
Por exemplo, a seguinte configuração parcial para um pool de endereços IPv4 define uma faixa, r1, de endereços a alocar, de 192.168.0.10 a 192.168.128.250. Ele exclui um único endereço, 192.168.110.10. Ele define ainda duas faixas, excluir1 e excluir2, que especificam dois conjuntos de endereços consecutivos que não podem ser alocados do pool.
pool v4-pool {
family inet {
network 192.168.0.0/16;
range r1 {
low 192.168.0.10;
high 192.168.128.250;
}
excluded-address 192.168.110.10
excluded-range exclude1 {
low 192.168.12.0
high 192.168.12.255
}
excluded-range exclude2 {
low 192.168.98.10
high 192.168.98.200
}
}
}
Da mesma forma, a configuração para pool v6-pool define uma variedade de endereços para alocar e uma variedade de endereços que são excluídos da alocação.
pool v6-pool {
family inet6 {
prefix 2016::/64;
range r2 {
low 2016::1;
high 2016::80:ffff;
}
excluded-range exclude3 {
low 2016::7c:a
high 2016::7c:ff
}
}
}
Para visualizar informações sobre endereços excluídos, você pode usar qualquer um dos seguintes comandos:
user@host> show network-access address-assignment pool pool-name IP address/prefix Hardware address Host/User Type 192.168.2.1 00:00:5e:00:53:01 user1 DHCP 192.168.2.2 00:00:5e:00:53:02 user2 DHCP 192.168.2.3 00:00:5e:00:53:03 user3 DHCP 192.168.2.4 NA EXCLUDED unknown
user@host> show network-access aaa statistics address-assignment pool pool-name Address-assignment statistics ... Addresses excluded: 1000 ...
Configuração de armadilhas de limite de uso do pool de atribuição de endereços
Você pode receber aviso avançado de que um pool de endereços ou um conjunto vinculado de pools de endereços está ficando curto em endereços disponíveis, configurando armadilhas de limiar de uso (utilização). O uso e a utilização são usados de maneira intercambiável para significar a porcentagem de endereços em um pool de endereços que atualmente são atribuídos. Um pool de endereços tem os seguintes limiares de SNMP associados a ele que permitem que o servidor de endereço local sinalize armadilhas SNMP quando determinadas condições existem:
limiar de alta utilização — quando a porcentagem de endereços atribuídos de um pool de endereços excede esse valor, uma armadilha SNMP de alta utilização é gerada. O sistema envia mensagens de aviso desde que esse limite seja excedido.
limite de utilização reduzida — quando a porcentagem de endereços atribuídos de um pool de endereços cai abaixo desse valor, uma armadilha de utilização reduzida é gerada. O sistema deixa de enviar as mensagens de aviso. Normalmente, você define o limite de utilização reduzida para menos do que o limiar de alta utilização; você não pode configurá-lo mais alto.
Os limites não têm valores padrão. Se você não configurar esses limites, o sistema não enviará uma notificação de exaustão iminente, pois a porcentagem de endereços atribuídos se aproxima 100%. O sistema envia uma armadilha fora do endereço somente quando todos os endereços da piscina de endereços forem atribuídos.
A partir do Junos OS Release 19.2R1, a armadilha fora de endereço não é enviada a menos que o limiar de alta utilização e o limiar de utilização reduzida estejam configurados. Quando a armadilha fora de endereço é enviada, uma mensagem de syslog fora do endereço também é enviada.
Você pode configurar limiares para todos os pools de endereço no nível de [edit access address-assignment] hierarquia ou apenas para pools de endereço em uma instância de roteamento especificada no nível de [edit routing-instance routing-instance-name] hierarquia. As configurações abaixo mostram apenas a [edit access] configuração.
Para definir as armadilhas de limiar:
Especifique o limite de alta utilização para pools de endereço IPv4 ou IPv6.
[edit accessaddress-assignment] user@host# set high-utilization percentage user@host# set high-utilization-v6 percentage
Especifique o limite de utilização reduzida para pools de endereço IPv4 ou IPv6.
[edit accessaddress-assignment] user@host# set abated-utilization percentage user@host# set abated-utilization-v6 percentage
No exemplo a seguir, o limite alto é definido para 95% de uso e o limite diminuído é definido para 90% de uso para pools de endereço IPv4. Quando o número de endereços atribuídos excede 95% do pool de endereços, uma armadilha de alta utilização é gerada. Se todos os endereços forem atribuídos da piscina, uma armadilha fora do endereço será gerada e uma mensagem de syslog fora do endereço for enviada. Quando o número de endereços atribuídos cai abaixo de 90% do pool de endereços, a armadilha de utilização reduzida é gerada.
[edit accessaddress-assignment] user@host# set high-utilization 95 user@host# set abated-utilization 90
Configuração do enlace do pool de atribuição de endereços
O enlace do pool de atribuição de endereços permite que você especifique um pool de endereços secundário para o roteador usar quando o pool de atribuição de endereços principal ou correspondente for totalmente alocado. Você pode criar uma cadeia de vários pools vinculados. Por exemplo, você pode vincular o Pool A ao Pool B e o enlace Pool B ao Pool C. Você pode vincular qualquer número de pools em série em uma cadeia, mas não pode criar vários links de ou para o mesmo pool. Por exemplo, você não pode criar links do Pool A ao Pool B e ao Pool C. Da mesma forma, o Pool C não pode ser vinculado tanto do Pool A quanto do Pool B. Uma consideração adicional é que todos os pools de endereço em uma cadeia devem ser do mesmo tipo de família, IPv4 ou IPv6.
Quando o pool de endereços compatível com os assinantes não tem endereços disponíveis, o roteador muda automaticamente para o pool vinculado e aloca endereços desse pool. O roteador usa um pool vinculado somente quando o pool de atribuição de endereço correspondente for totalmente alocado.
A partir do Junos OS Release 18.1, o comportamento muda para como encontrar e alocar um endereço gratuito em uma cadeia de pools de endereços. Você pode configurar pools vinculados a serem pesquisados de uma das duas maneiras:
Alocação de endereço contíguo — comportamento padrão. Todos os endereços de cada faixa de um pool são pesquisados. A busca começa na piscina combinada, depois muda para o primeiro pool da cadeia e, se necessário, continua por cada pool vinculado sucessivamente até o último pool da cadeia. Em cada pool, todos os endereços de todas as faixas são pesquisados por um endereço gratuito. Esse método permite que os endereços sejam atribuídos contíguamente; cada pool precisa estar cheio antes que outro pool seja pesquisado.
Alocação de endereços nãotiguosa (agregada) — Comportamento quando
linked-pool-aggregationconfigurado. Inicialmente, apenas certos endereços (do nextAddress ao highAddress) são pesquisados em cada faixa do pool combinado. A mesma pesquisa é realizada no pool vinculado, se necessário, e continua por cada pool vinculado sucessivo através do último pool da cadeia.A pesquisa é reiniciada no primeiro pool da cadeia (não necessariamente no pool combinado). Desta vez, todos os endereços de todas as faixas são pesquisados, em todos os pools até o fim da cadeia.
Incluir a linked-pool-aggregation declaração pode ser desejável se você configurar seu servidor RADIUS para usar o endereço IP sozinho para identificar assinantes. Normalmente, os assinantes são identificados pelo servidor RADIUS usando o ID de sessão do assinante e outros critérios. Se você usar apenas o endereço IP, você pode encontrar o seguinte problema com o comportamento padrão quando a linked-pool-aggregation declaração não estiver configurada. Um assinante pode se desconectar e esse endereço pode ser atribuído ao próximo assinante. A mensagem acct-start para o segundo assinante pode ser enviada antes que a mensagem Acct-Stop seja enviada para o assinante desconectado. Quando o Acct-Stop é recebido, o novo assinante, identificado apenas pelo endereço IP, pode ser desconectado.
Você pode evitar essa situação incluindo a linked-pool-aggregation declaração ou configurando seu servidor RADIUS para usar o ID de sessão do assinante (em vez do endereço IP) para identificação.
Antes de começar, configure seus pools de endereços. Veja a visão geral da configuração do pool de atribuição de endereços.
Para vincular um pool de atribuição de endereço a um pool secundário:
Por exemplo, os seguintes links de configuração Pool_A para Pool_B e, em seguida, links Pool_B para Pool_C.
[edit access] user@host# set address-assignment pool Pool_A link Pool_B user@host# set address-assignment pool Pool_B link Pool_C
Configuração do hold-down do pool de atribuição de endereços
O recurso hold-down do pool de atribuição de endereço — também conhecido como dreno passivo — permite que você faça a transição graciosa de um pool de endereços ativo para um estado inativo. Quando o pool está no estado inativo, você pode realizar a manutenção com segurança no pool sem afetar nenhum assinante atual (como adicionar, alterar ou excluir endereços).
Quando um pool de atribuição de endereços está no estado de espera, nenhum endereço adicional é alocado nesse pool. No entanto, o estado de retenção não afeta nenhum assinante existente que esteja usando endereços anteriormente atribuídos do pool. Conforme os assinantes existentes se desconectam, seus endereços IP são marcados como gratuitos no pool, mas os endereços não são realocados devido ao estado de retenção do pool. Eventualmente, quando todos os assinantes se desconectaram e seus endereços são devolvidos ao pool, o pool fica inativo.
Para colocar um pool ativo de atribuição de endereços no estado de espera:
Configuração do pool de endereços local DHCP Rapidamente dreno
Você pode forçar o servidor local DHCP a parar de alocar endereços de um pool de endereços local específico, configurando o pool para o modo de drenagem ativa. Esse modo permite ao servidor encerrar assinantes que já estão usando endereços atribuídos a esse pool e fazer a transição para outro pool. Quando um assinante DHCP tenta renovar (no momento da renovação do T1) o leasing em um endereço IP de um pool agora configurado para modo de drenagem ativa, o servidor local DHCP responde com um NAK à solicitação de renovação do assinante. Essa resposta força o assinante a renegociar um contrato de locação. Em seguida, o servidor aloca um novo endereço IP de um pool de endereços alternativo que não está configurado para drenagem ativa.
O modo de drenagem ativa oferece uma maneira de drenar rapidamente os assinantes de um pool de endereços. Consequentemente, quanto mais tempo de locação configurado para assinantes, mais útil pode ser o modo active-drain. Se você não configurar o modo de drenagem ativa para um pool e, em seguida, parar a alocação de seus endereços, você deve configurar o modo de drenagem passiva ou excluir o pool.
O modo de drenagem passiva coloca o pool de endereços em um estado de espera. Não há mais endereços alocados no pool, mas os assinantes que atualmente usam um endereço atribuído do pool não são afetados. Os assinantes existentes podem envelhecer. Quando o assinante desconecta (ou é desconectado por um operador) o endereço é liberado, mas não pode ser remanejado. Eventualmente, todos os assinantes liberaram seus endereços, e o pool não está mais ativo. Como os leasings para assinantes ativos são renovados sob solicitação, o modo de drenagem passiva pode levar muito mais tempo do que o modo de drenagem ativa para recuperar todos os endereços do pool.
A exclusão do pool interrompe o tráfego para cada assinante atual usando um endereço de pool pelo tempo que for necessário para o contrato expirar e para o assinante renegociar e obter um novo contrato de locação. O servidor remove todos os assinantes com um endereço do pool excluído. Os assinantes tentam estender o contrato de locação, mas falham porque o contrato de locação foi excluído no servidor. Quando os assinantes tentarem posteriormente renegociar um novo contrato de locação, ele pode ser concedido com um endereço de um pool diferente ou do RADIUS.
Você pode excluir a configuração de dreno ativo antes que o pool de endereços seja esvaziado. Nesse caso, as extensões de locação podem ser concedidas para assinantes que ainda tenham endereços a partir deste pool. Essa recuperação é o melhor esforço, porque alguns assinantes estão em processo de ser logados pelo servidor quando a configuração é excluída. Esses assinantes não podem ser recuperados no pool e devem renegociar um contrato de locação. Esses assinantes podem então ser designados para um endereço a partir deste pool (porque ele está ativo novamente) ou de um pool alternativo.
Se o cliente DHCP não receber a notificação de que o pool de endereços está sendo drenado, ele pode continuar a conceder extensões de locação aos assinantes que usam esse pool. Essa condição é indicada quando o endereço permanece vinculado ao cliente além do tempo T1 (até o tempo T2) quando deveria ter sido recuperado pelo pool. Nessa situação, exclua a configuração de dreno ativo e reconfigure-a para o pool para garantir que o pool seja drenado em tempo hábil.
No caso de uma reinicialização authd ou jdhcpd, ou de um gracioso switchover do Mecanismo de Roteamento, os endereços do pool ainda podem ser usados por alguns assinantes para os quais um NAK não foi enviado para iniciar o logotipo. Quando a reinicialização ou GRES for concluída, o authd envia uma notificação ao jdhcpd com uma lista de assinantes que ainda têm endereços do pool configurados para dreno ativo. A drenagem de piscinas pode continuar.
A partir do Junos OS Release 18.4R1, o método de alocação de endereços determina o comportamento subseqüente quando authd notifica o processo DHCP de que um pool de endereços é excluído ou sendo drenado.
Quando os endereços são alocados sob demanda, a família com o endereço nesse pool é registrada imediatamente quando o pool é excluído, ou logado graciosamente pelo processo de drenagem quando um DHCP renova ou rebina mensagem é recebida.
Quando os endereços são preallocados, os endereços de ambas as famílias são excluídos imediatamente quando o pool é excluído, ou excluídos graciosamente pelo processo de drenagem quando um DHCP renova ou rebina mensagem é recebida.
Para configurar o servidor local DHCP para parar de alocar endereços de um pool de endereços:
Você pode usar o comando para confirmar que o show network-access aaa statistics dreno ativo está configurado para um pool.
user@host> show network-access aaa statistics address-assignment pool pool1
Address assignment statistics
Pool Name: pool1
Out of Memory: 0
Out of Addresses: 0
Address total: 33009
Addresses in use: 1
Address Usage (percent): 0
Pool drain configured: yes
O recurso de drenagem ativa tem precedência sobre a preservação do endereço de prefixo. A preservação do endereço pode garantir que o mesmo prefixo delegado seja atribuído ao assinante com base no identificador de circuito de acesso (ACI). Quando um assinante com um prefixo preservado se registra, a ACI e o prefixo são armazenados na tabela de preservação de endereços. Quando esse assinante tenta fazer login novamente, o endereço e a ACI são analisados na tabela.
O modo de drenagem ativa afeta esse comportamento. Quando o prefixo faz parte de um pool definido para o modo active-drain, ele é removido da tabela e não é atribuído ao assinante quando o assinante tenta fazer login novamente.
Se o dreno ativo for cancelado enquanto o cliente estiver em processo de registro, o prefixo e a cadeia de ACI serão preservados na tabela. Nesse caso, o prefixo pode ser atribuído a essa cadeia de ACI quando o assinante fizer login novamente. No entanto, se o dreno ativo for cancelado após o cliente já ter sido logado e a tabela tiver sido liberada da associação de prefixo/ACI, o assinante em um login subsequente receberá um prefixo do pool que é reativado e o prefixo pode ser diferente.
Veja também
Configuração da atribuição de endereços estáticos
Você pode criar opcionalmente uma vinculação de endereço IPv4 estática reservando um endereço específico para um determinado cliente. O endereço é removido do pool de atribuição de endereços para que ele não seja atribuído a outro cliente. Ao reservar um endereço, você identifica o host do cliente e cria uma ligação entre o endereço MAC do cliente e o endereço IP atribuído. Os pools de atribuição de endereço IPv6 não oferecem suporte a vinculações de endereços estáticos.
Para configurar uma ligação estática para um endereço IPv4:
Configuração de proteção de endereço IPv4 duplicada para AAA
A partir do Junos OS Release 14.1, se você estiver usando a AAA para fornecer endereços IPv4, você pode habilitar a proteção de endereço duplicada para evitar que os endereços sejam usados mais de uma vez. Se habilitados, os seguintes atributos recebidos de servidores externos são verificados:
Framed-IP-Address
Framed-Pool
Em seguida, o roteador toma uma das seguintes ações:
Se um endereço for compatível com um endereço em um pool de endereços, o endereço será retirado do pool, desde que esteja disponível.
Se o endereço já estiver em uso, ele será rejeitado como indisponível e o assinante existente que usa o endereço permanecerá intacto.
Para configurar a proteção de endereço duplicada:
A partir do Junos OS Release 18.4R1, você pode habilitar opcionalmente a redesignação de um endereço que está em uso no momento quando a proteção do endereço é configurada, incluindo a opção reassign-on-match . Quando configurado, o roteador desconecta o assinante existente e permite que o novo assinante desabilcie. O efeito dessa configuração é que o endereço em uso é sempre remanejado para o novo assinante.
Um caso de uso para esse recurso de substituição ocorre quando um assinante móvel é acidentalmente retirado do nó de suporte para GPRS (GGSN) do gateway, mas o GGSN mantém a sessão L2TP do assinante ativada por algum período de tempo. Quando o cliente tenta se reconectar por um nó diferente, a sessão não pode se conectar porque a sessão original ainda está ativa. A redesignação do endereço permite que a nova sessão preempite a sessão existente, permitindo que o assinante se reconecte.
O assinante existente só é desconectado quando o endereço é de um pool de endereços de origem RADIUS. Quando o endereço é de um pool de endereços configurado localmente, a sessão de assinantes existente permanece intacta.
Não use a opção quando o reassign-on-match RADIUS está alocando endereços contidos em um pool de endereços configurado localmente porque há uma maior chance de colisão de endereço. Recomendamos que você não se sobreponha a endereços de origem RADIUS com pools de endereços locais.
A opção reassign-on-match funciona da seguinte maneira:
Um assinante negocia o acesso com um determinado endereço IP.
O roteador determina se esse endereço está em uso e de onde ele veio.
Quando um assinante já está logado com esse endereço, o endereço não faz parte de um pool configurado localmente e a proteção de endereços é ativada:
O roteador envia um NAK para o novo assinante, rejeitando a solicitação.
O roteador envia uma solicitação de desconexão ao assinante existente. A solicitação de desconexão inclui uma identificação de encerramento para relatar a causa do logotipo.
O novo assinante (rejeitado) pode renegociar e recebe o endereço IP.
Quando um assinante já está logado com esse endereço e o endereço foi alocado em um pool de endereços local:
O roteador envia um NAK para o novo assinante, rejeitando a solicitação.
O roteador não envia uma solicitação de desconexão ao assinante existente.
Quando você adiciona reassign-on-match a uma configuração de proteção de endereço duplicada existente, ela entra em vigor imediatamente para os assinantes existentes. Da mesma forma, se você remover reassign-on-match de uma configuração, ela entra em vigor imediatamente, para que uma solicitação subsequente de acesso com um endereço em uso não resulte no encerramento do assinante existente.
Para habilitar a redesignação do endereço:
[edit access address-protection] user@host# set reassign-on-match
Veja também
Exemplo: configurar um pool de atribuição de endereços
Requisitos
Visão geral
Configuração
Este exemplo mostra uma configuração de pool de atribuição de endereço que cria dois pools, um para clientes DHCP IPv4 (isp_1) e um segundo pool (chi-fiber-ra) que é usado para anúncio de roteador.
Configuração rápida da CLI
[edit access]
address-assignment {
network-discovery-router-advertisement chi-fiber-ra;
pool isp_1 {
family inet {
network 192.168.0.0/16;
range southeast {
low 192.168.102.2 high 192.168.102.254;
}
range northeast {
low 192.168.119.2 high 192.168.119.250;
}
host host.example.net {
hardware-address 00:00:5E:00:53:90;
ip-address 192.168.44.12;
}
dhcp-attributes {
option-match {
option-82 {
circuit-id fiber range northeast;
}
option-82 {
circuit-id cable_net range southeast;
}
}
boot-file boot.client;
boot-server 192.168.200.100;
grace-period 3600;
maximum-lease-time 18000;
netbios-node-type p-node;
router 192.168.44.44 192.168.44.45;
}
}
}
pool chi-fiber-ra {
family inet6 {
prefix 2001:db8:2008:2009:2010::/48;
range fiber3 {
low 2001:db8:2008:2009:2010::1/64;
high 2001:db8:2008:2009:2010::5/64;
}
}
}
}
Este exemplo cria um pool de atribuição de endereço IPv4 nomeado isp-1, que contém duas faixas de endereço nomeadas, southeast e northeast. O pool de atribuição de endereços também contém uma ligação estática para o cliente host host.example.net. A configuração do pool ISP_1 também inclui a dhcp-attributes declaração, indicando que o pool é usado para clientes DHCP. Se a opção 82 circuit-id de entrada for compatível com a cadeia fiber, o DHCP atribui ao cliente um endereço da northeast faixa. Se a opção 82 circuit-id for compatível com a cadeia cable_net, o DHCP atribui um endereço da southeast faixa.
O segundo pool de atribuição de endereços criado neste exemplo é chi-fiber-ra. A neighbor-discovery-router-advertisement declaração no início da sintaxe especifica que este pool de atribuição de endereços nomeado é usado para anúncio de roteador. A sintaxe ao final do exemplo configura o pool de atribuição de endereços chamado chi-fiber-ra.
reassign-on-match .