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.
Subscribe to:
Posts (Atom)