CLUS 2017 – A remote view

This year I was unable to make it to Cisco Live U.S. for a variety of reasons. Sometimes the stars don’t align and you can’t make logistics work, or maybe financials just fall short. That doesn’t mean you can’t “go” to CLUS even if it may be remotely and in spirit. Trust me, if the spirits right it’s an exhausting week even when you aren’t there.

I dedicated a lot of effort this year into “attending” even though I was remote just shy of a couple thousand miles away. Here’s how I did it!
Read the rest of this entry »

Permanent link to this article: http://www.packetpilot.com/clus-2017-a-remote-view/

MPLS Headend FVRF Migration Strategy

Say you have a network that currently has an MPLS WAN from your HQ to all of your Branches. You want to migrate these MPLS connections into a DMVPN design and in doing that, you would like to move the MPLS links into a Front Door VRF. There comes a challenge with this move in regards to the routing tables and when to move the headend.

Read the rest of this entry »

Permanent link to this article: http://www.packetpilot.com/mpls-headend-fvrf-migration-strategy/

Python + XLRD SecureCRT Import

First of all a disclaimer. I am NOT a programer. I promise this could probably be cleaned up considerably by someone that actually does programming. Also, It may require some tweaking to work on your system. This is tested on Mac 10.12.3 and SecureCRT 8.1*

I’ve always loved using SecureCRT. I often find myself needing to add anywhere from a small to a large number of sessions to my list. Especially in my current role. I had remembered in my past at an old roll where I used Windows as my primary OS (work issued) that I had discovered a forum that had a python and VBS script to import sessions out of a CSV. Now that I am running on Apple I sought out that old forum and grabbed the python script. Drats!!! The python script doesn’t work on my new version of SecureCRT for Mac (8.1). Then I started thinking. Most of the time clients give me a nice spreadsheet of IP addresses. This got me thinking, why not write my own that uses Excel. So here it is!

  Read the rest of this entry »

Permanent link to this article: http://www.packetpilot.com/python-xlrd-securecrt-import/

Cisco Champions 2017 – A reason to reflect

tl;dr – THANK YOU ALL!

Yesterday morning I opened up my Spark app and was surprised to see I was added to the Cisco Champions room. I checked my e-mail and saw nothing. I knew it was being announced soon do to some twitter chatter. After validating with members it was true. I was selected as a 2017 member of Cisco Champions. I’m going to say I’m blown away even still today. I am absolutely honored to be part of such an amazing group of individuals. It has caused me to sit back and think about how I even came to know the people I look up to. So how did it start?

Read the rest of this entry »

Permanent link to this article: http://www.packetpilot.com/cisco-champions-2017-a-reason-to-reflect/

2017 – Whats in my bag

The new year just sprung upon us. This is usually when I go through my bag and reorganize. I figured hey why not post what I carry. I know, it’s nothing new nor original. I’m surely not the first person to do this post. I always find it interesting though to see what others carry so maybe someone is interested in my daily carry.

2017 Carry Bag

So, here we go. Lets start with the top left and move through from there.

  • Super Glue
    • I always end up ripping a finger or knuckle home on something. Super glue it the go to fix
  • Pain Reliever
  • Extra Pair of Contacts
    • Hey, I’ve lost one before and it isn’t fun being half blind
  • Visine
    • Again, contacts…they tend to dry out in datacenters
  • Bose Soundsport bluetooth headphones
    • For conference calls, general listening. Paired with laptop and phone
  • Laptop Charger
  • Kobalt 6x speed driver and bits
    • Seriously the coolest and most efficient screwdriver. Each turn and back cycle = 6 spins.
  • Small LED flashlight
  • Old Wacom Tablet for drawing diagrams on projectors when whiteboards aren’t available
  • Fluke Networks rollup pouch
    • Holds misc cables and adapters
  • The original Air Console.
    • Freedom from the rack!!!
  • Stock iPhone headphones and charger
    • No I haven’t upgraded to the 7
  • Thumb Drive and SD card
  • Whiteboard Markers
  • Console Cable
  • Battery Pack
  • Metallic Sharpie
    • Ever need to take notes about cables on a black network rack?
  • Pen and Pad of paper
    • Sometimes you just have to write analog style
  • Laptop
  • Bose QC 15 cans
    • Again, haven’t had a reason to upgrade but love noise canceling when necessary

 

So where does it all go? It seems like a lot listed out but to be honest it barely fills up the backpack I carry. I currently carry an OGIO Renegade RSS. Plenty of room for more than you need. Also, before anyone asks “what? No box cutter?!”. Daily carry is a Gerber Paraframe of sorts on my person.

 

 

 

Permanent link to this article: http://www.packetpilot.com/2017-whats-in-my-bag/

Using MRM to test Multicast

I’ve always wanted to find a quick way to test a multicast deployment in a Cisco environment. Many of us are already familiar with simply pinging a multicast address from an interface, and going to another router and issuing the ip igmp join-group command.

I’ve came across a new way to test that I’ve missed over the years but has apparently been around. This tool is the Multicast Routing Monitor. It has a fairly straight forward configuration and will at least give you some view into your multicast domain and it’s functionality.

Read the rest of this entry »

Permanent link to this article: http://www.packetpilot.com/using-mrm-to-test-multicast/

Advertise Static Routes in EIGRP without Redistribution

I came across a paragraph in an older book in regards to EIGRP operation. As I read it I was kind of dumfounded. To be honest I didn’t believe it at first so of course I had to lab it to see if it was true. It turns out that it is in fact the way EIGRP operates in this very specific circumstance. I had never seen it before in some of my favorite books nor through my favorite video training vendors. So my findings are this: In a very specific scenario, EIGRP will advertise static routes into EIGRP as internal routes without any redistribution statements.

Read the rest of this entry »

Permanent link to this article: http://www.packetpilot.com/advertise-static-routes-in-eigrp-without-redistribution/

CCNA – HSRP Config – Prempt- Priority – Version

This lab will cover the topics 5.5.a, 5.5.b, and 5.5.c HSRP Priority, Preemption, and Version from the Cisco Certified Network Associate (CCNA) blueprint. It will test your understanding and knowledge of configure DHCP Servers on Cisco IOS devices. Please use the initial configurations as a template for your lab utilizing whatever console means you have (GNS, Physical Gear, VIRL, etc).

CCNAHSRP


In this lab we will configure the First Hop Redundancy Protocol calls Hot Standby Router Protocol (HSRP). This is a two part lab. The first part we will configure “Legacy” HSRP. In part two we will configure HSRPv2. The initial config files contain the starting configs that will be used for both labs. They set up routing and DHCP for you.

Part1:
Configure R1 Eth1/0 with address 192.168.12.3
Configure R2 Eth1/0 with address 192.168.12.2
Configure HSRP on R1 and R2 using the Virtual IP address of 192.168.12.1
Ensure PC can obtain a DHCP address and ping 3.3.3.3 with either R1 or R2 failing.

Part2:
Rebuild HSRP using group number 4000
Use Virtual IP address of 192.168.12.1
R1 should be active whenever it is online. If it is to fail and come back it should take over as the active forwarder.

SHUTDOWN R1

RESTART R1

Remove Old

COnfigure V2

Simulate R1 Failure

SIMULARE RESTORE

R1

R2

R3

Permanent link to this article: http://www.packetpilot.com/ccna-hsrp-config-prempt-priority-version/

CCNA – DHCP Client And Relay

This lab will cover the topics 5.3.b DHCP Relay and 5.3.c Client from the Cisco Certified Network Associate (CCNA) blueprint. It will test your understanding and knowledge of configure DHCP Servers on Cisco IOS devices. Please use the initial configurations as a template for your lab utilizing whatever console means you have (GNS, Physical Gear, VIRL, etc).

CCNADHCPClientAndRelay


In this lab you configuration will need to be added to routers 2 and 3 to establish their correct IP addressing.

R2 – Ethernet0/1
Address: 12.1.2.2/24

R2- Ethernet0/0
Address 23.2.3.2/24

R3 Ethernet0/0
Address 23.2.3.3/24

Add Default routing on R3 to establish connectivity back to R2’s Ethernet 0/1 segment.

Configure a DHCP scope on R3 to provide IP addresses for R2s E0/1 segment excluding R2s address and using it as a default gateway.

Configure R2 to relay DHCP requests to R3 for address lease obtainment. R1’s Ethernet 0/1 interface should be set to use DHCP.

To begin we will configure R2’s ethernet interfaces with the indicated IP addresses.

Next we will configure R3’s Ethernet 0/0 interface and create the default routing towards R2.

As indicated in the directions we will exclude R2’s Ethernet 0/1 address from any created DHCP Pools and create a pool to supply addresses to the 12.1.2.0/24 subnet utilizing 12.1.2.2 as the default gateway. This configuration will be done on R3

With this configuration in place we will debug R1 with debug DHCP detail which will enable DHCP client messages. On R3 we will debug DHCP server packets to verify it’s DHCP pool functionality. After debugs are enable we will enable the R1 Ethernet 0/1 as a DHCP client.

I have copied the output of a single attempt from R1’s debug to obtain a DHCP lease. There is no output from R3 indicating that it never received a request for an address from a DHCP pool.

Not fix this issue we will add the necessary command for relaying DHCP requests to R2. This command is applied on the incoming interface for DHCP discovery messages. In the case of R2 it will be on the Ethernet0/1 interface.

Now that we have the helper-address in place we will bring up the R1 interface again with debugs running on all three routers.

R1’s debug is show below. We can see the router issues DHCP discover messages out it’s interface ultimately coming up with and address of 12.1.2.4 with a default gateway of 12.1.2.2.

On R2 with DHCP server debugs on we can see R2 setting the GIADDR value to the interface the DHCP Discovery came in on. This is relayed to the address listed in the helper-address configuration and is used to help identify the correct DHCP pool to pick address from.

On R3 we can see the DHCP Discover message being received and it is indicated that it came in through the relay address of R2’s interface. The DHCP server utilizing this information to select an address from a pool and send it back to the relaying router as unicast. R2 then sends it to the appropriate client and this process repeats through the DORA operation.

We can now use R1 to verify our configuration is successful. With everything in place we should see a default route achieved from the default-route command in the DHCP pool pointing to R2’s interface on Ethernet0/1. We can also ping R3’s 23.2.3.3 address.

There are no initial configurations for this topology. All you need is a blank router with two interfaces in two different LAN segments.

Permanent link to this article: http://www.packetpilot.com/ccna-dhcp-client-and-relay/

CCNA – DHCP Server and Options

This lab will cover the topics 5.3.a DHCP Server and 5.3.d TFTP, DNS, and gateway options from the Cisco Certified Network Associate (CCNA) blueprint. It will test your understanding and knowledge of configure DHCP Servers on Cisco IOS devices. Please use the initial configurations as a template for your lab utilizing whatever console means you have (GNS, Physical Gear, VIRL, etc).

CCNADHCPServer


In this lab we will be looking at the use of a router as a DHCP Server. Cisco IOS provides you with the tools to create mulitple DHCP pools with the router itself acting as the DHCP Server. In this lab your task is to configure the two LAN segment interfaces as well as the DHCP Pools associated with them. The settings you need to enable are as follows:

Lan Segment 1 (PC 1 & 3):
Ethernet Interface: First available address in 172.16.18.0/23
DHCP Network: 172.16.18.0/23
DHCP Gateway: Ethernet Interface IP Address
DNS Server 1: 8.8.8.8
DNS Server 2: 4.2.2.2
TFTP Server: 10.1.1.1

Lan Segment 2 (PC 2):
Ethernet Interface: First available address in 192.168.16.0/20
DHCP Network: 192.168.16.0/20
DHCP Gateway: Ethernet Interface IP Address
DNS Server 1: 4.2.2.2
DNS Server 2: 8.8.8.8
TFTP Server 10.1.1.1

To begin with our lab provides us with two IP address to use for our Ethernet interfaces on our router. Starting with the left side of the diagram we will configure our interface and dhcp server for the 172.16.18.0/23 Subnet.

One of the first things I do before starting to create a DHCP pool is to exclude the address of the router interfaces from any pools that are created. This is an often forgten and overlooked step.

Our lab directions ask us to create a DHCP ool with specific settings. One thing that is not indicated is the name of the DHCP pool. This is an arbitrary name and should make sense to you when you are looking through your configurations later. In this case I am going to use CLIENTS-172 to indicate the network associated with 172.16.18.0. In DHCP configuration TFTP servers are indicated with DHCP Option 150. There are many other options available, however TFTP servers is indicated specifically on the blueprint so we wil configure it here.

Our settings to be configured as per the directions are as follows:
Network: 172.16.18.0/23
Gateway: 172.16.18.1
DNS Server 1: 8.8.8.8
DNS Server 2: 4.2.2.2
TFTP Server: 10.1.1.1

Now that our DHCP pool is configured we can test it out. Before we test we will turn on debugs so we can see the DHCP Pool in action. First we will turn on debugs for DHCP events, bring up a PC and then turn on debugs for dhcp packets before bringing up the second PC. This will let us see the different outputs.

In the first debug output we can see the server recognizing a DHCP request and checking out an internal DHCP pool. The second output shows the entire DHCP process commonly known as DORA. We see the initial Discover message send by the client in which the server returns a DHCP Offer. The client is happy with this address and sends the server back a DHCP Request asking to use the recommened address. Finally, the DHCP server responds with a Acknowledgement offer indicating both agree on the clients address and the binding is created.

A useful tool in the DHCP server are the outputs of the show ip dhcp pool and show ip dhcp binding commands. The later will show you the IP address and associated Client ID for each lease the DHCP server has created. The show ip dhcp pool will give you statistics on percentage of addresses in use, as well as total address and leased address counts. Creating a quick DHCP pool and checking this output is a great way to verify your subnetting in regards to host capacity when you aren’t sure of your math and don’t have handy access to a subnet calculator.

We now need to configure the second link on our router as well as our second DHCP pool for the clients on the right. Again, the DHCP pool name is arbitrary however, it must be unique on the router meaning we cannot use the same name we entered earlier. Using meaningful names for the subnets helps prevent this. Once again we will first configure the interface, and exclude the interfaces address before creating the DHCP pool. Our settings are as follows:

Network: 192.168.16.0/20
Gateway: 1192.168.16.1
DNS Server 1:4.2.2.2
DNS Server 2: 8.8.8.8
TFTP Server: 10.1.1.1

Notice how in thie case I issued the network command with a /20 CIDR notation. Some platforms will allow this, others require the subnet mask in decimal form. Always double check your config after entering it to verify it is as you want.

Once again we will turn on dhcp server packet debugging to watch the DORA process and verify it functions correctly.

Now that we can see our second client successfully got a lease from the DHCP server we can test end to end connectivity. So long as both DHCP pools provide the correct network, mask, and default-route the PC’s should be able to ping each other in this simple one router topology.

There are no initial configurations for this topology. All you need is a blank router with two interfaces in two different LAN segments.

Permanent link to this article: http://www.packetpilot.com/ccna-dhcp-server-and-options/

Older posts «