CLI baseado em transações em comutadores Ethernet


10

Eu estou familiarizado com a CLI em switches Ethernet gerenciados. No entanto, recentemente me deparei com um termo 'CLI baseado em transações' nos comutadores. Não sei exatamente o que é isso e o objetivo de tê-lo em switches. É semelhante às transações do banco de dados onde você pode desenrolar todos os comandos antes de enviá-los?

Editar:

Como pedido:

Folha de dados do RX5000

Transações da CLI do ponto de verificação


Alguma resposta o ajudou? Nesse caso, você deve aceitar a resposta para que a pergunta não apareça para sempre, procurando uma resposta. Como alternativa, você pode fornecer e aceitar sua própria resposta.
Ron Maupin

Respostas:


10

Eu estou familiarizado com a CLI em switches Ethernet gerenciados. No entanto, recentemente me deparei com um termo 'CLI baseado em transações' nos comutadores. Não sei exatamente o que é isso e o objetivo de tê-lo em switches. É semelhante às transações do banco de dados onde você pode desenrolar todos os comandos antes de enviá-los?

  • O RX5000 está falando da capacidade de reverter as alterações de forma incremental, como você pode em um banco de dados.
  • O link do ponto de verificação que você mencionou faz alusão à mesma coisa, mas eles especificam que comandos de configuração discretos podem ser agrupados em uma única ação de "confirmação".

Transações da Cisco CLI com archive de configuração e reversão

Esses recursos são muito semelhantes aos encontrados em outras partes do setor ... por exemplo, em um roteador Cisco, você pode confirmar alterações em transações reversíveis, se tiver archiveativado na configuração em execução da Cisco.

SW1#sh runn | b archive
archive
 path bootflash:$h_config
!
SW1#term exec prompt time
SW1#archive config

SW1#dir bootflash:
Directory of bootflash:/

   21  -rw-       52770   Nov 3 2013 12:48:04 -06:00  SW1_config-Nov--3-12-48-02-CST-1
   20  -rw-       52770   Nov 3 2013 12:45:02 -06:00  SW1_config-Nov--3-12-45-00-CST-0
   22  -rw-       52762   Nov 3 2013 12:52:22 -06:00  SW1_config-Nov--3-12-52-20-CST-0
   23  -rw-       52762   Nov 3 2013 14:38:44 -06:00  SW1_config-Nov--3-14-38-41-CST-1
   26  -rw-       66622  Jan 31 2014 13:17:46 -06:00  SW1_configJan-31-13-17-42-CST-2  <---

131436544 bytes total (95956992 bytes free)
SW1#

Não há um Loopback100 configurado no momento ...

SW1#sh runn int lo100
                  ^
% Invalid input detected at '^' marker.

SW1#

Transação CLI de exemplo, configure e confirme

Vamos configurar Loopback100com um timer de reversão de 10 minutos, ver nossas alterações desde o instantâneo da configuração, confirmar as alterações e, em seguida, reverter. Se o cronômetro de reversão expirar sem confirmar a configuração, ele reverterá automaticamente para o nosso último config archive(o que também acontece quando você executa config terminal revert).

Essas transações são valiosas porque, se você manipular completamente a configuração do roteador até o ponto inacessível, ele reverterá automaticamente para o instantâneo salvo ... também ajuda se você pode gerenciar o roteador, mas precisa reverter para um estado conhecido. configuração com pressa.

SW1#configure terminal revert timer 10
Rollback Confirmed Change: Backing up current running config 
 to bootflash:SW1_configJan-31-13-20-21-CST-3

Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#
SW1(config)#int loopback 100
SW1(config-if)#ip address 1.2.3.4 255.255.255.255
SW1(config-if)#end
SW1#

Podemos ver que Looback100 existe ...

SW1#sh runn int lo100
Load for five secs: 28%/0%; one minute: 24%; five minutes: 24%
Time source is NTP, 13:21:25.243 CST Fri Jan 31 2014

Building configuration...

Current configuration : 65 bytes
!
interface Loopback100
 ip address 1.2.3.4 255.255.255.255
end

SW1#

Podemos ver as diferenças necessárias para reverter para o último arquivo de configuração ...

SW1#sh archive config differences bootflash:SW1_configJan-31-13-17-42-CST-2
Load for five secs: 17%/0%; one minute: 24%; five minutes: 23%
Time source is NTP, 13:25:55.832 CST Fri Jan 31 2014
!
!Contextual Config Diffs:
-interface Loopback100
 -ip address 1.2.3.4 255.255.255.255

SW1#

Agora podemos confirmar a confirmação ... isso significa que não reverteremos automaticamente se o cronômetro de 10 minutos expirar.

SW1#configure confirm
SW1#sh runn int loo100
Load for five secs: 25%/0%; one minute: 25%; five minutes: 24%
Time source is NTP, 13:30:17.269 CST Fri Jan 31 2014

Building configuration...

Current configuration : 65 bytes
!
interface Loopback100
 ip address 1.2.3.4 255.255.255.255
end

SW1#

Reversão de transação da CLI

Suponha que encontremos um problema depois config confirm. Vamos reverter para a antiga configuração que arquivamos ...

SW1#configure replace bootflash:SW1_configJan-31-13-17-42-CST-2
This will apply all necessary additions and deletions
to replace the current running configuration with the
contents of the specified configuration file, which is
assumed to be a complete configuration, not a partial
configuration. Enter Y if you are sure you want to proceed. ? [no]: yes
Total number of passes: 1
Rollback Done

SW1#

Agora, o Loopback100 não existe na configuração em execução. A configuração é exatamente do jeito que era quando tiramos nosso primeiro instantâneo.

SW1#sh runn int lo100
                  ^
% Invalid input detected at '^' marker.

SW1#

Quando ocorre uma reversão, a configuração é bloqueada de qualquer outra atividade de configuração. No caso de um bug ou algum evento imprevisível, é uma boa ideia ter configuration mode exclusive auto expire [timeout-in-seconds]em sua configuração ao usar esse recurso. Eu gosto do valor de tempo limite máximo de 600 segundos ... isso significa que o tempo máximo que a configuração pode ser bloqueada é de 10 minutos.

Nota histórica

Originalmente, a Juniper era o primeiro grande fornecedor a implantar recursos de reversão de configuração. Eu trabalhava na Cisco na época e nossas contas de vendas gritavam por esse recurso no Cisco IOS. Ainda me lembro de editais internos de jogadores importantes da empresa, que disseram "é impossível no Cisco IOS".

Claro, com persistência suficiente (e alguns anos no meio), temos no IOS ... o ponto é, não assuma o primeiro "não, não podemos fazer isso" realmente está correto.


Obrigado pelo exemplo. Uma coisa não ficou clara para mim ... As alterações (neste caso, o loopback) são ativadas imediatamente assim que você digita os comandos ou ativadas quando você confirma as transações (configure confirm).
modesto

@modest, a Cisco aplica os comandos imediatamente; quando você faz um config confirm, está apenas dizendo ao roteador que não deseja reverter essas alterações automaticamente. Obviamente, é perfeitamente possível fazer alterações sem reversão programada. De qualquer forma, os comandos estão imediatamente ativos.
Mike Pennington

1

Sua suposição está correta. Nos dois casos, é possível reverter os comandos de configuração para um ponto conhecido se eles não funcionarem conforme o esperado.


Entendido. No entanto, você pode obter o efeito simplesmente carregando o arquivo de configuração anterior (supondo que você o salve antes de começar a fazer alterações), caso as coisas corram mal. Estou faltando alguma coisa aqui?
modesto

@modest Recarregar a configuração anterior não removerá comandos que exijam "no <cmd>". Por exemplo, se você aplicar uma lista de acesso a uma interface com o comando "ip access-group 100 in" e digite "copy start run" para recarregar a configuração, isso não removerá a lista de acesso.
Ron Trunk

A outra coisa que esse recurso faz (pelo menos na Cisco e Juniper) é permitir que você defina um cronômetro de reversão. Quando o cronômetro expirar, a configuração será revertida sozinha. Isso é útil se você fez alguma alteração que faz com que você perca a afetividade do dispositivo. Não que eu já tenha feito isso :(
Ron Trunk
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.