I posted notes from 3 different topics this morning. I've been out of town, traveling for work and my ability to study has been somewhat limited. However, I'm back in it today and catching up on all the things I have been putting off.
It's easy to get discouraged when the plan starts to falter. I know that I typically set lofty goals for study and test-taking, and when things don't go as planned I feel a little pressured to perform. It's important to remember that falling off the plan doesn't produce failure in general, it simply delays it for a short period of time and that the race is won by the persistent.
I'm back in the swing today, and we'll keep pushing forward. Life is going to happen - and as much as I'd like to say that there is nothing so important as obtaining a CCNP certification, I have 5 children that would disagree. Not to mention a beautiful wife who would like to see me once in a while as well...
Monday, May 23, 2011
EIGRP Router ID
EIGRP produces a Router ID, which is a 32-bit number in dotted decimal format. The Router ID (or RID) is used in external EIGRP to prevent routing loops. IN a properly configured network, the highest IP address assigned to a loopback address becomes the RID, and if no loopback interface is configured, the router's highest IP address becomes the RID. For an excellent explanation of the problem and configuration, look here.
Each router determines its RID when the process starts using the same general rules as OSPF:
The EIGRP RID has little value unless you are injecting external routes. That is when you are required to have unique RIDs to avoid confusion.
Show commands seldom list RID values, and are not needed to determine the topology database like OSPF. Duplicate RIDs will not prevent a neighbor relationship from taking place, either.
Each router determines its RID when the process starts using the same general rules as OSPF:
- The router will use a configured value (i.e. eigrp router-id a.b.c.d)
- It will use the highest IPv4 address on an up/up loopback interface
- It will then use the highest IPv4 address on an up/up non-loopback interface
The EIGRP RID has little value unless you are injecting external routes. That is when you are required to have unique RIDs to avoid confusion.
Show commands seldom list RID values, and are not needed to determine the topology database like OSPF. Duplicate RIDs will not prevent a neighbor relationship from taking place, either.
EIGRP Metric Components: K-Values
Normally, EIGRP metric calculation is done using contraining bandwidth and cumulative delay. Other values can be used and configured to tailor the metric and customize routes to match your environment. The default formula for EIGRP metric calculation is 256*(bw + delay), however, the full formula is:
EIGRP Metric = 256*([K1*Bw + K2*Bw/(256-Load) + K3*Delay]*[K5/(Reliability + K4)]).
And the default values are:
K1 = 1
K2 = 0
K3 = 1
K4 = 0
K5 = 0
As can be seen from the above formula, K1 and K2 affect bandwidth & load, K3 affects delay, while K4 and 5 affect reliability. If K5 is equal to zero, then the entire section of the formula is ignored, hence we arrive at the default formula. While not recommended by Cisco, K-values can be used to influence route calculation by modifying the weight of each respective metric component. For instance, in a lab situation bandwidth can be disabled to simplify metric calculation and make it easier to learn the concepts of EIGRP.
It is important to note that mismatched K-values can prevent a neighborship from taking place, and IOS will log mismatched K-values when the router receives an EIGRP packet.
To set K-values, you use the following commands:
router eigrp 1
metric weights 1 0 1 0 0
This command would set the values to the default configuration. To verify that K-values are configured properly, we use "show ip protocols" which would list the K-values.
While K-values are rarely modified, it is beneficial to understand exactly how EIGRP comes up with its configuration. Understanding how and why things work is the greatest troubleshooting tool a network engineer can have.
EIGRP Metric = 256*([K1*Bw + K2*Bw/(256-Load) + K3*Delay]*[K5/(Reliability + K4)]).
And the default values are:
K1 = 1
K2 = 0
K3 = 1
K4 = 0
K5 = 0
As can be seen from the above formula, K1 and K2 affect bandwidth & load, K3 affects delay, while K4 and 5 affect reliability. If K5 is equal to zero, then the entire section of the formula is ignored, hence we arrive at the default formula. While not recommended by Cisco, K-values can be used to influence route calculation by modifying the weight of each respective metric component. For instance, in a lab situation bandwidth can be disabled to simplify metric calculation and make it easier to learn the concepts of EIGRP.
It is important to note that mismatched K-values can prevent a neighborship from taking place, and IOS will log mismatched K-values when the router receives an EIGRP packet.
To set K-values, you use the following commands:
router eigrp 1
metric weights 1 0 1 0 0
This command would set the values to the default configuration. To verify that K-values are configured properly, we use "show ip protocols" which would list the K-values.
While K-values are rarely modified, it is beneficial to understand exactly how EIGRP comes up with its configuration. Understanding how and why things work is the greatest troubleshooting tool a network engineer can have.
Neighbor Requirements in EIGRP
- Routers must be able to send IP packets to each other (duh!)
- Interface primary address must be in the same subnet on neighboring routers
- Must not be passive on connected interfaces
- Must use the same Autonomous System Number on the "router" configuration command
- hello intervals, hello timers and hold timers do not need to match
- Must pass router authentication
- IP MTU does not need to match
- K-values *must* match
- Router ID does not need to be unique, however - duplicate RIDs may cause problems when configuring external EIGRP
Tuesday, May 10, 2011
Statically Assigning EIGRP Neighbors
To reduce overhead of EIGRP multicast traffic, EIGRP allows neighbors to be specifically, or statically defined. This may be useful in an environment where you have a frame relay circuit with several PVCs, but you only want EIGRP to be configured on a couple routers. In a normal multicast configuration, the frame would be replicated to all PVCs and use precious bandwidth that is unnecessary. By statically configuring the intended neighbors, the EIGRP messages only go to the intended neighbors.
Cool.
Configuration of a static neighbor is pretty straight-forward, but again, as with all IOS configuration, knowing how and why things work makes the design and verification much easier. To configure a static neighbor, you would enter the router sub command context and assign the neighbor as such:
router eigrp 9
neighbor <ip_address_of_intended_neighbor> <outgoing_int_on_router>
Some things to note about the above commands:
show ip eigrp neighbors detail
Without the detail command, IOS only shows that a neighbor is valid or not. Other interesting facts about statically assigning neighbors are that IOS disables all EIGRP broadcasts on an interface where a neighbor is statically assigned. There is no need to broadcast out that interface any longer since we're defining specific neighbor partnerships. As a result, any dynamically discovered neighbors will cease to work, and no new neighbors will be dynamically discovered.
Apply with caution, and always know what you're doing before you press "Enter."
EIGRP is fun...
Cool.
Configuration of a static neighbor is pretty straight-forward, but again, as with all IOS configuration, knowing how and why things work makes the design and verification much easier. To configure a static neighbor, you would enter the router sub command context and assign the neighbor as such:
router eigrp 9
neighbor <ip_address_of_intended_neighbor> <outgoing_int_on_router>
Some things to note about the above commands:
- the ip address of the neighbor router must be from the subnet connected to the listed interface
- a "network" command is not required, because EIGRP will still advertise the subnet connected to that interface
show ip eigrp neighbors detail
Without the detail command, IOS only shows that a neighbor is valid or not. Other interesting facts about statically assigning neighbors are that IOS disables all EIGRP broadcasts on an interface where a neighbor is statically assigned. There is no need to broadcast out that interface any longer since we're defining specific neighbor partnerships. As a result, any dynamically discovered neighbors will cease to work, and no new neighbors will be dynamically discovered.
Apply with caution, and always know what you're doing before you press "Enter."
EIGRP is fun...
EIGRP Authentication
EIGRP allows the use of a pre-shared key (or PSK) to create an MD5 digest for each message sent and received. This prevents denial-of-service attacks by refusing neighbor-ship of unauthorized routers, but does not provide any privacy. Because EIGRP multicasts to 224.0.0.10, any router can joint that multicast group and read the messages but won't be able to establish itself as a neighbor. Essentially, they are allowed to look at the Country Club through the gates but not allowed to golf...
Anyhow...
Configuration contains a few commands requiring special attention to detail. It's important to note that the name of the key-chain and the number of the key-chain *do not* need to match between all neighboring routers. All that is important to match is the key-string used to hash the PSK.
To configure:
key chain <name_of_keychain>
key <#>
key-string <string_used_for_PSK>
!Optional - set lifetime
accept-lifetime <start_date> <end_date>
send-lifetime <start_date> <end_date>
After configuring the key chain and PSKs, we enter interface configuration mode and execute the following sub-commands:
ip authentication mode eigrp <asn> md5
ip key-chain eigrp <asn> <name_of_chain>
Time-based logic for EIGRP authentication allows some rotation of keys and provides a higher level of security. The basic rules are:
To verify that EIGRP authentication is working properly, three commands are used:
show ip eigrp neighbors
This will show that neighboring routers are still up and that everything is working correctly. However, for the rare instance when that doesn't "just work" it's best to use:
show key chain
This command lists the valid keychain configuration and valid keys. If your keys aren't valid between all routers, it's not going to send or receive, and if your keys are valid, use:
debug eigrp packet
This command will list messages about why the intended neighbor routers did not authenticate. Typically, you will see messages that state "authentication mismatch" and then one of two reasons, either "invalid authentication" or "missing authentication". Both are relatively self-explanatory, don't you think?
Notes for troubleshooting EIGRP Authentication:
Anyhow...
Configuration contains a few commands requiring special attention to detail. It's important to note that the name of the key-chain and the number of the key-chain *do not* need to match between all neighboring routers. All that is important to match is the key-string used to hash the PSK.
To configure:
key chain <name_of_keychain>
key <#>
key-string <string_used_for_PSK>
!Optional - set lifetime
accept-lifetime <start_date> <end_date>
send-lifetime <start_date> <end_date>
After configuring the key chain and PSKs, we enter interface configuration mode and execute the following sub-commands:
ip authentication mode eigrp <asn> md5
ip key-chain eigrp <asn> <name_of_chain>
Time-based logic for EIGRP authentication allows some rotation of keys and provides a higher level of security. The basic rules are:
- EIGRP will send messages using the lowest-numbered valid key
- EIGRP will receive messages using any valid key
To verify that EIGRP authentication is working properly, three commands are used:
show ip eigrp neighbors
This will show that neighboring routers are still up and that everything is working correctly. However, for the rare instance when that doesn't "just work" it's best to use:
show key chain
This command lists the valid keychain configuration and valid keys. If your keys aren't valid between all routers, it's not going to send or receive, and if your keys are valid, use:
debug eigrp packet
This command will list messages about why the intended neighbor routers did not authenticate. Typically, you will see messages that state "authentication mismatch" and then one of two reasons, either "invalid authentication" or "missing authentication". Both are relatively self-explanatory, don't you think?
Notes for troubleshooting EIGRP Authentication:
- make sure your time is accurate and matched using "show clock" and use NTP to sync time on all routers
- Key chain name and number do not need to match on all routers, *only the PSK (or key-string) needs to match*
- use show key chain to list which keys are valid
- Each interface must have EIGRP authentication configured on it (ip authentication mode eigrp
md5) and the key chain assigned to it (ip authentication key-chain eigrp ) or authentication will fail with an invalid or missing authentication message in the EIGRP debug
Monday, May 9, 2011
EIGRP Passive Interfaces
In some cases, there will be a need to *not* send EIGRP information out a particular interface. To minimize network bandwidth consumption and congestion, it is possible to restrict hello packets to the 224.0.0.10 multicast address. We would do this by either configuring the interface as passive or by not enabling the EIGRP on that interface and using the "redistribute connected" command to send routing information about desired networks.
This scenario would be used when you have 3 offices connected by routers, perhaps using T1's. A T1 connects each router to every other router via serial port, and each router has 2 fast ethernet interfaces connected to different subnets in each office. When the "network" command is executed for each fast ethernet subnet, EIGRP will be enabled on those interfaces even though there is no legitimate EIGRP neighbor on those interfaces and EIGRP messages will go out those interfaces even though there is no need nor any desire for that traffic.
To limit this traffic, the preferred method is to set the fast ethernet interfaces to passive mode by executing the commands:
router eigrp 1
passive-interface fastethernet0/0
passive-interface fastethernet0/1
network
network
This will allow all WAN routers to be aware of routes to all LAN interfaces, but will not send any multicast or unicast messages out the fast ethernet interfaces. This will limit network utilization, as well as add to security by not broadcasting route information out interfaces that have no legitimate neighbors by design.
It is also possible to change the default behavior of EIGRP per ASN by using:
router eigrp 1
passive-interface default
no passive-interface serial0/0/0
no passive-interface serial0/0/1
network
This essentially changes the default so that all interfaces are configured as passive, and to allow EIGRP to broadcast out an interface, you have to disable the passivity.
To verify the configuration, we use "show ip eigrp interfaces" to see which are enabled. While this shows which interfaces EIGRP is enabled on, it does not show any passive interfaces. By using a "show ip protocols" command, we will see which networks are being routed using EIGRP as well as a specific list of passive interfaces.
Controlling route distribution using EIGRP is somewhat straight-forward in this respect. using passive-interfaces allows us to enable and restrict who sees what, allowing the fine-tuning and securing of networks.
This scenario would be used when you have 3 offices connected by routers, perhaps using T1's. A T1 connects each router to every other router via serial port, and each router has 2 fast ethernet interfaces connected to different subnets in each office. When the "network" command is executed for each fast ethernet subnet, EIGRP will be enabled on those interfaces even though there is no legitimate EIGRP neighbor on those interfaces and EIGRP messages will go out those interfaces even though there is no need nor any desire for that traffic.
To limit this traffic, the preferred method is to set the fast ethernet interfaces to passive mode by executing the commands:
router eigrp 1
passive-interface fastethernet0/0
passive-interface fastethernet0/1
network
network
This will allow all WAN routers to be aware of routes to all LAN interfaces, but will not send any multicast or unicast messages out the fast ethernet interfaces. This will limit network utilization, as well as add to security by not broadcasting route information out interfaces that have no legitimate neighbors by design.
It is also possible to change the default behavior of EIGRP per ASN by using:
router eigrp 1
passive-interface default
no passive-interface serial0/0/0
no passive-interface serial0/0/1
network
This essentially changes the default so that all interfaces are configured as passive, and to allow EIGRP to broadcast out an interface, you have to disable the passivity.
To verify the configuration, we use "show ip eigrp interfaces" to see which are enabled. While this shows which interfaces EIGRP is enabled on, it does not show any passive interfaces. By using a "show ip protocols" command, we will see which networks are being routed using EIGRP as well as a specific list of passive interfaces.
Controlling route distribution using EIGRP is somewhat straight-forward in this respect. using passive-interfaces allows us to enable and restrict who sees what, allowing the fine-tuning and securing of networks.
Tuesday, May 3, 2011
EIGRP Review
The morning started with a review of EIGRP. I haven't considered EIGRP for quite some time and don't work with it daily, so a review is good.
EIGRP is a relatively simple protocol to configure from a basic level. With a few simple commands, it can be enabled on a router and will likely run without issue. All it takes is a "router eigrp" with an autonomous system number and a network command and away it goes.
router eigrp 1
network 10.0.0.0
Normally we'd want to add a wild card mask to the network statement, but when a statement like the above is entered, it will enable EIGRP on all interfaces that match the classful IP address in the network statement. If the wild card mask is added, it will apply ACL properties to apply EIGRP only on the interfaces which match the mask.
Commands for verifying the functionality of EIGRP would then be:
show ip interfaces This command shows which interfaces EIGRP is enabled on and routing, omits passive interfaces
show ip protocols Shows which protocols are in effect and which networks are being advertised, or rather the contents of the 'network' commands as well as a list of neighbor IPs
show ip eigrp neighbors Lists the routers who have established relationships with the router on which one is currently working, and does not list neighbors for which a mismatched parameter prevents a valid EIGRP neighbor relationship
show ip eigrp topology shows the topology table, including the successor, feasible successor route, but does not list all known topology details
show ip route Lists all the networks for which this router is aware, including details of how the route was learned (by which protocol, connected, etc) and the administrative distances. All EIGRP-learned routes are labelled with a 'D'
I spent some time reacquainting myself with these commands last night, and was glad to see that with a little effort, I'm able to hone in on the information needed to troubleshoot and resolve any issues. I was also glad to make a mistake in my EIGRP test lab, where I misconfigured an interface. When I added the network to my EIGRP ASN, the route did not propagate. It ended up that the network I added didn't contain the IP address of the interface, and therefore EIGRP knew that there was no information to send to its neighbors. Using 'show ip eigrp int' I was able to see that it was not enabled on all the interfaces for the router. I was then able to troubleshoot backward and see where my mistake had been made.
A good review for the night. I'll continue reviewing tomorrow.
Monday, May 2, 2011
CCNP Day 1
As I begin tonight on my completion of the CCNP certification, I read the intro chapter #1 of Cisco Press' CCNP Route 642-902 by Wendell Odom. My goal is to finish this certification in 7 weeks from today, or rather to test on June 17.
Breaking that down, it's about 100 pages each day to study. I'm planning to work through about 20 each day.
One thing that I wish I had paid closer attention to over the past couple years was my original intent to maintain my CCNA skills. When I achieved that certification in 2009, I intended to continually work through labs where I don't have much exposure at work. This was intended to keep me sharp and ready for recertification or upgrading to the CCNP. Well, today when I took the first "Do I know this" quiz, I realized that I haven't been designing or supporting any EIGRP over the last couple years and I have a bit of catching up to do. I work more with firewalls and switches in my daily job, and do very little (if any) routing. So....now I have some catching up to do.
But I am pretty pumped to get going. I was surprised to read that Cisco has removed QoS from the CCNP requirements. I was hoping to delve into that a bit in the near future to enable me to more efficiently support Cisco's Voice offering which my company recently began selling like crazy.
So today I read about the exam topics and some thoughts about how to prepare for them. There is a large design and documentation component to the CCNP, which include determining resources required, creating an implementation plan and creating a verification plan all before configuring and verifying the solution. After these, results are documented.
While there is no single planning style recommended by Cisco, their PPDIOO model seems most natural to my style. The steps involved here are:
- Prepare
- Plan
- Design
- Implement
- Operate
- Optimize
These are the steps of the Cisco Lifestyle Services, and it seems to me to make the most sense - that or I work in a Cisco shop and that's all I know. Either way, it will get the job done. I also am glad to see the focus on planning and documentation in the CCNP objectives. Working in a support role where I inherit various networks from all kinds of different vendors, I'm always amazed at how little anyone plans or documents when they build a network. More commonly, people throw components together without any thought or consideration for support, and when I finally get the call it's usually pretty ugly. Great for my troubleshooting skills, not great for a customer who relies on their network to get their job done.
So, here we go. For the next week I'll be working on EIGRP neighbors, topology, routes and convergence. It was incredibly valuable to me when studying for the CCNA to summarize my nightly work in a blog, so I'll be doing that here instead of on my personal blog to keep the geek stuff apart from the stuff regular people might be interested in. Feel free to comment, let me know what you think or if you have any words of wisdom for my study. Especially comment if I make a mistake or don't explain something well enough - I want this to be a quick reference for my review as well and can't afford to have mistakes in the info.
OK, then. CCNP Route exam in 7 weeks. Away we go...
Subscribe to:
Posts (Atom)