Between studying for an Aruba wireless test and studying for my CCIE, time just gets away from me. Anyways, life goes on. I have been working on the INE workbook for EIGRP. I made it through some of the labs and most of it I have gotten right. There were a few gotchas. Feel pretty good thus far with it.
We all pretty much know what split horizon is and what it does. I know from the v4 test that you have to make sure that it was off when doing frame. Now that frame is off the blueprint, they still make you turn it off and this time with EIGRP. Not a gotcha there but an interesting. No matter the interface, split horizon is on by default. Tunnel, fast ethernet, whatever. Good to know.
Another thing that is default and this is recent to the 15 code is auto-summary is turned off. Thank goodness. Now to use it, which is rare, you have to explicitly turn it on. Hmm... A possible trouble ticket?
EIGRP now uses something called EIGRP Wide Metrics. This is where the metric is now 64 bits to accommodate super fast interfaces, such as a 10Gb or more. Gives better granularity over the metric for better routing. According to Cisco, the impact of using wide metrics is minimal except on DMVPN large scale deployments. There may be an impact there. Also, only bandwidth and delay are on and used for metric calculation by default, just like the regular metric. The delay on bandwidth that is below one gigabit is set to picoseconds and not microseconds and bandwidth above one gigabit uses a computed delay. There are two new values that can be used for metric calculation as well and they are accumulative jitter and energy and they are enabled with K6.
To use EIGRP Wide Metrics, you just have to run the 15 code. The routers will talk and if they all support the new metric, then away they go. If not, they fall back. Also, in a PE/CE environment, wide metrics will not be used and will used scaled attributes only. Also all routers that wish to use wide metrics have to use EIGRP Release 8.0 or higher. To see what version you are running, use the command show eigrp plugins as shown below from a router in my lab.
R1#show eigrp plugins
EIGRP feature plugins:::
eigrp-release : 11.00.00 : Portable EIGRP Release
: 1.00.19 : Source Component Release(rel11)
parser : 2.02.00 : EIGRP Parser Support
igrp2 : 2.00.00 : Reliable Transport/Dual Database
bfd : 2.00.00 : BFD Platform Support
mtr : 1.00.01 : Multi-Topology Routing(MTR)
eigrp-pfr : 1.00.01 : Performance Routing Support
EVN/vNets : 1.00.00 : Easy Virtual Network (EVN/vNets)
ipv4-af : 2.01.01 : Routing Protocol Support
ipv4-sf : 1.02.00 : Service Distribution Support
vNets-parse : 1.00.00 : EIGRP vNets Parse Support
ipv6-af : 2.01.01 : Routing Protocol Support
ipv6-sf : 2.01.00 : Service Distribution Support
snmp-agent : 2.00.00 : SNMP/SNMPv2 Agent Support
Authentication in EIGRP is something that I remember since learning about EIGRP and it has always been MD5. With the addition of Named Mode and the 15 code, there is now SHA 256 available. It has to done in Named Mode and it does not support the used of key chains but it is there for your use.
Speaking of Named Mode, I have to remember to use the address-family when trying to look at anything in EIGRP. Bit me in the behind a couple of times. For example, the following command is if you wanted to see the EIGRP detailed information about gi0/0.146.
show eigrp address-family ipv4 100 interfaces detail gi0/0.146
I love neighbor commands because that is like real life in that I want to know who the heck is around me at all times. Little paranoid I guess. When using neighbor commands on a tunnel interface for say DMVPN, you have to define all the neighbors. If you don't, it will drop all the others and they will not be able to register with that device. And when you are defining that neighbor, don't forget the interface that neighbor should come in on.
I hate, I repeat, HATE redistribution. For some reason, I always forget some stupid little thing and it blows my whole dag-nabbed thing up. Whether it is distance or filtering or some trivial garbage, it rarely works like anyone wants for me. Basic redistribution is fine. Fancy stuff kills me each time. But that is not the purpose here. The purpose here is to remind that the redistribution command in Named Mode falls under the topology base section.
So the last section that I did was on route summarization with poisoning. I remember in the 12 code, you could add 255 to the end of a summary-route and it would block the Null0 from being added to the routing table. No more. Now, you have to add the command summary-metric to the routing process along with the summary-route to the interface. Reading the command reference for the command, I like the command overall. It stops all recalculations for the route on each interface when a metric variable changes and makes them all standard for the ones that match the route in the command. I guess that I can also see the use of it for the distance section so that it applies to all the interfaces with the summary-route. What if you want finer granularity with this interface doing this and that one doing that? Hmm.. May need to look into that. The way the lab had it was confusing at first but was a great way to show how the command can be used to filter a route from being advertised. Not bad overall.
Well, that is it for now. Need to finish the next section.
No comments:
Post a Comment