I was just going to watch the BGP series without taking notes on NAPALM, but its been so long since I’ve configured it from scratch I figured I could knock the rust off, below is a quick review of the configs in my Multi-AS BGP Topology I’ve created for this lab.
Note – This lab does get cut short at the end by what appears to be a bug, and I need to really start trucking getting through as my Python as I can cover this weekend, but the info here is a good quick overview of working again with NAPALM and BGP!
How I configure my devices with BGP settings – Using Loopbacks as Update-Source
I prefer to use the “update-source lo#” and create an IP route where possible on neighbors iBGP and eBGP, not sure at all what the best practice is, however I know it obscures the true outside IP from would man in the middle attackers.
However with the ISP AS-200 on the Topology, I did just do a straight connection to the router, however I did configure the internal routers a little more unique just for some labbing fun with BGP to knock the rust off my BGP Configuration skills:
SW1
!
ip routing
!
router bgp 100
bgp log-neighbor-changes
network 192.168.20.0
network 192.168.238.0
neighbor 111.111.111.111 remote-as 100
neighbor 111.111.111.111 update-source Loopback11
neighbor 111.111.111.111 next-hop-self
!
ip route 111.111.111.111 255.255.255.255 192.168.238.111
Note that SW1 does need IP Routing turned on, I create a static route to point at R1’s loopback as I’ve configured them to use those as the update-source (rather than using the interface IP as the neighbor), and created the iBGP next-hop-self out of habit here to allow BGP Routers behind SW1 in the same AS to propagate BGP Routes!
R1
!
router bgp 100
bgp log-neighbor-changes
network 123.123.123.0 mask 255.255.255.0
network 192.168.238.0 <—
network 200.200.200.0 <— Wheres the mask???
neighbor 11.11.11.11 remote-as 100
neighbor 11.11.11.11 update-source Loopback111
neighbor 22.22.22.22 remote-as 300
neighbor 22.22.22.22 ebgp-multihop 2
neighbor 22.22.22.22 update-source Loopback111
neighbor 200.200.200.250 remote-as 200
!
ip route 11.11.11.11 255.255.255.255 192.168.238.11
ip route 22.22.22.22 255.255.255.255 123.123.123.2
Where’d the /24 mask go?? BGP does auto-summary (depending on the device image I am sure), so I would advise using “no auto” if you are entering multiple subnets within a Classful Subnet.
I did enter “no auto” but because its /24 it still does not show a mask, so BGP can be that way, I will leave it at that with this behavior and BGP “network” statements!
Also we see the “ebgp-multihop 2” in the neighbor statement, as the rule for eBGP neighbors is they should be point-to-point, and if not they require this command to create a BGP Peer. I did not do this back to SW1 because it is iBGP (AS-100) whereas R2 is eBGP (AS-300).
I won’t go into the other ACME Co site as it is configured the same, both Edge Routers for the “Companies” in the Topology connection to the ISP is just direct IP to IP without the loopback update source as I don’t generally see ISP’s make any kind of cutesy configs like this and have other mechanisms for securing transmission of routes / data.
With that, I will return back to the NAPALM portion of all of this BGP Chaos
To begin I will use a very simple script just to touch SW1 only to grab some info, and again use JSON to format the output for readability, as shown below:
These different values that I will be going through can be again found at:
https://napalm.readthedocs.io/en/latest/support/
This website is a great resource for writing NAPALM scripts, I haven’t checked out the GitHub nearly as much as I should, but this website has been great thus far.
I then copy / paste from VSC to NetAuto Host as a Py script, and execute on SW1:
This give a lot of information including the 3 network prefixes sent (loopback of 11.11.11.11, LAN of 192.168.20.0/24, and its 192.168.238.0/24), show up = true, local and remote-as 100, Uptime of the Adjacency, Prefixes Recv’d / Acccepted, tons of good stuff!
(An “Uptime = -1” means the Neighbor Adjacency is down in this output)
I’ll change this up to R1’s IP Address to see the output receive back from that here:
My chicken scratch may be difficult to read there, the Top output is SW1 Peer, then R2 Peer, then ISP Peer which are all showing good output of Uptimes / is_up = True / Prefixes Rec’d and Accepted / Etc.
How do I get all my BGP Neighbors information all at once? Python Lists!
Given that BGP is Transport Protocol meaning it will advertise prefixes but now provide routes to reach them (and vice versa on the other side), so in the current state I can only hit SW and R1 with my current configurations on the BGP lab to hit with this new script:
This uses a Python List with the variable name “bgplist” which is then used within a “for” loop to go through and connect to each IP in the list, and retrieve the info as shown here:
Nothing different at all, just a way to use Lists / Loops to grab more info at once, as we try to Automate more tasks on the network using Python as possible!
GNS3 kind of hits the breaks on my lab here, and I am not exactly sure why!
I have not worked with GNS3 to understand if this is a glitch, but the NetAuto Host in the Topology cannot ping beyond R1:
From here you can see me ping within the LAN, but once it tries to go outside the responses halt, so I did a wireshark on its Eth0 interface and simply just says that its not getting a response to any pings (even R1s outside interface of 123.123.123.1):
Even though SW1 that connects directly to the Host is able to ping to the Remote Nets:
Frustrating indeed, but while the battle is lost with BGP, the NAPALM war lives on!
I will take this as my queue to segway into actually deploying configurations via NAPALM, as we can basically just take the scripts already seen and expand upon them in our own topologies at a later time for practice, however I’d like to keep this NAPALM train chugging along – So I am going to reset our Topology here and NAPALM the network with pushing out configurations using files on the NetAuto Host!
The DEVNET GRIND! 