In this blog post, we are going to provide a sneak peek into some of the awesome information shared in the TSHOOT section of the bootcamp regarding the Troubleshooting of EIGRP. This can prove critical in the Troubleshooting and Configuration sections of the CCIE R&S Lab Exam, as well as the TSHOOT CCNP exam (duh!).
The first thing that you want to master when it comes to troubleshooting EIGRP is the ‘workflow” that EIGRP follows in its operation. We can subdivide the processes of this exciting protocol into four discrete steps:
Discovery of Neighbors
Remember that EIGRP discovers neighbors through bi-directional multicast by default. IP protocol 88 and 224.0.0.10 are the key parameters we need to watch out for here. Could there be issues with NBMA pseudo-broadcast support or filtering causing neighbor discovery to fail? Certainly things to examine in the topology. Also, watch out for the neighbor command under the EIGRP routing process. This feature causes the use of unicast packets for neighbor creation exclusively and must be agreed upon by BOTH neighbors.
Another area we need to be aware of is the attributes that must match in order for neighbors to form. Sure this list is nowhere near as lengthy as the parameters that we have to watch out for in OSPF networks, but the list is just as critical:
When it comes to the exchange of topology information, this is done with unicast. Notice that connectivity for neighborship still requires mutlicast communications (unless you are using the neighbor command).
Remember that EIGRP will only advertise those prefixes that it installs in the routing table. This is an excellent time to review the difference from the Topology Table to the Routing Table.
Important troubleshooting considerations for the exchange of topology information include:
Where Is My Neighbor!?!?!?
- Discovery of neighbors
- Exchange of topology information
- Best path selection
- Neighbor and topology table maintaince
Discovery of Neighbors
Remember that EIGRP discovers neighbors through bi-directional multicast by default. IP protocol 88 and 224.0.0.10 are the key parameters we need to watch out for here. Could there be issues with NBMA pseudo-broadcast support or filtering causing neighbor discovery to fail? Certainly things to examine in the topology. Also, watch out for the neighbor command under the EIGRP routing process. This feature causes the use of unicast packets for neighbor creation exclusively and must be agreed upon by BOTH neighbors.
Another area we need to be aware of is the attributes that must match in order for neighbors to form. Sure this list is nowhere near as lengthy as the parameters that we have to watch out for in OSPF networks, but the list is just as critical:
- Common Subnet (Must be the primary address – not a secondary)
- Autonomous System Number
- Authentication
- K values (metric weights)
When it comes to the exchange of topology information, this is done with unicast. Notice that connectivity for neighborship still requires mutlicast communications (unless you are using the neighbor command).
Remember that EIGRP will only advertise those prefixes that it installs in the routing table. This is an excellent time to review the difference from the Topology Table to the Routing Table.
Important troubleshooting considerations for the exchange of topology information include:
- Automatic summarization in use?
- Split horizon settings
- The use of duplicate router IDs preventing external route introduction
- No seed metric set for external prefixes
- Filtering through the use of distribute lists
No comments:
Post a Comment