Déployer facilement de nouveaux VLAN dans un grand environnement

Comment les gens gèrent-ils le besoin d'ajouter des VLAN à tous les commutateurs de leur réseau (ou même à un sous-ensemble d'appareils)? Nous ajoutons environ 6 nouveaux VLAN par semaine en ce moment et à mesure que le réseau se développe, cela devient une tâche très lourde et risquée.

Voici un modèle de script vraiment basique en Perl pour la connexion Telnet dans une liste de périphériques (un sur chaque ligne dans un fichier appelé devicelist.txt) et la configuration de certaines commandes. Selon ce que vous faites exactement, cela devrait fournir un bon départ.

  use Net::Telnet::Cisco;

    # read in a list of devices
    my @devicelist;
    open(DATA, "<devicelist.txt") || die "Can't open file!";
    while (<DATA>) {
            chomp;
            push( @devicelist, $_);
    }

    # loop through the devices
    foreach $hostname (@devicelist)
    {
            # telnet to device
            my $cs = Net::Telnet::Cisco->new(Host => $hostname);

            # login, go enable, disable paging, go into config mode
            $cs->login( "username", "password" );
            $cs->enable( "enable_password" );
            $cs->cmd( 'terminal length 0' );
            $cs->cmd( 'config t' );

            # configure the device
            $cs->cmd( 'vlan 100, 200, 300' );
            $cs->cmd( 'interface Ethernet0' );
            $cs->cmd( ' switchport access vlan 100' );

            # exit config mode and write the config
            $cs->cmd( 'end' );
            $cs->cmd( 'wr mem' );

            # close the connection
            $cs->close;
    }

Voici également plus de détails sur Net :: Telnet :: Cisco.

Je dirais que vous avez deux options:

1. Manuellement. Prend le plus de temps. Le plus sûr? Dépend de celui qui fait la config.
2. Utilisez un outil comme Kiwi Cattools ou Rancid etc. Beaucoup plus facile, mais vous auriez besoin d'une sorte de logique pour vérifier si le VLAN est déjà existant ou vous pourriez gâcher la structure de nommage. Peut-être pas une grosse affaire?
3. Script-le! Utilisez Perl, Python, Ruby ou tout autre langage avec lequel vous avez de l'expérience. Cela prend un certain temps pour le construire mais une fois qu'il est fait, vous pouvez réutiliser le script pour d'autres tâches de configuration. Ce serait personnalisable mais cela dépend si vous êtes à l'aise avec le codage.
4. Utilisez SNMP. Je n'ai jamais essayé ça. Exigerait RW sur les périphériques et je n'aime pas vraiment exécuter RW sur mes périphériques réseau.

Un logiciel de gestion de la configuration mérite d'être étudié - La gestion des périphériques réseau de Puppet peut facilement ajouter des réseaux locaux virtuels à de nombreux périphériques Cisco (si vous utilisez Cisco).

Le défi auquel vous êtes maintenant confronté est que vous allez dans un environnement mixte. Vous mentionnez que vous vous dirigez vers Juniper à partir de Je suppose que Cisco? Dans un environnement Cisco pur, VTP v3 avec des mots de passe serait la voie à suivre et prend en charge plus de 4 000 réseaux locaux virtuels. Dans le monde Juniper, l'équivalent serait le GVRP .

Vous pourrez peut-être utiliser une forme de gestion centralisée telle que Puppet comme cela a été mentionné par Shane Madden, SolarWinds , HP OpenView et autres, mais vous aurez toujours deux scripts à gérer.

J'essaierais de garder les choses aussi simples que possible ( KISS ) pour l'instant lorsque vous passez d'un fournisseur à un autre. L'utilisation de VTP et GVRP sur le matériel approprié est probablement la voie à suivre et n'ajoute pas le coût potentiel pour d'autres solutions ou la complexité de la gestion d'une autre nouvelle chose.

Il se pourrait que VTP soit votre réponse. Comme tout outil "automatisé", il a ses risques, mais vous pouvez les atténuer avec une bonne planification. Vous devriez également faire quelques lectures pour vous assurer de comprendre comment cela fonctionne ou vous pouvez créer par inadvertance vos propres problèmes (encore une fois, comme tout outil automatisé).

Je recommanderais VTP version 3, car cela peut aider à protéger contre certains des problèmes potentiels et offre des avantages supplémentaires.

Vous pouvez facilement trouver des centaines de documents en recherchant «configuration vtp version 3» dans le moteur de recherche de votre choix.

Le gestionnaire de configuration réseau de Solarwind peut exécuter des scripts sur des périphériques IOS et quelques autres.

Il fait également des choses comme les sauvegardes de configuration nocturnes, les rapports de modification et les audits de configuration. Leur prix n'est pas horrible, mais ils fusionnent NCM avec leur moniteur de performances réseau Orion et je ne suis pas certain que vous puissiez exécuter NCM séparément.

On dirait que vous avez un noyau effondré. Est-ce exact?

Une façon de gérer trop de changements basés sur l'ajout de nouveaux VLAN est de rapprocher votre limite L3 de l'accès. Cela nécessite un peu de travail à l'avance, mais si votre conception est bien planifiée et réfléchie, cela devrait faire de l'ajout de nouveaux VLAN une tâche d'un à trois appareils (selon que L3 s'arrête aux couches de distribution ou d'accès).

Il existe également de nombreux autres avantages, notamment une convergence plus rapide en cas de perte de liaison.

J'utilise ruby ​​avec les gemmes net-scp et net-ssh pour automatiser les tâches avec notre équipement réseau. C'est un script assez court pour exécuter des commandes (extrait, pas un produit fini):

begin
    Net::SSH.start(fqdn, username, :password => loginPassword) do |session|
        output = ""

        channel = session.open_channel do |ch|
            ch.send_channel_request "shell"
            ch.on_data do |ch, data|
                output += data
            end

            ch.send_data "conf t\n\r"
            #Some tasks here
            ch.send_data "exit\n\r" #Exit config mode
            ch.send_data "exit\n\r" #Exit device

        end

        # Wait for everything to complete
        channel.wait
    end
rescue Exception=>e
    errorOutput = fqdn + ": " + e.to_s
    puts errorOutput
    puts output
    return device
end
return output

Gardez à l'esprit que vous devez avoir une variable loginPassword vide. S'il est vide, il utilisera votre clé publique RSA pour la connexion (prise en charge sur les plates-formes HP ProCurve et Cisco 15.X).

En utilisant quelque chose comme git et quelques scripts courts, vous pouvez organiser toutes vos configurations d'équipement avec des différences de changements et qui a fait les changements (en supposant que vos ingénieurs tirent les configurations et les engagent une fois le travail terminé).

De plus, cela devrait aller de soi, mais au cas où, testez toujours le travail scripté dans un laboratoire avant de l'utiliser sur un équipement de production. Surtout lors de l'exécution de commandes et de la modification de configurations. Test, test, test.

si vous utilisez le même constructeur (Cisco par exemple) pour vos périphériques réseau, SecureCRT est votre meilleur choix. c'est un client SSH qui vous donne la possibilité d'envoyer des commandes sur plusieurs terminaux au moment de la vente:

pour configurer cela: 1. connectez-vous à tous vos appareils dans différents onglets 2. allez à la vue 3. cochez l'option "fenêtre de chat" 4. faites un clic droit sur la fenêtre -> cochez "envoyer le chat à tous les onglets"

L'utilisation peut utiliser NOC, NOC Project, c'est le système OSS open source évolutif et hautes performances pour les FAI. Vous pouvez facilement ajouter des VLAN via l'ensemble du réseau.