Configuração de interfaces de serviços

Cada interface tem um nome de interface, que especifica o tipo de mídia, o slot em que o FPC está localizado, a localização no FPC em que o PIC está instalado e a porta PIC. O nome da interface identifica um conector de rede individual no sistema. Você usa o nome da interface ao configurar interfaces e ao ativar várias funções e propriedades, como protocolos de roteamento, em interfaces individuais. O sistema usa o nome da interface ao exibir informações sobre a interface, por exemplo, no show interfaces comando.

O nome da interface é representado por uma parte física, uma parte lógica e uma parte do canal no seguinte formato:

A parte do canal do nome é opcional para todas as interfaces, exceto as interfaces DS3, E1, OC12 e STM1 canalizadas.

A parte física de um nome de interface identifica o dispositivo físico, que corresponde a um único conector de rede físico. Esta parte do nome da interface tem o seguinte formato:

type é o tipo de mídia, que identifica o dispositivo de rede. Para interfaces de serviço, ele pode ser um dos seguintes:

• ams— Interface agregada de multisserviços (AMS). Uma interface AMS é um pacote de interfaces de serviços que pode funcionar como uma única interface. Uma interface AMS é indicada como amsN na configuração, onde N está um número único que identifica uma interface AMS (por exemplo). ams0 As interfaces de membro em uma interface AMS são identificadas na configuração com um mams- prefixo (por exemplo mams-1/2/0).

• cp— interface de coletor de fluxo.

• es— Interface de criptografia.

• gr— Interface de túnel de encapsulamento de roteamento genérico.

• gre— Essa interface é gerada internamente e não configurável.

• ip— interface de túnel de encapsulamento IP-over-IP.

• ipip— Essa interface é gerada internamente e não configurável.

• ls— interface de serviços de enlace.

• lsq— interface de fila inteligente (IQ) dos serviços de enlace; também usado para serviços de voz.

• mams— Interface de membro em uma interface AMS.

• ml— interface multilink.

• mo— Interface de serviços de monitoramento. A interface mo-fpc/pic/portlógica .16383 é uma interface não configurada internamente para o tráfego de controle de roteador.

• ms— Interfaces multisserviços na placa de interfaces modulares multisserviços (MS-MIC) e concentradores de portas modulares multisserviços (MS-MPC).

• mt— interface de túnel multicast. Essa interface é gerada automaticamente, mas você pode configurar propriedades nela, se necessário.

• mtun— Essa interface é gerada internamente e não configurável.

• rlsq— Interface LSQ de redundância.

• rsp— Interface de serviços adaptativos de redundância.

• si— Interface de serviços em linha, configurada apenas em roteadores da Série MX3D.

• sp— Interface de serviços adaptativos. A interface sp-fpc/pic/portlógica .16383 é uma interface não configurada internamente para o tráfego de controle de roteador.

• tap— Essa interface é gerada internamente e não configurável.

• vt— Interface virtual de túnel de loopback.

Para AS PICs, PICs multisserviços, DPCs multisserviços e o módulo de serviços adaptativos internos (ASM) no roteador M7i, existem dois pacotes de serviço: Camada 2 e Camada 3. Ambos os pacotes de serviço são suportados em todas as interfaces de serviços adaptativos, mas você pode habilitar apenas um pacote de serviço por PIC, com exceção de um pacote combinado suportado no ASM. Em um único roteador, você pode habilitar ambos os pacotes de serviço instalando dois ou mais PICs na plataforma.

Você habilita pacotes de serviço por PIC, não por porta. Por exemplo, se você configurar o pacote de serviços de Camada 2, todo o PIC usa o pacote configurado. Para habilitar um pacote de serviços, inclua a declaração do pacote de serviços no nível de [edit chassis fpc slot-number pic pic-number adaptive-services] hierarquia e especifique layer-2 ou layer-3:

Para determinar qual pacote um AS PIC oferece suporte, emita o show chassis hardware comando: se o PIC oferece suporte ao pacote de Camada 2, ele está listado como Link Services II, e se for compatível com o pacote de Camada 3, ele está listado como Adaptive Services II. Para determinar qual pacote um PIC multisserviços oferece suporte, emita o show chassis pic fpc-slot slot-number pic-slot slot-number comando. O Package campo exibe o valor Layer-2 ou Layer-3.

Depois de cometer uma mudança no pacote de serviços, o PIC é retirado offline e depois colocado de volta on-line imediatamente. Você não precisa deixar o PIC offline e on-line manualmente.

Os serviços suportados em cada pacote diferem por pic e tipo de plataforma. A Tabela 1 lista os serviços suportados em cada pacote de serviço para cada PIC e plataforma.

Nos PICs as e multisserviços, o suporte a serviços de link inclui componentes Junos OS CoS, LFI (FRF.12), MLFR de ponta a ponta (FRF.15), MLFR UNI NNI (FRF.16), MLPPP (RFC 1990) e MLPPP multiclasse. Para obter mais informações, consulte os recursos e interfaces do pacote de serviços de Camada 2 e os recursos e interfaces do pacote de serviços de Camada 2.

A configuração a seguir inclui todos os itens necessários para configurar serviços em uma interface:

Você pode especificar configurações padrão globais para determinados timers que se aplicam a toda a interface. Existem três declarações deste tipo:

• inactivity-timeout— Define o período de inatividade para fluxos estabelecidos, após os quais eles não são mais válidos.

• open-timeout— Define o período de intervalo para o estabelecimento de sessão do Protocolo de Controle de Transmissão (TCP), para uso com defesas de cookies SYN contra intrusão de rede.

• close-timout— Define o período de intervalo para a derrubada do protocolo de controle de transmissão (TCP).

Para configurar uma configuração para o período de inatividade, inclua a inactivity-timeout declaração no nível de [edit interfaces interface-name services-options] hierarquia:

O valor padrão é de 30 segundos. A faixa de valores possíveis é de 4 a 86.400 segundos. Qualquer valor configurado na definição do protocolo do aplicativo substitui o valor especificado aqui; para obter mais informações, consulte Configuração de propriedades de aplicativos.

Para configurar uma configuração para o período de tempo limite do estabelecimento de sessão TCP, inclua a open-timeout declaração no nível de [edit interfaces interface-name services-options] hierarquia:

O valor padrão é de 5 segundos. A faixa de valores possíveis é de 4 a 224 segundos. Qualquer valor configurado na definição do serviço de detecção de intrusões (IDS) substitui o valor especificado aqui; para obter mais informações, consulte a configuração de regras do IDS em um MS-DPC.

Para configurar uma configuração para o período de intervalo de intervalo da sessão TCP, inclua a close-timeout declaração no nível de [edit interfaces interface-name services-options] hierarquia:

O valor padrão é de 1 segundo. A faixa de valores possíveis é de 2 a 300 segundos.

Uso de mensagens keep-alive para maior controle de tempo limite de inatividade TCP

As mensagens de manutenção são geradas automaticamente para evitar o tempo limite de inatividade do TCP. O número padrão de mensagens que mantêm a vida é 4. No entanto, você pode configurar o número de mensagens que mantêm-se vivas entrando na tcp-tickles declaração no nível de [edit interaces interface-name service-options] hierarquia.

Quando o tempo limite é gerado para um fluxo bidirecional de TCP, pacotes de manutenção vivos são enviados para redefinir o temporizador. Se o número de pacotes contínuos consecutivos enviados em um fluxo atingir o limite padrão ou configurado, a conversa será excluída. Existem vários cenários possíveis, dependendo da configuração do inactivity-timer número máximo padrão ou configurado de mensagens de manter-se vivos.

• Se o valor configurado de mensagens manter-vivas for zero e inactivity-timeout NÃO estiver configurado (nesse caso, o valor de tempo limite padrão de 30 for usado), nenhum pacote vivo será enviado. A conversa é excluída quando qualquer fluxo na conversa fica ocioso por mais de 30 segundos.

• Se o valor configurado de mensagens de manter-se vivo for zero e inactivity-timeout estiver configurado, nenhum pacote continua vivo é enviado e a conversa é excluída quando qualquer fluxo na conversa fica ocioso por mais do que o valor de tempo limite configurado.

• Se o número máximo padrão ou configurado de mensagens de manter-se vivo for algum inteiro positivo, e qualquer um dos fluxos em uma conversa estiver ocioso por mais do que o valor padrão ou configurado para inactivity-timeout pacotes keep-alive são enviados. Se os hosts não responderem ao número configurado de pacotes de keep-alive consecutivos, a conversa será excluída. O intervalo entre pacotes vivos será de 1 segundo. No entanto, se o host enviar de volta um pacote ACK, o fluxo correspondente se tornará ativo, e os pacotes de manter-se vivos não são enviados até que o fluxo fique ocioso novamente.

Você especifica propriedades que controlam como as mensagens de log do sistema são geradas para a interface como um todo. Se você configurar valores diferentes para as mesmas propriedades no nível de [edit services service-set service-set-name] hierarquia, os valores definidos por serviços substituem os valores configurados para a interface. Para obter mais informações sobre a configuração de propriedades definidas por serviços, consulte a configuração do registro do sistema para conjuntos de serviços.

Para configurar valores de registro padrão em toda a interface, inclua a syslog declaração no nível de [edit interfaces interface-name services-options] hierarquia:

Configure a host declaração com um nome de host ou um endereço IP que especifica o servidor alvo de log do sistema. O nome de local host direciona as mensagens de log do sistema para o Mecanismo de Roteamento. Para servidores de log externos do sistema, o nome de host deve ser alcançável da mesma instância de roteamento à qual o pacote de dados inicial (que acionou o estabelecimento da sessão) é entregue. Você pode especificar apenas um nome de host de registro do sistema.

Começando com o junos OS versão 17.4R1, você pode configurar até um máximo de quatro servidores de log do sistema (combinação de hosts de log de sistema locais e coletores de log de sistema remoto) para cada conjunto de serviços para interface ms sob [edit interfaces interface-name services-options] hierarquia.

A Tabela 2 lista os níveis de gravidade que você pode especificar em declarações de configuração no nível de [edit interfaces interface-name services-options syslog host hostname] hierarquia. Os níveis de emergency passagem info estão em ordem desde a mais alta gravidade (maior efeito sobre o funcionamento) até o mais baixo.

Recomendamos a configuração do nível de gravidade de registro do sistema durante a error operação normal. Para monitorar o uso de recursos pic, defina o nível para warning. Para coletar informações sobre um ataque de intrusão quando um erro de sistema de detecção de intrusão for detectado, defina o nível para notice uma interface específica. Para depurar uma configuração ou registrar a funcionalidade de tradução de endereços de rede (NAT), defina o nível para info.

Para obter mais informações sobre mensagens de log do sistema, consulte o System Log Explorer.

Para usar um código de instalação específico para todos os registros no host de log do sistema especificado, inclua a facility-override declaração no nível de [edit interfaces interface-name services-options syslog host hostname] hierarquia:

As instalações apoiadas incluem authorization, daemon, ftp, kernel, usere local0 através local7.

Para especificar um prefixo de texto para todos os registros neste host de log do sistema, inclua a log-prefix declaração no nível de [edit interfaces interface-name services-options syslog host hostname] hierarquia: