No, Andy, you explained yourself quite clearly. The question you're asking
is, "Can R3 discover the shortest path to ether2 by detecting or discovering
or learning the fastest interface on a neighboring router (via a routing
protocol that transmits its metrics)?" and the answer is no. You get two
routes with equal identical metrics.
The routing metrics to ether1 from R3 via R1 and R2 will be the same because
they both come from the characteristics of R3's FastEth interface. R3 has
no way of knowing the bandwidth of R1's link or R2's link - it only knows
its own link(s).
Think of a router as a big ARP table. All a basic router knows how to do is
map MAC addresses to IP/IPX/AT/DECnet/IBM network addresses. Anything above
and beyond that requires either
a. routing protocols (RP) that transmit their secondary metrics
(bandwidth/delay/load/reliability) in their routing updates, or
b. human intelligence
In the human intelligence arena, one could policy-route from R3 to R1 to
force routing in that direction, but that's a manual, not automatic,
procedure. One could also configure different RPs - run OSPF on the R1/R3
pair and RIP on the R2/R3 pair - the OSPF administrative distance is lower
than RIP, and therefore the R3 would take the R1 path to ether1.
In the RP arena, when you find an IGP that sends its secondary metrics info
as part of the routing update, let me know. ;-)
Now I'll give you something that DOES work - Let's put ether3 on a 2nd
fastethernet port of R3. R1 has 2 routes to ether2 - via ether1 R2 ether2
R3, and via ether2 R3. The preferred route is via the GigE interface
regardless of IGP because the metric will be smaller and the number of hops
is smaller.
Let's flip the interfaces, so that GigE on R1 faces ether1 and FastEth on R1
faces ether2. Guess what? If you're using a DVP (like RIP), the preferred
route is ether2 R3 (smaller hop count). If you're using a LSP (like OSPF),
the preferred route is ether1 R2 ether2 R3 (better interface metric). Go
figure...
-e-
----- Original Message -----
From: "Andy Harding"
To:
Sent: Monday, May 07, 2001 12:54 PM
Subject: Re: Route metrics on broadcast networks [7:3308]
> thanks for the response - I'm not sure that I explained myself clearly,
> should have done a diagram
>
> |------------| ether1
> | |
> fe| |fe
> R1 R2
> ge| |fe
> | |
> |-----------| ether2
> |
> |fe
> R3
> |
|-----------| ether3
> in view of the above, R3 has attached FE route to each of R1 and R2 which
> will each announce ether1 with equal metrics, based on the equal cost
> upstream. does R3 have any way of knowing that R1 is GE attached to
ether1,
> and that it (R3) should prefer the route via R1?
>
> what I am going after is whether, when one might have different bandwidths
> (10/100/1000 for ethernet), a router would be able to discern from the
> ourting information, which router to prefer in the case of there being
> parallel paths to a network, in the case of those routers having
> different-speed attachments to an interrim, attached, broadcast network.
>
> hope I've made sense this time ;-)
>
> regards
>
> Andy
>
> ----- Original Message -----
> From: "EA Louie"
> To: "Andy Harding" ;
> Sent: Sunday, May 06, 2001 7:01 PM
> Subject: Re: Route metrics on broadcast networks [7:3308]
>
>
> > 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]
> 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=3510&t=3308
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
