CLI basée sur les transactions sur les commutateurs Ethernet

Je connais l'interface CLI sur les commutateurs Ethernet gérés. Cependant, récemment, je suis tombé sur un terme «CLI basée sur les transactions» sur les commutateurs. Je ne sais pas exactement ce que c'est et le but de l'avoir dans les commutateurs. Est-ce similaire aux transactions de base de données où vous pouvez dérouler la totalité des commandes avant de les valider?

Éditer:

Comme demandé:

Fiche technique du RX5000

Transactions CLI Checkpoint

Je connais l'interface CLI sur les commutateurs Ethernet gérés. Cependant, récemment, je suis tombé sur un terme «CLI basée sur les transactions» sur les commutateurs. Je ne sais pas exactement ce que c'est et le but de l'avoir dans les commutateurs. Est-ce similaire aux transactions de base de données où vous pouvez dérouler la totalité des commandes avant de les valider?

• Le RX5000 parle de la possibilité d'annuler les modifications de manière incrémentielle, comme vous le pouvez dans une base de données.
• Le lien Checkpoint que vous avez mentionné fait référence à la même chose, mais ils spécifient que les commandes de configuration discrètes peuvent être regroupées en une seule action de «validation».

Transactions Cisco CLI avec archive de configuration et restauration

Ces capacités sont très similaires à ce que vous trouvez ailleurs dans l'industrie ... par exemple sur un routeur Cisco, vous pouvez valider des modifications dans les transactions réversibles, si vous l'avez archiveactivé dans la configuration en cours d'exécution de 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#

Il n'y a pas de Loopback100 configuré en ce moment ...

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

SW1#

Exemple de transaction CLI configurer et confirmer

Configurons Loopback100avec une minuterie de restauration de 10 minutes, examinons nos modifications depuis l'instantané de configuration, confirmons les modifications, puis restaurez. Si la temporisation de restauration expire sans confirmer la configuration, elle reviendra automatiquement à notre dernière config archive(ce qui se produit également lorsque vous effectuez config terminal revert).

Ces transactions sont précieuses, car si vous modifiez complètement la configuration de votre routeur au point qu'elle est inaccessible, elle reviendra automatiquement à votre instantané enregistré ... cela aide également si vous pouvez gérer le routeur mais devez revenir à un bien connu config pressé.

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#

On voit 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#

Nous pouvons voir les différences nécessaires pour revenir à la dernière archive de configuration ...

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#

Maintenant, nous pouvons confirmer la validation ... cela signifie que nous n'annulons pas automatiquement si le délai de 10 minutes expire.

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#

Restauration des transactions CLI

Supposons que nous trouvions un problème après config confirm. Revenons à l'ancienne configuration que nous avons archivée ...

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#

Maintenant, Loopback100 n'existe pas dans la configuration en cours d'exécution. La configuration est exactement la même que lorsque nous avons pris notre premier instantané.

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

SW1#

En cas de restauration, la configuration est verrouillée à partir de toute autre activité de configuration. En cas de bogue ou d'événement imprévisible, c'est une bonne idée d'avoir configuration mode exclusive auto expire [timeout-in-seconds]dans votre configuration lors de l'utilisation de cette fonctionnalité. J'aime la valeur de timeout max de 600 secondes ... cela signifie que la durée maximale de verrouillage de la configuration est de 10 minutes.

Note historique

À l'origine, Juniper a été le premier grand fournisseur à déployer des fonctionnalités de restauration de configuration. J'ai travaillé pour Cisco à l'époque, et nos comptes de vente criaient pour cette fonctionnalité dans Cisco IOS. Je me souviens encore des édits internes des acteurs importants de l'entreprise, qui ont dit "c'est impossible dans Cisco IOS".

Bien sûr, avec suffisamment de persistance (et quelques années au milieu), nous l'avons dans IOS ... le fait est que ne présumez pas que le premier "non, nous ne pouvons pas faire ça" est vraiment correct.

Votre hypothèse est correcte. Dans ces deux cas, vous pouvez restaurer les commandes de configuration à un point connu si elles ne fonctionnent pas comme prévu.