There is still some kind of crappy limitation with GNS3 and getting my Loopedback VLAN to communicate with the PC devices in ACME Co LAN – However I do have reachability on the Network Devices to play with some local configs in this lab!
I have just recently started to use GNS3 and am not sure why Hosts it seems specifically are not reachable at all from the NetAuto Host if its on another Subnet, however I can still reach SW1 and R1, and those can access R2 and SW2 so we should be good to go!
This series of posts / labs will be using config files to write configs to the net devices!
In the referenced NAPALM URL I keep going back to in different posts, there is a small portion with functions to manipulate configs, in fact I can snip it right here:
Source: https://napalm.readthedocs.io/en/latest/support/
I am really trying to truck through Python this weekend while juggling lots of life stuff, so I am not sure if I will get to cover it all, but I’ll get a good look at it over this and probably a couple other posts here!
With how GNS3 / My NetAuto Host is able to touch devices, I’ve had to compromise
Below is the logical breakup / explanation of the Topology I will be automating from my original beautiful big sprawling OSPF network of connectivity goodness:
So I’ve added Lo101, 111, 202, and 222 with host IP’s of their Loopback # that I confirmed that SW2 in the ACME Co LAN can hit at this time (so I will be messing with R1 for this) :
And I actually just put Hosts PC1 and PC2 on the .238.x subnet with .10 and .20 as their IP Address and confirmed R1 can now hit them, so I can mess with SW1 Access-Control :
Using NAPALM to configure R1 to block some ACME Co to LoopedBack traffic!
In this script I will be NAPALMing a single device (R1) to set some ACL’s to block a few connections from SW2 (in the remote LAN) from pinging SW1 Loopback Interfaces as shown below first in the script that will call out a *.cfg file to “Merge” this new configuration into the current running configuration (reminds me of GIT) :
Being its a single device for now I just threw the static info in there of “Access x.x.x.x” and the credentials / IP’s to be accessed via SSH, and below is a simple script to test that its working by restricting SW2 from pinging two of the Loopback interfaces on SW1:
Again you don’t want to always do a “wr” or “wr mem” at the end of scripts in production (or even during maintenance hours), as you can kill remote access to the device, and that can really cause some after hours headaches for your staff!
In a future demo I will lab up a certain type of NAPALM Controlled Commit that sounds to me similar like “Exception Handling” in Python or what is known as “try” statements, that will run when an error is hit so it can “try” to make sense of the code and run it!
However – NAPALM has its own config check it can perform as well I shall check out as well here, which does a check of the device running config before doing a commit (shown about within the script it is like the “wr mem” in the script), so lets get right to it here on R1 without further ado!
However like good engineers we verify connectivity before trying to restrict it!
And I actually ran into the “SSH Connection refused” thing again between NetAuto-Host and both SW1 and R1, so after a wire shark did not reveal an obvious answer, I just toasted them and threw new devices in and confirmed pings / SSH to all devices:
So now is the time to run those scripts from that new Net Auto Host Aaaaaaaand:
I completely forgot to run the commands to update this host at all or download / unpack any sort of Netmiko or Napalm libraries as its a brand new host:
apt-get update
apt-get install python3-pip
pip3 install -U netmiko
pip3 install -U napalm
pip3 install -U simplejson
Now that we have those all locked and loaded on the NetAuto Host, let try again!
ANOTHER ERROR PILE UP WHEN EXECUTING THE SCRIPT!
Though I wanted to share this error once again, because it spells out exactly what the issue is, the “ip scp server enable” needs to be enabled on R1 which I’ve now done:
I did actually read this somewhere in documentation and completely forgot about it over my day off labbing yesterday, so when you read something its probably best to apply the config, before you go off for a night drinking beer and blowing up fireworks š
The error handling and return codes for errors is amazing how good of a job that build team does to tell you in plain text what exactly went wrong I also updated the script:
Being that this is not an “iosvl2” image but rather just an “iosv” image I am not sure if that makes a difference, but probably best practice for making clean scripts, so I put it in there and NOW LETS SEE IF IT FINALLY WORKS SO I CAN SLEEP TONIGHT(!) :
Success!!! I think???? Lets go check! :
When first logging into R1 I saw this so it sure appears some Automation Ninja snuck in via SSH to commit some new settings š
Lets check it out:
!
interface GigabitEthernet0/1
ip address 123.123.123.1 255.255.255.0
ip access-group 101 in
duplex auto
speed auto
media-type rj45
!
!
access-list 101 deny ip 172.16.30.0 0.0.0.255 host 101.101.101.101
access-list 101 deny ip 172.16.30.0 0.0.0.255 host 202.202.202.202
access-list 101 permit ip any any
!
Success!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Now to verify verify verify from SW2 on ACME Co LAN SW2 that was just pinging those two loopback address on LoopedBack Inc’s SW1 loopback interfaces:
The expected result kind of, though I would expect to see “!A” as the return results which indicates “Administratively Dropped” whereas a “U” generally means no return route from the Upstream Device (Hence the “U” in the response).
Though its not what I expect, it worked, and I will end this lab here for tonight!
Being that it is Sunday, and I’ve had a whole day yesterday to bake in the hot sun / drink cold beer / hang out with family, I am happy to have come home and finished this off.
Much needed battery recharge, as I have another uphill mountain to climb with CCNA DevNet, and having 7 years of Networking Experience and a CCNP, that is a bold statement as that blueprint is massive for the CCNA DevNet.
My hope is to have Python and how it interacts with the network completely down before my July 14th CCNA DevNet Cisco Instructor led Study Group kick off, so I at least have one skillset needed in the bag š
Next up I will look at options to perform with NAPALM before just “commit”ing the changes to the devices sent out – Until next time! š
The DEVNET GRIND! 