I was going through the EIGRP section of INE's v5 workbook and was doing the EIGRP Named Mode section. They started talking about EIGRP Wide metrics and I had to go and figure this out. A quick Google search came back with a white paper from Cisco that was talking about now that bandwidth is getting to be high (10 gig in places), metrics have to be adjusted to support this. Cisco came up with Wide Metrics which, and I am paraphrasing from my quick reading, that it is where they now can go into greater detail about the metrics and also where they add two new metrics.
More detail, you say? How? So they expanded the metric fields for namely bandwidth and delay. This way bandwidth, which is still measured in Kb, is greater and allows for higher speeds. Delay is measured in picoseconds on one gigabit links or less and it is scaled on links greater than one gigabit since the delay is harder to calculate. Both of these together will help an engineer to further refine their routing plan within their network.
Now for the two newly added metrics. These are accumulative jitter and accumulative energy. Really, I don't see these being used that much but in case some crazy person does want to, they are activated by activating K6.
Another cool fact about this new metric "type" is that the routers can all send both metrics to their peers. This can hog some bandwidth but on normal links this won't kill them and still allow the links to carry other traffic. On large-scale DMVPN networks, Cisco says that this can be a problem and may need to be looked at or just run the same metric type on all the routers. If the routers all support Wide Metrics, then they will all use them and skip the classic style. Cool, interesting fact.
Let's now say you are running EIGRP in a PE/CE situation. Because of the redistribution that will be happening, Wide Metrics are not used. Thought that was good to know for when someone asks. Which will probably be never.
To use Wide Metrics, Cisco says to use IOS or IOS XE and either one had to support EIGRP Release 8.0 or higher. I am running IOS 15.2(4)S3 in my lab so they all picked up the new type with no problem. To check the release that you are running, use the command show eigrp plugins. As you can see below my IOS is running 11.0.
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
So, this is all fine and dandy, but what does this all mean to me when I am troubleshooting. To find out, let's look at a route from my network.
R1#show eigrp address-family ipv4 100 topology 150.1.2.2/32
EIGRP-IPv4 VR(MULTI-AF) Topology Entry for AS(100)/ID(150.1.1.1) for 150.1.2.2/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 10485841920, RIB is 81920640
Descriptor Blocks:
155.1.0.5 (Tunnel0), from 155.1.0.5, Send flag is 0x0
Composite metric is (10485841920/7209041920), route is Internal
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 60001250000 picoseconds
Reliability is 255/255
Load is 2/255
Minimum MTU is 1400
Hop count is 2
Originating router is 150.1.2.2
155.1.13.3 (GigabitEthernet0/0.13), from 155.1.13.3, Send flag is 0x0
Composite metric is (10486497280/10485841920), route is Internal
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 60011250000 picoseconds
Reliability is 255/255
Load is 2/255
Minimum MTU is 1400
Hop count is 3
Originating router is 150.1.2.2
You can see that the delay is now in picoseconds and not microseconds. It also does not mention using Wide Metrics and also does not show the jitter or energy. It does show a really big metric for these routes. Truly other than the picoseconds, there isn't much change. Thank goodness.
Time to get off here now and study more. Oh, before I leave. Here is the link to Cisco's white paper so someone can read it and tell me where I am wrong. :)
Cisco_White_Paper
No comments:
Post a Comment