Skip to main content

CCIE EIGRP METRIC CALCULATION

One of the annoying fileds in my opinion is calculation, I hate them! in my mind it is just in the way of the cool stuff. but unfurtunetly to get to the cool stuf you need to calculate.

so I would like to start by giving you a little review and may be more indepth look over EIGRP Metric, as we all should know EIGRP is a Hybrid Routing Protocol that use a Composite Metric in his DUAL Diffusing Update Algorithm. the Composite metric is composed (good word selection :-)!?) from K Values.

K1 K2 K3 K4 K5

K1 = Bandwidth = 1 meaning it is used in the calculation by default.

K2 = load = 0 you gust it, meaning that is not participating in the calculation by default.

K3 = Delay = 1 you can take it from here

K4 = Reliability = 0

K5 = MTU = 0

the K values tells us if the value is participating in the calculation or not and what is the weight of the value, meaning that if you set K1 to 3 then it means that the weight of K1 will be 3 times more "important" or in other words it will take the BW * 3.

So now we know what are the "K" Values we need to know how to calculate:


well I will not endolge you with long version of the formula as it is hardly ever use (by hardly I mean I never seen it fully used).

Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]

in the attached picture I draw a small network to demonstrate what I mean to get from R1 to R3 netwrok 3.3.3.0/24

you have the following options:
R1 -> R2 -> R3
The lowes bandwith in that path is 64Kbps
The Delay is 20000 for the 64Kbps link 100 for the 100 Mbps linke and another 100 for the 3.3.3.0/24 network link also 100Mbps = 20200 microseconds delay.

so now lets put all into the formula:

Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 100 + 100)]
Metric = [256 * (156250) + 256 * (20200)]
Metric = [40000000 + 5171200]
Metric = 45171200 = FD Feasable Distance (I will Talk about this in a bit)

R1 -> R4 -> R3

Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 1000 + 100)]

! note that now you have 1000 in the path as it is a regular 10 Mbps Ethernet
Metric = [256 * (156250) + 256 * (21100)]
Metric = [40000000 + 5401600]

Metric = 45401600 = FD

R1 -> R2 -> R4 -> R3
Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 20000 + 20000 + 100)]
Metric = [256 * (156250) + 256 * (60100)]
Metric = [40000000 + 15385600]

Metric = 55385600 = FD

R1 -> R4 -> R2 -> R3 I think you should do it now, you should get the point of the calculation

Now that have an idea how to calculate we need to see what route is preferd, in that senarion it is easy but in complex networks this basics can help us understand the proccess (leave the calc to the router).

FD as I was mentioning this Feasable Distance is the Metric that our router see from his outgoing interface to the point he wish to go, also caled end-to-end metric.

AD Advertised Distance that is the Distance we recive from our directly connected neighbor for the path we wish to go.

so for FD of R1 ->R2 ->R3 we get an AD of R2->R3.

FS Feasible Successor is the Router that is chosen by us to be the next hop to the Destination Prefix.

FC Feasible Condition is a rule that tells us in a very logical way to select a FS he must send to us an AD that is lower then the FD.

if we received from R4 for example a AD higher then the FD that we had already in our topology table to get to R3 then we would not consider him to be a Feasible Successor.

so final step lets take the Paths and FD and Calculate the AD and see what path sould we go as I am already exited where to go from now:

Now our AD for the Paths sent to R1:

R2 -> R3
Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/100000) + 256 * (100 + 100)]
Metric = [256 * (100) + 256 * (200)]
Metric = [25600 + 51200]

Metric = 76800 = AD
Metric = 45171200 =FD


R4 -> R3
Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 100)]
Metric = [256 * (156250) + 256 * (20100)]

Metric = [40000000 + 5145600]
Metric = 45145600 = AD
Metric = 45401600 = FD


R1 -> R2 -> R4 -> R3
Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 20000 + 20000 + 100)]
Metric = [256 * (156250) + 256 * (60100)]
Metric = [40000000 + 15385600]

Metric = 55385600 Here we can clearly see that there is not way that this route can meet the FC.
So we have a winner:
Metric = 76800 = AD
Metric = 45171200 =FD

to get to R3 3.3.3.0/24 R1 will take the path R1 ->R2 -> R3.
if it will fail then the path R1 ->R4->R3 will be taken as he still qualified to meet then FC for FS

FS Feasible Successor the second path in the topology that is set only of FC are met.

I hope this was an intersting article :-)

Comments

Popular posts from this blog

Docker Container Management from Cockpit

Cockpit can manage containers via docker. This functionality is present in the Cockpit docker package. Cockpit communicates with docker via its API via the /var/run/docker.sock unix socket. The docker API is root equivalent, and on a properly configured system, only root can access the docker API. If the currently logged in user is not root then Cockpit will try to escalate the user’s privileges via Polkit or sudo before connecting to the socket. Alternatively, we can create a docker Unix group. Anyone in that docker group can then access the docker API, and gain root privileges on the system. [root@rhel8 ~] #  yum install cockpit-docker    -y  Once the package installed then "containers" section would be added in the dashboard and we can manage the containers and images from the console. We can search or pull an image from docker hub just by searching with the keyword like nginx centos.   Once the Image downloaded we can start a contai

Remote Systems Management With Cockpit

The cockpit is a Red Hat Enterprise Linux web-based interface designed for managing and monitoring your local system, as well as Linux servers located in your network environment. In RHEL 8 Cockpit is the default installation candidate we can just start the service and then can start the management of machines. For RHEL7 or Fedora based machines we can follow steps to install and configure the cockpit.  Following are the few features of cockpit.  Managing services Managing user accounts Managing and monitoring system services Configuring network interfaces and firewall Reviewing system logs Managing virtual machines Creating diagnostic reports Setting kernel dump configuration Configuring SELinux Updating software Managing system subscriptions Installation of cockpit package.  [root@rhel8 ~] #  dnf   install cockpit cockpit-dashboard  -y  We need to enable the socket.  [root@rhel8 ~] #  systemctl enable --now cockpit.socket If firewall is runnin

Containers Without Docker on RHEL/Fedora

Docker is perfectly doing well with the containerization. Since docker uses the Server/Client architecture to run the containers. So, even if I am a client or developer who just wants to create a docker image from Dockerfile I need to start the docker daemon which of course generates some extra overhead on the machine.  Also, a daemon that needs to run on your system, and it needs to run with root privileges which might have certain security implications. Here now the solution is available where we do not need to start the daemon to create the containers. We can create the images and push them any of the repositories and images are fully compatible to run on any of the environment.  Podman is an open-source Linux tool for working with containers. That includes containers in registries such as docker.io and quay.io. let's start with the podman to manage the containers.  Install the package  [root@rhel8 ~] # dnf install podman -y  OR [root@rhel8 ~] # yum