see these pages:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/routing.htm
http://www.cisco.com/warp/public/103/5.html (this one is very technical, but
addresses metric calculation in IGRP)
http://www.cisco.com/cpress/cc/td/cpress/fund/iprf/ip2907.htm (general
presentation of route metrics)
----- Original Message -----
From: "Andy Harding"
To:
Sent: Saturday, May 05, 2001 7:28 AM
Subject: Route metrics on broadcast networks [7:3308]
> bit of a teaser I have been thinking about for a while, and haven't really
> been able to get clear in my mind:
>
> how do routing protocols calculate metrics on broadcast networks where the
> metric may be different between different neighbors?
In each routing protocol is an inherent metric value called administrative
distance. That's the primary routing path determination for IGPs. Other
metrics are local and determined by the interface characteristics.
Let's use the case of IGRP. (RIP is hop-count sensitive and uses that as
its routing metric).
All the router knows is the properties of its directly connected interfaces,
so it uses parameters like interface bandwidth, and delay, and the its
administrative distance to calculate the route metrics, including the ones
it learns. It then sends the routes it has for its directly-connected
routes and its learned routes to another router. That other router does the
same thing with the learned routes - that is, calculates learned route
metrics based on the ingress interface bandwidth and delay parameters and
the administrative distance of the IGRP itself.
>
> As an example, say you have a core router with a GE downlink into an
ethernet
> switch, and you have you distribution switches attached with FE. Do the
> distribution-level routers know to prefer the core router's uplink (all
other
> things being equal)? and if so, how?
Well, directly connected routes are best, regardless of what your other
routes may be, so if the Distribution router and Core router are in
parallel, the Distribution router would prefer his own route. Otherwise,
the routers that are FE connected will have higher metrics than the GigE
route. From an uplink perspective, let's say you have a distribution router
on the switch, and two paths out: via GigE core router and via FastE access
router. The distribution router will accept routes from both core and
access routers. Distribution router will see them as the same route with
exactly the same metric unless the metrics have been artificially altered in
one or the other router. Distribution router doesn't know how the core and
access routers are connected, and can't make a routing decision based on
their interface bandwidths.
Let's take another case, where the distribution router has two interface
paths - one Gigabit to the core, one Fast to the access router. Let's also
say that the core and access routers are parallel - that is, have the same
destination networks in its routing table. In the distribution routing
table, it will have a smaller metric to the core router, and therefore will
prefer that path. However, the routes from the access router will also be
there, so if the route to the Core router is lost, the backup will be to the
access router.
To summarize, the distribution router really has no knowledge of the uplink
bandwidth of it's neighbors, so it's no wonder that this has caused you
sleepless nights.
EIGRP handles metrics a bit differently. See
http://www.cisco.com/warp/public/103/eigrp-toc.html
and read the section on EIGRP metrics
OSPF also handles metrics a little differently - see
http://www.cisco.com/warp/public/104/9.html
and read the answer to the question "How does OSPF calculate its metric or
cost?"
>
> many thanks
>
> Andy
> FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=3375&t=3308
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]