The Adventures Continue

The New and Improved Lab

It's been some time since I last updated this, and my home lab has now grown to include an ASA 5505, a total of 15 routers, a few layer 3 switches, and 5 2950's. I also purchased an off-lease server: a poweredge C1100 with dual quad core Xenon cpus and 72GB of ram.  I've also decided that I wish to pursue my VCP so I have begun increasing the equipment in my lab to support an ESXi environment.  Needless to say, the available hardware for creating complex labs is finally available to me (along with the ability to exponentially increase my power bill).  And with that, I bring the latest lab that I am currently working with and will be posting about.  I am using this topology for prep for my CCNA Sec (yes I know its likely overkill) but also to experiment with various technologies such as Snort, open source SIEMs, centralized logging across an enterprise, backtrack fun, and experimenting with ESXi as I haphazardly learn about its operation in my little sandbox. I'm going to overview its configuration throughout the next series of posts, and touch on CCNA Security concepts along the way. 

Lab Details

• OSPF will be used as the routing protocol between the ISP_Core and Corp operated border routers
• EIGRP will be used for any internal routing (those clouds will expand as I put more of my equipment to use)
• Switches will be locked down utilizing switch security outlined in the CCNA Security syllabus
• Zone Based Firewalls will be configured (both via CLI and CCP) on all corp operated edge routers
• ISP routers will utilize packet filters to filter out common undesirable protocols
• Site to site VPNs as described in topology
• ESXi server will host a VM of an opensource firewall/IPS snort based system
• Vswitches will be used to then route traffic to corp operated assets-RADIUS, TACACS, logging, fileserver to use as examples, and shared with the rest of the enterprise via VPN tunnels
• Corp ASA will be configured to utilize anyconnect client w/ IPSec and SSL for remote workers (later placed down off the public IP cloud)
• A web server will be statically natted off the corp ASA for following NAT configuration within ASDM, utilizing one of the public IPs between the corp ASA and corp border router
• A linux based IDS will use a port mirror off corp_sw1's interface leading to the ASA for watching all traffic entering/leaving the corp network
• All ASA and ZBF logs will be sent to the datacenter, utilizing site-site VPN for central aggregation within a log analyzer (not necessarily ccna sec related, but I want to test some of the different open source SIEMs out there)
• Backtrack will be employed around the mock enterprise to try and break things, both before and after placing security configurations, and to test the effectiveness of the different SIEMs 

So obviously this is a rather complex lab, and at this point in time I have everything cabled, and will be configuring it in small chunks and posting about it along the way.  Some of this is CCNA sec, some of this is different scenarios I've wanted to try in a lab, but ultimately I wish to tie it all in together into one nice lab so I don't have to continue re-cabling every time I want to try something new.

EIGRP Authentication

To illustrate the similarities (and differences) between OSPF and EIGRP, I will be using the same topology and IP addressing from my OSPF lab.

The assumed starting point with this lab is that all devices have been cabled, and IP addressing has been set on all serial, ethernet, and loopback adapters.  Since I already covered PPP authentication in my previous lab, you can either opt to enable it, or just enter encapsulation ppp on the interfaces and forgo the authentication.  EIGRP authentication will be enabled on the 10.0.0.0/8 network.

If you are continuing this lab directly after the OSPF lab, you can easily clear your OSPF settings, and keep everything else, by entering

R1(config)# no router ospf 1
R2(config)# no router ospf 1
R3(config)# no router ospf 1

Remember that with EIGRP, there aren't special neighbor relationship states like in OSPF.  Routers will either become neighbors with one another, or they will not, depending on if they pass the requirements to be neighbors-if you can't recall these, they are:

operating in the same subnet
both configured with the same AS number
matching K values
successful authentication

Interestingly, the hello timers do not need to match, however if you do modify the hello/dead timers, you need to ensure that the configuration will work, and a neighboring router's dead timer does not expire.

To begin, we will start at router R1.  Keeping in mind that we must use matching AS numbers, we will use the value 7 for our AS number on this network.  Like OSPF, EIGRP uses wildcard masks with its network statements.

R1(config)# router eigrp 7
R1(config-router)#network 10.0.0.0 255.0.0.0
R1(config-router)#network 172.30.1.0 0.0.0.255
R1(config-router)#network 192.100.254.0 0.0.0.3

R2(config)#router eigrp 7
R2(config-router)#network 10.0.0.0 255.0.0.0
R2(config-router)#network 172.30.2.0 0.0.0.255
R2(config-router)#network 192.100.254.0 0.0.0.3
R2(config-router)#network 192.100.254.4 0.0.0.3

R3(config)#router eigrp 7
R3(config-router)#network 10.0.0.0 255.0.0.0
R3(config-router)#network 172.30.3.0 0.0.0.255
R3(config-router)#network 192.100.254.4 0.0.0.3

Next, we will configure EIGRP authentication over the 10.0.0.0/8 network.  EIGRP authentication is slightly more complex then the configuration set on OSPF and has a few more features available.

EIGRP uses the concept of key chains.  These key chains can be given a lifespan, so that you can automatically rotate different passwords amongst the routers based on two parameters- accept-lifetime and send-lifetime.  The router dates and clocks must be synchronized in order for key lifetime to work correctly.

Starting on R1, our first step will be to create a key chain.

R1(config)#key chain red

Next, we define an individual key by giving it a number and a name

R1(config-keychain)#key 1
R1(config-keychain-key)#key-string LAN

In this lab, I won't be configuring lifetimes for the keys, but the command syntax is:
accept-lifetime [H:M:S] [month] [day number] [yyyy] [H:M:S] [month] [day number]

The send-lifetime command uses the same parameters.

Now we will instruct the router to use this key on its fa0/0 port

R1(config)#int fa0/0
R1(config-if)#ip authentication mode eigrp 7 md5
R1(config-if)#ip authentication key-chain eigrp 7 red

Now, for authentication to be successful (and for the neighbor relationships to form again) the key-strings and key numbers for R1, R2 and R3 must match.  The key chain name does not need to match.

R2(config)#key chain blue
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string LAN
R2(config-keychain-key)#int fa0/0
R2(config-if)#ip authentication mode eigrp 7 md5
R2(config-if)#ip authentication key-chain eigrp 7 blue

R2 and R1 should now be neighbors on the 10.0.0.0/8 network.  You can confirm this with the command
show ip eigrp neighbors.  You will see 10.0.0.1 listed, but not 10.0.0.3 as authentication has not yet been configured on R3.

Authentication will now be configured on R3

R3(config)#key chain yellow
R3(config-keychain)#key 1
R3(config-keychain-key)#key-string LAN
R3(config-keychain-key)#int fa0/0
R3(config-if)#ip authentication mode eigrp 7 md5
R3(config-if)#ip authentication key-chain eigrp 7 yellow

Now, when you run show neighbors on R2, you will also see R3 as authentication matches between the three routers on the 10.0.0.0/8 network.

In a subsequent post, this lab will be expanded on and I will go into further detail about tweaking successor routes and feasible successor routes by changing the bandwidth and delay value on the links.

EIGRP-Successors and Distance

The terminology describing the distance or metric as seen by a router and its neighbors in EIGRP can be confusing.  Lets start first with the Feasible Distance (FD) and Reported Distance (RD).

Feasible Distance: This is the calculated metric at the local router to a destination subnet
Reported Distance: This is the metric advertised, or reported, by an EIGRP neighbor to reach the advertised route.
It is easier to understand this concept with a diagram:

(These are hypothetical values)

R1's feasible distance to reach its directly attached fa0/0 subnet is 28,610.  When it advertises this route to R2 through either a topology exchange or a bounded update, it will advertise the metric as 28,610.  At R2, this is the reported distance.  R2 then takes into account the bandwidth and delay of its serial link to R1 in order to reach the 10.0.1.0/24 network.  This calculated metric is R2's feasible distance, or in this example 1,258,478.


The Feasibility Condition: Successor Routes and Feasible Successor Routes
Next, we have the terms Successor Route and Feasible Successor route.  A successor route is a route with the lowest metric to a destination subnet.  A Feasible Successor route is essentially a backup route, but it has to meet a certain condition in order to be eligible in EIGRP.  This "eligibility" is determined by what is called the "Feasibility Condition".  In order for a route to be considered a feasible route, it must have a RD that is lower than the successor route's FD.

Again, this is something that is easier to understand by seeing it in a network diagram.  I have again used hypothetical values RD/FD values to make it easier to understand the concept.

As you can see in the diagram, R2 is advertising a RD of 2,020,000.  R3 is advertising a RD of 220,000.  The FD from R4 to R1 is 280,000.  In order to meet the Feasibility Condition, a route's RD must be less then the successor route's FD.  R2's route clearly exceeds this with a RD of 2,020,000.  R3's RD on the other hand, is 220,000, which is less than the FD of the successor route on R4-280,000.  The route through R3 to R1's subnet is then considered a feasible successor route.

Terminology aside, in plain English: R3's route can be considered a valid backup route, since the metric R3 is reporting is lower then R4's best route metric.

In this instance, the successor route (R4-R1) would be installed in the routing table, and the feasible successor would be visible under a show ip eigrp topology


Remember though-there can in fact be more then one successor route.  Depending on the load balancing options configured on the router (the default is 4 equal metric routes), if four routes are found to have the best metric, and have equal metrics, all four of those routes will be successor routes and will be installed in the routing table.

There can also be multiple feasible successor routes, provided they meet the feasibility condition.  Feasible successor routes are not installed in the routing table, but can be seen in the EIGRP topology table.

 I'll explain the configuration details of equal and unequal load balancing in a later post.

EIGRP Theory

EIGRP- Enhanced Interior Gateway Routing Protocol
This is only meant to be a brief overview.  I will be posting about the DUAL algorithm, the "feasibility condition" and terminology (anyone who has worked with EIGRP knows how confusing the chosen terms can be), and configuration/verification in their own separate sets of posts.

EIGRP-The "hybrid" routing protocol.
EIGRP is known as a hybrid routing protocol.  Its metric can make use of bandwidth, delay, reliability, and load.  By default, only bandwidth and delay are used.  EIGRP does not send periodic updates, and routing information does not expire.  Instead, EIGRP is aware of its neighbor's connection status through the use of hello messages.  If these messages are not received within a specific interval time, and the hold timer expires, EIGRP declares the route to be down and can immediately change to a backup route (known as a feasible successor route) if it exists, or it will use the Diffusing Update Algorithm (DUAL) to send a series of queries to neighboring routers in search of a valid path to the destination subnet.

EIGRP can operate in both a classful and a classless addressing scheme.  It does enable auto-summarization by default, so this is something to watch out for if working in a discontinguous network, or one that utilizes VLSM.  Unlike OSPF, any router can make use of summary routes in order to reduce the size of the routing table.

EIGRP Neighbors
The concept of neighbors is similar to OSPF, but simpler as there are not different states of the neighbor relationship-routers either form a neighbor relationship, or do not form a relationship.

Routers may form a neighbor relationship if:
-They are operating in the same subnet
-The routers are both configured with the same Autonomous System (AS) number
-The K values on both routers match
-Both routers pass authentication, if configured

If these four parameters are successfully met, the two routers become neighbors and begin by initiating a full topology transfer using the Reliable Transport Protocol (RTP).  After this topology exchange, the routers continue to send periodic hellos to the multi-cast address of 224.0.0.10.  In the event of a topology change, the router will notify its neighbor with an EIGRP update message using either the multicast address of 224.0.0.10 on multi-access networks, or the router's unicast IP address in a point to point type of relationship.  Two terms are used to describe EIGRP's update messages-bounded and partial.  A partial update will contain new information such as when a route changes, or a link goes down.  These are only sent in the event of a topology change.  The term bounded means that the updates are only sent to routers that are affected by this new change in the network topology.

Timers
The default hello interval depends on the link type being used.  Usually, a router configured to operate on a multi-point nonbroadcast multiaccess (NMBA) network such as Frame Relay, will have a default hello interval of 60 seconds.  The default hold time is 3x the hello interval.  On most other networks, the hello interval defaults to 5 seconds.  Unlike OSPF, these timers do not have to match in order to form a valid neighbor relationship, however if the timers are configured incorrectly, and the hold timer expires before receiving another hello message from its neighbor, EIGRP will drop the adjacency.

DUAL FSM
DUAL FSM (finite state machine) is the algorithm used by EIGRP to calculate the best path to a destination subnet.  It works to provide loop-free paths, and backup loop-free paths, which can be put to immediate use.  If a link goes down, DUAL makes a logical decision depending on whether it has any valid backup routes in its topology table-directly install a backup route (feasible successor route-this will be explained in further detail later), or if a feasible successor route does not exist, it will place the destination subnet in a "active" state and send queries to its neighbors.  If the neighbors have a valid route to the destination subnet, one of the types of messages they will send back is a reply message with information about the route.